팀에 Atomic Design을 도입한 6개월 회고

디자인 시스템을 도입해야겠다고 생각한 이유는 거창하지 않았다.

버튼 하나를 수정하면 여러 페이지가 깨지고,
비슷한 컴포넌트가 이름만 다르게 여러 개 존재하고,
새로운 화면을 만들 때마다 어디까지 재사용할 수 있는지 고민해야 했다.

처음에는 단순히 컴포넌트를 정리하면 해결될 문제라고 생각했다.

하지만 시간이 지날수록 문제는 코드보다 구조에 있다는 것을 느끼게 됐다.

그래서 Atomic Design을 도입해 보기로 했다.

생각보다 어려웠던 것은 기술이 아니었다

Atomic Design 자체는 어렵지 않았다.

Atom, Molecule, Organism으로 컴포넌트를 분리하는 개념도 이해하기 쉬웠다.

오히려 어려웠던 것은 팀이 같은 기준으로 생각하도록 만드는 일이었다.

어떤 컴포넌트는 Atom인가?

언제 새로운 컴포넌트를 만들어야 하는가?

어디까지 재사용해야 하는가?

기술적인 문제가 아니라 기준을 맞추는 과정이 더 오래 걸렸다.

도입 초기에는 생산성이 좋아질 것이라고 기대했다.

실제로는 반대였다.

컴포넌트를 만들 때마다

이건 Atom일까?

Molecule일까?

를 고민하게 됐다.

기존 코드를 분리하는 작업도 생각보다 오래 걸렸다.

구조는 좋아졌지만 체감되는 효과는 크지 않았다.

당시에는 괜히 시작했나 싶기도 했다.

구조가 어느 정도 자리 잡자 변화가 생겼다.

새로운 화면을 만들 때 기존 컴포넌트를 조합하는 경우가 많아졌다.

디자인 변경도 훨씬 쉬워졌다.

공통 버튼을 수정하면 전체 서비스에 반영됐고,
스타일 규칙도 자연스럽게 통일되기 시작했다.

무엇보다 컴포넌트를 찾는 시간이 줄어들었다.

이전에는 비슷한 컴포넌트를 새로 만드는 경우가 많았지만 이제는 먼저 재사용 가능한 것을 찾게 됐다.

돌아보면 Atomic Design의 가장 큰 효과는 컴포넌트 구조가 아니었다.

팀이 같은 언어를 사용하게 된 점이었다.

"이 컴포넌트는 공통으로 가져갈까요?"

"이건 Organism 레벨에서 관리하는 게 좋을 것 같아요."

이런 대화가 가능해졌다.

구조가 생기니 의사결정 기준도 함께 생겼다.

결국 디자인 시스템은 컴포넌트 모음이 아니라 팀의 약속에 더 가까웠다.

6개월 동안 Atomic Design을 적용하면서 느낀 것은 디자인 시스템이 개발 속도를 즉시 높여주는 마법 같은 도구는 아니라는 점이다.

오히려 초반에는 비용이 든다.

기준을 만들고,
구조를 정리하고,
팀이 적응하는 시간이 필요하다.

하지만 일정 시간이 지나면 그 비용 이상의 효과를 얻을 수 있다.

특히 규모가 커질수록 컴포넌트보다 규칙의 가치가 더 커진다.

돌아보면 Atomic Design을 도입한 것은 컴포넌트를 정리하기 위해서가 아니라 팀이 같은 방향으로 개발하기 위한 선택이었던 것 같다.