Files
llm-wiki/raw/official-docs/verification-spring-cloud-contract-official.md
T

8.6 KiB

title, source_type, url, archive_url, status, confidence, related_branches, related_projects, tags, created, last_reviewed
title source_type url archive_url status confidence related_branches related_projects tags created last_reviewed
Spring Cloud Contract — 공식 프로젝트 페이지 official-doc https://spring.io/projects/spring-cloud-contract raw high
feature-contract-verification-test-suite
ca-skeleton
contract-test
cdc
spring
stub-runner
verification
ca-skeleton
official-doc
2026-05-25 2026-05-27

Spring Cloud Contract — 공식 프로젝트 페이지

Layer: raw/official-docs/ — Spring 공식 프로젝트 페이지 발췌. ca-tmpl 결정 (snapshot + drift) 대안인 Spring Cloud Contract (stub-runner / CDC umbrella) 평가용.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-contract-verification-test-suite "Spring Cloud Contract 도 Pact 와 같은 사유로 out-of-scope" 결정의 평가 근거 — Spring 생태계 안의 CDC 대안 검토

특정 branch 없이 foundational 조사로 수집한 경우:

컨텍스트 / 왜 저장했는지

feature-contract-verification-test-suite 의 ca-tmpl 이 Pact 를 명시적으로 out-of-scope 로 두었기 때문에, Spring 생태계 안의 CDC 대안인 Spring Cloud Contract 도 같은 사유로 out-of-scope 인지 확인이 필요했다.

출처 / Source

  • 원본 URL: https://spring.io/projects/spring-cloud-contract
  • 아카이브 URL: (미수집)
  • 저자 / 조직: Spring (VMware / Broadcom)
  • 발행일: 지속적으로 갱신 (footer: "Copyright © 2005 - 2026 Broadcom")
  • 마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim)

[§Project overview] "Spring Cloud Contract is an umbrella project holding solutions that help users in successfully implementing the Consumer Driven Contracts approach."

[§Acceptance tests] "Acceptance tests (by default in JUnit or Spock) used to verify if server-side implementation of the API is compliant with the contract (server tests). Full test is generated by Spring Cloud Contract Verifier."

[§Stub Runner] "You can use Spring Cloud Contract Stub Runner in the integration tests to get a running WireMock instance or messaging route that simulates the actual service."

[§Contract DSL] "It is shipped with Contract Definition Language (DSL) written in Groovy or YAML."

