나만의 안드로이드 앱 만들기(중급자 편) - 클린 아키텍쳐 개요(clean architecture)

 

안드로이드 개발을 하다 보면, 앱의 규모가 커지고 복잡해지면서 유지보수가 어려워지는 경우가 종종 발생합니다. 이러한 문제를 해결하기 위해 클린 아키텍처를 적용하는 것이 좋습니다.

 

또한 안드로이드에서는 테스트 코드를 작성하기 위해서도 필요한 아키텍쳐 입니다.

 

Clean Architecture 는 유지보수성, 테스트 용이성, 확장성 등을 강조하여 소프트웨어의 품질을 향상시키는 데 도움이 됩니다. 이러한 목표를 달성하기 위해 소프트웨어를 몇 가지 독립적인 레이어로 분리하고, 각 레이어 간의 의존성을 최소화하는 방식으로 설계됩니다.

 

핵심 원칙은 다음과 같습니다.

 

 

• 의존성 역전의 원리 (Dependency Inversion Principle)
  • 의존성 역전의 원리는 상위 수준 모듈이 하위 수준 모듈에 의존하면 안 되며, 둘 모두 추상화에 의존해야 한다는 원칙입니다. 이를 통해 시스템의 유연성을 향상시키고, 변경에 대한 저항력을 높입니다.
• 단일 책임 원칙 (Single Responsibility Principle)
  • 클래스는 단일 책임을 가져야 하며, 클래스의 변경 이유는 하나여야 합니다. 이를 통해 코드의 응집성을 높이고, 유지보수를 쉽게 만듭니다.
• 개방/폐쇄 원칙 (Open/Closed Principle)
  • 소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장 가능하되 수정 불가능해야 합니다. 즉, 새로운 기능을 추가할 때는 기존 코드를 수정하지 않고 확장할 수 있어야 합니다.

 

Clean Architecture는 다음과 같이 여러 레이어로 구성됩니다.

 

• 도메인(Domain) 레이어
  • 도메인 레이어는 Clean Architecture에서 가장 안쪽에 위치하며, 핵심 비즈니스 로직을 담당합니다. 이 레이어는 시스템의 핵심 개념인 엔터티와 밸류 객체, 그리고 유즈케이스를 포함합니다.
  • Entity
    
    • Entity 는 시스템의 핵심 비즈니스 객체로, 유일한 식별자를 가지고 있습니다. Entity 는 도메인의 핵심 업무 규칙을 표현하고 데이터의 일관성을 유지하는 역할을 합니다.
  • Value Object
    • Value Object 는 Entity 와 다르게 고유한 식별자를 가지지 않고, 값 자체로 식별됩니다. 주로 도메인 내에서 의미 있는 개념을 표현할 때 사용되며 불변성(Immutable)을 가지고 있습니다.
  • UseCase
    
    • UseCase 는 시스템의 사용자가 어떤 목적을 달성하기 위해 수행하는 특정한 작업을 나타냅니다. 비즈니스 로직이 주로 담겨 있는 부분으로, Entity 와 Value Object 를 조합하여 특정 기능을 수행합니다.
• 데이터(Data) 레이어
  • 데이터 레이어는 도메인 레이어와 외부 시스템 사이에서 데이터의 입출력을 처리하는 역할을 합니다. 데이터 레이어는 데이터베이스, 외부 API, 파일 시스템과의 상호 작용 등을 담당합니다.
  • Repository
    • Repository는 도메인 레이어에서 필요로 하는 데이터를 저장하고 검색하는 역할을 합니다. 데이터의 영속성을 담당하며, 도메인 레이어의 엔터티와 밸류 객체를 데이터베이스와 연결합니다.
  • DataSource
    
    • DataSource는 도메인 레이어의 엔터티와 데이터베이스 스키마 간의 매핑을 담당합니다. 이는 도메인 레이어와 데이터베이스 간의 결합을 최소화하고, 도메인 모델이 데이터베이스에 종속되지 않도록 합니다.
