백엔드 타임아웃 예산 설계 실전 플레이북

실서비스에서 가장 자주 보는 장애 신호 중 하나는 CPU나 메모리보다 먼저 튀는 응답 지연입니다. 문제는 여기서 많은 팀이 timeout=30s처럼 단일 값을 올리거나 내리는 방식으로 대응한다는 점입니다. 지난달 우리 팀도 정산 배치와 사용자 결제 조회가 같은 DB 리더를 공유하던 시간대에 p95가 1.2초에서 8초까지 급등했고, 온콜 채널에서는 “일단 타임아웃을 60초로 올리자”는 의견이 바로 나왔습니다. 하지만 그렇게 하면 겉으로는 실패율이 잠깐 줄어도 워커 점유 시간이 길어져 큐가 더 막히고, 결국 재시도 트래픽까지 붙으면서 전체 지연이 커집니다. 실제로 당시 20분 동안 성공률은 유지됐지만 사용자 체감은 더 나빠졌고, 결제 완료 화면이 늦게 뜨면서 중복 클릭 문의가 급증했습니다. 타임아웃 대응의 핵심은 숫자를 키우는 게 아니라, 사용자 요청이 통과하는 전체 경로를 시간 예산으로 쪼개고 어디에서 대기 시간을 버릴지 먼저 결정하는 일입니다.

판단 기준은 네 가지로 고정하면 팀 내 논쟁이 줄어듭니다. 첫째, 엔드투엔드 예산을 정합니다. 예를 들어 모바일 결제 조회의 체감 한계를 2.5초로 두면 게이트웨이, 앱 서버, DB, 외부 결제사 호출에 각각 상한을 나눠야 합니다. 둘째, 실패 유형을 분리합니다. connect timeout, read timeout, pool acquisition timeout은 원인과 조치가 다르므로 한 그래프에 섞어 보면 판단이 틀어집니다. 셋째, 재시도 정책을 타임아웃과 함께 봐야 합니다. 타임아웃을 2배로 늘리면서 재시도 횟수를 유지하면 실제 점유 시간은 3~4배가 됩니다. 넷째, 백프레셔 지점을 명시합니다. 우리 팀은 API 서버에서만 막지 않고 큐 소비자 동시성까지 함께 낮춰 쓰기 경쟁을 줄였습니다. 이 네 기준을 대시보드와 런북에 같이 두자, 회의에서 “감”으로 값 바꾸는 시간이 줄고 10분 내에 방향이 정해졌습니다.

실행 절차는 30분 기준으로 쪼개는 게 가장 효과적이었습니다. 0~10분에는 신규 배포를 멈추고, 요청 경로별 현재 타임아웃과 재시도 설정을 표로 뽑아 사실부터 맞춥니다. 10~20분에는 완화 조치를 먼저 넣습니다. 사용자 트랜잭션 경로는 타임아웃을 유지하되 비핵심 후처리 작업을 큐로 이관하고, 외부 API 호출은 회로 차단 임계치를 낮춰 지연 전파를 줄입니다. 20~30분에는 구조 조치를 적용합니다. DB 풀 대기 타임아웃을 짧게 잡아 느린 쿼리가 워커를 오래 붙잡지 못하게 하고, 긴 조회는 캐시 가능한 응답으로 분리합니다. 이때 롤백 기준도 함께 못 박아야 합니다. 우리 팀은 5분 이동창에서 p99가 4초를 두 번 연속 넘고 큐 체류 시간이 90초를 초과하면 즉시 이전 정책으로 되돌리도록 정해두었습니다. 예전에 우리는 이 순서를 지키지 않고 외부 API 타임아웃만 늘렸다가 워커 고갈이 먼저 와서 API 서버를 수평 확장하는 비용만 늘린 적이 있습니다. 반대로 이번에는 사용자 경로 2.5초 상한을 끝까지 지키고, 배치 작업을 지연 허용 큐로 돌려 18분 만에 p95를 8초에서 2.9초까지 낮췄습니다.

복구 후 운영 체크리스트는 간단하지만 반드시 숫자와 결정 맥락을 함께 남겨야 합니다. 첫째, 장애 전후의 p95·p99와 큐 체류 시간 변화. 둘째, 타임아웃 상향 대신 비활성화한 기능 목록과 복구 시점. 셋째, 실패 유형 비율 변화(connect/read/pool). 넷째, 재시도 횟수와 백오프 정책을 왜 바꿨는지의 근거입니다. 마지막 주의사항은 “평균 응답시간 정상화”를 종료 신호로 착각하지 않는 것입니다. 평균은 빠르게 회복돼도 꼬리 지연이 남아 있으면 결제·주문처럼 민감한 플로우는 계속 불안정합니다. 그래서 우리 팀은 장애 종료 조건을 평균이 아니라 p99와 큐 적체 동시 정상화로 정의했고, 이후 타임아웃 상수를 서비스별 계약 파일로 통합해 릴리스 리뷰에서 반드시 점검하도록 바꿨습니다. 타임아웃은 성능 튜닝 파라미터가 아니라 사용자 신뢰를 지키는 운영 정책이라는 합의를 문서로 남겨야, 다음 사고 때도 같은 실수를 반복하지 않습니다.