[§Stub-implementation sync] "ensure that HTTP / Messaging stubs (used when developing the client) are doing exactly what actual server-side implementation will do"

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
SCC-OFFICIAL-C1 Spring Cloud Contract 는 CDC 접근법 구현을 돕는 umbrella project (여러 solution 의 집합) [§Project overview] "Spring Cloud Contract is an umbrella project holding solutions that help users in successfully implementing the Consumer Driven Contracts approach." official-vendor-doc Spring 생태계의 CDC 도구 선택 Spring Cloud Contract 가 CDC 만 지원한다는 뜻은 아님 — provider-side test 도 포함
SCC-OFFICIAL-C2 server-side 구현이 contract 와 compliant 한지 확인하는 acceptance test (JUnit/Spock) 가 Spring Cloud Contract Verifier 에 의해 자동 생성됨 [§Acceptance tests] "Acceptance tests (by default in JUnit or Spock) used to verify if server-side implementation of the API is compliant with the contract (server tests). Full test is generated by Spring Cloud Contract Verifier." official-vendor-doc provider-side compliance test 자동화 TestNG 등 다른 framework 도 자동 지원한다는 뜻은 아님 — "by default" 명시
SCC-OFFICIAL-C3 Stub Runner 를 integration test 에서 사용하면 WireMock instance 또는 messaging route 를 받아 actual service 를 시뮬레이션 [§Stub Runner] "You can use Spring Cloud Contract Stub Runner in the integration tests to get a running WireMock instance or messaging route that simulates the actual service." official-vendor-doc consumer-side test 에서 provider stub 사용 Testcontainers 같은 real-container 와의 결합 방식은 본 인용에 없음
SCC-OFFICIAL-C4 Contract 는 Groovy 또는 YAML 의 Contract Definition Language (DSL) 로 작성 [§Contract DSL] "It is shipped with Contract Definition Language (DSL) written in Groovy or YAML." official-vendor-doc Contract 작성 형식 Groovy/YAML 외 다른 형식 (예: JSON, Kotlin DSL) 의 지원 여부는 본 인용에 없음
SCC-OFFICIAL-C5 HTTP/Messaging stub (client 개발 시 사용) 이 실제 server-side 구현과 정확히 동일하게 동작하도록 보장 [§Stub-implementation sync] "ensure that HTTP / Messaging stubs (used when developing the client) are doing exactly what actual server-side implementation will do" official-vendor-doc stub-implementation 동기화의 핵심 가치 제안 "exactly" 가 100% 자동 보장된다는 뜻은 아님 — server test 통과가 전제 (SCC-OFFICIAL-C2 와 결합)

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • SCC-OFFICIAL-C1: Spring Cloud Contract 가 CDC 구현 umbrella project 라는 self-definition
    • SCC-OFFICIAL-C2: server-side compliance test 자동 생성 (JUnit/Spock)
    • SCC-OFFICIAL-C3: Stub Runner 의 consumer-side 통합 메커니즘 (WireMock/messaging)
    • SCC-OFFICIAL-C4: Groovy/YAML DSL 사용
    • SCC-OFFICIAL-C5: stub-implementation 동기화의 가치 제안
  • 이 자료가 증명하지 않는 것:
    • "Pact 와 동일한 사유로 out-of-scope" — 본 자료는 ca-tmpl 의 적용 판단을 말하지 않음 (ca-tmpl 별도 분석)
    • "외부 consumer 가 있을 때만 가치 있음" — 본 자료는 single-team 시나리오의 부적합성을 명시하지 않음 (해석)
    • Pact 와의 호환성 (Pact spec 지원) — 본 페이지 발췌에 없음 (다른 페이지)
    • Testcontainers 와의 중복 여부 — 본 자료에 없는 ca-tmpl 의 별도 판단
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl 의 "skeleton 단계 monolithic / single-consumer 가정" 이 Spring Cloud Contract 의 권장 사용 시나리오와 mismatch 한지 — 본 자료는 사용 권장 시나리오의 정량 임계점 명시 안 함
    • Stub Runner 가 ca-tmpl 의 "integration test 는 Testcontainers 로 producer 직접 띄움" 정책과 중복인지 — 본 자료는 중복성 직접 말하지 않음 (해석)
    • 멀티 팀/멀티 서비스 확장 시 도입 임계점 (Pact vs Spring Cloud Contract 선택) — 별도 페이지 / 외부 비교 자료 필요

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

  • Pact 와 결이 같음: 외부 consumer 가 있을 때 가치가 큼 (SCC-OFFICIAL-C1 의 CDC 정체성 + SCC-OFFICIAL-C3 의 Stub Runner 가 consumer 측 도구). skeleton 단계의 monolithic / single-consumer 가정과 mismatch — 본 자료가 직접 말하지 않는 해석.
  • Stub Runner 는 consumer-side 에서 producer stub 을 쓸 수 있게 해주는데 (SCC-OFFICIAL-C3), 이는 skeleton 의 integration test 가 producer 본체를 직접 띄움 (Testcontainers) 정책과 중복 가능성 — ca-tmpl 의 별도 판단.
  • 따라서 ca-tmpl 결정의 "JSON snapshot + OpenAPI drift" 는 single-team skeleton 맥락에서 합당 — 본 자료가 직접 결정을 지지하지 않음, 같은 사유 (multi-team CDC 도구) 라는 카테고리화에 기반한 해석.
  • 멀티 팀/멀티 서비스로 확장될 때 Spring Cloud Contract 또는 Pact 중 선택 (둘은 호환 가능, Pact spec 지원 — 본 페이지 발췌에 없는 외부 정보).