백엔드 시스템에서의 타임아웃(Timeout)에 대한 이해와 설계 기준

 

🔷개요

2025년 12월 17일, 외부 수집처인 SSG에서 전사적인 장애가 발생하였습니다.
장애 알림 메신저를 통해 상황을 인지한 직후, 문제 원인을 파악하기 위해 관련 로그를 확인하였습니다.

 

확인 결과, SSG 측의 전체 서버 장애로 인해 요청 자체를 정상적으로 처리할 수 없는 상황이었으며, 이로 인해 모든 요청이 실패하고 있었습니다.
다만 로그 상에 남은 오류 유형은 HTTP 요청 타임아웃이 아닌 액션 타임아웃(Action Timeout) 으로 기록되어 있었습니다.

 

여기서 말하는 액션 타임아웃이란, “하나의 액션 스크립트를 실행하는 데 허용하는 총 시간”입니다.
API요청을 받고 액션이 시작된 순간부터, 내부 로직과 외부 연동을 모두 거쳐 결과를 반환(또는 후속 처리를 완료)할 때까지의 전체 허용 시간을 일컫습니다.
즉, “외부 서버 응답 지연”이 아니라 “내부 로직이 오래 걸려 실패한 것처럼” 보이는 로그가 남고 있었던 것입니다.

 

이상하다고 판단하여 원인을 추적한 결과, 타 팀에서 외부 HTTP 요청에 대한 타임아웃 값 리팩토링을 진행하면서 타임아웃을 기본값으로 설정해 놓았고, 기본 타임아웃 값은 액션 타임아웃과 동일하게 되어 있던 문제를 발견했습니다.
그로 인해 외부 요청이 지연되거나 응답하지 않는 상황에서도, HTTP 요청 단계에서 타임아웃이 발생하지 않고 전체 액션이 끝날 때까지 대기하다가, 최종적으로 액션 타임아웃으로 실패 처리되고 있었습니다.

 

이 구조에서는 다음과 같은 문제가 발생합니다.
실제 원인은 외부 서버 장애임에도 로그 상으로는 내부 로직이 오래 걸린 것처럼 보이며 장애 분석 시 원인 파악이 어렵고 재시도, 우회 처리, 장애 전파 차단 전략을 적용하기도 힘들어집니다.

 

이에 따라 저는 내부 로직 수행 중 오래 걸려 발생하는 실패는 액션 타임아웃으로, 외부 시스템 호출로 인해 지연되거나 응답을 받지 못한 경우는 요청 타임아웃으로 명확히 구분하여 로깅될 수 있도록, 관련된 전체 파일의 타임아웃 설정을 수정하였습니다.

 

작업을 통해 단순히 타임아웃 값을 조정했다기보다는, "타임아웃이 왜 필요한지", "어떤 종류의 타임아웃이 존재하는지", 그리고 "타임아웃을 어떻게 구분하고 설계해야 운영 환경에서 의미 있는 로그와 장애 대응이 가능한지"에 대해 공부하고 정리해 보았습니다.

 

 

🤔타임아웃(Timeout)이란 무엇인가?

타임아웃(timeout)은 말 그대로 어떤 작업을 얼마나 오래 기다릴 것인지에 대한 최대 허용 시간을 의미합니다.
백엔드 시스템에서 타임아웃은 네트워크 요청, 데이터베이스 조회, 외부 API 호출, 내부 비동기 작업 등에서 정해진 시간 안에 처리가 완료되지 않을 경우 실패로 간주하고 중단하는 기준으로 사용됩니다.

 

타임아웃은 단순히 “느리면 끊는다”는 의미보단 시스템이 예기치 않은 상황에서도 무한 대기 상태에 빠지지 않도록 하는 방어 장치라고 보는 것이 더 정확합니다.
특히 분산 시스템 환경에서는 “언제까지 기다릴 것인가”를 명확히 정의하지 않으면, 작은 지연 하나가 전체 시스템 장애로 확대될 수 있습니다.

 

 

 

⏱️타임아웃이 반드시 필요한 이유

1. 무한 대기는 반드시 전염됩니다

백엔드 시스템에서 하나의 요청이 응답을 받지 못한 채 계속 대기하게 되면, 해당 요청을 처리하던 스레드나 워커는 반환되지 않습니다.
이 상태가 누적되면 결국 스레드 풀 고갈, DB 커넥션 풀 고갈, 메시지 큐 적체로 이어지게 됩니다.

 

