필사 모드: 화면은 열 글자로 쓰입니다 — 커스텀 위젯을 만들기 전에 물어야 할 한 가지

• 디자인 리뷰에서 나온 문장 하나
• 스물여섯 글자와 열 개의 요소
• 순위 자체가 정보입니다
• 위젯을 새로 만들 때 실제로 버리는 것
• 계약을 어기는 흔한 방식 네 가지
• 창과 포인터가 목록에서 빠진 이유
• 근거 있는 규칙이란 어떤 모양인가
• 이번 주에 할 수 있는 것 — 컴포넌트 목록에 글자를 붙이기
• 정리와 출처

디자인 리뷰에서 나온 문장 하나

새 화면 시안에 처음 보는 조작 단위가 하나 들어 있습니다. 카드처럼 생겼는데 클릭하면 선택되고, 선택되면 테두리가 생기고, 여러 개를 고를 수 있습니다. 만든 사람에게 이게 뭐냐고 물으면 대답은 대개 이렇습니다. 선택 카드요.

이때 나와야 하는 질문은 예쁜지가 아니라 이겁니다. 이건 체크박스인가요, 아니면 탭인가요, 아니면 그 밖의 무엇인가요. 이 질문이 왜 유용한지가 이 글의 내용입니다.

스물여섯 글자와 열 개의 요소

제이콥 닐슨이 2026년 7월 29일에 올린 GUI 요소에 관한 글은 비유 하나로 시작합니다. 스물여섯 개의 알파벳이면 모든 영어 단어를 쓸 수 있듯이, 열 개 남짓한 요소면 지금까지 나온 거의 모든 사용자 인터페이스를 조립할 수 있다는 것입니다. 그리고 그 열 개를 근거 기반 지침 86개와 함께 정리합니다.

목록은 이렇습니다. 버튼, 입력 필드와 폼, 메뉴, 링크, 대화 상자, 알림과 오류 메시지, 아이콘, 체크박스와 라디오 버튼, 탭, 검색.

처음 보면 시시합니다. 여기 없는 걸 만들어 본 적이 없어서 시시한 겁니다. 그런데 우리 디자인 시스템의 컴포넌트 목록을 꺼내 놓고 세어 보면 대개 마흔 개에서 여든 개가 나옵니다. 열 개짜리 알파벳으로 쓴 글에 왜 여든 개의 글자가 필요했는지를 설명할 수 있어야 합니다.

순위 자체가 정보입니다

닐슨은 이 열 개를 그냥 나열하지 않고 순서를 매겼습니다. 기준은 사용자의 일상적 상호작용이 각각에 얼마나 많이 걸려 있는가입니다. 그래서 1위가 버튼이고 10위가 검색입니다.

이 순서는 실무에서 우선순위표로 쓸 수 있습니다. 팀의 시간은 유한하고, 보통 새 컴포넌트에 쏠립니다. 그런데 사용자가 하루 동안 가장 많이 만지는 것은 언제나 버튼과 입력 필드입니다. 버튼의 상태 표현, 비활성 이유 안내, 터치 영역 크기, 폼 오류 메시지의 위치 같은 것들이 순위 1, 2위에 해당하는 작업입니다.

반대로 말하면 이렇습니다. 새로 만든 카드형 선택 위젯을 다듬는 데 사흘을 쓰는 동안 버튼의 비활성 상태가 왜 비활성인지 아무 데도 적혀 있지 않다면, 그 사흘은 순위표의 아래쪽에 쓰인 것입니다.

위젯을 새로 만들 때 실제로 버리는 것

새 위젯의 비용은 구현 시간이 아닙니다. 구현은 대개 하루면 끝납니다. 진짜 비용은 사용자가 이미 알고 있던 계약을 버리는 것입니다.

체크박스에는 사용자가 학습을 마친 계약이 붙어 있습니다. 여러 개를 고를 수 있고, 다시 누르면 해제되고, 라벨을 눌러도 토글되고, 키보드로 탭 이동한 뒤 스페이스로 켜지고, 스크린 리더가 선택 상태를 읽어 줍니다. 이 계약은 우리가 만든 것이 아니라 수십 년 동안 수천 개의 제품이 같은 방식으로 동작해서 생긴 것입니다.

카드형 선택 위젯을 새로 만들면 이 계약이 전부 초기화됩니다. 다시 누르면 해제되는지 사용자는 모릅니다. 키보드로 접근 가능한지는 우리가 따로 만들어야 합니다. 그리고 만들지 않으면 조용히 없습니다. 즉 새 위젯의 원가는 구현 하루가 아니라 버려진 계약을 우리 손으로 다시 짓는 비용 전부입니다.

그래서 앞의 질문이 중요합니다. 이게 체크박스라면, 체크박스로 구현하고 겉모습만 카드로 바꾸면 됩니다. 계약은 그대로 남습니다.

계약을 어기는 흔한 방식 네 가지

목록의 열 글자 중 무엇인지를 정한 다음에도, 그 글자의 계약을 반쯤 어기는 일이 자주 생깁니다. 자주 보이는 형태는 이렇습니다.

