brunch

You can make anything
by writing

C.S.Lewis

by designsystemguy Feb 23. 2023

프로덕트 디자인 관점에서 아토믹 디자인에 대한 고찰

이 글을 보시는 분들은 아토믹 디자인에 대해서는 들어보셨을 거에요.

웹디자이너이자 개발자 Brad Frost가 2016년에 ‘Atomic Design’이라는 도서를 발간하면서 정립된 방법론이죠 (유튜브 보면 그 이전부터 전파해오긴 했습니다). 오늘은 아토믹디자인 방법론에 대해 프로덕트디자인 중심에서 이야기 해보려해요.

아토믹 디자인

이거 많이 보셨죠? 아토믹디자인 방법론은 UI로써 가장 작은 원자(atom)단위부터 시작해서 분자(molecules), 유기체(organism)로 점점 확장하며 디자인해나가는 방식이에요.

이 방법의 근간은 재사용을 통한 효율성과 일관성에 있어요. 반복되는 UI 패턴 속에서 만들어진 공통의 약속은 디자이너와 개발자로 하여금 더 높은 생산성과 품질을 유지하는데 큰 기여를 합니다. 아토믹디자인은 이러한 생산성의 관점에서 '컴포넌트를 잘 활용하는 방법'에 대해 이야기하고 있고요.

이 방법론을 통해 실무에서 적용도 쉽게 시작할 수 있어요. 프로덕트 전역에 걸쳐 사용되는 아토믹한 단위의 컴포넌트를 생각했을 때, 버튼부터 시작해서 텍스트인풋, 슬라이더 등 하나하나 고민 없이 만들어 나가기 쉽거든요. 하지만, 고민거리는 이제부터 생겨나기 시작합니다.

고민 1. ‘분자단위 컴포넌트부터는 어떻게 관리되어야 하는가?’

컴포넌트 라이브러리를 하나로 운용하면서 그 안에 원자단위 컴포넌트를 모아놓은 상태를 가정해봅시다. 각 프로덕트 디자이너들은 디자인하며 비슷한 패턴의 UI를 생성해나갈 것이고, 반복되어 발생하는 UI를 컴포넌트화 시키고 싶어할 것입니다. 디자이너는 로컬 컴포넌트로 만들어쓰거나, 컴포넌트 라이브러리를 통해 배포하거나 두가지를 생각해볼 수 있어요.

프로덕트 디자이너가 분자 단위부터 로컬 컴포넌트로 만들어 사용할 경우, 디자이너간 오차가 생길 수 있습니다. 일관성이 깨질 여지가 있다는 것이죠. 리스트 형태의 UI를 디자인하는데 이 파일과 저 파일에서 비슷한 패턴을 갖고있지만 자세히보면 다른 컴포넌트를 각자 로컬로 가지고 있다면, 제작자(프로덕트 디자이너)에게는 심각한 관리의 문제로 이어집니다. 더불어 그걸 바라보는 고객에게는 일관되지 않은 경험을 제공하는 셈이 되버리죠.

후자로 말씀드린 처음부터 컴포넌트 라이브러리에서 만들어서 배포하는 경우도 여전히 문제는 발생합니다. 컴포넌트 라이브러리의 관리 주체는 반드시 디자인시스템에 대해 가장 많이 알고있는 사람이 되어야합니다. 그렇지않고 깊은 고민없이 누구나 무분별하게 컴포넌트 라이브러리에 접근하게된다면, 자기 페이지의 디자인과 완벽하게 호환이 안된다고 비슷한 컴포넌트를 추가하거나, 협업용이 아닌 자기만 알아볼 수 있는 컴포넌트를 만들어 놓는 등 생각만해도 끔찍한 상황이 발생할 것이기 때문입니다.

위 두가지 상황에 직면하게될까봐 겁이나 분자단위 이상의 컴포넌트 생성을 아예 안하는 것도 문제입니다. 컴포넌트는 반복되는 패턴입니다. 하나의 프로덕트에서 원자 단위 이상의 다양한 컴포넌트가 생성되고 사라지는 일은 필연적일 수밖에 없는데 같은 패턴의 UI를 컴포넌트화시키지 않고, (Figma상의) Frame으로만 만들어두는 것은 궁극적으로는 개인뿐만아니라 같이 일하는 디자이너, 개발자와의 협업에 좋지 않을 수 있습니다.

고민 2. ‘사람마다 컴포넌트를 구분짓는 기준이 다르다.‘

디자인팀만의 이야기를 하는 것이 아닌 디자인팀, 개발팀 모두에 대한 문제입니다. 직접 경험하기도 했고, 인터넷의 아토믹디자인에 대한 몇몇 글들을 살펴보면 많은 분들이 컴포넌트를 나누는 기준의 모호성에 관해 이야기합니다. A라는 컴포넌트는 과연 분자단위일까? 유기체단위일까? 디자이너들은 이것이 중요하지 않다고 생각할 수도 있겠지만, 파일구조설계적 관점에서 이는 관리의 주체 및 방법, 확장성의 영역으로 넓혀지는 부분이기 때문에 결정해야하는 중요한 사안입니다.

개인적으로 원자와 분자 단위 컴포넌트를 UI적 SRP(Single Responsibility Principle)를 지키는 Generic한 컴포넌트로 관리하며, 유기체부터는 페이지의 컨텍스트를 따르는 것이 가장 건강한 구조를 이루는 방법으로 생각합니다. 하지만, 개발자를 너머 디자이너에게까지 깊은 공감과 이해를 이끌어내려면 수많은 온보딩과 스터디 등의 노력이 필요합니다.

정리

위 두 고민지점을 바탕으로 프로덕트 디자이너관점에서 아토믹 디자인에 대해 이야기해보았는데요. ‘아토믹 디자인은 이래서 문제야~ 저래서 문제야~’로 들리실지 모르겠지만, 이야기는 끝이 아니라 사실 이제 시작이에요 ㅎㅎ..아토믹 디자인 사고를 토대로 발전한 제 경험을 들려드리고 싶었거든요. 그 글은 다음 포스팅에서 이어서 하며, 이 글은 아래 두문장으로 정리하며 마무리 짓도록 하겠습니다.

아토믹디자인이라는 사고방식(또는 멘탈모델) 자체는 컴포넌트를 작은단위부터 만들고 큰단위 컴포넌트 안에 중첩되어 확장해나갈 수 있다는 점에서 Component Driven Development적으로 훌륭한 기틀을 마련했다. 하지만 실무 적용에 있어서는 개인/팀적으로 소화하는데 차이가 있을 여지가 보인다. '아토믹디자인'이라는 사고방식은 유지하되, 이것을 바탕으로 각 팀에서 어떻게 디자이너와 개발자 모두가 공감하고 적용할 수 있는 디자인시스템을 Organizing해나갈지에 대해서는 함께 고민해보는 것이 좋을 것이다.