UI 컴포넌트

화면을 그리다 보면 같은 것이 계속 다시 나옵니다. 문서 목록에도 버튼이 있고 설정 화면에도 버튼이 있고 결제 화면에도 버튼이 있습니다. 예전에는 그때마다 새로 그렸습니다. 시안 파일을 열어 사각형을 그리고 모서리를 둥글리고 글자를 얹었습니다. 개발 쪽도 같았습니다. 화면마다 버튼 코드를 새로 썼습니다.

한 사람이 열 장을 그릴 때는 이 방식이 문제를 일으키지 않습니다. 앞 화면을 복사해 오면 되고, 조금 어긋나도 열 장을 나란히 놓고 보면 금방 눈에 띕니다. 사람이 셋이 되고 화면이 백 장이 되면 사정이 달라집니다. 각자 기억하는 버튼이 조금씩 다르고, 어느 것이 맞는지 물어볼 데가 없습니다.

페이지덱에서 이 문제가 눈에 띈 것은 문서 삭제 확인 창을 만들 때였습니다. 민서가 앞서 만들어 둔 창들을 열어 보니 이미 세 곳에 비슷한 것이 있었는데 닫는 방법이 다 달랐습니다. 공유 설정 창은 바깥을 누르면 닫혔고, 결제 창은 ESC 키만 먹었고, 초대 창은 오른쪽 위 X 만 눌러야 닫혔습니다. 실제로 수아가 고객에게 받은 문의도 이것이었습니다. 창 바깥을 눌렀는데 안 닫혀서 멈춘 줄 알았다는 이야기였습니다.

같은 기간에 태오 쪽에도 같은 문제가 다른 모양으로 있었습니다. 세 창이 각각 다른 코드로 만들어져 있어서, 닫는 방법을 하나로 맞추려면 세 곳을 따로 고쳐야 했습니다. 나중에 창이 열 곳으로 늘면 열 곳을 고쳐야 한다는 뜻이기도 했습니다.

문제의 뿌리는 같은 것을 여러 벌 만들어 두었다는 데 있습니다. 여러 벌이 있으면 그 벌들이 어긋나는 것은 시간문제고, 어긋난 뒤에는 어느 쪽에 맞출지부터 정해야 합니다. UI 컴포넌트는 그 벌을 하나로 줄이는 장치입니다. 버튼을 한 번 제대로 만들어 두고, 화면은 그것을 새로 그리는 대신 가져다 씁니다. 그러면 모서리 둥글기를 바꾸는 일이 한 곳을 고치는 일이 되고, 닫는 방법을 맞추는 일도 한 번으로 끝납니다.

부품을 모아 두는 틀이 디자인 시스템입니다. 색과 글자 크기 같은 값, 언제 무엇을 쓰는지 적은 문서, 그리고 부품이 함께 들어갑니다. 그중에서 화면에 실제로 놓이는 물건 하나하나를 가리키는 말이 이 페이지의 표제어입니다.

UI 컴포넌트 아래 묶인 용어는 여섯 갈래입니다. 세 질문으로 묶으면 지형이 잡힙니다. 사용자가 무엇을 하는가(동작·입력), 화면 위에 어떻게 얹히는가(레이어·알림), 무엇을 어떤 모양으로 보여 주는가(표시·구성)입니다.

동작은 한 종류뿐입니다. 버튼은 누르면 무언가가 실행되는 요소입니다. 종류가 하나라고 단순하지는 않습니다. 버튼 하나에 평소 모습, 마우스를 얹었을 때, 누르고 있을 때, 눌러도 안 되는 상태, 눌린 뒤 결과를 기다리는 상태가 다 있어야 합니다. 특히 마지막 두 가지를 빼먹으면 사용자가 같은 버튼을 두 번 누르고 문서가 두 번 저장됩니다.

입력은 사용자에게서 값을 받아 오는 갈래이고 여덟 종류가 있습니다. 자유롭게 쓰게 할 것인지 정해진 것 중 고르게 할 것인지가 첫 갈림길입니다.

