[3회차] Connection Pool, 어떻게 동작하고 어떻게 설정해야 할까? - DBCP와 HikariCP의 차이부터 적정 Pool 사이즈 공식까지

[github-actions[bot]]

🚀 발표 주제

Connection Pool, 어떻게 동작하고 어떻게 설정해야 할까? - DBCP와 HikariCP의 차이부터 Pool 사이즈 실험까지

---

📅 발표일

2026-06-15

🙋 발표자

로지

🗂️ 카테고리

💾 Database

📚 발표 자료

업로드 예정

🎥 발표 영상

업로드 예정

---

🎯 핵심 개념 요약

Connection Pool이란?

DB 연결을 매 요청마다 새로 만들지 않고, 미리 여러 개 만들어 풀에 보관해뒀다가 빌려주고 반납받아 재사용하는 기법이다. DB 연결 생성 과정(TCP 3-way handshake → DB 인증 → 세션 초기화)이 비싸기 때문에 필요하다.

DBCP1 → DBCP2 → HikariCP 발전 흐름

1. DBCP1: 커넥션을 꺼낼 때 전체 Pool에 단일 Lock → 나머지 스레드 전부 대기
2. DBCP2: 연결별 독립 Lock으로 개선 → 여러 스레드 동시 접근 가능
3. HikariCP: Lock 자체를 없애고 CAS(Compare-And-Swap) 방식 도입 → Context Switching 없음

HikariCP ConcurrentBag 3단계 전략

커넥션을 가져올 때 아래 순서로 탐색한다.

1. ThreadLocal: 내가 마지막에 사용했던 커넥션 목록을 먼저 확인 → 경합 자체가 없어 가장 빠름
2. CopyOnWriteArrayList + CAS: 공유 Pool에서 CAS 연산으로 원자적으로 커넥션 획득 시도
3. SynchronousQueue: Pool이 완전히 비었을 때만 사용 → 반납 즉시 직접 전달

적정 Pool 사이즈 공식

connections = (core_count × 2) + effective_spindle_count

Pool 사이즈가 너무 크면 DB 서버에서 Context Switching이 증가해 오히려 성능이 저하된다.

🔗 미션과의 연결

방탈출 예약 대기 미션에서 다뤘던 예약 대기 자동 승격처럼 동시에 여러 요청이 들어올 때, Pool에서 커넥션을 어떻게 가져오는지가 실제 성능에 직결된다. 특히 maximumPoolSize를 기본값(10)보다 무작정 크게 설정하면 오히려 DB 서버에 부하가 생길 수 있다.

📚 참고 자료

1. Apache Commons DBCP 공식 문서
2. HikariCP GitHub 공식 문서
3. HikariCP Pool 사이즈 공식 문서
4. HikariCP ConcurrentBag 소스코드

---

🙋‍♀️ 질문

Q1. Connection Pool 없이 매 요청마다 DB 연결을 새로 만든다면 어떤 과정을 거치게 될까요? 그 과정이 왜 비용이 크다고 할 수 있을까요?
Q2. DBCP1에서 Thread A가 커넥션을 꺼내는 순간 나머지 Thread B, C가 대기 상태가 되는 이유는 무엇일까요?
Q3. HikariCP가 커넥션을 가져올 때 가장 먼저 ThreadLocal을 확인하는 이유는 무엇일까요?

[2Jaeheon]

Q1. Connection Pool 없이 매 요청마다 DB 연결을 새로 만든다면 어떤 과정을 거치게 될까요? 그 과정이 왜 비용이 크다고 할 수 있을까요?

DB 연결을 새로 만들 때마다 TCP handshake + DB Session 을 생성 + memory에 socket 생성 등을 매 순간마다 해야하며,
이 오버헤드가 매 connection 마다 생성되므로 매우 비효율적임.

---

Q2. DBCP1에서 Thread A가 커넥션을 꺼내는 순간 나머지 Thread B, C가 대기 상태가 되는 이유는 무엇일까요?

DBCP1에서 ThreadA가 커넥션을 꺼내는 순간 ConnectionPool 전체에 Lock이 걸리고 B, C는 대기 상태가 된다.

