2022. 4. 22. 17:11ㆍ프론트엔드/React.js
사실 아토믹 디자인을 전부터 들어보기는 했는데
솔직히 공부해 봐야겠다는 생각은 안 들었다.
원래도 컴포넌트로 잘 쪼개서 쓰기도 했고,
직관적으로 사용하던 기존 상황에 이름을 붙인 거라고 생각했다.
그리고 사실 공부를 해도 비슷한 것 같다.
결국 직관적으로 컴포넌트를 잘 조합해서 만들면 되는거지,
분자, 유기체와 같은 카테고리에 집착할 필요는 없다고 생각한다.
하지만 중요한 것은 소통이다.
결국 같은 언어와 용어로 얘기를 해야
여러 사람이 같은 내용에 대해 이야기 할 수 있다.
그래서 교양의 영역으로 공부를 해볼까 한다.
오늘은 이 분의 글을 읽고 공부를 해보기로 했다.
주관적인 판단 범위와 정보를 분리해서 잘 설명해주신 것 같다.
이건 아토믹 디자인 제작자의 원문글이다.
Atomic Design이란?
아토믹 디자인은 가장 작은 원자 단위부터 시작해서
원자를 합쳐 분자로, 유기체로, 템플릿으로, 페이지로 쌓아나가는 방식이다.
재활용 빈도가 높고, 직관적인 이해로 페이지를 분할할 수 있다는 장점이 있다.
특히 일관성 있는 디자인으로 프론트엔드를 구성하는 현재에 유용하다고 할 수 있다.
알고리즘과 같이 명확한 구현 방법이 있는 것이 아니고,
방법론적인 내용이다.
"이런 개념으로 구조를 구성해보면 좋지 않을까?"
라는 관점으로 보면 될 것이다.
Atom (원자)
아토믹 디자인에서 가장 작은 단위이다.
Atoms are the basic building blocks of matter. Applied to web interfaces, atoms are our HTML tags, such as a form label, an input or a button.
원자는 물질의 기존 구성 요소입니다. 웹 인터페이스에 적용해보면, 원자는 <form>, <label>, <input>, <button>과 같은 HTML 태그가 될 것입니다.
내 기준에 핵심은
"재사용 가능한 최소단위"다.
단순히 단일 태그나 크기가 작은 것이 핵심이 아닌,
여러 부분에서 재사용이 가능할 정도로 쪼갠 부분이라고 생각한다.
개인적인 기준
개발을 하다보면 이런 바리에이션의 버튼들을 보게 된다.
이러한 컴포넌트들을 개별의 원자로 구분하지 않는다.
Mui (@material-ui)와 같이 프로퍼티를 받아서
하나의 원자로 구현하고, 다양한 형태를 지원하는게 낫다고 생각한다.
예를 들면 다음과 같다.
const Button = ({ type, color, chlidren }) => {
const types = {
text: {
border: 0,
background: transparent,
},
contained: {
...
},
...
}
// 이런 색상관련 값들은 theme나 전역으로 사용하는 방법이 있다.
const colors: {
red: {
color: color,
backgroundColor: "white",
},
blue: {
...
},
...
}
// 예시니까 예외처리는 생략
return (
<button style={{ ...colors[color], ...types[type] }}>
{chlidren}
</button>
);
}
Molecule (분자)
분자의 설명은 다음과 같다.
Building up to molecules from atoms encourages a “do one thing and do it well” mentality. While molecules can be complex, as a rule of thumb they are relatively simple combinations of atoms built for reuse.
분자를 구성하는 것은 "한가지 일을 하고, 그 한가지를 잘 하는 것"을 기준으로 하기를 추천한다. 분자의 개념이 복잡해 보일 수 있지만, 일반적으로 원자의 조합이라고 보면 된다.
딱 봐도 추상적이다.
아래에서 추가적으로 얘기를 하겠지만,
원자만으로도 "한가지 일을 하고, 잘 하는 것"을 달성할 수 있다.
(단일버튼만으로도 역할을 다하는 것)
그래도 대략 생각나는 몇가지 예시들이 있다.
예를 들어 공식 문서에도 있는 입력창이다.
입력을 받고, 역할에 대한 설명(텍스트), 검색까지 할 수 있다.
이 분자는 "입력을 받아 그 내용으로 검색하는 것"을 잘 한다고 볼 수 있다.
또는 이런 것도 있겠다.
"현재 선택된 값을 보여주고, 여러 값중에 선택할 수 있는 것"을
잘 하는 분자라고 볼 수 있다.
내 생각에 핵심은
"기능을 가지는 것"이라고 본다.
마치 H2와 O가 만나 물이 되고,
특성을 가지는 무언가가 된다.
이 특성이 존재하는가 아닌가로 볼 수 있는 것 같다.
Organism (유기체)
여러 분자가 모여서 구성한 것이라고한다.
그리고 전체 페이지가 구성이 된다 뭐다 하는데...
너무한거 아닙니까 설명이...
원문 글을 봐도 모르겠다.
개인적으로 이해하기에는 시멘틱 태그가 생각났다.
<header>, <section>, <article>, <footer>등과 같은 시멘틱 태그는
개발자와 브라우저에게에게 각 부분이 어떤 내용인지 설명하는 것이 목적이다.
이렇듯, 무언가 기능을 하는 기능들을 조합하여
직관적으로 페이지의 한 부분을 담당하는 것이 아닌가...
생각을 한다.
Template (템플릿)
갑자기 템플릿이라는 개념이 나오는데,
원문의 이 부분을 보면 이해가 쉬워질 것 같다.
In my experience working with this methodology, templates begin their life as HTML wireframes, but over time increase fidelity to ultimately become the final deliverable.
이 방법론을 써본 제 경험상, 템플릿은 HTML 와이어프레임으로 시작했지만, 완성도가 높아지면 최종 결과물이 됩니다.
이런 식으로 이해를 해 보자.
템플릿이란 이런 것이다.
// html, head 태그는 생략
<body>
<Header />
<Nav />
<Section />
<Article />
<Footer />
</body>
위에서 유기체는 하나의 시멘틱 태그와 개념이 비슷하다고 했다. (내 생각이지만)
그 점을 이해하고 다음과 같이 시멘틱 태그를 조합하여 페이지를 구성했다고 생각하는 것이다.
이 유기체들이 실제 구현이 되었는지는 중요하지 않다.
전체적인 구조를 보여주는 것이고, 배치를 클라이언트에게 설명하는
소통의 도구로써 사용된다는 느낌이다.
Page (페이지)
페이지는 사용자가 실제로 보는 화면을 위한 것이다.
실질적인 컨텐츠가 구성되어 보이는 것이다.
이건 마치...
색칠놀이판을 생각나게 한다.
아니 사진을 골라보고 나니 왜 돼지는 저기서 사진을...
(제가 그린거 아닙니다)
템플릿은 유기체를 조합하여 그 틀을 구성하고,
페이지는 실제 색(데이터)를 주입하여 각 요소에 값이 들어갈 수 있게 하는 것 같다.
이러면... 안 될 것 같은데...?
자 이러면 문제가 뭘까?
페이지에서 모든 데이터를 다 가지고 있다는 점이다.
생각해보자 페이지에서 모든 callback과 state를 가지는 그런...
(난죽택)
그래서 위에서 올린 링크의 글에서는
Wrapped라는 컴포넌트를 만들어 주입을 했다.
내 생각은 다음과 같다.
이런 디자인 패턴은 결국 더 좋은 결과를 위한 것이다.
그런데 디자인 패턴에 얽혀 더 어려워진다면,
본질에 반한다고 생각한다.
그렇기 때문에 나는 유기체 단계에서부터
값을 삽입하는 것이 좋다고 생각한다.
만약 같은 유기체를 여러 페이지에서 재활용을 하고 싶다면,
위의 글과 같이 컴포넌트를 따로 만들어 값을 주입하거나
Context를 이용해 주입하거나,
아예 템플릿 단계를 건너뛰고 유기체에 값을 넣은 컴포넌트들로
페이지를 구성하는건 어떤가 싶다.
(솔직히 템플릿 없어도 될 것 같은데... 내가 이해를 잘못 한 건가)
아무래도 나는 만들어진 템플릿을 여러번 활용하는
경우를 많이 안 봐서 그 단계를 스킵하는게 더 편해 보인다.
이런 부분들은 자신의 상황에 맞게
잘 적용하는게 중요한 것 같다.
고민해야 할 부분
만약 내부에 아이콘이 달려있는 버튼이 있다고 생각해보자.
이런 아이콘 버튼을 구현해야 한다면,
버튼과 svg에 대한 컴포넌트를 만든다음,
둘을 합친 컴포넌트를 따로 만들 것 같다.
// 원자: 버튼
const Button = ({ children }) => (<button>{children}</button>);
// 원자: 아이콘
const Icon = ({ src }) => (<svg src={src} />);
// 분자: 아이콘 버튼
const IconButton = ({ text, src }) => (
<Button>
<Icon src={src} />
<span style={{ ... }} /> // 아이콘과 텍스트 사이 공백
{text}
<Button>
);
하지만 이건 분자의 기준에 맞지 않다.
역할로만 따진다면 원자에 맞다.
하지만 원자들의 결합이기 때문에 원자라고 보기도 애매하다.
역할로는 원자,
구조적으로는 분자가 된다.
이런 문제도 하나의 논점이고,
이런것에 대한 해석으로 인해서 다양한 방법이 나오는 것 같다.
한 단위 내에서도 위아래가 갈린다?
위에서 본 예제와 같이 Icon과 Button을 합친 IconButton을 보자.
원자라고 하게 된다면, 같은 원자지만 원자를 결합한 원자가 된다.
원자에서만 이런 일이 벌어질까?
분자나 유기체에서도 벌어질법하다.
분자 단계 스킵 (원자만으로 유기체 조합)
이런 부분도 생각해볼만하다.
정말 단순하면서 끔찍한 UI라서,
원자를 조합해도 유기체를 만들 수 있다고 생각해보자.
예를 들어 상단바인데, 버튼 1개, 타이틀 1개로만 구성되어 있다.
이건 역할적으로는 유기체다.
하지만 원자들의 조합이라는 점에서 아이러니하다.
핵심은 원자만으로도 분자의 역할,
무언가 하나를 잘 한다를
만족한다는 점이다.
이런 부분도 고민해볼 여지가 될 것이다.
아토믹 디자인의 한계
전체 페이지를 개념단위로 쪼개고 쪼개는 방식은
전부터 있어왔다.
왜냐하면 개념적으로 직관적이었기 때문이다.
그것을 명문화했다고 볼 수 있다.
하지만 이건 어디까지나 개념적인 내용이다.
원자, 분자, 유기체의 3단계가 개발을 하다보면
7단계의 세부적인 구조가 될 수도 있는 것이다.
그렇기 때문에 '이건 원자야, 분자야'와 같은 논쟁보다는
'개념단위의 컴포넌트 구성'과 '최소 단위 컴포넌트를 통한 재활용'에
초점을 맞추는게 더 중요하지 않나 생각해본다.
'프론트엔드 > React.js' 카테고리의 다른 글
React 공식 문서 읽기 - 1회: 주요 개념(1) (0) | 2022.05.15 |
---|---|
객체 지향 설계 - SOLID (0) | 2022.05.14 |
Next.js - Page에 대해 알아보자 (0) | 2022.04.14 |
Next.js 튜토리얼 (0) | 2022.03.20 |
React CRA 없는 프로젝트 베이스 (0) | 2022.03.15 |