• 링크처럼 생겼는데 버튼인 경우: 밑줄 친 파란 글씨를 새 탭으로 열려고 가운데 클릭했는데 아무 일도 일어나지 않습니다. 링크와 버튼의 차이는 모양이 아니라 이동인가 실행인가입니다.
• 버튼처럼 생겼는데 라디오인 경우: 나란히 놓인 버튼 세 개 중 하나를 누르면 나머지가 꺼집니다. 이건 라디오 버튼의 동작인데, 눌렀을 때 무언가 실행될 것이라 기대한 사용자는 한 박자 멈칫합니다.
• 탭인데 페이지가 바뀌는 경우: 탭은 같은 맥락 안에서 보이는 면을 바꾸는 장치입니다. 탭을 눌렀는데 뒤로 가기 기록이 쌓이면 사용자의 모델이 깨집니다.
• 알림인데 조작을 요구하는 경우: 알림은 지나가도 되는 것이고 대화 상자는 답해야 하는 것입니다. 몇 초 뒤에 사라지는 토스트 안에 되돌리기 버튼만 있으면, 그 되돌리기는 놓치라고 만든 것에 가깝습니다.

네 가지의 공통 구조가 있습니다. 겉모습으로 하나를 약속하고 동작으로 다른 것을 줍니다. 사용자는 겉모습을 믿습니다.

창과 포인터가 목록에서 빠진 이유

닐슨은 창과 포인터를 본문 열 개에 넣지 않고 보너스로 따로 다룹니다. 이유는 이 둘이 이제 대체로 운영체제의 몫이 되었기 때문이라고 밝힙니다.

이 구분이 실무에서 유용한 이유는, 우리가 만들지 말아야 할 것을 알려 주기 때문입니다. 웹 앱 안에 창 관리 기능을 직접 구현하는 순간 그 창은 운영체제의 창과 다르게 동작하기 시작합니다. 최소화가 없거나, 드래그 영역이 다르거나, 겹침 순서가 다릅니다. 사용자는 운영체제 쪽 계약을 기준으로 기대합니다.

포인터도 같습니다. 커서 모양을 바꾸는 것은 상태를 알려 주는 강력한 수단이지만, 커서 자체를 그림으로 대체하는 순간 지연이 눈에 보입니다. 플랫폼이 이미 맡고 있는 층을 다시 만들 때는 그 층의 기존 계약 전부를 이겨야 합니다.

근거 있는 규칙이란 어떤 모양인가

닐슨의 글이 근거 기반이라고 말할 때의 근거가 어떤 것인지 한 예로 보겠습니다. 글이 인용하는 것 중 하나가 1954년의 피츠의 법칙입니다. 어떤 대상을 가리키는 데 걸리는 시간은 그 대상까지의 거리와 대상의 크기로 정해진다는 실험 결과입니다. 멀수록 오래 걸리고 클수록 빨라집니다.

그래서 버튼을 크게 그리라는 말은 취향이 아니라 측정된 사실의 결과입니다. 여기서 실무적으로 더 쓸 만한 따름 결과가 나옵니다. 화면의 모서리와 가장자리는 무한히 큰 목표처럼 동작합니다. 마우스를 아무리 세게 던져도 화면 밖으로 나가지 않기 때문입니다. 자주 쓰는 조작을 가장자리에 붙이면 같은 크기라도 더 빨리 닿습니다.

이 글은 다른 종류의 근거도 인용합니다. 남성의 약 12명 중 1명이 적록 색각 이상을 갖는다는 수치가 그렇습니다. 색만으로 상태를 구분한 화면이 왜 위험한지에 대한 답이 여기 있습니다. 그리고 폼 필드 하나를 없앤 것만으로 연간 1200만 달러 규모의 개선이 있었다는 사례도 소개합니다. 이 사례는 제가 원 자료까지 확인하지 않았고, 닐슨의 글이 전하는 내용으로 적습니다.

이번 주에 할 수 있는 것 — 컴포넌트 목록에 글자를 붙이기

한 시간이면 되는 작업이 있습니다.

1. 디자인 시스템의 컴포넌트 목록을 그대로 표로 옮깁니다.
2. 각 항목 옆에 열 개 중 어느 글자인지를 적습니다. 버튼, 입력, 메뉴, 링크, 대화 상자, 알림, 아이콘, 체크박스와 라디오, 탭, 검색.
3. 글자를 적을 수 없는 항목에 표시를 합니다.
4. 표시된 항목마다 한 줄로 답합니다. 이건 어떤 계약을 새로 만든 것이고, 그 계약을 문서와 접근성 구현으로 실제로 지키고 있는가.

대부분의 팀에서 3번에 남는 항목은 두세 개입니다. 그 두세 개는 대개 정말로 필요한 것들이고, 나머지는 기존 글자의 다른 옷입니다. 다른 옷이라는 사실을 코드에 반영하는 순간 접근성과 키보드 조작이 공짜로 따라옵니다.

정리와 출처

목록의 가치는 무엇을 만들지 알려 주는 데 있지 않습니다. 새로 만든 것이 알파벳에 없는 글자라면, 그 글자를 처음부터 다 가르쳐야 한다는 사실을 알려 주는 데 있습니다.

• 10 GUI Design Elements Build Every User Interface — 제이콥 닐슨, 2026년 7월 29일. 열 개의 목록과 순위 기준, 지침 86개, 창과 포인터를 따로 다룬 이유, 피츠의 법칙과 색각 이상 수치, 폼 필드 사례가 모두 이 글에서 나온 것입니다.
• 열 개의 순서와 순위 기준, 알파벳 비유, 지침 개수는 위 글에서 직접 확인했습니다. 본문의 계약 위반 네 가지 예시와 컴포넌트 라벨링 작업은 이 글이 제시하는 것이 아니라 제가 그 관점을 실무에 옮겨 본 것입니다.