API Test란 무엇인가 — 왜 Postman으로 Contract Test를 더 이상 하지 않는가
한때 "API 개발의 기본 중의 기본"이었던 Postman. 지금, 개발자들은 조용히 떠나고 있다.
이 블로그에 Postman 을 다루는 내용을 처음 다루었던 것은 2020년도였다.
Postman의 Test Scripts와 Collection Runner를 활용하여 API가 약속대로 동작하는지 검증하는 방법에 대한 내용을 다루었는데, 그 당시에는 Postman을 이용한 Contract Test가 충분히 합리적이었다.
그러나, 2026년도 현재에는 Postman을 이용한 Contract Test 라는 표현은 업계에서 통용되는 의미와 조금 멀어졌다. 새롭게 카테고리를 만들게 된 이유가 이것이다.
이 글은 머릿말과 같은 기능으로, 본격적으로 Postman (2026) 을 다루기에 앞서 몇 가지를 짚어두려 한다.
API Test가 무엇인지,
왜 과거에는 Postman을 이용하여 Contract Test를 했었는지,
왜 지금은 그 방식이 달라졌는지,
그리고 지금 Postman은 어느 자리에 있는지.
Postman은 여전히 많은 곳에서 사용되고 있다. 그러나 서서히 이탈하는 이들이 늘어나고 있는데 그 이유는 다음 글( Postman Trend 2026 )에서 다루어보겠다.
01 먼저 — API Test란 무엇인가
서비스는 결국 API로 소통한다
현대의 서비스들은 직접 대화하지 않는다. 프론트엔드는 백엔드에게, 백엔드는 또 다른 백엔드에게, 모바일 앱은 서버에게 — 모두 API(Application Programming Interface) 를 통해 요청을 보내고 응답을 받는다.
쇼핑몰에서 "주문하기" 버튼을 누르는 순간, 눈에 보이지 않는 곳에서는 수십 개의 API 호출이 일어난다.
- 재고를 확인하고,
- 결제를 처리하고,
- 배송 정보를 생성하고,
- 알림을 보내는 등
모든 과정이 API를 통해 연결된다.
API가 약속대로 동작하지 않으면?
버튼을 눌러도 아무 동작하지 않거나, 결제는 됐는데 주문이 안 잡히거나 (아찔) , 알림이 엉뚱한 사람에게 가는 일 (안돼..!) 이 생긴다.
실제로 서비스 장애의 상당수는 코드 자체의 버그가 아니라, API가 기대한 대로 동작하지 않은 것에서부터 시작된다.
API Test는 바로 이것을 검증하는 작업이다. "이 API가 약속한 요청을 받았을 때, 약속한 응답을 주는가?"
API Test의 종류
무엇을 검증하느냐에 따라 API Test 의 성격이 달라지는데 이에 따라 테스트를 분류한다.
| 기능 테스트 ( Functional Test ) |
"이 엔드포인트에 이 요청을 보내면 이 응답이 오는가?"
상태코드, 응답 바디, 헤더가 예상한 것과 일치하는지 확인한다. - 가장 기본적인 형태 - Postman이 가장 잘하는 영역 |
| 계약 테스트 ( Contract Test ) |
"지금 잘 동작하는가"를 넘어 "서비스 간의 약속이 깨지지 않았는가"를 검증.
API를 제공하는쪽( Provider ) 과 사용하는쪽( Consumer ) 사이의 인터페이스가 변경됐을때 서로 충돌하지 않는지 확인하는 것이 핵심이다. |
| 성능 테스트 ( Performance Test ) |
"이 API가 동시에 1만명이 요청을 보내도 버티는가" 를 검증한다.
- k6, Apache JMeter 같은 툴이 주로 쓰인다. |
| 보안 테스트 ( Security Test ) |
인증 없이 접근 가능한지, SQL 인젝션이 통하는지 등을 검증한다.
|
이 글과 이 카테고리에서 주로 다루는 것은 기능 테스트(Functional Test)와 계약테스트(Contract Test) , 그리고 그 경계에 있는 것들이다.
02그땐 왜 Postman으로 Contract Test를 했나
2020년의 맥락
2020년, "Contract Test By Postman"이라는 카테고리가 만들어졌을 때의 맥락을 먼저 이해해야 한다.
당시 Martin Fowler 가 정의한 Contract Test의 핵심은 이것이었다.
"서비스 제공자가 계약(요청과 응답)대로만 동작하는지 검사하는 것"
이 정의만 놓고 보면, Postman으로 충분히 Contract Test를 구현할 수 있었다.
Postman의 Test Scripts로 응답 상태 코드를 검증하고, 응답 바디의 필드가 예상한 형태인지 확인하고, 이 테스트들을 Collection으로 묶어 Newman으로 CI 에서 실행한다.
API가 "계약대로" 동작하는지 검증하는 것 — 이 목적만 보면 Postman은 꽤 훌륭한 도구였다.
실제로 당시 많은 팀들이 이 방식으로 API 테스트를 구축했다. Postman이 유일한 선택지였기 때문이기도 했고, 진입 장벽이 낮았기 때문이기도 했다.
그리고 그 방식은 틀리지 않았다.
중요한 것은, 당시의 접근이 틀린 게 아니었다는 점이다.
Postman으로 API 응답을 검증하는 것은 명백히 테스트다. 서비스가 예상한 대로 동작하는지 확인하고, 그 결과를 CI에서 자동으로 실행하는 것은 분명히 가치 있는 작업이었다. "Contract Test"라는 표현이 이 맥락에서 완전히 어긋난 것도 아니었다.
03 왜 지금은 Postman으로 Contract Test를 하지 않나
마이크로서비스가 문제를 바꿔버렸다
2020년 이후, 상황이 달라졌다. MSA가 본격적으로 확산되면서 서비스 간 API 의존성이 폭발적으로 늘어났다.
문제는 이것이었다. Postman 방식의 테스트는 Provider 혼자 잘 동작하는지 를 확인한다. 그런데 마이크로서비스 환경에서 진짜 무서운 장애는 여기서 오지 않는다. Provider가 "하위 호환성을 유지한다"고 생각하며 필드 하나를 수정했는데, 그 필드에 의존하던 Consumer 서비스가 조용히 죽는 상황이 더 빈번했다.
Postman 테스트는 이걸 잡아내지 못했다. Consumer가 어떤 필드에 실제로 의존하는지 Provider가 알 방법이 없었고, Provider 혼자 테스트를 통과했다고 해서 Consumer와의 호환성이 보장되지 않았다.
Consumer-Driven Contract Testing의 등장
이 문제를 해결하기 위해 나온 개념이 Consumer-Driven Contract Testing 이다.핵심 아이디어는 방향을 뒤집는 것이다.
기존 방식이 "Provider가 스스로 잘 동작하는지 테스트" 였다면 CDCT는 "Consumer가 실제로 의존하는 것들을 계약으로 명시하고, Provider가 그 계약을 만족하는지 검증"한다.
Consumer는 "나는 이 엔드포인트에서 이 필드들을 쓴다"는 계약 파일을 생성한다. Provider는 이 계약 파일을 가져와서 "내 구현이 이 계약을 깨뜨리지 않는가"를 CI에서 자동으로 검증한다.
Provider가 필드를 바꾸거나 삭제하려는 순간, 어느 Consumer가 그 필드에 의존하는지 즉시 알 수 있다.
이 방식을 구현하는 사실상의 표준 도구가 Pact다. 두 서비스를 동시에 띄울 필요 없이, 각자 독립적으로 테스트를 실행하면서 계약 호환성을 검증할 수 있다.
Postman이 밀려난 이유
Postman이 이 방향으로 가지 못한 데는 구조적인 이유가 있다.
Postman의 Collection은 Provider 중심으로 설계됐다. "이 API에 요청을 보내면 이 응답이 온다"는 관점이다. Consumer가 어떤 필드에 의존하는지를 명시하고, 그 의존성을 계약으로 관리하고, CI에서 배포 호환성을 자동으로 판단하는 can-i-deploy 같은 메커니즘이 없다.
게다가 2023년 오프라인 모드 제거와 2026년 무료 플랜 축소로 인해 많은 팀들이 이탈하면서, "Postman이 아니어도 된다"는 인식이 빠르게 퍼졌다. Contract Testing이 중요해질수록 Pact로, 가벼운 API 탐색에는 Bruno나 Thunder Client로 역할이 분리되었다.
04그렇다면 지금 Postman은 어디에 쓰이나
Postman이 사라진게 아니다. 여전히 전 세계 3,500만 여 명이 사용하고 있고, Fortune 500 기업의 98%가 도입하고 있다. 다만 역할이 명확해진 것이다.
| API 탐색과 수동 테스트 |
"이 엔드포인트가 실제로 어떻게 응답하는지" 빠르게 확인하는 용도.
백엔드 개발자가 자신이 만든 API를 두드려보거나, 프론트엔드 개발자가 백엔드 API 동작을 확인할때. - Postman의 직관적인 GUI는 여전히 강점 |
| 외부 파트너·클라이언트 데모 |
API를 외부에 설명할 때 Postman 컬렉션을 공유하는 것은 여전히 통용되는 관행이다. 상대방도 Postman을 알고 있을 가능성이 높고, 비개발자에게 보여주기에도 좋다.
|
| API 문서화 |
컬렉션에서 자동으로 API 문서를 생성하는 기능은 소규모 팀에서 여전히 편리하게 쓰인다.
|
| 엔터프라이즈 API 거버넌스 |
수백 개의 API를 팀 단위로 관리하고, 접근 권한을 제어하고, 사용 현황을 모니터링하는 플랫폼으로서의 역할은 아직 완전히 대체 가능한 대안이 없다.
|
한 마디로 정의하면 이러하다.
Postman은 "API의 Figma"가 됐다.
코드 파이프라인 안에 들어가는 도구라기보다, 개발자가 API를 탐색하고 이해하고 공유하는 도구.
05이 카테고리에서 다룰 것들
"Contract Text By Postman (2020)" 이 Postman으로 API 계약을 검증하는 방법을 다뤘다면, 이 카테고리 "API Test By Postman (2026)" 은 조금 더 넓은 시야로 접근한다.
Postman이 실제로 잘 하는 영역인 API 기능 테스트, 자동화, 팀 협업 을 중심으로, 2026년 현재 변화한 플랜 구조와 새로운 기능들을 실용적인, 실무적인 관점에서 살펴볼 것이다. 그리고 Postman만으로는 부족한 영역 — Contract Testing, 성능 테스트, 보안 테스트 — 에서는 어떤 대안과 함께 쓰면 좋은지도 함께 다룰 예정이다.
Postman이 어디서 강한지, 어디서 한계가 있는지를 명확하게 아는 것. 그것이 도구를 제대로 쓰는 첫걸음이다.
Introduction | Pact Docs
Fast and reliable testing for your APIs and microservices during development. Safety during deployment.
docs.pact.io
bliki: Contract Test
Test Doubles avoid non-deterministic errors, but you need Contract Tests to ensure they remain consistent with the real services.
martinfowler.com
댓글