104 lines
8.6 KiB
Markdown
104 lines
8.6 KiB
Markdown
---
|
|
title: Spring Cloud Contract — 공식 프로젝트 페이지
|
|
source_type: official-doc
|
|
url: https://spring.io/projects/spring-cloud-contract
|
|
archive_url:
|
|
status: raw
|
|
confidence: high
|
|
related_branches: [feature-contract-verification-test-suite]
|
|
related_projects: [ca-skeleton]
|
|
tags: [contract-test, cdc, spring, stub-runner, verification, ca-skeleton, official-doc]
|
|
created: 2026-05-25
|
|
last_reviewed: 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 조사로 수집한 경우:
|
|
|
|
- [[raw/project-notes/ca-skeleton-operational-contract]] — Test Contract (§12) 의 contract level 대안 평가
|
|
|
|
## 컨텍스트 / 왜 저장했는지
|
|
|
|
`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 지원 — 본 페이지 발췌에 없는 외부 정보).
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 official-doc / 자료:
|
|
- [[raw/official-docs/verification-pact-cdc-official]] — CDC 의 다른 도구 (Pact)
|
|
- [[raw/official-docs/verification-approvaltests-snapshot-official]] — ca-tmpl 채택안 (snapshot)
|
|
- [[raw/official-docs/test-taxonomy-practical-pyramid-fowler]] — CDC workflow 일반론
|
|
- [[raw/official-docs/test-taxonomy-testcontainers-official]] — integration level 와의 역할 분리
|
|
- 인용하는 branch:
|
|
- [[raw/branch-notes/feature-contract-verification-test-suite]]
|
|
- canonical contract 섹션:
|
|
- [[raw/project-notes/ca-skeleton-operational-contract]] (Test Contract §12)
|
|
- 대안 그룹: **Group G-G — Skeleton Governance** (verification)
|
|
- 본 source 의 위치: 대안 3 — Spring Cloud Contract (stub-runner 대안)
|
|
- 인용하는 wiki: (미작성)
|