프론트엔드 디자인 패턴: Atomic Design + FSD 적용기

프롤로그: 협업을 시작하며

처음으로 현업에서 종사하는 여러 프론트엔드 개발자들과 협업을 진행하면서 다양한 프론트엔드 디자인 패턴에 대해 깊이 고민할 기회가 생겼다. 그중에서도 가장 큰 고민은 어떻게 폴더 구조를 정리하고, 컴포넌트를 재사용할 것인가? 였다.

이 과정에서 접하게 된 대표적인 디자인 패턴이 바로 Atomic Design Pattern과 Feature-Sliced Design(FSD) 이다. 이번 글에서는 Atomic Design의 장점과 한계, 그리고 이를 보완하기 위해 FSD와 결합한 방식을 소개하려 한다.

Atomic Design Pattern 적용기

Atomic Design Pattern이란?

Brad Frost가 제안한 UI 설계 방식으로, 컴포넌트를 작은 단위에서 점점 확장하는 방식이다.

UI를 다음 5가지 단계로 구성한다.

1.	Atoms (원자) – 더 이상 쪼갤 수 없는 최소한의 UI 요소 (ex. Button, Input, Typography)
2.	Molecules (분자) – Atom이 조합된 단위 (ex. SearchBar, Dropdown)
3.	Organisms (유기체) – 여러 Molecule이 조합된 UI 블록 (ex. Header, Footer)
4.	Templates (템플릿) – Organism을 배치한 UI 레이아웃
5.	Pages (페이지) – 최종 데이터가 반영된 화면

Atomic Design Pattern 적용 시 폴더 구조

/components
├── atoms
│   ├── Button.tsx
│   ├── Input.tsx
│   ├── Typography.tsx
│
├── molecules
│   ├── Header.tsx
│   ├── Footer.tsx
│   ├── MenuItem.tsx
│
├── organisms
│   ├── Menu.tsx
│
└── templates

이런 구조를 사용하면 컴포넌트를 조합하는 방식이 명확해지고, 재사용성이 높아지는 장점이 있다. 하지만 실제 프로젝트에 적용하면서 몇 가지 한계를 경험했다.

Atomic Design의 한계와 고민

Feature-Sliced Design(FSD)이란?

FSD(Feature-Sliced Design) 은 기능(Feature) 단위로 폴더를 구성하는 방식이다.

•	컴포넌트는 기능 단위로 묶는다.
•	비즈니스 로직, 서비스 로직, UI 컴포넌트를 명확하게 구분한다.
•	페이지별로 독립적인 폴더 구조를 유지하여 유지보수가 쉽다.

Atomic Design + FSD 결합 후 디렉토리 구조

Root
├── public
├── src
│   ├── app
│   │   ├── {page}
│   │   │   ├── layout.tsx
│   │   │   ├── page.tsx
│   │
│   ├── components  # 공통 UI 컴포넌트
│   │   ├── atoms
│   │   │   ├── Button.tsx
│   │   │   ├── Input.tsx
│   │   │   ├── Typography.tsx
│   │   ├── molecules
│   │   ├── organisms
│   │
│   ├── features  # 기능별 관리
│   │   ├── {feature}
│   │   │   ├── components
│   │   │   ├── services
│   │   │   ├── hooks
│   │   │   ├── types
│   │
│   ├── shared  # 유틸, API, 컨텍스트 등
│   │   ├── api
│   │   ├── hooks
│   │   ├── context
│   │   ├── utils

•	Atomic Design은 components 폴더에서 UI 요소를 관리하는 데 적용
•	FSD는 features 폴더에서 기능별로 폴더를 나누어 관리
•	공통적으로 사용하는 로직(hooks, api 등)은 shared 폴더에 배치

적용 후 개선된 점

폴더 구조가 기능 중심으로 정리되어 유지보수가 쉬워졌다.

UI 컴포넌트와 비즈니스 로직을 분리할 수 있었다.

페이지 단위로 기능을 나누면서 개발 속도가 빨라졌다.

고민했던 점

1. Atomic Design을 어디까지 적용할 것인가?

   • Atom/Molecule/Organism으로 나누는 것은 좋은데, 모든 컴포넌트가 Atomic한 것은 아니다.

   • 어떤 기준으로 구분할지 논의가 필요했다.

2. FSD의 Feature 컴포넌트는 어디에 넣어야 할까?

   • features/{feature}/components 안에 넣어야 할까?

   • 아니면 components/organisms로 가야 할까?

   • 결국 독립적인 기능일 경우 features 안에 넣고, 재사용할 UI는 components에 넣기로 결정

3. FSD 적용 후 폴더 depth를 어떻게 제한할 것인가?

   • 너무 깊은 구조를 만들지 않기 위해 최대 3 depth 이하로 제한

   • 예외적으로 스터디 만들기 폼처럼 많은 컴포넌트가 필요한 경우 한 depth 추가

최종 정리 & 회고

Atomic Design과 FSD를 결합한 이유?

•	Atomic Design은 UI 컴포넌트의 재사용성을 높이는 데 효과적
•	FSD는 비즈니스 로직을 기능 단위로 구분하여 유지보수를 쉽게 함
•	두 가지를 조합하면 UI와 기능을 분리하면서도 재사용성을 높일 수 있음

적용하면서 느낀 점

•	Atomic만 적용하면 폴더 구조가 너무 깊어지고 관리가 어려워진다.
•	FSD만 적용하면 재사용성이 떨어질 수 있다.
•	적절한 기준을 정하는 것이 중요하며, 프로젝트의 규모와 특성에 맞춰 유연하게 적용하는 것이 중요하다.