CDD(Component-Driven Development)

DONG EUN LEE·2026년 2월 15일

AtomicDesign React cdd frontend 바이브코딩

컴포넌트 주도 개발(CDD)

목록 보기

1/1

Component-Driven Development 란?

Component-Driven Development(CDD)는 UI 컴포넌트 단위로 설계·개발·검증하는 개발 방식을 말한다.

화면을 먼저 만들고, 나중에 쪼개는 방식 ❌
작은 UI 컴포넌트를 먼저 만들고 조합해서 화면을 구성하는 방식 ✅

마치 레고 블록을 하나씩 조립해서 거대한 성을 만드는 것

CDD 를 사용했을때 장점은 ?

재사용성 : 중복 코드 최소화
독립적 개발 : 데이터가 준비되어있지 않아도 UI를 미리 만들고 테스트가 가능
유지보수 용이 : 특정 요소의 스타일을 바꾸어야 할때, 해당 컴포넌트만 수정하여 전체 서비스에 적용

기존방식(Page-Driven) vs CDD 방식

구분	기존 방식 (Page-Driven)	CDD (Component-Driven)
접근 방식	Top-Down (페이지 → 컴포넌트)	Bottom-Up (컴포넌트 → 페이지)
작업 단위	페이지(Page) 중심	컴포넌트(Component) 중심
의존성	데이터 구조에 의존적	UI 자체의 독립성 강조

기존방식 코드

// MainDashboard.jsx (페이지 중심)
function MainDashboard() {
  return (
    <div className="dashboard-container">
      {/* 검색 바 영역: 페이지 안에서 직접 정의 */}
      <header style={{ display: 'flex', padding: '10px' }}>
        <input type="text" placeholder="검색어를 입력하세요" style={{ border: '1px solid gray' }} />
        <button style={{ backgroundColor: 'blue', color: 'white' }}>검색</button>
      </header>

      {/* 컨텐츠 영역 */}
      <main>
        <h1>대시보드 메인</h1>
        <p>환영합니다!</p>
      </main>
    </div>
  );
}

CDD 방식의 코드 (Atomic 방식)

1. 가장 작은 단위(Atoms)

// src/components/atoms/Button.jsx
export const Button = ({ label, color }) => (
  <button style={{ backgroundColor: color, color: 'white' }}>{label}</button>
);

// src/components/atoms/Input.jsx
export const Input = ({ placeholder }) => (
  <input type="text" placeholder={placeholder} style={{ border: '1px solid gray' }} />
);

2.원자요소 (Molecules)

// src/components/molecules/SearchBar.jsx
import { Button } from '../atoms/Button';
import { Input } from '../atoms/Input';

export const SearchBar = () => (
  <div style={{ display: 'flex', gap: '5px' }}>
    <Input placeholder="검색어를 입력하세요" />
    <Button label="검색" color="blue" />
  </div>
);

3.Page 에서의 조합

// src/pages/MainDashboard.jsx
import { SearchBar } from '../components/molecules/SearchBar';

function MainDashboard() {
  return (
    <div className="dashboard-container">
      <header>
        <SearchBar /> {/* 조립만 하면 끝! */}
      </header>
      <main>
        <h1>대시보드 메인</h1>
      </main>
    </div>
  );
}

실전 사용 예시: Atomic Design 패턴

저는 CDD를 실천하기 위해 아토믹 디자인(Atomic Design) 패턴을 주로 사용합니다. 이 패턴은 UI를 화학적 단위로 쪼개어 관리합니다.

Atoms(원자): 버튼, 입력창, 라벨처럼 더 이상 쪼갤 수 없는 최소 단위
Molecules(분자): 원자들을 조합한 기능 단위 (예: 검색창 = 입력창 + 버튼)
Organisms(유기체): 분자와 원자를 조합한 복잡한 섹션 (예: 헤더, 내비게이션 바)
Templates(템플릿): 데이터가 없는 레이아웃 구조
Pages(페이지): 실제 데이터가 주입되어 완성된 최종 화면

저는 프로젝트를 진행할 때 Templates까지를 순수한 UI 레벨로 두려고 노력합니다. 예외도 있지만..😂
Templates: 데이터가 어떻게 보여야 하는지, 컴포넌트들이 어디에 배치되어야 하는지 등 'UI 구조'만을 담당합니다. (Props로 데이터를 받기만 함)
Pages: 실제 API 호출, 상태 관리(State), 데이터 가공 등의 '비즈니스 로직'을 담당하여 그 결과를 Template으로 전달합니다.

마무리

요즘은 AI 도구를 활용한 '바이브 코딩(Vibe Coding)'이 대세가 되면서, 명령어 한 줄로 페이지 전체를 뚝딱 만들어낼 수 있는 시대가 되었습니다. 저 또한 AI에 의존하다 보니, 어느덧 차근차근 컴포넌트를 설계하던 CDD의 원칙을 조금씩 소홀히 하고 있지는 않았나 하는 반성을 하게 됩니다..😭
AI는 당장 돌아가는 '통코드'를 짜주는 데는 능숙하지만, 그 코드가 우리 프로젝트의 구조에 맞는지, 재사용성이 고려되었는지까지 완벽하게 챙겨주지는 못합니다. 결국 AI로 작업할수록 결과물은 빠르게 나오지만, 역설적으로 컴포넌트 간의 경계가 모호해지고 유지보수가 어려워지는 '기술 부채'가 쌓이는 기분도 듭니다.

이번 포스팅을 정리하며 다시금 다짐해 봅니다.

"AI는 강력한 엔진이지만, 설계도(CDD/Atomic Design)를 그리는 것은 여전히 개발자의 몫이다."

그래서 앞으로는 AI와 협업할 때 나만의 'CDD 가이드라인'을 더 명확히 전달해 보려 합니다. 예를 들어, AI에게 코딩 룰을 설정할 때 "모든 UI는 아토믹 패턴에 따라 구현해 줘"라거나 "Templates와 Pages의 책임을 엄격히 분리해 줘" 같은 프롬프트를 활용하는 것이죠

속도에 매몰되어 CDD의 본질을 놓치기보다, AI를 활용해 더 정교한 컴포넌트를 더 빠르게 만드는 방식으로 나아가야 할 것 같습니다.

CDD를 정리하다보니 Storyboo이라는 도구를 알게되었습니다. 이것도 한번 사용해보고, 포스팅을 해보고자 합니다.

DONG EUN LEE