디자인 파일에는 “메인 카드”, 코드에는 featured-box, 회의에서는 “그 큰 박스”. 같은 것을 가리키는 이름이 셋이면 대화마다 번역이 한 번씩 붙습니다. 번역은 처음에는 비용이 작아 보이지만, 번역표가 사람 머릿속에만 있다는 것이 진짜 문제입니다. 새로 합류한 사람에게는 전달되지 않고, 6개월 뒤의 본인에게도 전달되지 않습니다.
이름이 갈리면 무엇이 실제로 어긋나는가
이름이 다르면 세 가지가 순서대로 무너집니다. 첫째, 수정 요청이 길어집니다. “카드 여백 8 줄여 주세요” 로 끝날 말이 “목록 화면에서 세 번째 줄에 있는 그 큰 박스 있잖아요” 가 됩니다.
둘째, 같은 컴포넌트인지 아닌지가 흐려집니다. 디자이너는 하나로 생각한 것이 코드에 둘로 존재하면, 한쪽만 고쳐지고 다른 쪽은 남습니다. 화면에서는 “왜 여기만 안 바뀌었지” 로 나타나고, 원인은 이름이 갈린 지점에 있습니다.
셋째, 문서가 낡습니다. 이름이 다른 두 세계를 잇는 문서는 유지 대상이 하나 더 늘어난 것이고, 유지되지 않는 순간 틀린 지도가 됩니다.
이름 짓는 규칙 세 가지
1. 생김새가 아니라 역할로 짓습니다. “파란 박스” 는 색을 바꾸는 순간 거짓말이 됩니다. “알림” 이라고 부르면 색이 바뀌어도 이름이 살아 있습니다. 같은 이유로 “왼쪽 사이드바” 보다 “필터 패널” 이 오래갑니다.
2. 블록 · 요소 · 변형의 세 층으로 나눕니다. 카드라는 블록이 있고, 그 안에 제목 · 요약 같은 요소가 있고, 강조된 카드 같은 변형이 있습니다. 이 구조는 디자인 파일의 레이어 구조와도, 코드의 클래스 구조와도 그대로 대응합니다.
3. 변형은 세 개 이상일 때만 만듭니다. 한 화면에만 나오는 예외를 변형으로 승격시키면 목록만 길어집니다. 두 번까지는 예외로 두고, 세 번째로 같은 모양이 나타났을 때 이름을 붙입니다 — 그때가 그것이 진짜 패턴이 된 시점입니다.
이름표를 어디에 두는가
이름은 한 곳에만 있어야 합니다. 디자인 파일의 컴포넌트 이름이 곧 목록이 되는 방식이 가장 단순합니다. 별도의 문서를 만들면 두 곳이 어긋날 자리가 생기고, 어긋난 사실은 대체로 한참 뒤에 발견됩니다.
워드프레스 쪽에서는 이 이름이 클래스 접두사와 템플릿 파일 이름으로 그대로 내려앉습니다. 카드가 card 라면 스타일 파일도 card, 클래스도 card 계열로 갑니다. 이름 하나가 디자인 파일 · 스타일 파일 · 대화에서 같은 소리를 내는 상태가 목표입니다.
컴포넌트 단위로 사고하는 구조는 개발 워크플로우 아카이브에서 더 다루고, 이름 체계를 포함한 구조 정비를 함께 맡기고 싶다면 최적화 지원 사업의 범위에 들어갑니다.
다음 회차
이름이 맞았다면 다음은 그 컴포넌트가 실제로 겪을 상황입니다. 다음 회차는 상태와 예외 — 빈 목록, 오류, 아주 긴 제목, 없는 이미지를 그리는 이야기입니다.