모의 API란 무엇인가? 알기 쉽게 설명

모의(mock) API는 실제 API처럼 동작하는 가짜 API입니다. 동일한 요청을 수락하고, 동일한 형태의 응답을 반환하며, 호출할 수 있는 URL을 가지고 있지만, 해당 URL 뒤에는 실제 데이터베이스, 비즈니스 로직, 실제 서비스가 없습니다. 응답은 미리 정의한 것입니다.

이는 사소하게 들리지만, 아이디어 자체는 간단합니다. 그 가치는 뒤에 있는 것이 존재하기 전이나, 실제 서비스가 너무 느리거나, 비용이 너무 많이 들거나, 호출하기에 너무 신뢰할 수 없을 때 인터페이스를 기반으로 구축하고 테스트할 수 있게 해준다는 점에서 나옵니다. 이 설명서는 해당 용어를 정확하게 정의하고, 모의 API가 혼동되는 다른 개념들과 구분하며, 모의 API가 어떻게 동작하는지를 결정하는 정적-동적 구분을 설명합니다.

모의 API는 실제로 무엇인가

간단히 말해, 모의 API는 요청-응답 매핑입니다. 요청이 들어오면, 모의 API는 사용자가 설정한 규칙과 일치시켜 응답을 선택하고 다시 보냅니다. 사용자가 요구하지 않는 한 중간에 어떠한 계산도 없습니다.

모의 API는 세 부분으로 구성됩니다. 첫째, 인터페이스: 수락하는 경로, 메서드, 매개변수로 실제 API와 정확히 일치해야 합니다. 둘째, 응답 정의: 반환하는 본문, 상태 코드, 헤더입니다. 셋째, 일치 로직: 간단한 경로 일치부터 쿼리 매개변수나 헤더에 따라 분기하는 규칙에 이르기까지, 주어진 요청에 대해 어떤 응답을 받을지 모의 API가 결정하는 방식입니다.

인터페이스가 실제 API와 일치하기 때문에 모의 API를 호출하는 코드는 그것이 가짜라는 것을 알지 못합니다. 기본 URL만 바꾸면 동일한 클라이언트가 실제 서비스와 통신합니다. 이러한 상호 교환성이 핵심입니다. 직접 구축하는 과정을 보려면, 테스트용 API 모킹 가이드를 참조하세요.

모의 API가 아닌 것이 무엇인지 정확히 아는 것이 중요합니다. 캐시가 아닙니다. 캐시는 실제 응답을 저장하지만, 모의 API는 응답을 생성하기 때문입니다. 샌드박스도 아닙니다. 벤더 샌드박스는 실제의 단순화된 로직을 실행하지만, 모의 API는 로직을 전혀 실행하지 않습니다. 그리고 스테이징 환경도 아닙니다. 스테이징은 실제 시스템의 완전한 배포이기 때문입니다. 모의 API는 이 세 가지보다 훨씬 가볍습니다. 미리 정의된 답변만 있는 API의 정문일 뿐이며, 그 외에는 아무것도 없습니다.

모의(Mock)와 스텁(Stub)의 차이

사람들은 "모의(mock)"와 "스텁(stub)"을 서로 바꿔 사용하지만, 테스트에서는 다른 의미를 가집니다.

스텁은 더 간단한 개념입니다. 호출에 대해 미리 정해진 답변을 반환하고 그 이상은 하지 않습니다. 사용자 정보를 요청하면, 고정된 사용자 정보를 반환합니다. 스텁은 어떻게 호출되었는지에 대해 아무런 의견이 없습니다.

엄격한 테스트 의미에서 모의(mock)는 상호작용도 검증합니다. 호출되었는지, 몇 번 호출되었는지, 어떤 인수로 호출되었는지 확인할 수 있습니다. 모의는 단순히 값을 제공하는 것을 넘어 호출이 잘못되었기 때문에 테스트를 실패시킬 수 있습니다.

일상적인 API 작업에서는 이 경계가 모호하며, "모의 API"는 일반적으로 둘 다 포함합니다. 유용한 결론은 다음과 같습니다. 스텁은 응답하고, 모의는 응답하고 관찰합니다. 코드가 받는 데이터에만 관심이 있다면 스텁 방식의 응답으로 충분합니다. 코드가 올바른 방식으로 올바른 호출을 했는지에 관심이 있다면, 진정한 모의가 추가하는 검증이 필요합니다. 더 넓은 용어를 보려면 유효성 검사(validation)와 검증(verification)의 차이점을 참조하세요.

