패턴 라이브러리

부품을 모아 두는 일은 일찍 자리를 잡았습니다. 버튼과 입력창을 한 번 만들어 컴포넌트 라이브러리에 넣어 두면 화면마다 다시 그리지 않아도 됩니다. 그런데 부품이 다 갖춰진 팀에서도 화면끼리 어긋나는 일이 계속 생겼습니다.

어긋나는 자리는 부품이 아니라 상황이었습니다. 문서를 지울 때 한 화면은 모달을 띄워 되묻고 다른 화면은 말없이 지운 뒤 토스트로 알렸습니다. 모달은 뒤 화면을 막고 위에 띄우는 창이고 토스트는 잠깐 떴다 사라지는 알림입니다. 둘 다 정식 부품이었으니 규칙을 어긴 사람은 없었습니다. 어느 쪽이 기준인지가 적혀 있지 않았을 뿐입니다.

민서가 새 목록 화면 시안을 올렸을 때 이 문제가 드러났습니다. 리뷰에서 "지난 분기 그 화면은 다르게 했는데 왜 이번엔 이렇게 하나요" 라는 질문이 나왔고, 아무도 어느 쪽이 맞는지 답하지 못했습니다. 결정은 있었지만 기록이 없었던 겁니다.

패턴 라이브러리는 그 기록을 두는 자리입니다. 부품이 "이 버튼은 이렇게 생겼다" 를 답한다면, 이쪽은 "지울 때는 되묻는다" 를 답합니다. 부품이 명사라면 패턴은 문장에 가깝습니다.

항목 하나가 상황 하나를 맡습니다. 한 항목에 들어가는 것은 대개 여섯 가지입니다.

1. 상황 이름 — 부품 이름이 아니라 상황으로 적습니다. "확인 모달" 이 아니라 "되돌릴 수 없는 삭제를 확인받기" 입니다. 이름이 상황으로 적혀 있으면 새 화면을 만드는 사람이 자기 상황으로 검색하게 됩니다.
2. 쓰는 조건과 안 쓰는 조건 — 어디까지 적용하는지 경계를 적습니다. 되돌릴 수 있는 삭제에는 되묻지 않고 실행 취소를 준다고 적어 두면 되묻는 창이 온 제품에 퍼지지 않습니다.
3. 해법 — 어떤 부품을 어떤 순서로 쓰는지 적습니다. 부품 이름에서 멈추지 않고 제목에 무엇을 담고 버튼을 어느 쪽에 두는지까지 내려갑니다.
4. 화면 예시 — 제대로 쓴 예와 어긋난 예를 나란히 놓습니다. 어긋난 예가 없으면 읽는 사람이 경계를 가늠하지 못합니다.
5. 문안 — 제목과 본문과 버튼 라벨을 확정해 둡니다. 마이크로카피까지 정하지 않으면 같은 패턴을 쓴 화면 다섯 개의 버튼 라벨이 다섯 가지가 됩니다.
6. 결정 근거와 예외 — 왜 이렇게 정했는지와 허용된 예외를 적습니다. 근거가 없으면 반년 뒤 같은 논의가 처음부터 돌아갑니다.

담는 상황은 제품마다 다르지만 겹치는 자리가 있습니다. 되돌릴 수 없는 작업의 확인, 보여 줄 내용이 없을 때의 빈 상태, 저장이 실패했을 때의 오류 메시지, 입력값이 규칙에 안 맞을 때의 알림, 오래 걸리는 작업의 진행 표시입니다. 스무 개 안쪽에서 시작해 실제로 부딪힌 상황을 하나씩 더해 가는 편이 무난합니다.

쓰는 사람은 디자이너지만 혼자 쓰지는 않습니다. 화면에서 실제로 무엇이 가능한지는 개발자가 알고, 문안은 UX 라이팅을 맡은 사람이 봅니다. UX 라이팅은 제품 안의 문구로 사용자를 안내하는 설계입니다.

