# [[Design Patterns (디자인 패턴)]]

## 📌 Brief 소Summary
**디자인 패턴(Design Patterns)**은 소프트웨어 개발 과정에서 공통적으로 발생하는 문제들을 해결하기 위해 반복적으로 재사용할 수 있는 표준화된 해결책이자 템플릿입니다 [1]. 이는 개발자들에게 공통의 용어와 소통 기반을 제공하며, 모범 사례(Best Practices)를 강제하여 코드의 가독성과 유지보수성을 높입니다 [2]. 현대 소프트웨어 생태계에서는 프론트엔드(React, Vue)와 백엔드(Django, Spring Boot, NestJS) 각 프레임워크의 철학에 최적화된 형태로 발전하여, 기술 부채를 줄이고 대규모 시스템의 확장성을 확보하는 핵심 전략으로 활용됩니다 [3, 4].

## 📖 Core Content
현대 프레임워크에서 활용되는 실전 디자인 패턴은 기술 스택에 따라 다음과 같이 고도화되어 적용됩니다.

*   **React의 컴포넌트 및 로직 분리 패턴**
    *   **컨테이너와 프레젠테이션 패턴 (Container and Presentational Pattern):** 상태 관리와 데이터 페칭을 담당하는 로직(Container)과, UI 렌더링에만 집중하는 뷰(Presentational)를 물리적으로 분리하여 재사용성과 테스트 용이성을 높입니다 [5].
    *   **복합 컴포넌트 (Compound Components):** HTML의 `<select>`와 `<option>` 태그처럼 여러 하위 컴포넌트가 협력하여 하나의 응집된 UI를 구성하는 패턴입니다 [6]. 부모 컴포넌트가 Context API 등을 통해 상태를 암시적으로 공유하므로 불필요한 'Prop Drilling'을 방지하고 유연성을 제공합니다 [6-8].
    *   **커스텀 훅 (Custom Hooks):** 렌더 프로프(Render Props)나 고차 컴포넌트(HOC) 패턴이 야기하던 '래퍼 지옥(Wrapper Hell)' 문제를 해결하기 위해 도입되었습니다 [9, 10]. API 호출, 폼 상태 관리 등의 상태 기반 로직을 함수 합성을 통해 깔끔하게 추출하고 재사용할 수 있습니다 [10-12].

*   **Vue 3의 확장성 및 조합 패턴**
    *   **컴포저블 (Composables):** React의 훅과 유사하게, 비즈니스 로직이나 상태 관리(예: 폼 유효성 검사, API 페칭)를 캡슐화한 독립적인 함수 패턴입니다 [13]. Mixin이 가지던 이름 충돌이나 데이터 은닉 문제를 해결하며 로직을 모듈화합니다 [14, 15].
    *   **스마트 vs 덤 컴포넌트 (Smart vs Dumb Components):** React의 컨테이너/프레젠테이션 패턴과 동일한 개념으로, API 호출과 상태를 관리하는 '스마트' 컴포넌트가 Prop을 통해 순수 UI 역할만 하는 '덤' 컴포넌트로 데이터를 내려주는 구조입니다 [16].

*   **Django의 비즈니스 로직 분리 패턴**
    *   **서비스 레이어 (Service Layer):** 비즈니스 로직을 View나 Model에서 분리하여 독립된 서비스 함수로 중앙 집중화하는 패턴입니다 [17, 18]. 뷰는 HTTP 응답과 입력 검증만 처리하도록 얇게 유지(Thin Views)합니다 [18, 19].
    *   **셀렉터 (Selectors):** 데이터베이스에서 데이터를 읽어오는 로직(QuerySet 필터링 등)을 전담하는 패턴으로, 서비스(쓰기)와 셀렉터(읽기)의 책임을 명확히 분리하고 N+1 쿼리 등의 성능 최적화를 용이하게 합니다 [18, 20].