---

Q3. HikariCP가 커넥션을 가져올 때 가장 먼저 ThreadLocal을 확인하는 이유는 무엇일까요?

캐싱을 위해서이다.

HikariCP 내부의 ConcurrentBag은 커넥션을 빌릴 때 먼저 현재 스레드의 ThreadLocal 목록을 확인함.
만일 이전에 이 스레드가 반납한 커넥션 후보가 거기 있을 수 있기 때문인데,존재하면 공유 풀 전체를 뒤지거나 다른 스레드와 경쟁하지 않고,
상태만 NOT_IN_USE → IN_USE로 바꿔 바로 가져올 수 있어 효율적임

즉, 지역 캐싱 + 가능성이 높은 빠른 경로 최적화이다.

다만 이는 보장이 아닌, 후보를 추려내는 과정이기 때문에 HikariCP의 커넥션은 여전히 풀 전체의 자원이고,
ThreadLocal은 먼저 확인하는 지역 후보 목록에 가깝다고 볼 수 있음.

ThreadLocal에 있는 커넥션이 항상 사용 가능한 것은 아니므로 상태를 CAS로 확인한 뒤 실패하면 공용 풀을 탐색하여 connection을 점유함.

[wontop02]

Q1. Connection Pool 없이 매 요청마다 DB 연결을 새로 만든다면 어떤 과정을 거치게 될까요? 그 과정이 왜 비용이 크다고 할 수 있을까요?

커넥션 풀이 없다면 매 연결마다 '네크워크 연결 -> DB 인증 -> DB 내부 리소스 할당 -> 쿼리 실행 및 결과 반환 -> 연결 종료' 과정이 필요합니다.
트래픽이 몰릴 경우, DB가 수많은 연결 요청을 맺고 끊는 과정에서 서버가 다운될 수 있습니다.

Q2. DBCP1에서 Thread A가 커넥션을 꺼내는 순간 나머지 Thread B, C가 대기 상태가 되는 이유는 무엇일까요?

DBCP1은 커넥션 풀을 관리할 때, 풀 전체에 대한 락을 걸었습니다. 그래서 스레드 A가 커넥션 풀을 사용하는 동안, B와 C는 A의 작업을 마칠 때까지 커넥션 풀을 사용할 수 없습니다.

Q3. HikariCP가 커넥션을 가져올 때 가장 먼저 ThreadLocal을 확인하는 이유는 무엇일까요?

스레드간 락 경합을 줄이기 위해서입니다. 커넥션을 사용하고 반납할 때 ThreadLocal로 캐싱을 하고, 다음에 커넥션이 또 필요할 때 캐시에 남아있던 커넥션을 우선으로 사용합니다.

[Soojin6943]

Q1. Connection Pool 없이 매 요청마다 DB 연결을 새로 만든다면 어떤 과정을 거치게 될까요? 그 과정이 왜 비용이 크다고 할 수 있을까요?

DB 연결의 경우 네트워크를 통해 연결하다보니 높은 비용이 발생합니다. SQL을 처리하기 위해 TCP 연결 생성 -> 인증 -> 세션 생성 -> 사용 후 연결 끊기 의 과정을 수행합니다.

실제 sql 수행보다 커넥션 생성 비용이 더 큰 경우가 많다보니 매번 커넥션을 생성하는 것은 비효율적입니다.

Q2. DBCP1에서 Thread A가 커넥션을 꺼내는 순간 나머지 Thread B, C가 대기 상태가 되는 이유는 무엇일까요?

커넥션 풀 전체를 하나의 락으로 관리하기 때문에 A가 커넥션을 사용한다면 B, C는 대기 상태가 됩니다.

Q3. HikariCP가 커넥션을 가져올 때 가장 먼저 ThreadLocal을 확인하는 이유는 무엇일까요?

쓰레드 로컬은 현재 쓰레드만 접근할 수 있는 본인만의 저장공간이라 락이 필요없고, 경쟁이 없습니다. 만약 이전에 사용한 커넥션을 사용하고 있는 쓰레드가 없다면 락 없이 즉시 커넥션을 획득할 수 있기 때문에 쓰레드 로컬을 가장 먼저 확인합니다.

