Atomic Design vs FSD 비교: UI 계층과 도메인 계층을 함께 설계하는 기준

Atomic Design vs FSD 비교: UI 계층과 도메인 계층을 함께 설계하는 기준

Atomic Design은 UI 재사용성 중심, FSD는 비즈니스 책임 분리 중심이라는 차이가 있다. 실무에서는 둘 중 하나를 버리기보다 서로 다른 축으로 결합하는 방식이 효과적이다. 검색 유입이 많은 키워드(폴더 구조, 마이그레이션, 안티패턴, 상태관리)를 기준으로 실무 적용 포인트를 정리했다.

FSD 공식 사이트 참조 이미지 (출처: feature-sliced.design)

핵심 개념

실무에서 먼저 결정할 기준

이 주제는 코드 배치 기준을 먼저 정하고, 이후 네이밍과 import 경계를 린트로 고정하는 순서가 가장 안정적이다.

핵심 요소 3~6개

항목	의미	언제 쓰는지(실무 상황)
Atomic Design	UI 조합 규칙(Atom~Page)	디자인 시스템 컴포넌트 재사용률을 높일 때
FSD	도메인 책임 기반 구조화	기능 확장 시 변경 영향 범위를 통제할 때
결합 전략	UI는 shared/ui, 기능은 features로 분리	디자인 일관성과 도메인 독립성을 동시에 확보할 때
경계 기준	스타일/표현 vs 상태/비즈니스	코드리뷰에서 책임 혼합 여부를 판단할 때
도입 순서	Atomic 기초 후 FSD 레이어 도입	기존 UI 라이브러리가 이미 있는 팀에서 전환할 때

예시 코드

shared/ui/Button.tsx  // Atomic 성격
features/auth/sign-in/model/use-sign-in.ts  // FSD 성격
features/auth/sign-in/ui/sign-in-form.tsx

문제 상황 1개

상황: 디자인 시스템 컴포넌트는 잘 만들어졌지만 기능 로직이 여기저기 퍼져 유지보수가 어렵다.
원인: UI 계층만 정리했고 도메인 계층 규칙이 없었다.
해결: UI 컴포넌트는 shared/ui로 고정하고, 기능 로직은 features/entities로 이동해 책임을 분리한다.
예방 팁: PR에서 UI 변경과 도메인 변경이 한 파일에 섞였는지 체크리스트로 검증한다.

참고/출처

공식 자료: Atomic Design
공식 문서: FSD Overview
신뢰 자료: React Docs - Thinking in React