소비자 주도 계약을 통한 마이크로서비스 호환성 보장
Min-jun Kim
Dev Intern · Leapcell

마이크로서비스 통합 문제의 조용한 살인마
현대 소프트웨어 개발의 역동적인 환경에서 마이크로서비스 아키텍처는 탁월한 확장성, 유연성 및 독립적인 배포 가능성을 제공하며 지배적인 패러다임으로 부상했습니다. 그러나 이러한 분산된 특성은 중대한 과제를 야기합니다. 독립적으로 개발 및 배포된 서비스가 예상치 못한 통합 실패 없이 원활하게 통신할 수 있도록 어떻게 보장할까요? 전통적인 통합 테스트는 종종 복잡하고 시간이 많이 소요되는 노력으로 전락하며, 정교한 테스트 환경과 팀 간의 긴밀한 조정을 요구합니다. 백엔드 서비스에서 치명적인 변경이 발생하면 클라이언트 애플리케이션이나 다운스트림 서비스는 런타임이 되어서야 이를 발견하지 못할 수 있으며, 이는 프로덕션 인시던트와 좌절감을 느끼는 사용자로 이어집니다.
이러한 문제는 마이크로서비스 생태계에서 통합 테스트에 대한 보다 효율적이고 안정적인 접근 방식의 중요성을 강조합니다. 여기서 Pact.io와 같은 도구를 사용한 "소비자 주도 계약 테스트"가 실용적인 해결책으로 등장하여 호환성을 보장하고 독립적인 개발을 촉진합니다.
이 문서는 Pact.io를 사용한 소비자 주도 계약 테스트의 원칙과 실제 적용에 대해 자세히 알아보고, 팀이 어떻게 탄력적이고 잘 통합된 마이크로서비스를 구축할 수 있는지 보여줄 것입니다.
Pact와 함께하는 계약 테스트의 기둥 이해
구현에 대해 자세히 알아보기 전에 소비자 주도 계약 테스트와 Pact.io를 뒷받침하는 핵심 개념에 대한 공통된 이해를 확립해 봅시다.
- 마이크로서비스: 특정 비즈니스 기능에 초점을 맞춘 독립적으로 배포 가능한 작고 느슨하게 결합된 서비스입니다.
 - 소비자: 다른 서비스에 요청하는 서비스 또는 애플리케이션입니다. 예를 들어, 
주문 서비스는 제품 정보를 필요로 할 때제품 서비스의 소비자일 수 있습니다. - 제공자: 다른 서비스의 요청에 응답하는 서비스입니다. 이전 예에서 
제품 서비스는주문 서비스에 대한 제공자입니다. - 계약: 소비자 및 제공자 간의 공식적인 계약으로, 요청 및 응답의 예상 형식을 설명합니다. 이 계약은 소비자가 제공자로부터 기대하는 상호 작용을 지정합니다.
 - 소비자 주도 계약(CDC) 테스트: 제공자가 API를 통제하는 방식(제공자가 API를 예상치 못하게 변경할 때 소비자가 실패할 수 있음)에서 소비자가 통합 지점 정의에 대한 책임을 명시적으로 설명하는 개발 관행입니다. 소비자는 제공자로부터 필요한 것과 기대하는 것을 명시적으로 말합니다. 이 정의가 계약이 됩니다.
 - Pact.io: 소비자 주도 계약 테스트를 위한 오픈 소스 프레임워크입니다. 소비자가 제공자의 API에 대한 기대를 정의할 수 있게 하여 제공자의 실제 구현에 대해 확인할 수 있습니다.
 
소비자 주도 계약의 원리
CDC 테스트의 근본적인 원리는 통합 지점 정의의 책임 전환입니다. 제공자가 API를 결정하는 대신(제공자가 API를 예상치 못하게 변경할 때 소비자가 실패할 수 있음), 소비자는 제공자로부터 필요한 것과 기대하는 것을 명시적으로 설명합니다. 이 정의가 계약이 됩니다.
Pact.io는 소비자가 다음을 수행할 수 있도록 함으로써 이 과정을 촉진합니다.
- 기대 정의: 소비자 서비스는 제공자에게 보낼 정확한 HTTP 요청과 받을 것으로 예상되는 정확한 HTTP 응답을 지정하는 "Pact 테스트"를 작성합니다. 여기에는 요청 메서드, 경로, 헤더, 본문 및 예상되는 응답 상태, 헤더 및 본문이 포함됩니다.
 - Pact 파일 생성: 소비자 테스트 실행 중에 Pact.io는 이러한 정의된 기대를 "Pact 파일"(JSON 문서)에 기록합니다. 이 파일이 계약을 나타냅니다.
 - Pact 파일 게시: 그런 다음 소비자는 이 Pact 파일을 "Pact Broker"(계약의 중앙 저장소)에 게시하거나 제공자 팀과 직접 공유합니다.
 - 제공자 검증: 그런 다음 제공자 서비스는 이 Pact 파일을 사용하여 자체 API 구현을 검증합니다. Pact.io는 계약에 정의된 요청을 실제 제공자 서비스에서 재생하는 "제공자 검증 테스트"를 실행합니다. 제공자의 응답이 Pact 파일의 기대와 일치하면 계약이 이행된 것입니다. 불일치가 있으면 제공자 검증이 실패하며, 이는 치명적인 변경이 발생했음을 나타냅니다.
 
실용적인 예: 주문 서비스 및 제품 서비스
주문을 처리하기 위해 제품 서비스에서 제품 세부 정보를 가져와야 하는 주문 서비스와 같은 일반적인 시나리오를 살펴보겠습니다.
소비자 측(주문 서비스)
주문 서비스는 ID별로 제품을 가져와야 합니다. 다음은 Pact JVM 라이브러리를 사용하여 Java Spring Boot를 이용한 단순화된 예입니다.
// OrderServiceConsumerPactTest.java import au.com.dius.pact.consumer.MockServer; import au.com.dius.pact.consumer.dsl.PactDslWith

