95% 실패율 감소를 이끈 Timeout·Retry·Fallback 실패 처리 체계와 메서드 데코레이터를 활용한 Global Exception Handling

 

외부 Open API와 통신하는 서비스에서 “실패”는 피할 수 없습니다. 문제는 실패가 발생했을 때, 시스템이 그 실패를 어떻게 다루느냐입니다.

토스 Runner's High 첫번째 세션이 듣고 그 다음날 12월 17일, 오픈마켓 외부 수집처인 SSG에 장애가 발생했습니다. SSG 와 관련된 모든 사내 기능이 마비 됐고, 에러 로그는 무수히 쌓여 팀 에러 메신저 방에 알럿이 왔습니다.

 

2025.12.17 SSG Open API 리소스 서버 장애 발생

 

 

장애 자체는 외부 사정이었지만, 문제는 “외부 장애” 그 자체가 아니라, 장애 상황에서 우리 시스템이 실패를 다루는 방식이었습니다.

 

이번 글은 그때의 장애를 계기로, HTTP Client timeout을 재설정하고, 실패 시 retry 구조와 backoff/jitter 정책을 도입했으며, 외부 장애가 의심될 때 시스템이 자동으로 기능을 차단하는 fallback(서킷 브레이커) 프로세스를 만든 경험을 정리한 글입니다. 

 

 

더불어, 예외 처리 누수로 인해 사용자 화면에 에러 문구가 그대로 노출되거나 이력이 “진행중”으로 남는 문제를 해결하기 위해, TypeScript 메서드 데코레이터를 사용해 진입점에 전역 예외 처리를 걸고(Global Exception Handler), 예외 정책을 한 곳으로 모으는 구조로 리팩토링한 내용까지 함께 담았습니다.

 

 

이번 작업의 핵심은 단순히 “실패 처리 개선”이 아닙니다. 사용자 경험을 저해하던 근본 원인이 스크래핑 모듈 내부의 ‘예외 처리 불안정성’에 있음을 정확히 짚어내고, 에러 처리 구조를 일관된 정책 기반으로 재설계함으로써 서비스 실패율을 낮추는 동시에, 장애 상황에서도 시스템이 스스로 대응할 수 있도록 자동화된 방어 체계까지 구축한 것입니다. 

 

 

즉, 이번 개선은 단기적인 장애 대응을 넘어, 동일한 문제가 재발하더라도 흔들리지 않는 구조를 미리 마련한 작업이었습니다.

 

 

 

⚠️Situation - 문제 상황 및 배경

장애는 외부에서 시작됐지만, 문제는 내부에서 증폭됐다.

 

 

“HTTP 요청 timeout 설정이 빠짐”

첫 번째 문제는 SSG 장애 발생시 로그를 파악해 보니, HTTP timeout이 아니라 Action timeout으로 터지고 있었다는 점입니다.

사내 스크래핑 모듈은 토픽을 구독해 실행되는 Action이 있고, Action은 전체 실행에 대한 타임아웃(액션 타임아웃)을 갖습니다. 정상적인 구조라면, 외부 응답이 지연되거나 끊겼을 때는 HTTP Client timeout이 먼저 발생하고 “네트워크 실패”로 분류되어야 합니다.

 

SSG 서버 장애로 인한 서비스 에러 로그

 

그런데 실제 로그는 그렇지 않았습니다. 통신이 끊긴 게 아니라 “Action 내부 로직이 오래 걸려서 실패”처럼 기록되고 있었습니다.

 

원인을 추적해보니 타 팀 작업으로 인해 모든 HTTP 기본 timeout이 액션 타임아웃과 같은 값으로 맞춰져 있었고, 쇼핑몰 전반 외부 통신 코드가 그 기본값을 그대로 적용받고 있었습니다. 결과적으로 통신 실패가 제때 끊기지 않고, 전체 작업이 늘어지다가 Action timeout으로 끝나버리는 구조가 되어 있었습니다.
실패 원인 분류가 흐려지는 순간, 후속 처리도 흐려집니다. “통신 실패에 대한 대응”과 “업무 실패에 대한 대응”은 다를 수밖에 없는데, 우리는 그 둘을 섞어버린 상태였습니다.

 

 

