소프트웨어 디자인 관점에서 바라본 아토믹 디자인의 의미와 한계

디자인 시스템을 설계하는 디자이너 혹은 리액트, 뷰, 앵귤러와 같은 컴포넌트 중심 개발을 해본 적 있는 사람은 아토믹 디자인에 대해 들어본 적 있을 것이다. 디자인 시스템에 대한 아토믹 디자인의 간결하고 명료한 접근법은 처음 보는 사람들을 감탄하게 만든다. “어서 우리 회사에 적용시켜야 해”

Atomic design is methodology for creating design systems. There are five distinct levels in atomic design: Atoms, Molecules, Organisms, Templates, Pages Atomic Design - Brad Frost

개발, 디자인 관련 커뮤니티에서 아토믹 디자인의 적용에 대한 질문을 찾는 것은 그리 어렵지 않다. 그 만큼 이제는 널리 알려진 방법론인 것이다. 그러나 실제로 이를 프로젝트에 적용하다 보면 오히려 문제를 복잡하게 만들기 일쑤이다. 여러 회사들의 공개된 디자인 시스템에서 아토믹 디자인이 적용된 것을 찾기는 쉽지 않다. 영향력을 기준으로 회사의 범위를 좁히면 거의 없다고 보는 것이 맞을 것이다. 이 글은 아토믹 디자인이라는 방법론에 어떤 문제가 있으며 이 방법론이 우리에게 주는 의미가 무엇인지 알아보는 글이다.

아토믹 디자인의 핵심은 무엇일까? 그 이름에서 발견할 수 있다. Atomic한 컴포넌트가 존재한다는 믿음이다. 마치 원자처럼 더이상 쪼개질 수 없는 빌딩블록이 존재한다는 것이다. 원문에서는 버튼과 라벨, 인풋 엘리먼트를 그 예로 들고 있다. 그 뿐만 아니라 잘 정의된 애니메이션, 컬러, 타이포그래피도 아톰의 일종으로 바라볼 수 있다고 한다. 그러나 우리의 관심을 사로잡는 부분은 Atom, Molecule, Organism, Template, Page라는 멋진 이름을 가진 분류 방법이다. 여기에서부터 문제가 발생한다.

이는 웹에서 찾을 수 있는 아토믹 디자인의 적용에 대한 글들에서 자주 보이는 문제점이기도 하다. 앞서 말한 것 처럼 아토믹 디자인의 핵심은 무엇이 아톰인지를 결정하는 것이다. 그리고 그 논리를 뒷받침하는 규칙, 즉 공리가 있어야 한다. 그러나 많은 글들이 이에 대한 논의가 빈약하다. 대신 컴포넌트를 다섯 단계의 계층 구조로 나누는 원문의 아이디어를 반복해서 설명하는데 초점을 맞추고 있다. 미디엄에 포스팅 된 Atomic design methodology는 Brad Frost 의 원문을 잘 해석한 글이다. 이 글은 컬러, 아이콘, 폼 엘리먼트, 타이포그래피, 버튼을 아톰으로 부르고 있는데 이쯤 되면 HTML, CSS 스펙의 부분집합이라고 설명하는 것이 훨씬 명료할 것 같다.

원문을 읽다 보면 분자 레벨의 예시로 인풋과 버튼이 합쳐진 컴포넌트가 등장한다. atom이 합쳐져 molecule을 이룬다는 상당히 추상적인 설명 다음에 나오는 구체적인 사례로 상당히 적합해 보이지만 실은 그렇지 않다. 버튼을 예로 들자면 그 쓰임새에 따라 색, 타이포가 다양하고 어떤 버튼에는 아이콘이 붙고 비활성화, 포커스, 호버 등 다양한 상태를 표현한다. 그럼 앞서 말한 타이포와 아이콘, 색깔이 아톰에 속한다 했을 때 이 버튼은 아톰과 분자 어느쪽에 속해야 하는가? 추상적인 버튼에 여러 속성이 정의되어 구체적인 버튼으로 표현 되었을 때 아톰이 모여 만들어져 있으므로 분자라고 부르는게 맞을 것 같다. 라벨이나 인풋 또한 마찬가지라고 할 때, 검색 바는 분자가 합쳐진 오가니즘에 포함되는 것이 맞지 않을까라는 의문을 가질 수 있다. 그러나 원문에서는 이를 분자의 예로 들고 있다.

이런 애매모호 함을 피하기 위해 계층 구조에 좀더 많은 단계를 둘 수 있다. 예를 들자면 단순한 오가니즘은 컴파운드(복합체)라고 부른다던가 하는 식으로 말이다. 하지만 이런 방식으로 접근하기 시작하면 그 계층 구조가 한도 끝도 없이 나올 것이라는 걸 예상할 수 있다. 바로 이 지점에서 이론의 한계를 찾을 수 있다. UI를 구성하는 빌딩블럭의 복잡도는 스펙트럼을 형성하기 때문에 이산적으로 분류하기 쉽지 않다. 이를 제대로 나누려 노력해도 회색 지대는 끊임없이 나올 것이다.

