커넥션 풀, 몇 개로 설정해야 할까? 아키텍처가 알아야 할 3가지 기준

안녕하세요. 웹과 앱 서비스를 직접 만들고 운영하는 개발사 에그코드입니다.

"커넥션 풀, 몇 개로 잡을까요?"

서비스를 만들다 보면 반드시 마주치는 질문입니다.

그런데 이 답을 '감'으로 정하는 경우가 의외로 많습니다.

"넉넉하게 100개?", "트래픽 많으니까 200개?"처럼요.

결론부터 말씀드리면, 커넥션 풀은 많이 잡는다고 빨라지지 않습니다.

오히려 잘못 잡으면 평소엔 멀쩡하다가 트래픽이 몰릴 때 한 번에 무너집니다.

오늘은 비개발자 담당자도 큰 그림을 잡을 수 있게, 커넥션 풀의 기본과 함정, 그리고 개수를 정하는 3가지 기준을 정리해 드리겠습니다.

커넥션 풀이 뭐길래 — 30초 정리

먼저 용어부터 짚겠습니다.

커넥션(connection)은 우리 서비스(앱·웹 서버)와 데이터베이스(DB)를 잇는 '통화 연결선'입니다.

그런데 이 연결을 매번 새로 만드는 건 생각보다 비쌉니다.

연결할 때마다 인증하고 세션을 준비하는 절차를 다시 밟아야 하기 때문입니다.

그래서 연결을 미리 몇 개 열어 두고, 빌려 쓰고 반납하는 방식을 씁니다.

이 '미리 열어둔 연결 묶음'이 바로 커넥션 풀(connection pool)입니다.

은행 창구를 떠올리면 쉽습니다.

손님(요청)은 수백 명이 몰려도, 창구(연결)는 정해진 수만큼만 엽니다.

→ 그래서 핵심 질문은 자연스럽게 "창구를 몇 개 열 것인가"가 됩니다.

'많을수록 좋다'는 착각부터 버리자

가장 흔한 오해가 여기서 나옵니다.

"연결이 많으면 동시에 더 많이 처리하니까 빠르겠지?"

직관적으로는 맞는 말 같지만, 실제로는 틀립니다.

연결 수가 어느 지점을 넘으면 처리량은 더 오르지 않고, 오히려 떨어집니다.

이유는 단순합니다.

DB 서버의 CPU 코어가 한 번에 처리할 수 있는 일의 양은 정해져 있습니다.

연결만 잔뜩 늘리면, DB는 일을 빨리 하는 게 아니라 '여러 일 사이를 왔다 갔다' 하느라 시간을 씁니다.

여기에 락(lock) 경쟁 — 같은 데이터를 여러 연결이 동시에 건드릴 때 생기는 순서 다툼 — 까지 겹칩니다.

실제로 한 사례에서는 커넥션을 수천 개에서 수십 개로 줄였더니 응답이 더 빨라졌습니다.

→ 즉, 커넥션 풀 크기는 '많이'가 아니라 '적정'을 찾는 문제입니다.

아키텍처가 알아야 할 커넥션 풀의 기본과 함정

이제 핵심입니다.

시스템 전체를 설계하는 입장에서 커넥션 풀을 볼 때, 기본 원칙은 한 줄로 정리됩니다.

풀 크기는 '요청이 몇 건 들어오느냐'가 아니라, 'DB가 동시에 진짜 처리할 수 있는 양'에 맞춥니다.

이 원칙을 놓치면 아래 4가지 함정에 그대로 빠집니다.

함정 1. 인스턴스 곱셈을 잊는다

커넥션 풀은 보통 '서버 1대(인스턴스)당' 설정됩니다.

풀을 50개로 잡고 서버를 10대로 늘리면, DB에는 최대 500개의 연결이 요청됩니다.

DB가 감당하는 한도가 100개라면, 나머지 요청은 그대로 거부됩니다.

오토스케일링으로 서버가 자동으로 늘어나는 환경이라면 더 위험합니다.

함정 2. 서버리스에서 연결이 폭증한다

AWS Lambda 같은 서버리스 환경에서는 요청이 몰리면 인스턴스가 수백 개로 복제됩니다.

각 인스턴스가 저마다 연결을 열면, DB 연결이 순식간에 폭증합니다.

