Clean Architecture에 관한 간단한 고찰

들어가며

 

“프로젝트에서 클린 아키텍처를 적용한 경험이 있나요?”

“클린 아키텍처와 구글 권장 앱 아키텍처의 차이점이 무엇인가요?”

 

두 질문 모두 최근에 각각 다른 면접에서 받은 질문입니다.

‘클린 아키텍처’, 안 들어본 개발자가 없을 정도로 아주 유명하고 익숙한 아키텍처입니다. 하지만 저는 우아한테크코스를 다닐 때만 해도 클린 아키텍처가 어렵게 느껴졌고, 공부의 필요성을 느끼지 못해서 더 자세히 공부하지 않았습니다. (아무래도 안드로이드, 코틀린, 코루틴에 대한 학습이 먼저라고 생각했습니다)

 

그런데 취업 준비를 계속 하다보니, 클린 아키텍처에 대한 지식이나 적용 경험을 요구하는 공고가 생각보다 많았습니다. 또 면접 질문 단골 주제인 만큼, 공고에 클린 아키텍처가 언급되어 있지 않아도 면접관이 클린 아키텍처에 대해 질문하는 경우도 많은 것 같습니다.

저는 클린 아키텍처를 적용해본 경험은 없지만, 개념을 어느 정도 이해하는게 면접 준비에 도움이 될 것 같았고, 나중에 실무에서도 도움이 될 것이라 생각해 클린 아키텍처에 대해 간단히 공부해보았습니다. 클린 아키텍처를 조금씩 파헤쳐보며 알게된 내용들을 여기에 정리해서 남겨보려 합니다.

 

이번 포스트는 클린 아키텍처의 탄생 배경과 구조 및 특징, 클린 아키텍처를 둘러싼 오해를 살펴보겠습니다.

 

---

 

클린 아키텍처(Clean Architecture)란?

Clean? 깨끗한? 깔끔한?
깔끔한 아키텍처?

 

클린 아키텍처(Clean Architecture)는 Uncle Bob(Robert C. Martin)(이하 Uncle Bob)이 2012년 블로그 포스트를 통해 처음 제안하고, 이후 2017년에 저서 "Clean Architecture: A Craftsman's Guide to Software Structure and Design"으로 정리한 아키텍처 원칙입니다.

Clean Coder Blog

 

클린 아키텍처 하면 떠오르는 그 유명한 다이어그램

 

언제나 그렇듯, 왜 만들어졌는지를 살펴보면 이 아키텍처가 해결하려는 문제가 무엇인지 명확하게 알 수 있으니, 클린 아키텍처의 탄생 배경을 먼저 알아보겠습니다.

 

클린 아키텍처의 탄생 배경

소프트웨어는 크게 도메인과 세부 사항으로 구분된다

소프트웨어에서 UI나 DB와 같은 부분은 자주 수정될 수 있고, 또 변경될 수 있습니다.

클린 아키텍처에서는 소프트웨어의 UI나 DB와 같은 기술을 외부 기술이라고 하며, 단지 소프트웨어의 세부 사항이라고 말합니다.

그리고 소프트웨어의 중심이며 핵심이 되는 비즈니스 로직을 도메인이라고 명시합니다.

 

여러분에게 익숙한 은행 서비스를 생각해볼까요? 다른 계좌로 돈을 송금하는 화면의 UI가 변경되었다거나, 서버에서 계좌 정보를 가져오는 API를 개선했다고 하더라도, 돈을 송금하는 로직, 즉 "현재 계좌에서 돈을 출금해 다른 계좌에 입금한다."라는 과정은 변경되지 않습니다.

은행 서비스를 이루는 핵심 로직(도메인)은 은행 업무를 소프트웨어 세계에서 나타낸 것들의 집합이고, Web, UI와 DB 같은 외부 기술들은 단지 세부 사항일 뿐입니다.

 

세부 사항은 자주 변경될 수 있다

소프트웨어에서 세부 사항들은 자주 변경될 수 있습니다.

 

우선 UI는 정말 자주 변경되는 요소입니다. 기능의 추가는 물론, 기능의 아주 사소한 부분이 변경되더라도 영향을 받을 수 있습니다. 또 서비스 접근성, 사용성을 개선하거나 광고와 같은 특정 요소의 클릭률을 높이기 위해 변경되기도 합니다.

 