“간헐적인 단순 응답 오류에도 그대로 실패 처리함.”

timeout 관련해 로직을 파악하면서 확인한 또 하나의 중요한 사실은 요청 실패 시 즉시 실패 확정하고 있었고, 리트라이 구조가 잡혀 있지 않다는 점입니다. 네트워크는 언제든 흔들리고, 외부 Open API도 간헐적으로 500 대 에러나 429(Too Many Request)를 반환할 수 있습니다.

 

이런 실패는 일반적으로 “한 번 더” 시도하면 성공하는 경우가 매우 많습니다. 그런데 우리는 실패를 받는 순간 바로 실패 확정 처리를 해버렸습니다. 사용자는 필요 이상으로 실패를 경험하고, 전체적인 서비스 성공률은 떨어지는 문제를 파악했습니다.

 

 

“외부 장애 발생시에도 사용자의 요청은 계속 들어와 실패가 폭발하는 구조”

세 번째 문제는 외부 장애가 발생했을 때, 관리자가 기능을 막기 전까지 사용자는 계속 요청을 보낼 수 있었고 그 모든 요청이 실패로 돌아가면서 로그가 폭발하는 구조였다는 점입니다. 외부 서버가 죽었는데도 사용자는 그 사실을 모른 채 기능을 계속 사용합니다. 그러면 실패 요청이 계속 누적되고, 로그는 폭발적으로 쌓입니다. 

 

사용자는 “우리 서비스가 고장 났다”고 오해할 수 있고, 내부적으로는 모니터링과 운영 부담이 커집니다. 외부 서버 입장에서도 장애 상황에서 불필요한 재요청이 계속 들어오니 회복을 방해하는 방향이 될 수도 있습니다. 즉, 장애 상황에서 실패를 줄여야하는데, 오히려 잘 대처하지 못하고 방치하는 구조였습니다.

 

 

 

“예외 처리 누수로 인해 사용자 경험이 직접적으로 깨지고 있었음.”

스크래핑 모듈 내에 try/catch로 예외를 제대로 감싸지 못한 경로가 존재해, 어떤 경우에는 에러 메시지가 그대로 사용자 화면에 노출되기도 했습니다. 더 큰 문제는 “이력”이었습니다. 우리 업무 흐름은 마지막 단계에서 성공/실패 이력을 업데이트하는 토픽을 발행해 사용자에게 작업 결과를 남깁니다.

 

그런데 예외가 중간에서 throw 되고 처리되지 않으면 로직이 비정상 종료되면서, 이력 업데이트 토픽이 발행되지 못해 이력이 ‘진행중’으로 남는 케이스가 간헐적으로 발생했습니다. 사용자는 이미 실패한 작업을 “아직도 진행중인지”, “실패한 건지” 알 수 없습니다. 이건 단순 버그가 아니라 서비스 신뢰를 무너뜨리는 문제라고 생각합니다.

 

에러 메세지가 그대로 노출

 

실패된 작업인데도 "진행중" 중으로 남는 이력 문제

 

 

 

 

📜Task - 해결해야 하는 과제 및 목표

목표는 “성공률을 올리는 것”이 아니라 “실패를 통제하는 것”

 

“외부 통신과에 있어 적절한 timeout 처리”

외부 통신에서 반드시 HTTP timeout을 업무 특성에 맞게 설정해야 했습니다. 외부 서버가 장애일 때, 시스템이 오랜 시간 응답을 기다리며 리소스를 점유하는 건 운영적으로 매우 낭비입니다.

 

통신 단계에서 적절한 시간만 기다리고 끊어야 “실패가 실패로 분류”되고, 후속 조치(재시도/차단/사용자 안내)가 정교해질 수 있습니다. 또한 Action timeout 에러와 통신 timeout 에러는 발생 원인과 후속 조치가 다르므로, 서로 다르게 명확히 분리해야 했습니다.

 

 

“Retry 구조 설계”

