이 글의 내용
“Frame 184”나 “Button Copy”는 화면을 정리해 보여도 의도를 숨깁니다. Pixso UI 디자인 메이커에서 레이어, 컴포넌트, variant와 핸드오프를 같은 용어로 검토하세요.

1. 이름이 해야 할 일
이름은 자산을 찾고 역할을 예측하며 다른 화면에서도 의미를 유지하고 코드와 연결되어야 합니다. 카테고리와 목적은 이름으로, 크기와 상태 차이는 variant로 표현합니다.
세부사항을 긴 문자열에 넣지 말고 설명, 문서와 예시로 나눕니다. 검색, 변경 논의와 핸드오드라는 세 순간을 실제 화면에서 테스트하세요.
2. 작은 네이밍 문법
Category / Component / Subcomponent처럼 카테고리를 앞에 두면 Navigation / Tabs / Item과 Input / Select / Option을 찾기 쉽습니다. 대소문자와 구분자를 한 번 정하세요.
Blue Button 같은 외관 이름 대신 Primary Button처럼 역할을 사용합니다. Pixso의 슬래시 검색 규칙과 충돌하는 구분자는 피합니다.
3. 의미로 컴포넌트와 variant 이름 짓기
컴포넌트는 처음 쓰인 화면이 아니라 시스템의 역할로 이름을 정합니다. variant는 size, emphasis, state, icon position처럼 예측 가능한 질문에 답해야 합니다.
type=one, version=new 같은 이력 이름은 피하고 components, styles, variables와 assets에 같은 용어를 적용합니다.
4. 레이어 이름으로 구조와 동작 설명하기
구조적이거나 인터랙티브한 레이어는 목적을 보여 줘야 합니다. label, supporting text, dismiss action 같은 의미 이름은 폰트와 색이 바뀌어도 정확한 대화를 만듭니다.
- 외관보다 목적을 먼저 쓴다.
- 같은 역할에는 같은 용어를 쓴다.
- slot과 property 이름을 문서와 맞춘다.
- 내부 작업 이력을 공개 이름에 넣지 않는다.
- deprecated 패턴은 변경 기록과 함께 옮긴다.
5. 토큰·자산·문서의 용어 맞추기
gray-700과 blue-500은 값이지 사용 목적이 아닙니다. 시맨틱 토큰은 역할을 보여 주고 search, download, warning 같은 아이콘 이름은 의미와 문맥을 말해야 합니다.
언제 쓰고 피해야 하는지, property 의미, 입력 콘텐츠와 필수 상태를 컴포넌트 가까이에 기록합니다.
6. 기존 라이브러리를 통제된 방식으로 마이그레이션
성숙한 라이브러리를 한 번에 바꾸지 않습니다. 사용량, 소유자, 중복과 의존성을 조사하고 한 family에서 새 이름과 이전 이름을 매핑합니다.
Pixso는 Figma, Sketch, Axure 파일과 라이브러리를 가져올 수 있습니다. variant, 글꼴, prototype trigger와 Auto Layout을 확인하고 Smart Rename도 제한된 범위에서 리뷰합니다.
7. Pixso에서 공동 리뷰
네이밍 규칙은 용어 회의만으로 정하지 않습니다. 디자이너가 찾고 variant를 만들고 화면을 구성한 뒤 개발자가 대응 이름을 읽는 과업으로 검증하고 결론을 문서로 옮깁니다.
8. 핸드오프에 의미 전달하기
production component에 design name, code counterpart, properties, tokens, states, content constraints와 responsive rules를 적습니다. D2C 코드는 검토를 돕지만 운영 코드를 대신하지 않습니다.
최종 감사
- 이름이 화면이나 색이 아닌 안정적인 역할을 설명한다.
- variant가 이해 가능한 선택지를 표현한다.
- 레이어가 구조와 인터랙션 목적을 보여 준다.
- 토큰이 의미를 드러내면서 원시 값을 보존한다.
- 검색·문서·코드가 같은 용어집을 쓴다.
- 마이그레이션에 담당자와 테스트, deprecation 안내가 있다.
결론
좋은 네이밍 규칙은 검색, 확장, 리뷰, 마이그레이션과 구현을 쉽게 합니다. 문법을 작게 유지하고 목적을 이름에 담으며 variant로 차이를 관리하고 Pixso의 레이어부터 핸드오프까지 용어를 맞추세요.