컴포넌트 주도 개발(CDD)을 도입해보면 어떨까? (feat: 디자인시스템 라이브러리 & 스토리북)

Component-Driven Development(CDD)란?

Component-Driven Development(CDD)는 컴포넌트를 중심으로 애플리케이션을 개발하는 방식이다. 화면을 구성하는 작은 단위의 UI 컴포넌트를 먼저 개발하고, 이를 조합해 전체 애플리케이션을 완성한다. 각 컴포넌트의 역할과 책임이 명확해지며 UI의 복잡성을 줄일 수 있다.

 

특징

1. 컴포넌트 중심 설계: 작은 단위의 UI 컴포넌트를 먼저 설계하고 구현한다.
2. 재사용성: 컴포넌트는 다양한 페이지에서 재사용 가능하다.
3. 독립적인 테스트: 컴포넌트 단위로 테스트를 작성해 개별 동작을 확인한다.
4. 디자인 시스템과의 통합: 디자인 시스템과 통합이 용이하여 일관된 UI를 유지한다.

 

 

장점

효율적인 컴포넌트 관리
각 프로젝트마다 동일한 UI 컴포넌트를 반복해서 개발하게 된다. 이는 개발 시간의 낭비뿐만 아니라, 코드의 일관성을 해치고 중복 코드를 유발하는 주요 원인이다.CDD 환경을 구축함으로써, 공통된 컴포넌트를 중앙에서 관리하고 재사용할 수 있다. 이는 개발 효율성을 극대화하고, 코드의 유지보수를 용이하게 만든다. 또한, 컴포넌트를 모듈화하여 관리함으로써, 새로운 기능 추가 시 기존 코드를 손쉽게 확장할 수 있게 된다.

일관된 사용자 경험 제공
CDD는 일관된 사용자 경험을 제공하는 데 중요한 역할을 한다. 모든 프로젝트에서 동일한 디자인 언어와 상호작용 패턴을 사용함으로써, 사용자는 일관된 경험을 할 수 있다. 이는 브랜드 신뢰성을 높이고, 사용자 만족도를 향상시키는 데 기여한다. 작은 팀에서는 특히 일관성을 유지하는 것이 더 어려울 수 있는데, CDD 환경을 통해 이를 체계적으로 관리할 수 있다.

기술적 일관성 확보
다양한 프로젝트에서 동일한 기술 스택과 패턴을 사용하지 않으면, 코드의 일관성이 떨어져 유지보수가 어려워진다. CDD 환경을 도입하면, 모든 컴포넌트가 동일한 기술적 기준을 따르게 되어, 코드의 일관성을 유지할 수 있다. 이는 새로운 팀원이 프로젝트에 합류할 때, 빠르게 코드베이스를 이해하고 적응할 수 있게 도와준다. 또한, 기술적 부채를 줄이고, 장기적인 프로젝트의 안정성을 높이는 데 기여한다.

유지보수 비용 절감
공통된 디자인시스템을 사용하면, 컴포넌트의 유지보수가 용이해진다. 컴포넌트에 버그가 발생하거나 기능을 추가해야 할 때, 중앙 라이브러리에서 한 번 수정하면 모든 프로젝트에 자동으로 반영되기 때문에, 개별 프로젝트에서의 수정 작업이 필요 없어진다. 이는 유지보수 비용을 절감하고, 개발자의 시간을 보다 효율적으로 사용할 수 있게 한다.

팀 간 협업 강화
공통된 디자인시스템은 개발자와 디자이너 간의 협업을 강화한다. 디자이너는 중앙화된 디자인 가이드를 제공함으로써, 개발자가 이를 기반으로 안정적이고 예측 가능한 컴포넌트를 개발할 수 있게 한다. 이는 소통의 단절을 줄이고, 디자인 의도를 정확히 반영하는 데 도움을 준다. 또한, 팀 간의 협업이 원활해지면서 프로젝트의 품질과 효율성이 동시에 향상된다.

 

 

단점

복잡한 관리 
컴포넌트가 많아지면 관리가 복잡해질 수 있다.

초기 비용
컴포넌트 구조 설계에 초기 시간이 많이 소요된다.

 

CDD는 특히 React와 같은 컴포넌트 기반 라이브러리와 잘 맞아 프론트엔드 개발자들 사이에서 널리 사용된다.

 

---

 

그럼 CDD는 어떤 상황에 사용해야 좋을까? 

CDD 도입이 효율적인 상황

