---
id: P-REINFORCE-AUTO-0A3765
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 클린 아키텍처 (Clean Architecture)"
---

# [[클린 아키텍처 (Clean Architecture)|클린 아키텍처 (Clean Architecture)]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> 클린 아키텍처는 로버트 C. 마틴(Uncle Bob)이 창안한 소프트웨어 설계 철학으로, 시스템을 '관심사의 분리(Separation of Concerns)' 원칙에 따라 명확한 계층으로 나누는 아키텍처 구조입니다 [1-3]. 이 아키텍처는 시스템의 핵심인 비즈니스 로직을 프레임워크, UI, 데이터베이스와 같은 외부 기술 요소로부터 완벽히 분리시켜 유지보수성, 확장성, 그리고 테스트 용이성을 극대화하는 것을 목표로 합니다 [1, 4, 5]. 핵심 원리는 소스 코드의 의존성이 오직 내부의 고수준 정책(비즈니스 로직)을 향하도록 통제하는 '의존성 규칙(Dependency Rule)'을 엄격히 준수하는 것입니다 [1, 6, 7].

## 📖 구조화된 지식 (Synthesized Content)
**1. "뇌와 팔다리의 분리" 메타포를 통한 관심사 분리의 구현**
클린 아키텍처는 시스템을 '뇌(핵심 비즈니스 로직)'와 '팔다리(인프라스트럭처 및 외부 요소)'로 엄격하게 이분화하여 관심사의 분리(SoC)를 실현합니다 [8, 9]. 
*   **뇌 (핵심 계층):** 도메인의 본질적인 규칙을 담고 있는 엔티티(Entities)와 이를 제어하는 유스케이스(Use Cases)로 구성됩니다 [9]. 뇌가 신체의 중심인 것처럼 이 계층은 외부 세계(DB, UI 등)에 대해 전혀 알지 못하는 가장 독립적이고 순수한 형태를 유지해야 합니다 [9, 10].
*   **팔다리 (외부 계층):** 웹 인터페이스, 데이터베이스, 서드파티 프레임워크 등 핵심 로직을 감싸고 외부와 소통하는 저수준의 세부 사항입니다 [9, 11]. 팔다리는 언제든 다른 기술로 교체 가능하도록 시스템의 심장부에 '플러그인' 형태로 연결되어야 합니다 [9, 12].

**2. 의존성 규칙 (Dependency Rule)**
클린 아키텍처가 동작하게 하는 가장 핵심적인 규칙으로, 모든 소스 코드의 의존성은 반드시 바깥쪽(저수준 메커니즘)에서 안쪽(고수준 정책)으로만 향해야 합니다 [1, 6, 7]. 내부의 원에 속한 코드는 외부 원에 선언된 함수, 클래스, 변수 등 어떠한 것도 이름조차 언급해서는 안 되며, 외부의 데이터 형식에 의존해서도 안 됩니다 [7].

**3. 4가지 주요 동심원 계층 구조**
클린 아키텍처는 통상적으로 4가지 동심원 계층으로 소프트웨어를 구성합니다 [3, 7, 13].
*   **엔티티 (Entities):** 전사적인 핵심 업무 규칙과 데이터를 캡슐화한 가장 안쪽의 중심 계층입니다 [3, 10, 13]. 외부의 무언가가 변경되더라도 가장 영향을 받지 않습니다 [10].
*   **유스케이스 (Use Cases / Interactors):** 특정 애플리케이션에 특화된 업무 규칙을 포함하며, 엔티티로 들어오고 나가는 데이터 흐름을 조정합니다 [3, 13, 14].
*   **인터페이스 어댑터 (Interface Adapters):** 유스케이스와 엔티티에 편리한 형식의 데이터를 외부 에이전시(DB, 웹 등)가 사용하기 편리한 형식으로 변환해 주는 어댑터(프레젠터, 뷰, 컨트롤러 등)들의 모임입니다 [3, 11, 13, 14].
*   **프레임워크와 드라이버 (Frameworks & Drivers):** 데이터베이스, 웹 프레임워크, UI 등이 위치하는 가장 바깥쪽의 변동성이 큰 계층입니다 [3, 11, 13].

**4. 클린 아키텍처의 주요 이점**
*   **완벽한 격리 및 테스트 용이성:** 업무 규칙은 UI, 데이터베이스, 웹 서버 등의 외부 요소가 없어도 독립적으로 테스트할 수 있습니다 [4, 5, 15].
*   **기술적 독립성 및 유연성:** 시스템은 특정 프레임워크에 종속되지 않으며, 외부 계층(팔다리)을 변경하더라도 내부 계층(뇌)의 핵심 기능은 아무런 영향을 받지 않기 때문에 기술 변화에 유연하게 대응할 수 있습니다 [4, 5, 15].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리 (Separation of Concerns)|관심사의 분리 (Separation of Concerns)]], [[의존성 역전 원칙 (Dependency Inversion Principle)|의존성 역전 원칙 (Dependency Inversion Principle)]], [[단일 책임 원칙 (Single Responsibility Principle)|단일 책임 원칙 (Single Responsibility Principle)]]
- **Projects/Contexts:** [[웹 애플리케이션의 3계층 구조|웹 애플리케이션의 3계층 구조]], [[도메인 주도 설계 (DDD)|도메인 주도 설계 (DDD)]], [[넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환|넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환]]
- **Contradictions/Notes:** 소스에 따르면 클린 아키텍처는 유지보수성과 확장성을 비약적으로 높여주지만, 초기 개발 시간이 증가하고 계층과 추상화가 너무 많아질 경우 시스템 구조가 지나치게 복잡해지는 오버엔지니어링(Over-Engineering) 및 간접 참조에 의한 가독성 저하를 유발할 수 있습니다 [16, 17]. 따라서 과도한 추상화를 경계하고, 실용적 필요에 맞게 응집도와 결합도를 고려하여 아키텍처의 균형을 맞추는 것이 중요합니다 [16, 18].

---
*Last updated: 2026-04-18*
- Raw Source: 00_Raw/2026-04-20/클린 아키텍처 (Clean Architecture).md
---
