8강. 장애 상황에서 계약을 지키는 복원력 설계

🤔 Question

👉 이런 상황을 겪어본 적 있나요?

"결제 서비스가 잠깐 죽었는데 전체 주문이 멈췄어요."
"외부 인증 서버 장애 때문에 로그인 자체가 안 돼요."
"장애는 복구됐는데 고객 신뢰가 떨어졌어요."

MSA 환경에서 장애는 피할 수 없습니다.
하지만 더 중요한 질문은 이것입니다.

👉 장애 상황에서도 API 계약을 지킬 수 있는가?

 

🎯 장애가 계약을 깨뜨리는 순간

정상 상황에서 API 계약은 잘 지켜집니다.

하지만 장애가 발생하면
갑자기 이런 응답이 나타납니다.

  500 Internal Server Error

JSON을 기대하던 소비자는
HTML을 받고 파싱에 실패합니다.

👉 이 순간 계약은 완전히 깨집니다.

장애 자체보다 위험한 것은
계약이 예측 불가능해지는 것입니다.

 

🎯 좋은 복원력 설계의 목표

복원력(Resilience)은
"장애가 나지 않게 하는 것"이 아닙니다.

👉 장애가 나도 계약은 유지하는 것입니다.

✔ 항상 같은 응답 형식 유지
✔ 예외 상황도 스키마 내에서 표현
✔ 타임아웃 시에도 예측 가능한 에러 반환

이것이 계약 중심 복원력입니다.

 

🎯 Fallback은 계약의 일부다

외부 서비스가 실패했을 때
무작정 500을 던지는 것은 쉬운 선택입니다.

하지만 계약 관점에서 더 나은 선택은 이것입니다.

{
  "success": false,
  "errorCode": "PAYMENT_TIMEOUT",
  "message": "결제 시스템이 일시적으로 지연되고 있습니다"
}

👉 장애 상황도 정상 응답 스키마 안에 포함시키는 것.

소비자는
"실패했지만 형식은 항상 같다"
라는 신뢰를 갖게 됩니다.

 

🎯 Circuit Breaker는 계약 보호 장치

Circuit Breaker는
단순한 장애 방지 기술이 아닙니다.

👉 계약을 지키기 위한 방어선입니다.

✔ 일정 실패율 이상 시 호출 차단
✔ 대체 응답(Fallback) 즉시 반환
✔ 호출자는 항상 예측 가능한 계약을 받음

이로써 장애 전파를 막고
계약 일관성을 유지합니다.

 

🎯 Timeout도 계약의 일부

타임아웃이 없는 호출은
장애를 기다리는 구조입니다.

✔ 언제까지 기다릴 것인가?
✔ 타임아웃 시 어떤 응답을 줄 것인가?

👉 이 또한 계약에 명시되어야 합니다.

"3초 내 응답 없으면 TIMEOUT 에러 반환"
이 자체가 팀 간 합의된 계약입니다.

 

🎯 장애를 숨기지 말고 구조화하라

장애를 숨기려 하면
계약이 깨진 응답이 튀어나옵니다.

하지만 장애를
👉 계약 안에 구조화하면
소비자는 항상 동일한 규칙으로 처리합니다.

복원력 설계는
에러 설계 + 계약 설계의 결합입니다.

 

☔ 정리

👉 장애는 막을 수 없지만 계약 붕괴는 막을 수 있습니다.
👉 복원력 설계의 목표는 계약 일관성 유지입니다.
👉 Fallback, Circuit Breaker, Timeout은 계약 보호 장치입니다.

진짜 안정적인 시스템은
장애 속에서도 약속을 지키는 시스템입니다.

 

 

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