서비스 가상화: 개념과 도구

서비스 가상화는 제어할 수 없는 의존성을 시뮬레이션합니다. 모킹과의 차이점, 팀이 이를 사용하는 이유, 그리고 WireMock, Hoverfly, Mountebank, Apidog와 같은 도구들에 대해 알아보세요.

INEZA Felin-Michel

INEZA Felin-Michel

6 July 2026

서비스 가상화: 개념과 도구

Apidog 엔터프라이즈

온프레미스 배포

SSO & RBAC

SOC 2 준수

Apidog Enterprise 살펴보기

귀하의 코드는 제어할 수 없는 서비스에 의존합니다. 결제 게이트웨이, 파트너 API, 레거시 메인프레임, 다른 팀의 마이크로서비스 등입니다. 이러한 의존성은 유지 보수 중이거나, 테스트 실행에 속도 제한을 걸거나, 호출당 요금을 부과하거나, 불안정한 데이터를 반환할 수 있습니다. 따라서 개발이 중단되고 CI 파이프라인이 코드와 관련 없는 이유로 빨간불이 들어옵니다.

서비스 가상화가 이 문제를 해결합니다. 실제 종속성을 마치 그것처럼 동작하는 대역으로 교체하여, 귀하가 완전히 제어할 수 있는 것을 기반으로 빌드하고 테스트할 수 있습니다. 이 가이드는 서비스 가상화가 무엇인지, 모킹 및 스터빙과 어떻게 다른지, 팀이 왜 이를 사용하는지, 그리고 WireMock, Hoverfly, Mountebank, 엔터프라이즈 옵션 및 Apidog의 API 계약 가상화를 위한 목 서버에 대한 실제 명령과 함께 어떤 도구들이 이 작업을 수행하는지 설명합니다.

button

서비스 가상화란 무엇인가요

서비스 가상화는 귀하가 제어할 수 없는 종속성의 동작을 시뮬레이션하여, 귀하의 애플리케이션이 실제 시스템 대신 시뮬레이션과 통신할 수 있도록 합니다.

여기서 “동작(behavior)”이라는 단어는 중요합니다. 좋은 가상 서비스는 고정된 페이로드만 반환하지 않습니다. 요청 세부 정보를 매칭하고, 다른 입력에 대해 다른 응답을 반환하며, 호출 전반에 걸쳐 상태를 유지하고, 지연 및 오류를 주입하며, 실제 시스템과 동일한 프로토콜을 사용합니다. 목표는 개발 및 테스트 중에 코드가 차이를 인지할 수 없을 정도로 현실적인 대역을 제공하는 것입니다.

종속성이 HTTP API인 경우 “API 가상화”는 동일한 의미를 가지며, “API 시뮬레이터”는 가상 엔드포인트를 생성하는 도구입니다. 이 둘을 서비스 가상화 중 API에 초점을 맞춘 부분에 대한 동의어로 간주하세요.

서비스 가상화 vs 모킹 vs 스터빙

이 세 용어는 서로 겹치며, 사람들은 이를 느슨하게 사용합니다. 이들을 구분하는 실용적인 방법은 다음과 같습니다.

**스터브(stub)**는 하드코딩된 응답을 반환합니다. 요청을 무시하고 항상 동일한 방식으로 응답합니다. 테스트가 GET /user/42를 호출하고 스터브가 고정된 사용자 객체를 반환하도록 설정되어 있다면, 어떤 ID를 보내든 동일한 객체를 반환합니다. 스터브는 가장 간단한 형태이며 테스트 코드 내부에 존재합니다.

**목(mock)**은 상호작용도 검증하는 스터브입니다. 호출 방식(어떤 메서드, 어떤 인자, 몇 번 호출되었는지)을 기록하여 코드가 종속성을 올바르게 사용했는지 테스트에서 확인할 수 있도록 합니다. 목은 단위 테스트 도구입니다. 일반적으로 코드와 동일한 언어로 프로세스 내에서 실행됩니다. 당사의 API 스터빙 vs API 모킹 설명서는 이 구분에 대해 더 깊이 다룹니다.

