컴포넌트 라이브러리

부품을 한 번만 만들어 돌려 쓰자는 데까지는 팀이 금방 합의합니다. 막히는 건 그다음 질문입니다. 그 부품을 어디에 둘 것인가.

페이지덱도 이 자리에서 한 번 넘어졌습니다. 민서가 문서 목록 화면을 만들며 버튼을 한 번 제대로 그려 뒀는데, 그 원본은 문서 목록 시안 파일 안에 있었습니다. 두 달 뒤 결제 화면을 새 파일에서 시작하며 민서는 앞 파일을 열어 버튼을 복사해 왔습니다. 반년 뒤 파일은 일곱 개가 됐고 버튼도 일곱 벌이 됐습니다. 높이가 40인 것과 44인 것이 섞여 있었고, 어느 쪽이 맞는지 아는 사람이 없었습니다.

새로 들어온 디자이너의 질문에서 사정이 분명해졌습니다. "버튼 어디서 가져오면 되나요" 라는 질문에 "아마 결제 화면 파일에 있는 게 제일 최신일 거예요" 라는 답이 돌아왔습니다. 부품이 있는 것과 부품을 찾을 수 있는 것은 다른 문제였습니다. 찾을 수 없으면 사람들은 옆 화면에서 복사하고, 복사하는 순간 벌이 하나 더 늘어납니다.

UI 컴포넌트가 부품 하나를 가리킨다면 컴포넌트 라이브러리는 그 부품들을 꺼내 쓸 수 있게 모아 둔 자리입니다. 만드는 일과 모아 관리하는 일이 서로 달라서 이름이 따로 생겼습니다.

라이브러리에 들어가는 것은 부품만이 아닙니다. 다섯 가지가 한 묶음으로 들어갑니다.

1. 부품. 버튼·입력창·모달·탭처럼 화면에 놓이는 물건입니다. 제품 하나에 보통 30개에서 60개이고, 이 목록이 곧 화면을 만들 때의 선택지가 됩니다.
2. 부품마다의 형태와 상태. 배리언트로 기본·보조·위험 같은 성격을 나누고, 상태로 평소·마우스 얹힘·누름·비활성·대기를 갖춥니다. 성격 셋에 크기 셋에 상태 다섯이면 버튼 하나가 마흔다섯 칸입니다.
3. 부품을 만든 재료 값. 색과 간격은 부품에 직접 적지 않고 디자인 토큰, 곧 값에 이름을 붙여 둔 단위를 불러 씁니다. 그래야 다크 모드를 붙일 때 부품을 다시 만들지 않고 토큰만 갈아 끼우면 됩니다.
4. 쓰는 법. 부품마다 컴포넌트 명세가 붙습니다. 글자가 길어지면 자르는지 줄바꿈하는지, 어떤 상황에서 이 부품을 쓰지 말아야 하는지가 적힙니다.
5. 판번호와 변경 기록. 3.2에서 3.3으로 올리며 무엇이 바뀌었는지 적어 둡니다. 쓰는 쪽은 이 기록을 보고 갱신을 지금 받을지 배포 뒤로 미룰지 정합니다.

라이브러리는 한 벌이 아니라 짝으로 존재합니다. 디자이너가 쓰는 시안 파일과 개발자가 코드에서 불러 쓰는 꾸러미입니다. 코드 쪽에서 부품 하나를 컴포넌트라고 부르고, 그 부품만 화면 없이 따로 띄워 상태별로 확인하는 도구가 스토리북입니다. 두 벌의 이름이 어긋나면 짝이 깨집니다. 시안의 강조 버튼을 코드에서 메인 버튼이라 부르면, 둘이 같은 것인지는 사람 기억으로만 확인됩니다.

만드는 사람은 둘이고 읽는 사람은 팀 전체입니다. 페이지덱에서는 민서와 태오가 짝을 이뤄 라이브러리를 맡습니다. 한쪽만 만들면 결과가 기웁니다. 디자이너 혼자면 구현하기 까다로운 형태가 들어가고, 개발자 혼자면 코드로는 깔끔한데 화면에서 아무도 찾지 않는 부품이 쌓입니다. 마흔다섯 명 규모에서는 전담 팀 대신 두 사람이 각자 업무의 일부를 떼어 씁니다.