*   **백엔드(Spring Boot & NestJS)의 횡단 관심사 및 아키텍처 패턴**
    *   **AOP 및 인터셉터 (AOP, Filters, Interceptors):** 로깅, 인증, 에러 처리와 같은 **횡단 관심사(Cross-Cutting Concerns)**를 핵심 비즈니스 로직과 분리하는 패턴입니다 [21, 22]. Spring Boot는 어노테이션 기반의 AOP를, NestJS는 가드(Guards)와 인터셉터를 파이프라인 형태로 사용하여 코드 중복을 제거합니다 [23, 24].
    *   **헥사고날 아키텍처 (Hexagonal Architecture / Ports and Adapters):** 핵심 도메인 로직을 외부 시스템(UI, 데이터베이스 등)으로부터 완전히 고립시킵니다 [25]. 시스템의 진입점과 출력점을 '포트(Ports)'로 정의하고, 이를 구현하는 '어댑터(Adapters)'를 두어 기술 스택 변경 시에도 도메인 규칙이 영향받지 않게 보호합니다 [26-28].

## ⚖️ Trade-offs & Caveats
디자인 패턴은 많은 문제를 해결하지만, 잘못된 적용이나 한계로 인한 **반대 급부(Trade-off)** 또한 존재합니다.

*   **추상화로 인한 디버깅 및 추적 난이도 상승:** 
    *   React의 **렌더 프로프(Render Props)**나 **HOC**는 과도하게 사용될 경우 중첩된 JSX 래퍼가 깊어지는 '래퍼 지옥'을 초래하여 코드 흐름을 따라가기 어렵게 만듭니다 [9, 10, 29, 30]. 
    *   Spring Boot의 **AOP**나 프레임워크의 매직 코드(마법처럼 동작하는 코드)는 인프라 코드를 완벽히 분리해주지만, 동작이 명시적이지 않아 새로운 개발자가 실행 흐름을 파악하거나 에러를 디버깅하기 어렵게 만듭니다 [22, 31].
*   **안티 패턴으로 전락할 수 있는 기능들:** Django의 **시그널(Signals)**은 모델 저장 등의 이벤트 시 동작을 분리할 수 있으나, 코드의 실행 흐름을 불투명하게 만들고 예상치 못한 부수 효과(Side Effects)를 유발하여 대규모 시스템에서는 치명적인 안티 패턴으로 꼽힙니다. 대신 명시적인 서비스 함수 호출이 권장됩니다 [32, 33].
*   **상속(Base Classes)의 한계:** 공통 로직을 처리하기 위해 기본 클래스(Base Class)를 사용하는 패턴은 다중 상속의 제한으로 인해 확장성이 떨어지며, 의존성이 추가될 때마다 모든 파생 클래스의 생성자를 수정해야 하는 유지보수 문제를 야기합니다 [34, 35].
*   **규칙 준수의 엄격함:** React의 **커스텀 훅(Custom Hooks)**은 유연하지만 React의 훅 규칙을 엄격하게 준수하지 않으면 애플리케이션 상태가 깨질 위험이 있으며 [12], 의존성 배열 누락으로 인한 '오래된 클로저(Stale Closure)' 문제에 주의해야 합니다 [36]. 

## 🔗 Knowledge Connections

### Related Concepts

#### [프론트엔드 UI 및 상태 설계 (UI & State Design)]
- [[Compound Components]]
  - 연결 이유: React에서 다수의 하위 컴포넌트가 구조적 유연성을 유지하면서 상태를 공유하는 대표적인 실전 UI 패턴입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context API를 활용한 암시적 상태 공유의 원리와 'Prop Drilling' 해결 방법론.
- [[Custom Hooks]]
  - 연결 이유: React 생태계에서 렌더링 로직과 비즈니스/상태 로직을 완전히 분리하는 가장 현대적인 패턴입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 함수 합성을 통한 로직의 캡슐화 및 재사용 극대화 전략.

#### [백엔드 아키텍처 및 도메인 설계 (Backend Architecture)]
- [[Hexagonal Architecture]]
  - 연결 이유: 백엔드 환경에서 프레임워크와 도메인 로직을 분리하기 위한 궁극적인 구조적 패턴(Ports and Adapters)입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 의존성 역전 원칙(DIP)의 실제 적용과 도메인 중심의 확장 가능 시스템 설계.
- [[Service Layer Pattern]]
  - 연결 이유: Django 등의 프레임워크에서 컨트롤러(View)가 비대해지는 것을 막고 비즈니스 로직을 분리하는 핵심 패턴입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 입력/검증 계층과 실제 비즈니스 규칙(Write) 및 조회(Read/Selectors)의 책임 분리.

