글
네이밍 컨벤션 — 디자이너와 개발자가 같은 언어로 대화하는 법
"레이어1", "그룹 복사본 3", "버튼-최종2" — 이 파일, 혹시 당신 거 아닌가요? 😅 레이어 이름부터 컴포넌트·페이지 구조까지, 디자이너와 개발자가 같은 언어로 대화할 수 있는 네이밍 컨벤션을 나쁜 예시와 좋은 예시를 직접 대비하며 정리해 드릴게요! 솔직히 고백하자면 저도 한동안 레이어 패널이 "Rectangle 45", "그룹 복사본 2", "Frame 123" 같은 이름들로 가득한 채로 작업했어요. 혼자 쓸 땐 큰 문제 없었거든요. 🙈 근데 개발자에게 파일을 넘기는 순간부터 달라졌어요. "이 레이어가 버튼이에요, 배경이에요?" "이 컴포넌트 이름이랑 코드 이름이 다른데 맞는 거예요?" 질문이 쏟아지더라고요. 네이밍은 단순한 정리 습관이 아니에요. 디자이너·개발자·기획자가 같은 단어로 같은 것을 가리킬 수 있게 해주는 공통 언어 예요. 오늘은 레이어·컴포넌트·페이지 구조 각각의 네이밍 원칙을 나쁜 예시 vs 좋은 예시로 대비해서 보여드릴게요. BEM, Atomic Design 같은 방법론과의 연결까지요! 왜 네이밍이 이렇게 중요한가요? 🤔 나쁜 네이밍이 실무에서 만들어내는 문제는 크게 세 가지예요. 탐색 비용 증가: "이 컴포넌트 어디 있더라?" 하고 레이어 패널을 뒤지는 시간이 쌓이면 하루에 몇십 분이 날아가요. 코드-디자인 불일치: Figma에서 "버튼-블루"인데 코드에선 ButtonPrimary 예요. 신규 입사자가 무엇을 참조해야 할지 몰라요. 인수인계 실패: 작업자가 바뀌면 파일을 처음부터 해석해야 해요. "이게 뭐지?" 시간이 온보딩의 절반을 잡아먹어요. 💡 핵심 원칙 먼저! ...