뿐만 아니라 유지보수 비용을 낮추기 위한 목적으로 DB와 같은 외부 프레임워크를 바꾸기도 하고, 특정 기술에 대한 지원이 중단되어 다른 기술로의 변경이 불가피한 경우도 생깁니다.

실제로 Discord, Netflix, Airbnb, Uber와 같은 여러 대형 서비스들이 외부 기술을 변경하는 사례도 있습니다.

• Discord: MongoDB → Apache Cassandra → ScyllaDB 로 두 차례 변경
  • https://discord.com/blog/how-discord-stores-billions-of-messages
  • https://discord.com/blog/how-discord-stores-trillions-of-messages
• Netflix: Oracle → Apache Cassandra
  • https://www.infoworld.com/article/2171162/big-movies-big-data-netflix-embraces-nosql-in-the-cloud.html
• Airbnb: React Native → 네이티브(Android, iOS) 전환
  • https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a
• Uber: PostgreSQL → MySQL
  • https://www.uber.com/en-KR/blog/postgres-to-mysql-migration/

 

기술과 비즈니스 로직이 강하게 결합되는 문제

만약 이런 외부 기술들이 비즈니스 로직과 강하게 결합되어 있다면?

 

소프트웨어는 초기에는 빠르게 개발되고, 규모가 작아 변경 사항에도 대처가 쉽습니다. 하지만 시간이 지나고 규모가 커질수록 변경에 대한 비용이 기하급수적으로 증가하는 문제에 직면합니다

대부분의 원인은 바로 비즈니스 로직이 UI, DB, 프레임워크와 같은 특정 기술(세부 사항)에 묶여있는 구조 때문입니다. 비즈니스 로직과 특정 기술이 강하게 결합되어있는 구조로 인해, 특정 기술을 수정하거나 변경할 때마다 비즈니스 로직도 함께 수정해야하는 일이 발생하게 됩니다.

 

홈쇼핑 앱에서 DB에 저장된 사용자 정보를 가져오는 쿼리를 수정하거나, 화면의 ‘주문하기’ 버튼 하나를 변경할 뿐인데, 주문을 처리하는 로직까지 수정해야할 수 있습니다.

더욱이 위에서 소개한 실제 사례들처럼 DB나 UI 프레임워크를 변경해야하는 대공사를 진행한다면, 서비스 도메인 자체를 처음부터 다시 설계해야하는 일이 발생할 수도 있습니다.

 

Uncle Bob의 클린 아키텍처

옛날 개발자들은 완전히 멘탈이 나가버렸습니다.

 

개발자들은 옛날부터 이러한 현상을 겪어왔고, Uncle Bob 또한 마찬가지였습니다. 수십년 동안 이러한 현상을 겪어온 Uncle Bob은 이 문제를 해결하기 위해, 이전에 다른 엔지니어들이 고안한 Hexagonal Architecture(Alistair Cockburn, 2005)와 Onion Architecture(Jeffrey Palermo, 2008) 등 여러 아키텍처의 핵심 아이디어를 종합해서 저희가 잘 알고 있는 동심원 다이어그램을 만들었습니다. 그리고 이것을 클린 아키텍처라고 이름 지었습니다.

 

클린 아키텍처가 탄생하기 이전에도 위와 비슷한 문제들이 있었고, 이를 해결하려는 엔지니어들의 고민과 노력으로 다양한 아키텍처들이 탄생했습니다. Uncle Bob은 이 중 일부 아키텍처의 각 특성과 장점, 핵심적인 공통점을 모아서 클린 아키텍처를 고안해낸 것입니다.

Uncle Bob이 참고한 아키텍처들은 아래와 같습니다.

 

• Hexagonal Architecture(Ports and Adapters) — Alistair Cockburn
• Onion Architecture — Jeffrey Palermo
• Screaming Architecture — Robert C. Martin
• DCI(Data, Context, Interaction) — James Coplien, Trygve Reenskaug
• BCE(Boundary-Control-Entity) — Ivar Jacobson

 

클린 아키텍처의 특징을 잘 이해하기 위해, Uncle Bob이 레퍼런스로 활용한 아키텍처들 중 헥사고날 아키텍처와 어니언 아키텍처를 먼저 살펴보겠습니다.

 

헥사고날 아키텍처

