[Backend] DB 성능 최적화: 커넥션 풀(Connection Pool)과 HikariCP의 등장

1. 서론: 왜 속도가 중요할까?

학원 수업 중 강사님께서 "HikariCP가 DBCP보다 훨씬 빠르기 때문에 요즘은 무조건 이걸 쓴다"고 말씀하셨다. 단순히 "빠르다"고만 알고 넘어가기엔 백엔드 개발자로서 궁금증이 생겨, 정확히 무엇이 다르고 얼마나 차이가 나는지 정리해 보았다.

 

2. 커넥션 풀(Connection Pool)이란?

DB와 연결을 맺는 과정(Connection)은 꽤 무거운 작업이다.

비유하자면, 매번 통화할 때마다 전화선을 새로 설치하고(연결), 통화하고(SQL 실행), 선을 뽑는(종료) 것과 같다.

• 커넥션 풀이 없을 때: 요청마다 연결/해제를 반복하여 시간이 오래 걸림.
• 커넥션 풀(Connection Pool): 전화기(Connection) 10대를 미리 설치해두고, 요청이 오면 수화기만 빌려줬다가 다시 받아놓는 방식.

즉, 미리 생성해 둔 Connection을 빌려주고 반납받으며 재사용하는 공간이다.

 

3. HikariCP vs Commons DBCP

자바 진영에는 이 커넥션 풀을 관리해 주는 여러 라이브러리가 있는데, 대표적으로 과거에 많이 쓰던 Commons DBCP와 현재 표준인 HikariCP가 있다.

비교 항목	Commons DBCP (구형)	HikariCP (신형)
속도	상대적으로 느림	압도적으로 빠름
코드 크기	무거움	매우 가벼움 (Code base가 작음)
안정성	데드락 발생 가능성 존재	안정적임
사용처	과거 레거시 시스템	Spring Boot 2.0 이후 기본값

 

4. 핵심: 속도가 얼마나 차이 날까?

강사님 말씀대로 HikariCP는 압도적으로 빠르다. 벤치마크 테스트 결과(JMH)를 찾아보면 그 차이를 명확히 알 수 있다.

• 처리량(Throughput):
• 동일한 환경에서 초당 처리할 수 있는 요청 수를 비교했을 때, HikariCP는 다른 커넥션 풀(DBCP2, Tomcat 등) 대비 약 2배 이상의 성능을 보여준다.
• 응답 속도:
• Connection을 빌려오고 반납하는 과정(getConnection/close)에서 낭비되는 시간이 거의 없다.

[왜 이렇게 빠를까?]

1. Bytecode Level Engineering: 코드를 컴파일된 바이트코드 단위까지 최적화했다.
2. Micro optimizations: 불필요한 코드 라인을 극도로 줄였다. (실제로 HikariCP의 소스 코드는 다른 라이브러리보다 훨씬 짧고 간결하다.)
3. Collection 최적화: 연결 객체를 담아두는 리스트(List) 관리를 매우 효율적으로 처리하여 CPU 낭비를 줄였다.

 

5. 결론 및 요약

• 커넥션 풀은 DB 연결 비용을 아끼기 위해 미리 연결을 만들어두는 기술이다.
• 과거에는 Commons DBCP를 썼지만, 현재는 더 가볍고 2배 이상 빠른 HikariCP가 표준이다.
• 스프링 부트(Spring Boot) 2.0부터는 별도 설정이 없으면 자동으로 HikariCP를 사용한다.