Backend

PostgreSQL 성능 튜닝 실전 가이드

한 줄 요약: PostgreSQL 성능 튜닝의 80%는 인덱스 설계, 쿼리 최적화, 커넥션 풀 설정에서 결정된다. PostgreSQL은 기본 설정만으로도 잘 동작하지만, 트래픽이 늘면 느려지기 시작한다. 성능 개선의 첫 단계: EXPLAIN ANALYZE. 이 명령으로 쿼리 실행 계획을 확인하고, Seq Scan(전체 스캔)이 발생하는 곳을 찾습니다.

by Lee발행: 2026-04-06

한 줄 요약: PostgreSQL 성능 튜닝의 80%는 인덱스 설계, 쿼리 최적화, 커넥션 풀 설정에서 결정된다.

PostgreSQL은 기본 설정만으로도 잘 동작하지만, 트래픽이 늘면 느려지기 시작한다. 이 가이드는 실전에서 가장 효과적인 성능 튜닝 전략을 단계별로 정리한다.

느린 쿼리 찾기

성능 개선의 첫 단계: EXPLAIN ANALYZE. 이 명령으로 쿼리 실행 계획을 확인하고, Seq Scan(전체 스캔)이 발생하는 곳을 찾습니다.

EXPLAIN ANALYZE는 성능 진단의 시작점이다. 느린 쿼리에 EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)를 붙여 실행 계획을 확인한다. Seq Scan(전체 스캔)이 보이면 인덱스 부족, Nested Loop가 대량 데이터에 사용되면 JOIN 전략 변경이 필요하다.

EXPLAIN ANALYZE 실전 예시
EXPLAIN (ANALYZE, BUFFERS)
SELECT u.name, COUNT(o.id)
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created_at > '2026-01-01'
GROUP BY u.name
ORDER BY COUNT(o.id) DESC
LIMIT 10;

-- Seq Scan on orders가 보이면:
CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at);

인덱스 설계 원칙: WHERE 절에 자주 사용되는 컬럼에 인덱스를 만든다. 복합 인덱스는 카디널리티가 높은 컬럼을 앞에 배치한다. 부분 인덱스(WHERE is_active = true)로 인덱스 크기를 줄인다. 사용되지 않는 인덱스는 INSERT/UPDATE 성능을 저하시키므로 정기적으로 제거한다.

인덱스 전략

인덱스는 만능이 아닙니다. 자주 검색하는 컬럼에 만들되, INSERT/UPDATE가 많은 테이블에서는 인덱스가 오히려 성능을 떨어뜨릴 수 있습니다. 복합 인덱스의 컬럼 순서가 중요합니다.

모니터링 도구

추천 모니터링 도구: pg_stat_statements(쿼리 통계), pgBadger(로그 분석), Datadog/Grafana(실시간 대시보드).

커넥션 풀 최적화

PostgreSQL의 기본 max_connections은 100이다. 서버리스 환경(Vercel, Lambda)에서는 각 함수 인스턴스가 커넥션을 생성하므로, 순식간에 한도에 도달한다. PgBouncer(커넥션 풀러)를 사이에 두면 수천 개의 요청을 수십 개의 실제 커넥션으로 처리할 수 있다. Supabase, Neon 등은 PgBouncer를 기본 포함한다.

핵심 설정 튜닝

서버 메모리 16GB 기준 권장 설정: shared_buffers = 4GB(전체 RAM의 25%), effective_cache_size = 12GB(전체 RAM의 75%), work_mem = 64MB(복잡한 정렬/해시에 사용), maintenance_work_mem = 1GB(VACUUM/CREATE INDEX에 사용). PGTune 도구로 서버 사양에 맞는 설정을 자동 생성할 수 있다.

운영 팁: pg_stat_statements 확장을 활성화하면 가장 많이 실행되거나 가장 느린 쿼리를 자동으로 추적할 수 있다. 주기적으로 상위 10개 쿼리를 확인하고 최적화하라.

1인 개발자 관점에서 이 주제가 왜 중요한가

이 글의 주제(PostgreSQL 성능 튜닝 실전 가이드)를 다룰 때 저는 슈퍼베이스 + 버셀 + 카프카 조합으로 1인 백엔드를 굴리는 입장 관점에서 봅니다. 단순히 새 기능을 소개하는 입장이 아니라, 12개 한국어 사이트를 1인으로 운영하면서 매일 클로드 코드를 켜두고 작업하는 입장이라 의사결정의 기준이 다소 좁고 실용적인 편입니다. 신기술이 출시될 때마다 곧바로 도입하기보다는 우선 한두 사이트에 시범 도입해 두고, 운영 부담이 늘지 않는지 며칠 지켜본 뒤 전체 확산을 결정하는 식입니다.

