디자인 프레임워크(Mui)를 사용 시에 아토믹 디자인 아키텍쳐 고찰

서비스의 아키텍쳐는 어느 정도 정해진 틀에서 개인의 역량과 프로젝트 성향에 맞춰 유기적으로 변하는 생물 같은 개념이다.

클린 아키텍쳐, 도메인 주도 아키텍쳐, 관심사 분리 위주의 아키텍쳐 등 다양한 아키텍쳐가 존재하고 어느 회사, 어느 개인의 아키텍쳐를 봐도 완전히 똑같은 경우는 거의 없다.

이번 프로젝트에서 아토믹 디자인 패턴을 적용해보고자 마음 먹으면서 동시에 디자인 프레임워크 중에 React Material UI를 사용하게 되었다.

처음 설계 단계부터 고민이 없을 수가 없었는데 처음의 설명대로 유기적으로 변하는 생물 같은 개념을 뭔가 딱 답을 정해서 표현할 필요는 없기에 나만의 설계대로 진행해보고자 한다.

우선 아토믹 디자인의 기본 개념부터 알고 접근해야 할 것 같다.

아토믹 디자인

아토믹 디자인이란 원자(atmos), 분자(molecules), 유기체(organisms), 템플릿(templetes), 페이지(pages) 5가지의 계층 구조로 구분되는 디자인을 의미한다.

원자가 조합되서 분자를 만들고 분자가 조합되서 유기체를 만들고 뭐… 명확히 선형적인 구조라면 별다른 고민이 없겠지만, 사실 아토믹 디자인의 실제 적용 후기나 공식 문서 등을 봐도 원자, 분자, 유기체 등은 특히나 그 경계가 애매모한 경우가 많다.

그래서 이 부분은 특히나 개발자의 직관적인 역량에 맞춰 디자인 되는 경우가 많다고 본다.

원자(atoms)

간단하게 접근하자면 더 이상 쪼갤 수 없는 가장 작은 단위의 컴포넌트를 의미한다.

우리가 html 태그의 기준으로 보자면 <button>처럼 더 쪼개질 수 없는 단위를 얘기하는 것이다.

그래서 대부분 단일 태그 기준으로 나눠지는 원자가 구분되는 경우가 많고 좀 더 명확한 분류다.

분자(molecules)

공식 문서 상으로는 2개 이상의 원자가 모여 구성되고 고유한 특성을 가지고 있다고 한다.

우리가 어떤 입력폼을 만든다면 input, button 등의 조합된 컴포넌트라고 볼 수 있을 것이고 이것이 분자 단위에 해당된다.

유기체(organisms)

분자가 상대적으로 간단힌 컴포넌트라면 유기체는 상대적으로 복잡한 컴포넌트를 의미한다.

원자, 분자, 유기체 어느 조합으로도 만들어질 수 있다.

말 그대로 유기체끼리 조합해서도 더 복잡한 유기체를 만들 수 있고 우리는 여기서 한가지 고민에 휩싸이게 된다.

상대적으로 간단한 유기체는 분자 단위가 아닌가? 물론 정답은 없다.

자신의 기준을 가질 수 밖에…

템플릿(templates)

템플릿은 의미가 좀 명확한 편이지만 용도에 대해서는 의문은 있는 컴포넌트이다.

왜냐하면 실제로 화면상에 노출될 일은 없는 컴포넌트가 아닌가? 라는 의문이 있기 때문이다.

실제로 템플릿은 동적인 상태가 없으며, 기본 상태만 부여해서 가이드라인 역할을 하는 위주로만 사용된다.

그래서 템플릿이란 일반적으로 실제 데이터 핸들러 구현을 하기 전 기본 뼈대를 만들고 구성원 간의 상호 소통을 위해 필요한 영역이라고 주관적인 판단을 하고 있다.

그리고 본인의 스토리북 등을 활용한다면, 꽤 괜찮은 시점에서 개발, 디자인, 기획자 간의 소통이 가능한 컴포넌트라고 할 수 있을 것이다.

페이지(pages)

말 그대로 도메인과 데이터, 핸들러가 적용된 실제 페이지를 의미한다.

원자, 분자, 유기체 어느 조합과도 조합될 수 있지만 템플릿과는 조합되지 않는다.

템플릿 자체가 페이지의 뼈대이기 때문이다.

Material UI를 적용한다면?

본인의 프로젝트에 디자인 프레임워크(mui 같은…)가 적용된다면 이미 대부분 개발에 필요한 원자, 분자 단위의 컴포넌트를 제공 받고 있는 것이다.

그럼 나는 굳이 이 컴포넌트들을 한번 더 감싸고 중복되는거나 마찬가지인 원자, 분자 단위 컴포넌트를 또 만들어야할까?

그건 아닐 것이다.

사실 분자 단위의 컴포넌트는 필요에 따라 더 조합해서 만들 수는 있다고 본다.

그리고 대부분의 상황에서는 유기체 단위의 컴포넌트를 mui에서 제공하는 원자, 분자 단위의 컴포넌트를 조합하여 만들게 될 것이다.

컴포넌트 부분의 아키텍쳐

/src
  /assets
  /components
    /composite -- 합성된 모든 컴포넌트
      /Header
      /Aside
      /Nav
    /templates -- 페이지의 기본 뼈대가 되는 템플릿 컴포넌트
      /Home
      /User
      /Error
  /pages -- 페이지 단위의 컴포넌트
    /Home
    /User
    /Error
  /hooks -- custom hooks
  /store -- 상태 관리
  /utils

mui를 사용하면 거의 만들지도 않을 원자 단위의 폴더도 구색을 맞추기 위해 넣는다거나 하는 것은 너무 보수적인 행동이라고 본다.

그래서 mui를 사용한 모든 합성 컴포넌트들을 composite로 명명하고 애매한 분자와 유기체를 한번 더 나누는 고민을 하기 보다는

분자 단위의 컴포넌트는 mui에서 제공하는 것을 적극 활용하고 별도로 분자 단위의 컴포넌트를 만들던 유기체를 만들던 하나의 레이어에 포함하는 것을 채택했다.

물론 이 구성은 composite 컴포넌트가 분류가 어려운 수준으로 늘어난다던가 하는 상황이 생긴다면 한번 더 구분하는 것을 고려해보겠지만 처음부터 아키텍쳐를 복잡한 수준까지 가정하고 갈 필요는 없다고 본다.

말 그대로 변하는 생물이니까…

기본 구성을 이렇게 가져가고 그때그때 상황에 맞춰 대처를 하고 데이터, 핸들러, 컨텍스트의 관리를 composite 컴포넌트 수준에서 관리하는 방식으로만 채택해도 많은 해결이 가능할 것이라고 생각해서 적용했다.