간헐적 실패를 흡수하기 위한 리트라이 구조 설계가 필요했습니다. 단, 무작정 리트라이하면 외부에 부하를 주고 장애를 악화시킬 수 있으므로, 어떤 실패에 리트라이할지, 어떤 업무는 리트라이하면 안 되는지(보안 정책으로 IP 차단 위험이 큰 카드/은행 스크래핑), 그리고 몇 번까지 시도할지(무한 재시도 금지) 등 정책을 정의하고 도입해야 했습니다.

 

 

“Fallback 전략 도입”

먼저 다시 같은 문제가 발생했을 때 어떻게 대비할 것인가? 장애 대응에 있어 어떻게 자동화 처리를 할 수 있을 것인가에 대해 고민했습니다. 외부 특정 리소스 서버 장애 시 “다른 서버로 보내는 이원화”는 현실적으로 어렵기 때문에, 우리가 할 수 있는 Fallback은 명확했습니다. 장애가 의심되는 순간 시스템이 자동으로 기능을 차단해 더 많은 사용자가 실패를 경험하기 전에 요청 자체를 막아야 했습니다.

 

이건 단순 편의가 아니라, 장애 상황에서 내부/외부 리소스를 보호하는 운영 전략입니다. 특히 새벽에 스케줄이 돌며 자동으로 서비스가 동작 할 때 외부 서버 점검과 겹쳐 연속 실패가 발생하는 경우, 사람이 알아채고 막기 전에 시스템이 먼저 차단해주는 게 훨씬 안전합니다.

 

 

“예외 처리 누수를 해결하기 위한 전역적인 에러 처리”

예외 처리 누수를 해결하기 위한 전역적인 에러 처리(글로벌 익셉션 핸들러)가 필요했습니다. 사용자에게 에러 원문이 노출되는 문제를 막는 것은 기본이고, 더 중요한 건 “어떤 예외가 발생하더라도 이력 업데이트/실패 확정/표준 메시지 응답이 보장되는 구조”를 만드는 것입니다. 예외 처리 정책이 코드 곳곳에 흩어져 있으면, 언젠가 반드시 누수가 생깁니다. 그래서 예외 처리 자체를 하나의 관심사로 분리해, 진입점에서 전역적으로 처리해야 했습니다.

 

 

👨‍🔧Action - 행동 및 작업

정책을 먼저 합의하고, 공통 계층으로 끌어올려 “한 번에 적용”

 

 

“타임 아웃 설정 및 리트라이 구조, 폴백 프로세스 정책 구상 후 팀내 제안”

SSG 관련 에러로그를 파악하면서 스크래핑 모듈에 내에 존재하는 문제점들을 먼저 리스트업 했습니다. 이를 기반으로 개선할 수 있는 점과 기대효과를 정리해 글로 작성하고, ASIS 구조와 TOBE 구조를 도식화하여 첨부 했습니다. 글의 핵심은 모든 문제를 따로 보는 것이 아니라 근본적인 문제인 실패처리를 전체 파이프라인으로 보는 관점입니다. 글을 제안서 형태로 다듬어 팀장님 및 부문장님과 회의를 진행했고, 적용 범위/정책/운영 방식까지 합의한 뒤 단계적으로 구현에 들어갔습니다.

 

 

“타임 아웃 설정 및 리트라이 구조 설계”

가장 먼저 손댄 것은 HTTP timeout과 리트라이였습니다. 스크래핑 모듈의 쇼핑몰 업무 하위에는 외부 통신을 수행하는 소스 파일이 약 138개 존재합니다. 이 구조에서 “각 파일에 리트라이 넣기”는 유지보수 관점에서 실패하는 접근입니다. 리트라이 정책은 ‘공통 정책’이기 때문에, 구현도 반드시 ‘공통 계층’에 있어야 유지보수가 편리하다고 생각했습니다.

 

