Mock의 역설

격리와 통합 사이에서 균형 찾기

Sep 24. 2025 brunch_membership's

"우리 테스트는 모두 통과했습니다. 100% 성공률입니다."

월요일 아침 스탠드업 미팅. 시니어 개발자가 자신있게 보고했습니다. 하지만 화요일 오후, 프로덕션 배포 직후 고객 지원팀 슬랙 채널이 폭발했습니다. 외부 결제 API가 새로운 응답 형식을 반환하기 시작했고, 우리의 완벽했던 Mock은 이를 전혀 반영하지 못했던 것입니다.

이것이 바로 Mock의 역설입니다. 테스트를 빠르고 안정적으로 만들어주는 Mock이, 동시에 우리를 실제 세계로부터 격리시켜 위험에 빠뜨립니다. 마치 비행 시뮬레이터에서만 연습한 조종사가 실제 난기류를 만났을 때와 같은 상황입니다.

Martin Fowler는 2007년 "Mocks Aren't Stubs"에서 고전적인 논쟁을 정리했지만, 2025년 현재 마이크로서비스와 클라우드 네이티브 환경에서 이 문제는 더욱 복잡해졌습니다. 우리는 이제 단순히 Mock을 쓸 것인가 말 것인가의 문제가 아니라, 어떻게 현명하게 균형을 잡을 것인가를 고민해야 합니다.

Mock이 만드는 거짓 안전지대

시간이 멈춘 테스트

대형 테크 기업들의 내부 연구에 따르면, Mock 객체와 실제 API 간의 업데이트 주기에는 상당한 격차가 있다고 합니다. Mock은 한번 만들어지면 장기간 유지되는 반면, 실제 API는 빈번하게 변경됩니다. 이로 인해 상당수의 Mock이 만들어진 후 얼마 지나지 않아 현실과 동떨어진 "좀비 Mock"이 되어버립니다.

더 심각한 것은 이러한 괴리를 아무도 인지하지 못한다는 점입니다. 테스트는 계속 통과하고, 개발자들은 안전하다고 믿습니다. 국내 대형 이커머스 기업의 한 엔지니어는 "프로덕션 인시던트의 상당 부분이 오래된 Mock으로 인한 가정 불일치에서 발생했다"고 밝혔습니다.

실제로 국내 핀테크 기업에서도 비슷한 사례가 있었습니다. 외부 신용평가 서비스의 Mock이 장기간 업데이트되지 않았고, 그동안 실제 서비스는 응답 구조를 여러 차례 변경했습니다. 결국 신규 서비스 출시 직후 대규모 장애가 발생했다는 후문입니다.

복잡성의 블랙홀

국내 대형 결제 서비스 기업의 사례를 보면, 한 서비스의 통합 테스트가 수십 개의 Mock 객체를 사용하고 있었습니다. Mock 설정 코드만 수천 줄을 넘었고, 이는 실제 비즈니스 로직의 상당 부분에 달하는 규모였습니다.

Mock 자체가 또 다른 시스템이 되어버린 것입니다. 한 국내 금융 서비스 QA 엔지니어는 "Mock 유지보수에 들어가는 시간이 실제 기능 테스트 작성 시간보다 많아졌다"며, "이는 본말전도"라고 지적했습니다.

더 나아가, 복잡한 Mock 설정은 테스트의 가독성을 해칩니다. 새로운 팀원이 합류했을 때, 테스트 코드를 이해하기 위해 먼저 Mock의 동작을 이해해야 하는 아이러니한 상황이 발생합니다.

계약의 환상

"우리는 API 스펙에 맞춰 Mock을 만들었으니 안전합니다."

많은 개발자들이 이렇게 생각합니다. 하지만 실제로는 API 문서와 실제 구현 사이에 불일치가 흔하게 발생합니다. 특히 에러 응답이나 엣지 케이스 처리 부분에서 문서화되지 않은 동작이 많습니다.

마이크로서비스 환경에서는 서비스 간 암묵적인 동작 패턴이 존재합니다. 예를 들어, 특정 서비스가 부하가 높을 때 429 상태 코드 대신 503을 반환하거나, 특정 시간대에만 캐시를 사용하는 등의 행동은 문서화되지 않은 경우가 많습니다. Mock은 이런 미묘한 행동 패턴을 절대 포착할 수 없습니다.

통합 테스트의 현실적 고통

환경 구성의 지옥

통합 테스트 환경 구성은 한국 스타트업들에게 특히 큰 부담입니다. 국내 대형 배달 플랫폼 엔지니어링 팀은 "마이크로서비스가 수십 개를 넘어가면서 로컬 개발 환경 구성이 거의 불가능해졌다"고 토로했습니다.

Docker Compose로 전체 스택을 구성하려 했지만, 개발자 노트북의 메모리 한계로 인해 동시에 실행할 수 있는 서비스가 제한되었습니다. 결국 선택적으로 서비스를 띄우는 방식을 택했지만, 이는 또 다른 복잡성을 낳았습니다.

실행 시간의 딜레마

국내 중고거래 플랫폼의 QA 엔지니어링 리드는 "통합 테스트 실행 시간이 30분을 넘어가면서 개발자들이 테스트를 스킵하기 시작했다"고 밝혔습니다. 이는 글로벌 기업만의 문제가 아니라 국내 IT 기업들도 공통적으로 겪는 문제입니다.

특히 한국의 빠른 개발 문화에서 긴 테스트 실행 시간은 더욱 치명적입니다. "빨리빨리" 문화와 품질 보증 사이의 균형을 맞추는 것이 큰 도전입니다.

플레이키 테스트의 악몽

통합 테스트는 본질적으로 불안정합니다. 네트워크 지연, 타이밍 이슈, 리소스 경쟁 등 수많은 변수가 존재합니다. 이는 이미 게시된 "플레이키 테스트의 경제학: 불안정성이 조직에 미치는 실제 비용 분석" 글을 참고해보세요. 플레이키 테스트로 인한 생산성 손실이 상당하다는 분석이 담겨 있습니다.