가장 자주 보는 변수는 1인 개발자의 현금흐름 한계, 그리고 한국 결제 시 VAT 10% 환급 절차입니다. 두 변수는 신기술을 도입할지 말지 결정할 때 거의 매번 영향을 줍니다. 글의 본문은 위의 두 축을 직접 명시하지는 않지만, 본문에서 다루는 항목을 이 축에 비춰 보시면 본인 환경에 맞는지 빠르게 판단할 수 있습니다. 특히 버셀 무료 티어 한도 vs 유료 전환 시점 같은 운영 변수는 도구 자체 성능보다 더 큰 영향을 주는 경우가 많기 때문에 본문 비교표를 볼 때 같이 떠올리시면 좋습니다.

한 가지 더 강조하면, Backend 영역의 글을 읽을 때 저는 본문이 다루는 도구·서비스가 ① 한국 결제 가능 여부 ② 한국어 응답 품질 ③ 종량제 비용의 예측 가능성 ④ 1인 개발자 학습 시간 대비 효과, 네 항목을 모두 충족해야 실제 도입을 결정합니다. 네 항목 중 하나라도 명확하지 않으면 도입을 1~2주 미루는 편이고, 그 사이 같은 카테고리의 다른 글도 확인합니다.

본문의 각 비교·코드·체크리스트는 이 네 항목 중 어느 부분에 영향을 주는지 의식하면서 보시면 더 빠르게 결론에 도달하실 수 있습니다. 본 사이트의 다른 Backend 글과 함께 보시면 같은 평가 축이 반복되는 것을 확인하실 수 있습니다. 토픽 페이지 또는 같은 카테고리 태그를 따라가시면 동일한 평가 기준이 적용된 글을 한 번에 모아 보실 수 있습니다.

본인 환경에 적용하기 전 확인할 체크포인트

본문의 내용을 본인 환경에 적용하기 전에 다음 항목을 빠르게 확인하시면 도입 실패 가능성을 줄일 수 있습니다.

공식 문서 버전 일치 — 본문 작성 시점과 현재 배포 버전이 다른 경우, 같은 명령어가 다르게 동작할 수 있습니다.
한국 결제·환율 검증 — 카드 결제, 부가가치세 처리, 원화 환산 시점에 따라 실제 청구액이 본문 예시와 다를 수 있습니다.
기존 스택과의 호환성 — Next.js·Vercel·Supabase 같은 기본 스택과 충돌이 없는지 패키지 의존성을 먼저 확인하세요.
롤백 절차 사전 정리 — 도입 후 문제가 생겼을 때 1회 명령으로 이전 상태로 되돌릴 수 있는 절차를 도입 전에 메모해 두시면 운영 부담이 크게 줄어듭니다.

위 네 항목을 모두 통과하면 보통 1~2시간 내에 도입을 마칠 수 있고, 통과하지 못한 항목이 있다면 그 항목을 우선 해결한 뒤 다시 시작하는 것이 효율적입니다.

자주 묻는 질문

가장 자주 발생하는 실수나 함정은 무엇인가요?

가장 흔한 실수는 느리다는 느낌만으로 인덱스를 마구 추가하는 것입니다. 인덱스는 SELECT를 빠르게 하지만 INSERT/UPDATE마다 갱신 비용이 붙어서, 쓰기가 많은 테이블에 인덱스를 남발하면 오히려 전체 성능이 떨어집니다. 반드시 EXPLAIN (ANALYZE, BUFFERS)로 Seq Scan이 실제로 찍히는 쿼리를 확인한 뒤, 그 컬럼에만 인덱스를 만드셔야 합니다. 복합 인덱스는 카디널리티가 높은 컬럼을 앞에 두는 순서가 핵심이고, 순서가 틀리면 인덱스가 있어도 안 탑니다. 또 하나 자주 놓치는 함정은 서버리스 환경의 커넥션 폭발입니다. Vercel이나 Lambda는 함수 인스턴스마다 커넥션을 새로 맺어 기본 max_connections 100을 순식간에 넘기므로, PgBouncer나 Supabase/Neon의 내장 풀러를 반드시 끼워야 합니다. 사용되지 않는 인덱스를 방치하는 것도 쓰기 성능을 갉아먹으니 정기 점검 대상입니다.

