요즘같이 데이터가 넘쳐나는 시대에 백엔드만 잘한다고 끝이 아니죠. 진짜 실력 있는 풀스택 개발자는 백엔드 API와 프론트 UI만 다루는 게 아니라, 느려터진 쿼리 하나도 직접 고치고, DB 성능까지 챙길 줄 알아야 해요. 특히 PostgreSQL을 쓰는 서비스라면, 제대로 된 쿼리 튜닝은 선택이 아니라 ‘생존’입니다. 단 몇 줄의 SQL이 서버를 멈추게 만들 수도 있고, 반대로 수천만 건을 단 몇 초만에 조회할 수도 있거든요. 이 글에서는 단순한 EXPLAIN이나 인덱스 개념을 넘어, 실무에서 진짜 써먹을 수 있는 고급 쿼리 튜닝 테크닉을 낱낱이 정리해봅니다. 어렵게만 느껴졌던 튜닝, 이제는 손에 잡히는 무기가 될 거예요.
- 실행 계획(EXPLAIN ANALYZE)을 통해 문제 쿼리를 정확히 진단하는 방법을 배웁니다.
- 인덱스의 종류와 쓰임새, 그리고 실전에서 언제 어떻게 쓰면 좋은지 구체적으로 살펴봅니다.
- SQL 쿼리 자체를 바꿔서 속도를 개선하는 여러 가지 실전 패턴을 소개합니다.
- PostgreSQL 설정 파일에서 수정할 수 있는 성능 관련 파라미터들을 하나하나 짚어봅니다.
- 실무 고수들이 자주 사용하는 진짜 고급 튜닝 기법들을 예제로 정리합니다.
1. 실행 계획을 모르면, 튜닝은 시작도 못 한다
“EXPLAIN ANALYZE 한 번 안 돌려보고 성능 얘기하지 말자.” 개발자들끼리 우스갯소리처럼 하는 말이지만, 진심 100% 담긴 조언이에요. PostgreSQL은 쿼리를 실행할 때마다 내부적으로 최적의 계획을 짭니다. 그게 바로 실행 계획이에요. 우리가 EXPLAIN으로 보는 그 플랜이죠.
여기서 중요한 건 단순히 어떤 인덱스를 썼는지가 아니라, 왜 Seq Scan이 나왔는지, 왜 Nested Loop을 탔는지, 예상 row 수치가 실제와 얼마나 차이나는지 등을 꼼꼼히 읽어야 한다는 거예요. 예를 들어, 쿼리에서 user_id를 조건으로 줬는데도 Index Scan이 안 나왔다면? 인덱스가 없거나, 통계가 잘못되었거나, 아니면 planner가 Seq Scan이 더 낫다고 판단한 겁니다.
바로 이럴 때 `ANALYZE` 명령으로 통계를 다시 수집하거나, 인덱스를 새로 추가해주면 쿼리 성능이 확 달라질 수 있어요. 이건 말 그대로 ‘눈으로 직접 보는 디버깅’이라, 어느 정도 익숙해지면 실전에서 엄청난 무기가 됩니다.
실행 계획 읽을 때 꼭 확인할 포인트
- 예측 row와 실제 처리 row 차이
- 불필요한 Nested Loop 발생 여부
- 조인 시 키 컬럼에 인덱스가 있는지
- 정렬/그룹 연산으로 인한 Disk Sort 유무
2. 인덱스의 세계는 생각보다 훨씬 깊습니다
보통 인덱스라고 하면 B-Tree만 떠올리지만, PostgreSQL은 그보다 훨씬 다양한 인덱스 옵션을 제공합니다. 특히 서비스에서 특정 조건으로 자주 조회가 들어올 경우엔 Partial Index나 Expression Index를 잘 활용하면 대박이에요.
| 인덱스 종류 | 설명 | 활용 팁 |
|---|---|---|
| B-Tree | 가장 일반적인 인덱스 방식 | 대부분의 비교 연산(=, <, >)에 적합 |
| Partial Index | 조건이 붙은 특정 행만 인덱싱 | 자주 조회되는 조건(status = ‘ACTIVE’ 등)에 유리 |
| Expression Index | LOWER(), TRIM() 등 표현식 기반 인덱스 | 함수를 자주 쓰는 검색 조건에 활용 |
인덱스는 많다고 좋은 게 아닙니다. 너무 많으면 INSERT나 UPDATE가 느려지고, 디스크 공간도 낭비하죠. 실제로 성능 로그를 보면, 쿼리는 Index Scan인데도 느린 경우가 있어요. 그건 인덱스 탐색보다 테이블 접근 비용이 더 많이 드는 경우예요. 이럴 땐 covering index를 고려해보는 것도 좋죠.
3. 쿼리 작성 습관이 성능을 좌우한다
풀스택 개발자들이 ORM만 믿고 방심할 때 자주 마주치는 게 바로 N+1 문제입니다. 반복문 안에서 매번 SELECT 날리는 코드 보신 적 있죠? 이건 데이터베이스 입장에선 지옥이에요. 한 번에 조인해서 가져오면 될 걸 수십 번 호출하게 되니까요.
또한 LIKE ‘%keyword%’는 무조건 느립니다. 인덱스를 못 타요. 이런 경우엔 pg_trgm 확장이나 Full Text Search를 쓰는 게 훨씬 낫습니다. OR 조건도 마찬가지. 여러 조건이 OR로 묶이면 planner는 그걸 효율적으로 처리하기 어려워서 쿼리 속도가 확 떨어지죠. UNION으로 쿼리를 분리해버리면 각 조건별로 인덱스도 타고 속도도 빨라져요.
현장에서 자주 쓰는 튜닝 꿀팁
- SELECT 대상 컬럼만 인덱스에 다 포함되게 설정 → Index Only Scan 가능
- 쿼리 전 SET work_mem으로 정렬 메모리 조정 → Disk Sort 방지
- 다중 조건일 땐 조건 순서 조정 → planner의 선택 유도
4. PostgreSQL 설정도 개발자의 영역입니다
보통 이런 건 DBA만 신경 쓰는 줄 알지만, 요즘은 다들 DevOps 시대잖아요. 특히 작은 팀에선 개발자가 DB 설정도 봐야 할 일이 많아요. 가장 먼저 알아야 할 건 work_mem입니다. 이건 쿼리 하나가 정렬이나 해시 작업할 때 쓸 수 있는 메모리양인데요, 너무 작으면 무조건 디스크를 쓰게 돼서 느려져요. 너무 크면 서버 전체 메모리를 다 잡아먹죠.
그 다음은 pg_stat_statements 같은 확장 도구예요. 이걸 켜두면 어떤 쿼리가 가장 느리고, 얼마나 자주 호출되는지를 볼 수 있어요. 저는 개인적으로 가장 좋아하는 튜닝 툴입니다. 한 번 써보면 성능 이슈를 눈으로 잡아내는 맛에 중독될지도 몰라요.
5. 진짜 고급 튜닝: 힌트와 파티션, 그리고 VACUUM
이건 약간 레벨업한 내용인데요, 실무에서 자주 쓰이는 테크닉 중 하나가 pg_hint_plan 확장이에요. PostgreSQL은 기본적으로 힌트를 안 받아요. 무조건 planner가 최적 플랜을 짜도록 돼 있죠. 그런데 planner가 바보처럼 Seq Scan만 고집할 때는 우리가 직접 “야, 이건 Index Scan 해!”라고 알려줄 수도 있어요.
그리고 데이터가 너무 많아졌다면 테이블 파티셔닝을 고려할 때입니다. 특히 날짜별 파티셔닝은 대용량 로그나 트랜잭션 데이터에 효과적이에요. 단점은 설계가 복잡해지고 관리가 어려워진다는 점. 그래서 어느 시점에 이걸 도입할지 신중히 결정해야 해요.
마지막으로, 진짜 많이 놓치는 게 VACUUM이에요. PostgreSQL은 MVCC 구조라서 데이터를 지워도 실제로는 안 지워요. Dead Tuple이 쌓이죠. 이걸 안 치우면 성능이 점점 떨어집니다. 자동으로 도는 autovacuum이 있지만, 그걸 믿고 있다가 낭패 보는 경우가 많아요. 대량 변경이 일어났다면 수동 VACUUM 해줘야 쿼리가 살아나요.
마무리하며 – 개발자에게 쿼리 튜닝이란?
풀스택 개발자에게 쿼리 튜닝은 단순한 퍼포먼스 개선이 아니에요. 전체 시스템의 흐름을 이해하고, 어떤 부하가 어디서 생기는지를 몸으로 느끼는 과정이죠. 이 글에서 소개한 PostgreSQL 고급 튜닝 기법들은 실무에서 바로 써먹을 수 있는 내용들이에요. 처음엔 낯설고 복잡해 보일 수 있지만, 한두 개씩 적용하다 보면 어느새 서비스가 날아다니는 걸 보게 될 거예요.
다음에 쿼리가 느리다는 말이 들리면, 자신 있게 “EXPLAIN ANALYZE 해봤어?”라고 묻는 개발자가 되어보세요. 여러분의 DB도, 팀의 성능도 한 단계 올라갈 겁니다 🚀