그래서 저는 각 통신 구현체에 로직을 흩뿌리지 않고, 부모 클래스의 HTTP 요청을 Send하는 메서드에 retry를 구현해 138개 파일에 한 번에 적용되도록 만들었습니다. timeout 값은 config로 관리하고, 수집처 특성에 따라 리트라이 횟수를 조정 가능할 수 있도록 리트라이는 수집처 업무 명세서에 설정할 수 있도록 했습니다.

 

리트라이 규칙은 단순하지만 명확하게 잡았습니다. 

• 네트워크 예외(타임아웃/커넥션 문제 등)
• 429 응답 또는5xx 대 응답

 

 

무작정 재시도하지 않도록, 리트라이는 기본적으로 2회로 제한했습니다. 즉 한 요청당 최대 3회까지 시도합니다. 과도한 재시도는 외부 장애 상황에서 실패를 폭발시키는 방향이 되기 때문에, “성공률 상승”과 “장애 증폭 방지” 사이에서 균형을 잡는 게 중요했습니다.

 

 

여기서 핵심은 “리트라이를 어떻게 기다리느냐”입니다. 같은 요청을 즉시 연속으로 보내는 방식은 거의 최악입니다. 외부 서버가 잠깐 버벅이거나 rate limit이 걸린 상황에서는, 짧은 시간에 요청이 몰리면 더 악화될 가능성이 큽니다. 그래서 리트라이 대기시간은 지수 백오프(Exponential Backoff)를 사용했습니다. 실패가 누적될수록 대기 시간을 늘려 외부 서버에 회복 시간을 주고, 리소스도 보호할 수 있도록 했습니다.

 

 

그리고 지수 백오프만으로는 충분하지 않습니다. 같은 시간대에 수많은 요청이 실패했다면, 모든 워커가 “2초 뒤 재시도”처럼 동일한 패턴으로 깨어나 다시 요청을 몰아넣습니다. 이건 장애 상황에서 2차 폭발(재시도 스파이크)을 만들 수 있습니다. 그래서 백오프 딜레이에 지터(Jitter)를 넣었습니다. 지연 시간을 50~150% 범위에서 랜덤하게 흩뿌려, 재시도 트래픽이 특정 순간에 쏠리지 않도록 분산했습니다.

const delay = 1000 * 2 ** attempt_count; // 1초, 2초, 4초... 지수 백오프
const delay_ms = delay * (0.5 + Math.random()); // Simple Jitter 
sleep(delay_ms);

 

 

다만, 모든 업무에 리트라이를 적용하진 않았습니다. 카드/은행처럼 응답을 스크래핑해서 데이터를 추출하는 업무는, 잦은 요청이 보안 정책에 의해 IP 차단으로 이어질 수 있습니다. 이 영역에서는 “성공률”을 조금 올리기 위해 리트라이를 넣는 순간, “차단 리스크”라는 더 큰 비용을 치를 수 있습니다. 그래서 이 영역은 리트라이 제외로 정책을 확정했습니다.

즉, 리트라이를 도입하되 무조건이 아니라, 업무 특성과 리스크를 기준으로 적용 대상을 구분했습니다.

 

 

“Fallback 프로세스로 기능 차단 자동화를 위해 서킷 브레이커 패턴을 활용”

우리가 외부 리소스 서버를 이원화해 특정 서버 장애시 다른 서버로 보내 failover 할 수 있다면 실패율을 낮추고 사용자의 경험을 증대시킬 수 있을 것입니다. 하지만 우리가 외부 서버의 이원화를 가능케 할 수 있는 방법은 없습니다.

 

현실적인 fallback은 “더 이상 시도하지 않는 것”입니다. 외부가 죽었는데 계속 때리는 건 우리도 손해, 외부도 손해, 사용자는 더 큰 손해입니다. 이때 가장 잘 맞는 패턴이 서킷 브레이커(Circuit Breaker)이라고 생각했습니다. 서킷 브레이커는 외부 의존성이 일정 기준 이상 실패하면 회로를 열어(Open) 요청을 차단하고, 정상 상태(CLOSED), 탐색 상태(HALF_OPEN)를 이용해 시스템을 보호하는 패턴입니다. 저는 이 패턴을 단순히 라이브러리로 붙이는 것이 아니라, 우리 시스템의 운영 방식에 맞게 “정책/룰”로 구현했습니다.

 

 