**서비스 가상화**는 코드 내부가 아닌 네트워크를 통해 작동합니다. 실제 네트워크 포트에서 실제 프로토콜을 사용하는 실행 중인 서비스를 설정합니다. 애플리케이션은 기본 URL 또는 프록시 설정을 변경하여 프로덕션에 연결하는 것과 동일한 방식으로 가상 서비스에 연결합니다. 가상 서비스는 상태를 가질 수 있고, 복잡한 요청 조건을 매칭할 수 있으며, HTTP 상태 코드, 헤더, 스트리밍, 연결 오류와 같은 프로토콜 수준 동작을 시뮬레이션할 수 있습니다.

일상적인 대화에서 “목”과 “서비스 가상화”의 경계는 모호합니다. 많은 팀이 완전한 가상화를 수행하는 실행 중인 HTTP 목 서버를 “목”이라고 부르기도 합니다. 이는 괜찮습니다. 중요한 구분은 다음과 같습니다. 프로세스 내부의 객체를 교체하는 것인지(모킹/스터빙), 아니면 앱이 연결하는 네트워크 서비스를 설정하는 것인지(가상화)? 목 측면에 대해서는 API 모킹: 알아야 할 모든 것을 참조하세요.

팀이 서비스 가상화를 사용하는 이유

대부분의 도입은 세 가지 문제로 인해 발생합니다.

**종속성이 준비되지 않았습니다.** 프런트엔드와 백엔드 팀은 병렬로 작업하며, 백엔드에서 API를 배포하기 전에 프런트엔드에서는 작동하는 API가 필요합니다. API 계약으로 구축된 가상 서비스를 통해 프런트엔드는 오늘날 현실적인 응답을 기반으로 빌드할 수 있습니다. 아무도 기다리지 않습니다.

**종속성이 비싸거나 속도 제한이 있습니다.** 서드파티 API는 종종 호출당 요금을 부과하거나 aggressively 제한을 가하므로, 라이브 샌드박스에 대해 전체 테스트 스위트를 실행하면 할당량과 비용이 소모됩니다. 가상 서비스는 무료로 호출할 수 있으므로 CI는 하루에 수천 개의 시나리오를 실행할 수 있습니다.

**종속성이 불안정하거나 제어하기 어렵습니다.** 실제 결제 제공업체가 특정 오류를 반환하거나, 타임아웃되거나, 잘못된 형식의 응답을 보내도록 쉽게 만들 수 없습니다. 가상 서비스는 이러한 모든 것을 주문형으로 생성하여, 프로덕션에서 발생하는 오류 경로를 테스트할 수 있게 합니다.

제어 측면의 이점도 있습니다. 실제 종속성에는 귀하 모르게 변경되는 데이터가 있습니다. 가상 서비스는 고정되고 알려진 상태를 제공하므로 테스트가 결정적입니다. 녹색 빌드는 코드가 작동함을 의미하며, 원격 시스템이 오늘 우연히 제대로 작동했다는 의미가 아닙니다.

서비스 가상화 작동 방식

대부분의 도구는 다음 두 가지 패턴 중 하나를 따릅니다.

**기록 및 재생.** 도구를 프록시로 실제 서비스를 가리키고, 실제 트래픽을 한 번 통과시키면 요청/응답 쌍을 캡처합니다. 나중에 실제 서비스를 호출하는 대신 해당 기록을 재생합니다. 응답을 직접 작성할 필요가 없으므로 빠릅니다. Hoverfly의 캡처 모드와 WireMock의 기록 모드는 모두 이런 방식으로 작동합니다.

**명세 기반.** API 계약 또는 수동으로 가상 서비스를 정의합니다. 어떤 요청이 어떤 응답과 일치하는지 선언하고, 동적 값을 추가하고, 상태를 가지는 동작을 설정합니다. 초기 작업이 더 많지만, 완전한 제어권을 제공하며 실제 서비스가 아직 존재하지 않을 때도 작동합니다.

어떤 방식이든 핵심 메커니즘은 요청 매칭입니다. 요청이 도착하면 도구는 일련의 규칙(경로, 메서드, 쿼리 파라미터, 헤더, 본문)과 비교하여 첫 번째 일치하는 항목에 연결된 응답을 반환합니다. 더 나은 도구는 템플릿 기능을 추가하여 응답이 요청의 일부를 에코하거나 각 호출마다 새로운 값을 생성할 수 있도록 합니다. 이를 통해 가상 서비스가 정적이지 않고 살아있는 것처럼 느껴집니다.