#### [횡단 관심사 최적화 (Cross-Cutting Optimization)]
- [[Aspect-Oriented Programming (AOP)]]
  - 연결 이유: 로깅, 보안, 캐싱 등 여러 모듈에 흩어진 횡단 관심사 로직을 중앙에서 관리하기 위한 설계 패러다임입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체 지향 프로그래밍(OOP)을 보완하여 코드 중복을 없애고 인프라스트럭처 로직을 분리하는 방법.

### Deeper Research Questions
- React의 복합 컴포넌트(Compound Components)를 설계할 때, 자식 컴포넌트가 렌더링될 때 발생하는 불필요한 성능 저하(리렌더링)를 Context API와 결합하여 어떻게 최적화할 수 있는가?
- 백엔드의 횡단 관심사(Cross-Cutting Concerns)를 처리하기 위해 Spring Boot의 AOP와 NestJS의 Interceptor를 적용할 때 발생하는 런타임 오버헤드는 어느 정도이며, 디버깅 난이도를 낮추기 위한 최적의 로깅 전략은 무엇인가?
- 헥사고날 아키텍처(Hexagonal Architecture)를 도입할 때, 인바운드와 아웃바운드 포트(Ports)를 연결하는 어댑터 계층에서 DTO(Data Transfer Object)와 도메인 엔티티 간의 변환 책임은 정확히 어느 객체가 가져야 하는가?
- Django 생태계에서 'Fat Models' 방식과 'Service Layer' 패턴 중 어떤 방식을 선택해야 하는지 결정짓는 프로젝트의 도메인 복잡도 기준은 무엇인가?
- Vue 3의 Composition API에서 활용되는 컴포저블(Composables) 패턴은 React의 커스텀 훅(Custom Hooks)과 비교하여 라이프사이클 처리와 반응성(Reactivity) 모델에서 어떤 구조적 우위를 가지는가?

### Practical Application Contexts
- **Implementation:** 프론트엔드 개발 시, 무조건적인 상태 공유보다 **컴포지션 패턴(Compound Components, Render Props)** 또는 **스마트/덤 컴포넌트 패턴**을 적용하여 UI 코드의 결합도를 낮추고 모듈의 재사용성을 높입니다.
- **System Design:** 백엔드 API 시스템 기획 시, **헥사고날 아키텍처**나 **서비스/셀렉터 레이어 패턴**을 도입해 비즈니스 로직과 인프라(DB 연동, 외부 API 등)의 의존성을 격리함으로써, 훗날 기술 스택을 변경해도 도메인 로직을 재작성할 필요가 없도록 설계합니다.
- **Operation / Maintenance:** 운영 중 로깅, 예외 처리, 권한 확인 코드가 애플리케이션 전반에 흩어져 있다면, **AOP나 미들웨어/인터셉터 패턴**을 도입해 한 곳에서 횡단 관심사(Cross-cutting concerns)를 일괄 통제하고 비즈니스 코드 오염을 방지합니다.
- **Learning Path:** 특정 프레임워크의 문법(예: React, Django)을 익힌 후, 단순한 기능 구현을 넘어 각 커뮤니티에서 가장 권장되는 실전 패턴(커스텀 훅, 서비스 분리 등)을 학습하고, 안티 패턴(예: Django Signals 오남용)을 피하는 방향으로 학습을 심화합니다.
- **My Project Relevance:** 현재 유지보수 중인 프로젝트 내에 수천 줄에 달하는 비대한 클래스/컴포넌트가 존재한다면, 가장 먼저 **관심사 분리(Separation of Concerns)** 원칙을 바탕으로 디자인 패턴을 도입하여 테스트가 용이한 작은 단위의 코드 블록으로 리팩토링하는 데 활용합니다.

### Adjacent Topics
- [[Cross-Cutting Concerns]]
  - 확장 방향: 로깅, 보안, 에러 핸들링, 캐싱 등 시스템 전체에 적용되는 비기능적 요구사항을 설계 레벨에서 다루는 아키텍처 기법과 통합 도구로의 확장.
- [[Microservices Architecture]]
  - 확장 방향: 단일 시스템 내의 패턴을 넘어, 각각 독립된 모듈로 구축된 여러 서비스 간의 통신, 분산 트랜잭션, 데이터 동기화 등을 해결하는 아키텍처 디자인 패턴(예: API Gateway, Saga 패턴 등)으로의 연구 확장.

---
*Last updated: 2026-05-03*