백엔드 요청 타임아웃 예산 설계

백엔드 장애는 느린 실패에서 더 자주 커집니다. 완전히 죽는 시스템보다, 조금씩 늦어지는 시스템이 큐를 쌓고 스레드를 묶고 결국 전체 체인을 무너뜨리는 경우가 많습니다. 그래서 타임아웃은 단순한 네트워크 옵션이 아니라 자원 보호 계약입니다.

타임아웃을 한 곳에서만 정하면 안 된다

흔한 실수는 API 게이트웨이에만 5초 타임아웃을 두고 내부 서비스는 모두 기본값에 맡기는 것입니다. 이 경우 바깥에서는 5초 뒤 실패해도, 안쪽 서비스와 DB 커넥션은 더 오래 붙잡혀 있을 수 있습니다.

좋은 구조는 전체 요청 시간 안에서 예산을 나누는 것입니다.

각 계층이 같은 숫자를 공유하면 안 되고, 바깥이 안쪽보다 약간 더 길어야 취소와 정리가 정상적으로 동작합니다.

평균이 80ms라고 해서 100ms 타임아웃을 두는 식은 위험합니다. 실제 사용자 문제는 보통 p95, p99에서 발생합니다.

타임아웃을 정할 때는 다음을 함께 봐야 합니다.

특히 재시도가 있는 시스템은 “한 번의 호출 시간”이 아니라 전체 시도 예산으로 계산해야 합니다.

재시도는 회복력을 만들 수도 있지만, 잘못 걸면 장애를 증폭시킵니다. 예를 들어 2초 타임아웃에 3회 재시도를 허용하면 사용자에게 6초 이상 기다리게 하면서 하위 시스템에는 더 큰 부하를 줍니다.

그래서 보통은 다음 원칙이 안전합니다.

재시도는 “실패를 고치는 마법”이 아니라 제어된 복구 시도여야 합니다.

상위 요청이 이미 종료됐는데 하위 작업이 계속 실행되면, 타임아웃 숫자를 잘 넣어도 보호 효과가 작습니다. 프레임워크 차원에서 취소 신호가 하위 HTTP 클라이언트, DB 드라이버, 비동기 작업으로 전달되는지 확인해야 합니다.

타임아웃은 느린 시스템을 숨기기 위한 숫자가 아니라, 시스템이 어느 시점에서 자원을 포기할지 선언하는 규칙입니다. 잘 설계된 백엔드는 성공 경로만 빠른 것이 아니라, 실패 경로도 짧고 통제 가능합니다.