소프트웨어를 설계하다 보면 단단한 계층구조가 문제를 일으킨다는 것을 쉽게 경험할 수 있다. 각 레벨이 단단히 묶여있는 경우 상위 레벨의 작은 변경 사항이 그 아래로 크게 증폭되기 때문이다. 예를 들어 버튼의 기본 패딩을 변경했을 때 그 버튼에 의존하는 수많은 컴포넌트 들이 동시에 변경되는데 이러한 사이드 이펙트는 의도 되었고 충분히 컨트롤 가능할 때만 의미가 있다. 그러나 복잡하게 얽힌(예를 들자면 다섯 단계로 이루어진) 계층 구조는 컨트롤하기 쉽지 않다. OOP에 대한 비판적인 시선을 아토믹 디자인에 적용하는 것은 크게 어렵지 않다. 물론 컴포넌트들 간의 관계만 놓고 보자면 상속이 아닌 조합의 관계로 묶여 있긴 하지만 이를 분류하는 행위는 “~는 ~이다”의 관계를 형성하기 때문이다. 또한 그 조합에 있어서 충분히 논리적인 규칙을 정의하기 힘들다는 점이 있다.

그러나 우린 아토믹 디자인에서 어떠한 가능성을 발견할 수 있다. 프로그래밍 패러다임의 발전과 유사한 양상이다. 직접적인 비유를 할 수는 없지만, 과거 프로그래밍은 제한적인 환경에 맞춰진 명령어의 연속에서 OS가 기본적으로 제공하는 API를 직접 활용했다. 이를 추상화하는 과정에서 몇몇 언어들은 각자의 생태계에 종속된 프레임 워크를 만들었고 이러한 프레임 워크 들을 관통하는 패러다임을 정의하기 시작했다. 디자인 시스템의 부트스트랩, 시맨틱UI 혹은 한층 더 깊은 통찰을 보여준 머터리얼 디자인은 일종의 모노리식한 프레임 워크라고 볼 수 있다. 근래에는 모든 회사들이 각자의 디자인시스템을 만들어가고 있으며 소규모 프로젝트에도 그 필요성이 등장하고 있는데 어찌보면 아토믹 디자인처럼 디자인시스템에 대한 방법론이 학술적인 영역을 벗어나 실무로 가깝게 다가오는 것은 자연스러운 현상일 것이다.

그렇다면 어떤 형태의 방법론이 디자인시스템 생태계를 더욱 풍부하게 만들어 줄 수 있을까? 우선 아토믹 디자인은 모든 디자인 시스템이 아톰으로부터 출발한다는 아이디어를 주었다. 컴포넌트가 가질 수 있는 속성의 부분집합을 정의할 수 있다는 의미인데, 많은 프로젝트에서 그 부분집합을 HTML과 CSS스펙으로 환원한다는 것은 매우 흥미롭다. 스케치나 Figma를 봐도 알 수 있는데, UI의 공통 언어가 거의 완성되었다는 의미로 해석할 수 있다. 그리고 특정 분류 체계에 묶인 단단한 계층 구조는 실패할 것이라는 걸 알려줬다. 그러나 계층 구조에 대한 필요성, 조합에 대한 원칙이 필요하다는 것 또한 알려주고 있다.

이러한 아이디어를 바탕으로 각자의 상상력을 발휘할 수 있는데 내 개인적인 상상으로 예를 들어 보겠다. 디자인 시스템에 대한 방법론이 그 의미를 더하기 위해선 조합에 관한 연구가 발전 되어야만 한다. 타입 시스템과 일급 시민으로서의 함수를 가진 함수형 프로그래밍이 함수 합성이라는 간단하지만 강력한 도구를 바탕으로 발전 하였듯이 컴포넌트의 조합을 다루는 디자인 시스템은 그에 관한 대수적인 체계를 갖추어야 한다는 것이다. 함께 사용될 수 있는 atom 조합이 있다면 이에 관한 기본 공리와 공리에 기반한 증명 체계가 있어야 한다. 예를 들자면 네비게이션 바를 이루는 컴포넌트들은 자신의 위 아래에 아무 것도 올 수 없다라는 원칙을 세울 수 있다. 너무 당연하지만 버튼 안에 버튼이 들어갈 수 없다. Hovered와 Focused, Disabled등 각각 상태를 표현하는 색상에 대한 방정식을 세울 수도 있다. 이러한 규칙들을 바탕으로 목적에 맞는 UI를 인공 지능이 설계하는 미래를 상상해 볼 수 있을 것이다.