• 프레젠테이션(Presentation) 레이어
  • 프레젠테이션 레이어는 사용자와의 상호 작용을 담당하며, 도메인 레이어와 사용자 인터페이스 간의 상호 작용을 조율합니다.
  •  뷰모델(ViewModel)
    • 컨트롤러 또는 프레젠터는 클라이언트(웹 브라우저, 모바일 앱 등)에서 들어오는 요청을 받아 유즈케이스를 호출하고, 그 결과를 사용자에게 적절하게 보여주는 역할을 합니다.
  • 뷰(View)
    • 뷰는 사용자 인터페이스를 담당하며, 컨트롤러 또는 프레젠터에서 전달받은 데이터를 사용자에게 표시합니다. 뷰는 사용자 입력을 컨트롤러 또는 프레젠터에 전달하여 상호 작용이 이루어지게 합니다.
  • 프레젠테이션 모델(Presentation Model)
    • 프레젠테이션 모델은 도메인 레이어의 Entity 와 Value Object 를 프레젠테이션 레이어에서 사용할 수 있도록 변환하는 역할을 합니다. 이는 도메인 레이어와 프레젠테이션 레이어 간의 결합을 최소화하고, 화면에 필요한 데이터를 제공합니다.

 

이러한 3계층 구조로 Clean Architecture를 설계하면, 각 레이어가 독립적으로 변경될 수 있으며 시스템의 유지보수성과 확장성이 향상됩니다.

 

Clean Architecture의 장점

 

• 유지보수성 향상
  • 각 레이어가 독립적이므로 하나의 레이어의 변경이 다른 레이어에 미치는 영향을 최소화합니다.
• 테스트 용이성
  • 비즈니스 룰은 독립적으로 테스트할 수 있으며, 외부 의존성을 모의(mock)로 대체하기 용이합니다.
• 확장성
  • 새로운 기능이나 요구 사항이 추가될 때 적은 수정으로 시스템을 확장할 수 있습니다.

 

 

Clean Architecture의 단점

 

Clean Architecture 는 장점 만큼이나 단점도 만만치 않습니다.

 

• 복잡성 및 추가 작업
  • Clean Architecture를 구현하려면 세부적인 레이어 간의 상호작용을 관리하는 추가적인 코드 및 구조를 작성해야 합니다. 이로 인해 초기에는 구현에 대한 부담이 있을 수 있습니다.
• 높은 러닝커브
  
  • Clean Architecture는 처음에는 이해하기 어려울 수 있습니다. 특히, 새로운 개발자나 팀에게는 적응하기에 시간이 걸릴 수 있습니다. 기존의 전통적인 아키텍처에 익숙한 팀이라면 변화를 수용하는 데 일정한 노력이 필요할 수 있습니다.
• 오버 엔지니어링 위험
  • 모든 프로젝트가 Clean Architecture의 수준의 복잡성과 유연성을 필요로 하는 것은 아닙니다. 작은 규모의 프로젝트나 간단한 애플리케이션에서는 Clean Architecture가 오버 엔지니어링일 수 있습니다.
• 프로젝트 크기와 적절성
  • Clean Architecture는 대규모 프로젝트나 중요한 비즈니스 로직을 가진 프로젝트에서 높은 가치를 제공할 수 있습니다. 그러나 작은 규모의 프로젝트에서는 오히려 부가적인 복잡성을 가져올 수 있습니다.
• 개발 속도의 감소
  • Clean Architecture의 엄격한 규칙을 따르면서 개발할 경우, 빠른 개발 속도를 위해 어떤 규칙을 유연하게 적용해야 할 지를 고민해야 합니다. 일부 프로젝트에서는 개발 속도가 상대적으로 감소될 수 있습니다.

 

결론

Clean Architecture는 소프트웨어 개발에서 중요한 아키텍처 패턴 중 하나로, 유연하고 테스트 가능하며 유지보수성이 높은 소프트웨어를 설계하기 위한 강력한 도구입니다. 이러한 아키텍처 원칙을 적용하여 프로젝트를 진행하면, 복잡한 소프트웨어 시스템에서도 변경에 대한 저항력을 유지하고 효율적으로 개발할 수 있습니다.

 

다음 편에서는 클린 아키텍쳐를 직접 적용해보도록 하겠습니다.

 

감사합니다.