Connection Pool의 Wait을 조절한다는 것

Connection Pool의 Wait Time은 단순한 시간 설정이 아니라, 사용자 경험과 시스템 안정성 간의 균형 전략이다.

Connection Pool 설정에서 wait time(acquireTimeoutMS 또는 serverSelectionTimeoutMS 등)을 짧게 가져가는 이유는 단순히 성능 때문이 아니라, 사용자 행동과 시스템 리스크를 통합적으로 고려한 전략적 선택이어야 한다.

예를 들어 max pool size가 10인 상황에서 30개의 요청이 동시에 들어왔고, 이때 DB가 느려져 하나의 쿼리에 10초 이상이 걸린다고 가정하자. 그렇다면 10개의 요청은 커넥션을 점유하고 처리 중이고, 나머지 20개는 커넥션을 기다리는 상태가 된다. 이때 wait time이 30초라면, 커넥션을 기다리는 요청은 최대 30초 동안 아무런 응답도 받지 못하고 계속 대기하게 된다.

이 상황은 단순한 지연이 아니다. 유저는 반응이 없자 새로고침을 반복하게 되고, 브라우저나 모바일 앱은 이전 요청을 취소하지 않은 채 새로운 요청을 계속 전송한다. 결국 대기 중인 요청 + 새로 들어온 요청이 합쳐져서, DB와 서버는 재시도 스톰(Retry Storm)에 빠지게 된다.

특히 Node.js처럼 싱글 스레드 기반의 런타임에서는, I/O 병목이 곧 event loop 지연 → 전체 서비스 응답성 저하로 이어지기 때문에 더 큰 문제가 된다.

짧은 Wait Time은 “빠른 실패”를 유도함으로써 시스템을 보호한다

그래서 나는 wait time을 짧게, 예를 들어 1초 이내로 설정하는 것이 다음과 같은 이점을 가진다고 본다.

• 사용자 입장:
  무반응 상태에서 수십 초 대기하는 대신, 1~2초 내에 실패 응답을 받아볼 수 있다.
  "실패하더라도 빠르게 응답받는다"는 것은 UX 측면에서도 긍정적이다.
• 서버 입장:
  커넥션 대기열이 비정상적으로 쌓이는 것을 조기에 감지할 수 있고,
  재시도 로직에 의한 트래픽 증폭도 짧은 wait time 덕분에 분산된다.

물론 에러 응답이 늘어날 수 있지만, 무반응 로딩 상태에서의 새로고침 유도 그리고 병목 악화보다는 훨씬 낫다.

커넥션 풀은 단순한 성능 도구가 아니라, 사용자 행동을 고려한 시스템 제어 장치다

wait time뿐 아니라 다음 설정들도 전체 시스템 전략의 일부로 접근해야 한다:

• idleTimeout: 유휴 커넥션을 얼마나 빨리 제거할지
  → 너무 짧으면 아침 트래픽 폭증 시 재연결로 인한 부하 발생
  → 너무 길면 유휴 커넥션이 쌓이며 리소스 낭비
• maxLifetime: 커넥션을 최대 얼마까지 유지할지
  → 장시간 유지 시 DB 내부 커넥션 상태 불일치나 오류 발생 가능
• validation query 또는 connection health check:
  → 잘못된 커넥션이 오래 유지되는 문제 방지
  → wait time이 짧더라도 죽은 커넥션을 반환하고 있으면 아무 의미 없다

이 모든 설정은 결국 하나의 목적을 향한다.

“어떻게 하면 사용자가 느끼는 불편을 줄이면서, 동시에 시스템 자원을 지키고, 장애 전조를 빠르게 포착할 것인가?”

진짜 중요한 건 “원인에 맞는 대응”이다

물론 wait time을 짧게 설정하는 것만으로는 완전한 해결이 아니다. 문제의 본질이 슬로우 쿼리라면, 커넥션을 아무리 조정해도 병목은 해결되지 않는다.

그래서 나는 항상 다음을 함께 본다:

• 슬로우 쿼리 로그 → 쿼리 튜닝, 인덱스 최적화
• TTL 기반 캐시 또는 읽기 전용 Replica → 부하 분산
• Async Queue (예: BullMQ) → 비동기 처리로 응답 속도 개선
• 재시도 정책 제한 → exponential backoff, jitter 도입
• 커넥션 풀 확장 → DB CPU, context switching 비용 고려 후 최후에

결론

Connection Pool의 wait time, idle timeout, max pool size 같은 설정은 성능 수치를 위한 파라미터가 아니다.
그건 유저의 행동 패턴, 시스템의 부하 특성, 네트워크 I/O 병목 현상까지 고려한 시스템 설계이다.

나는 이 설정들을 통해 단순히 "DB를 빨리 쓰는 방법"이 아니라, 시스템이 무너지는 패턴을 미리 감지하고, 사용자 경험을 지키는 보호막을 설계하는 것이 진짜 목적이라고 생각한다.