도구들

여기서는 오픈 소스 HTTP 중심 도구부터 강력한 엔터프라이즈 스위트까지 주요 옵션들을 소개합니다. 이러한 도구들은 빠르게 변화하므로, 사용을 결정하기 전에 각 프로젝트의 공식 문서를 통해 현재 버전과 기능을 확인하세요.

WireMock

WireMock은 HTTP를 위한 오픈 소스 API 모킹 및 서비스 가상화 도구입니다. 독립 실행형 프로세스로, JVM 테스트에 내장되거나 컨테이너 내에서 실행됩니다. 스터브 매핑을 JSON으로 정의하면 WireMock이 들어오는 요청을 이에 맞춰 매칭합니다. 실제 서비스에 대한 기록 및 재생, 응답 템플릿, 상태를 가지는 시나리오, 오류 주입, 시뮬레이션된 지연을 지원합니다.

독립 실행형 JAR 실행:

java -jar wiremock-standalone-3.13.2.jar --port 8080

그런 다음 관리 API를 통해 스터브 등록:

curl -X POST http://localhost:8080/__admin/mappings \
  -H "Content-Type: application/json" \
  -d '{
    "request": {
      "method": "GET",
      "url": "/user/42"
    },
    "response": {
      "status": 200,
      "headers": { "Content-Type": "application/json" },
      "jsonBody": { "id": 42, "name": "Ada Lovelace" }
    }
  }'

WireMock은 종속성이 HTTP이고 JVM 또는 컨테이너 환경에서 세밀한 제어를 원할 때 가장 강력합니다. 관리형 옵션을 원한다면 상업용 호스팅 버전(WireMock Cloud)도 있습니다.

Hoverfly

Hoverfly는 Go로 작성된 경량 오픈 소스 서비스 가상화 도구입니다. 프록시로 작동하며, 애플리케이션의 아웃바운드 트래픽을 Hoverfly를 통해 라우팅하면 실제 응답을 기록하거나 시뮬레이션된 응답을 재생합니다. 캡처, 시뮬레이션, 스파이, 수정, 합성, diff 등 여러 모드로 실행됩니다.

hoverctl 명령을 사용한 기본적인 캡처-재생 흐름:

hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate

Hoverfly의 관리 API는 기본적으로 8888 포트에서 실행되며 프록시는 8500 포트에서 실행됩니다. 기록-재생 프록시 모델은 모든 응답을 수동으로 작성하는 대신 기존 트래픽을 빠르게 가상화하려는 경우에 적합합니다. 호스팅되는 Hoverfly Cloud도 있습니다.

Mountebank

Mountebank는 “임포스터(imposters)”를 중심으로 구축된 오픈 소스 도구입니다. 임포스터는 단일 포트에서 수신하고 단일 프로토콜을 사용하는 단일 가상 서비스입니다. HTTP 및 HTTPS 외에도 Mountebank는 TCP 및 SMTP도 처리하며, 이는 종속성이 일반 REST API가 아닐 때 유용합니다. 포트 2525의 REST 제어 플레인을 통해 전적으로 제어할 수 있습니다.

설치 및 시작:

npm install -g mountebank
mb

그런 다음 제어 포트에 JSON을 POST하여 임포스터 생성:

curl -X POST http://localhost:2525/imposters \
  -H "Content-Type: application/json" \
  -d '{
    "port": 4545,
    "protocol": "http",
    "stubs": [{
      "predicates": [{ "equals": { "method": "GET", "path": "/user/42" } }],
      "responses": [{ "is": { "statusCode": 200, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }]
    }]
  }'

프레디케이트(predicates)는 어떤 요청이 일치하는지 결정하고, 응답은 무엇이 반환되는지 정의합니다. Mountebank의 다중 프로토콜 지원은 오픈 소스 옵션 중에서 차별점입니다.

Parasoft Virtualize 및 Broadcom Service Virtualization