헥사고날 아키텍처(Hexagonal Architecture)의 원래 이름은 “Ports and Adapters Architecture” 입니다. 아키텍처 다이어그램의 모양이 육각형을 닮아서 헥사고날 아키텍처란 별명으로 잘 알려져 있습니다.

헥사고날 아키텍처는 Alistair Cockburn란 엔지니어가 고안해냈고, 비즈니스 로직이 UI나 DB 같은 외부 기술에 직접 의존하면서 외부 기술의 변경이 어려워지는 문제를 해결하기 위해 만들어졌습니다.

비즈니스 로직과 외부 기술을 분리하는 “경계”를 만들어 의존성을 낮추는 구조를 가집니다.

 

Hexagonal Architecture - 출처: happycoders.eu

 

위 그림에서 3가지 요소를 볼 수 있습니다.

• Application : 비즈니스 로직과 도메인 모델 등을 담은 레이어입니다.
  • 가장 안쪽에 위치합니다.
• Port : Application과 외부 기술 사이를 연결해주는 레이어입니다.
  • Application 레이어 가까이서 인터페이스로 구현되어, 둘 사이의 계약(Contract) 역할을 합니다.
  • Application이 외부 요소에게 요청하거나, 외부 요소가 Application에 접근할 작업이 명시되어 있습니다.
• Adapters : Port를 구현하는 구현체입니다.
  • DB에 접근하거나 API를 호출하는 코드 또는 객체가 여기에 해당됩니다.
  • 외부 요소가 Application에 접근할 때 사용되는 요소도 포함됩니다. (REST Controller, 테스트 코드 등)

가장 큰 특징은 "의존성의 방향이 항상 바깥에서 안쪽으로 향한다"는 것입니다.

Application은 Port(인터페이스)만 알고 바깥의 Adapter(구현체)는 모르기 때문에, 외부 기술(DB, UI 등)을 변경하더라도 Adapter만 변경하면 될 뿐, Application은 손 댈 필요가 없습니다.

 

헥사고날 아키텍처에 대해 더 자세히 알고 싶으시다면 아래의 글을 참고하세요.
https://alistair.cockburn.us/hexagonal-architecture
https://www.happycoders.eu/software-craftsmanship/hexagonal-architecture/

hexagonal-architecture

Hexagonal Architecture – What Is It? Why Use It?

 

어니언 아키텍처

어니언 아키텍처(Onion Architecture)는 Jeffrey Palermo라는 엔지니어가 2008년에 블로그 시리즈를 통해 제안한 아키텍처입니다. 다이어그램이 양파 껍질처럼 동심원 형태를 하고 있어서 어니언 아키텍처라는 이름이 붙었습니다.

 

어니언 아키텍처가 해결하려는 문제는 전통적인 레이어드 아키텍처(N-Layer Architecture)의 한계입니다.

전통적인 레이어드 아키텍처에서는 보통 UI → Business Logic → Data Access 순서로 의존성이 흐릅니다. 여기서 문제는, Business Logic 레이어가 Data Access 레이어에 직접 의존한다는 것입니다. 비즈니스 로직이 데이터를 어떻게 저장하고 가져오는지를 알고 있어야 하는 구조이기 때문에, 비즈니스 로직을 테스트하려면 실제 DB가 필요하고 인프라 기술을 바꾸면 비즈니스 로직도 영향을 받게 됩니다.

Palermo는 "인프라에 대한 관심사가 애플리케이션의 핵심을 오염시켜서는 안 된다"는 원칙을 세우고, 이를 구조적으로 강제하는 아키텍처를 설계했습니다.

 

Onion Architecture - 출처: jeffreypalermo.com

 

어니언 아키텍처는 안쪽에서 바깥쪽으로 갈수록 세부 사항에 가까워지는 동심원 형태의 레이어로 구성되어 있습니다.

• Domain Model (가장 안쪽) : 비즈니스의 핵심 엔티티와 값 객체가 위치합니다. 어떤 기술에도 의존하지 않는 순수한 도메인 모델입니다.
• Domain Services : 도메인 모델을 활용한 비즈니스 규칙을 수행합니다. 단일 엔티티에 속하지 않는, 여러 엔티티를 조합하는 비즈니스 로직이 이 레이어에 위치합니다.
• Application Services : 유스케이스를 조율하는 레이어입니다. 도메인 서비스를 호출하고, 트랜잭션을 관리하고, 외부와의 데이터 변환을 담당합니다.
• Infrastructure / UI (가장 바깥쪽) : DB, 외부 API, UI, 프레임워크 등 모든 외부 관심사가 여기에 위치합니다.

 

