주문 화면에서 배송사 API가 답을 주지 않는다. 우리 서버는 기다리고, 사용자는 버튼을 다시 누르고, 서버는 같은 외부 호출을 여러 번 보낸다. 잠깐의 외부 장애가 우리 서비스의 연결과 작업 스레드를 잡아먹어 다른 기능까지 느려진다. 이때 필요한 것은 ‘재시도 횟수 3’이라는 숫자 하나가 아니다. 어디까지 기다리고, 언제 다시 시도하며, 언제 멈추고, 고객에게 무엇을 보여 줄지를 정한 장애 경계다.
Microsoft의 일시 장애 대응 가이드는 제한된 재시도와 전체 재시도 예산을 강조한다. 일시적으로 회복할 오류와 잘못된 요청처럼 반복해도 성공하지 않을 오류를 구분하는 일부터 시작해야 한다.
먼저 외부 호출이 핵심 업무에 얼마나 필요한지 정한다
결제 승인 결과가 없으면 주문을 확정할 수 없다. 반면 배송 예상일을 못 가져왔다고 상품 조회 자체를 막을 필요는 없을 수 있다. 외부 연동마다 ‘실패 시 거래를 중단’, ‘대기 상태로 두고 나중에 완료’, ‘최근 값을 명시하고 임시 제공’ 중 무엇이 가능한지 정한다. 값이 오래되면 위험한 정보에 캐시를 무조건 쓰면 안 된다. 대체 응답은 제품 정책과 사용자 안내가 함께 있어야 한다.
전체 요청의 마감시간도 필요하다. 고객 화면이 5초만 기다릴 수 있는데 외부 호출을 5초씩 세 번 시도하는 설정은 앞뒤가 맞지 않는다. DNS 연결, TLS 연결, 응답 읽기처럼 여러 단계의 타임아웃을 모두 고려하고, 남은 시간을 하위 호출에 전달한다. 타임아웃은 장애를 없애지 않고 우리 서비스가 외부 문제에 묶이는 시간을 제한한다.
타임아웃 뒤의 결과는 ‘실패’가 아닐 수도 있다
중요한 함정이 있다. 결제사에 요청을 보냈고 응답만 잃었을 수 있다. 이때 새 요청으로 즉시 다시 결제하면 중복 실행이 된다. 쓰기 요청은 거래 ID나 멱등 키를 안정적으로 부여하고, 제공자가 같은 키의 재요청을 어떻게 처리하는지 확인한다. 이미 처리됐는지 조회할 수 있다면 상태를 먼저 확인한다. 제공자가 중복 안전성을 지원하지 않으면 자동 재시도 대신 보류·수동 확인이 더 안전할 수 있다.
읽기 요청이라도 무조건 반복하지 않는다. 모든 인스턴스가 같은 간격으로 재시도하면 회복 중인 외부 서비스를 한꺼번에 다시 압박한다. 백오프로 간격을 늘리고 지터로 시점을 흩뜨린다. AWS Builders' Library의 타임아웃·재시도 안내는 이런 동시 재시도 문제와 지터의 필요성을 설명한다. 요청 하나의 제한뿐 아니라 서비스 전체가 외부 서비스에 보내는 추가 시도량도 제한해야 한다.
지속 장애에는 회로 차단이 필요할 수 있다
외부 서비스가 몇 분째 대부분 실패한다면 매 사용자 요청마다 오래 기다리는 전략은 더 이상 합리적이지 않다. 회로 차단기는 최근 실패를 보고 일시적으로 새 호출을 막는다. 일정 시간이 지난 뒤 소량의 시험 요청을 보내 회복을 확인하고, 성공하면 천천히 정상 흐름으로 돌아간다. Microsoft의 Circuit Breaker 패턴도 재시도가 일시 장애 회복을 기대하는 것과, 회로 차단이 지속 실패의 확산을 막는 것은 목적이 다르다고 구분한다.
회로 차단은 모든 상황의 정답이 아니다. 요청량이 적거나 메시지 큐가 이미 재시도와 격리를 담당하면 불필요한 복잡성을 더할 수 있다. 반대로 외부 호출이 동기식 사용자 요청을 오래 붙잡고 장애가 전파된다면 효과가 크다. 차단 범위도 제공자 전체, API 종류, 지역별로 달리할 수 있다. 한 기능의 장애 때문에 관련 없는 기능까지 막지 않도록 경계를 좁힌다.
고객에게는 ‘안 됨’보다 현재 상태를 알려 준다
결과를 모르는 작업을 실패로 단정하지 말고 ‘확인 중’ 상태를 두는 편이 안전할 수 있다. 고객이 새 주문을 반복 생성하지 않게 작업 ID와 현재 상태를 보여 주고, 나중에 결과를 조회하거나 담당자에게 문의할 경로를 제공한다. 배송 조회가 지연된다면 마지막으로 확인된 시각을 표시한다. 이때 오래된 값을 최신 값처럼 보여 주면 장애보다 큰 신뢰 문제를 만든다.
운영 지표에는 외부 호출 성공률뿐 아니라 타임아웃, 재시도 횟수, 회로가 열린 시간, 대기 상태로 남은 업무 건수, 고객이 실제로 완료한 작업을 넣는다. 재시도가 최종 성공을 높였는지, 오히려 응답시간과 외부 부하를 키웠는지도 본다. 장애 연습에서는 제공자를 느리게 만들거나 응답을 끊은 상황을 넣어 핵심 기능이 살아 있는지 확인한다.
계약상 호출 한도도 경계에 포함한다. 제공자의 분당 요청 한도를 넘어서 생긴 제한 응답을 네트워크 일시 장애와 같은 방식으로 빠르게 재시도하면 상황이 더 나빠진다. 제공자가 재시도 가능 시점을 알려 주면 이를 존중하고, 내부에서는 고객별·업무별 우선순위를 정한다. 꼭 필요한 결제 확인과 나중에 해도 되는 통계 동기화를 같은 대기열에 넣으면 비핵심 작업이 핵심 작업의 회복을 늦출 수 있다.
설계 체크리스트
- 외부 연동별 실패 시 업무 상태를 정의했는가?
- 전체 요청 마감시간과 하위 호출 타임아웃이 맞는가?
- 쓰기 작업의 중복 안전성과 결과 조회 방법을 확인했는가?
- 일시 오류에만 제한된 백오프·지터 재시도를 하는가?
- 지속 장애가 다른 기능으로 번지지 않게 격리했는가?
- 대체 응답의 최신성·한계를 고객에게 설명하는가?
- 대기 작업과 실패 작업을 나중에 복구할 수 있는가?
외부 API는 언제든 느려지거나 멈출 수 있다. 좋은 연동은 그 사실을 숨기지 않는다. 시간, 중복, 재시도, 차단, 고객 안내를 하나의 경계로 설계할 때 외부 장애가 우리 서비스 전체의 장애로 번지는 일을 줄일 수 있다.
