Antigravity Agent
27 lines
3.8 KiB
Markdown
27 lines
3.8 KiB
Markdown
# [[소비자 주도 계약 테스트 (Consumer-Driven Contract Tests, CDC)]]
|
|
|
|
## 📌 Brief Summary
|
|
소비자 주도 계약 테스트(CDC)는 마이크로서비스 환경에서 인터페이스를 소비하는 측(Consumer)이 요구사항을 바탕으로 테스트를 작성하여 제공자(Provider)의 API 구현을 주도하는 자동화된 테스트 기법이다 [1]. 소비자가 작성한 테스트 명세를 제공자가 지속적으로 실행함으로써, 인터페이스의 변경으로 인한 시스템의 오류를 조기에 발견할 수 있다 [2]. 이를 통해 조직 내 여러 팀이 런타임 통신 계약을 유지하면서도 자율적이고 빠르게 소프트웨어를 개발할 수 있도록 돕는다 [3, 4].
|
|
|
|
## 📖 Core Content
|
|
* **CDC 테스트의 기본 워크플로우:**
|
|
1. 소비하는 팀(Consumer)은 자신이 인터페이스로부터 필요로 하는 모든 데이터와 기대사항을 담아 자동화된 테스트를 작성한다 [1, 2].
|
|
2. 작성된 테스트(또는 Pact 파일과 같은 계약 명세)를 제공자 팀이 가져갈 수 있도록 배포(publish)한다 [1, 2, 5].
|
|
3. 제공하는 팀(Provider)은 빌드 파이프라인에서 이 CDC 테스트를 지속적으로 실행하여 API를 개발한다. 모든 테스트가 통과하면 소비자가 요구하는 모든 사항을 구현했음을 확신할 수 있다 [1, 2].
|
|
4. 만약 제공자가 인터페이스를 변경하여 CDC 테스트가 실패하게 되면, 두 팀이 즉시 소통하여 API 변경에 대해 논의하고 해결책을 찾는다 [2, 3].
|
|
|
|
* **도구와 구현 방식:**
|
|
* CDC 테스트의 가장 단순한 형태는 API에 요청을 보내고 필요한 모든 것이 응답에 포함되어 있는지 단언(assert)하는 것이다 [6].
|
|
* 현대적이고 대중적인 도구로는 **Pact**가 있다. 소비자는 Pact를 사용하여 기대사항이 담긴 JSON 형태의 계약 파일(pact file)을 생성하고, 제공자는 이 파일을 읽어들여 자신의 서비스가 기대 상태에 맞게 응답하는지 검증한다 [5-7].
|
|
|
|
* **아키텍처 및 조직적 이점:**
|
|
* **불필요한 구현 방지:** 제공하는 팀은 소비자가 작성한 테스트를 통과하는 데 필요한 기능만 정확히 구현하면 되므로, YAGNI(You Aren't Gonna Need It) 원칙을 준수하고 시스템을 단순하게 유지할 수 있다 [2].
|
|
* **독립성과 소통 강화:** 방대하고 무거운 인터페이스 문서를 주고받는 대신, 실행 가능한 테스트를 통해 명확한 소통을 유도한다. 이는 마이크로서비스를 구축하는 자율적인 팀들이 다른 서비스를 망가뜨릴 걱정 없이 빠르게 개발할 수 있게 하는 핵심(Game changer)이 된다 [4, 8].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
* **공개 API(Public API) 적용의 한계:** CDC 테스트는 조직 내부의 마이크로서비스 환경에서 가장 유용하다. 불특정 다수가 사용하는 공개 API의 경우, 제공자 측에서 모든 소비자의 요구사항을 반영한 테스트를 일일이 구동하고 맞춰주는 것이 불가능하므로 이 접근 방식을 적용하기 어렵다 [9].
|
|
* **테스트 공유를 위한 인프라 관리:** 소비자가 생성한 계약 파일(Pact 파일 등)을 제공자에게 전달하려면 추가적인 관리 방법이 필요하다. 버전 관리 시스템에 직접 체크인하거나, Amazon S3, 아티팩트 저장소, 또는 전용 Pact Broker와 같은 인프라를 구축하고 관리하는 수고가 발생한다 [10].
|
|
* **팀 간 소통의 필수성:** 자동화된 테스트가 소통을 돕는 도구이긴 하지만, 테스트가 실패했을 때(예: 불가피한 API 변경 시) 결국 관련된 두 팀이 직접 만나 향후 방향성을 논의하고 조율하는 과정이 필수적으로 동반되어야 한다 [3].
|
|
|
|
---
|
|
*Last updated: 2026-05-03* |