Atomic Design과 FSD 비교: Todo 예제로 보는 구조 차이

프론트엔드 구조를 고민하다 보면 Atomic Design과 FSD(Feature-Sliced Design)를 자주 만나게 됩니다. 둘 다 코드 구조를 정리하는 데 도움이 되지만, 실제로는 같은 문제를 해결하는 방식이 아닙니다.

Atomic Design은 UI를 작은 단위에서 큰 단위로 조합하는 데 강하고, FSD는 기능과 도메인 기준으로 구조를 나누는 데 강합니다. 그래서 둘 중 무엇이 더 좋다기보다, 지금 프로젝트에서 어떤 문제가 더 큰가에 따라 선택이 달라집니다.

이 글에서는 먼저 같은 Todo 화면을 두 방식으로 비교해보고, 그 다음 리빌딩 프로젝트에서 Atomic Design에서 FSD로 전환했던 실무 사례를 기준으로 왜 구조를 바꾸게 되었는지 정리해보겠습니다.

같이 보면 좋은 글:

먼저 한 줄로 비교하면

Atomic Design: UI를 작은 컴포넌트에서 큰 화면으로 조합하는 방식
FSD: 기능과 도메인을 책임과 의존성 기준으로 분리하는 방식

대략적으로 한눈에 보면 이렇습니다.

항목	Atomic Design	FSD
중심 질문	이 컴포넌트는 얼마나 작은가?	이 코드는 어떤 기능과 도메인에 속하는가?
분류 기준	UI 크기와 조합 단계	기능, 도메인, 책임, 의존성
대표 구조	`atoms > molecules > organisms > templates > pages`	`shared > entities > features > widgets > pages > app`
수정할 때 찾는 기준	이 UI가 어느 단계 컴포넌트인가?	이 요구사항이 어느 기능과 도메인인가?
잘 맞는 상황	디자인 시스템, UI 재사용성 중심 프로젝트	기능 규모가 크고 협업 범위가 넓은 프로젝트
강점	화면 구조와 컴포넌트 재사용 정리가 쉬움	기능 수정 범위와 코드 위치가 명확해짐
아쉬운 점	상태, API, 비즈니스 로직 구조 설명에는 약함	처음엔 구조가 다소 낯설고 과해 보일 수 있음

빠르게 정리하면, UI 재사용성과 디자인 시스템 정리가 먼저면 Atomic Design이 잘 맞고, 기능 복잡도와 협업 범위 정리가 먼저면 FSD가 더 잘 맞습니다.

결국 Atomic Design은 컴포넌트 관점, FSD는 기능과 도메인 관점이라고 보면 이해가 쉽습니다.

무엇을 기준으로 나누는가?

두 구조를 헷갈리는 가장 큰 이유는 "둘 다 폴더 구조 이야기처럼 보이기 때문"입니다. 하지만 실제로는 기준점이 다릅니다.

Atomic Design은 UI를 단계적으로 쌓아 올린다

Atomic Design은 보통 아래 흐름으로 설명합니다.

flowchart TD
    atoms[Atoms] --> molecules[Molecules]
    molecules --> organisms[Organisms]
    organisms --> templates[Templates]
    templates --> pages[Pages]

즉:

atom: 버튼, 인풋, 체크박스 같은 작은 UI
molecule: 인풋 + 버튼 같은 작은 조합
organism: 리스트, 툴바, 카드 영역 같은 큰 블록
template: 페이지 구조
page: 실제 데이터가 들어간 최종 화면

핵심은 "이 UI가 어느 정도 크기와 의미를 가지는가"입니다.

FSD는 책임과 의존성을 기준으로 나눈다

FSD는 보통 아래 흐름으로 이해합니다.

flowchart TD
    appLayer[app] --> pagesLayer[pages]
    pagesLayer --> widgetsLayer[widgets]
    widgetsLayer --> featuresLayer[features]
    featuresLayer --> entitiesLayer[entities]
    entitiesLayer --> sharedLayer[shared]

즉:

shared: 공통 UI, 유틸, 설정
entities: Todo, User 같은 도메인 모델
features: 추가, 삭제, 필터 변경 같은 사용자 액션
widgets: 화면에서 의미 있는 큰 블록
pages: 라우트 단위 화면
app: 앱 진입점과 전역 설정