적는 시점이 이 문서의 성질을 정합니다. 패턴은 앞으로 이렇게 하자는 계획이 아니라 이미 내린 결정의 기록입니다. 화면 두세 개에서 같은 상황을 풀어 보고 한 방식이 낫다고 판단된 뒤에 적습니다. 써 보기 전에 적은 항목은 첫 화면에서 어긋나고, 그런 항목이 몇 개 쌓이면 팀이 문서를 안 믿습니다.

읽는 사람은 셋입니다.

1. 새 화면을 만드는 디자이너 — 시안을 그리기 전에 그 상황이 이미 정해져 있는지 봅니다. 있으면 정할 일이 아니라 고르는 일이 됩니다.
2. 개발자 — 시안에 없는 경우를 여기서 확인합니다. 시안에는 잘 풀린 경우만 그려져 있고 실패했을 때는 대개 빠져 있습니다.
3. 새로 합류한 사람 — 이 팀이 왜 이렇게 하는지를 사람에게 묻지 않고 압니다.

갱신 책임을 정해 두지 않으면 이 문서가 가장 먼저 낡습니다. 화면이 바뀌었는데 항목이 그대로면 읽는 사람은 어느 쪽이 지금인지 모르고, 그때부터 안 읽는 쪽이 안전해집니다. 항목마다 고친 날과 담당을 적어 두는 팀이 많습니다.

"이 상황 패턴 라이브러리에 있어요. 삭제 확인은 되돌릴 수 없을 때만 되묻기로 정해 뒀습니다."

이미 내려진 결정이니 이 자리에서 다시 정하지 말자는 말입니다.

"패턴은 없고 부품만 있어서 화면마다 다르게 풀고 있어요."

부품은 갖췄는데 상황별 해법이 기록되지 않았다는 뜻입니다.

"이번 건은 패턴에서 벗어나는데, 예외로 적어 둘까요 아니면 패턴을 고칠까요?"

한 번의 예외인지 기준 자체가 바뀐 것인지를 가르자는 제안입니다.

페이지덱은 화면이 예순 개를 넘긴 뒤에 이 문서를 만들기 시작했습니다. 민서가 먼저 한 일은 새 항목을 쓰는 게 아니라 이미 있는 화면을 훑어 같은 상황이 몇 가지 방식으로 풀려 있는지 세는 것이었습니다. 삭제 확인이 네 가지, 빈 상태가 일곱 가지로 나왔습니다.

그중 어느 쪽을 기준으로 삼을지는 태오와 같이 정했습니다. 화면 수가 가장 많은 방식이 아니라 고치는 비용이 가장 적은 방식을 골랐습니다. 항목 열두 개로 시작해, 그 뒤로는 새 화면에서 결정이 필요해질 때마다 하나씩 붙였습니다.

패턴 라이브러리를 컴포넌트 라이브러리의 문서판으로 읽는 경우가 가장 많습니다. 둘 다 디자인 시스템 안에 있고 이름이 비슷하니 그렇게 보입니다. 하지만 담는 단위가 다릅니다. 부품 쪽은 버튼 하나의 크기와 상태를 다루고 패턴 쪽은 여러 부품이 엮인 흐름을 다룹니다. 같은 것으로 보고 부품 문서 안에 패턴을 적어 넣으면, 버튼 문서를 읽는 사람은 삭제 확인 규칙을 영영 못 찾고 그 규칙은 다시 화면마다 갈라집니다.

많이 적을수록 좋은 문서라고 보는 것도 흔합니다. 항목이 백 개면 든든해 보이지만, 그중 실제 화면에서 검증된 것이 스무 개뿐이면 나머지 여든 개가 앞의 스무 개까지 의심스럽게 만듭니다. 읽는 사람은 어느 항목이 진짜 쓰이는지 구분할 수 없어 결국 전부 안 읽습니다.