1. 복잡한 UI 구성: 애플리케이션의 UI가 복잡하거나 다양한 UI 패턴을 재사용해야 할 때 CDD가 유용하다. 각 UI 요소를 독립적인 컴포넌트로 만들어 관리하면 개발과 유지보수가 편리해진다.
2. 일관성 있는 디자인이 필요한 경우: 여러 페이지에 걸쳐 일관된 디자인이 필요할 때 CDD를 사용하면, 디자인 시스템을 통해 컴포넌트를 재사용할 수 있어 디자인 일관성을 쉽게 유지할 수 있다.
3. 협업이 많은 프로젝트: 디자이너, 개발자, QA 팀 간 협업이 잦은 경우 CDD가 효과적이다. 각 컴포넌트가 독립적으로 개발되고 테스트되기 때문에 커뮤니케이션이 용이하고 수정 및 검토도 빠르다.
4. 테스트와 유지보수가 중요한 프로젝트: 각 컴포넌트의 단위 테스트가 가능하므로, 안정성과 품질이 중요한 프로젝트에서 CDD를 도입하면 유지보수가 수월해진다.

 

CDD 도입이 비효율적인 상황

1. 작거나 단순한 프로젝트: 컴포넌트 구조 설계와 테스트를 위한 초기 비용이 큰 만큼, 간단한 UI만 필요한 소규모 프로젝트에서는 오히려 개발 시간이 길어질 수 있다.

2. 빠른 프로토타입이 필요한 경우: 빠르게 MVP(최소 기능 제품)를 개발해야 하는 경우 CDD는 비효율적일 수 있다. 컴포넌트를 세분화하는 작업이 시간 소모적일 수 있어, 빠른 개발이 중요할 때는 단순한 코드 구조가 유리하다.

3. 컴포넌트 재사용 가능성이 낮은 프로젝트: 한 번 사용되고 끝나는 컴포넌트가 많다면 CDD로 인한 재사용의 장점이 크지 않다. 이 경우 CDD를 적용하는 것이 비효율적일 수 있다.

4. 일회성 페이지 개발: 이벤트나 특정 마케팅 페이지와 같이 일회성으로 사용되는 경우, 세분화된 컴포넌트를 관리하기보다는 단순한 구조로 개발하는 것이 효율적이다.

 

CDD는 UI의 복잡성과 재사용성을 높이려는 프로젝트에서 큰 장점이 있지만, 모든 프로젝트에 적합한 것은 아니다. 프로젝트의 목적과 범위를 고려해 CDD를 적용하는 것이 중요하다.

 

 

---

그럼 어떻게 CDD 환경을 구축할 수 있을까?

Component-Driven Development(CDD) 환경을 구축할 때, 대표적인 접근 방식으로 모노레포(Monorepo)와 디자인 시스템 라이브러리를 고려할 수 있었다. 두 방식은 모두 공통 컴포넌트를 관리하고 재사용을 극대화한다는 공통점이 있지만, 각 방식은 상황에 따라 적합성이 다르다.

 

모노레포 vs. 디자인 시스템 라이브러리

모노레포(Monorepo)는 여러 프로젝트를 하나의 리포지토리에서 관리하는 방식이다. 모든 프로젝트가 같은 리포지토리에 있기 때문에 공통 컴포넌트를 쉽게 관리할 수 있고, 변경 사항이 즉시 전체 프로젝트에 반영된다. 모노레포 방식의 장점은 다음과 같다:

 

• 일관된 코드베이스: 모든 프로젝트가 동일한 코드베이스 내에 있어 공통 코드의 일관성을 유지할 수 있다.

• 통합된 버전 관리: 공통 컴포넌트와 모듈에 대해 한 번에 버전 관리를 할 수 있어, 코드베이스의 업데이트를 일괄적으로 적용하기에 용이하다.

• 자동화와 통합 빌드: 테스트, 배포 등 자동화된 파이프라인을 구축할 때 모든 프로젝트에 공통 규칙을 적용할 수 있어 효율적이다.

 

그러나 모노레포는 모든 프로젝트가 하나의 리포지토리에 포함되는 방식이기 때문에, 프로젝트가 많아질수록 리포지토리가 복잡해지고 빌드 시간이 길어질 수 있다. 또한, 각 프로젝트가 이미 독립적인 리포지토리로 운영되고 있는 경우, 모노레포로 전환하려면 기존 프로젝트 구조를 통합해야 하는 큰 리소스가 필요하다.

 

 

디자인 시스템 라이브러리는 여러 프로젝트에 걸쳐 일관된 UI를 유지하면서 독립적으로 관리할 수 있는 컴포넌트를 모아놓은 라이브러리다. 디자인 시스템 라이브러리의 장점은 다음과 같다:

 

• 독립적 관리: 각 프로젝트가 독립된 리포지토리에서 운영되더라도, 디자인 시스템 라이브러리를 통해 공통 컴포넌트를 사용함으로써 일관된 UI를 제공할 수 있다.

