[P-Reinforce] 2026-05-03: 지식 강화 완료 (Datacollector_MAC 기술 아티팩트 일괄 위키화)

01_Archive/2026-05-03/Clean Architecture.md

@@ -0,0 +1,63 @@
+# [[Clean Architecture]]
+
+## 📌 Brief Summary
+Clean Architecture는 시스템의 핵심 비즈니스 로직과 애플리케이션 전체에 걸쳐 있는 횡단 관심사(Cross-cutting concerns)를 분리하여 시스템의 유지보수성과 확장성을 보장하는 아키텍처 원칙입니다 [1]. 이 아키텍처는 관심사의 분리와 모듈화를 강조하며, 비즈니스 규칙이 다른 요소들로 인해 어지럽혀지지 않고 깔끔하며 적응 가능하도록 유지하는 것을 목표로 합니다 [1, 2]. 핵심 아이디어는 로깅, 캐싱, 유효성 검사 등의 횡단 관심사를 비즈니스 로직과 분리하여 인프라스트럭처(Infrastructure) 계층에 구현하는 것입니다 [3].
+
+## 📖 Core Content
+
+*   **관심사 분리와 모듈화의 중심 역할**
+    Clean Architecture에서 횡단 관심사(로깅, 인증, 유효성 검사, 캐싱 등)는 시스템의 유지보수성과 확장성을 보장하기 위해 핵심 비즈니스 로직과 별개로 처리되어야 합니다 [1, 4]. 이러한 분리는 컴포넌트 간의 강한 결합(tight coupling)을 방지하고 코드의 중복을 막아줍니다 [4]. Clean Architecture의 원칙에 따라 핵심 비즈니스 규칙을 깔끔하게 유지하면, 아키텍처 자체를 변경에 유연하게 만들 수 있습니다 [1].
+
+*   **인프라스트럭처 계층(Infrastructure Layer)에서의 횡단 관심사 구현**
+    이상적으로 횡단 관심사는 인프라스트럭처 계층에 구현되어야 합니다 [3]. 프레임워크에 따라 ASP.NET Core 미들웨어나 데코레이터, MediatR 파이프라인 동작(Pipeline behaviors) 등을 사용하여 비즈니스 로직과 횡단 관심사를 명확히 분리할 수 있습니다 [3, 5].
+
+*   **주요 횡단 관심사의 실전 분리 전략**
+    *   **로깅(Logging):** 파이프라인 동작 내에 로깅 로직을 캡슐화하여 비즈니스 로직과 분리된 고유한 관심사로 취급해야 합니다 [5]. 구조화된 로깅(Structured logging)을 사용하면 정보를 효과적으로 수집하면서도 핵심 로직을 어지럽히지 않을 수 있습니다 [5, 6].
+    *   **유효성 검사(Validation):** 유효성 검사는 시스템에 잘못된 데이터가 들어오는 것을 막는 첫 번째 방어선으로, 핵심 처리 로직에 도달하기 전에 파이프라인에서 요청을 검증해야 합니다 [6, 7]. 데이터 형식 등을 확인하는 '입력 유효성 검사'와 도메인 특정 규칙을 준수하는지 확인하는 '비즈니스 규칙 유효성 검사'를 명확하게 구별하여 설계해야 합니다 [7, 8].
+    *   **캐싱(Caching):** 성능과 확장성 향상을 위해 자주 쓰이며, 파이프라인 내에서 Cache Aside 패턴 등을 구현해 요청 처리 전 캐시를 확인하고 업데이트하는 방식을 사용합니다 [8, 9].
+
+## ⚖️ Trade-offs & Caveats
+Clean Architecture 설계 자체의 근본적인 단점이나 아키텍처적 반대 급부(Trade-off)에 대해서는 **소스에 관련 정보가 부족합니다.** 
+
+다만, Clean Architecture 원칙에 따라 횡단 관심사를 인프라스트럭처 계층으로 분리하여 최적화할 때 다음과 같은 기술적 제약과 고려 사항이 따릅니다:
+*   **로깅의 적정성 문제:** 효과적인 로깅을 위해 구조화된 데이터를 캡슐화하더라도, 세분화(granularity)와 명확성 사이의 균형을 맞추지 못하면 로그가 유용한 도구가 아닌 단순한 소음(noise)으로 전락할 수 있습니다 [6].
+*   **캐싱 설계의 복잡성 증가:** 캐싱을 구현할 때는 연산 비용이 높으면서도 충분히 안정적인(stable) 데이터만을 신중히 선택해야 합니다 [9]. 또한, 적절한 캐시 무효화(Invalidation) 시점 결정과 만료 시간 및 크기 등의 캐시 설정(Configuration)을 완벽히 통제해야 하는 기술적 부담이 발생합니다 [9]. 
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처 패턴 / 설계 사상]
+- [[Hexagonal Architecture]]
+  - 연결 이유: Clean Architecture와 마찬가지로 외부 종속성(DB, UI 등)으로부터 애플리케이션 로직을 강하게 결합하지 않고 관심사를 분리 및 모듈화하기 위해 고안된 아키텍처 패턴입니다 [2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처가 어떻게 핵심 비즈니스 로직을 중심에 두고 외부와의 인터페이스(포트와 어댑터)를 통해 횡단 관심사와 외부 기술을 격리하는지 이해할 수 있습니다 [2, 10].
+
+- [[Cross-Cutting Concerns]]
+  - 연결 이유: 로깅, 유효성 검사, 캐싱, 예외 처리 등 여러 계층에 걸쳐 나타나는 공통 기능들로, Clean Architecture가 비즈니스 로직에서 떼어내어 인프라스트럭처 계층으로 격리하고자 하는 주 대상입니다 [1, 3, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 이 관심사들이 중앙집중화되어야 하며, 이를 방치할 경우 어떻게 코드 중복과 강한 결합이 발생하는지 통찰을 얻을 수 있습니다 [4].
+
+#### [구현 및 활용 도구]
+- [[Modular Monolith]]
+  - 연결 이유: Clean Architecture 원칙과 결합하여 대규모 애플리케이션을 구축할 때 자주 언급되는 실전 시스템 구현 구조입니다 [11, 12].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 물리적인 마이크로서비스로 분리하기 전, 단일 코드베이스 내에서 Clean Architecture의 모듈화와 관심사 분리 원칙을 어떻게 실제 프로덕션 수준으로 구현하는지 파악할 수 있습니다 [12].
+
+### Deeper Research Questions
+- Clean Architecture 내에서 도메인 규칙을 검증하는 '비즈니스 규칙 유효성 검사'와 단순한 '입력 유효성 검사'를 코드 레벨에서 완벽하게 분리하는 가장 이상적인 패턴은 무엇인가?
+- 인프라스트럭처 계층의 파이프라인 (예: MediatR 파이프라인)을 통해 캐싱과 로깅을 중앙 집중화할 때 발생하는 런타임 오버헤드는 어떻게 최소화할 수 있는가?
+- Clean Architecture, Hexagonal Architecture(Ports and Adapters), Onion Architecture 등 관심사 분리를 강조하는 아키텍처들 간의 미세한 구조적 차이점과 프레임워크(Spring Boot, NestJS 등)별 최적합성은 무엇인가?
+- 대규모 애플리케이션에서 비즈니스 로직의 순수성을 지키면서 캐시 무효화(Cache Invalidation)와 같은 인프라적 제어 로직을 도메인과 분리해 설계하는 방법은 무엇인가?
+- 클린 아키텍처의 의존성 주입(DI) 원칙이 모놀리식 구조에서 마이크로서비스 아키텍처로 전환할 때 어떤 이점과 한계를 가지는가?
+
+### Practical Application Contexts
+- **Implementation:** .NET 에코시스템의 MediatR `IPipelineBehavior` 나 ASP.NET Core 미들웨어를 사용하여 로깅, 캐시(Cache Aside), 입력 유효성 검사를 구현함으로써 비즈니스 로직과 인프라를 분리할 수 있습니다 [3, 5, 9].
+- **System Design:** 아키텍처 초기 설계 단계부터 횡단 관심사를 한 곳에 집중시키도록 설계함으로써, 각 기능(Feature) 모듈의 핵심 도메인 규칙이 오염되지 않는 확장 가능한 백엔드 시스템을 설계할 수 있습니다 [1, 4].
+- **Operation / Maintenance:** 구조화된 로깅과 체계적인 예외 파이프라인 처리를 통해 시스템 운영 시 발생하는 상태 이상을 빠르게 추적하고, 잘못된 데이터 유입을 비즈니스 로직 진입 전에 차단하여 운영 복원력을 높입니다 [6, 8].
+- **Learning Path:** 횡단 관심사 이해 -> 의존성 주입과 파이프라인 패턴 학습 -> Clean Architecture와 Hexagonal Architecture 철학 이해 -> Modular Monolith 및 Domain-Driven Design 설계 방식 수립 순으로 학습을 진행합니다 [2, 3, 11, 12].
+- **My Project Relevance:** 현재 적용 중인 웹 프레임워크(예: NestJS의 파이프/가드, Spring Boot의 AOP/인터셉터)에서 핵심 로직 외의 기능들이 어떻게 구현되어 있는지 점검하고, 이를 Clean Architecture의 관점에서 인프라스트럭처 계층으로 재배치하는 리팩토링에 활용할 수 있습니다 [3, 13].
+
+### Adjacent Topics
+- [[Domain-Driven Design]]
+  - 확장 방향: Clean Architecture가 구조적 분리를 통해 뼈대를 잡는다면, DDD는 그 내부의 '핵심 비즈니스 로직'을 어떻게 모델링하고 구체화할지에 대한 방법론을 제공하므로 이 둘의 결합 시너지를 탐구할 수 있습니다 [8, 11].
+
+---
+*Last updated: 2026-05-03*