Mock Service Worker (MSW) 대안: 풀 API 모킹 플랫폼을 대신 사용해야 할 때

프런트엔드 테스트를 작성한다면 Mock Service Worker(MSW)를 접했을 것입니다. 브라우저와 Node 내에서 요청을 가로채는 데 가장 많이 사용되는 라이브러리이며, 단위 및 컴포넌트 테스트에서는 MSW를 능가하기 어렵습니다. 이 가이드는 MSW가 잘하는 일, 확장성 한계, 그리고 호스팅된 API 목업 플랫폼이 더 적합한 경우를 설명합니다.

button

Mock Service Worker란 무엇인가요?

Mock Service Worker는 소스에서 네트워크 요청을 가로채는 JavaScript 라이브러리입니다. 브라우저에서는 나가는 fetch 및 XMLHttpRequest 호출을 가로채는 서비스 워커를 등록합니다. Node에서는 요청 계층을 패치하여 동일한 핸들러가 Jest 또는 Vitest에서 실행되도록 합니다. 메서드와 경로에 일치하는 요청 핸들러를 작성한 다음 원하는 응답을 반환합니다.

설계는 영리합니다. 애플리케이션 코드는 실제 네트워크 API를 계속 호출합니다. MSW는 중간에 위치하여 응답하므로 fetch를 스텁하거나 HTTP 클라이언트를 교체할 필요가 없습니다. 동일한 목업 정의가 테스트와 실행 중인 개발 빌드에서 모두 작동하므로 많은 React 및 Vue 팀이 MSW를 사용하는 이유입니다. 가로채기 계층이 어떻게 작동하는지 보려면 GitHub의 MSW 소스를 살펴볼 수 있습니다.

일반적인 핸들러는 다음과 같습니다:

import { http, HttpResponse } from 'msw'

export const handlers = [
  http.get('/api/users/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Ada Lovelace' })
  }),
]

이것이 바로 MSW의 매력입니다. 목업은 코드 옆에 존재하며, 테스트와 함께 버전 관리되고, JavaScript가 실행되는 모든 곳에서 실행됩니다.

MSW의 장점

목업과 소비자가 동일한 코드베이스에 있을 때 MSW는 강력하게 적합합니다. MSW가 진정으로 올바른 도구인 몇 가지 경우는 다음과 같습니다.

컴포넌트 및 단위 테스트. 컴포넌트를 렌더링하고, 실제 요청을 보내도록 하며, 미리 정의된 데이터를 반환합니다. 테스트 더블을 연결할 필요가 없습니다. 클라이언트를 직접 스파이하는 것과 비교한다면, API 호출에 대한 Jest 목업과 어떻게 다른지 확인하십시오.
로컬 프런트엔드 개발. 백엔드가 존재하기 전에 UI를 구축합니다. 핸들러를 토글하여 로딩, 오류 또는 빈 상태를 필요에 따라 시뮬레이션합니다.
결정론적 CI. 테스트는 라이브 서버에 접근하지 않으므로 네트워크 조건이나 공유 스테이징 데이터로 인해 불안정해지지 않습니다.
하나의 언어, 하나의 팀. 목업을 작성하는 사람과 소비하는 사람이 같을 때, 핸들러를 리포지토리에 유지하는 것이 가장 간단한 방법입니다.

귀하의 상황이 그렇다면, 아마 다른 것은 필요 없을 것입니다. MSW는 무료이며 오픈 소스이고, 바로 이러한 목적을 위해 만들어졌습니다.

MSW가 한계에 부딪히기 시작하는 지점

단일 리포지토리에서 MSW를 훌륭하게 만드는 것, 즉 해당 리포지토리의 코드로서 존재하는 목업은 더 많은 사람이 참여하게 되면 한계를 드러내게 됩니다. 팀들이 MSW의 한계를 느끼기 시작하는 지점은 다음과 같습니다.

비 JavaScript 소비자

MSW 핸들러는 JavaScript입니다. 모바일 팀이 Swift나 Kotlin으로 작성하거나, 백엔드 통합 테스트가 Go나 Python으로 실행된다면, 그들은 귀하의 핸들러를 가져올 수 없습니다. 그들은 자체 목업이 필요하며, 이는 귀하의 것과 달라질 수 있습니다. 실제 URL을 통해 HTTP로 통신하는 언어 불가지론적인 목업 서버는 언어에 관계없이 모든 클라이언트에서 작동합니다.

공유되고 항상 켜져 있는 목업