어니언 아키텍처 역시 "의존성은 항상 안쪽으로만 향한다"는 원칙을 따릅니다. 이 점은 헥사고날 아키텍처와 동일합니다.

다만 헥사고날과 비교해 차이가 있다면, 헥사고날은 안쪽(Application)과 바깥쪽(Adapter)의 경계를 Port/Adapter로 명확히 나누는 것에 초점을 맞추었고, 어니언은 안쪽 레이어를 Domain Model, Domain Services, Application Services로 더 세밀하게 나누어 "도메인이 모든 것의 중심이다"라는 것을 구조적으로 강조하고 있습니다.

 

어니언 아키텍처에 대해 더 자세히 알고 싶으시다면 아래의 글을 참고하세요.
https://jeffreypalermo.com/tag/onion-architecture/

onion architecture – Programming with Palermo

 

여러 아키텍처를 종합해 탄생한 클린 아키텍처

결국 두 아키텍처 모두 "비즈니스 로직을 외부 기술로부터 보호하자"라는 같은 문제의식에서 출발하고 있고, Uncle Bob은 이런 공통된 핵심 원칙을 종합해 클린 아키텍처를 탄생시킨 것입니다.

 

아주 닮아있는 세 아키텍처들

 

세 아키텍처의 다이어그램을 비교해보면 구조가 꽤 비슷하게 생겼죠? 그리고 클린 아키텍처의 다이어그램에서 두 아키텍처의 특징이 잘 나타나있습니다.

 

우선 다이어그램의 모양이 동심원인 것, 비즈니스 로직을 구현하는 부분을 2개의 레이어로 세분화한 것(Enterprise Business Rules, Application Business Rules)은 어니언 아키텍처의 특징이 드러납니다.

 

Interface Adapters 레이어와 Input & Output Port로 외부(External Interfaces)와 내부(Use Case)를 이어주는 구조는 헥사고날 아키텍처의 특징을 활용한 것 같습니다.

 

또한 가장 중요한 것, 세 아키텍처 모두 관심사가 분리되어있다는 점입니다. 위의 세 아키텍처 모두 소프트웨어의 구성 요소를 목적과 역할에 따라 여러 계층으로 나누어 관심사의 분리를 수행하고 있으며, 적어도 하나 이상의 비즈니스 규칙을 가진 레이어와 인터페이스를 포함한 레이어를 가지고 있습니다.

 

그리고 아래에서 설명할 클린 아키텍처의 핵심 원칙인 의존성 법칙, "의존성의 방향은 밖에서 안으로 향한다"는 규칙도 주요 특성 중 하나입니다.

 

클린 아키텍처의 구조

클린 아키텍처 다이어그램의 구조를 살펴보며 더 자세히 이해해봅시다.

 

Clean architecture - 출처: blog.cleancoder.com

 

클린 아키텍처는 동심원 형태의 4개 레이어로 구성되어 있습니다. 안쪽일수록 추상적이고 핵심적인 비즈니스 규칙을, 바깥쪽일수록 구체적인 기술 세부 사항을 담당합니다.

 

Enterprise Business Rules (Entities)

가장 안쪽에 위치하는 레이어로, 비즈니스의 핵심 규칙이 담겨있는 곳입니다.

이 규칙들은 소프트웨어의 존재 여부와 무관하게 성립하는 규칙입니다. 예를 들어 한 배송 서비스에서 “주문 금액이 2만원 이상이면 배송비가 무료다” 라는 규칙은 웹 페이지가 있든 없든, 모바일 앱이 있든 없든 서비스 자체에 존재하는 고유한 규칙이죠.

도메인 모델과 핵심 비즈니스 로직이 이 레이어에 위치하며, 순수한 프로그래밍 언어로만 작성됩니다. 어떠한 외부 프레임워크에도 의존하지 않습니다.

 

Application Business Rules (Use Cases)

애플리케이션 고유의 비즈니스 규칙을 캡슐화하는 레이어입니다.

