MVVM가 유리한 환경
소규모/짧은 일정 : 1–3명, MVP·해커톤·프로토타입. 빨리 찍고 학습이 목적인 경우.
도메인 단순 : CRUD 위주, 복잡한 비즈니스 규칙/정책이 거의 없음.
변화 범위가 UI 중심 : 뷰/상호작용이 자주 바뀌지만, 핵심 규칙은 얕음.
테스트 범위가 제한적 : 핵심 1~2 로직만 단위 테스트면 충분.
외부 연동이 단순: 단일 REST API, 버전 변동 적음.
출시 후 대규모 확장 계획이 불확실 : 처음엔 가볍게 가고, 필요하면 이후 계층 분리.
클린 아키텍처가 유리한 환경
중/대규모/장기 : 팀 4명+, 기능 라인 병렬 개발, 버전 2/3가 확정적.
도메인 복잡 : 결제/권한/캘린더·타이머 규칙/오프라인 동기화/여러 정책(국가별, 유저 타입별).
변화 축이 여러 개 : UI는 계속 바뀌고, 데이터 소스/비즈니스 규칙도 잦게 바뀜.
강한 테스트 요구 : 유즈케이스/도메인 단위로 UI 없이도 테스트하고 싶음.
외부 연동 다양 : REST + GraphQL + 로컬 캐시 + 백그라운드 작업 + 알림 등 데이터 소스 교체/복수화가 예정.
멀티 플랫폼 : iOS, watchOS, 위젯/익스텐션, 향후 macOS 공유 고려(도메인 재사용).
규칙이 자주 바뀌거나 복잡해질 것 같다 → 클린
UI를 빨리 실험해야 한다. 규칙 단순 → MVVM
도메인 규칙이 3개 이상으로 얽혀 있다 (타이머 + 캘린더 + 알림 정책) → 클린
외부 데이터 소스 교체 가능성 높다 (CoreData↔Realm↔CloudKit) → 클린
팀원이 병렬 개발해야 한다 (UI/도메인/데이터 분업) → 클린
4주 미만 일정의 MVP, 데모, PoC → MVVM
유지보수자가 1~2명, 배포 후 큰 확장 계획 없음 → MVVM
구조 비교
MVVM(가벼운 형태)
View ↔ ViewModel ↔ Service/Repository(합쳐도 됨)
DI는 간단한 초기자 주입 정도.
폴더 : UI/Feature + Services + Models
클린 아키텍처(전형)
Presentation(ViewModel)
Domain(Entities, UseCases, Repository Interfaces)
Data(Repository Impl, DataSources: Remote/Local)
DI 레이어 또는 컴포지션 루트 필요.
멀티 모듈이면 App / Presentation / Domain / Data 로 분리.
보일러플레이트가 늘어나는 지점들 (클린)
UseCase 파일 : 유즈케이스당 프로토콜/구현 1~2개씩 증가
Repository 인터페이스/구현 분리 : Domain에 인터페이스, Data에 구현
데이터 소스 계층화 : RemoteDataSource, LocalDataSource
매핑 코드 : DTO ↔ Entity ↔ ViewModel 변환자(Mapper)
DI/조립 코드 : 각 레이어 연결(팩토리/컴포지션 루트)
테스트 더블 : 인터페이스가 늘면서 Mock/Fake/Stub 파일 증가
대가 : 파일 수/초기 세팅은 늘지만, 변경 충격 최소화 + 테스트 용이 + 교체 용이를 얻음.