핵심은 "이 코드가 어떤 기능과 도메인에 속하고, 어디까지를 알아야 하는가"입니다.

같은 Todo 화면을 두 방식으로 보면

비교가 가장 쉬운 예시는 Todo 화면입니다. 아래 정도의 요구사항이 있다고 가정해보겠습니다.

Todo 입력
Todo 목록 조회
완료/미완료 토글
상태 필터
남은 Todo 개수 표시

같은 화면이라도 Atomic Design과 FSD는 보는 기준이 다릅니다.

flowchart TD
    todoApp[TodoApp] --> atomicView[AtomicDesign]
    todoApp --> fsdView[FSD]
    atomicView --> atomicUnits[AtomToPage]
    fsdView --> fsdUnits[SharedToApp]

Atomic Design으로 보면

Atomic Design에서는 보통 이렇게 생각할 수 있습니다.

src/
  components/
    atoms/
      button.tsx
      input.tsx
      checkbox.tsx
    molecules/
      todo-input-form.tsx
      todo-filter-tabs.tsx
      todo-list-item.tsx
    organisms/
      todo-toolbar.tsx
      todo-list.tsx
      todo-summary.tsx
    templates/
      todo-page-template.tsx
    pages/
      todo-page.tsx

이 구조의 장점은 분명합니다.

버튼, 인풋, 체크박스 같은 작은 UI가 어디 있는지 명확함
작은 조합과 큰 블록을 단계적으로 쌓아 올리기 쉬움
디자인 시스템과 연결하기 좋음

반면 여기서는 "Todo 추가 기능은 어디에 있지?"보다 "이 컴포넌트가 molecule인가 organism인가?"가 먼저 보이기 쉽습니다.

FSD로 보면

FSD에서는 같은 Todo 화면을 이렇게 볼 수 있습니다.

src/
  pages/
    todos/
      ui/
        todos-page.tsx
  widgets/
    todo-list/
    todo-toolbar/
    todo-summary/
  features/
    add-todo/
    toggle-todo/
    filter-todos/
  entities/
    todo/
      api/
      model/
      ui/
  shared/
    ui/
    api/

여기서는 질문이 달라집니다.

Todo라는 도메인은 어디에 있지?
Todo 추가 기능은 어디에 있지?
필터 기능을 수정하려면 어디를 보면 되지?

즉, FSD는 화면이 아니라 기능 수정 포인트를 빠르게 찾는 구조에 더 가깝습니다.

Todo 예제로 보면 어떤 차이가 더 크게 느껴질까?

Todo 화면에서 두 구조의 차이는 아래처럼 정리할 수 있습니다.

1. `TodoInputForm`

Atomic Design에서는 input + button 조합이라서 보통 molecule로 보기 쉽습니다.

FSD에서는 "Todo를 추가하는 사용자 액션"이므로 features/add-todo로 보는 것이 자연스럽습니다.

즉:

Atomic Design: 조합된 UI인가?
FSD: 어떤 기능인가?

라는 차이가 있습니다.

2. `TodoListItem`

Atomic Design에서는 크기와 조합 정도에 따라 molecule이나 organism으로 볼 수 있습니다.

FSD에서는 Todo를 표현하는 도메인 UI라면 entities/todo/ui에 둘 가능성이 큽니다.

즉, Atomic Design은 UI 계층으로 보고, FSD는 도메인 소속으로 봅니다.

3. `TodoToolbar`

Atomic Design에서는 보통 큰 화면 블록이므로 organism입니다.

FSD에서는 add-todo, filter-todos 같은 feature를 조합하는 widget으로 볼 수 있습니다.

4. 전체 페이지

Atomic Design에서는 template와 page를 나눠서 페이지 구조와 실제 데이터를 구분합니다.

FSD에서는 pages/todos가 라우트 단위 화면을 담당하고, 내부에서 widgets, features, entities를 조합합니다.

그래서 둘 중 무엇이 더 좋을까?

작은 예제에서는 Atomic Design도 충분히 잘 동작합니다. 특히 디자인 시스템이 중요하고 UI 재사용성이 핵심이라면 Atomic Design이 직관적입니다.

