본문으로 건너뛰기
고급약 20분

컨슈머 주도 계약 테스트와 Pact: 마이크로서비스 간 약속 지키기

OpenAPI가 제공자 관점의 계약이라면, Pact는 소비자(컨슈머)가 원하는 것을 기준으로 계약을 만든다. 마이크로서비스가 많은 조직에서 이 방식이 왜 유용한지 이해한다.

  • #ConsumerDrivenContract
  • #Pact
  • #마이크로서비스

개념

서비스가 많아지면 생기는 문제

마이크로서비스 환경에서는 서비스 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를 바꿨는데 어떤 팀이 영향을 받는지 몰라서 사고가 났다"는 문제는, 서비스가 많아질수록 심해진다. 컨슈머 주도 계약 테스트는 이 두 문제를 동시에 해결한다 — 소비자가 실제로 쓰는 것만 계약으로 관리하고, 그 계약을 깨는 변경은 자동으로 걸러진다.

실습 과제

과제 1 — 관점 차이 적용하기 (10분)

"상품 상세 API"에 대해, OpenAPI 스펙에는 20개 필드가 정의되어 있지만 프런트엔드는 그중 5개만 실제로 사용한다고 하자. 컨슈머 주도 계약 관점에서 이 상황을 어떻게 다르게 다룰 수 있을지 설명한다.

과제 2 — 계약 깨짐 시나리오 (10분)

제공자 팀이 orderId 필드 이름을 id로 바꾸려 한다. Pact 방식의 컨슈머 주도 계약 테스트가 있었다면, 이 변경이 배포되기 전에 어떻게 걸러질 수 있는지 순서대로 설명한다.

자가 체크리스트

  • 컨슈머 주도 계약 테스트가 OpenAPI 계약 테스트와 어떤 관점 차이가 있는지 설명할 수 있다
  • Pact의 기본 동작 흐름(계약 생성 → 공유 → 제공자 측 검증)을 설명할 수 있다
  • 두 방식이 각각 어떤 상황에 더 적합한지 판단할 수 있다
  • QA가 계약 테스트 도입에서 할 수 있는 역할을 설명할 수 있다

흔한 실수

  • OpenAPI 계약 테스트와 컨슈머 주도 계약 테스트를 같은 것으로 혼동한다. 관점(제공자 vs 소비자)이 다르다.
  • 소비자가 명확하지 않은 공개 API에도 컨슈머 주도 계약을 강제하려 한다. 불특정 다수가 쓰는 API는 OpenAPI 방식이 더 적합하다.
  • 계약 테스트를 도입하면 서비스 간 커뮤니케이션이 필요 없어진다고 생각한다. 계약 테스트는 소통을 자동 검증으로 보완하는 것이지, 완전히 대체하지는 않는다.

참고 자료

  • Pact 공식 문서 — 컨슈머 주도 계약 테스트의 공식 가이드
  • Martin Fowler — Contract Test — 계약 테스트 개념을 정리한 대표 아티클