좌충우돌: 사장님 Plus App Architecture 전환기

화면마다 router, interactor, component, builder protocol을 만들면 test boundary와 dependency injection은 좋아진다. 반면 작은 feature에도 file과 연결 code가 크게 늘고 navigation flow를 따라가기 어렵다. 실제 변경 frequency와 신규 developer onboarding 시간을 측정해 over-engineering 지점을 찾는다.

Composable Architecture는 unidirectional state와 effect를 일관되게 제공하지만 새로운 concept·library dependency와 migration 비용이 있다. 회사의 다른 iOS app이 사용하는 MVVM은 익숙하고 인력 이동에 유리하다. State complexity, test 방식, module 구조와 장기 ownership을 표로 비교한다.

담당자가 고정돼 있을 때는 RIBs 숙련도가 유지됐지만 service 간 인력을 유동적으로 배치하려 하자 높은 learning curve가 병목이 됐다. TCA도 같은 위험을 만들 수 있어 새 framework의 기능보다 조직이 지속 교육·지원할 수 있는지를 본다. Architecture 선택을 hiring·rotation constraint와 연결한다.

Foundation·core·feature module과 business use case가 이미 separation을 제공하고 async/await로 callback code도 줄어 view model이 과도하게 커질 위험이 낮았다. 회사 공통 MVVM으로 맞춰 재사용과 인력 이동을 높인다. 결론은 가장 강력한 pattern보다 product 규모에 맞고 팀이 일관되게 지킬 수 있는 구조를 선택하는 것이다.