Entities를 활용하여 데이터를 주고 받고, 특정 사용자 시나리오(Use Case)를 수행하는 역할을 담당합니다. 쉽게 이해하자면, Entities가 "무엇이 가능한가?"를 정의한다면 Use Cases는 "사용자가 실제로 어떤 흐름으로 그것을 수행하는가?"를 정의합니다.

해당 레이어 또한 외부 프레임워크에 의존적이지 않아야 하기에, 순수한 프로그래밍 언어로 작성되어야 합니다.

 

Interface Adapters (Controllers / Presenters / Gateways)

안쪽 레이어(Use Cases, Entities)와 바깥쪽 레이어(DB, 웹 등)의 데이터 형식을 서로 변환해주는 역할을 하는 레이어입니다.

외부 데이터 형식(SQL Row, JSON 등)을 내부 레이어에서 처리하기 적합한 형태로 변환하고, 그 반대 방향의 변환도 수행합니다. 다이어그램에서는 Controllers, Gateways, Presenters로 표현되어 있으며, 안드로이드에서는 ViewModel이 Presenter 역할, Repository 구현체가 Gateway 역할에 가깝다고 볼 수 있습니다.

 

Frameworks & Drivers (UI / Web / DB)

가장 바깥쪽에 위치하는 레이어로, 구체적인 구현 세부 사항을 담당합니다.

UI, DB, 웹, 외부 인터페이스, 디바이스 등이 이 레이어에 해당합니다. 안드로이드로 치면 Retrofit, Room, Activity/Fragment, SharedPreferences 같은 것들이 여기에 속합니다.

Uncle Bob은 이 레이어에는 glue code(접착 코드) 정도만 존재해야 한다고 말합니다. 가장 바깥에 있고, 가장 쉽게 교체될 수 있어야 하는 부분이기 때문입니다. 해당 레이어의 변경이 비즈니스 로직에 영향을 주어서는 안 됩니다.

 

클린 아키텍처의 핵심 원칙: 의존성 규칙

클린 아키텍처에서 가장 중요한 원칙, 바로 Dependency Rule(의존성 규칙)입니다.

의존성 규칙이란?

"소스 코드의 의존성은 반드시 안쪽을 향해야 한다. 안쪽 원에 속한 것은 바깥쪽 원에 대해 아무것도 알아서는 안 된다."
 - Robert C. Martin

 

의존성 규칙은 정말 단순합니다. 안쪽 레이어는 바깥쪽 레이어의 존재를 몰라야 한다는 것이 전부입니다.

구체적으로 말하면, 안쪽 레이어의 코드에서 바깥쪽 레이어의 클래스명, 함수명, 변수명, 데이터 형식 등 그 어떤 것도 알아서는 안 됩니다. Entities는 Use Cases를 모르고, Use Cases는 Controller나 Presenter를 모르고, Controller는 DB나 UI 프레임워크의 세부 구현을 모릅니다.

 

그런데 여기서 한 가지 의문이 생길 수 있습니다.

"안쪽이 바깥을 모른다면, 안쪽 레이어에서 바깥쪽 레이어의 기능이 필요할 때는 어떻게 하죠?"

 

예를 들어 Use Case에서 DB에 데이터를 저장해야 한다고 해봅시다. DB 접근 코드는 바깥쪽 레이어(Frameworks & Drivers)에 있습니다. 그러면 Use Case가 DB 접근 코드를 직접 호출해야 할텐데, 그럼 의존성 규칙을 위반하게 되겠죠.

 

이 문제를 해결하는 핵심이 바로 의존성 역전 원칙(Dependency Inversion Principle, DIP)입니다.

 

의존성 역전 원칙(DIP)으로 의존성 규칙 지키기

의존성 역전 원칙은 SOLID 원칙 중 하나로, 핵심을 한 줄로 요약하면 이렇습니다.

구체적인 것이 추상적인 것에 의존해야 한다. 추상적인 것이 구체적인 것에 의존해서는 안 된다.

 

조금 어렵게 느껴질 수 있으니, 코드 예시를 토대로 살펴보겠습니다.

Use Case가 DB에 데이터를 저장해야 하는 상황입니다. 의존성 규칙을 지키면서 이 문제를 해결하려면 어떻게 해야 할까요?

 

1단계 : 안쪽 레이어에서 인터페이스를 정의

Use Case 레이어에서 "나는 이런 기능이 필요해"라고 인터페이스(추상)를 정의합니다.

