디자인 패턴이란?

• 디자인 패턴은 소프트웨어를 설계할 때 자주 마주치는 문제 상황에서 이미 검증된 "모범답안" 또는 "설계 템플릿"입니다.
• 코딩 그 자체가 아니라 문제를 푸는 구조화된 방법, 그리고 그 방법을 쉽게 공유하기 위한 표기법이기도 합니다.
  한마디로 “현실에서 자주 맞닥뜨리는 프로그래밍 설계 이슈의 검증된 해결법/구조” 입니다.

3. 종류

(1) GoF(전통적 소프트웨어 디자인 패턴)

대표: 싱글톤, 팩토리, 옵저버, 전략, 데코레이터, 컴포지트 등 "GoF(Gang of Four)" 의 23개 패턴
주로 클래스·객체 구조, 인스턴스 생성/관계/행위 패턴 등

(2) 프론트엔드/웹 프로젝트 구조 디자인 패턴

브라우저 기반 대형 프로젝트에서 파일·폴더·기능 분리 구조(Atomic, Feature Sliced, Layered, DDD, Ducks 등)

프론트 아키텍처 종류

1. Feature-Sliced Design (FSD)

주요 개념

• 기능(Feature) 단위로 코드를 분리
• 다음과 같이 계층(슬라이스)화
• app: 전체 앱 설정, 라우팅
• processes: 여러 feature를 조합, 프로세스 레벨 단위(예: 로그인 흐름)
• pages: 실제 라우트와 매칭되는 부분, 여러 feature 조립
• features: 하나의 독립된 도메인 기능 (ex: auth, profile, cart 등)
• entities: 핵심 도메인 모델 (user, product 등)
• shared: 재사용 가능한 helpers, ui, lib 등

장점

• 대형 프로젝트에서 협업과 유지보수에 매우 강력
• 계층별 책임 분리가 명확
• 기능/도메인 단위로 확장, 코드재사용성↑

단점

• 작은 프로젝트엔 과도할 수 있음
• 러닝커브가 있음 (처음에는 동료들과 조율 필요)

2. Atomic Design

주요 개념

• UI 컴포넌트를 화학의 "원자 → 분자 → 유기체"처럼 계층적으로 분리
• Atoms: 버튼, 인풋 등 최소 단위
• Molecules: Atoms의 조합(예: SearchForm)
• Organisms: 여러 Molecule로 조합된 복잡 컴포넌트
• Templates: 레이아웃 뼈대, 데이터 없음
• Pages: 실제 데이터를 가진 최상위 단

장점

• 컴포넌트 재사용 극대화
• 디자인 시스템화에 적합
• UI 일관성 유지 용이

단점

• 논리적 분리가 어려울 때 계층화가 애매해질 수 있음
• 실제 비지니스 로직(도메인) 분리엔 약함

3. Domain-Driven Design (DDD) 구조

주요 개념

• 비즈니스 도메인 중심으로 디렉토리를 분리(주제/의도 기반)
• 각 도메인(orders, users 등) 안에 그 도메인 관련된 코드 전부를 넣음 (api, components, helpers, states 등)

장점

• 실제 서비스 요구사항, 팀 조직과 강하게 매칭
• 도메인별 팀운영(마이크로서비스화)에도 용이
• 코드 응집력↑, 외부 노출↓ (캡슐화)

단점

• 도메인 경계를 정하는 데 시간 소요
• 작은 서비스에서는 오히려 복잡할 수 있음

4. Ducks Pattern (Redux 관련 주로 사용)

주요 개념

• Redux store, action type, action creator, reducer를 한 파일(또는 한 폴더)에 그룹핑해서 도메인 단위로 나눔

장점

• 관련 코드가 모두 한 곳에 있어 추적과 유지보수 편리

단점

• 상태관리가 없거나 작으면 굳이 필요없을 수 있음

5. Layered (Layer) Pattern (전통적 3계층 등)

주요 개념

• Presentation(UI)-Business(Data/Usecase)-Persistence(API) 계층별로 분리
• 전통적 Frontend, Backend 모두에 사용
• Next.js에서는 다음처럼도 적용 가능

장점

• 횡단 관심사 분리에 적합 (로그인, 유효성 검증 등)
• 각 레이어마다 책임 명확

단점

• 지나친 레이어 분리는 오히려 복잡도 유발
• 기능 단위 개발에는 적합하지 않을 수도 있음

디자인 패턴이 필요한 이유

1. 반복되는 문제의 효과적 해결 : 이미 검증된 설계 해법(패턴)을 적용하면, 시행착오 없이 효율적으로 문제를 풀 수 있습니다.
2. 코드 재사용성과 확장성 높임 : 패턴은 "재사용할 수 있는 구조"를 만들어 줍니다. 같은 문제에 같은 해법을 적용하면 관리, 기능 추가, 변경이 쉬워집니다.
3. 코드의 일관성 및 유지보수 용이 : 명확히 구조화된 코드는 새로운 팀원이 와도 빠르게 파악할 수 있습니다. 유지보수/버그수정 업무가 쉬워집니다(코드의 약속이 생김).
4. 팀원/개발자 간 '공통 언어' 제공 : “싱글톤”, “옵저버”, “팩토리”, “아토믹 디자인” 등 패턴 이름만 말해도 설계 의도가 즉시 통합니다. 리뷰, 설계 토론, 문서화가 한결 빨라지고 효율적입니다.
5. 복잡성 관리 : 규모가 커질수록, 설계 규칙 없이 만들면 스파게티 코드가 됩니다. 패턴은 복잡성을 분리(Encapsulation)/관리하는 방법을 제공합니다.
6. 테스트와 변경이 쉬운 코드 : 올바른 패턴을 활용하면, 특정 기능·클래스만 독립적으로 교체, 확장, 테스트할 수 있습니다.

요약

디자인 패턴은
① 효과적으로 문제를 해결하고,
② 팀 전체가 공통 언어로 협업/리팩토링/유지보수하며,
③ 코드를 '튼튼하고 확장성 있게' 만들어주는 검증된 설계 약속입니다.

디자인 패턴 결정에 중요한 기준

프로젝트에서 어떤 폴더 구조/디자인 패턴을 사용할지 결정할 때 가장 중요한 기준은 ‘유행’이나 ‘정답’이 아니라, 당신의 프로젝트 상황과 목표/팀 환경에 가장 맞는 구조를 선택하는 것

1. 프로젝트의 규모와 복잡도
2. 팀 구성 및 협업 방식
3. 비즈니스/기능 변화 속도
4. 기술 스택과 호환성
5. 유지보수, 학습/온보딩, 테스트 가능성
6. 재사용성과 확장성
7. 아키텍처 설계 겅험/공통 규약