Contract Test 경계 선택 가이드

Contract test는 통합 드리프트를 일찍 잡는 데 강력하지만, 실전에서는 “정확히 어디까지를 계약으로 볼 것인가”가 가장 어려운 질문입니다.

계약은 모든 세부사항이 아니다

계약에 너무 많은 것을 넣으면 테스트가 brittle해지고 비싸집니다. 너무 적게 넣으면 안심만 주고 실제 위험은 못 잡습니다.

보통 좋은 contract test는 다음에 집중합니다.

• request/response shape
• 필수 필드와 불변 조건
• 상태코드와 에러 의미
• 버전 호환 기대치

목표는 구현 복제가 아니라 협업 보호입니다.

팀 간 결합도를 기준으로 경계를 정하자

Contract test는 특히 다음 상황에서 효과적입니다.

• 한 팀이 다른 팀의 API에 의존할 때
• 변경 빈도가 높을 때
• end-to-end 피드백이 너무 느릴 때

팀 간 의존성이 강할수록 계약 경계의 가치도 커집니다.

E2E의 역할까지 가져오면 안 된다

Contract test가 증명하려고 하면 안 되는 것들도 있습니다.

• UI 전체 사용자 여정
• 환경 전체 배포 wiring
• 모든 persistence 부작용

그것들이 중요하지 않아서가 아니라, 다른 테스트 계층이 맡아야 하기 때문입니다.

강한 경계에는 소유권이 있다

• 누가 계약을 발행하는가
• 누가 호환성을 검증하는가
• 어떤 변경이 버전 증가를 요구하는가

Contract test는 assertion 묶음을 늘리는 것보다, 팀 간 협업을 더 명확하게 만들 때 가장 큰 효과를 냅니다.

Continue Reading

다음으로 읽기 좋은 글

🧪 Test

플레이키 테스트 신호 예산 관리

불안정한 테스트를 단순 재시도로 덮지 않고 신뢰도, 소유권, 격리 기준으로 관리하는 방법을 정리합니다.

🧪 Test

릴리스 후보 테스트 컷라인 설계

모든 테스트를 다 돌리는 것과 안전하게 배포하는 것은 다릅니다. 릴리스 후보에서 어떤 테스트를 통과 기준으로 삼아야 할지 정리합니다.

📱 Mobile

모바일 Crash Budget 운영법

모바일 안정성은 단순히 크래시를 줄이는 것이 아니라, 어느 수준까지 허용하고 언제 출하를 멈출지 결정하는 운영 문제입니다.

🤖 AI / LLMOps

AI 평가 루브릭 실전 설계

프로덕션 AI 기능을 위해 품질 기준, 실패 유형, 릴리스 게이트를 어떻게 정의할지 정리한 실전 가이드입니다.