1. 인풋 — 글자를 직접 받습니다. 이름이나 검색어처럼 미리 목록을 만들 수 없는 값에 씁니다.
2. 셀렉트 — 정해진 목록에서 하나를 고릅니다. 평소에는 접혀 있어서 자리를 적게 먹습니다.
3. 콤보박스 — 입력하면서 후보를 좁혀 고릅니다. 나라 이름처럼 후보가 200개쯤 되어 목록을 훑는 것보다 몇 글자 치는 게 빠를 때 씁니다.
4. 체크박스 — 여러 개를 함께 고릅니다. 알림 종류를 셋 다 켜는 식입니다.
5. 라디오 버튼 — 여럿 중 하나만 고릅니다. 요금제처럼 둘 이상을 동시에 고를 수 없는 값에 씁니다.
6. 토글 — 켜고 끄는 두 상태를 오갑니다. 체크박스와 달리 누르는 즉시 반영되는 자리에 쓰고, 그래서 따로 저장 버튼이 없는 설정 화면에 잘 맞습니다.
7. 슬라이더 — 범위 안의 값을 끌어서 정합니다. 정확한 숫자보다 대략의 위치가 중요한 값에 씁니다.
8. 데이트 피커 — 달력에서 날짜를 고릅니다. 글자로 받으면 2026-09-16 인지 16/09/2026 인지부터 어긋나서 따로 둡니다.

고르는 요소 사이의 선택은 대개 개수로 갈립니다. 선택지가 두셋이면 라디오 버튼으로 펼쳐 두는 쪽이 빠르고, 예닐곱을 넘으면 셀렉트로 접는 편이 낫고, 수십 개를 넘어가면 콤보박스로 검색하게 만듭니다. 선택지 열두 개를 라디오 버튼으로 깔면 그 질문 하나가 화면 절반을 차지합니다.

레이어는 기존 화면 위에 덧씌워 뜨는 갈래이고 네 종류입니다. 뒤를 얼마나 막느냐로 갈립니다.

1. 모달 — 뒤 화면을 어둡게 덮고 위에 뜹니다. 답하기 전에는 다른 일을 못 하게 막는 것이 목적이라, 삭제 확인처럼 되돌릴 수 없는 결정에 씁니다. 막는 것이 곧 비용이라 자주 쓰면 안 됩니다.
2. 드로어 — 화면 가장자리에서 밀려 나옵니다. 뒤가 절반쯤 보여서, 목록을 보면서 한 건을 고치는 작업에 맞습니다.
3. 팝오버 — 특정 요소에 붙어 작게 뜹니다. 아바타를 누르면 그 아래에 계정 메뉴가 뜨는 식입니다.
4. 툴팁 — 요소에 닿았을 때 짧은 설명을 띄웁니다. 손가락으로 쓰는 화면에는 닿는 동작이 없어서 툴팁만 보고 알 수 있는 정보를 넣으면 그 정보는 모바일에서 사라집니다.

알림은 사용자가 요청하지 않았는데 제품이 먼저 말을 거는 갈래이고 셋입니다. 얼마나 오래 남느냐가 기준입니다.

1. 토스트 — 3초쯤 떴다 사라집니다. "저장했습니다" 처럼 놓쳐도 되는 확인에 씁니다.
2. 스낵바 — 결과를 알리면서 되돌릴 기회를 함께 줍니다. 문서를 지운 직후 "삭제했습니다 · 실행 취소" 가 뜨는 자리입니다.
3. 배너 — 화면 위쪽에 걸려 계속 남습니다. 결제 실패나 점검 예정처럼 읽고 나서 무언가를 해야 하는 공지에 씁니다.

셋을 가르는 기준은 하나입니다. 놓치면 곤란한 내용은 사라지는 알림에 담지 않습니다. 결제 카드가 만료됐다는 안내를 토스트로 띄우면 다른 화면을 보던 사람은 그 문장을 영영 못 봅니다.

표시는 사용자가 누르는 대상이 아니라 상태를 알려 주는 갈래이고 넷입니다. 배지는 개수나 상태를 작게 붙입니다. 안 읽은 알림이 셋이라는 빨간 동그라미가 이것입니다. 칩은 선택이나 태그를 알약 모양으로 나타내고, 필터를 걸었을 때 무엇이 걸려 있는지 보여 주는 자리에 자주 씁니다. 아바타는 사용자를 대표하는 작은 이미지라 누가 문서를 보고 있는지 알립니다. 프로그레스는 진행 정도를 보여 줍니다. 몇 퍼센트인지 아는 경우와 모르는 경우의 모양이 다르고, 1초 넘게 기다리게 되는 자리에는 무엇이든 띄워야 사용자가 멈춘 줄 알고 새로고침하지 않습니다.

