외부 모듈 의존성 추상화 이후의 성과와 다음 고민
빌드 속도 개선과 Mock 전략의 한계
2025-01-15 23:10
·- iOS
- Architecture
- Modularization
- Build
- Mock
들어가며
앱의 외부 모듈 의존성을 추상화하는 작업이 거의 끝났어요.
생각보다 꽤 오랜 시간이 걸린 작업이었지만, 결과를 놓고 보면 충분히 의미 있는 선택이었다고 느꼈어요.
특히 이번 작업은 "구조가 좋아졌다"라는 추상적인 만족이 아니라,
수치로 성과가 드러난 작업이라는 점에서 더 인상 깊었어요.
빌드 속도로 확인한 성과
클린 빌드를 기준으로 개발 환경과 프로덕션 환경의 빌드 속도를 비교해봤어요.
- 클린 빌드
- Production: 약 300초
- Development: 약 150초
개발 환경 기준으로는 절반 수준까지 줄어든 셈이에요.
증분 빌드에서는 차이가 더 명확했어요.
- 증분 빌드
- Production: 약 20초
- Development: 약 8초
개발 사이클에서 가장 자주 겪는 증분 빌드 시간이 줄어드니
작업 흐름 자체가 훨씬 쾌적해졌어요.
수치로 확인하니
"열심히 한 보람이 있다"라는 생각이 자연스럽게 들었어요.
추상화 이후, Mock이 남긴 고민
의존성 추상화를 진행하면서 자연스럽게 따라온 과제는
API Mock 전략이었어요.
Mock 객체 자체를 만드는 일은 생각보다 어렵지 않았어요.
- AI를 활용해 Mock 구현을 빠르게 만들 수 있고
- 주석이나 기본 시나리오 정리도 깔끔하게 돼요
그럼에도 불구하고,
실제 개발 과정에서는 미묘한 병목이 계속 발생했어요.
현재의 Mock 개발 프로세스
지금의 흐름은 대략 이래요.
- API에서 다른 응답이 필요해짐
- AI에게 Mock 객체를 다른 응답으로 수정해달라고 요청
- Mock 반영
- 다시 빌드
- 결과 확인
UI 코드 변경처럼 핫리로드가 잘 동작하는 경우에는 문제가 크지 않아요.
하지만,
- 비즈니스 로직이 변경되거나
- API 응답 구조가 달라지는 경우
결국 다시 빌드해야 하는 상황이 돼요.
Mock 객체를 여러 개 만들어 핫리로드로 전환하는 방식도 고민해봤지만,
- 구조가 복잡해지고
- 관리 비용이 늘어나며
- 빌드 의존성 문제를 근본적으로 해결하지는 못해요
Vapor 기반 로컬 서버라는 대안
이런 고민 끝에 떠오른 선택지가 하나 있었어요.
Vapor를 이용해 로컬 서버를 두는 방식
이미 Swift 언어로 정의된 Response Model이 존재하니,
그 모델을 그대로 서버 쪽에서 사용하면
굳이 앱 내부에 Mock 객체를 둘 필요가 없지 않을까 하는 생각이었어요.
로컬 서버를 사용했을 때의 흐름
로컬 서버를 사용한다면, 개발 흐름은 이렇게 바뀌어요.
- API에서 다른 응답이 필요해짐
- AI에게 서버 응답을 다른 형태로 수정 요청
- 반영
- 바로 확인
앱을 다시 빌드할 필요가 없어져요.
물론 서버 역시 다시 빌드되어야 하지만,
- 앱 전체 빌드에 비하면 훨씬 가볍고
- 로컬 서버를 정말 라이트하게 구성한다면
- 반복 피드백 속도는 체감될 정도로 빨라질 가능성이 있어요
Mock과 로컬 서버 사이에서
정리해보면 두 방식은 명확한 성격 차이가 있어요.
-
Mock 객체
- 구조가 단순해요
- 테스트 코드와 궁합이 좋아요
- 하지만 빌드 사이클에서 자유롭지 않아요
-
로컬 서버
- 실제 API 흐름과 유사해요
- 개발 중 피드백 루프가 빨라요
- 초기 세팅 비용이 있어요
아직 어느 쪽이 정답이라고 단정하기는 어려워요.
다만 지금 시점에서는,
Mock을 더 정교하게 만드는 것보다
개발 흐름 전체를 빠르게 만드는 선택이 더 중요해 보여요.
마치며
외부 모듈 의존성 추상화는
구조 안정성과 빌드 성능 모두에서 분명한 성과를 가져왔어요.
이제 관심사는 기술적인 완성도보다는
개발 경험과 피드백 속도에 더 가까워지고 있어요.
다음 단계에서는
Mock과 로컬 서버를 어떻게 조합할지,
혹은 전혀 다른 방식이 나올지
조금 더 실험해볼 생각이에요.