두 가지 용어가 더 있습니다. 페이크(fake)는 동작하지만 단순화된 구현으로, 실제 데이터베이스 대신 사용되는 인메모리 데이터베이스와 같습니다. 로직이 있지만 더 적습니다. 스파이(spy)는 실제 객체를 감싸고 동작을 변경하지 않고 어떻게 호출되었는지 기록합니다. API 개발에서 사용되는 "모의 API"라는 용어는 실제 URL에서 HTTP를 통해 제공되는, 선택적 검증 기능이 있는 스텁에 가장 가깝습니다. 용어를 엄격하게 구분할 필요는 없지만, 스펙트럼을 알면 헤매지 않고 테스트 문서를 읽는 데 도움이 됩니다.

모의 API 대 실제 서버

실제 서버와 모의 서버는 동일한 URL에 위치하여 동일한 JSON을 반환할 수 있으므로, 차이점은 엔드포인트 뒤에서 일어나는 일에 있습니다.

실제 서버는 진실을 알려줍니다. 실제 코드를 실행하고 시스템이 작동함을 증명합니다. 또한 느리고, 상태를 가지며, 실제 부작용을 일으킬 수 있으므로, 실제 서버에 대한 테스트는 카드에 요금을 청구하거나 이메일을 보낼 수 있습니다.

모의 서버는 사용자가 알려준 것만 알려줍니다. 빠르고, 부작용이 없으며, 완벽하게 예측 가능하여 개발 및 대부분의 테스트에 이상적입니다. 그러나 모의는 실제 로직을 실행하지 않기 때문에 잘못될 수 있고 결코 알 수 없습니다. 그래서 일부 테스트는 실제 서버에서 유지합니다. 이러한 장단점은 모의 서버 대 실제 서버에서 자세히 다룹니다.

정적 모의와 동적 모의

모의는 두 가지 방법 중 하나로 응답을 반환하며, 이 선택은 모의 사용 경험을 형성합니다.

정적 모의는 고정된 페이로드를 반환합니다. 정확한 JSON을 한 번 작성하면, 모든 일치하는 요청이 동일한 본문을 받습니다. 정적 모의는 예측 가능하여 주장을 테스트하기 쉽습니다. 단점은 현실성입니다. 단일 하드코딩된 페이로드는 긴 문자열, 빈 배열 또는 예상치 못한 null 값에서 깨지는 코드의 버그를 드러내지 않습니다.

동적 모의는 요청별로 응답을 생성합니다. 고정된 `“id”: “user_1001”` 대신, 각 호출마다 새로운 UUID를 생성합니다. 하나의 이름 대신, 매번 다른 현실적인 이름을 반환합니다. 동적 모의는 일반적으로 Faker.js와 같은 데이터 생성 문법을 사용하여 이를 구현하므로, `email`이라는 필드는 이메일을 생성하고 `created_at`은 날짜를 생성합니다. 이는 더 현실적이고 엣지 케이스를 노출하는 데 더 뛰어나지만, 정확하게 주장하기가 더 어렵다는 단점이 있습니다.

대부분의 팀은 둘 다 사용합니다. 하나의 알려진 값이 필요한 어서션 중심의 단위 테스트에는 정적 모의를 사용합니다. 다양성이 고정된 응답보다 더 중요한 개발, 데모 및 퍼징 스타일 커버리지에는 동적 모의를 사용합니다.

동적 모의는 또한 조건부일 수 있으며, 이는 단순한 생성 단계를 넘어섭니다. 조건부 모의는 요청에 따라 분기합니다. `/orders/404`에 대한 요청은 `404`를 반환하고, 잘못된 토큰이 있는 요청은 `401`을 반환하며, 그 외의 모든 것은 정상적인 `200`을 반환합니다. 하나의 모의 엔드포인트는 정상 경로와 여러 실패 경로를 동시에 처리합니다. 이는 건강한 실제 서버가 요청 시 생성하지 않을 오류 응답을 재현할 수 있기 때문에 모의를 테스트에 매우 유용하게 만듭니다.

개발에서 모의 API가 활용되는 지점

