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

 

안드로이드 프로젝트를 진행하며 클린 아키텍처를 기반으로 구현을 하게 되었는데요

처음엔 너무 대체 이게 뭐지..? 싶었던 클린 아키텍처를 차근차근 정리해보려고 합니다

오늘은 우선 클린 아키텍처의 개념부터 정리해보겠습니다 :) 

 

 

👩🏻‍💻 클린 아키텍처(Clean Architecture)란 ?

클린 아키텍처란 개발자들 사이에서 유명한 책인 '클린 코드 (Clean Code)'를 저술한 로버트 마틴(Robert C.Martin)이 제안한 시스템 아키텍처로, 복잡한 소프트웨어 시스템 관리를 용이하게 하고 기존의 아키텍처들이 가지던 의존성에서 벗어나도록 하는 설계를 제공합니다.

 

주요 원칙

클린 아키텍처의 주요 원칙은 아래와 같습니다

 

1. 의존성 역전 원칙 (Dependency Inversion Principle)

고수준 모듈은 저수준 모듈에 의존하지 않아야 하며, 두 모듈은 모두 추상화에 의존해야 한다.

이는 고수준 모듈이 저수준 모듈의 구체적인 구현에 얽매이지 않고, 오히려 추상화를 통해 상호작용하도록 하여 코드를 더 유연하게 만듭니다.

 

 

2. 경계(Boundary)의 분리

시스템의 각 모듈에서 책임을 명확히 나누어 관리하여 독립성을 보장합니다.

 

특히 클린 아키텍처에서는 경계를 중요하게 생각하는데요,

소프트웨어 아키텍처는 선을 긋는 기술이며, 나는 이러한 선을 경계(boundary)라고 부른다.
경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다.
- Robert C. Martin, Clean Architecture

 

이러한 경계 덕에 각 기능의 독립성을 높여주고 유지보수를 보다 용이하게 할 수 있습니다.

 

3. 인터페이스 분리 원칙 (Interface Segregation Principle)

클라이언트가 사용하지 않는 인터페이스에 의존하지 않도록 해야 합니다.

즉, 특정 기능이 필요하지 않은 클라이언트는 그 기능을 포함한 인터페이스를 강제로 구현할 필요가 없어야 하며, 인터페이스는 클라이언트의 요구에 맞게 작게 분리되어야 합니다.

 

 

 

 

클린 아키텍처 구조를 설명하는 가장 유명한 사진인데요,

이 사진을 통해 위에서 설명한 주요 원칙을 다시 살펴보자면

 

 

1. 의존성 역전 원칙 (Dependency Inversion Principle)

화살표의 방향은 의존성의 방향을 의미합니다.

 

의존성은 바깥에서 안쪽을 향하며 바깥에 위치할 수록 (저수준 모듈) 덜 중요하고 세부적으로 표현되며,

안쪽에 위치할 수록 (고수준 모듈) 추상화된 개념으로 표현됩니다.

 

이렇게 하면 고수준 모듈이 저수준 모듈에 의존하지 않게 됩니다.

 

2. 경계(Boundary)의 분리

프레임워크와 드라이버, 인터페이스 어댑터, 애플리케이션 업무 규칙, 엔터프라이즈 업무 규칙으로 크게 4가지로 경계를 나누어 각자의 독립성을 보장합니다.

 

각 계층을 간단하게 설명하자면

 

엔터프라이즈 업무 (엔티티)

- 핵심 업무 규칙을 캡슐화

- 외부로부터 가장 영향을 받지 않는 영역

- 메서드를 가지는 객체, 데이터 구조와 함수의 집합

 

애플리케이션 업무 (유즈케이스)

- 시스템의 모든 유즈케이스를 캡슐화 하고 구현

- 엔티티로 들어오고 나가는 데이터의 흐름을 조작

 

인터페이스 어댑터 (컨트롤러, 프레젠터, 게이트 웨이)

- 외부 인터페이스에서 들어오는 데이터를 유즈케이스와 엔티티에서 처리하기 편한 방식으로 변환

- 반대로 유즈케이스와 엔티티에서 나가는 데이터를 외부 인터페이스에서 처리하기 편한 방식으로 변환

 

프레임워크와 드라이버 (외부 인터페이스, DB, UI 등)

- 시스템의 핵심 업무와는 상관 없는 세부 사항

 

