프론트엔드 설계 고민 -5-

큰틀은 대략적으로 잡았으니 조금 더 작은 부분들을 고민해보자. SPA 개발 즉, 모던 웹개발로 들어오면서부터 웹프론트의 UI의 경우 기본적으로 기존의 페이지 단위나 템플릿 단위의 개발에서 컴포넌트 단위의 개발로 개념이 조금 변경 되었다.

기존에는 마크업이나 스타일링을 HTML과 CSS로 그리고 JS로 필요한 동적인 조작을 하는 정도 였다면 모던 웹개발에서는 JS를 기반으로 HTML(마크업)과 CSS(스타일링)등을 모두 관리한다. (예: JSX)

그러다보니 기존 HTML, CSS와 많은 부분 같으면서도 다른 특징을 가지는데 HTML,CSS와 JS로 된 DOM, CSSOM의 차이점에서 오는 부분이라고 볼 수 있다. HTML과 CSS, JS로 개발을 진행할때는 각 영역이 독립적이고 서로 침범하지 않는게 미덕이였다. 그러나 DOM과 CSSOM을 조작하는 지금에 와서는 여전히 기존의 영역을 존중해야하지만 HTML과 CSS가 아닌 DOM과 CSSOM이라는 점에 의해서 사실상 JS의 영역으로 들어오게되었다.

그렇기에 기존의 HTML, CSS, JS를 분리하던 방식의 개발과 다르게 컴포넌트 단위로 DOM과 CSSOM 그리고 JS로 된 로직들을 일정한 추상화로 묶어서 관리하는 컴포넌트 방식의 개발을 진행하게 된다. (이점이 몇몇 기존 웹개발자 올드멤버들이 모던 웹개발을 어려워하는 점이 아닐까라고 추측해본다.)

물론 여러가지 도구를 활용해서 비슷한 효용성을 얻을 수 있기는 하지만 어쨌든 UI를 DOM과 CSSOM을 묶은 컴포넌트라는 개념으로 관리한다. 그리고 그런 컴포넌트의 재사용성등 여러 측면을 고려하기 위해서 그 컴포넌트를 개발하기 위한 다양한 방법들이 연구 되고 있다.

그중 하나로 개인적으로도 애용하고 보편적으로 여기저기서 많이 사용되는 아토믹 디자인 패턴이 존재한다. 처음 해당 패턴이 나왔을 당시에는 그렇게 권위 있는 방법론은 아니였던 것으로 알지만 현재에서는 프레젠테이션(UI)컴포넌트를 관리하는 보편적인 방법론으로 자리잡았다.(Recoil도 영향을 받은 것 같다.)

아토믹 패턴의 경우 UI를 Atoms,Molecules,Organisms,Templates 크게 4가지 구분으로 UI의 복잡도에 따라서 재사용하기 좋게 컴포넌트를 관리하자는 내용인데 개인적으로는 Atoms,Molecules,Organisms에 Layout을 더하는 방식으로 변형해서 지키려고 노력한다.

왜냐하면, 추상화 정도에 따라서 다르겠지만 아직 진행하는 UI개발의 수준이 디자인 시스템 정도의 복잡성을 가진게 아니다보니 재사용 할 필요가 없는 부분을 따로 하위 레이어로 추상화해서 관리하지 않는 편이고 Templates 정도 단계가 될 경우 순수하게 UI적인 부분만을 제네릭하게 관리하는 경우가 프로젝트 상으로 잘 없기 때문이고 보통 도메인에 종속적인 Feature로 상태와 결합해서 관리하는 편이기 때문이다.

이 부분은 결국 프로젝트 규모나 목적에 따라서 달라질 부분이긴하지만 보편적인 수준의 웹 프로젝트에서는 해당 부분에서 추가로 따로 레이아웃 레이어를 구분해주는 정도만 하는게 생산성 측면에서 적당하다고 느낀다.

그렇다면 컴포넌트와 보통 원자나 분자등의 레이어는 어떻게 구분 할것인가? 이것에는 개인적으로 크게 두가지 기준이 있다고 보고 있다. 하나는 기존의 개발 또는 디자인 시스템에서 보이는 보이는 요소에 따르는 구분이고, 다른 하나는 목적에 따르는 구분이라고 생각한다.

보이는 요소에 따르는 구분은 보통 스타일링에 따라서 달라진다. 같은 버튼이라도 둥근 버튼, 네모난 버튼, 절반만 둥근 버튼 또 햄버거 버튼, 미트볼 버튼, 케밥 버튼 등으로 UI적인 부분이 잘 정의되어서 목적에 따라서 달라지는게 아닌 공통된 규격을 가지고 해당 규격들을 재활용하는 선에서 움직이는 부트스트랩등의 디자인 시스템에서 자주보이는 방식이다.

목적에 따르는 구분은 보통 해당 UI가 제공해주는 목적에 따라서 달라진다. 같은 모달이라도 확인과 취소를 지원해주는 확인 모달이 있고, 단순한 경고를 제공해주는 경고 모달 정보를 알리는 목적을 가진 팝업모달(허접한 네이밍은 신경쓰지 말아주길 바란다.)등이 있다. 보통 프로덕트 어디에서나 자주보이는 방식이다.

