외부 모듈 의존성 추상화 이후의 성과와 다음 고민

빌드 속도 개선과 Mock 전략의 한계

앱의 외부 모듈 의존성을 추상화하는 작업이 거의 끝났다.
생각보다 꽤 오랜 시간이 걸린 작업이었지만, 결과를 놓고 보면 충분히 의미 있는 선택이었다고 느낀다.

특히 이번 작업은 “구조가 좋아졌다”라는 추상적인 만족이 아니라,
수치로 성과가 드러난 작업이라는 점에서 더 인상 깊었다.

🚀 빌드 속도로 확인한 성과

클린 빌드를 기준으로 개발 환경과 프로덕션 환경의 빌드 속도를 비교해 보았다.

개발 환경 기준으로는 절반 수준까지 줄어든 셈이다.

증분 빌드에서는 차이가 더 명확했다.

개발 사이클에서 가장 자주 겪는 증분 빌드 시간이 줄어드니
작업 흐름 자체가 훨씬 쾌적해졌다.

수치로 확인하니
“열심히 한 보람이 있다”라는 생각이 자연스럽게 들었다.

의존성 추상화를 진행하면서 자연스럽게 따라온 과제는
API Mock 전략이었다.

Mock 객체 자체를 만드는 일은 생각보다 어렵지 않았다.

그럼에도 불구하고,
실제 개발 과정에서는 미묘한 병목이 계속 발생했다.

지금의 흐름은 대략 이렇다.

UI 코드 변경처럼 핫리로드가 잘 동작하는 경우에는 문제가 크지 않다.
하지만,

결국 다시 빌드해야 하는 상황이 된다.

Mock 객체를 여러 개 만들어 핫리로드로 전환하는 방식도 고민해봤지만,

는 한계가 있었다.

이런 고민 끝에 떠오른 선택지가 하나 있었다.

Vapor를 이용해 로컬 서버를 두는 방식

이미 Swift 언어로 정의된 Response Model이 존재하니,
그 모델을 그대로 서버 쪽에서 사용하면
굳이 앱 내부에 Mock 객체를 둘 필요가 없지 않을까 하는 생각이었다.

로컬 서버를 사용한다면, 개발 흐름은 이렇게 바뀐다.

앱을 다시 빌드할 필요는 없어진다.
물론 서버 역시 다시 빌드되어야 하지만,

정리해보면 두 방식은 명확한 성격 차이가 있다.

아직 어느 쪽이 정답이라고 단정하기는 어렵다.
다만 지금 시점에서는,

Mock을 더 정교하게 만드는 것보다
개발 흐름 전체를 빠르게 만드는 선택이 더 중요해 보인다.

외부 모듈 의존성 추상화는
구조 안정성과 빌드 성능 모두에서 분명한 성과를 가져왔다.

이제 관심사는 기술적인 완성도보다는
개발 경험과 피드백 속도에 더 가까워지고 있다.

다음 단계에서는
Mock과 로컬 서버를 어떻게 조합할지,
혹은 전혀 다른 방식이 나올지
조금 더 실험해볼 생각이다.