• 재사용성 극대화: 중앙 라이브러리에서 공통 컴포넌트를 관리하므로, 중복 없이 일관된 스타일과 동작을 유지할 수 있다.

• 유지보수와 업데이트 용이: 디자인 시스템 라이브러리를 통해 수정이 필요한 컴포넌트의 업데이트가 이루어지면, 이 업데이트가 각 프로젝트에 자동으로 반영되어 유지보수 비용이 절감된다.

 

따라서 우리 회사는 이미 여러 프로젝트가 독립적인 리포지토리로 개발되고 있는 상황이기 때문에, 모든 프로젝트를 하나의 리포지토리로 통합하는 모노레포 방식은 큰 리소스가 필요하고 운영상의 복잡성을 증가시킬 우려가 있다. 반면, 디자인 시스템 라이브러리를 통해 각 프로젝트에 일관된 UI 컴포넌트를 제공하고, 변경 사항을 중앙에서 관리할 수 있다는 점에서 효율적이다.

 

선택한 방법: 디자인 시스템 라이브러리와 스토리북의 조합

디자인 시스템 라이브러리 구축을 위한 도구로 스토리북(Storybook)을 선택했다. 스토리북은 각 컴포넌트를 독립적으로 개발하고 미리보기할 수 있는 환경을 제공하며, 컴포넌트를 문서화하고 상호작용을 테스트하는 데 최적화되어 있다. 스토리북을 사용함으로써 얻을 수 있는 주요 이점은 다음과 같다:

 

• 개별 컴포넌트의 독립적 테스트: 스토리북은 개발자가 각 컴포넌트를 독립적으로 개발하고 미리보기할 수 있는 환경을 제공하여, 컴포넌트가 기대한 대로 동작하는지 쉽게 확인할 수 있게 한다. 이로 인해 개발자는 컴포넌트를 분리된 상태에서 검토하고 빠르게 문제를 수정할 수 있다.

• 디자이너와의 협업 강화: 스토리북은 컴포넌트의 시각적 상태와 상호작용을 명확하게 보여주기 때문에, 디자이너와 개발자가 컴포넌트의 최종 상태를 사전에 검토하고 피드백을 주고받을 수 있다. 이를 통해 디자인 의도를 정확히 반영하고 소통의 단절을 줄여준다.

• 효율적인 문서화: 스토리북은 컴포넌트의 사용 방법과 상태별 동작을 문서화하는 기능을 제공하여, 팀 내에서 공유할 수 있는 간단한 문서화 환경을 마련해준다. 이는 새로운 팀원이 컴포넌트를 빠르게 이해하고 활용하는 데 큰 도움이 된다.

 

디자인 시스템 라이브러리와 스토리북을 조합하여 사용함으로써 컴포넌트를 개발하고 유지보수하는 과정이 더욱 효율적이고 체계적으로 진행된다. 디자인 시스템을 통해 각 프로젝트가 일관된 스타일과 상호작용 패턴을 따르도록 하고, 스토리북을 통해 문서화와 협업을 동시에 해결할 수 있는 환경을 마련하게 된다. 이는 UI 컴포넌트의 일관성을 유지하면서도, 디자이너와 개발자가 원활하게 소통하고 효율적으로 협업할 수 있는 기반이 된다.

---

 

그렇다면 우리 회사의 상황에는 CDD를 도입하는게 맞을까?

우리 회사는 소규모 스타트업으로, 1인 프론트엔드 개발자가 다양한 프로젝트를 동시에 관리하고 있다.

현재 여러 서비스 페이지가 각각 독립적으로 개발되고 있어, 사용자 경험의 일관성을 유지하는 데 어려움이 크다.

이러한 상황에서 Component-Driven Development(CDD)를 도입하는 것은 꽤나 효율적인 방안이라고 생각한다. CDD를 통해 컴포넌트를 중심으로 구조화하고 관리함으로써, 중복된 작업을 줄이고 개발 효율성을 높일 수 있다. 또한, 사내 디자인 시스템을 라이브러리 형태로 구축하여 일관된 UI와 재사용 가능한 컴포넌트를 제공하면, 프로젝트의 유지보수성과 협업 효율성을 크게 향상시킬 수 있다.

 

물론 1인 프론트엔드 개발을 맡고 있는 입장으로서 CDD 환경을 구축하는데에 들어가는 리소스가 크지만, 비용 대비 효율을 생각한다면 충분히 투자해볼 가치가 있다고 생각한다. 더군다나 신규 개발이 계속되는 지금이 가장 빠른 시기일 것이다. 기술 부채가 더 쌓이기 전에 빠르게 도입해 시스템을 체계화시키고자 한다.