// Use Case 레이어에 위치하는 인터페이스
interface OrderRepository {
    fun save(order: Order)
    
    fun findById(id: Long): Order?
}

 

이 인터페이스는 "주문을 저장하고 조회하는 기능이 필요하다"는 것만 명시할 뿐, 그 기능이 어떻게 구현되는지, Room을 쓰는지, Retrofit으로 서버에 보내는지에 대해서는 전혀 알지 못합니다.

 

2단계 : 바깥 레이어에서 인터페이스를 구현

Use Case를 감싼 레이어인 Interface Adapters 레이어에서 이 인터페이스의 구현체(구체)를 만듭니다.

 

// Interface Adapters 레이어에 위치하는 구현체
class OrderRepositoryImpl(
    private val orderDao: OrderDao
) : OrderRepository {
    override fun save(order: Order) {
        orderDao.insert(order.toEntity())
    }

    override fun findById(id: Long): Order? {
        return orderDao.findById(id)?.toDomain()
    }
}

 

이렇게 하면 Use Case는 OrderRepository 인터페이스에만 의존하고, 실제 구현체인 OrderRepositoryImpl의 존재를 전혀 알지 못합니다. 의존성의 방향이 "바깥(구현체) → 안쪽(인터페이스)" 으로 향하게 되어, 의존성 규칙을 지킬 수 있게 되는 것입니다.

헥사고날 아키텍처에서 살펴봤던 Port와 Adapter의 관계가 기억나시나요? 여기서의 인터페이스가 Port, 구현체가 Adapter에 해당합니다.

 

의존성 규칙을 지키면 무엇이 좋은가?

의존성 규칙이 제대로 지켜지면 아래와 같은 이점을 얻을 수 있습니다.

 

1. 비즈니스 로직이 외부 변화로부터 보호

Room을 Realm으로 바꾸든, Retrofit을 Ktor로 바꾸든, 안쪽 레이어의 비즈니스 로직은 전혀 수정할 필요가 없습니다. 바깥쪽의 구현체만 교체하면 됩니다. 이것이 바로 클린 아키텍처가 처음부터 해결하고자 했던 문제이기도 합니다.

 

2. 테스트 가능

Use Case를 테스트할 때 실제 DB나 네트워크가 필요 없습니다. OrderRepository 인터페이스를 가짜 객체(Mock 또는 Fake)로 대체하면, 비즈니스 로직만 독립적으로 테스트할 수 있습니다.

// 테스트용 Fake 구현체, UseCase 테스트 시 해당 구현체를 주입시키면 된다.
class FakeOrderRepository : OrderRepository {
    private val orders = mutableListOf<Order>()

    override fun save(order: Order) {
        orders.add(order)
    }

    override fun findById(id: Long): Order? {
        return orders.find { it.id == id }
    }
}

 

3. 각 레이어가 독립적으로 개발·변경 가능

안쪽 레이어와 바깥쪽 레이어가 인터페이스로만 연결되어 있기 때문에, 서로의 구현 세부 사항을 신경 쓰지 않고 독립적으로 작업할 수 있습니다.

 

 

클린 아키텍처의 오해

클린 아키텍처는 개발 커뮤니티에서 굉장히 많이 언급되는 주제입니다. 그만큼 널리 알려져 있지만, 동시에 잘못 알려진 사실도 많습니다. 자주 마주치는 오해들을 하나씩 짚어보겠습니다.

 

아래의 글로부터 참고하였습니다.
https://codesuite.org/blogs/clean-architecture-misconceptions-and-a-better-approach-to-project-structure/
https://chaincoder.hashnode.dev/the-myth-of-the-clean-architecture
https://jamesmckay.net/2018/09/just-how-clean-is-uncle-bobs-clean-architecture

Clean Architecture: Misconceptions and a Better Approach to Project Structure

The Myth Of The Clean Architecture

Just how clean is Uncle Bob's Clean Architecture? - james mckay dot net

 

오해 1 : 레이어 개수는 무조건 4개여야 한다? ❌

클린 아키텍처 다이어그램을 보면 4개의 동심원이 그려져 있어서, 반드시 4개의 레이어로 나눠야 한다고 생각할 수 있습니다.

하지만 Uncle Bob은 이에 대해 명확하게 이야기하셨습니다.