이렇게 각 계층에 해당하는 요소들은 다른 계층에 있는 요소를 알지 못합니다.

 

3. 인터페이스 분리 원칙 (Interface Segregation Principle)

중간에 있는 인터페이스 어댑터를 통해 필요한 기능에 메서드만 구현합니다.

이를 통해 새로운 기능이 추가되거나 변경이 발생할 때, 기존의 인터페이스에 영향을 주지 않고 새로운 인터페이스를 추가함으로써 시스템을 확장할 수 있습니다.

 

 

 

그렇다면 많은 아키텍처들 중 왜 클린 아키텍처를 사용해야 할까요?

 

 

 

 

 

🤔 클린 아키텍처를 사용해야 하는 이유

 

소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 ‘부드러워’야 한다.
다시 말해 변경하기 쉬워야 한다.
이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 쉽게 적용할 수 있어야 한다.
- Robert C. Martin, Clean Architecture

 

 

로버트 마틴의 말을 보면 소프트웨어는 변경하기 쉬워야 한다 라고 하는데요,

이는 각 경계가 명확히 분리되어 있어 독립적으로 개발이 가능하도록 해주는 클린 아키텍처가 가지고 있는 가장 큰 장점인 것 같습니다.

 

이러한 장점은 시스템의 변경이나 업그레이드가 필요할 때 전체 시스템을 다시 작성하지 않아도 되며, 특정 부분만 수정하는 것이 가능하게 해줍니다

 

예시를 통해 설명을 해보자면

우리의 프로젝트가 출시가 되었다!

그런데 새로운 버전을 내며 DB가 수정되었다
그리고 우리의 서비스를 앱에서 웹으로 확장하려고 한다

 

이때 우리는 엔터프라이즈 업무와 애플리케이션 업무는 수정할 필요 없이 프레임워크와 드라이버, 인터페이스 어댑터만 수정하면 된다.

이렇게 클린 아키텍처는 기존의 비지니스 로직은 건들지 않고 DB와 프레임워크에 구애받지 않고 교체할 수 있습니다.

 

 

장점을 조금 더 구체적으로 3가지로 나눠보자면

 

1. 유지보수성 (Maintainability)

- 각 계층이 명확한 역할과 책임을 가지므로, 필요한 부분만 수정이 쉬워 유지보수가 용이합니다.

- 특정 기능이나 모듈의 변경이 다른 부분에 미치는 영향을 최소화합니다.

 

2. 테스트 용이성 (Testability)

- 각 계층이 서로 독립적이므로, *유닛 테스트와 *통합 테스트를 독립적으로 수행할 수 있습니다.

- 인터페이스를 통해 의존성을 관리함으로써, 실제 구현체 대신 모의 객체를 사용하여 테스트할 수 있습니다. 이를 통해 테스트가 더 간단해집니다.

 

*유닛테스트 : 애플리케이션의 개별 구성 요소(또는 유닛)를 독립적으로 테스트하여, 해당 유닛이 예상대로 동작하는지 검증하는 과정으로 일반적으로 함수나 메서드 단위로 진행됩니다.

*통합 테스트 : 여러 유닛 또는 모듈이 함께 작동하는지를 검증하는 테스트입니다. 유닛 테스트가 개별 구성 요소를 독립적으로 검증하는 반면, 통합 테스트는 이들이 결합되었을 때 올바르게 상호작용하는지를 확인합니다.

 

3. 유연성 (Flexibility)

 

- 외부 라이브러리나 프레임워크에 대한 의존성을 줄일 수 있어 DB나 프레임워크가 변경되어도 코드 변경이 최소화됩니다.

- 새로운 기능을 추가하거나 기존 기능이 변경될 때 변경의 범위가 최소화됩니다.

 

 

이러한 장점들로 인해 요즘 클린 아키텍처가 굉장히 많이 사용되고 있습니다 !

 

 

 

 

 

 

🍀 마무리

아키텍처가 워낙 추상적인 개념이기도 하고 클린 아키텍처를 처음 접했을 땐 몇 번을 읽어도 이해가 어려웠었는데요

이를 안드로이드에 다시 적용해보고 직접 코드에 적용해보니 조금씩 와닿았던 것 같습니다

 

더 구체적인 부분들과 안드로이드에 적용한 부분은 따로 또 정리해보겠습니다 !