이때는 풀 크기 조정만으로 안 되고, 연결을 한 번 모아 주는 '커넥션 풀러(PgBouncer, RDS Proxy, Supabase 풀러 등)'가 따로 필요합니다.

함정 3. 숨은 소비자를 빼먹는다

DB 연결을 쓰는 건 우리 앱만이 아닙니다.

데이터 이전(마이그레이션), 배치 작업, 백오피스 관리 도구, 모니터링 시스템도 같은 DB의 연결을 나눠 씁니다.

풀 크기를 계산할 때 이들을 빼먹으면, 평소엔 괜찮다가 배치가 도는 시간에 한도가 터집니다.

함정 4. 풀 고갈과 좀비 연결

연결을 빌려 쓰고 제때 반납하지 않으면, 풀이 비어 버립니다(풀 고갈).

그러면 다른 요청들은 연결을 기다리다 타임아웃으로 실패합니다.

반대로, 끊어진 연결을 정리하지 않으면 '좀비 연결'이 풀을 차지한 채 남습니다.

그래서 유휴 연결을 정리하는 시간(idle timeout)과 연결 최대 수명 설정도 함께 챙겨야 합니다.

그래서 몇 개로 잡아야 할까 — 3가지 기준

이제 실제로 숫자를 정하는 기준입니다.

복잡한 공식보다, 다음 3가지 순서로 접근하면 큰 실수는 피할 수 있습니다.

기준 ① 서버 코어 수가 상한선이다

HikariCP와 PostgreSQL 위키가 권하는 출발점 공식이 있습니다.

커넥션 수 ≈ (코어 수 × 2) + 디스크 수

4코어에 SSD를 쓰는 서버라면 (4 × 2) + 1 = 약 9개입니다.

생각보다 훨씬 작은 숫자라 당황스러울 수 있습니다.

하지만 이건 'CPU가 진짜 동시에 할 수 있는 일의 양'에서 나온 값입니다.

이 공식은 정답이 아니라, 측정을 시작할 기준값으로 보면 됩니다.

→ 큰 숫자로 시작하기보다, 작게 잡고 필요할 때 늘리는 편이 안전합니다.

기준 ② DB 최대 연결 수에서 거꾸로 계산하라

DB에는 받아들일 수 있는 최대 연결 수(max_connections)가 정해져 있습니다.

PostgreSQL 기본값은 100, MySQL은 151 정도입니다.

이 한도에서 거꾸로 내려와야 합니다.

예를 들어 한도가 100이고 운영 도구용으로 20개를 비워 둔다면, 80개를 앱이 나눠 씁니다.

앱 서버가 10대라면, 인스턴스당 풀은 8개 정도가 상한입니다.

오토스케일링이 켜져 있다면 '최대로 늘어났을 때의 대수'로 계산해야 합니다.

→ 풀 크기 × 인스턴스 수가 DB 한도를 넘지 않게. 이게 안 깨지는 1번 규칙입니다.

기준 ③ 추측하지 말고, 측정해서 조정하라

마지막은 가장 중요하지만 자주 건너뛰는 단계입니다.

공식과 역산으로 '시작값'을 잡았다면, 이제 실제 부하에서 지켜봐야 합니다.

연결을 기다리는 대기 시간이 길어지는지, 풀 사용률이 꽉 차는지를 봅니다.

만약 대기 줄이 길다면, 풀을 늘리기 전에 '느린 쿼리'부터 의심하는 게 맞습니다.

대부분의 풀 고갈은 풀이 작아서가 아니라, 쿼리가 연결을 너무 오래 붙잡고 있어서 생기기 때문입니다.

→ 숫자를 키우는 것보다, 병목을 찾는 게 먼저입니다.

정답은 없습니다, 그래서 설계가 중요합니다

커넥션 풀에는 '모든 서비스에 맞는 정답 숫자'가 없습니다.

서버 사양, 쿼리 성격, 인스턴스 수, 트래픽 패턴에 따라 적정값이 달라지기 때문입니다.

다만 길을 잃지 않는 세 가지 기준은 분명합니다.

코어 수에서 상한을 잡고, DB 한도에서 역산하고, 측정하며 조정하는 것입니다.

그리고 무엇보다, 인스턴스 곱셈을 잊지 않는 것.

에그코드는 이런 DB·서버 구조를 직접 서비스를 운영하며 다져 온 개발사입니다.