현업에서는 종종 다음과 같은 상황이 발생합니다.
외부 API 하나가 느려졌을 뿐인데, 내부 서비스 전체가 응답하지 않는 것처럼 보이는 장애

이는 대부분 타임아웃이 없거나 지나치게 길게 설정된 경우에 발생합니다.

 

 

2. 실패를 인지하지 못하면 복구도 할 수 없습니다

타임아웃이 없다는 것은 곧, “이 요청이 실패했는지 성공했는지 영원히 알 수 없다”는 의미가 됩니다.
실패를 인지하지 못하면 재시도도 할 수 없고, 다른 경로로 우회하거나 대체 처리 로직을 실행할 수도 없습니다.
타임아웃은 단순한 제한이 아니라, 실패를 명확하고 빠르게 처리할 수 있게 도와줍니다.

 

 

3. 사용자 경험을 보완할 수 있습니다.

사용자 입장에서 다음 두 가지 상황을 비교해 보겠습니다.

1. 10초 동안 아무 응답도 없는 요청
2. 3초 만에 “일시적인 오류” 응답을 받는 요청

대부분의 경우, 빠르게 실패하는 쪽이 훨씬 낫습니다.
타임아웃은 내부 시스템 보호뿐 아니라, 사용자 경험의 하한선을 보장하는 역할도 함께 수행합니다.

 

 

 

🔢 타임아웃의 주요 종류

타임아웃은 하나의 값으로 끝나지 않으며, 계층별로 서로 다른 의미를 가집니다.

 

1️⃣ 커넥션 타임아웃 (Connection Timeout)

커넥션 타임아웃은 서버와 연결 자체를 맺는 데까지 허용하는 시간을 의미합니다.
DNS 조회, TCP Handshake, TLS Handshake 과정이 여기에 포함됩니다.

서버가 죽어 있거나 네트워크가 단절된 상황에서는, 이 타임아웃이 없을 경우 요청이 매우 오랜 시간 대기 상태로 남게 됩니다.
실무에서는 보통 수백 밀리초에서 수 초 이내로 비교적 짧게 설정합니다.

 

 

2️⃣ 읽기 타임아웃 (Read Timeout)

읽기 타임아웃은 연결은 완료되었지만, 응답 데이터를 받지 못하고 있는 상태에서의 대기 시간 제한입니다.

현업에서 가장 자주 문제를 일으키는 타임아웃 유형이기도 합니다. 특히 외부 API가 “처리는 완료했지만 응답이 늦어지는 상황”에서 자주 발생합니다.

예를 들어, 결제사나 금융 API 연동 시 실제로는 처리가 되었지만 응답이 늦어 타임아웃이 발생하고 동일 요청을 재시도하게 되는 상황이 있습니다.
이 경우, 타임아웃과 멱등성 설계가 함께 고려되지 않으면 중복 처리로 이어질 수 있습니다.

 

 

3️⃣ 쓰기 타임아웃 (Write Timeout)

쓰기 타임아웃은 요청 데이터를 서버로 전송하는 데 허용되는 최대 시간입니다.

클라이언트 사이드에서 요청 데이터를 서버 소켓으로 밀어 넣는 과정이 너무 오래 걸리고 있지 않은가에 대해 고민해 볼 수 있습니다. 쓰기 타임아웃은 클라이언트 네트워크 스택 관점의 타임아웃입니다.
특히 대용량 요청이나 파일 업로드, 스트리밍 환경에서 중요합니다.

일반적인 JSON 기반 API에서는 크게 체감되지 않지만, 대용량 업로드를 처리하는 백엔드라면 반드시 고려해야 하는 항목입니다.

 

 

4️⃣ 전체 요청 타임아웃 (Request / Call Timeout)

전체 요청 타임아웃은 요청 시작부터 응답 완료까지의 총 허용 시간을 의미합니다.
내부적으로는 connection, read, write 타임아웃을 모두 포함하는 개념입니다.

 

https://www.keycdn.com/support/408-request-timeout

 

업무 관점에서는 가장 직관적인 타임아웃이며, “이 API는 최대 몇 초까지 허용한다”라는 서비스 기준선이 됩니다.
앞서 저희 사내에서 쓰는 액션 타임아웃도 이와 동일한 개념을 가집니다.

 

 

5️⃣ 서버 내부 타임아웃

외부 호출이 없어도, 서버 내부에는 다양한 타임아웃이 있습니다.