처음에는 공용 저장소인 Redis에 수집처별 실패 카운트를 누적하고, 임계치 초과 시 자동 차단하는 구조를 떠올렸습니다.

하지만 사내에는 매 초 룰을 평가하는 공용 시스템이 이미 존재했고, 부문장님 권유로 그 서비스를 먼저 활용하기로 했습니다. 12월 17일 SSG 장애 당시 남은 로그를 기반으로, “슬라이딩 윈도우 알고리즘을 활용해, 최근 일정 시간 슬라이스 안에서 실패가 얼마나 발생하면 장애로 볼 것인가”를 룰로 정의했습니다.

 

 

에러 로그 스파이크가 몰렸을 땐 1분 사이에 10건, 평균적으론 4.4건이 발생했습니다. 실패 집계 윈도우를 30초로 잡고, 실패 카운트 역치 값을 5회로 해보기로 하였습니다.

 

 

OPEN 상태 지속시간과 HALF_OPEN 은 어떻게 할지에 대해서도 논의했습니다. 서킷 브레이커는 회복 탄력성 관점에서 Half-Open을 통한 자동 회복 탐지가 일반적이지만, 저희 조직에서는 외부 장애의 원인 파악과 안정성 확인이 더 중요하다고 판단했습니다.

 

그래서 회의 이후 결론은 “자동 Half-Open으로 조금씩 열어보는 방식”이 아니라, 사람이 원인을 확인하고, 안정성을 가시적으로 확인한 뒤 수동으로 오픈하는 운영 정책이었습니다.

이런 선택은 자동화 수준을 일부 낮추는 대신, 불필요한 재폭발을 막고 운영 리스크를 줄이는 방향입니다. 시스템 설계에서 이런 트레이드오프는 늘 존재하고, 이번엔 운영 안전 쪽을 택했습니다.

 

 

차단이 발생하면, 외부 수집 기능 on/off를 관리하는 Redis 상태값을 off 로 만들어 사용자의 요청 자체를 막습니다. 사용자는 외부 사이트 변경으로 인해 기능을 사용하지 못한다는 알림창을 받을 수 있습니다.

 

 

그리고 “○○수집처가 시스템에 의해 자동 차단되었다”는 이벤트를 팀 내 에러 로그 알림방으로 보내 운영자가 즉시 인지할 수 있게 했습니다. 또한 오탐(일시적 오류를 장애로 판단하는 케이스)을 대비해, 서킷 브레이커를 수동으로 끄고 켤 수 있는 기능도 제공했습니다. 외부 서버에 장애가 발생해 또 다시 실패 로그가 남는다면 그 양상을 파악해 설정값을 튜닝해 나가기로 했습니다.

 

 

 

“예외 처리 누수를 해결하기 위해 글로벌 익셉션 핸들러 개발과 스크래핑 모듈 리팩토링”

기존 스크래핑 모듈의 에러는 공용 PTP 로그로만 쌓이고, 모니터링 팀이 주로 먼저 대응하는 구조였습니다. 하지만 이번 개선을 제안하는 과정에서, 부문장님께서 “스크래핑/API 팀 자체 로그 테이블을 만들고 운영 주체를 우리 팀이 가져가자”고 결정해주셨습니다. 이걸 통해 발생하는 문제를 팀내에서 먼저 모니터링해 주도적으로 개선하도록 지시하셨습니다.

작업 제안자인 저에게 전반적인 권한을 주셔서 직접 실패 이력 테이블을 설계하고, 어떤 단계에서 에러 발생시 필요한 구분값 등을 정했습니다. 담당 모니터링 동료가 평소에 원했던 구분값(서버/어시스턴트, 법인/개인, 내부 소스 문제/외부 통신 문제 등)을 스키마에 포함해, 문제가 터졌을 때 “원인 분류”가 빨라지도록 했습니다.(관리자 화면 렌더링 도표는 다른 개발자 담당이라 미완성되어 보지 못했지만 dual write 하여 일단은 공용 ptp 로그로 확인하고 있습니다.)

 

 