대기업을 위한 강력한 도구로는 Parasoft Virtualize와 Broadcom Service Virtualization(DevTest 스위트의 일부)이 있습니다. 이들은 HTTP 외에 다양한 프로토콜 및 메시지 형식을 시뮬레이션하고, 가상 서비스를 실제 데이터 소스에 연결하며, 여러 환경에서 가상화를 중앙 집중식으로 관리해야 하는 팀을 위해 구축된 상용 플랫폼입니다.

Parasoft Virtualize는 광범위한 산업 표준 프로토콜 및 메시지 형식 지원과 외부 데이터 소스에서 제공되는 데이터 기반 가상 서비스를 광고합니다. Broadcom의 제품은 병렬 개발 및 테스트를 위한 가상화된 환경을 통해 유사한 엔터프라이즈 시나리오를 목표로 합니다. 두 제품 모두 엔터프라이즈 라이선스 및 설정 오버헤드를 수반하므로, 소수의 REST 엔드포인트가 아닌 레거시 프로토콜(메인프레임, MQ, 고정 길이 메시지)을 대규모로 가상화할 때 적합합니다. 종속성이 일반적인 HTTP API인 경우, 위에 언급된 오픈 소스 도구 또는 API 플랫폼이 훨씬 저렴한 비용으로 해결해 줍니다. 각 공급업체에 최신 프로토콜 목록 및 가격을 확인하세요.

Apidog: API 계약을 위한 경량 서비스 가상화

가상화해야 하는 종속성이 계약으로 정의된 HTTP API인 경우, Apidog는 별도의 도구 없이 해당 부분을 처리합니다. API를 설계하거나 가져오면 Apidog는 자동으로 목 서버를 설정합니다. 백엔드 코드가 존재하기 전에 프런트엔드 또는 테스트 스위트는 스키마만으로 작동하는 엔드포인트를 얻습니다.

이것이 단순한 스터브보다 가상화에 가까운 이유는 Apidog의 목이 스키마 인식적이고 동적이기 때문입니다. Apidog의 Smart Mock은 JSON 스키마를 읽고 모든 제약 조건(타입, 형식, 열거형, 필수 필드)을 준수하는 응답을 생성합니다. 또한 필드 이름을 내장 규칙과 매칭하여 email이라는 필드는 유효한 이메일을 반환하고 city라는 필드는 플레이스홀더 쓰레기 대신 도시 이름을 반환합니다. 더 세밀한 제어를 위해 Faker.js 기반의 동적 값은 모든 호출에서 현실적인 데이터를 생성하며, 결정론이 필요한 곳에는 고정된 값을 지정할 수 있습니다.

또한 요청 매개변수에 따라 다른 응답을 반환하는 사용자 지정 목 규칙을 작성할 수 있으며, 이는 가상화를 고정된 스터브와 구별하는 요청 매칭 동작입니다. 목 서버는 GUI 또는 헤드리스 모드로 실행되므로 로컬 개발 및 CI 모두에 적합합니다. 자세한 내용은 1분 안에 API 모킹하는 방법을 참조하세요.

Apidog가 적합한 곳: HTTP/REST 및 유사한 API 계약 서비스 가상화. 적합하지 않은 곳: 임의의 레거시 프로토콜을 위한 프록시 기반 기록-재생 도구가 아니며, 부하 생성기도 아닙니다. 이러한 용도에는 위에 언급된 도구들이 올바른 선택입니다. 더 광범위한 도구별 비교는 온라인 API 모킹 도구 비교최고의 API 모킹 도구 10가지를 참조하세요.

시작하는 방법