모의 API는 세 가지 시점에서 유용합니다. 초기에 프론트엔드 팀과 백엔드 팀이 계약에 합의하고 병렬로 개발할 수 있게 하여 서로 기다리지 않도록 합니다. 테스트 중에는 코드를 네트워크 불안정성으로부터 격리시키고, 실제 서버가 요청 시 생성하지 않을 오류 응답을 트리거할 수 있게 합니다. 그리고 데모 및 프로토타입의 경우, 피치 중간에 실패할 라이브 종속성 없이 제어되고 예측 가능한 데이터를 제공합니다. 이러한 시나리오는 API 모킹 활용 사례 가이드에서 더 자세히 설명합니다.

반복되는 위험은 드리프트(drift)입니다. 모의 API는 인터페이스의 스냅샷이며, 인터페이스는 변경됩니다. 실제 API가 필드를 추가하거나 이름을 변경하면, 연결되지 않은 모의 API는 계속해서 이전 형태를 제공하고, 사용자의 테스트는 더 이상 존재하지 않는 계약에 대해 통과합니다.

해결책은 모의 API를 직접 작성하는 것이 아니라 파생된 것으로 취급하는 것입니다. 실제 API가 게시하는 것과 동일한 스키마에서 모의 API를 생성하여 계약이 변경되면 모의 API가 다시 생성되도록 합니다. 직접 타이핑한 모의 API는 즉시 노후화되기 시작하는 복사본입니다. 스펙에서 생성된 모의 API는 항상 최신 스냅샷입니다. 이 차이는 첫날에는 나타나지 않지만, 6개월 후에도 모의 API가 신뢰할 수 있는지 여부를 결정합니다. Apidog는 이런 방식으로 작동합니다. API를 한 번 설계하면, 필드 이름에서 추론된 현실적인 데이터로 모의 엔드포인트가 해당 설계에서 생성됩니다. 모의 API, 문서, API 계약 테스트는 모두 단일 소스에서 읽어오므로 일관성을 유지합니다. 설계에서 모의까지의 전체 흐름을 보려면 Apidog를 다운로드하세요.

자주 묻는 질문

간단히 말해 모의 API란 무엇인가요?

모의 API는 실제 API를 모방하는 가짜 API입니다. 동일한 경로를 노출하고 동일한 형태의 응답을 반환하지만, 그 뒤에는 실제 로직이나 데이터베이스가 없습니다. 응답은 미리 정의되어 있어 실제 서비스가 존재하기 전에 인터페이스를 기반으로 구축하고 테스트할 수 있습니다.

모의(mock)와 스텁(stub)의 차이점은 무엇인가요?

스텁은 미리 정해진 응답만 반환합니다. 엄격한 테스트 의미에서 모의는 상호작용도 검증하므로, 올바른 인수로 올바른 횟수만큼 호출되었는지 확인할 수 있습니다. 스텁은 응답하고, 모의는 응답하고 관찰합니다.

모의 API는 실제 서버와 어떻게 다른가요?

모의 API는 실제 계산 없이 미리 정의된 응답을 반환하므로 빠르고 예측 가능하며 부작용이 없습니다. 실제 서버는 실제 데이터베이스에 대해 실제 로직을 실행하므로 느리고 상태를 가지지만 시스템이 실제로 작동함을 증명합니다. 개발에는 모의 API를 사용하고, 계약 및 엔드투엔드 테스트에는 실제 서버를 사용합니다.

정적 모의 또는 동적 모의 중 무엇을 사용해야 하나요?

단위 테스트에 적합한, 하나의 예측 가능한 값을 어설션해야 할 때는 정적 모의를 사용하세요. 엣지 케이스를 찾아낼 수 있는 현실적이고 다양한 데이터가 필요할 때는 동적 모의를 사용하세요. 이는 개발 및 데모에 적합합니다. 많은 팀이 둘 다 사용합니다.

모의 API가 부정확해지는 것을 어떻게 막을 수 있나요?

모의 API를 수동으로 작성하는 대신, 실제 API가 게시하는 것과 동일한 스키마에서 생성하세요. 계약이 변경되면 모의 API도 다시 생성됩니다. 실제 API에 대한 스케줄링된 계약 테스트를 통해 남은 드리프트도 조기에 파악할 수 있습니다.