예외 처리 누수를 해결하기 위해 글로벌 익셉션 핸들러를 만들었습니다. 

전역적인 예외 처리를 할때 “각 파일에서 하는 구조”로 두지 않았습니다. 저는 TypeScript 메서드 데코레이터를 만들어 스크래핑 모듈의 진입점에 전역 예외 처리를 걸었습니다. 아이디어는 Spring Boot의 @RestControllerAdvice에서 가져왔습니다.

try {
  // 핸들러(컨트롤러 메서드) 호출
} catch (Exception ex) {
  // 여기서 "예외 처리 체인"으로 넘김
  processHandlerException(ex);
}

 

Spring에서 전역 예외 처리가 가능한 이유는, 컨트롤러 각각을 try/catch로 감싸기 때문이 아니라 요청의 진입점(DispatcherServlet)에서 예외를 한 번 잡아 공통 정책으로 응답을 매핑하기 때문입니다.

즉, “진입점을 Around로 감싼다”는 발상입니다.

 

 

이를 스크래핑 모듈로 옮기면, 토픽을 구독해 실행되는 Action이 “요청의 최초 진입점” 역할을 합니다. 스크래핑 모듈은 템플릿 메서드 패턴에 의해 모든 Action의 실행 함수가 executeCore()로 정해져 있으니, 저는 여기에 메서드 데코레이터를 달아 executeCore()를 Around Advice처럼 래핑했습니다.

 

export function _global_exception_handle(
  target: any,
  property_key: string,
  descriptor: PropertyDescriptor
) {
  const original_method = descriptor.value;

  descriptor.value = function (context: IExecutionContext, request: any) {
    try {
      return original_method.call(this, context, request);
    } catch (exception: unknown) {
      _globalExceptionHandle(context, exception, request);
    }
  };

  return descriptor;
}

function _globalExceptionHandle(
  execution_context: IExecutionContext,
  exception: unknown,
  request: any
): void {
  const global_exception_handler =
    execution_context.getFeature<IScrapingGlobalErrorHandlerFeature>(
      IScrapingGlobalErrorHandlerFeature
    );

  if (!(exception instanceof Error)) {
    global_exception_handler.handleUnknownThrown?.(exception, request);
    return;
  }

  switch (exception.name ?? '') {
    case SCRAPING_ERROR_TYPE.SCRAP_ERROR:
      global_exception_handler.handleScrapError(exception, request);
      return;

    case SCRAPING_ERROR_TYPE.E2E_ERROR:
      global_exception_handler.handleE2EError(exception, request);
      return;

    case SCRAPING_ERROR_TYPE.HTTP_CLIENT_ERROR:
      global_exception_handler.handleExternalHttpClientError(exception, request);
      return;

    case SCRAPING_ERROR_TYPE.ASSITANT_ERROR:
      global_exception_handler.handleAssistantError(exception, request);
      return;

    case SCRAPING_ERROR_TYPE.REDIS_CLIENT_ERROR:
      global_exception_handler.handleExternalRedisClientError(exception, request);
      return;

    case SCRAPING_ERROR_TYPE.NETWORK_ERROR:
      global_exception_handler.handleNetworkError(exception, request);
      return;

    default:
      global_exception_handler.handleUnknownError(exception, request);
      return;
  }
}

 

이 데코레이터를 통해 예외 처리 정책이 바뀔 때마다 관련된 모든 파일을 찾아 수정할 필요가 없어졌습니다. 각 단계별로 적합한 커스텀 에러(“어떤 실패인지”, "사용자에게 보일 문구"를 프로퍼티로 갖음)를 던지고, 글로벌 핸들러가 그 에러를 분류해 로그를 적재하고, 이력을 실패로 업데이트하는 토픽을 send하고, 사용자에게 보여줄 메시지를 표준화합니다.(AOP)

 

즉, 예외 발생 시점은 그대로 유지하면서, 처리 정책만 중앙으로 모으는 구조가 됩니다.