다른 대안과 비교했을 때 어떤 상황에 적합한가요?

여기서 다룬 튜닝은 데이터가 늘면서 쿼리가 느려지기 시작한, 즉 이미 PostgreSQL을 쓰고 있는 단계에 가장 적합합니다. EXPLAIN ANALYZE로 병목을 찾고 인덱스·커넥션 풀·설정을 손보는 접근은 트래픽이 수만 단위로 커지는 일반적인 웹 서비스 백엔드에 잘 맞습니다. 반대로 부적합한 경우도 있습니다. 인덱스와 work_mem을 아무리 만져도 단일 인스턴스의 한계를 넘는 초대용량·고동시성 쓰기라면 읽기 복제본(read replica) 분산이나 Citus 같은 샤딩, 또는 시계열에 특화된 별도 엔진을 검토해야 할 단계입니다. 또 서버리스 환경(Vercel·Lambda)에서 PostgreSQL을 쓴다면 이 글의 설정 튜닝보다 PgBouncer 같은 커넥션 풀러를 끼우는 것이 먼저이고, 관리 부담을 줄이고 싶다면 풀러를 기본 내장한 Supabase·Neon 같은 매니지드 서비스가 자체 튜닝보다 현실적인 선택입니다.

더 깊게 공부하려면 어떤 자료를 보면 좋을까요?

PostgreSQL 공식 문서의 두 챕터가 핵심입니다. 하나는 Using EXPLAIN 페이지로, 실행 계획에서 Seq Scan·Nested Loop·Hash Join을 읽는 법을 정확히 잡아줍니다. 다른 하나는 Server Configuration 챕터인데 shared_buffers·work_mem·effective_cache_size 같은 파라미터의 의미를 본문 권장값과 대조해 이해할 수 있습니다. 더 들어가려면 키워드로 인덱스 종류(B-tree·GIN·BRIN, 부분 인덱스, 커버링 인덱스)와 VACUUM·autovacuum 동작 원리를 추천합니다. 실측 진단은 pg_stat_statements 확장 문서가 필수이고, 설정값을 직접 잡기 어렵다면 본문에 링크한 PGTune으로 서버 사양에 맞는 초안을 받은 뒤 공식 문서로 각 값을 검증하는 순서가 안전합니다.

PostgreSQL 성능 튜닝 실전 가이드, 한 줄로 정리하면 어떻게 되나요?

성능 개선의 80%는 인덱스 설계·쿼리 최적화·커넥션 풀에서 결정됩니다. pg_stat_statements로 느린 쿼리를 측정하고, 그 쿼리에 EXPLAIN (ANALYZE, BUFFERS)를 붙여 Seq Scan과 대량 Nested Loop를 찾아 필요한 컬럼에만 인덱스를 만드는 것이 가장 효과 큰 순서입니다. shared_buffers·work_mem 같은 설정 튜닝은 그다음이고, 서버리스에서 DB를 쓴다면 이 모든 것에 앞서 PgBouncer 같은 커넥션 풀러부터 끼워야 한다는 게 결론입니다.

성능 튜닝, 어디서부터 손대야 하나요?

막연히 설정값부터 바꾸지 마시고, 가장 먼저 pg_stat_statements 확장을 켜서 실제로 어떤 쿼리가 느리고 자주 실행되는지부터 측정하시길 권합니다. 상위 10개 느린 쿼리를 찾았으면 그 각각에 EXPLAIN (ANALYZE, BUFFERS)를 붙여 Seq Scan이나 대량 데이터의 Nested Loop를 찾고, 필요한 인덱스를 추가하는 게 가장 효과가 큰 순서입니다. 본문에 적었듯 성능 개선의 80%는 인덱스 설계와 쿼리 최적화에서 나오기 때문에, shared_buffers나 work_mem 같은 설정 튜닝은 그다음입니다. 설정은 직접 감으로 잡기보다 PGTune에 서버 메모리와 코어 수를 넣어 권장값을 받은 뒤 적용하시면 안전합니다. 서버리스에서 DB를 쓴다면 이 모든 것에 앞서 커넥션 풀러부터 끼우셔야 합니다.

postgresql데이터베이스성능인덱스쿼리최적화