Atomic design과 컴포넌트 개발

이상현·2022년 7월 25일
1

thoughts

목록 보기
1/1

언젠가 네이버가 블로그 서비스의 기술 스택을 이전할 때 atomic design을 기반으로 프로젝트를 진행했다는 아티클을 본 기억이 있다. 본래 5단계인 원론을 실제에 맞춰 적용해 3단계 - 아마도 atoms < mocules < template - 로 줄이고, 여기에 맞춰 컴포넌트를 만들었다는 내용이었는데...

추상화, 계층 구조, 그리고 현재의 주류가 되있는 컴포넌트가 무언가의 쪼개진 단위라는 데에서 atomic design을 하나의 개발 architecture로 보는 게 아닐까 싶다.


원문의 기나긴 사전 배경 설명의 1장을 지나 이 아이디어를 설명한 2장에서 Brad frost가 말하는 5단계 추상화의 요점은, 디자인 시스템의 계층화이다.

- Brad frost 설명의 반대 방향의 풀이이긴 하지만 - 웹 페이지의 수많은 요소를 잘게 조사 쪼개다보면 더이상 그 형체나 특성을 잃어버리지 않는 수준까지 내려갈 수 있고, 그 계층의 단위를, 문자 그대로 물질의 특성을 유지하는 수준에서 더이상 쪼갤 수 없는 원자의 이름을 차용해 atom이라 이름한다.

이해가 어려울 때는 낮은 차원에서 상상하는 게 실물을 체감하기 편하다. page 같이 다양한 내용을 가진 큰 덩어리보다 훨씬 마이크로한 것을 놓고 위의 원리에 입각해 생각해본다 하면, 텍스트의 경우, 두께, 색상, 크기, 행간, 자간등으로도 쪼갤 수 있을 것이다.

코드로 옮겨본다면 이러할 것이다.

function Text({theme, copy, tagname}){
	const {color, size, weight, lineHeight, letterSpacing} = theme;
  	const style = {
    	fontSize : size,
    	fontWeight : weight,
     	color,
      	lineHeight,
    	letterSpacing
    };
  	return(
    	<tagname style={style}>{copy}<tagname>
    )
}

컴포넌트 Text는 props - color, size... - 로부터 받는 정보로 구성되므로 props = atom으로 치환할 수 있다. 그런데, 앞서 말한대로 특성은 잃어버리면 안되는 가장 단위로 정의된 것이 atom인데 색상이나 크기, 두께를 atom으로 볼 수 있을까. 혹자의 디자인 시스템에서는 색상, 글씨의 크기, 두께를 하나의 요소로서 정의하기도 하지만, 그러나 Brad frost는 형태로 존재할 수 있는 것 - atom - 부터 계층으로 정의했다. 따라서 theme나 copy등의 값이 아닌 컴포넌트가 atom이 될 수 있고, Brad frost의 계층 정의에 따르면 이 컴포넌트들이 이룰 트리 구조에서 특히 가장 말단이 atom이 될 것이다.

그런데 하나 의문이 든다. 정말 가장 말단의 컴포넌트는 모두 atom과 매칭될까...

개발에서 컴포넌트를 사용하는 목적에는 다형성과 의존성 관리에 있다.

가령, 위의 Text 컴포넌트의 성격은 theme에 따라 달라진다. 컴포넌트의 특성을 결정짓는 것은 theme이고, 그 특성이 개별로 컴포넌트화한다면 Title, Description, Eyebrow, Disclaimer, Anouncement, Annotation...등 수많은 종류가 될 것이다. theme를 확장하면, 밑줄, 기울이기등도 있을테고, font css에 관련된 모든 것이 주입 가능하다. theme가 recipe - defendancy - 역할을 하는 것이다. 이로 보면, Text 컴포넌트는 theme를 받는 그릇으로 Title, Description... 이전에 존재하는 원형이 된다.