“No, the circles are schematic. You may find that you need more than just these four. There’s no rule that says you must always have just these four. However, The Dependency Rule always applies.”
“이 원들은 단순한 예시일 뿐입니다. 실제로는 이 네 개만으로는 부족할 수도 있습니다. 반드시 이 네 개만 포함해야 한다는 규칙은 없습니다. 하지만 ‘의존성 규칙’은 항상 적용됩니다.”
— Robert C. Martin, Clean Architecture

 

클린 아키텍처 다이어그램의 4개 동심원은 단순 예시일 뿐, 반드시 4개로 나눠야 한다는 규칙은 없습니다. 즉, 프로젝트의 규모와 복잡도에 따라 레이어를 3개로 줄이거나, 5개 이상으로 늘릴 수 있습니다.

 

중요한 것은 레이어의 개수가 아니라, 어떤 구조를 선택하든 의존성의 방향이 반드시 안쪽으로 향해야 한다는 의존성 규칙을 지키고, 그리하여 비즈니스 로직을 외부 변화로부터 보호하는 것입니다.

 

오해 2 : 클린 아키텍처는 Uncle Bob이 발명한 새로운 아키텍처다? ❌

위에서 소개했듯, 클린 아키텍처는 헥사고날 아키텍처, 어니언 아키텍처, BCE 등 이전에 먼저 고안된 아키텍처들의 공통 원칙을 종합하고 정리한 것입니다. 즉, Uncle Bob이 클린 아키텍처의 구조와 핵심 원칙의 A-Z를 모두 처음부터 발명한 것이 아닙니다.

 

오해 3 : 특정 폴더 구조/프로젝트 구조를 따라야 한다? ❌

클린 아키텍처를 적용하기 위해 레이어 구조를 그대로 따라서 모듈 또는 폴더로 분리하는 경우가 있습니다. 하지만 이는 클린 아키텍처를 올바르게 적용하는 것이 아닙니다.

구체적인 폴더/패키지 구조에 대한 명확한 가이드라인은 없습니다. 따라서 어떤 프로젝트 구조가 정답이다라는 것은 없습니다. 단지 관심사의 분리에 따라 적절히 계층을 나누고 의존성 규칙을 잘 지키면 클린 아키텍처를 올바르게 적용하는 것입니다.

 

오해 4: 각 레이어를 별도의 프로젝트/모듈/폴더로 분리해야 한다? ❌

위의 오해와 관련이 있는 오해입니다.

많은 개발자들이 종종 다이어그램의 각 레이어가 별도의 프로젝트, 패키지, 또는 루트 폴더를 가져야 한다고 생각합니다. 하지만 이러한 방식은 실제로 Common Closure Principle(CCP)에 위배될 수 있습니다. CCP는 같은 이유로 변경되는 클래스들은 밀접하게 묶여있어야 한다는 원칙입니다.

 

만약 서로 관련있는 클래스들을 서로 다른 폴더, 프로젝트, 또는 패키지들에 흩어 놓으면, 이를테면 domain 모듈, data 모듈, ui 모듈 등으로 분리하면, 관련 있는 클래스들 간의 응집성이 깨지게 됩니다. 그렇게 되면 컴포넌트가 파편화되어 흩어지고, 오히려 유지보수와 업데이트가 복잡하고 오류가 발생하기 쉬운 엉망진창 코드가 되어버립니다.

클린 아키텍처의 동심원은 프로젝트나 폴더를 나타낸 것이 아니라, 서로 다른 수준의 정책(policy)을 나타낸 것이며, 의존성이 비즈니스 규칙을 향해 안쪽으로 향하는 것입니다.

 

오해 5 : 모든 경계에 반드시 인터페이스를 만들어야 한다? ❌

인터페이스의 적용은 의존성을 떨어뜨려 변경에 유리하게 작용하지만, 과도한 적용은 오히려 복잡한 코드 구조를 만들 수 있습니다.

Uncle Bob은 의존성 역전이 필요한 상황, 즉 실행 흐름이 안쪽에서 바깥쪽으로 향하는 경우에 인터페이스(Port)를 사용하여 소스 코드 의존성이 실행 흐름의 방향과 반대가 되도록 한다고 설명합니다. 즉, 인터페이스는 의존성 방향이 이미 안쪽을 향하고 있는 곳에서는 불필요할 수 있습니다.

 