MSW는 프로세스 내에서 실행됩니다. QA 엔지니어, 디자이너 또는 파트너 팀이 각자의 머신에서 접근할 수 있는 공유 URL이 없습니다. 여러 사람이 동시에 사용하는 하나의 엔드포인트를 원한다면, 하나의 브라우저 탭에 묶인 서비스 워커가 아닌 안정적인 주소를 가진 호스팅된 목업 서버가 필요합니다.

설계 우선 및 스키마 기반 워크플로우

코드를 작성하기 전에 OpenAPI에서 API를 설계하는 경우, 스펙에서 목업이 자동으로 생성되기를 원할 것입니다. 이렇게 하면 목업이 계약과 일치하지 않을 수 없습니다. MSW는 핸들러를 직접 작성하도록 요구합니다. 스키마에서 직접 목업을 생성하는 것은 다른 모델입니다. 이 접근 방식에 대한 자세한 내용은 API 목업 및 관련 패턴에 대한 이 가이드에서 확인할 수 있습니다.

대규모의 현실적이고 동적인 데이터

MSW는 핸들러가 코딩하는 것을 반환합니다. 많은 필드에 걸쳐 실제와 같은 데이터를 얻으려면 직접 로직을 작성해야 합니다. faker 스타일 생성 및 필드 이름 추론을 통합한 플랫폼은 각각을 직접 작성하지 않고도 현실적인 응답을 제공합니다.

MSW 대 완전한 API 목업 플랫폼

다음은 솔직한 비교입니다. 추상적으로 어느 한 쪽이 더 "낫다"고 할 수는 없으며, 각각 다른 문제를 해결합니다.

기능	Mock Service Worker	호스팅 API 플랫폼 (예: Apidog)
JS 단위/컴포넌트 테스트 내 실행	예, 네이티브	아니요, JS 테스트 라이브러리가 아닙니다
HTTP를 통한 언어 불가지론적	아니요 (JS 전용)	예, 모든 클라이언트
전체 팀을 위한 공유 URL	아니요	예, 호스팅 목업 서버
OpenAPI에서 목업 생성	수동	스키마로부터 자동
스마트/동적 데이터 생성	수동 코딩	내장
테스트와 함께 리포에 존재	예	공유 프로젝트에 저장
비용	무료, 오픈 소스	무료 티어 + 유료 플랜

결론: MSW는 프런트엔드 테스트 및 로컬 개발에 적합합니다. Apidog와 같은 플랫폼은 목업이 공유되거나, 언어 중립적이거나, 스펙에 의해 구동되어야 할 때 적합합니다.

대체가 아닌 보완재로서의 Apidog

분명히 말해, Apidog는 Jest나 Vitest 내에서 MSW를 대체하는 드롭인 방식이 아닙니다. 테스트 파일로 가져오는 JavaScript 라이브러리도 아닙니다. Apidog는 단위 테스트 위에 있는 계층, 즉 목업이 전체 팀을 위한 공유되고 언어 불가지론적인 리소스가 되는 곳으로 취급하십시오.

실제로 어떤 모습인지 설명합니다. Apidog에서 API를 설계하거나 가져오면, 스키마에서 목업 엔드포인트를 자동으로 생성합니다. 이 목업은 프런트엔드, 모바일, QA 팀원 모두가 호출할 수 있는 실제 URL을 갖습니다. Apidog는 필드 이름을 통해 추론하여 응답을 현실적인 데이터로 채웁니다. 예를 들어, email이라는 필드는 이메일을 반환하고 createdAt은 날짜를 반환합니다. 특정 500 응답이나 특별한 예외 상황이 필요할 때는 사용자 정의 규칙을 작성할 수도 있습니다.

목업이 설계 및 테스트와 동일한 스키마에서 생성되므로, 계약과 동기화된 상태를 유지합니다. 이는 수동으로 작성된 핸들러가 보장할 수 없는 부분입니다. 스키마 기반 목업 생성이 도구별로 어떻게 비교되는지 보고 싶다면, 최고의 API 목업 도구에 대한 이 요약 글에서 각 옵션을 비교해 볼 수 있습니다.

많은 팀이 선택하는 실용적인 분할 방식:

프런트엔드 리포지토리 내에서 컴포넌트 및 단위 테스트를 위해 MSW를 유지합니다.
팀 간 통합, 데모, 그리고 모든 비-JS 소비자를 위해 호스팅된 목업을 사용합니다.

하나만 선택하는 것이 아닙니다. 각 도구가 적합한 곳에 사용합니다. 기존 MSW 설정과 함께 호스팅된 측면을 사용해보고 싶다면 Apidog를 다운로드하십시오.

