아토믹 디자인(Atomic Design) 적용해볼까?

이 글은 아토믹 디자인(Atomic Design)이 무엇인가에 대한 글은 아닙니다. 아토믹 디자인 컨셉을 활용해 본 후기입니다.

아토믹 디자인은 아래 블로그에서 자세히 확인하실 수 있습니다.

Brad Frost의 아토믹 디자인 컨셉

 

아토믹 디자인이라는 용어를 접한 건 작년 2019년 입니다. 아토믹 디자인은 쉽게 말해서 화면을 구성할 수 있는 아주 작은 단위의 요소부터 디자인 시스템을 만들어가는 방법론이라고 볼 수 있습니다.

놀랍게도 2013년도부터 이 용어가 쓰여졌는데요. 2016년에는 책도 쓰였으니 꽤나 오래된 개념이라고 볼 수 있겠네요. 제가 이 용어를 접하게 된 계기는 재미있게도 디자인이 아닌 개발 효율화 측면이었습니다. 비슷한 모양의 비슷한 기능을 하는 스타일코드와 스크립트들이 중복하여 존재하는 프로젝트가 있었습니다. 이를 개선할 방법은 중복 코드의 제거를 통한 효율화인데 프로젝트의 오너는 비개발자여서 이를 더 멋지게 설명할 그럴듯한 단어가 필요하여 아토믹 디자인을 발견하게 되었습니다. 최신 웹 개발 프레임워크(Angular, React, Vue 등)들이 컴포넌트 단위의 개발을 지원하기에 아토믹 디자인과 디자인시스템의 도입은 개발 측면에서도 상당한 이득을 가져다 줄 수 있었습니다.

여기까지가 머리 속에서 그린 청사진이지요. 안타깝게도 현실은 만만치가 않습니다. 머리 속에서 그렸던대로 흘러가지 않았습니다. 제가 마주한 어려움들 몇 가지를 공유하며 아토믹 디자인을 적용하기 위한 전제에 대해 적어봅니다.

1. 아토믹 디자인은 모든 팀원이 이해하고 시작해야 합니다.
어떤 방법론이든 참여자들의 이해를 기반하여 성과가 나온다는 것은 명확합니다. 아토믹 디자인은 특히나 기획/디자인/개발 역할자 모두가 아토믹 디자인이 어떤 식으로 흘러가는지 이해할 필요가 있습니다. 일반적인 작업 방식과 순서부터가 다릅니다. 전체적인 그림을 그리고 부분적으로 채워가는 Top-Down 방식이 아닌 가장 작은 요소부터 만들어가는 Bottom-Up 방식으로 만들어집니다. 요즘은 애자일이라 부르고 짧은 일정에 디자인과 개발이 병렬적으로 수행되는 경우가 많은데 이런 상황에서는 기획/디자인이 Top-Down 방식으로 가는 이상 개발에서 아토믹 디자인을 적용하기 상당히 어렵습니다. 논의를 통해 공통요소를 도출하고 적어도 스타일 가이드는 만들어가야 그나마 흉내는 낼 수 있죠. 다만 상당히 고생할 수 밖에 없습니다.

2. 이미 정의된 아토믹 요소를 공유할 체계가 필요합니다.
프로젝트는 여러 사람이 함께합니다. 아토믹한 요소들에 대해 모두가 숙지하고 있다면 좋겠지만 큰 프로젝트의 경우 스타일 가이드를 완성해가는 사람들과 실제 화면을 디자인해가는 사람들이 다릅니다. 따라서 디자인의 근간이 되는 요소들이 실시간으로 공유될 체계가 잡혀있어야합니다. Zeplin이든 Sketch Library든 또는 코드가 포함된 Style Guide든 (PatternLab, Storybook, Fractal 등) 눈으로 쉽게 확인할 수 있는 방법과 무엇이 언제 왜 업데이트가 되는 지에 대한 내용이 문서이든 협업 도구든(Slack, Jira, Confluence, Wiki 등) 잘 기록되고 관리되어야합니다. 아무 체계 없이 가다가는 혼란스러울 뿐입니다.

3. 적당한 경계를 잘판단해야 합니다.
가장 어려운 단어인 '적당한'이 등장 합니다. 어디까지가 표준이고 공통이며 어디부터가 변용인지 명확한 경계가 없습니다. 팀원들이 잘 정해나가야하죠. 표준이 너무 강하면 디자인의 자유도가 떨어지고, 변용이 너무 강하면 표준이 의미가 없어집니다. 브랜딩인지 마케팅인지 성능인지 사용성인지 방향성을 잘잡고 가야합니다.

주저리 주저리 적어봤지만 너무 추상적이 되어버렸네요. 컴포넌트 단위의 개발, 스타일 가이드, 디자인 시스템이 효율적인 방법론을 제공하는 것은 분명합니다만, 쓸 줄 모르는 도구는 때론 안쓰는 것만 못할 때가 있다라는 더 추상적인 말로 마무리 짓겠습니다.