이건 Brad frost가 구상한 것과는 다르다. 그의 계층에는 여러가지로 뽑혀나올 수 있는 원형이라는 개념이 없다. 디자인 시스템에서 18px text와 20px text는 서로 다른 요소이며, 18px bodycopy와 18px headcopy도 서로 다른 요소 - atom - 이다. atom은 이미 theme가 주입된 컴포넌트, 즉 디자인이 투영된 인스턴스인 것이다.

mocules/organisms 계층에서 정의될 다른 디자인을 생각해보자.

Header 안에 Navigation과 Search가 있다. 디자인은 이 문장만으로 요소 표현이 가능하다. 개발할 컴포넌트는 그보다는 조금 더 내용이 들어간다. 이 사이에 layout이라는 계층이 필요하다.

function Header(props){
	const theme = {
		display:"flex",
		justifyContent:"space-between",
		alignItems:"center",
		rowGap:"20px",
	};
	return (
		<Layout theme={theme}>
			<Navigation /> {/* Menu:List < ClickableItem:Link */}
			<Search /> {/* Label:text + Input + Button */}
		</Layout>
	)
}

atomic design에서 Layout은 어디에 속하는 계층일까. Header라는 organism에서 각각의 mocule의 자리를 정하는 계층이므로 organisms에 가까워 보인다. 그런데 이 컴포넌트는 mocule의 위치를 정하는 규칙을 정할 기능만 있고 Header의 특성을 정하는 실제 값은 theme가 쥐고 있다. Layout의 관점에선 반드시 Header에만 종속되지 않고 다른 어느 곳에서도 쓸 수 있고, 심지어는 Header의 위치조차도 Layout이 정할 수 있을 것이다. 결국 Header organism이라고 못 박을 수가 없다. 실체가 없는 추상화 계층이라 함이 적합하다.

또한 Header가 또다른 형태의 layout이 되려면 layout에 내려질 값은 정해져 있지 않아야 한다. Text와 마찬가지로 이에 관해선 Header 역시 의존성을 theme에 두게 될 것이다. 그런데 Text와는 다르게 Header 안의 것이 Header를 결정하는 모습이라 상하의 종속성이 바뀐다.

brad frost의 이론에 담겨있지 않은 하나가 이것이다. 그의 추상화는 형태적 분해가 가능하다는 것을 직관하고 그 계층의 레벨을 추상화한 것일 뿐, 요소가 담아내야 할 값이나 정보를 대상으로 한 것은 아니다. 그래서 Header가 organism이라는 계층에서 추상화될 순 있지만, 실체는 GlobalHeader나 LocalHeader가 되는 것이다.

data를 넣는 것만을 고려하면 atomic design은 도입하기 괜찮을 지 모른다. 이미 특성 - 넣어야/담아야 할 정보의 주제 -이 정해져 있어 기능 분화가 전제된 상태일테니 요소의 추상화를 생략할 수 있다. 그렇지만 이 data를 제어할 동적 권한이 주어져야 하는 경우, 그러니까 인터랙션 이벤트와 그에 딸리는 api는 theme와 같은 존재이며, 결국 개발자는 atomic을 도입할 때 요소의 추상화를 어떻게 가져가야 할 지 - 등식이 성립하지 않는 계층의 정리를 - 정해야 한다. 이론에 맞춰 구분하지 않고 뭉쳐버리면 개별 케이스로 각각 나뉘게 될 것이고 이렇게 다루면 관리의 문제가 붙으며, 관리하기 좋게 만들자면 화면의 정의가 추가, 변경될 때마다 혹은 그보다 사전에 많은 고민과 테스트가 필요하다.


ps. atomic design은 쪼갠다는 방식으로 대상의 차원을 제한해서 관찰할 수 있고, bottom-up 방식으로 대상을 바라볼 수 있다는 점에서 의미를 가진다 볼 수 있다. 개발에서 취해야 할 것은 이 부분이 아닐까 생각해본다. react를 통해서 템플릿 - 앱 - 을 대하는 방식에 변화가 생겼을 때처럼 이 이론은 사고 방식의 토대로서 활용되어야 가치가 있을 것이다.

profile
이런 건 왜...

0개의 댓글