구성은 정보를 어떻게 배치하고 나누느냐를 다루는 갈래이고 여섯입니다. 탭은 같은 자리에서 내용을 갈아 끼웁니다. 아코디언은 제목을 눌러 내용을 접고 펴서, 대부분 안 볼 내용을 접어 두는 데 씁니다. 카드는 관련 정보를 한 덩어리로 묶은 상자라 목록을 격자로 늘어놓을 때 씁니다. 테이블은 행과 열로 데이터를 늘어놓아 값끼리 견주기 좋게 만듭니다. 페이지네이션은 목록을 쪽으로 나눠 이동하게 합니다. 스테퍼는 여러 단계를 순서대로 밟게 하고, 지금 몇 번째인지와 몇 개가 남았는지를 함께 보여 줍니다.

여섯 갈래는 쌓는 순서가 아니라 고를 때의 질문 순서에 가깝습니다. 사용자에게 무엇을 시킬지 정하면 동작과 입력에서 고르게 되고, 그것을 지금 화면 위에 띄울지 아래에 놓을지 정하면 레이어와 알림에서 고르게 되고, 결과를 어떻게 보여 줄지 정하면 표시와 구성에서 고르게 됩니다. 이 부품들이 실제 화면에서 잘 도는지는 접근성이 함께 걸립니다. 키보드만으로 모달을 닫을 수 있는지, 배지의 빨간색을 못 보는 사람에게도 개수가 전해지는지가 부품 단위에서 정해지기 때문입니다.

"이건 모달 말고 드로어로 가죠. 뒤 목록을 보면서 고쳐야 해서요."

작업 도중에 뒤 화면 정보가 필요하니 뒤를 완전히 막는 레이어는 쓰지 말자는 말입니다.

"선택지가 열두 개면 라디오 말고 셀렉트로 바꿔 주세요."

항목을 다 펼쳐 두면 화면을 너무 먹으니 접히는 요소로 바꾸라는 요청입니다.

"이 내용은 놓치면 안 되는 거라 토스트 말고 배너로 올려야 할 것 같아요."

몇 초 뒤 사라지는 알림에 반드시 읽어야 할 내용이 들어 있다는 지적입니다.

삭제 확인 창 이야기 뒤에 페이지덱은 순서를 바꿨습니다. 민서가 새 화면을 그릴 때 부품부터 고르고, 고를 것이 없을 때만 새로 그리기로 했습니다. 창은 하나로 합쳐 바깥 클릭과 ESC 키 둘 다로 닫히게 맞췄고, 태오는 그 창을 코드로도 한 벌만 남겼습니다. 그 뒤로 새 창이 필요하면 안에 들어갈 내용만 바꿔 끼웁니다.

바뀐 것은 만드는 속도만이 아닙니다. 민서와 태오가 같은 이름을 쓰게 됐습니다. 시안에 "확인 모달" 이라고 적혀 있으면 태오가 코드에서 같은 이름을 찾아 쓸 수 있습니다. 예전에는 시안 속 사각형이 어느 코드에 대응하는지 매번 물어봐야 했습니다.

부품을 보이는 모양으로만 읽는 것이 첫 번째 오해입니다. 시안에 그려진 것이 모양뿐이니 그렇게 보이는 것도 당연합니다. 실제로 부품의 본체는 모양보다 규칙 쪽에 있습니다. 비활성일 때 어떻게 보이는지, 글자가 길어지면 줄을 바꾸는지 잘라 내는지, 최소 너비가 얼마인지, 누른 뒤 응답이 3초 걸리면 그동안 무엇을 보여 주는지 같은 것들입니다. 시안에는 대개 잘 풀린 경우 하나만 그려져 있어서, 이 규칙이 적혀 있지 않으면 개발자가 나머지 경우를 혼자 정하게 됩니다. 그러면 같은 버튼이 화면마다 다르게 동작하고, 부품을 만든 이유가 그 자리에서 사라집니다.

두 번째는 부품이 많을수록 시스템이 좋아진다고 읽는 것입니다. 만들어 둔 것이 많으면 골라 쓸 것도 많아 보입니다. 실제로는 고르는 비용이 함께 늡니다. 버튼 종류가 서른 개가 되면 새로 들어온 사람은 어느 것이 맞는지 판단하지 못하고, 판단하지 못하면 결국 새로 하나를 만듭니다. 그렇게 서른한 개가 됩니다. 늘려야 할 때는 종류를 늘리는 대신 한 부품 안에서 성격과 크기를 가르는 쪽이 낫습니다. 버튼 하나에 기본·보조·위험 세 성격과 대·중·소 세 크기를 두면 쓰는 사람은 목록 서른 개를 훑는 대신 두 가지 질문만 답하면 됩니다.