DB가 멈췄어요! HikariCP 커넥션 풀(Connection Pool) 고갈 원인과 최적화 가이드 (렌터카 비유)

안녕하세요, 여러분의 든든한 IT 길잡이 데브프리입니다.

 

스프링 부트(Spring Boot) 3.x 버전대가 완전히 실무 표준으로 자리 잡은 2026년 현재에도, 백엔드 서버의 기본 데이터베이스 연결 도구는 변함없이 HikariCP가 굳건히 자리를 지키고 있습니다. 가볍고, 빠르며, 안정적이기 때문이죠.

 

하지만 서비스에 사용자가 몰리는 피크 타임이 되면, CPU나 메모리 리소스는 널널한데 이상하게 API 응답이 멈추고 서버가 기절해 버리는 미스터리한 장애가 발생하곤 합니다. 에러 로그를 열어보면 십중팔구 '커넥션 고갈(Connection Timeout)' 문제가 적혀 있죠.

 

오늘은 백엔드 개발자라면 반드시 마주치게 되는 HikariCP 커넥션 풀(Connection Pool) 고갈 에러의 원인을 객관적으로 분석하고, 서버가 멈추는 것을 방지하기 위한 실무 최적화 베스트 프랙티스를 렌터카 대여소 비유로 알기 쉽게 정리해 드립니다.

 

1. 커넥션 풀(Connection Pool)이 도대체 뭔가요?

백엔드 서버가 데이터베이스(DB)에서 데이터를 가져오려면, 매번 네트워크를 타고 DB와 연결(Connection)을 맺어야 합니다. 그런데 이 연결 과정(TCP 3-way Handshake 등)은 생각보다 매우 느리고 비용이 많이 듭니다.

이를 해결하기 위해 등장한 것이 커넥션 풀입니다.

커넥션 풀은 렌터카 대여소와 같습니다. DB와 미리 연결된 차량(Connection) 10대를 주차장에 시동을 켠 채로 대기시켜 놓고, 요청이 올 때마다 즉시 빌려주고 쓴 뒤 반납받습니다.

스프링 부트를 켜면 HikariCP는 기본적으로 10개의 커넥션(차량)을 미리 DB와 연결해 두고 풀(주차장)에 보관합니다.

사용자 요청이 들어오면 대여소에서 차를 빌려주고(Borrow), 쿼리를 다 실행하면 다시 대여소로 반납(Return)합니다. 매번 새로 차를 조립해서 탈 필요가 없으니 속도가 비약적으로 빨라지는 것이죠.

 

2. 실전 트러블슈팅: 커넥션 풀은 왜 고갈될까?

로컬 테스트에서는 아무 문제가 없었는데, 실서버에 배포하고 트래픽이 몰리자 아래와 같은 끔찍한 에러가 쏟아집니다.

Plaintext

java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms.
    at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:696)
    at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:197)

이 에러는 "렌터카 대여소에 남은 차가 없어서 손님이 30초(30000ms) 동안 밖에서 기다리다가 화가 나서 집에 가버렸다"는 뜻입니다.

도대체 10대의 차량은 어디로 간 걸까요? 실무에서 발생하는 가장 흔한 원인 두 가지를 분석해 보겠습니다.

원인 ①: 트랜잭션(Transaction)이 너무 길 때

차를 빌려 간 스레드(일꾼)가 차를 빨리 반납하지 않는 경우입니다.

외부 API(결제 연동, 알림톡 발송 등)를 호출하는 로직이 @Transactional 안에 묶여 있으면, 외부 API 응답이 지연되는 3~5초 동안 DB 커넥션도 반납되지 못하고 그대로 묶여버립니다. 이런 요청이 10번만 동시에 들어오면 커넥션 풀은 즉시 고갈됩니다.

원인 ②: 스레드 기아 데드락 (Thread Starvation Deadlock)

백엔드 아키텍처 설계 실수로 발생하는 아주 악랄한 에러입니다.

예를 들어, 하나의 로직을 처리하는 데 2개의 커넥션이 필요한 상황을 가정해 봅시다. (@Transactional(propagation = Propagation.REQUIRES_NEW) 등을 남발했을 때 자주 발생합니다.)

• 대여소에 총 10대의 차가 있습니다.
• 10명의 손님(스레드)이 동시에 들어와서 각각 1대씩 차를 빌렸습니다. (남은 차 0대)
• 그런데 이 10명의 손님은 목적지에 가려면 무조건 차 1대를 더 빌려야 하는 상황입니다.
• 10명 모두 1대씩 탄 상태로, 누군가 차를 반납하기만을 서로 무한정 기다립니다. (데드락 발생)

결국 30초가 지나 타임아웃 에러가 폭발하며 서버가 완전히 뻗어버리게 됩니다.

 

3. 안정적인 서비스를 위한 커넥션 풀 최적화 베스트 프랙티스

이러한 참사를 막기 위해 실무에서는 다음 두 가지 원칙을 적용하여 백엔드 서버를 튜닝합니다.

베스트 프랙티스 1: 트랜잭션 범위 최소화

DB 연결이 필요 없는 로직(네트워크 통신, 파일 업로드 등)은 절대 @Transactional 안에서 실행하지 마세요. 서비스 레이어의 역할을 분리하여, 순수하게 DB 쿼리가 실행되는 짧은 순간에만 커넥션을 빌려 가도록 코드를 리팩토링해야 합니다.

베스트 프랙티스 2: 적절한 풀 사이즈(Maximum Pool Size) 산정

