클린 아키텍처(Clean Architecture)

클린 아키텍처(Clean Architecture)

클린 아키텍처(Clean Architecture)는 소프트웨어를 유지보수가 쉽고, 확장 가능하며, 테스트하기 쉬운 구조로 설계하는 방법을 말합니다.
소프트웨어 설계의 원칙을 체계적으로 정리한 구조로, 로버트 C. 마틴(Robert C. Martin, 일명 ‘아저씨 마틴’)이 제안한 개념입니다.

1. 왜 클린 아키텍처가 필요할까요?

프로그램이 작을 때는 구조가 단순해도 문제없지만,
규모가 커지고, 여러 사람이 개발하고, 오랜 기간 유지해야 하는 경우에는
기능 간의 의존 관계가 복잡해져서 유지보수가 어려워집니다.

클린 아키텍처는 ‘의존성 역전(Dependency Inversion)’ 원칙을 중심으로,
비즈니스 로직과 외부 요소(데이터베이스, UI 등)를 분리해서 코드의 복잡도를 줄이고자 합니다.

2. 클린 아키텍처의 기본 구조

아래 구성처럼, 원형 구조로 표현됩니다.

[ 가장 안쪽 ]
- 엔터티(Entities): 핵심 비즈니스 규칙
- 유스케이스(Use Cases): 애플리케이션의 동작 규칙
- 인터페이스 어댑터(Interface Adapters): 외부와의 연결 (웹, DB 등)
- 프레임워크 & 드라이버(Frameworks & Drivers): 실제 동작 기술 (웹서버, DB 등)
[ 가장 바깥쪽 ]

각 계층 설명

1. Entities (엔터티)

시스템의 핵심 규칙과 개념 (예: 회원, 주문, 상품 등)

어떤 기술에도 의존하지 않음

2. Use Cases (유스케이스)

사용자의 요구를 처리하는 로직 (예: 회원가입, 로그인, 상품구매 등)

엔터티를 사용하여 실제 동작 구현

3. Interface Adapters (인터페이스 어댑터)

유스케이스와 외부 세계(DB, 웹 등) 사이를 연결하는 계층

예: 컨트롤러, 프레젠터, 레포지토리 인터페이스 등

4. Frameworks & Drivers (프레임워크와 드라이버)

웹 프레임워크(Flask, Django), 데이터베이스(MySQL 등) 같은 기술적인 도구들

이들은 가장 바깥에 있어야 하며, 안쪽 로직에 영향을 주지 않아야 함

3. 의존성 규칙 (Dependency Rule)

안쪽 계층은 바깥쪽 계층을 몰라야 합니다.
즉, 비즈니스 로직이 프레임워크에 의존해서는 안 됩니다.
대신, 바깥쪽에서 안쪽의 인터페이스를 구현하도록 설계합니다.

이런 구조를 통해,

UI가 바뀌어도 비즈니스 로직은 그대로

DB가 바뀌어도 핵심 로직은 영향 없음

테스트도 쉽게 가능

4. 클린 아키텍처의 장점

유지보수가 쉬움: 기능이 명확하게 분리되어 수정 시 영향이 작음

테스트 용이: 핵심 로직이 외부 의존이 없어 단위 테스트 가능

기술 교체가 쉬움: 웹 프레임워크, DB 등을 쉽게 교체 가능

협업에 유리: 역할이 명확히 나뉘어 여러 명이 나눠서 개발 가능

5. 단점 및 주의점

초기 설계와 구현이 복잡하게 느껴질 수 있음

작은 프로젝트에는 과도할 수 있음

팀 내 설계 원칙에 대한 이해가 필요함

마무리 요약