
컴포넌트 주도 개발(Component Driven Development)과 아토믹 디자인(Atomic Design).
이 두 가지 접근 방식을 선택하게 된 이유는?!
컴포넌트 주도 개발(Component Driven Development)과 아토믹 디자인(Atomic Design)은 이번 사이드 프로젝트에서 주요한 개발 패턴으로 적용하게 되었습니다.
이 두 가지 접근 방식을 선택하게 된 이유는 더 효율적이고 유지보수가 용이한 UI 컴포넌트 구조를 만들기 위해서였습니다.
최근 판교 퇴근길 밋업 with 인프런 #06 FE 테스트코드에 참석하면서, 컴포넌트 주도 개발(CDD)과 아토믹 디자인을 적용해보는 것이 현재 프로젝트에서 큰 도움이 될 것이라고 느꼈습니다.
컴포넌트를 중심으로 UI를 개발함으로써 재사용성을 극대화할 수 있겠다는 생각이 들었습니다.
아토믹 디자인은 화면 전체를 큰 단위로 설계하기보다, 재사용 가능한 공통 컴포넌트를 식별해 점진적으로 개발해나가는 방식입니다.
이를 통해 UI 컴포넌트를 독립적으로 관리할 수 있고, 재사용성과 유지보수성을 크게 높일 수 있었습니다.
이 과정에서 CDD와 자연스럽게 연결되기 때문에 컴포넌트 주도 개발을 위한 적합한 디자인 패턴이라는 확신을 얻었습니다.
먼저 피그마로 디자인을 작성한 후, 컴포넌트를 아토믹 디자인의 각 레벨에 따라 분류했습니다. (atomic-design 참고 블로그)
Atomic Design 분류
기본 UI 요소(Atomic Components)
복합 컴포넌트(Molecular Components)
기능 컴포넌트(Functional Components)
레이아웃 컴포넌트(Layout Components)
페이지 레벨 컴포넌트(Page-Level Components)
Storybook은 컴포넌트 주도 개발에서 중앙적인 도구로 사용되었습니다.
Storybook을 통해 공통 컴포넌트의 스토리를 먼저 작성하고, 그 후 실제 컴포넌트를 개발하는 방식으로 진행했습니다. 이러한 스토리 퍼스트 개발 방식은 다음과 같은 이점을 제공했습니다.
이를 통해 다음과 같은 프로세스를 적용했습니다.
컴포넌트 개발 전에 스토리 작성: Storybook에 컴포넌트의 스토리를 먼저 작성하고 그 후에 실제 컴포넌트를 개발하는 방식으로 진행했습니다.
이렇게 함으로써 컴포넌트가 독립적으로 작동하는지, 디자인과 기능이 일치하는지를 사전에 테스트할 수 있었습니다.
테스트 코드와 병행: Vitest를 사용해 Storybook 스토리와 컴포넌트 테스트를 병행했습니다. 이 과정에서 단일 책임 원칙을 적용하여 각 컴포넌트가 하나의 명확한 책임을 가지도록 설계하였습니다.
프로젝트의 확장성을 고려한 컴포넌트 설계가 가능해졌습니다.
이러한 스토리 퍼스트 개발 방식은 여러 이점을 제공했습니다.
컴포넌트 주도 개발의 장점을 많이 느꼈지만, 복합 컴포넌트로 넘어가면서 props 관리가 어려워지는 것을 경험했습니다.
특히 다양한 상태와 기능을 관리해야 할 때는 props의 개수가 많아져 복잡해졌는데, 이를 해결하기 위해서는 props 구조의 명확화와 타입스크립트의 타입 정의가 필수적이라는 점을 배웠습니다.
느낀 단점이 있다면,, props가 많아져서 지저분,,,,한건 기분 탓이 아니겠죠