9강. REST 이후: Async API와 Event 계약

🤔 Question

👉 REST API 계약을 잘 설계했습니다.
👉 MSA 팀 간 외교 문서도 안정적으로 운영됩니다.

그런데 어느 날 이런 요구가 나옵니다.

"실시간으로 주문 상태를 전파하고 싶어요."
"결제 완료 이벤트를 여러 서비스가 구독하게 해주세요."

이 순간 우리는 깨닫습니다.

👉 REST 이후의 세계가 시작되었다.

 

🎯 REST의 한계 지점

REST는 요청-응답 모델입니다.

✔ 호출자가 있어야 동작
✔ 즉시 응답이 필요
✔ 동기적 의존성 발생

하지만 현대 시스템은 다릅니다.

👉 "어떤 일이 발생했는지"를 흘려보내고 싶다
👉 "누가 듣고 있는지 몰라도 된다"

이 요구가 REST를 넘어
Async API와 Event 기반 구조로 이어집니다.

 

🎯 이벤트도 결국 계약이다

이벤트를 도입하면 종종 이런 착각이 발생합니다.

"이벤트는 그냥 JSON 던지면 되잖아요?"

하지만 이벤트 소비자는
REST API 소비자와 똑같습니다.

👉 이벤트 메시지 구조 역시 계약입니다.

계약 없는 이벤트는
예측 불가능한 장애를 부릅니다.

 

🎯 Event Contract 예시

{
  "eventType": "OrderCompleted",
  "eventVersion": 1,
  "occurredAt": "2026-01-17T12:30:22Z",
  "payload": {
    "orderId": 1001,
    "totalAmount": 15000,
    "userId": 77
  }
}

✔ 이벤트 타입 명시
✔ 버전 명시
✔ 발생 시각 명시
✔ 실제 데이터(payload) 분리

👉 이 구조 자체가 팀 간 이벤트 계약입니다.

 

🎯 Async API는 새로운 외교 문서

REST에서 API 문서가 외교 문서였다면,
이벤트 세계에서는 Async API 문서가 그 역할을 합니다.

✔ 어떤 이벤트가 발행되는가?
✔ payload 스키마는 무엇인가?
✔ 소비자는 어떤 보장을 받는가?

👉 Async API 스키마가 새로운 계약서입니다.

 

🎯 이벤트 진화도 하위 호환성이 핵심

이벤트 스키마도 REST와 동일합니다.

✔ 기존 필드 삭제 금지
✔ 의미 변경 금지
✔ 새 필드는 선택적으로 추가

👉 계약은 확장만 가능하고 변경은 금지입니다.

지키지 않으면
구독 중인 서비스가 조용히 망가집니다.

 

🎯 Consumer-Driven Event Contract

이벤트 세계에서도 답은 같습니다.

👉 소비자가 기대하는 이벤트 계약을 테스트로 고정

발행자가 이벤트를 변경하면
계약 테스트가 깨지고 배포가 차단됩니다.

REST에서 했던 계약 기반 개발은
Async 세계에서도 그대로 이어집니다.

 

🎯 REST 이후에도 변하지 않는 것

기술은 변합니다.
REST → GraphQL → Async → Event Streaming

하지만 변하지 않는 것이 있습니다.

👉 API는 결국 계약이다
👉 이벤트도 결국 계약이다
👉 신뢰는 계약에서 나온다

프로토콜이 아니라
약속이 시스템을 지탱합니다.

 

☔ 시리즈 최종 정리

👉 REST는 기술이 아니라 계약이다.
👉 MSA에서 API는 팀 간 외교 문서다.
👉 계약은 문서가 아니라 스키마로 고정해야 한다.
👉 계약 검증 없는 변경은 배포 사고로 이어진다.
👉 장애 상황에서도 계약은 지켜져야 한다.
👉 REST 이후 Async 세계에서도 계약은 계속된다.

결국 시스템의 품질은 계약의 품질이다.

 

 

If I was of any help to you, please buy me coffee 😿😢😥

If you have any questions, please leave them in the comments

Buy me a coffee

▶ Youtube Sub

🧭 References

[1] reference : https://doctorson0309.tistory.com/

[2] Ads : https://apps.apple.com/us/app/beluga-classic-film-filters/id6744041061