오해 6 : 클린 아키텍처를 따르면 코드가 자동으로 이해하기 쉬워진다? ❌

클린 아키텍처의 원칙에 따라 의존성 규칙을 준수하고 관심사 분리에 따라 레이어로 나누어져 있더라도, 이것이 코드를 이해하기 쉬운 구조를 의미하는 건 아닙니다. 모든 의존성 규칙을 준수하면서도, 이 값은 어디서 오는지, 이 동작이 왜 존재하는지, 이 요청이 들어오면 실제로 무슨 일이 벌어지는지가 오히려 명료하지 않을 수 있습니다.

깔끔하다는 것이 항상 명료하다는 것을 나타내는 것은 아닙니다. 이는 클린 아키텍처에 대한 비판적인 의견들 중 하나입니다.

"Controller가 Use Case에 위임하고, Use Case가 인터페이스에 의존하고, 인터페이스는 Adapter가 구현하고, Adapter는 Gateway를 감싸고, Gateway는 프레임워크 호출을 감싼다. 데이터는 DTO, mapper, presenter, view model, response model을 거쳐 흐른다"
CHAINCODER의 글 중에서

제 생각에 이는 '객체 지향적 설계가 올바르게 적용되어 있는가?'와 더 관련있는 문제가 아닐까 합니다.

 

오해 7: 비즈니스 로직을 중심에 고정하면 변경에 유연해진다? 🤔

"중심을 신성시함으로써, Clean Architecture는 가장 자주 변경되는 코드를 가장 변경하기 어렵게 만든다. 이것은 정확히 거꾸로 된 것이다."
CHAINCODER의 글 중에서

사실 오늘날의 비즈니스 규칙이야말로 시장, 규제, 요구사항에 따라 자주 바뀔 수 있는 부분입니다. 이를 모든 것의 중심에 놓고 여러 레이어로 감싸면 오히려 변경 비용이 증가할 수 있다는 주장도 있습니다.

클린 아키텍처가 이루고자 하는 궁극적인 목표는 깔끔함(cleanliness)이 아니라 회복력(resilience)입니다. 회복력 있는 아키텍처는 변경을 대소동 없이 흡수하고, 실수가 발생해도 일부만 고치면 해결되게 만드는 것이죠. 하지만 그 구조에 너무 치부되면 오히려 변경에 유연하지 못한 소프트웨어로 변질될 수 있습니다.

구조적 설계도 중요하지만, 적절한 관용과 트레이드 오프가 필요할 수 있고, 이것이 변경에 대한 유연성을 가져다줄 수도 있는 것입니다.

 

---

 

마치며

 

지금까지 클린 아키텍처에 대해서 간단히 살펴보았습니다.

결국 클린 아키텍처가 해결하고자 한 문제는 변경이 쉽고 유연하게 대처할 수 있는, 회복력이 강하고 건강한 소프트웨어를 만드는 것입니다.

그리고 이를 위해 적절히 관심사를 분리하고, 의존성 규칙을 준수하는 것을 권장합니다.

동심원 구조나 이론적인 것에 너무 사로잡히지 않고, 프로젝트의 규모와 비즈니스의 방향, 그리고 함께 일하는 팀원들의 의견을 잘 고려하여 여러분만의 깔끔한 아키텍처를 만들어가는 것이 중요합니다.

 

Reference

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Clean Coder Blog

 

https://blog.cleancoder.com/uncle-bob/2011/11/22/Clean-Architecture.html

Clean Coder Blog

 

https://alistair.cockburn.us/hexagonal-architecture

hexagonal-architecture

 

https://www.happycoders.eu/software-craftsmanship/hexagonal-architecture/

Hexagonal Architecture – What Is It? Why Use It?

 

https://jeffreypalermo.com/tag/onion-architecture/

onion architecture – Programming with Palermo

 

https://codesuite.org/blogs/clean-architecture-misconceptions-and-a-better-approach-to-project-structure/

Clean Architecture: Misconceptions and a Better Approach to Project Structure

 

https://chaincoder.hashnode.dev/the-myth-of-the-clean-architecture

The Myth Of The Clean Architecture

 

https://jamesmckay.net/2018/09/just-how-clean-is-uncle-bobs-clean-architecture

Just how clean is Uncle Bob's Clean Architecture? - james mckay dot net