Clean Architecture

📌 Brief Summary

클린 아키텍처(Clean Architecture)는 로버트 C. 마틴(Robert C. Martin)이 제안한 소프트웨어 설계 패턴으로, 도메인 중심 설계와 프레임워크 독립성을 핵심 원칙으로 삼는다 [1]. 이 아키텍처는 애플리케이션을 동심원 형태의 여러 추상화 계층으로 나누며, 모든 의존성이 항상 도메인을 향해 안쪽으로만 향하도록 강제한다 [2]. 결과적으로 비즈니스 로직을 데이터베이스, UI, 웹 프레임워크 등 외부 기술로부터 완벽히 분리하여 테스트 용이성과 장기적인 유지보수성을 극대화한다 [2-4].

📖 Core Content

핵심 원리 및 동심원 계층 구조: 클린 아키텍처는 비즈니스 규칙이 외부 환경과 기술로부터 철저히 독립적으로 유지되도록 시스템을 여러 개의 동심원 계층으로 구성한다 [2]. 이를 구성하는 4가지 주요 컴포넌트는 다음과 같다 [2].
- Entities (엔티티): 장기적인 안정성을 가지는 도메인 모델로, 특정 비즈니스 규칙을 포함한다 [2].
- Use Cases / Interactors (유스케이스): 애플리케이션 수준의 규칙을 오케스트레이션하고, 엔티티를 조정하며 입출력 흐름을 정의한다 [2].
- Interface Adapters (인터페이스 어댑터): 외부 세계와 유스케이스 사이의 번역기 역할을 담당하며, 컨트롤러, 프리젠터, 리포지토리 등이 여기에 속한다 [2].
- Frameworks & Drivers (프레임워크 및 드라이버): 데이터베이스, 웹 프레임워크, UI, 메시징 시스템 등 주변의 세부 사항들로, 코어 도메인에 영향을 주지 않고 언제든 교체될 수 있어야 한다 [2].
프레임워크별 실전 패턴 (Flutter의 사례): 현대 애플리케이션 프레임워크, 특히 Flutter 생태계에서는 비즈니스 로직과 UI 위젯을 엄격하게 분리하기 위해 클린 아키텍처를 적극적으로 수용하고 있다 [4]. 실무에서는 앱의 구조를 다음의 3가지 계층으로 분리하여 관심사를 명확히 한다 [3, 5].
- Presentation Layer (프리젠테이션 계층): UI 렌더링 및 사용자 이벤트 처리를 담당하며, BLoC나 Cubit과 같은 상태 관리 패턴이 사용된다 [3, 5].
- Domain Layer (도메인 계층): 프레임워크에 의존하지 않는 순수한 비즈니스 로직, 엔티티, 유스케이스 및 리포지토리 인터페이스를 정의한다 [3, 5].
- Data Layer (데이터 계층): 외부 데이터 소스와의 통신 및 데이터 매핑을 담당하며, 리포지토리의 실제 구현체, 데이터 소스, 데이터 모델 등을 포함한다 [3, 5]. 이러한 계층 분리는 코드의 재사용성을 높이고 시스템이 향후의 변화에 쉽게 적응할 수 있도록 돕는다 [3].
다른 아키텍처 패턴과의 관계: 클린 아키텍처는 육각형 아키텍처(Hexagonal Architecture)와 구조적 시각화 방식에는 차이가 있으나, 도메인을 중앙에 배치하고 인프라 세부 구현을 외곽으로 밀어낸다는 철학과 의존성 역전 원칙을 동일하게 공유한다 [1, 6].

⚖️ Trade-offs & Caveats

클린 아키텍처를 구현하기 위해 리포지토리나 서비스에 대한 인터페이스를 일일이 정의하고 계층을 엄격하게 나누는 설계 관행은 양날의 검이 될 수 있다 [7]. NestJS와 같은 특정 프레임워크 환경이나 단순한 구조를 가진 프로젝트에서는 이러한 엄격한 계층 분리가 오히려 과도한 엔지니어링(Overkill)으로 작용하여, 불필요하게 많은 보일러플레이트(Boilerplate) 코드를 양산하는 원인이 될 수 있다 [7]. 따라서 프로젝트의 비즈니스 복잡도와 규모를 고려하여 추상화 수준을 결정해야 한다.

🔗 Knowledge Connections

[아키텍처 및 설계 철학]

Hexagonal Architecture
- 연결 이유: 클린 아키텍처와 동일하게 도메인을 코어에 두고 외부 기술을 분리하여 소프트웨어의 유연성을 확보하려는 목적을 지닌 아키텍처 패턴이다 [1, 6].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 내부 비즈니스 로직과 외부 세계 간의 경계를 '포트'와 '어댑터'라는 개념으로 정의하고 계약을 맺어 의존성 방향을 제어하는 실무적인 메커니즘 [6, 8].
Domain-Driven Design
- 연결 이유: 클린 아키텍처의 중심에 위치하는 엔티티(Entity) 계층과 유스케이스를 도출하고 코어 비즈니스를 모델링하는 데 근간이 되는 방법론이다 [6, 9].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 보편적 언어(Ubiquitous Language)를 사용해 Bounded Context를 나누고, 비즈니스 규칙을 엔티티와 값 객체(Value Objects)로 구체화하여 아키텍처의 코어를 채우는 방법 [6, 10].

