오경식

새로 합류한 팀원이 MVVMC를 제안했고 전사 프로젝트에 적용하는 방향이 잡혔습니다. MVVM에 Coordinator를 두어 상태 통제와 인터랙션 수용을 전담시키는 사내 고유 구조로, 신규 앱이던 햇배달이 첫 적용 대상이 됐습니다. 도입에 착수했으나 초기 단계에서 방향을 바꿨습니다.

• Coordinator가 상태 통제와 인터랙션 수용을 모두 떠안는 구조라, 화면이 복잡해질수록 함께 비대해졌습니다
• 화면이 필요로 하는 것이 전부 Coordinator를 경유하면서 의존성이 한 곳으로 몰렸습니다
• SwiftUI는 뷰가 상태를 소유하는 것이 전제입니다. NavigationStack의 path 자체가 이미 상태인데 Coordinator가 이를 다시 감싸면서 이중 상태 관리가 됐습니다

대신 최상위 화면을 Screen으로 명명하고 하위 뷰가 각자 자신의 ViewModel을 소유하도록 해서, 한 객체가 화면 전체의 상태를 떠안지 않게 했습니다.

기사 앱의 핵심은 신규 주문을 실시간으로 받는 것이었습니다. 데이터 흐름은 서버 → 클라이언트 단방향이었고, 기사 단말이 서버로 실시간 신호를 보낼 일은 없었습니다.

• WebSocket — 양방향 통신이 가능하지만 이 도메인에는 클라이언트 → 서버 실시간 채널이 필요 없었습니다
• SSE — 단방향 전용으로 요구사항과 일치했습니다
• 폴링 — 주문 발생과 인지 사이에 지연이 생기고, 대부분 빈 응답인 호출 비용이 커서 제외했습니다
• 사일런트 푸시 — 실시간 전파의 주 수단으로 쓰기에는 전달 보장이 약해 제외했습니다

SSE를 채택했습니다. 결정적이었던 것은 사내 다른 웹 서비스가 이미 SSE를 운영 중이었다는 점입니다. 구축된 시스템을 그대로 쓸 수 있었고, 백엔드팀도 이를 근거로 SSE를 선호해 협의 끝에 함께 결정했습니다. WebSocket을 골랐다면 클라이언트와 서버 양쪽에 신규 구축 비용을 새로 만드는 선택이 됐을 것입니다.

케이마켓은 4.5개월 만에 출시한 앱이라 구조가 레이어 우선이었습니다. 사내 다른 iOS 앱은 이미 모듈 분리가 끝나 있었고 케이마켓만 단일 타깃으로 남아 있었습니다.

그런데 레이어 우선 구조에서는 모듈을 바로 뽑을 수 없었습니다. 한 기능의 코드가 여러 폴더에 흩어져 있으면 모듈 경계를 그을 수 없기 때문입니다. 장바구니를 모듈로 만들려면 Entities/Cart, Presentation/Cart, APIs/ 조각을 먼저 한곳에 모아야 했습니다.

한 도메인으로 검증한 뒤 나머지에 적용했습니다.

• Order 도메인 하나만 Step 1~8로 쪼개 분리하고, 그 절차를 Clean Architecture 가이드로 문서화했습니다
• 확립한 절차로 나머지 11개 도메인을 분리했습니다
• Domains/Shared를 신설해 공용 자산을 명시적으로 격리했습니다. 모듈로 나눌 때 생길 순환 의존을 미리 차단하기 위해서입니다
• 각 Step을 독립 커밋으로 유지해 단계마다 동작 보존을 검증했습니다

케이마켓은 요구사항 정의도 기획도 없는 상태에서 시작했습니다. 참여자 전원이 0에서 1을 만들어야 하는 조건이었고, 기획이 나오지 않은 단계에서 화면부터 그리는 것은 성립하지 않았습니다.

화면을 만들 수 없는 구간을 비워두는 대신, 기획과 무관하게 어차피 필요해질 것을 먼저 만들기로 했습니다. 마침 디자이너가 이전부터 준비하던 디자인 시스템이 있었고, 사내 다른 서비스에도 적용하려던 것이어서 여기서부터 시작하자는 데 합의했습니다.

KM 컴포넌트 12종과 타이포그래피 체계를 먼저 구축했고, 기획이 확정된 뒤 화면 20여 개를 이 컴포넌트로 조립했습니다. 4.5개월 만에 출시할 수 있었던 배경 중 하나입니다.

파트너스는 웹 서비스를 iOS로 전환한 앱으로 초기에는 단일 타깃 레거시 구조였습니다. 출시 후 기능이 계속 추가되면서 구조 개선이 필요해졌지만, 리팩토링 전용 기간은 확보할 수 없었습니다. 기능 개발은 계속 들어왔고, 한 번에 바꾸는 범위가 클수록 장애가 일정에 타격을 줄 위험도 커졌습니다.

그래서 기능 개발에 얹어서 조금씩 바꾸는 방식을 택했습니다. 특정 기능이 들어갈 때 그 기능이 닿는 범위의 구조를 함께 정리하는 식입니다. 리팩터링 커밋이 전체의 46.5%(239건)에 이르는 것이 이 방식의 결과입니다. 구조 개선에 따로 시간을 쓴 것이 아니라, 기능 작업마다 구조를 조금씩 밀어올린 누적입니다.

사전에 설계한 것은 아니지만 결과적으로 의존 순서를 따라갔습니다.

• MVVM-C 도입 — AppCoordinator 구현, ViewModel Action 패턴 통일
• Clean Architecture — Repository, Usecase 분리, Domain Entity 정의, DTO 도입
• SPM 멀티모듈 분리 — Domain / Data / Presentation / API
• 네비게이션 재설계 — 화면별 dismiss 산재 제거, 루트 뷰 단일 관리

1차 출시 당시 큐머니(포인트)는 전액 사용이 가능했고 쿠폰과의 동시 적용은 막아둔 상태였습니다. 계산 정합성이 확실치 않은 조합을 5개월 출시 일정 안에서 여는 것은 결제 금액이 틀어질 위험을 안는 선택이었기 때문입니다.

2024년 1월 구매 금액의 20%까지로 한도 정책이 도입되면서 상황이 달라졌습니다. 한도를 계산할 기준 금액을 쿠폰 할인 전으로 볼지 후로 볼지에 따라 결과가 달라졌기 때문입니다.

• 2024.01 — 한도 계산 시 쿠폰 할인금액을 제외하도록 처리
• 2024.06 — 반대로 쿠폰 사용가능 여부 계산 시 큐머니 적용 금액을 제외

두 값이 서로의 계산에 들어가려는 구조였습니다. 한쪽을 맞추면 다른 쪽이 어긋났고, 계산 책임이 여러 곳에 흩어져 있어 전체를 한눈에 검증할 수 없었던 것이 반복의 원인이었습니다. 2025년 2월, CalculateQMoneyUsageLimitUseCase로 계산을 분리하고 큐머니 최대 사용과 쿠폰 사용을 같은 UseCase에서 처리하도록 통합한 뒤 테스트케이스로 결과를 고정했습니다. 계산 책임이 한곳에 모이면서 재발이 멈췄습니다.