개념
서비스가 많아지면 생기는 문제
마이크로서비스 환경에서는 서비스 A가 서비스 B의 API를 호출하고, B는 다시 C를 호출하는 식으로 의존 관계가 복잡해진다. 레슨 4에서 배운 OpenAPI 계약 테스트는 API 제공자(Provider)가 스펙대로 동작하는지를 확인하지만, 한 가지 질문에는 답하지 못한다 — "이 API를 실제로 쓰는 소비자(Consumer)들이 정말로 필요로 하는 게 뭔지" 는 제공자 혼자만의 관점으로는 알기 어렵다.
컨슈머 주도 계약(Consumer-Driven Contract)
이름 그대로, API를 소비하는 쪽이 "나는 이런 응답이 필요하다"는 계약을 먼저 정의하고, 제공자는 그 계약을 만족하는지 검증받는 방식이다. 모듈 5(레슨 9)에서 배운 생태계 다이어그램의 화살표 하나하나가, 이 관점에서는 "소비자가 정의한 계약"으로 구체화된다.
OpenAPI 계약 테스트: "제공자가 만든 스펙대로 동작하는가?" (제공자 관점)
컨슈머 주도 계약 테스트: "소비자가 실제로 필요로 하는 걸 제공하는가?" (소비자 관점)Pact의 동작 방식
Pact는 컨슈머 주도 계약 테스트를 구현하는 대표적인 도구다.
1. 소비자 측에서 "이 API를 이렇게 호출하면, 이런 응답을 기대한다"는
계약 파일(Pact 파일)을 자동으로 생성한다
2. 이 계약 파일을 제공자 팀에 전달한다(공유 저장소를 통해)
3. 제공자 측 CI에서, 실제 API가 이 계약을 만족하는지 자동으로 검증한다{
"description": "주문 상세 조회 요청",
"request": { "method": "GET", "path": "/orders/123" },
"response": {
"status": 200,
"body": { "orderId": "123", "status": "shipped" }
}
}이 계약은 "소비자(예: 프런트엔드)가 주문 상세를 조회할 때, 최소한
orderId와 status 필드가 있는 응답을 기대한다"는 뜻이다. 제공자
팀이 API를 바꾸려 할 때, 이 계약을 깨는 변경이라면 제공자의 CI가
실패해서, 배포 전에 "이 변경이 어떤 소비자에게 영향을 주는지"
바로 알 수 있다.
어느 쪽을 언제 쓰는가
| OpenAPI 계약 테스트 | 컨슈머 주도 계약(Pact) | |
|---|---|---|
| 관점 | 제공자가 정한 전체 스펙 | 소비자가 실제로 쓰는 부분 |
| 장점 | 전체 API 문서화와 함께 관리하기 쉬움 | 소비자 요구를 놓치지 않음, 불필요한 부분까지 검증하지 않아 유연함 |
| 적합한 상황 | API를 공개적으로 제공하거나, 많은 불특정 소비자가 있을 때 | 내부 마이크로서비스처럼 소비자가 명확히 식별될 때 |
두 방식은 경쟁 관계라기보다, API의 성격에 따라 선택하거나 함께 쓰는 관계다.
QA가 계약 테스트 도입에서 할 수 있는 역할
QA가 계약 테스트 자체를 직접 구현하지 않더라도, "이 두 서비스 간 계약이 명시적으로 정의되어 있는가?"를 확인하고, 정의되어 있지 않다면 이를 제안하는 것만으로도 큰 가치가 있다 — 이건 모듈 5(레슨 9)의 신뢰 경계 개념을, 실제 자동 검증 장치로 구체화하도록 이끄는 역할이다.
실무에서 왜 필요한가
"프런트엔드 팀이 필요 없는 필드까지 API 제공자가 전부 문서화하고 관리하느라 시간을 낭비한다"거나 "제공자가 API를 바꿨는데 어떤 팀이 영향을 받는지 몰라서 사고가 났다"는 문제는, 서비스가 많아질수록 심해진다. 컨슈머 주도 계약 테스트는 이 두 문제를 동시에 해결한다 — 소비자가 실제로 쓰는 것만 계약으로 관리하고, 그 계약을 깨는 변경은 자동으로 걸러진다.