[프레임워크 생태계 및 구현 도구]

BLoC
- 연결 이유: Flutter 환경에서 클린 아키텍처를 적용할 때, 프리젠테이션 계층(Presentation Layer)의 상태를 관리하고 비즈니스 로직을 UI로부터 분리하기 위해 가장 널리 사용되는 패턴이다 [5, 11].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클린 아키텍처의 규칙을 훼손하지 않으면서 이벤트 중심(Event-Driven)의 반응형 상태 흐름을 구축하는 구체적인 구현 전략 [3].
Test-Driven Development
- 연결 이유: 클린 아키텍처의 가장 큰 이점 중 하나인 외부 프레임워크 비의존성을 통해, 모킹(Mocking) 객체를 활용한 독립적인 단위 테스트가 수월해지며 TDD 도입의 기반이 된다 [3, 4, 11, 12].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터베이스나 UI 인프라 없이 도메인 중심의 비즈니스 규칙과 유스케이스가 올바르게 작동하는지 코드를 작성하기 전에 선제적으로 검증하는 방법론 [11, 12].

Deeper Research Questions

클린 아키텍처 도입으로 인해 필연적으로 발생하는 보일러플레이트 코드를 NestJS 및 Flutter와 같은 개별 프레임워크 환경에서 어떻게 효율적으로 최소화할 수 있는가?
도메인 중심의 클린 아키텍처를 도입하는 것이 비즈니스 로직이 비교적 단순한 CRUD 기반 애플리케이션에서도 비용 대비 효용을 가지는 손익분기점(Break-even point)은 언제인가?
모바일(Flutter) 환경의 Data Layer에서 REST API 데이터 모델(DTO)과 클린 아키텍처의 핵심 도메인 Entity 간의 데이터 변환 계층을 설계할 때 성능과 메모리 오버헤드를 최적화하는 전략은 무엇인가?
프론트엔드 환경에서 횡단 관심사(Cross-cutting Concerns) 처리를 위한 고차 컴포넌트(HOC)와 클린 아키텍처의 유스케이스 계층은 설계적으로 어떻게 역할을 분담해야 하는가?
마이크로서비스 아키텍처에서 각 서비스의 내부 구조를 클린 아키텍처로 구성할 때, Bounded Context 간의 통신(이벤트 스트리밍 등)을 어댑터 계층에서 어떻게 추상화하는 것이 이상적인가?

Practical Application Contexts

Implementation: Flutter 프로젝트 개발 시 앱의 구조를 Presentation, Domain, Data 폴더로 엄격하게 모듈화하고 BLoC을 활용하여 의존성 규칙에 따라 코드를 작성하는 기반 패턴으로 활용됨 [3, 5, 11].
System Design: 애플리케이션의 뼈대를 잡을 때 코어 도메인을 최우선으로 설계하고, 데이터베이스나 외부 프레임워크는 언제든 교체 가능한 플러그인(Plugin) 형태로 동작하도록 의존성의 방향을 내부로만 향하게 설계함 [2].
Operation / Maintenance: 레거시 데이터베이스 기술 스택이나 UI 프레임워크가 교체되더라도, 핵심 비즈니스 로직인 도메인 영역은 수정할 필요가 없으므로 시스템의 장기 유지보수성과 변화에 대한 회복력이 크게 증가함 [2, 12].
Learning Path: 단순한 계층형 아키텍처(Layered Architecture)의 한계를 이해한 후, 의존성 역전 원칙(DIP)과 도메인 중심 설계를 기반으로 육각형 아키텍처 및 클린 아키텍처로 나아가는 소프트웨어 공학 학습 경로의 핵심 지표로 활용됨 [2, 13, 14].
My Project Relevance: 다양한 기술 스택을 사용하는 대규모 프로젝트나 여러 모바일/웹 플랫폼을 지원하는 프로덕트를 구축할 때, 도메인 비즈니스 규칙의 파편화를 막고 독립적인 유닛 테스트 작성을 보장하기 위한 가장 필수적인 아키텍처 가이드라인으로 적용 가능함.

Adjacent Topics

Onion Architecture
- 확장 방향: 제프리 팔레르모(Jeffrey Palermo)가 고안한 아키텍처로, 클린 아키텍처와 유사하게 인프라를 외부로 밀어내고 코어 비즈니스 도메인을 중앙에 두는 모델이다. 두 아키텍처의 동심원 분할 방식과 사용되는 용어(Application Services 등)의 미세한 차이를 비교 분석해 볼 수 있다 [15].

Last updated: 2026-05-02

9.4 KiB Raw Blame History