무조건 격리한다고 좋은 테스트일까? MSA 환경에서 구축하는 시나리오 인수 테스트 #우아콘2025 #우아한형제들

우아한테크·우아콘 2025 2025·7개월 전·

#microservices#end-to-end-testing#docker-compose#continuous-integration#cucumber#acceptance-testing

AI 요약

광고 플랫폼이 단위 테스트 3,400개와 73% coverage를 갖고도 1,800개 QA 시나리오의 반복과 microservice 간 실제 연결을 보장하지 못한 문제에서 출발한다. Cucumber 시나리오와 통합 실행 환경을 한 번에 완성하려 하지 않고 점진적으로 구축한 과정을 따라간다.

핵심 포인트

각 microservice가 독립적으로 성공해도 연결 지점 하나가 실패하면 전체 사용자 흐름이 끊기므로, module 내부 테스트와 별개로 조합된 시나리오 검증이 필요했음을 짚음
1,800개 edge case를 처음부터 자동화하지 않고 핵심 사용자의 happy path부터 Cucumber feature로 작성한 뒤 회귀 사례를 점진 추가하고, 의존 범위가 작은 광고 core module부터 실제 service·infrastructure를 묶어 확장
실패 원인이 제품 코드인지 깨진 환경인지 빠르게 가르도록 health endpoint smoke → service 간 호출 E2E → 사용자 acceptance의 3계층으로 검증해 피드백 시간을 단축
service repo를 clone해 Docker Compose로 DB·Kafka와 실행하고 외부 팀 service는 WireMock으로 대체, infrastructure·test module·CI pipeline을 분리해 긴 runtime을 배포가 아닌 code merge 시 실행

왜 읽나MSA에서 높은 단위 커버리지로도 남는 통합 불안을 겪는 팀에게 계층형 시나리오 인수 테스트의 구축 순서와, 즉시 측정되지 않는 테스트 문화를 정착시키는 방법을 함께 담은 경험담.

챕터별 상세

012:44 – 6:01

높은 coverage로도 남은 MSA의 불안

외부 광고주 도구의 전체 QA는 약 1,800개 시나리오에 달해 매 변경마다 사람이 반복하기 어려웠지만, 3,400개 단위 테스트와 73% coverage만으로는 출시 안정감을 대체하지 못했다. 각 microservice가 독립적으로 성공해도 연결 지점 하나가 실패하면 전체 사용자 흐름은 끊기므로 module 내부와 별개로 조합된 시나리오를 검증해야 했다.

시나리오 실패가 제품 코드인지 깨진 test environment인지 빠르게 구분하도록 먼저 health endpoint로 모든 server의 기동을 확인하는 smoke test를 둔다. 이어 service 사이의 실제 호출 경로를 확인하는 E2E test를 통과시킨 뒤 사용자 acceptance scenario를 실행해, 원인 범위를 단계별로 좁히고 긴 통합 테스트의 피드백 시간을 줄인다.

검증 대상 service의 repository를 clone해 image를 만들고 Docker Compose로 DB·Kafka와 함께 실행하며, 외부 팀의 service는 WireMock의 약속된 응답으로 대체한다. 환경 구축과 Cucumber test를 별도 module로 나누고 test layer별 package를 분리해 필요한 범위만 실행하며, 긴 runtime을 배포 과정에 직접 넣지 않고 code merge 시 CI pipeline에서 동작하게 구성했다.

새로운 통합 테스트는 관리 부담과 즉시 측정 가능한 성과가 없다는 우려를 동반하므로 많은 resource를 한 번에 투입하기보다 작은 불편에서 출발해 결과와 피드백을 쌓아야 한다. 배포 속도나 bug 감소로 바로 증명되지 않아도 심리적 안정감, 신뢰, 협업 방식에 영향을 주며, 동료가 공감할 수 있는 점진적 변화가 팀에 맞는 개발 문화를 만든다.