API Mocking 실전: MSW vs WireMock, 프론트/백엔드에서 언제 무엇을 쓰나

API Mocking 실전: MSW vs WireMock, 프론트/백엔드에서 언제 무엇을 쓰나

API mocking은 테스트 편의가 아니라 개발 속도를 지키는 장치입니다.
MSW(프론트)와 WireMock(백엔드)로 어디까지를 mock하고, 어디부터는 실제 통합으로 검증할지 기준을 정리합니다.

이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.

왜 이게 어려운가(운영 관점)

API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.

특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 반복하지 않게 됩니다.

실전 내용(바로 적용)

API mocking은 테스트 편의가 아니라 개발 속도를 지키는 장치입니다.
MSW(프론트)와 WireMock(백엔드)로 어디까지를 mock하고, 어디부터는 실제 통합으로 검증할지 기준을 정리합니다.

핵심 요약(결론부터)

• 기준(정책)을 먼저 정하고, 구현/도구는 그 다음에 선택한다
• 실패/예외/회귀를 운영 체크리스트로 막는다
• 공식 문서를 최종 근거로 삼고, 팀 문서로 재가공한다

MSW가 강한 곳

브라우저/프론트 개발 서버에서 네트워크 레이어를 가로채 UI 개발
스토리북/컴포넌트 테스트에서 일관된 응답 제공

WireMock이 강한 곳

백엔드 통합 테스트에서 외부 API를 안정적으로 대체
실패/지연/엣지 케이스를 재현

팀 운영 팁

mock 응답도 계약(OpenAPI/샘플 JSON) 기반으로 관리하면 드리프트가 줄어든다

선택 표

도구	주 용도	장점	주의
MSW	프론트 개발/테스트	브라우저에서 자연스럽게 동작	실제 서버와 드리프트 주의
WireMock	백엔드 통합테스트	외부 API를 강하게 통제	스텁 유지보수 비용

운영 체크리스트(바로 적용)

• mock은 '빠르게'를 위한 도구, 핵심 플로우는 통합 테스트로 보강
• 실패 케이스(429/500/timeout)도 mock에 포함
• mock 응답 변경은 PR 리뷰 대상으로

FAQ

Q. mock만으로 QA를 대체할 수 있나요?
A. 아니요. mock은 개발 속도/재현성을 높이지만, 실제 통합 문제(CORS, 인증, 프록시, 스키마)는 통합 테스트/스테이징에서 잡아야 합니다.

마무리: 다음 액션

• 팀의 기본값(정책)을 1페이지로 문서화한다
• 대표 시나리오 1개를 코드/설정 예시로 고정한다
• 배포 전후 지표(p95/p99, 오류율)를 비교해 효과를 확인한다

자주 하는 실수(사고 패턴)

• 결정 기준 없이 팀원 취향으로 기술을 고른다
• 문서(스키마)와 구현이 어긋난 상태를 장기간 방치한다
• 재시도/타임아웃을 '늘리기'만 하고 예산/정렬을 안 맞춘다
• 장애 시나리오(429/timeout/partial failure)를 테스트에 넣지 않는다

적용 순서(추천)

• 1) 바꾸려는 것(성능/보안/호환성/운영 단순화)을 한 문장으로 정의한다
• 2) 기본값과 예외를 먼저 정하고, 예외는 만료일/사유/소유자를 남긴다
• 3) 대표 시나리오(요청/응답 예시)를 만들어 계약으로 고정한다
• 4) 지표(p95/p99, 오류율, 재시도율)로 배포 전후를 비교한다
• 5) CI/PR에서 자동 검증(린트/스키마 diff/계약 테스트)을 걸어 회귀를 막는다

검증/회귀 방지

• 배포 전후 지표(p95/p99, 4xx/5xx, 재시도율)를 동일 조건으로 비교
• 프록시/CDN/게이트웨이 설정 변경 이력을 남기고, 롤백 플랜을 준비
• 대표 시나리오를 e2e 테스트로 고정(문서가 아니라 테스트가 계약이 되게)

팀 합의 템플릿(복붙용)

# 팀 합의 템플릿(복붙용)
목표: (예) 구버전 클라이언트 유지하면서 응답 스키마 변경
기본값: (예) /v1 경로 버전 사용
예외: (예) 내부 API는 헤더 버전 허용(게이트웨이 필수)
대표 시나리오: (요청/응답 예시 첨부)
모니터링: (오류율/지연/트래픽) 대시보드 링크
EOL/변경 정책: (날짜/공지 채널/롤백 규칙)

FAQ

Q. mock만으로 QA를 대체할 수 있나요?
A. 아니요. mock은 개발 속도/재현성을 높이지만, 실제 통합 문제(CORS, 인증, 프록시, 스키마)는 통합 테스트/스테이징에서 잡아야 합니다.

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

• MSW
• WireMock