타임아웃이 나면 커넥션 풀부터 늘리는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-11-07

#백엔드 #트러블슈팅 #성능

트래픽이 조금만 몰려도 커넥션 타임아웃 에러가 뜹니다. 로그 창에 500 에러가 쏟아지기 시작하면 머릿속이 하얘집니다.

이때 많은 개발자가 가장 먼저 하는 일이 있습니다. 설정 파일을 열어 HikariCP의 최대 풀 크기를 올리는 것입니다. 10을 30으로 바꾸고, 그래도 불안하면 50이나 100으로 올립니다.

잠깐은 에러가 멎은 것처럼 보입니다. 하지만 사용자가 조금 더 유입되는 순간, 이번에는 DB 서버의 CPU가 100%를 찍으며 데이터베이스 자체가 완전히 뻗어버립니다. 커넥션을 넉넉하게 늘려주었는데 시스템은 왜 더 처참하게 무너졌을까요?

커넥션은 많을수록 좋은 창구가 아닙니다

많은 주니어 개발자가 데이터베이스 커넥션 풀을 은행 창구처럼 생각합니다. 창구를 100개로 늘리면 손님 100명을 동시에 응대할 수 있으니 무조건 빠를 것이라는 착각입니다.

현실의 데이터베이스는 마법을 부리지 않습니다. 서버의 CPU 코어 수는 한정되어 있습니다. 4코어짜리 DB 서버에 커넥션 100개가 동시에 쿼리를 쏟아내면 무슨 일이 일어날까요?

4개의 일꾼이 100개의 요청 사이를 쉴 새 없이 오가며 컨텍스트 스위칭만 반복합니다. 정작 쿼리를 연산하는 시간보다 일꾼이 자리를 바꾸는 비용이 더 커집니다. 커넥션을 늘릴수록 처리량이 늘어나는 것이 아니라, 응답 지연이 기하급수적으로 늘어납니다.

200명이 넘는 백엔드 개발자들을 멘토링하면서 커넥션 고갈을 겪은 프로젝트를 수없이 만났습니다. 그중에서 커넥션 풀 크기가 진짜 작아서 장애가 난 경우는 5%도 되지 않았습니다.

나머지 95%의 원인은 하나였습니다. 커넥션을 너무 오래 쥐고 놓아주지 않은 것입니다.

인덱스가 누락된 쿼리가 테이블 풀 스캔을 돌며 커넥션을 3초 동안 독점합니다. 더 심각한 상황은 트랜잭션 안에서 외부 결제 API나 알림 발송을 호출하는 코드입니다.

외부 서버가 응답하는 1초 동안 내 애플리케이션의 커넥션 하나가 꼼짝없이 묶입니다. 초당 요청이 20개만 들어와도 10개짜리 풀은 0.5초 만에 동납니다. 이런 구조에서는 풀 크기를 100으로 늘려봤자 5초 뒤에 똑같이 터집니다.

커넥션 타임아웃이 터졌을 때 가장 먼저 열어야 할 것은 설정 파일이 아닙니다. 슬로우 쿼리 로그와 트랜잭션의 범위입니다.

트랜잭션이 커넥션을 점유하는 시간을 0.1초에서 0.01초로 줄이면 어떻게 될까요? 커넥션 풀이 10개만 있어도 초당 1,000개의 요청을 병목 없이 소화합니다. PostgreSQL과 HikariCP 공식 문서가 작은 커넥션 풀을 권장하는 이유입니다.

커넥션 풀을 무작정 늘리는 행위는 빚을 갚기 위해 또 다른 사채를 끌어다 쓰는 것과 같습니다. 커넥션을 얼마나 많이 쥐고 있느냐가 아니라, 얼마나 빠르게 반납하느냐가 시스템의 체급을 결정합니다.

설정 파일의 숫자부터 손대지 마십시오. 코드 안에서 커넥션이 어디에 발이 묶여 숨을 헐떡이고 있는지부터 찾아내시기 바랍니다.