읽는 쪽은 셋입니다.

1. 화면을 만드는 디자이너. 새 화면을 그리기 전에 목록부터 봅니다. 쓸 수 있는 부품이 정해져 있으면 그리는 일이 고르는 일로 바뀝니다.
2. 화면을 구현하는 개발자. 시안에 적힌 부품 이름으로 코드 쪽 부품을 찾습니다. 이름이 맞으면 화면 한 장이 조립으로 끝나고, 없는 부품이 섞여 있으면 그 자리만 새로 만듭니다.
3. 일정을 잡는 사람. 지현은 새 시안을 받으면 라이브러리에 없는 부품부터 셉니다. 둘이면 개발 일정에 며칠이 붙는다는 뜻이라, 목록이 일정 대화의 재료가 됩니다.

넣고 빼는 판단은 두 사람이 임의로 하지 않습니다. 새 부품 요청이 오면 누가 정하고 기존 부품을 고칠 때 누구에게 알리는지를 미리 정해 두는데, 그 운영 규칙을 디자인 시스템 거버넌스라고 부릅니다. 이 규칙이 없으면 반년 만에 버튼이 열두 종류가 되고, 목록이 길어지면 사람들은 뒤지는 대신 다시 옆 화면에서 복사합니다.

"그거 라이브러리에 있어요. 새로 그리지 마세요."

이미 만들어 둔 부품이 있으니 같은 것을 또 만들지 말라는 말입니다.

"라이브러리 3.3 올렸습니다. 입력창 오류 문구 자리가 아래로 내려갔어요."

원본이 바뀌었으니 각자 파일과 코드에서 갱신을 받으라는 안내입니다.

"이 화면 부품 중에 라이브러리에 없는 게 둘이라 일정을 더 잡아야 해요."

새로 만들 부품이 있으니 구현 기간이 늘어난다는 뜻입니다.

요금제 개편 일정을 잡던 자리에서 이 셋이 한 번에 나왔습니다. 지현이 언제 나갈 수 있는지 묻자 민서가 시안을 훑으며 표 머리글의 정렬 토글이 라이브러리에 없다고 짚었습니다. 태오가 새 부품이면 사흘, 기존 버튼을 변형해 쓰면 하루라고 답했습니다. 셋은 이번엔 기존 것으로 가고 정렬 토글은 다음 분기에 정식 부품으로 넣기로 정했습니다.

이 대화가 가능한 건 목록이 한곳에 있기 때문입니다. 부품이 파일 일곱 개에 흩어져 있으면 없는 부품을 세는 데만 반나절이 듭니다.

라이브러리를 만들어 두면 부품이 저절로 쓰인다고 생각하기 쉽습니다. 좋은 부품을 모아 뒀으니 당연해 보입니다. 실제로 갈리는 건 품질이 아니라 찾을 수 있느냐입니다. 이름이 내부 약어로 붙어 있거나 분류가 만든 사람 기준이면, 쓰려던 사람은 30초 뒤지다 포기하고 옆 화면에서 복사합니다. 복사가 한 번 시작되면 라이브러리 밖에 두 번째 벌이 생기고, 처음 해결하려던 문제가 그대로 돌아옵니다.

한 번 만들면 끝나는 일이라는 오해도 흔합니다. 부품 목록은 완성되는 물건처럼 보이니 그렇게 읽힙니다. 제품이 자라면 전에 없던 화면이 생기고, 새 화면은 대개 목록에 없는 부품을 하나씩 요구합니다. 갱신이 멈춘 라이브러리는 반년이면 실제 화면과 어긋나고, 어긋난 뒤에는 사람들이 라이브러리 대신 최근 화면을 기준으로 삼습니다. 만드는 품보다 계속 맞춰 두는 품이 큰 쪽이라, 만들기로 정할 때 유지할 사람까지 같이 정합니다.