UI의 경우 순수 디자인 과 목적 부분이 결합 되어 있기 때문에 보통 두가지 기준을 혼용하는 경우가 많은 것 같다.(본인만 그럴지도...) 보통 그런 상황에서는 보편적으로 Atoms단계에서는 디자인적인 부분으로 구분을 하고, Molecuels부분 부터는 목적에 맞는 구분으로 들어가는게 적합하다고 본다.

왜냐하면, 추상화 정도에 따라서 조금씩 달라지겠지만 아토믹 패턴의 경우 보통 원자, 분자, 유기체 템플릿 단계에서 각 단계를 구분 짓는 기준이 해당 컴포넌트의 복잡성인 경우가 많고 그렇기에 디자인시스템을 따로 구축하고 그걸 프로덕트에서 가져다 쓰는게 아닌 경우 보통 분자 정도의 복잡도 수준만 되어도 그것을 단순히 UI적인 부분으로 구분짓기 힘들기 때문이다. 순수하게 디자인에 종속적이지도 않고 말이다.

동일한 구조에서 단순히 스타일링이나 구성요소 하나 달라진 것을 디자인적으로 정의 내리자면 정의하는 용어가 존재하는 것이라면 모르겠지만 자칫하면 "모달-배경이 반투명한 검은색임-닫기버튼있음", "모달-배경이 보노보노등 이미지-확인 취소가능" 따위가 되기 쉽다.(물론 실제로 저렇다 한들 배경등은 스타일을 외부에서 주입하겠지만) 그리고 사실 애초에 햄버거 버튼이나 케밥 버튼 미트볼 버튼 따위의 용어도 순수하게 디자인적인 측면만 있다고 보긴 힘들다.

그렇게 복잡도가 낮은 단계에서는 디자인적인(스타일링) 측면에 따라서 구분하고 복잡도가 올라 갈 수록 목적에 따라서 구분한다고 결정했으니 이제 그 추상화 정도를 어떻게 구분 지을지 고민해보자. 위의 논의에서 알 수 있다시피 추상화 단계를 구분 짓는 것은 자의적으로 결정하게된다. 애초에 프로젝트에 적합한 구조라는게 항상 일괄적이고 동일 할 수 없기 때문이다.

여기서 말하는 복잡도는 당연히 알고리즘에서 말하는 복잡도가 아니다.(곰곰이 생각해보면 관련이 아예 없진 않지만) 컴포넌트 구조의 복잡도를 말한다.
컴포넌트의 복잡도를 어떻게 구분지을 것인가라는 측면에서는 Atoms,Molecules,Organisms 등의 레이어의 관계를 고민해봐야하는데 각각 레이어가 상속관계를 가질지 아니면 동일한 위계의 다른 도메인(목적)을 담당할지에 따라서, 그리고 그 도메인간의 의존성을 어떻게 할지 등의 측면에 따라서 달라진다. Atoms가 같은 Atoms를 참조 할 수 있거나, 없거나 또는 Molecules가 Atoms에 의존해서 UI를 구성하는지 아닌지 등등 말이다.

보통 아토믹 패턴의 경우 의존성이 Organisms이 Molecules와 Atoms를 Molecules가 Atoms를 하는 관계를 가져서 Atoms의 변화가 Organisms등으로 전파된다. 그 반대는 존재하지 않는다고 보면 좋다. 어쨌든 아토믹 자체가 동일한 구조를 재활용해서 직관적으로 일관적인 UI를 개발하기 위해서가 목적이다보니 특수한 구조가 아닌한 보편적으로 해당 구조와 비슷하게 간다.

그리고 컴포넌트의 경우 크게 두가지 관점으로 복잡도를 나눌 수 있다.
컴포넌트를 상속받는 관계에 따라서 레이어가 나뉘는 경우, 컴포넌트 자체가 가진 DOM의 복잡도에 따라서 나뉘는 경우

보통 두가지 경우를 모두 적절히 봐서 복잡도를 설정하는게 좋은데 컴포넌트 상속의 경우 재사용성과 관리의 측면에서 동일한 버튼 구조를 가지고 그것에 특색이 있는 경우라거나 그럴 경우 기본 버튼 구조가 변하면 해당 버튼 구조에서 조금 변형된 부분은 동일하게 변화하는게 좋은 경우 등이 있고
DOM의 복잡도가 높아서 여러 컴포넌트나 NODE 들이 결합하는 관계를 가지는 케이스의 경우 예를 들면 Input 태그와 Button 태그는 그 자체로는 동일한 DOM 깊이에 구성요소가 같지만 Input의 경우 보통 Label이나 Text나 Image등이 결합되는 점이 있어서 서로 다른 레이어로 구분 짓는 경우 등이 있다. 이 경우는 애초에 구조적으로 Atoms와 차이가 나므로 편의상 하위 레이어가 없다고 할지라도 분자 단위로 구분 짓기도 한다.

정리하자면
이전 웹개발의 원칙이 사라진 것은 아니지만 모던 웹개발의 경우 사실 JS를 다루고 있다. 그렇기에 컴포넌트 개발이라는 형식을 가진다.
UI개발에서 현재 보편적으로 아토믹패턴 설계 원칙을 따르고 있다.
UI 컴포넌트 분리에서 하위 레이어는 디자인적인 측면을 추상화 될 수 록 목적에 따라서 분리한다.
UI 레이어는 보통 복잡도와 재사용성(관리)를 고려해서 적절하게 설정한다.
UI 적인 요소 부분은 최대한 디자인 시스템을 구축하도록 노력해보자.