그거 'Atom' 아니에요: 디자이너와 개발자가 드디어 '싱크'가 맞기 시작했습니다

최근 디자이너와 디자인 시스템의 '컴포넌트 단위(Unit)'에 대한 정책을 정의하는 미팅을 가졌습니다. 제가 생각하는 가장 작은 단위, 즉 'Atom(원자)'의 기준은 명확했습니다.

1. 가장 기본적인 기능 단위
2. 단 하나의 기능(클릭, 입력)만 가질 것
3. 서버와 직접 통신하지 않을 것 (데이터나 맥락을 갖지 않을 것)

말 그대로 "Atomic Design"의 교과서적인 정의였죠. 하지만 현실은... 😭

디자이너로부터 "컴포넌트 단위입니다"라며 전달받은 피그마(Figma) 파일을 열어보면, 제 정의와는 사뭇 다른 결과물들이 있었습니다. '특정 비즈니스 로직'이 잔뜩 포함된 카드나, 12가지가 넘는 조합으로 이루어진 '모달 헤더' 같은 것들이었죠.

이건 Atom일까요, Molecule(분자)일까요? 이대로 가면 재사용은커녕 컴포넌트 지옥이 열릴 게 뻔했습니다.

그래서 이 혼돈을 잠재우고 '레고 블록'처럼 착착 맞는 시스템을 만들기 위해, 우리만의 명확한 '설계도'가 필요했습니다. 그 설계도의 제1원칙을 세웠죠.

💡 핵심 원칙: "Dumb Component (멍청한 컴포넌트)"

가장 먼저 합의한, 그리고 가장 중요한 원칙입니다.

디자인 시스템의 가장 작은 단위(Atom)는 **'Dumb Component(멍청한 컴포넌트)'**로 만드는 것을 원칙으로 합니다. 말 그대로 '멍청하게', 스스로 아무것도 결정하지 못하고 외부에서 시키는 대로 화면만 그리는 녀석들입니다.

이해하기 쉽게 비유를 들자면 이렇습니다.

• Dumb Component (배우) 🎭: 감독이 준 대본(Props)대로 연기(렌더링)만 합니다. 스스로 "이 장면은 슬프니 울어야지"라고 결정하지 않습니다.
• Smart Component (감독) 🎬: 모든 상황(State, API 통신)을 파악하고, 어떤 배우(Dumb)가 어떤 연기(Props)를 할지 지시합니다.

Atom은 '배우'입니다. 이 원칙을 기준으로 우리가 마주했던 애매한 사례들을 다시 정의해 봤습니다.

🧐 예시 1: Atom인가, Molecule(조합)인가?

가장 흔한 문제입니다. 디자이너는 '클릭되는 요소'를 Atom이라고 생각했지만, 이미 여러 Atom이 '조합'되어 특정 '역할'을 가진 경우가 많았습니다.