알아둘 가치가 있는 다른 MSW 대안

MSW가 유일한 목업 라이브러리가 아니며, 플랫폼이 유일한 옵션도 아닙니다. 귀하의 스택에 따라:

Mockoon은 코드 대신 GUI를 사용하여 로컬 목업 서버를 빠르게 실행하는 데 사용되는 데스크톱 앱입니다.
WireMock은 Java 기반 목업 서버로, JVM 팀과 계약 테스트에 강력합니다.
Stoplight의 Prism은 명령줄을 통해 OpenAPI 파일에서 직접 목업을 생성합니다.
json-server는 JSON 파일을 프로토타이핑을 위한 빠른 REST API로 변환합니다.

각각 장단점이 있습니다. WireMock과 Prism은 백엔드 및 계약 작업에 중점을 둡니다. Mockoon과 json-server는 빠른 로컬 설정에 중점을 둡니다. 만약 귀하의 장애물이 특히 "MSW는 내 비-JS 팀원들을 도울 수 없다"는 것이라면, 어떤 HTTP 기반 목업 서버라도 해결할 수 있습니다. 더 넓은 프런트엔드 관점에서, 팀들이 Axios를 사용하여 React에서 API를 목업하는 방법을 확인하십시오.

자주 묻는 질문

MSW는 무료인가요?

네. Mock Service Worker는 MIT 라이선스 하의 오픈 소스이며 상업적 프로젝트를 포함한 모든 프로젝트에서 무료로 사용할 수 있습니다. 공유 목업을 위해 호스팅된 플랫폼으로 전환할 때만 비용이 발생하며, Apidog와 같은 도구에도 무료 티어가 포함되어 있습니다.

Apidog가 단위 테스트에서 MSW를 대체할 수 있나요?

아니요, 그리고 그렇게 하려고 시도해서도 안 됩니다. MSW는 JavaScript 테스트 러너 내부에서 요청을 가로챕니다. Apidog는 가져올 수 있는 라이브러리가 아니라 호스팅된 플랫폼이므로, MSW처럼 Jest나 Vitest 내부에 위치할 수 없습니다. 대신 Apidog는 공유되거나 팀 간에 사용되거나 스키마 기반 목업을 위해 사용하십시오. 테스트 러너 측면에만 집중한다면, API 호출을 목업하는 방법에 대한 이 가이드가 코드 내 접근 방식을 다룹니다.

MSW는 Node에서도 작동하나요, 아니면 브라우저에서만 작동하나요?

둘 다입니다. 브라우저에서는 MSW가 서비스 워커를 사용합니다. Node에서는 요청 계층을 패치하여 동일한 핸들러가 Jest, Vitest 또는 다른 Node 테스트 환경에서 실행되도록 합니다. 이러한 듀얼 모드는 풀스택 JS 팀에게 가장 큰 장점 중 하나입니다.

MSW에서 호스팅 목업 서버로 전환해야 할 시점은 언제인가요?

목업을 공유해야 할 때 전환하거나, 더 정확히는 추가해야 합니다. 가장 명확한 신호는 다음과 같습니다: 비-JavaScript 클라이언트가 필요로 할 때, 여러 사람이 동일한 안정적인 URL을 필요로 할 때, 또는 스펙 우선으로 API를 설계하고 OpenAPI에서 목업이 자동으로 생성되기를 원할 때입니다.

결론

MSW는 프런트엔드 및 단위 테스트를 위해 JavaScript 내부에서 요청을 가로채는 본연의 목적에 탁월합니다. MSW는 공유되고, 호스팅되며, 언어 불가지론적인 목업이 되려고 하지 않으며, 이는 괜찮습니다. 목업이 리포지토리를 벗어나야 할 때, 다른 언어 또는 다른 팀에서 목업이 필요할 때, 또는 스펙에서 목업이 생성되기를 원할 때, 그때가 바로 MSW와 함께 완전한 플랫폼을 추가해야 할 시점입니다.

Apidog는 공유되고 스키마 기반의 측면을 처리합니다: 실제 URL을 가진 호스팅 목업 서버, OpenAPI 설계에서 자동 생성되는 목업, 그리고 즉시 사용 가능한 현실적인 데이터. MSW가 강점을 발휘하는 곳에서는 MSW를 유지하고, 테스트 러너의 범위를 벗어나는 모든 것은 Apidog가 담당하게 하십시오. Apidog를 다운로드하고 프런트엔드를 공유 목업으로 설정하여 차이점을 확인해보세요.

button