피드로 돌아가기
올리브영 테크블로그Mobile
원문 읽기
올리브영 앱 - 아키텍처 도입 1탄
올리브영이 God Class와 강한 결합도를 가진 레거시 Android/iOS 앱을 3-layer 클린 아키텍처(Presentation, Domain, Data)로 리구성해 관심사 분리 및 코드 유지보수성 개선
AI 요약
Context
Android, iOS 앱이 God Activity/ViewController와 God Object로 인해 강하게 결합되어 있었고, 관심사 분리가 없어 코드 분석이 어려웠으며, 간단한 기능 수정 시에도 사이드 임팩트를 우려해야 하는 상황이었다. 팀은 눈앞의 이슈 처리로 인해 구조 개선을 미루고 있었으나, 앱 성능 개선이라는 과제를 계기로 아키텍처 개선을 추진하기로 결정했다.
Technical Solution
- Presentation Layer 도입: View는 UI 화면 표시와 입력 처리만 담당하고, Presenter(ViewModel)가 UseCase 실행 판단 및 UI 업데이트 수행
- Domain Layer 설계: UseCase가 앱에 특화된 업무 로직을 캡슐화하고, Model이 순수 업무 데이터를 정의하며, Repository Interface가 Data Layer 구현과의 경계 설정
- Data Layer 구조화: Repository가 Domain에서 정의한 Interface를 구현하고, DataSource가 실제 데이터 입출력 방식(API, DB, 파일)을 추상화
- 의존성 규칙 적용: 소스코드가 안쪽(Domain)을 향해서만 의존하도록 강제하여 외부 변경(UI, 데이터소스)이 내부 비즈니스 로직에 영향을 주지 않도록 격리
- 크로스플랫폼 일관성: Android와 iOS 모두 동일한 Domain Layer와 Data Layer 설계를 적용하여 두 플랫폼 개발자가 동일한 비즈니스 로직 구조로 협업 가능
Key Takeaway
클린 아키텍처 도입 시 계층 분리의 주요 가치는 외부 변화(UI, 데이터소스)로부터 비즈니스 로직을 보호하는 것이며, 특히 Domain Layer는 정답이 없는 지속적 리팩토링 대상이지만 UI나 백엔드 데이터 변화로부터 프로젝트 전체가 영향받는 것을 방지하는 필수 계층이다.
실천 포인트
강한 결합도를 가진 모바일 앱 프로젝트를 리구성할 때, Presentation/Domain/Data의 3-layer 클린 아키텍처를 도입하되 각 계층이 의존성 규칙을 준수하도록 하면 UI 변경 시 비즈니스 로직 수정을 최소화할 수 있고, 팀 규모가 커질수록 크로스플랫폼 간 설계 일관성을 유지해 온보딩과 협업 효율을 높일 수 있다.