기존 흐름 (에러 관리를 위한 여러 분기문이 존재 + 에러 처리를 위한 중복된 로직 다수 존재)

글로벌 예외 핸들링으로 예외 처리를 한곳에서만 집중 관리

 

이 방식은 try/catch + 분기 로직이 섞여 있어 “비즈니스 로직 + 예외 처리”가 뒤엉키던 구조에서, "에러 처리"라는 관심사를 분리해 소스의 가독성과 유지보수성을 동시에 올립니다.

 

무엇보다 중요한 건, 진입점에서 try/catch가 보장되기 때문에 예외가 새어 나가 비정상 종료되는 케이스가 구조적으로 완벽하게 없어진다는 점입니다.

 

 

 

🏆Result - 결과 및 성과

실패는 줄었고, 누수는 막혔고, 운영은 자동화됐다.

 

이 개선의 결과는 “안정성”이라는 추상적인 단어로만 설명하기엔 아쉬울 정도로 구체적이었습니다.

 

“타임아웃 설정과 리트라이 적용으로 느린 요청 2개 관측 및 실패율 95.24% 감소”

우선, HTTP timeout을 5초로 명확히 설정하면서 “느린 요청”이 관측되기 시작했습니다. 이전에는 Action timeout에 묻혀 원인을 보기 어려웠던 지연이, 통신 단계에서 분리되며 드러난 것입니다. 그 과정에서 지연율이 높은 요청 2건을 찾아 조치했습니다. 플레이오토EMP 상품 조회 API는 한 번에 모든 주문상태를 500건 조회하며 10초가 걸리고 있었고, 팀장님과 상의 후 200건씩 조회하도록 수정했습니다. 

 

 

쿠팡 “상품 처리중” API(주문상태 변경 PUT메서드)는 50건 배치 처리 시 6초가량 걸리는 것을 확인했고, 20건씩 보내도록 조정했습니다. 이 과정에서 중요한 사실도 확인했습니다.

 

PUT 메서드 요청이라 멱등성이 보장될 것이므로 타임아웃 후 재시도해도 안전할 것이라 기대했지만, 실제로는 “배송상태를 변경할 수 없습니다. 주문내역을 확인해주세요” 같은 실패 처리가 발생했습니다.

 

그래서 해당 유형의 요청은 리트라이 대상에서 제외하는 정책을 팀 내에서 확정했고, “기술적으로 그럴 듯한 가정”보다 “실제 외부 API의 동작”을 기준으로 정책을 다시 잡는 계기가 됐습니다.

 

 

정량적으로 보면, 영업일 5일 기준 HTTP 요청 실패 케이스가 배포 전에는 21건 있었지만 배포 후 동일 조건에서 1건으로 줄었습니다. 감소율로 계산하면 약 95.24%입니다.

ASIS - 21건

 

TOBE - 1건 : RequestTimeout : 5초

 

단순히 리트라이를 넣어서 줄어든 게 아닙니다. timeout으로 실패를 빠르게 분류하고, retry로 간헐 실패를 흡수하고, 위험한 업무은 정책으로 제외하는 “균형 잡힌 실패 처리”가 작동한 결과였습니다. 이 수치는 사용자 경험을 직접적으로 끌어올립니다. 사용자가 느끼는 건 “성공/실패율”이고, 성공률의 작은 상승은 반복 사용 서비스에서 체감 차이가 크게 나타난다고 생각합니다.

 

 

“7832개의 고객사에서 사용하는 쇼핑몰 기능 안정화 및 스크래핑 모듈 내 에러 100% 처리”

또한 7,832개의 고객사가 사용하는 쇼핑몰 기능 관점에서도 의미가 컸습니다. 요청 진입점에 메서드 데코레이터 기반 전역 try/catch가 걸리면서, 기존에 누수되던 예외로 인해 이력이 진행중으로 남거나, 에러 문구가 그대로 노출되던 문제가 구조적으로 정리되었습니다.

 