[MODUGGAGI]

Q1. Connection Pool 없이 매 요청마다 DB 연결을 새로 만든다면 어떤 과정을 거치게 될까요? 그 과정이 왜 비용이 크다고 할 수 있을까요?

1. DB 서버와의 TCP 연결 과정
2. DB 인증
3. DB 세션 초기화

과정을 매번 거치기 때문에 매 요청마다 DB와 새로운 연결을 생성해야 합니다.
이 과정 속 위의 3가지 단계를 반복적으로 수행하게 되므로 네트워크 왕복 비용과 서버 자원 사용량이 증가합니다.
또한 DB 입장에서도 연결 생성과 해제를 계속 처리해야 하므로 전체 성능이 저하될 수 있습니다.

Q2. DBCP1에서 Thread A가 커넥션을 꺼내는 순간 나머지 Thread B, C가 대기 상태가 되는 이유는 무엇일까요?

• DBCP1은 커넥션 단일 Pool Lock 방식이기 때문에 특정 스레드 A가 커넥션 풀에서 커넥션을 사용하게 되면 커넥션 풀에 락이 걸려서 나머지 스레드들은 해당 락이 풀릴 때까지(A가 커넥션 사용을 완료할 때까지) 대기 상태가 됩니다.

Q3. HikariCP가 커넥션을 가져올 때 가장 먼저 ThreadLocal을 확인하는 이유는 무엇일까요?

• 가장 최근에 자신의 스레드에서 사용한 커넥션을 점유할 수 있나 확인하기 위해서입니다.
• 자신의 스레드에서 최근에 사용한 커넥션은 다른 커넥션들에 비해 상대적으로 다른 스레드가 사용중일 가능성이 낮기 때문에 ThreadLocal에 캐싱된 커넥션을 우선적으로 점유하려 시도합니다.

[Jiihyun]

Q1. Connection Pool 없이 매 요청마다 DB 연결을 새로 만든다면 어떤 과정을 거치게 될까요? 그 과정이 왜 비용이 크다고 할 수 있을까요?

요청이 들어올 때마다 새로운 DB 연결을 생성하면, 이 과정에서

1. DB 서버와 TCP 소켓 연결을 맺고
2. TCP 연결을 수행하고
3. DB 계정 인증 및 세션 생성 과정을 거쳐야 한다.

이러한 네트워크 왕복과 인증 과정은 수 ms~수십 ms의 비용이 발생하며, 요청마다 반복되면 응답 시간이 증가하고 DB 서버에도 큰 부하를 주게 된다.

Q2. DBCP1에서 Thread A가 커넥션을 꺼내는 순간 나머지 Thread B, C가 대기 상태가 되는 이유는 무엇일까요?

여러 스레드가 동시에 풀의 상태(사용 가능한 커넥션 목록, 사용 중인 커넥션 수 등)를 수정하면 데이터가 깨질 수 있기 때문에 DBCP1은 synchronized로 한 번에 하나의 스레드만 접근하도록 설계되어있다.
따라서 락을 획득하지 못한 스레드는 BLOCKED 상태로 대기하게 된다.

Q3. HikariCP가 커넥션을 가져올 때 가장 먼저 ThreadLocal을 확인하는 이유는 무엇일까요?

HikariCP는 락 경쟁을 최소화하고 더 빠르게 커넥션을 획득하기 위해 먼저 ThreadLocal을 확인한다.
자신의 스레드에서 최근에 사용한 커넥션은 다른 스레드가 사용중일 가능성이 낮기 때문에, 해당 스레드가 사용했떤 커넥션이 ThreadLocal에 남아 있다면, 공유 자료구조를 조회하지 않고 바로 재사용할 수 있다.
이렇게 하면 여러 스레드가 동시에 접근하는 공유 자원에 대한 경쟁을 줄일 수 있고, CAS 연산이나 탐색 비용도 줄어들어 커넥션 획득 성능이 향상된다.