소프트웨어 개발 중 설계에서 가장 중요한 것은 모듈화와 추상화 두 가지라고 할 수 있다. 웹 프론트엔드 업계는 이미 React, Vue.js, Angular와 같은 오픈소스 프레임워크를 통해 끝을 달리는 추상화와 모듈화를 보여주고 있다. 특히 모듈화 측면에서 세 프레임워크는 컴포넌트 인터페이스 를 매우 쉽게 제공하기 때문에 프레임워크 사용자는 효율적인 재사용이 가능하고 캡슐화된 컴포넌트를 아주 간단하게 만들 수 있다. 그렇기에 우리는 좋은 컴포넌트를 만들기 위해 올바른 방법과 규칙을 정하기만 하면 된다.
이번 포스팅의 핵심 키워드인 Atomic Design은 좀 더 효과적인 컴포넌트를 구성하기 위한 방법론이다. 최근들어 크게 유행하고 많은 기업이 도입하는 방법론이지만 Brad Frost가 2013년에 처음 공개했으니 생각보다 오래된 방법론이다. 아마 본격적인 컴포넌트 주도 개발 방식이 자리 잡게 된 후 주목을 받은 것 같다. Brad Frost가 직접 쓴 책을 따로 $10에 판매하기도 하니 관심이 있다면 구매해보는 것도 괜찮을 것 같다.
본론으로 돌아와 이번 포스트에서 다룰 이야기는 Atomic Design을 더 잘 쓰기 위한 방법에 대해 소개한다. 물론 그전에 Atomic Design이 무엇인지 간단히 알아보고 진행하도록 하자.
Atomic Design이란?
Atomic design is methodology for creating design systems.
- Brad Frost
Atomic Design은 그 이름처럼 화학 용어를 이용하여 설명하는 컴포넌트 관리(디자인 시스템) 방법론이다.
좌측부터 Atom(원자), Molecule(분자), Organism(유기체), Template, Page
로 이루어져있다. 기초적인 화학 내용이 기억 안나는 사람들을 위해 간단히 설명하자면 원자는 물질을 구성하는 가장 작은 입자고 원 자가 모여 분자가 구성된다. 유기체는 활동하는 생명체를 의미하므로 훨씬 큰 개념이라 볼 수 있다.
어떻게보면 과거부터 우리가 해왔던 컴포넌트 구성 방법과 크게 다르지 않다. 보통 개발자들은 Atomic Design을 모르던 시절에도 본능적으로 작은 단위부터 큰 단위로 컴포넌트 단위를 나누고 상향식 접근을 통해 컴포넌트를 구성해왔다. 결국 Atomic Design은 우리가 본능적으로 해왔던 것을 직관적인 용어와 문서로 정리 한 것이라고 볼 수 있다.
Atom
Atom은 더 이상 쪼갤 수 없는 단위에 해당하는 요소에 해당한다. 혹은 애니메이션, 폰트, 색상 등과 같이 요소가 아닌 속성도 Atom에 해당된다. 가장 작은 단위인 만큼 가장 많이 재사용된다고 볼 수 있다.
Molecule
Molecule은 여러 개의 Atom이 모여 목적성이 있는 하나의 컴포넌트가 된다. 가급적 많은 곳에서 재사용되도록 컴포넌트를 구성하되 "한 가지 일을 한다"라는 원칙을 지키며 만드는 것이 좋다.
Organism
Molecule까지는 사용자에게 크게 의미 있는 인터페이스라고 볼 수는 없었다. Organism은 사용자에게 의미 있는 정보를 제공하거나 인터렉션 할 수 있는 UI를 제공하는 등 서비스로서 의미를 가지는 인터페이스라고 볼 수 있다. 이 단계부터 재사용성이 크게 줄어든다.
Template
Template은 흔히 사용해왔던 Layout과 비슷한 개념으로 볼 수도 있다. 더 정확하게 말하자면 실제 콘텐츠가 입혀지기 전 UI 요소, 레이아웃, 기능이 어떻게 배치될지 정하는 와이어 프레임이라고 볼 수 있다. 따라서 자주 재사용되는 컴포넌트가 된다.
Page
Page는 사용자가 볼 수 있는 최종 콘텐츠가 보이는 화면이다. 사용자와 인터렉션이 발생하거나 API 호출 등을 통해 사이드 이펙트가 발생 할 수 밖에 없는 컴포넌트기도 하다. 일반적으론 하나의 URI 당 하나의 Page 컴포넌트만 존재한다.
Why Effective?
Atomic Design에 대한 설명만 본다면 컴포넌트를 나누는 단계가 명확해보이기에 크게 문제가 없어보인다. 하지만 실제 구현을 하다보면 애매모호한 부분이 생기고 팀 내에서도 해석이 달라지기에 결국 규칙을 만들게 된다.
그 원인을 보자면 Atomic Design은 방법론이지만 레이어 아키텍처 패턴으로 이루어진 컨셉으로도 볼 수 있기 때문이다. 우리는 이러한 컨셉을 구현하는 과정에서 개발 환경, 구성원 등 다양한 고려 사항이 생기기 때문에 컨셉을 여러 방법으로 해석할 수 있고 심한 경우 컨셉을 잘못 이 해할 수도 있다. 예를 들어, 유명한 아키텍처 패턴인 MVC(Model-View-Controller) 패턴을 구현하더라도 다양한 해석이 존재하고 애플이 iOS에 적합하도록 CocoaMVC1로 완전한 재해석한 것처럼 컨셉을 크게 바꿔버릴 수도 있다.
따라서 우리는 아키텍처를 올바르게 구현하기 위해 컨셉을 잘 이해하고 원칙을 정해야 한다. 필자는 Atomic Design을 적용하며 겪은 시행착오를 통해 나름 보완점과 설명이 필요한 부분을 정리하여 7가지 표준적인 규칙을 정했다.
Atom의 범위
앞서 Atom은 눈에 보이는 요소를 포함하여 애니메이션, 폰트, 색상 등과 같이 요소가 아닌 속성도 Atom에 해당된다고 설명했다. 최소 범위는 HTML 요소 혹은 속성 하나로 정할 수 있지만 최대 범위는 어디까지 정해야 할까? Atom의 경우 최대한 재사용이 가능하도록 만들어야 하지만 지나치면 오히려 사용하기 힘들어질 뿐이다. 필자의 경우 요소와 속성을 포함하여 UI가 시각적으로 하나의 덩어리이며 한 가지 역할을 한다면 Atom으로 인정하기로 규칙을 정했다.
예를 들어, 페이스북 게시물을 본다면 프로필 이미지가 보이는 아바타와 링크에 대한 정보를 볼 수 있는 아이콘 버튼은 여러 요소가 중첩되고 다양한 속성이 추가되었지만 시각적으로 하나의 덩어리로 포함되고 각각 프로필 이미지를 보여주는 것과 버튼이라는 한 가지 목적을 지니고 있기에 Atom이라 볼 수 있다.
Atom의 범위는 디자인 원칙과 크게 맞닿아있다. 위에 첨부된 사진을 보면 디자인 원칙에 따라 어떤 역할이든 통일된 버튼을 사용할 수 있고 역할별로 다른 버튼을 사용할 수도 있다. 전자의 경우 적합한 Atom 컴포넌트를 하나 만들면 되지만 후자의 경우 역할 별로 Atom을 만들지 Atom 하나가 옵션에 따라 변할지 정해야 한다. 좋은 선택을 하기 위해선 확장 가능성, 수정될 가능성 등 디자인 관점에서 여러 가지 상황을 고려해야 한다. 그렇기 때문에 우리가 Atom 컴포넌트를 잘 만들기 위해선 어느 정도 서비스에 적용되는 디자인 원칙을 이해할 필요2가 있다.
이 컴포넌트는 Molecule, Organism 어느 쪽?
Atomic Design 방법론으로 컴포넌트 시스템을 구성하다 보면 어느 순간 반드시 Molecule로 둘지 Organism에 둘지 고민하는 순간이 온다. 그런 경우 무의식적으로 컴포넌트가 차지하는 영역이 크다면 Organism에 넣고 아닌 경우 Molecule에 넣을 때가 많지만 별로 좋은 방법은 아니다.
다른 사례를 보면 React 용 Atomic Design 기반 Starter Kit인 ARc는 일단 너무 고민하지 말고 아무 곳에 넣고 추후 어떤 레이어에 속해야 하는지 알게 되면 정리하라고 권한다.
소프트웨어 개발자는 항상 바쁘기 때문에 ARc의 구분 방법도 괜찮다고 생각한다. 하지만 필자가 생각하는 구분법은 다음과 같다.
- Molecule은 데이터를 표시하고 이벤트를 받을 수 있지만 "하나의 역할"만을 가진다.
- Organism은 사용자에게 의미를 가지는 기능적 요구사항에 포함되는 경우에 해당되는 컴포넌트다.
네이버 메인을 필자 기준대로 분석한다면 다음과 같다. 파란색이 Organism 주황색이 Molecule이다.
컴포넌트의 복잡성이나 크기로만 생각한다면 광고 영역은 Organism이 아닌 Molecule로 들어갈 것이다. 하지만 사용자는 광고를 본다
, 광고는 주기적으로 변경된다
라는 기능적 요구사항을 가지는 컴포넌트기 때문에 필자는 Organism에 포함시켰다.
한편 날씨 정보를 보여주는 곳은 작은 영역을 차지하기에 Molecule처럼 보일 수 있다. 여기서 중요한 것은 해당 컴포넌트가 날씨 정보를 보여주는, 단순히 데이터에 맞춰 UI를 표시하는 하나의 역할
을 가진 컴포넌트라는 점이다. 이런 컴포넌트는 주입받은 데이터가 어제 날씨인지 오늘 날씨인지 심지어 아무렇게나 넣은 데이터인지 알 수 없다. 따라서 Molecule에 속한다. 하지만 현재 날씨 정보를 실시간으로 업데이트하며 보여준다
는 요구사항은 컴포넌트를 감싸는 Organism이 처리하게 된다. 이처럼 기능적 요구사항 관점에서 본다면 대부분은 결정할 수 있다. 하지만 그럼에도 불구하고 결정하기 어려운 컴포넌트가 등장한다면 ARc처럼 일단 아무곳이나 넣고 나중에 고민해보자.