종속성에 맞는 도구를 선택하세요. 그 반대가 아닙니다.

  1. **프로토콜을 식별하세요.** 일반 HTTP/REST인가요? 여기서는 거의 모든 것이 작동하며, API 플랫폼이 가장 마찰이 적습니다. TCP 또는 SMTP가 필요한가요? Mountebank입니다. 대규모 레거시 엔터프라이즈 프로토콜인가요? Parasoft 또는 Broadcom입니다.
  2. **기록할 것인지, 명세할 것인지 결정하세요.** 실제 서비스가 존재하고 트래픽을 라우팅할 수 있다면 기록-재생(Hoverfly, WireMock 기록 모드)이 가장 빠릅니다. 아직 존재하지 않는다면 API 계약(Apidog, WireMock 스터브, Mountebank 임포스터)을 통해 가상 서비스를 구동하세요.
  3. **앱이 가상 서비스를 가리키도록 설정하세요.** 테스트 또는 개발 환경에서 기본 URL 또는 프록시 설정을 변경하고, 이를 구성 뒤에 두어 가상과 실제 간 전환이 단일 변수로 이루어지도록 합니다.
  4. **실패 사례를 추가하세요.** 핵심은 오류 경로를 테스트하는 것이므로, 4xx 및 5xx 응답, 타임아웃, 잘못된 형식의 본문을 추가하세요. 이는 실제 종속성으로는 연습할 수 없는 부분입니다.
  5. **CI에서 실행하세요.** 노트북에서만 실행되는 가상 서비스는 귀하에게는 도움이 되지만 빌드에는 도움이 되지 않습니다. 파이프라인에 포함하여 녹색이 녹색을 의미하도록 하세요. GUI 없이 CI에서 헤드리스로 실행되는 목이 필요한 경우 헤드리스 API 목 도구를 참조하세요.

일반적으로 가상 종속성과 실제 종속성 간의 장단점에 대해서는 목 서버 vs 실제 서버에서 각각을 언제 사용해야 하는지 설명합니다.

자주 묻는 질문

**서비스 가상화는 모킹과 같은가요?** 정확히 같지는 않습니다. 모킹은 일반적으로 단위 테스트를 위해 프로세스 내부의 객체를 대체하고 호출 방식을 검증합니다. 서비스 가상화는 애플리케이션이 실제 프로토콜을 통해 연결하는 네트워크 포트에서 실행 중인 서비스를 설정합니다. 사람들은 HTTP 가상 서비스를 비공식적으로 “목”이라고 부르기도 하지만, 이는 괜찮습니다. 하지만 기술적인 구분은 프로세스 내 객체와 네트워크 서비스 간에 있습니다.

**실제 테스트 환경 대신 가상 서비스를 언제 사용해야 하나요?** 실제 종속성을 사용할 수 없거나, 속도 제한이 있거나, 비용이 많이 들거나, 제어하기 어려울 때 가상화를 사용하세요. 이는 결정적이고, 무료이며, 항상 사용 가능한 응답을 제공하고, 실제 시스템에서는 유발할 수 없는 오류를 시뮬레이션할 수 있게 합니다. 최종 통합 확인을 위해 실제 서비스에 대한 소규모 테스트 세트는 유지하세요.

**가상 서비스는 상태를 가질 수 있나요?** 네, 그렇습니다. WireMock 및 Mountebank와 같은 도구는 이전 요청에 따라 응답이 변경되는 상태를 가지는 시나리오를 지원합니다. 예를 들어, 빈 카트를 반환한 다음 POST 요청 후에 항목이 있는 카트를 반환하는 식입니다. 이는 단일 호출보다는 워크플로를 시뮬레이션할 때 중요합니다.

**유료 엔터프라이즈 도구가 필요한가요?** 많은 비HTTP 프로토콜을 가상화하거나 대규모 조직에서 가상화를 관리하는 경우에만 필요합니다. 일반적인 HTTP API의 경우, 오픈 소스 도구(WireMock, Hoverfly, Mountebank) 또는 API 플랫폼 목 서버가 엔터프라이즈 라이선스 없이 작업을 처리합니다.

**명세로부터 HTTP API를 가상화하는 가장 빠른 방법은 무엇인가요?** API 정의를 스키마에서 목을 생성하는 도구로 가져오세요. Apidog는 이를 자동으로 수행합니다. OpenAPI 명세를 가져오면 현실적인 동적 데이터를 포함하는 스키마 인식 목 서버를 얻을 수 있으며, 응답을 직접 작성할 필요가 없습니다. 거기서부터 테스트에 필요한 특정 요청/응답 조건에 대한 사용자 지정 규칙을 추가할 수 있습니다.

Apidog에서 API 설계-첫 번째 연습

API를 더 쉽게 구축하고 사용하는 방법을 발견하세요