"차가 부족하면 렌터카를 1,000대로 늘리면 되는 거 아닌가요?"라고 생각하기 쉽지만, 이는 최악의 선택입니다. 커넥션이 늘어날수록 DB 서버가 감당해야 할 메모리와 CPU 컨텍스트 스위칭 오버헤드가 기하급수적으로 증가하기 때문입니다. PostgreSQL이나 MySQL 진영에서도 풀 사이즈는 보통 코어 수에 비례하여 작게 유지할 것을 권장합니다.

 

HikariCP의 제작자인 Brett Wooldridge가 제시한 유명한 데드락 방지 공식을 적용해 풀 사이즈를 설정하세요.

• 공식: Tn x (Cm - 1) + 1 (Tn = 톰캣의 최대 스레드 수, Cm = 하나의 스레드가 동시에 요구하는 최대 커넥션 수)

예를 들어 한 로직에서 최대 2개의 커넥션(Cm)이 필요하고, 최대 동시 요청 스레드(Tn)가 10개라면, 10 x (2 - 1) + 1 = 11. 즉, 최소 11개의 커넥션 풀 사이즈를 가져야 데드락을 방지할 수 있습니다. 여유를 두어 15개 정도로 설정하는 것이 합리적입니다.

YAML

# application.yml 설정 예시
spring:
  datasource:
    hikari:
      maximum-pool-size: 15 # 서비스 부하와 데드락 공식을 고려한 최적의 수치
      connection-timeout: 30000 # 30초 (기본값 유지 권장)

커넥션 풀 사이즈를 무작정 늘리는 것은 정답이 아닙니다. 애플리케이션의 처리량과 데이터베이스의 CPU 허용량 사이에서 완벽한 균형점을 찾는 것이 중요합니다.

 

💡 [데브프리의 실무 꿀팁: 지금 내 주차장(Pool)에 남은 차가 있는지 두 눈으로 확인하는 법!]

"이론은 알겠는데, 실제로 커넥션이 부족한지 눈으로 직접 확인하고 싶어요!"

그렇다면 굳이 복잡한 모니터링 툴을 붙이기 전에, application.yml에 아래 로그 설정 딱 두 줄만 추가해 보세요.

YAML

logging:
  level:
    com.zaxxer.hikari.HikariConfig: DEBUG
    com.zaxxer.hikari: TRACE

서버를 켜고 API를 호출해보면 콘솔 창에

[HikariPool-1 - Pool stats (total=15, active=10, idle=5, waiting=0)] 이라는 실시간 현황판이 2초마다 갱신되며 찍히게 됩니다!

• active: 현재 손님이 타고 나간 렌터카 수 (일하고 있는 커넥션)
• idle: 주차장에서 대기 중인 렌터카 수 (쉬고 있는 커넥션)
• waiting: 차가 없어서 대여소 밖에서 기다리고 있는 손님 수 (스레드 대기열)

만약 waiting 숫자가 1 이상으로 계속 올라가고 있다면, 그때가 바로 트랜잭션 로직을 리팩토링하거나 방금 배운 공식으로 풀 사이즈를 늘려야 할 명확한 타이밍입니다!

 

🧮 내 서버에 맞는 HikariCP 풀 사이즈 계산기

운영 중인 DB 서버의 스펙과 톰캣 스레드 설정을 입력하면, PostgreSQL/MySQL 권장 기준 및 데드락 방지 공식을 적용한 최적의 maximum-pool-size를 계산해 드립니다.

1. 데이터베이스(DB) 서버의 CPU 코어 수

2. 톰캣 최대 동시 요청 스레드 수 (Tn) * Spring Boot 기본값은 200입니다.

3. 단일 스레드가 동시에 요구하는 최대 커넥션 수 (Cm) * 일반적인 쿼리는 1. 부모-자식 트랜잭션 분리 등 특수 상황 시 2 이상.

📌 하드웨어 스펙 기반 권장 사이즈 (Core * 2 + 1)

-

🚨 데드락 방지를 위한 최소 마지노선 (Brett Wooldridge 공식)

-

-

 

4. 전문가의 확고한 결론 (Verdict)

커넥션 풀 사이즈 증설(Scale-up), 실무에 언제 도입하고 언제 피해야 할까요?

• 👍 늘려도 좋은 타이밍 (도입 권장): 분산 트랜잭션이 많거나 부득이하게 하나의 로직 내에서 부모-자식 트랜잭션이 분리되어 2개 이상의 커넥션을 동시에 점유해야 하는 상황이라면, 앞서 말씀드린 공식에 따라 데드락이 발생하지 않을 최소한의 안전선까지는 maximum-pool-size를 반드시 늘려주어야 합니다.
• 🛑 늘리는 것을 피해야 할 때 (도입 금지): 단순한 단일 조회/저장 쿼리인데 타임아웃 에러가 난다고 해서 풀 사이즈를 100개, 200개씩 무작정 늘리는 것은 절대 금물입니다. 이는 인프라의 근본적인 문제(DB의 슬로우 쿼리, 인덱스 누락, 비효율적인 N+1 쿼리)를 가려버리는 진통제에 불과합니다. 커넥션을 늘리기 전에 데이터베이스의 병목 지점을 찾고, 쿼리 튜닝과 트랜잭션 범위를 축소하는 것이 최우선 해결책입니다.

HikariCP는 여러분이 건드리지 않아도 될 만큼 이미 완벽에 가깝게 튜닝된 기본값을 제공합니다. 에러가 발생했다면 프레임워크의 설정을 의심하기 전에, 우리가 작성한 코드가 DB 커넥션을 낭비하고 있지 않은지 되돌아보는 것이 시니어 백엔드 개발자로 나아가는 첫걸음입니다.

 

항상 팩트에 기반한 객관적인 실무 가이드로 여러분의 삽질 시간을 줄여드리겠습니다. 다음 포스팅에서도 개발자들에게 유용한 도구 최적화 팁으로 찾아뵙겠습니다!