안드로이드 주니어 개발자의 클린아키텍처 도입기 (1)

안녕하세요! 팀 호남향우회의 프론트엔드 개발을 맡고 있는 포케입니다.

처음 구조를 정하지 않고 프로젝트를 시작하게 되면 어느새 늘어나 있는 코드들과 건들기 어려운 상황을 볼 수 있습니다. 저희 팀은 초기부터 운영을 목표로 프로젝트를 진행했기 때문에 유지보수성과 확장성을 위하여 구조를 확실하게 정하고 가야 한다고 생각하였습니다.

저희 프론트엔드팀은 클린 아키텍처 + MVI 패턴을 결합한 구조를 선택하였습니다! 이번 포스팅에서는 클린 아키텍처의 개념을 설명하고자 합니다.

클린 아키텍처가 궁금한가요?

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

클린 아키텍처란?

소프트웨어 설계 패턴 중 하나로 Robert C. Martin(일명 “Uncle Bob”)이 제안한 개념입니다. 클린 아키텍처는 시스템을 독립적인 계층으로 분리하여 모듈화하고, 각 계층 간의 의존성을 명확하게 정의하여 유지보수성과 확장성을 높이는 형태를 제공합니다.

clean architecture

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

주요 원칙

  1. 의존성 역전 원칙 (DIP: Dependency Inversion Principle)
    상위 수준 모듈은 하위 수준 모듈에 의존하지 않고, 추상화에 의존합니다. 이는 시스템의 주요 비즈니스 로직이 세부 구현 사항에 종속되지 않도록 합니다. 예를 들어, 비즈니스 로직을 구현한 서비스는 데이터베이스나 네트워크 API 같은 하위 모듈에 직접 의존하지 않고, 인터페이스나 추상 클래스에 의존하여 의존성을 역전시킵니다.

  2. 경계(Boundary)의 분리
    시스템을 여러 영역으로 나누고, 각 영역 사이의 인터페이스를 정의하여 각 영역의 독립성을 보장합니다. 이러한 경계 분리를 통해 서로 다른 부분이 독립적으로 변경될 수 있으며, 각 영역은 자신만의 책임과 역할을 가집니다. 이는 시스템의 복잡성을 줄이고 유지보수성을 높이는 데 도움이 됩니다.

  3. 인터페이스 분리 원칙 (ISP: Interface Segregation Principle)
    클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않아야 합니다. 즉, 인터페이스는 클라이언트의 요구에 딱 맞는 형태로 분리되어야 합니다. 이렇게 하면 각 클라이언트는 자신이 필요로 하는 기능만을 가지는 인터페이스를 구현하게 되어, 변경의 영향을 최소화할 수 있습니다. 이는 시스템의 유연성과 확장성을 높입니다.

클린 아키텍처의 계층

호남향우회 팀은 에그로그 서비스에 클린 아키텍처를 적용하며 Presentation Layer, Domain Layer, Data Layer로 계층화하였습니다. (구현 내용이 궁금하다면 2부를 봐주세요) 각 계층의 역할은 다음과 같습니다.

  1. Presentation Layer

    • 역할: 사용자 인터페이스 및 사용자 상호작용을 처리합니다.
    • 내용: 이 계층은 UI 컴포넌트, 뷰모델, 프레젠터, 컨트롤러 등으로 구성됩니다.
    • 책임: 사용자 입력을 처리하고, 도메인 계층에 요청을 전달하며, 도메인 계층으로부터 받은 데이터를 표시 형식으로 변환하여 사용자에게 보여줍니다.
  2. Domain Layer
    • 역할: 애플리케이션의 핵심 비즈니스 로직과 규칙을 정의합니다.
    • 내용: 엔티티, 유스케이스, 인터랙터 등이 포함됩니다.
    • 책임: 비즈니스 규칙을 구현하고, 데이터 처리 로직을 수행하며, 애플리케이션의 상태를 관리합니다. 도메인 계층은 다른 계층에 의존하지 않고, 오직 자체의 비즈니스 로직에만 집중합니다.
  3. Data Layer
    • 역할: 데이터 소스와의 상호작용을 담당합니다.
    • 내용: 리포지토리, 데이터 소스, 데이터 매퍼 등이 포함됩니다.
    • 책임: 네트워크 요청, 데이터베이스 쿼리 등 실제 데이터 접근 로직을 처리합니다. 데이터 계층은 도메인 계층에 데이터를 제공하며, 도메인 모델과 데이터 모델 간의 변환을 수행합니다.

총평

결론적으로 클린 아키텍처를 미리 구성하는 것은 장기적인 관점에서 프로젝트의 성공과 효율적인 유지보수를 위한 중요한 기반을 마련할 수 있었습니다. 하지만 처음 안드로이드를 개발해 보는 혹은 아직은 미숙한 주니어 개발자의 입장에서는 다소 시간이 소요될 수 있지만 그만한 가치가 있다고 생각합니다. 이 포스팅을 보시는 분 중 클린아키텍처를 적용해 볼지 하는 고민이 든다면 개발 시간이 여유로운지를 고려해 보시는 것이 좋을 것 같습니…….다.

마무리

클린 아키텍처를 적용해 보며 구조를 적용하는 게 괜찮은 방식일까 하는 의구심도 시도 때도 없이 가졌던 것 같습니다. 막상 적용하고 프로젝트의 기반을 갖춘 지금 바라보았을 때 이 구조를 가지고 가지 않았다면 코드가 얼마나 엉망이었을지 상상하기도 싫네요… 네 그러면 다음 포스팅에서 클린 아키텍처를 프로젝트에 어떤 식으로 적용했는지에 대해 만나보도록 하겠습니다. 2부에서 만나요

Discussion and feedback