하지만 프로젝트가 커질수록 구조를 바라보는 질문이 조금씩 바뀝니다.

이 컴포넌트는 molecule인가 organism인가?
이 기능을 수정하려면 어느 파일들을 같이 봐야 하지?
검색 기능 전체는 어디에 모여 있지?
상태 변경 로직은 왜 page와 hook과 api에 흩어져 있지?

이 시점부터는 UI 계층만으로는 부족하고, 기능과 도메인 중심 구조가 더 필요해집니다.

리빌딩 실무 사례: 왜 Atomic에서 FSD로 옮겼을까?

실무에서 구조 전환이 필요해졌던 시점도 비슷했습니다.

처음 리빌딩을 시작했을 때는 화면을 빠르게 정리해야 했고, 재사용 가능한 UI를 만드는 일이 중요했습니다. 그래서 Atomic Design 기준으로 atoms, molecules, organisms를 나누는 방식이 잘 맞았습니다.

초기에는 장점이 분명했습니다.

공용 버튼, 인풋, 모달 같은 UI를 빠르게 정리할 수 있었고
화면 블록을 작은 단위로 나누면서 중복 UI를 줄이기 쉬웠고
디자이너와도 공통 언어를 만들기 편했습니다

문제는 운영 화면이 커지면서 시작됐습니다.

하나의 화면 안에 아래 같은 흐름이 함께 들어오기 시작했습니다.

목록 조회
검색과 상태 필터
정렬 변경
상세 패널 열기
수정 모달
권한별 버튼 노출
API 호출
캐싱과 상태 동기화

이 단계에서는 화면을 작은 UI 조합으로만 보는 것보다, 기능 단위로 묶는 것이 더 중요해졌습니다.

예를 들어 "상태 필터를 수정한다"는 요구사항이 들어오면 실제 코드는 여러 곳에 흩어져 있었습니다.

organism 안의 탭 UI
page에서 관리하는 상태
별도 hook
API 요청 파라미터
검색 조건을 만드는 유틸

UI는 잘 나뉘어 있었지만, 기능 수정 포인트는 한곳에 모여 있지 않았습니다.

협업에서도 비슷한 문제가 있었습니다. 팀 기준으로는 "이 molecule을 누가 맡는가?"보다 "검색 기능 전체를 누가 맡는가?"가 더 중요했는데, Atomic Design만으로는 이 경계를 설명하기가 어려웠습니다.

그래서 리빌딩 과정에서 구조를 다시 볼 때, 질문 자체를 바꾸게 됐습니다.

이제는 "이 컴포넌트가 얼마나 작은가?"보다 "이 코드는 어떤 기능에 속하는가?", "이 기능은 어떤 도메인에 속하는가?"가 더 중요한 질문이 됐습니다.

이 질문에 더 잘 맞았던 구조가 FSD였습니다.

FSD로 옮기면서 달라진 점은 아래와 같았습니다.

1. 기능 기준으로 코드를 찾기 쉬워졌다

search, filter, update-status 같은 동작이 features 기준으로 보이기 시작하면서, 수정 범위를 더 빨리 좁힐 수 있었습니다.

2. 도메인 기준으로 공통 모델을 묶기 쉬워졌다

entities에 타입, API, 도메인 UI를 묶어두니 화면마다 같은 도메인을 다루는 기준이 더 선명해졌습니다.

3. 협업 범위가 더 자연스러워졌다

