아토믹(Atomic) 컴포넌트 디자인 개발 패턴
대형 프로젝트를 위한 코드 재사용 최적화 컴포넌트 관리법
대형 프로젝트에서는 최적화된 코드 재사용이 필수입니다. 이를 위해서 대두된 코드 디자인 패턴 중 하나는 바로 아토믹(Atomic) 디자인 패턴입니다. 위 패턴은 리액트, 뷰, 앵귤러 등 컴포넌트를 사용하는 라이브러리와 프레임워크에 모두 사용될 수 있습니다.
아토믹 디자인은 이름에서 유추할 수 있듯 가장 작은 컴포넌트 단위를 원자(Atoms)로 설정하고, 이를 바탕으로 상위 컴포넌트를 만들어 코드 재사용을 최대화하는 방법론입니다. 상위 컴포넌트는 순서대로 분자(Molecules), 유기체(Organisms), 템플릿(Templetes)으로 가며 최종적으로는 페이지(Pages)를 관리합니다.
왓차 메인 페이지이번 글에서는 왓차(Watcha)라는 서비스를 통해 각각의 컴포넌트를 어떤 식으로 분리할 수 있는지 살펴보겠습니다.
원자(Atoms)
원자 컴포넌트는 디자인과 기능의 최소 단위라 이해할 수 있습니다. 앞으로 만들 상위 컴포넌트에 재사용해야 하기 때문에 가장 작고, 미니멀하게 제작합니다. 대표적인 원자 컴포넌트는 레이블(Label), 텍스트(Text), 컨테이너(Container), 버튼(Button), 아이콘(Icon) 등입니다.
분자(Molecules)
원자보다 한 단계 위의 컴포넌트입니다. 입력 폼(Input forms), 내비게이션(Navigation), 카드(Card) 등을 예로 들 수 있습니다. 보통 프런트 개발자들이 컴포넌트를 만들 때 가장 많이 만드는 단위가 분자 수준의 컴포넌트라 할 수 있습니다.
왓차 웹사이트의 개별 콘텐츠 카드왓차를 예로 들면 각각의 콘텐츠 카드에 해당합니다. 텍스트, 썸네일 이미지와 같은 원자 수준의 컴포넌트를 사용해 제작할 수 있습니다.
유기체(Organisms)
분자를 묶어 관리하는 컴포넌트입니다. 입력 폼과 함께 헤더를 감싸거나, 여러 카드를 관리하는 그리드 등을 예로 들 수 있습니다. 유기체부터는 명확히 컴포넌트의 사이즈를 설명하기는 어렵습니다. 프로젝트별로 유기체에 해당하는 컴포넌트 단위는 다를 수 있고, 이를 유기체 단위가 아닌 더 상위 컴포넌트라 할 수 있는 템플릿과 페이지로 관리할 수도 있습니다.
왓차에서 유기체에 해당하는 컴포넌트는 카드 그리드라 할 수 있습니다.
템플릿(Templetes)
템플릿은 여러 유기체가 모여있고, 페이지보다는 낮은 단위입니다. 왓차에서 예를 들어보자면 다음과 같습니다.
여러 카드 그리드를 묶어 하나의 템플릿 컴포넌트를 만들 수 있습니다. 물론 이를 템플릿으로 묶어 관리해도 되고, 페이지에서 직접 카드 그리드를 호출해 제작할 수도 있습니다.
위에서 설명한 아토믹 디자인 패턴을 실제 디렉터리와 파일로 구현하면 다음과 같습니다.
각각의 컴포넌트의 계층 구조를 판단하기도 쉽고 알아보는 것도 쉽습니다. 심지어 디렉토리명이 A, M, O, T로 영어 순서에 맞아서 직관적으로 아래 디렉터리로 갈수록 상위 컴포넌트가 됩니다.(실제로 도움이 됩니다)
아토믹 디자인 패턴의 단점
아직까지 방법론과 장점을 설명했다면 단점도 이야기를 해봐야겠죠. 당연히 모든 개발 방법론 중 정답은 없기에 아토믹 디자인에도 아쉬운 점은 존재합니다. 대표적으로 컴포넌트 간 의존성과 복잡도가 생각보다 까다로울 수 있습니다.
예를 들어 디자인 팀에서 "헤더 중 일부를 변경해 앵커(Anchor)로 동작되도록 해주세요."라고 합시다. 이때 보통 개발자는 두 가지 선택지 중 하나를 선택합니다.
1. 헤더 컴포넌트에 props 등을 추가로 넣어 앵커 기능도 가능하도록 한다.
2. 앵커가 포함된 해커 컴포넌트를 새로 만든다.
1번을 택하는 경우 헤더보다 상위 컴포넌트를 조금만 수정해주면 끝나게 됩니다. 하지만 어떤 이유에서인지 2번으로 진행하게 되면 컴포넌트 코드를 모두 대체하게 됩니다. 이런 요청이 한 번이면 크게 문제가 안될 겁니다. 하지만 이런 요청이 계속 발생한다면 어떨까요? 아토믹 디자인에서 원자에 해당하는 컴포넌트가 파편화되고, 난잡해지는 결과가 생길 수 있습니다. 그러면 결국 수 많은 원자 컴포넌트가 각각 어떤 기능을 하는지 명확히 구분하기 어려워집니다.
아토믹 디자인은 어느 정도의 변화 또는 대형 변화에는 최적화된 패턴이라 할 수 있습니다. 그러나 변화가 누적되면서 각각을 구성하는 컴포넌트가 많아질 때는 답이 없습니다. 심지어 컴포넌트 간 의존성이 상하로 발생하기 때문에 하위 컴포넌트에서 예상치 못한 에러가 발생하게 되면 모든 상위 컴포넌트가 엉망이 되는 일이 생기게 됩니다.
이를 위해서는 원자 단위를 보수적으로 관리할 필요가 있고, 이벤트 핸들링에 대해서는 수동적으로 관리할 필요가 있습니다. 또한 입력 필드와 같이 데이터를 처리하는 값에 대해선 원자 단위보다는 한 단계 위인 분자 수준의 컴포넌트에서 관리하는 게 방어적 프로그래밍이 될 수 있습니다.
웹 개발, 블록체인 컨트렉트 개발 문의: https://flexweb.io
