대부분의 팀은 API를 목업(mock)하는 방법을 알고 있습니다. 하지만 언제 목업이 실제로 도움이 되고 언제 유지보수할 계층만 추가하는지에 대한 명확한 답을 가진 팀은 더 적습니다. 적절한 순간에 사용하는 목업은 실제 병목 현상을 해결해줍니다. 습관적으로 만드는 목업은 현실과 멀어져 조용히 당신을 속이는 또 다른 존재가 됩니다.
이 글은 '어떻게'가 아닌 '언제'에 초점을 맞춥니다. 각 섹션은 목업이 제 역할을 하는 구체적인 상황을 다룹니다: 미완성 백엔드를 기반으로 개발할 때, 오류 경로를 연습할 때, 불안정한 서드파티 서비스를 대신할 때, 데모를 실행할 때, 그리고 CI를 안정화할 때입니다. 이 글을 튜토리얼이 아닌 의사 결정 보조 도구로 읽어주십시오.
병렬 프론트엔드 및 백엔드 개발
이것이 고전적인 경우입니다. 프론트엔드 팀은 백엔드 팀이 아직 구축하지 않은 엔드포인트가 필요합니다. 목업이 없으면 프론트엔드는 기다리거나, 실제 서비스와 처음 연결될 때 오류가 발생하는 추측에 기반하여 코드를 작성하게 됩니다.
목업은 의존성을 끊습니다. 양 팀은 먼저 일반적으로 OpenAPI 문서 형태로 계약에 동의합니다. 프론트엔드는 해당 계약에서 생성된 목업을 기반으로 개발하고, 백엔드는 실제 기능을 구현합니다. 백엔드가 완성되면 프론트엔드는 기본 URL을 바꾸고, 양측이 계약을 준수했다면 다른 것은 아무것도 변경되지 않습니다.
합의가 핵심적인 부분입니다. 프론트엔드만으로 만들어진 목업은 한 팀의 가정을 코드화할 뿐입니다. 공유된 사양에서 파생된 목업은 양 팀의 정렬을 유지하며, 이는 API 계약 테스트의 원리와 동일합니다. 병렬 작업을 해제하기 위해 목업을 사용하되, 양측이 승인한 계약에 대해서만 사용하십시오.
그 이점은 프로젝트 전반에 걸쳐 증폭됩니다. 백엔드에 멈추지 않는 프론트엔드 팀은 자체 일정에 따라 기능을 출시합니다. 반쯤 구축된 엔드포인트에 대해 호출을 받지 않는 백엔드 팀은 집중력을 유지합니다. 디자이너와 제품 관리자는 몇 주 더 일찍 클릭 가능한 빌드를 받아 피드백할 수 있습니다. 이 모든 것은 실제 서비스가 아직 존재할 필요가 없습니다. 유일한 지속적인 비용은 계약이 발전함에 따라 목업을 계약과 동기화하는 것인데, 이는 목업이 직접 작성되지 않고 사양에서 생성될 때 저렴합니다.
필요할 때 트리거할 수 없는 오류 경로 테스트하기
정상적인 API는 200을 반환합니다. 이것이 문제입니다. 클라이언트 코드 또한 429, 500, 503, 잘못된 형식의 바디, 그리고 타임아웃을 처리해야 하지만, 작동 중인 서버는 테스트 요청 시 이러한 응답을 생성하지 않습니다.
목업은 명령에 따라 이를 생성합니다. 하나의 요청에는 500을 반환하도록, 다른 요청에는 Retry-After 헤더를 포함한 429를 반환하도록, 그리고 세 번째 요청에는 의도적인 지연 후 도착하는 바디를 반환하도록 구성할 수 있습니다. 그런 다음 재시도 로직, 백오프, 타임아웃 처리가 모두 제대로 작동하는지 확인할 수 있습니다.
| 테스트 실패 시나리오 | 목업 설정 | 증명하는 것 |
|---|---|---|
| 서버 오류 | 500 반환 |
클라이언트가 재시도한 후 우아하게 기능 저하 |
| 속도 제한 | Retry-After 포함된 429 |
클라이언트가 올바른 간격으로 대기 |
| 느린 네트워크 | 응답을 5초 지연 | 클라이언트가 깔끔하게 타임아웃 처리 |
| 잘못된 페이로드 | 손상된 JSON 반환 | 파서가 충돌 없이 실패 |
이것은 팀이 가장 자주 건너뛰고 가장 후회하는 사용 사례입니다. 한 번도 실행되지 않은 오류 처리는 존재하지 않는 오류 처리와 같습니다. 목업을 철저한 API 검증과 함께 사용하여 각 실패 경로가 가정되지 않고 검증되도록 하십시오.
목업할 가치가 있는 두 번째 종류의 오류가 있습니다: HTTP는 유효하지만 도메인에는 잘못된 응답입니다. 음수 가격의 200, 열거형에 없는 상태의 주문, next 커서가 아무데도 가리키지 않는 페이지네이션된 목록 등입니다. 실제 서버는 올바르다면 이런 것을 절대 보내지 않습니다. 목업은 가능하며, 의도적으로 잘못된 형식이지만 잘 구성된 데이터를 클라이언트에 제공함으로써 파싱 코드가 조용히 내리는 가정을 찾아낼 수 있습니다.
서드파티 API를 대신하기
테스트 내에서 실제 결제 처리기, 매핑 서비스 또는 배송 API를 호출하는 것은 느리고, 때로는 호출당 비용이 발생하며, 제어할 수 없는 서비스에 의존하게 됩니다. 그들의 샌드박스가 다운되면 당신의 테스트 스위트도 다운됩니다.
서드파티를 목업하십시오. 실제 응답을 한 번 기록하거나 공개된 스키마에서 목업을 구축한 다음 목업을 대상으로 테스트를 실행합니다. 테스트는 빠르고, 무료이며, 결정론적이 됩니다. 또한 공급업체에 장애가 발생하더라도 계속 작동합니다.
유지보수 비용이 발생합니다. 서드파티는 알려주지 않고 API를 변경할 수 있으며, 당신의 목업은 이를 알지 못합니다. 해결책은 실제 서비스를 호출하여 응답이 여전히 목업의 형태와 일치하는지 확인하는 작은 예약 작업입니다. 이 계약 확인은 실제 서드파티와 상호작용하는 유일한 지점이며, 사용자가 알아차리기 전에 변경 사항을 감지합니다. 또한 공급업체의 변경 로그를 구독하여 계약 테스트 실패 전에 예정된 변경 사항을 미리 파악하는 것이 좋습니다.
데모 및 프로토타입 구동하기
클라이언트 앞에서 실시간 서비스를 호출하는 데모는 도박과 같습니다. 느린 쿼리, 빈 결과 집합, 또는 불운한 장애는 정교한 발표를 사과로 바꿔버립니다.
목업은 데모를 결정론적으로 만듭니다. 정시 배송되는 주문, 정상적인 수치를 보여주는 대시보드, 깨끗한 결과를 반환하는 검색 등 데모에 필요한 데이터를 정확하게 스크립트할 수 있습니다. 프로토타입에도 동일하게 적용됩니다. 목업이 프로토타입이 기대하는 모든 응답을 제공하기 때문에 백엔드가 존재하기 훨씬 전에 UI 흐름을 검증하거나 기능을 제안할 수 있습니다.
여기서의 요점은 테스트가 아니라 제어입니다. 청중이 무엇을 볼지 당신이 결정하며, 외부적인 요인이 이를 망칠 수 없습니다. 초기 단계 작업의 경우, 목업은 사람들이 클릭할 수 있는 무언가를 가장 빠르게 제시하는 방법인 경우가 많습니다. 이 분야의 도구 비교는 온라인 API 목업 도구에 대한 글에서 다룹니다.
프로토타입 목업은 디자인 문서 역할도 겸합니다. 목업이 최종 API가 제공할 정확한 형태를 반환할 때, 그에 따라 작성하는 프론트엔드 코드는 일회용 스캐폴딩이 아닌 실제 코드입니다. 백엔드가 나중에 동일한 계약을 준수한다면, 프로토타입은 기본 URL 변경만으로 제품이 됩니다. 이것이 목업을 보조 도구로 사용하는 것과 목업을 선점 우위로 사용하는 것의 차이입니다.
CI를 빠르고 안정적으로 유지하기
CI에서 외부 서비스를 호출하는 테스트 스위트는 해당 서비스들이 가진 모든 문제를 상속받습니다. 네트워크 끊김, 속도 제한, 다른 빌드에 의해 방금 변경된 공유 스테이징 데이터: 이 모든 것이 검토 중인 코드와는 아무 관련 없는 불안정한 실패로 이어집니다.
불안정한 테스트는 사람들이 실패를 무시하도록 훈련시키며, 이는 CI의 목적을 상실하게 합니다. 외부 종속성을 목업하면 스위트가 고립됩니다. 모든 실행은 동일한 알려진 상태에서 시작되고, 네트워크 왕복이 없으므로 더 빨리 완료되며, 코드가 실제로 손상되었을 때만 실패합니다.
한 가지 예외를 두십시오. 커밋별 스위트와는 별도로, 실제 API에 대해 얇은 계층의 계약 테스트를 스케줄에 따라 실행하십시오. 이는 목업이 여전히 프로덕션과 일치하는지 확인합니다. 커밋별 스위트는 빠르고 목업된 상태를 유지하며, 예약된 작업이 변경 사항을 감지합니다. 이러한 분리는 건전한 CI/CD 테스트 파이프라인의 핵심입니다.
속도 향상은 사소한 편리함이 아닙니다. 12분에서 90초로 단축되는 스위트는 팀의 작업 방식을 변화시킵니다. 개발자들은 희망하는 대신 모든 푸시 전에 실행합니다. 검토자들은 diff를 읽는 시간 안에 결과를 확인합니다. 빠르고 고립된 스위트는 사람들이 실제로 신뢰하는 것이며, 신뢰는 자동화된 테스트의 투자 수익 전체입니다.
목업을 사용하지 말아야 할 때
목업에는 실패 모드가 있습니다: 현실과 더 이상 일치하지 않는 목업입니다. 프로덕션이 중단되어도 테스트는 초록색을 유지하는데, 이는 가상의 상황을 검증하기 때문입니다.
테스트 대상이 통합 자체일 때는 목업을 사용하지 마십시오. 계약 테스트와 종단 간(end-to-end) 검사는 실제 경계를 확인하기 위해 존재하므로, 이를 목업하는 것은 존재 이유를 없애는 것입니다. 실제 서비스와 대조하여 결코 검증하지 않는 종속성은 목업하지 마십시오. 검증되지 않은 목업은 현실과 멀어지기 때문입니다. 그리고 테스트 환경에서 실제 서비스가 빠르고, 무료이며, 신뢰할 수 있을 때는 목업을 사용하지 마십시오. 목업은 단지 오버헤드일 뿐입니다.
일반적인 규칙: 속도, 격리, 제어를 위해 목업을 사용하고, 목업이 여전히 유효한지 확인하기 위해 실제와 접촉하는 작고 정직한 테스트 세트를 유지하십시오. 목업과 계약 확인을 한 곳에서 관리하고 싶다면, Apidog는 당신의 API 디자인에서 목업을 생성하고 목업과 실제 엔드포인트 모두에 대해 테스트를 실행합니다. 이를 설정하려면 Apidog를 다운로드하고 기존 사양에서 시작하십시오. 개념적 기초를 위해 목업 API가 실제로 무엇인지 확인하십시오.
자주 묻는 질문
실제 API를 호출하는 대신 언제 API를 목업해야 합니까?
속도, 격리 또는 제어가 필요할 때 목업하십시오: 미완성 백엔드에 대한 병렬 개발, 실제 서버가 생성하지 않을 오류 경로 테스트, 느리거나 유료인 서드파티 서비스 대체, 데모 실행, CI 안정화 등입니다. 계약 및 종단 간(end-to-end) 테스트의 경우 실제 API를 호출하십시오.
목업은 통합 테스트를 대체합니까?
아닙니다. 목업은 자신의 코드를 확인하는 단위 및 컴포넌트 테스트용입니다. 통합 및 계약 테스트는 실제 경계를 건드려야 합니다. 그들의 역할은 실제 서비스가 계약과 일치하는지 확인하는 것이기 때문입니다. 이러한 테스트를 목업하는 것은 그 목적을 제거합니다.
목업이 오래되지 않도록 하려면 어떻게 해야 합니까?
공유 스키마, 이상적으로는 OpenAPI에서 목업을 생성하여 계약 변경 시 업데이트되도록 하십시오. 그런 다음 실제 API에 대해 예약된 계약 테스트를 실행하여 실시간 응답이 여전히 해당 스키마와 일치하는지 확인하십시오. 변경 사항은 사용자에게 도달하기 전에 감지됩니다.
제가 제어할 수 없는 서드파티 API를 목업할 수 있습니까?
네, 그리고 이것은 가장 강력한 사용 사례 중 하나입니다. 서드파티의 실제 응답을 기록하거나 공개된 스키마에서 목업을 구축한 다음, 속도와 신뢰성을 위해 목업을 대상으로 테스트하십시오. 공급업체가 API를 변경할 때 알 수 있도록 실시간 서비스에 대한 예약된 확인을 추가하십시오.
목업은 데모 및 프로토타입에 유용합니까?
매우 유용합니다. 목업은 청중에게 보여주고 싶은 데이터를 정확하게 스크립트하여 데모를 결정론적으로 만들고, 실시간 장애나 불운한 데이터로 인한 위험을 없앱니다. 프로토타입의 경우, 목업을 통해 백엔드가 존재하기 전에 UI 흐름을 구축하고 검증할 수 있습니다.