왜 이름 짓기가 늘 어려울까?
우리가 사용하는 언어는 사고방식과 대화의 방향을 결정합니다. 그래서 색상, 아이콘, UI 컴포넌트, 기능에 대해 이야기할 때마다 혼란이 생기고, 디자인 토큰이나 HTML 클래스, 변수 이름을 짓는 일이 늘 고통스럽죠.
문제는 두 가지입니다. 이름이 너무 일반적이면 정확히 무엇을 의미하는지 알 수 없고, 너무 구체적이면 재사용과 유연성이 떨어집니다. 그렇다면 적절한 이름은 어떻게 선택해야 할까요? 이 글에서는 실무에서 바로 쓸 수 있는 네이밍 전략과 검증된 레퍼런스를 정리해 공유합니다.
근거자료: Smashing Magazine - A Practical Guide To Naming Things
실전 네이밍 전략: 영역별 접근법
1. HTML 클래스와 함수 이름
이름 짓기에 막혔을 때 유용한 리소스가 있습니다. Classnames는 행동, 유사성, 순서, 그룹화, 연관성 등 주제별로 묶인 단어 목록을 제공합니다. 자연, 예술, 건축, 패션 등 코드와 거리가 멀어 보이는 분야의 어휘도 포함되어 있어 발상의 전환을 도와줍니다.
2. 색상 이름
#FF5733 같은 코드 대신 의미 있는 이름이 필요할 때, David Aerne이 관리하는 저장소에는 30,355개의 고유 색상 이름이 수록되어 있습니다. 컬러 피커와 이름 검색 기능도 제공되어 실무에서 바로 참조할 수 있습니다.
3. 레이어와 그룹
좋은 이름의 조건은 명확합니다: 논리적 구조, 짧음, 의미 있음, 팀 전체가 아는 단어, 시각적 속성과 무관함. Javier Cuello가 정리한 모범 사례는 사이즈, 색상, 그룹, 레이어, 컴포넌트 이름을 지을 때 고려해야 할 세부 사항까지 다룹니다.
4. 디자인 토큰
Intuit(Mailchimp, QuickBooks, TurboTax 운영사)은 여러 제품에 걸쳐 작동하는 유연한 토큰 분류 체계를 구축했습니다. Nate Baldwin의 사례 연구는 기존 시스템의 문제점, 새 시스템의 기준, 구축 과정을 상세히 공유합니다. 다중 브랜드·다중 테마 환경에서 토큰 이름만 보고도 용도를 파악할 수 있게 만드는 것이 핵심입니다.
// 디자인 토큰 네이밍 예시 (계층 구조)
const tokens = {
// 원시 값 (Primitive)
colorBlue500: '#3B82F6',
// 의미론적 토큰 (Semantic)
colorActionPrimary: '{colorBlue500}',
colorTextOnAction: '#FFFFFF',
// 컴포넌트 토큰 (Component)
buttonBackgroundDefault: '{colorActionPrimary}',
buttonLabelDefault: '{colorTextOnAction}'
};
// 이름만 보고도 '버튼의 기본 배경색'임을 즉시 파악 가능
5. UI 컴포넌트 이름
비슷한 것을 다른 이름으로 부르는 관행을 정리한 Component Gallery는 50개 이상의 UI 컴포넌트(아코디언부터 visually hidden까지)에 대해 각 시스템이 사용하는 대체 명칭을 함께 보여줍니다. 팀 내 용어 통일에 매우 유용합니다.
6. 기능(Feature) 이름
기능 도입률이 낮은 이유는 대부분 발견 가능성(discoverability) 부족입니다. 좋은 기능 이름은 사용자의 니즈와 문제에서 출발하며, 기능의 가치나 결과(job-to-be-done)를 신호해야 합니다. 가장 중요한 것은 사용자가 실제로 쓰는 언어를 반영하는 것입니다. 사용자에게 기능을 자기 말로 설명해보라고 하고, 그 단어를 그대로 쓰세요.
주의사항과 실무 팁
흔한 함정
- 시각적 속성에 종속된 이름:
red-button은 테마 변경 시 거짓말이 됩니다.primary-action처럼 역할 기반으로 짓세요. - 팀별 방언(dialect): 디자이너는 '컴포넌트', 개발자는 '위젯', 기획자는 '모듈'이라고 부르면 같은 것을 두고 대화가 엇갈립니다. 네이밍 컨벤션 문서를 만들어 단일 용어집을 유지하세요.
- 네이밍 충돌 방치: 충돌을 발견하면 백로그에 등록해 반드시 해결하세요. 작은 디테일이 팀 협업의 마찰을 크게 줄입니다.
국내 개발 생태계에서의 적용 맥락
국내 SI·에이전시 환경에서는 프로젝트마다 클라이언트가 바뀌기 때문에 네이밍 컨벤션이 매번 초기화되는 경우가 많습니다. 이럴 때 **디자인 토큰 계층 구조(원시 → 의미론 → 컴포넌트)**를 템플릿화해두면 신규 프로젝트 온보딩 속도가 눈에 띄게 빨라집니다. 특히 다크 모드·멀티 브랜드 요구가 늘어난 요즘, 시맨틱 토큰 계층 없이 색상을 직접 참조하는 코드는 유지보수 지옥의 지름길이에요 😅
이 접근법의 한계
완벽한 네이밍 체계는 존재하지 않습니다. 팀 규모가 커지고 제품이 성숙할수록 기존 이름이 낡아버리는 기술 부채가 됩니다. 따라서 네이밍 컨벤션은 '한 번 정하고 끝'이 아니라, 분기별로 리뷰하고 마이그레이션 계획을 세우는 살아있는 문서로 관리해야 합니다.
결론: 좋은 이름은 팀과 사용자가 함께 쓰는 이름
정답은 하나입니다. 팀과 사용자가 잘 이해하고 실제로 사용하는 이름이 좋은 이름입니다. 같은 것을 두고 디자이너의 방언, 개발자의 방언, 기획자의 방언, 사용자의 방언으로 이야기하는 순간 시간과 감정이 낭비됩니다.
도입률이 낮다면 이름 때문일 수 있습니다. 네이밍 충돌은 백로그에 쌓아두고 하나씩 해결하세요. 사소해 보이는 이 디테일이 팀 협업의 질을 바꿉니다.
다음 단계 학습 방향
- 디자인 토큰 실습: Figma의 Variables 기능으로 시맨틱 토큰 계층을 직접 만들어보세요.
- 용어집 운영: 팀 위키에 UI 용어 사전을 만들고 PR 리뷰 시 참조하도록 프로세스화하세요.
- 자동화: Stylelint나 ESLint 커스텀 룰로 네이밍 컨벤션 위반을 CI에서 잡아내세요.