프로젝트를 처음 시작할 때 '어떤 아키텍처를 사용할 것인가'에 대한 논의를 한다.
그럴 때 항상 클린아키텍처와 구글 권장 아키텍처 사이에서 고민을 한다.
현재 아키텍처를 다르게 선택한 프로젝트 2개를 동시에 작업 중에 있다❗️
그 과정에서 느낀 각각의 아키텍처의 특징과 장단점 그리고 아키텍처를 선택할 때 고려해보면 좋은 점들을 이야기 해보자✨
🤍 클린 아키텍처 - 역할 분리의 끝판왕
개인적으로 클린 아키텍처는 '역할 분리의 끝판왕'이라고 생각한다.
이 구조를 처음 접했을 땐 “굳이 이렇게까지 나눠야 하나?” 싶은 마음이 컸다.
하지만 실제로 중장기 프로젝트를 운영해보면 이 구조가 얼마나 강력한 방패가 되어주는지 체감하게 된다.
💡 각 계층이 담당하는 역할
클린 아키텍처는 보통 다음과 같은 계층으로 나뉜다:
1️⃣ UI: 화면을 그리는 역할만 담당. 상태(State)를 관찰하고 UI로 표현하는 데 집중.
2️⃣ Presentation: ViewModel이 위치하는 계층. 유즈케이스를 호출하고 UI에 필요한 데이터 형식으로 가공한다.
3️⃣ Domain: 비즈니스 로직이 위치. 외부 의존성이 없고 테스트하기 용이하다.
4️⃣ Data: Repository 구현체와 Mapper가 위치. Remote API, Local DB 등 외부 데이터 소스와 직접 통신한다.
이렇게 각 계층이 명확히 책임을 나누고 있어 "이 로직은 어디에 위치해야 하지?" 같은 고민이 줄어든다. 내가 느끼기엔 이런 명확한 책임 분리가 “혼란 없는 개발”의 시작점이 되어주는 것 같다.
🧠 처음엔 복잡하게 느껴지지만…
물론 단점도 있다. 가장 큰 단점은 역시 초기 설계와 파일 수다.
작은 기능 하나를 추가해도 UI, ViewModel, UseCase, Repository, Mapper 등
5~6개의 파일이 기본적으로 생겨난다.
처음에는 이게 정말 번거롭게 느껴졌고 “이렇게까지 해야 하나?” 싶었다.
하지만 프로젝트가 커지고 여러 명이 함께 개발하게 되면서 이 구조의 진가가 드러나기 시작했다.
-
ViewModel에 모든 로직이 몰리지 않음
-
각 클래스가 자기 역할만 하니까 테스트도 쉬움
-
구조가 예측 가능하니 유지보수할 때 실수 확률도 줄어듦
오히려 시간이 갈수록 나중을 위한 체력 비축이라는 느낌이 들었다.
일종에 투자개념?
☑️ 내가 느낀 클린 아키의 핵심 포인트
✅ 규모가 커질수록 유지보수성은 압도적이다.
✅ 팀원이 많을수록 역할 분리가 큰 힘을 발휘한다.
✅ 테스트 코드 작성이 편하고 명확하다.
❌ 단기 개발이나 소규모 앱에는 오히려 과할 수 있다.
💚 구글 권장 아키텍처 – 효율성의 끝판왕
클린 아키텍처가 ‘역할 분리의 끝판왕’이라면
구글 권장 아키텍처는 ‘효율성의 끝판왕’이라고 부를 수 있을 것 같다.
공식 문서와 샘플 프로젝트들 대부분이 따르고 있는 이 구조는
ViewModel – Repository – DataSource 구조를 중심으로 단순하고 직관적이다.
실제로 프로젝트를 시작할 때 가장 빠르게 손에 익고 무엇보다 Compose와 궁합이 정말 좋다.
‼️ 구권아가 Compose와 궁합이 좋은 이유
구글 권장 아키텍처는 ViewModel 중심의 단방향 데이터 흐름을 기본으로 한다.
이 구조는 Compose의 선언형 UI 방식과 자연스럽게 연결된다.
🔸 ViewModel이 StateFlow로 상태를 관리하고
🔸 Compose는 그 상태를 collectAsState()로 관찰
🔸 UI는 상태 변화에 따라 자동으로 갱신된다 (Recomposition)
덕분에 별도의 LiveData나 DataBinding 없이도 상태 관리가 깔끔하고
구조적으로도 Compose와 충돌 없이 잘 동작한다.다시 아키텍처 이야기로 돌아와보자
💡 구단개속(구조가 단순 할수록 개발이 빠르다)
이 구조는 기본적으로 다음과 같은 구성으로 이루어진다:
1️⃣ ViewModel: 상태를 관리하고, Repository를 호출하는 중심.
2️⃣ Repository: 데이터를 불러오는 역할. API든 DB든 모두 여기를 거친다.
3️⃣ DataSource: 실제 API 통신이나 DB 쿼리를 담당하는 계층.
물론 클린 아키텍처처럼 계층이 세분화되진 않지만
이 단순함 덕분에 빠르게 구현하고 빠르게 검증할 수 있는 개발 사이클을 만들어준다.
🧠 내가 느낀 구글 권장 아키텍처의 장점
개인적으로 가장 크게 느낀 장점은 속도감이다.
✅ 구조가 직관적이라 새로운 기능을 빠르게 붙일 수 있음
✅ 설계보다 기능 개발에 집중할 수 있어서 MVP에 적합
✅ ViewModel에서 Compose 상태 관리가 자연스럽게 이어짐
✅ 공식 문서나 가이드가 잘 정리되어 있어 적용이 쉽다
특히 프로젝트 초기에 팀원들과 빠르게 개발을 진행할 때 이 구조는 정말 든든한 기반이 되어준다. 별다른 설명 없이도 각자 코드를 작성할 수 있으니까.
❗ 단점도 분명 존재한다
물론 효율성 중심의 구조다 보니 규모가 커지면 구조가 흐트러지기 쉬운 단점도 있다.
❌ ViewModel이 비대해지기 쉬움
❌ 관심사 분리가 명확하지 않으면 디버깅이 어려워짐
❌ 테스트 코드 작성 시 의존성이 많아짐
❌ 도메인 로직이 UI나 Repository에 섞여 들어가는 경우가 많음
예를 들어 ViewModel에서 API 호출, 에러 처리, 상태 관리, 필터링, 가공까지 다 하게 되면 그 코드가 쉽게 복잡해지고 유지보수가 어려워지는 상황이 온다.
처음엔 빠르고 효율적이었지만 어느 순간부터 “이게 맞나?” 싶은 시점이 찾아오게 된다.
☑️ 내가 느낀 구글 권장 아키의 핵심 포인트
✅ MVP나 데모 앱, 빠른 론칭용 프로젝트에 최적화
✅ 팀 규모가 작거나, 설계보단 실행이 중요한 경우 유리
❌ 하지만 규모가 커지면 반드시 구조적인 보완이 필요
❌ 관심사 분리 원칙을 어기기 쉬우므로 주의해야 한다
🧭 아키텍처, 프로젝트에 맞게 ‘선택’하는 것이 중요
두 가지 프로젝트를 동시에 진행해보며 가장 강하게 느낀 건 아키텍처는 무조건 정답이 있는 게 아니라 프로젝트의 특성에 따라 ‘선택’해야 한다는 거였다.
나는 실제로
❤️ 규모가 큰데도 구글 권장 아키텍처를 사용하는 프로젝트
💙 규모는 작지만 클린 아키텍처를 적용한 프로젝트
를 모두 경험해봤다.
❤️ 프로젝트가 크지만 구글 권장 아키를 사용한 경우
처음에는 구조가 단순하니 작업 속도도 빠르고 진입장벽도 낮았다.
하지만 프로젝트가 커질수록 한 클래스나 객체에 여러 책임이 얽히기 시작했고
그걸 분리하는 기준에 대해 팀원들과 지속적으로 논의하고 합의해야 했다.
특히 에러가 발생했을 때 문제의 원인을 명확히 파악하는 데 시간이 오래 걸리고,
책임이 분산되지 않아 디버깅도 쉽지 않았다.
💙 프로젝트가 작지만 클린 아키를 사용한 경우
반대로 프로젝트 규모는 작았지만 클린 아키텍처를 적용했을 땐
작은 기능 하나를 구현하더라도 생성해야 할 파일 수가 많아 부담이 컸다.
로직은 간단한데 UseCase, Repository, Mapper, UiState 등
관련 클래스가 과하게 많아지는 느낌이었고 결과적으로 앱 크기에 비해 보일러플레이트 코드가 많아졌다.
빌드 속도도 상대적으로 느려져서
“이 정도 프로젝트에 이 구조까지 필요한가?” 하는 고민이 들었다.
✍️ 결국 중요한 건 ‘상황에 맞는 선택’
그래서 나는 지금은 이렇게 생각한다.
“아키텍처는 기술 스택이 아니라 설계의 기준이다.”
✅ 빠르게 만들어야 하는 MVP라면 구글 권장 아키텍처
✅ 테스트와 유지보수가 중요한 서비스라면 클린 아키텍처
✅ 팀원이 적다면 단순한 구조
✅ 구조적 안정성이 필요하다면 계층 분리된 구조
무조건 하나가 더 낫다고 말하긴 어렵다.
그 대신 지금 내가 설계하는 이 프로젝트에 가장 적절한 구조는 무엇인가?
이 질문에 답할 수 있어야 한다고 생각한다.
🧩 결론 – 정답은 없지만 '기준'은 있어야 한다
아키텍처를 둘 다 써보면서 느낀 건
“이게 무조건 더 좋다”는 건 없다는 거였다.
하지만 내가 중요하게 생각하는 개발의 핵심은 ‘구조’다.
단순히 빠르게 만드는 것보다
어떤 흐름으로, 어떤 책임을 갖고, 어떤 방향으로 관리되는지가
앱의 ✨안정성과 ✨완성도를 좌우한다고 생각한다.
그래서 나는 지금도
“어떤 기능을 만들지”만큼이나 “어떻게 구조를 잡을지”에 많은 고민을 한다.
(코드리뷰로 이런 이야기를 나눌때가 요즘 가장 재미있다 ㅎ)
클린 아키텍처든, 구글 권장 아키텍처든
가장 중요한 건 ‘이 프로젝트에 어떤 구조가 맞는가’를 스스로 판단할 수 있는 기준이다.
- 프로젝트의 규모
- 유지보수 기간
- 팀원 수나 협업 구조
- 상태관리와 테스트 전략
이런 질문에 답하면서 구조를 고민하다 보면
결국은 어떤 아키텍처든 ‘내 것’이 되는 순간이 온다.
지금도 나는 여전히 고민하고 상황에 맞게 구조를 유연하게 바꾸기도 한다.
하지만 하나 확실히 말할 수 있는 건
좋은 구조는 결국 좋은 코드를 만든다.
그리고 좋은 코드는 좋은 팀을 만들고 좋은 서비스를 만든다.
이 글이 아키텍처 선택 앞에서 고민 중인 개발자분들께 도움이 되었으면 좋겠다:)
