2nd/10_Wiki/Topics/클린 아키텍처.md

---

id: P-Reinforce-AUTO-417677 category: Unified confidence_score: 0.90 tags: [auto-reinforced] last_reinforced: 2026-04-20 github_commit: "[P-Reinforce] Continuous Worker - 클린 아키텍처"

클린 아키텍처

📌 한 줄 통찰 (The Karpathy Summary)

클린 아키텍처(Clean Architecture)는 로버트 C. 마틴(RoBERT C. Martin)이 제안한 소프트웨어 설계 철학으로, 비즈니스 로직과 애플리케이션 규칙을 시스템의 중심에 배치하는 구조를 갖습니다 [1, 2]. 소프트웨어를 여러 동심원 계층으로 분리하여 관심사를 철저히 분리하며, 프레임워크, 사용자 인터페이스(UI), 데이터베이스 등 외부 요소로부터 시스템을 완전히 독립시키는 것을 목표로 합니다 [1, 3-5]. 이 아키텍처의 핵심은 소스 코드의 의존성이 오직 내부의 고수준 정책만을 향해야 한다는 '의존성 규칙(Dependency Rule)'입니다 [1, 5, 6]. 이를 통해 시스템은 프레임워크나 외부 에이전시의 변경에 영향을 받지 않으며, 유지보수성, 확장성, 그리고 테스트 용이성을 극대화할 수 있습니다 [5, 7, 8].

📖 구조화된 지식 (Synthesized Content)

• 핵심 목적과 이점: 클린 아키텍처의 주된 목적은 관심사의 분리([[뇌와 팔다리의 분리 - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])를 통해 시스템을 모듈화하고, 프레임워크, UI, 데이터베이스로부터 독립적인 시스템을 만드는 것입니다 [3-5]. 이를 통해 개발자는 외부 요소의 개입 없이 핵심 비즈니스 로직을 격리하여 단위 테스트를 수행할 수 있으며(TeStability), 시스템의 생명주기를 늘리고 새로운 요구사항에 유연하게 대응할 수 있는 확장성(Scalability) 및 유지보수성(Maintainability)을 확보할 수 있습니다 [3, 5, 8].

• 동심원 계층 구조: 클린 아키텍처는 보통 4가지의 계층으로 시스템을 나눕니다 [9, 10].

  • 엔티티 (Entities): 시스템의 가장 안쪽에 위치하며, 전사적이고 가장 일반적인 핵심 업무 규칙을 캡슐화합니다 [9-11]. 페이지 네비게이션이나 보안 등 외부의 변경 사항에 절대 영향을 받지 않아야 합니다 [11].
  • 유스케이스 (Use Cases): 애플리케이션에 특화된 업무 규칙을 포함하며, 엔티티로 들어가고 나가는 데이터의 흐름을 조정합니다 [9, 10, 12].
  • 인터페이스 어댑터 (Interface Adapters): 유스케이스나 엔티티에게 편리한 데이터 형식을 데이터베이스나 웹 같은 외부 에이전시가 이용하기 편리한 형식으로 변환하는 어댑터 역할을 합니다 [9, 10, 12]. 프레젠터(Presenter), 뷰(View), 컨트롤러(Controller) 등의 MVC 구조가 이곳에 속합니다 [9, 12].
  • 프레임워크와 드라이버 (Frameworks & Drivers): 가장 바깥쪽 계층으로, 데이터베이스, 웹 프레임워크, UI 등 변동성이 매우 큰 외부 도구들로 구성됩니다 [9, 10, 13].

• 핵심 설계 원칙:

  • 의존성 규칙 (Dependency Rule): 소스 코드의 의존성은 반드시 바깥쪽에서 안쪽으로, 즉 고수준의 정책(비즈니스 로직)을 향해야 합니다 [1, 5, 6]. 내부 원의 코드는 외부 원에 선언된 어떤 요소(함수, 클래스, 변수 등)의 이름도 언급해서는 안 됩니다 [5].
  • 의존성 역전 원칙 (DIP) 활용: 제어 흐름이 내부에서 외부로 향해야 할 때는 의존성 역전 원칙을 사용하여 소스 코드 의존성이 제어 흐름과 반대 방향이 되도록 만듭니다 [14, 15]. 예를 들어 유스케이스가 프레젠터를 호출해야 할 경우, 직접 호출하는 대신 내부 원의 인터페이스를 호출하고 외부 원의 프레젠터가 이를 구현하도록 합니다 [15].
  • 경계를 횡단하는 데이터: 계층의 경계를 가로지르는 데이터는 엔티티나 데이터베이스의 행(Row)이 아닌, 격리되고 단순한 데이터 구조(DTO 등)여야 합니다 [16, 17].

• 적용 시의 과제 및 한계: 클린 아키텍처는 유지보수성과 유연성을 가져오지만, 다수의 계층과 추상화를 도입해야 하므로 초기 개발 시간이 늘어나고 시스템이 불필요하게 복잡해지는 오버 엔지니어링(Over-Engineering)을 유발할 수 있습니다 [18]. 또한, 여러 계층 간의 상호작용으로 인해 통합 테스트의 복잡성이 증가할 수 있습니다 [18].

• 실제 적용 사례: 클린 아키텍처의 원칙은 구글이 권장하는 Android 애플리케이션 아키텍처, iOS의 VIPER 아키텍처, ASP.NET Core 웹 애플리케이션, 그리고 Netflix의 마이크로서비스 설계 등 다양한 플랫폼과 환경에서 실질적으로 적용되어 견고한 시스템 구축에 기여하고 있습니다 [19-21].

⚠️ 모순 및 업데이트 (Contradictions & RL Update)

• 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
• 정책 변화: Design & Experience 분야의 자동 자산화 수행.

🔗 지식 연결 (Graph)

• Related Topics: 관심사의 분리, 의존성 규칙, 의존성 역전 원칙, SOLID 원칙
• Projects/Contexts: Netflix 마이크로서비스, Android 애플리케이션 아키텍처, VIPER 아키텍처
• Contradictions/Notes: 클린 아키텍처는 시스템의 유지보수성과 유연성을 극대화하지만, 동시에 여러 계층과 추상화의 추가로 인해 초기 개발 시간이 늘어나고 구조가 복잡해지는 '오버 엔지니어링'의 위험을 동반하므로 실용성과의 적절한 균형이 필요하다는 점을 주의해야 합니다 [18].

---

Last updated: 2026-04-18

---