[SaaS] 테스트 안정감을 N배로 확보할 수 있었던 이유

Context

마이크로서비스 기반 SaaS 플랫폼(KOS)의 예약 시스템 개발 중 자동화 테스트는 성공했으나 운영 배포 후 버그가 발생했던 경험이 있었다. 복잡한 비즈니스 요구사항을 충족하기 위해 Visitor Service(WebClient), Redis, MongoDB, AWS Kinesis 등 다양한 외부 의존성이 필요했으나, 모든 인프라를 로컬 테스트 환경에서 구동해야 하는 문제가 있었다.

Technical Solution

• 테스트 대역(Fake/Stub)을 선택적으로 활용: VisitorReader는 원격 서비스 호출 특성상 Stub으로 대체하여 네트워크 의존성 제거
• InMemoryEventStoreFake 구현: MongoDB와 AWS Kinesis 의존성 제거, HashMap 기반 메모리 저장소로 도메인 이벤트 관리
• ReservationOverlapValidatorFake 구현: Redis 외 다른 저장소로 변경될 수 있으므로 HashMap 기반 검증 대역 활용
• 실제 구현(DoC) 선택적 도입: Redis 검증 로직의 거짓 음성 방지를 위해 @DataRedisTest와 TestContainer를 활용한 실제 Redis 인스턴스 테스트
• 테스트 대역 사용 시 명확한 기준 수립: SUT가 검증하려는 로직이 외부 서비스의 환경이 아닌 자체 서비스 로직 복잡성일 때만 대역 사용

Key Takeaway

단순히 "외부 의존성을 모킹해야 한다"는 원칙보다 "무엇을 검증하려는가"에 초점을 맞춰 테스트 대역과 실제 구현 간 트레이드오프를 명확히 인식하면, 테스트 속도와 안정감을 동시에 확보할 수 있다.