네트워크 문제나 인프라 장애가 아닌 이상, 사용자는 작업 결과를 “성공/실패로 명확히” 확인할 수 있고, 실패하더라도 사용자 친화적인 메시지로 안내받게 됩니다. 알 수 없는 에러도 default 실패 문구로 처리해 “에러 원문 노출” 문제를 제거했습니다. 예외 처리 정책을 코드 곳곳에서 통제하는 대신, 전역 핸들러 하나로 모아 관리하는 구조가 됐기 때문에 이후 정책 변경도 훨씬 쉬워졌습니다.

 

 

“운영자의 판단이 아닌 시스템에 의해 자동으로 기능 차단”

마지막으로, 서킷 브레이커 기반 자동 차단은 “개발자나 운영자가 판단해서 막는 운영”에서 “시스템이 먼저 보호하는 운영”으로 전환시켜줍니다.

 

외부 장애가 의심되면 요청을 Fail Fast로 차단해 더 많은 사용자가 실패를 경험하기 전에 보호할 수 있고, 로그 폭발을 방지하며, 외부 리소스 서버에도 불필요한 트래픽을 줄일 수 있습니다.

 

이번 글 작성 시점에는 “실제 외부 서버 대규모 장애 재발”이 없어 로그 폭발 전/후 비교 수치를 아직 만들진 못했지만, 구조 자체는 장애가 다시 올 때 확실하게 효과를 볼 수 있는 형태로 준비되었습니다. 무엇보다 중요한 건, 장애가 왔을 때 “사람이 알아차릴 때까지 기다리는 구조”가 아니라, 자동으로 시스템이 먼저 실패를 통제하는 구조가 됐다는 점입니다.

 

 

“주도적인 문제 해결 자세와 문제 해결 능력에 대해 칭찬”

잠깐의 외부 서버 장애로도 '장애가 해결 됐으니, 다시 서비스 정상 동작'으로 끝나지 않고, 근본적인 문제점을 찾아내어 이에 대해 개선 방안을 먼저 사내에 제안한 점에 대해 높은 칭찬을 받을 수 있었습니다.

업무 보고서 관련 팀장님 및 부문장님 첨언 내용

 

단순히 로그를 파악하고 단발성으로 수습하는 수준이 아니라, “왜 이런 장애에서 로그가 폭발했는지”, “왜 사용자에게 에러가 그대로 노출되는지”, “왜 실패 이력이 ‘진행중’으로 남는지” 같은 구조적인 원인을 끝까지 파고들어 정리한 태도를 좋게 평가해주셨습니다.

 

결과적으로 이번 개선은 단순한 기능 패치가 아니라, 서비스 안정성과 사용자 경험을 함께 끌어올리는 실패 처리 체계로 이어졌고, 저 역시 장애 대응을 ‘사후 처리’가 아니라 재발을 막는 구조 개선으로 확장하는 방식을 체득할 수 있었습니다.

 

 

✍️마무리

이번 작업은 HTTP timeout 값을 몇 초로 바꾸고, retry를 2회 넣는 정도의 변경이 아니었습니다. 실패를 어떻게 관측하고, 어떻게 분류하고, 어떻게 처리하고, 어디서 정책을 관리할지까지 포함한 “실패 처리 체계”를 만든 작업이었습니다.

외부 장애는 언제든 옵니다. 하지만 외부 장애가 왔을 때 우리 시스템이 해야 할 일은 명확합니다. 통신 단계에서 적절히 끊고, 간헐 실패는 흡수하되 위험한 업무은 보호하고, 장애 구간에서는 더 큰 실패가 오기 전에 자동으로 차단하며, 어떤 예외가 발생해도 사용자에게는 일관된 결과와 메시지를 제공해야 합니다.

 

이번 개선 작업은 문제가 발생했을 때 정말 근본적인 문제점을 찾고(사내 에러 처리), 문제점을 해결하고(적절한 정책과 기술적 전략), 또 다시 관련 문제가 발생했을 때 방어는 어떻게 자동화 해볼 수 있는지(폴백 프로세스) 고민에 대한 저만의 구현 및 해결방안을 도출해 내는 좋은 경험이됐습니다.