[MSA] 계약 테스트와 통합 테스트 전략 비교

마이크로서비스 아키텍처(MSA)는 서비스 간에 명확하게 분리된 구조이지만, 이들이 서로 통신하지 않는다면 아무 의미가 없다.
즉, 독립적으로 개발하더라도 서비스 간의 연동(REST API, 메시지, 이벤트 등)은 반드시 정확해야 한다.
문제는 각각 독립적으로 개발되기 때문에 한쪽 변경으로 인해 다른 서비스가 깨지는 문제가 자주 발생한다.
이러한 문제를 방지하기 위해 사용되는 테스트 기법이 바로 계약 테스트(Contract Test)이다.

✅ 통합 테스트란?

통합 테스트(Integration Test)는 두 개 이상의 컴포넌트(또는 서비스)가 정상적으로 연동되는지를 실제로 호출하여 검증하는 테스트이다.
예를 들어 A 서비스가 B 서비스의 API를 호출했을 때, 응답 값이 기대한 형태인지 확인하는 식이다.

🔍 특징

• 실제 HTTP 통신 또는 DB 연결이 발생한다.
• 외부 시스템이 준비되어 있어야 테스트 가능하다.
• 환경 의존성이 크기 때문에 속도가 느리고 안정성도 낮은 편이다.

✅ 장점

• 실제 환경과 거의 동일한 조건에서 테스트할 수 있다.
• 통합 오류나 배포 간 문제를 사전에 파악할 수 있다.

❌ 단점

• 테스트 유지보수가 어렵다.
• 외부 의존성 때문에 테스트가 자주 깨진다.
• 실행 시간이 오래 걸린다.

반응형

📑 계약 테스트란?

계약 테스트(Contract Test)는 서비스 간의 계약(API 요청/응답 형식, 메시지 포맷 등)이 지켜지는지를 테스트하는 방식이다.
소비자(Consumer)와 제공자(Provider)가 사전에 약속한 스펙을 기준으로 독립적으로 테스트할 수 있다.
대표적인 도구로는 Spring Cloud Contract, Pact 등이 있다.

🧩 작동 방식 요약

1. 소비자 서비스가 필요한 API 요청/응답 형식을 정의한다.
2. 그 정의를 계약 파일(JSON 또는 DSL)로 만든다.
3. 제공자 서비스는 이 계약을 기준으로 응답을 생성하고 테스트를 수행한다.

✅ 장점

• 양쪽 서비스를 독립적으로 테스트할 수 있다.
• 실제 API 호출 없이 빠르고 안정적인 테스트가 가능하다.
• CI 파이프라인에 통합하기 적합하다.
• 변경된 API가 다른 서비스에 영향을 주지 않는지 조기에 검출할 수 있다.

❌ 단점

• 초기 설정과 계약 정의에 시간과 노력이 필요하다.
• 계약 파일이 변경되면 테스트 양쪽 모두를 조정해야 한다.
• API의 의미적 오류(비즈니스 로직 차이)는 잡지 못한다.

🔍 통합 테스트 vs 계약 테스트 비교

항목	통합 테스트	계약 테스트
목적	실제 시스템 간 통신 검증	요청/응답 형식의 약속 검증
실행 환경	외부 시스템 필요	독립 실행 가능
테스트 속도	느림	빠름
신뢰성	환경 영향 큼	안정적
적용 난이도	간단하지만 유지보수 어려움	초기 설정 복잡하나 효율적
대표 도구	TestRestTemplate, RestAssured	Spring Cloud Contract, Pact

반응형

🛠️ Spring Cloud Contract 예시

1. 계약 정의 (Groovy DSL)

Contract.make {
    request {
        method 'GET'
        url '/api/users/1'
    }
    response {
        status 200
        body(
            id: 1,
            name: 'Alice'
        )
        headers {
            contentType(applicationJson())
        }
    }
}

2. 자동으로 Stub 생성

• 이 계약을 기반으로 WireMock 기반의 Stub 서버가 생성된다.
• 소비자는 실제 서비스를 호출하지 않고 이 Stub을 통해 테스트를 수행한다.

@Test
public void testUserApi() {
    given()
      .port(port)
      .when()
      .get("/api/users/1")
      .then()
      .statusCode(200)
      .body("name", equalTo("Alice"));
}

3. 제공자 측 검증

• 계약 파일을 기준으로 실제 API 응답이 스펙을 만족하는지 자동 검증된다.
• 이를 통해 API 변경 시 다른 서비스에 미치는 영향을 조기에 파악할 수 있다.

🧠 실무 적용 전략

• 간단한 연동 + 빠른 확인이 필요할 때는 통합 테스트
• 서비스 간 계약이 자주 바뀌고, 배포 주기가 빠른 환경에서는 계약 테스트
• 이상적인 전략은 두 가지 테스트를 조합해서 사용하는 것이다.
  • 계약 테스트 → API 형식 검증
  • 통합 테스트 → 실제 배포 환경 연동 검증

✅ 결론

MSA에서의 테스트는 단일 애플리케이션보다 훨씬 중요하고 복잡하다.
통합 테스트는 실제 시스템 간 연동 확인에 효과적이고, 계약 테스트는 빠르고 안정적인 검증에 유리하다.
두 테스트를 적절히 조합하면 API 스펙 오류, 연동 실패, 통신 문제를 미리 방지할 수 있으며, 서비스 간 결합도를 유지하면서도 배포 안정성을 높일 수 있다.

📌 참고한 공식 문서

• Spring Cloud Contract 공식 문서
• Pact 공식 사이트
• Testing Strategies in MSA - Martin Fowler