한 명은 features/filter-*, 다른 한 명은 entities/*, 또 다른 한 명은 widgets/*를 맡는 식으로 역할을 나누기 쉬워졌습니다.

4. UI와 기능을 분리해서 볼 수 있게 됐다

작은 컴포넌트를 만드는 문제와, 기능을 어디에 둘지 정하는 문제가 분리되면서 구조 판단이 더 쉬워졌습니다.

그렇다고 Atomic Design이 필요 없어진 걸까?

그렇지는 않습니다. 실무에서는 둘을 완전히 대체 관계로 보기보다, 서로 다른 층위의 기준으로 같이 가져가는 경우도 많습니다.

예를 들면:

앱 전체 구조는 FSD로 가져가고
shared/ui 안의 공용 컴포넌트는 Atomic Design 관점으로 정리할 수 있습니다

즉:

Atomic Design은 UI를 잘게 나누는 기준
FSD는 앱 전체 구조를 기능과 도메인 기준으로 정리하는 기준

으로 함께 쓸 수 있습니다.

언제 Atomic Design이 잘 맞을까?

다음과 같은 경우에는 Atomic Design이 특히 잘 맞습니다.

디자인 시스템을 함께 운영하는 프로젝트
컴포넌트 재사용성이 매우 중요한 프로젝트
화면 구조와 UI 계층을 먼저 정리해야 하는 프로젝트
기능 복잡도보다 UI 일관성이 더 중요한 경우

언제 FSD가 더 잘 맞을까?

다음과 같은 경우에는 FSD가 더 설득력 있습니다.

기능 규모가 빠르게 커지는 서비스
API, 상태, 비즈니스 로직이 함께 복잡해지는 프로젝트
협업 단위를 기능 기준으로 나누고 싶은 팀
리빌딩이나 점진적 구조 개선이 필요한 프로젝트

정리하면

Atomic Design과 FSD는 경쟁 관계라기보다, 문제를 바라보는 기준이 다른 구조입니다.

Atomic Design은 UI 계층을 설명하는 데 강하고
FSD는 기능과 도메인 구조를 설명하는 데 강합니다

리빌딩 경험을 기준으로 보면, 초기에는 Atomic Design이 UI를 정리하는 데 도움이 됐지만, 프로젝트 복잡도가 올라갈수록 FSD가 더 설득력 있는 선택이었습니다.

중요한 것은 유행하는 구조를 고르는 것이 아니라, 지금 프로젝트에서 가장 자주 부딪히는 문제를 해결해주는 구조를 고르는 것입니다.

카테고리

자주쓰는 태그

Atomic Design과 FSD 비교: Todo 예제로 보는 구조 차이

먼저 한 줄로 비교하면

무엇을 기준으로 나누는가?

Atomic Design은 UI를 단계적으로 쌓아 올린다

FSD는 책임과 의존성을 기준으로 나눈다

같은 Todo 화면을 두 방식으로 보면

Atomic Design으로 보면

FSD로 보면

Todo 예제로 보면 어떤 차이가 더 크게 느껴질까?

1. `TodoInputForm`

2. `TodoListItem`

3. `TodoToolbar`

4. 전체 페이지

그래서 둘 중 무엇이 더 좋을까?

리빌딩 실무 사례: 왜 Atomic에서 FSD로 옮겼을까?

1. 기능 기준으로 코드를 찾기 쉬워졌다

2. 도메인 기준으로 공통 모델을 묶기 쉬워졌다

3. 협업 범위가 더 자연스러워졌다

4. UI와 기능을 분리해서 볼 수 있게 됐다

그렇다고 Atomic Design이 필요 없어진 걸까?

언제 Atomic Design이 잘 맞을까?

언제 FSD가 더 잘 맞을까?

정리하면

같이 보면 좋은 글

Marco Lee@beta1360

태그

댓글

먼저 한 줄로 비교하면

무엇을 기준으로 나누는가?

Atomic Design은 UI를 단계적으로 쌓아 올린다

FSD는 책임과 의존성을 기준으로 나눈다

같은 Todo 화면을 두 방식으로 보면

Atomic Design으로 보면

FSD로 보면

Todo 예제로 보면 어떤 차이가 더 크게 느껴질까?

1. TodoInputForm

2. TodoListItem

3. TodoToolbar

4. 전체 페이지

그래서 둘 중 무엇이 더 좋을까?

리빌딩 실무 사례: 왜 Atomic에서 FSD로 옮겼을까?

1. 기능 기준으로 코드를 찾기 쉬워졌다

2. 도메인 기준으로 공통 모델을 묶기 쉬워졌다

3. 협업 범위가 더 자연스러워졌다

4. UI와 기능을 분리해서 볼 수 있게 됐다

그렇다고 Atomic Design이 필요 없어진 걸까?

언제 Atomic Design이 잘 맞을까?

언제 FSD가 더 잘 맞을까?

정리하면

같이 보면 좋은 글

Marco Lee@beta1360

태그

댓글

1. `TodoInputForm`

2. `TodoListItem`

3. `TodoToolbar`