• DB 쿼리 타임아웃
• 트랜잭션 타임아웃
• 락 대기 타임아웃
• 큐 소비 처리 제한 시간
• 비동기 작업 실행 제한 시간

특히 DB 락이나 트랜잭션 타임아웃이 없을 경우, 성능 문제와 데이터 정합성 문제가 동시에 발생할 수 있습니다.

사내에서도 쿼리 타임아웃을 6초 설정하여 오래 걸리는 쿼리의 경우 로깅을 남겨 쿼리 튜닝의 여지가 있는지, 인덱스를 설계해서 보완해야 하는지 판단하고 있습니다.

 

 

 

📍실무에서의 타임아웃 설정 기준

타임아웃을 설정할 때 가장 중요한 점은 “일관된 숫자”가 아니라 “의미 있는 기준”라고 생각합니다. 왜냐하면 각각의 비즈니스 요구사항에 맞게 값을 설정해야하기 때문입니다.

 

1. 호출 대상에 따라 다르게 설정

예를 들어 다음 세 호출은 성격이 완전히 다릅니다.

1. 내부 DB 조회
2. 내부 마이크로서비스 호출
3. 외부 결제/금융 API 호출

그럼에도 모든 호출에 동일한 타임아웃을 적용한다면, 불필요한 실패 또는 과도한 대기가 발생할 가능성이 높습니다.

대략적인 기준 예시는 다음과 같습니다.

• 내부 DB 조회: 수백 ms ~ 수 초
• 내부 서비스 호출: 1~2초
• 외부 API 호출: 2~5초 (업무 중요도에 따라 조정)

 

 

2. “최대 처리 시간”이 아니라 “포기해도 되는 시간”으로 기준 설정

타임아웃은 “최대 몇 초 걸릴 수 있는가”가 아니라, “이 이상 기다리는 것은 의미가 없다”라는 기준으로 설정하는 것이 바람직합니다.
이 관점이 없으면 타임아웃 값은 점점 늘어나기만 합니다.

 

 

3. 재시도 전략과 함께 설계

타임아웃만 있고 재시도가 없다면, 일시적인 네트워크 문제에도 바로 실패로 이어집니다.
반대로 재시도만 있고 타임아웃이 없다면, 시스템 전체가 장시간 대기로 묶일 수 있습니다.

실무에서는 보통 다음 요소를 함께 고려합니다.

• 타임아웃
• 재시도 횟수
• 재시도 간격(백오프)
• Circuit Breaker 패턴

 

 

⚠️타임아웃 설정 시 자주 발생하는 실수

1. “일단 넉넉하게” 설정하는 경우

가장 흔한 실수라고 생각됩니다. 넉넉한 타임아웃은 안정적으로 보이지만, 실제로는 장애 전파 시간을 늘립니다.

 

 

2. 모든 호출에 동일한 타임아웃을 적용하는 경우

시스템의 복잡도가 높아질수록, 타임아웃은 반드시 호출 맥락별로 분리되어야 합니다.

예를 들어 같은 Open API 를 통한 주문 데이터 수집이더라도, 해외 쇼핑몰 같은 경우 더 넉넉한 시간을 설정할 수 있습니다.

 

 

3. 타임아웃 로그를 남기지 않는 경우

운영 환경에서 타임아웃 로그는 성능 병목과 장애 원인을 찾는 가장 중요한 단서 중 하나입니다.
“타임아웃이 발생했다”보다 “어디에서, 얼마나 기다리다 실패했는지”가 훨씬 중요합니다.

 

📜마무리하며

타임아웃은 단순한 설정 값이 아닙니다. 적합한 타임아웃을 설정하기 위해선 시스템이 실패를 어떻게 받아들이는지, 언제 포기하고 언제 버틸 것인지 고민해야합니다.
제대로 된 타임아웃 설정은 내부 시스템의 리소스 낭비를 줄이고, 사용자 경험을 높입니다.

 

 

정확한 타임 아웃 설정과 정책은 장애 발생시에도 빠르게 대처하는 데에 도움이 됩니다. 커넥션 타임아웃이 발생했다면 내부적인 로직의 오류 파악이 아닌 인프라적인 문제가 있는지 빠르게 진단해볼 수 있습니다.

DB 쿼리 타임아웃 발생시, 쿼리 개선이 필요한 상황을 빠르게 인지하고, DB 장애에 이어지지 않도록 예방할 수도 있습니다.