당신의 애플리케이션, 왜 느릴까? Postgres 성능을 500배 향상시킨 반직관적 진실 4가지

Bro's Insights
1

당신의 애플리케이션은 왜 느릴까?

Postgres 성능을 500배 향상시킨 반직관적 진실 4가지

느린 애플리케이션의 진짜 범인을 찾아서

“애플리케이션이 왜 이렇게 느리지?”

개발자라면 누구나 한 번쯤 던져봤을 질문입니다. 우리는 보통 애플리케이션 로직이나 네트워크 문제를 의심하지만, 진짜 범인은 예상치 못한 곳에 숨어있습니다. 바로 데이터베이스죠.

특히 ORM을 사용하면 복잡한 SQL 쿼리가 단순한 코드 뒤에 감춰지기 때문에 이 사실을 놓치기 쉽습니다.

이 글에서는 Postgres 쿼리 성능에 대한 놀랍고 반직관적인 인사이트를 공유하려고 합니다. 이 글을 다 읽고 나면, 성능 문제의 근본 원인을 진단하고 해결하는 새로운 시각을 얻게 되실 거예요.

기억하세요: Database Performance = Application Performance

:light_bulb: 인사이트 1: 애플리케이션의 속도는 곧 데이터베이스의 속도

애플리케이션 성능은 데이터베이스 성능에 직접적으로 의존합니다. 많은 개발자들이 이 단순한 진실을 간과하는데요, 그 이유는 바로 ORM 때문입니다.

ORM은 복잡한 SQL 쿼리를 마법처럼 간단한 함수 호출로 바꿔줍니다.

예를 들어볼까요?

user.backends.first

Ruby on Rails에서 이렇게 한 줄로 쓰는 코드가, 내부적으로는 여러 테이블을 조인하는 복잡한 SQL 문을 생성할 수 있습니다. 개발자에게는 간단한 함수 호출처럼 보이지만, 데이터베이스는 막대한 작업을 수행해야 하는 거죠.

ORM이 추상화라는 장막 뒤에 숨겨놓은 진실을 파악하지 못하면, 진짜 성능 병목 지점을 영원히 찾지 못할 수도 있습니다.

:light_bulb: 인사이트 2: 가장 큰 성능 저하의 원인은 의외로 단순한 실수

데이터베이스 성능 문제의 가장 흔한 원인이 뭘까요?

복잡한 쿼리 튜닝? 서버 설정 문제?

아닙니다. 놀랍게도 가장 흔한 원인은 바로 **‘누락된 인덱스’**입니다.

왜 이 문제가 발견되기 어려울까요?

초기 개발 단계나 데이터가 적을 때는 문제가 잘 드러나지 않습니다. 애플리케이션은 원활하게 작동하는 것처럼 보이죠.

하지만 시간이 지나 데이터가 쌓이고 사용량이 늘어나면서, 인덱스 없는 쿼리는 시스템 전체를 마비시키는 시한폭탄이 됩니다.

처음에는 눈에 띄지 않기 때문에 많은 개발팀이 새 기능을 배포할 때 생성되는 모든 SQL 쿼리에 적절한 인덱스가 있는지 검증하는 과정을 놓치곤 합니다.

핵심 포인트: 데이터베이스 성능 문제의 가장 흔한 원인은 개발자가 인덱스 추가를 잊어버리는 것입니다.

:light_bulb: 인사이트 3: 진짜 ‘느린 쿼리’ 찾기는 탐정 게임

느린 쿼리를 찾아야 한다는 건 알겠는데, 어떻게 찾을까요?

pg_stat_statements의 함정

Postgres의 pg_stat_statements 확장 기능은 어떤 쿼리가 가장 많은 시간을 소모하는지 알려주는 훌륭한 도구입니다.

하지만 한 가지 함정이 있습니다.

효율성을 위해 쿼리를 정규화하여 저장합니다. 예를 들어:

-- 실제 쿼리
WHERE backend_id = '12345'

-- 저장되는 형태
WHERE backend_id = $1

이 때문에 실제 어떤 값으로 쿼리가 실행되었는지 알 수 없어서, EXPLAIN 명령을 바로 실행할 수 없습니다.

해결책 1: log_min_duration_statement

특정 실행 시간을 초과하는 쿼리의 전체 텍스트(실제 파라미터 값 포함)를 로그에 남길 수 있습니다.

해결책 2: auto_explain (게임 체인저!)

auto_explain은 한 단계 더 나아갑니다. 느린 쿼리가 발생했을 때 그 순간의 실제 실행 계획을 자동으로 로깅해줍니다.

왜 이게 중요할까요?

쿼리의 실행 계획은 특정 파라미터 값이나 당시의 데이터베이스 상태에 따라 달라질 수 있습니다. auto_explain은 프로덕션 환경에서 문제가 발생한 바로 그 순간의 실제 계획을 포착해서, "왜 이 쿼리가 그 시점에 느렸는가"를 정확히 분석할 수 있게 해줍니다.

:light_bulb: 인사이트 4: '좋은 인덱스’와 '위대한 인덱스’의 차이는 500배

“인덱스가 없어서 문제라면, 그냥 추가하면 되는 거 아냐?”

그렇게 단순하지 않습니다. 어떤 인덱스를 어떻게 만드느냐에 따라 성능은 하늘과 땅 차이로 벌어집니다.

실제 최적화 사례를 책을 읽는 것에 비유해서 단계별로 살펴볼게요.

1단계: 인덱스 없음 (처음부터 끝까지 다 읽기)

특정 backend_id를 찾는 쿼리를 인덱스 없이 실행하면?

책 한 권을 처음부터 끝까지 통째로 읽는 것과 같습니다.

  • Postgres는 테이블 전체를 순차 스캔(Seq Scan)

  • 디스크에서 680MB 데이터를 읽어야 함

2단계: 단순 인덱스 추가 (색인 사용하기)

backend_id 컬럼에 기본 B-Tree 인덱스를 추가하면?

책 뒤의 색인으로 페이지 번호를 찾는 것과 같습니다.

  • 쿼리 계획이 Bitmap Index Scan으로 변경

  • 성능 2배 향상!

하지만 문제가 있습니다. 쿼리는 wait_event라는 다른 컬럼 값도 필요했습니다.

데이터베이스는:

  1. 색인에서 페이지 번호(데이터 위치)를 찾고

  2. 본문의 해당 페이지들을 일일이 다시 펼쳐서 필요한 정보를 읽어옴

이 과정(Bitmap Heap Scan) 때문에 여전히 디스크에서 207MB 데이터를 읽어야 했습니다.

3단계: 커버링 인덱스 (마법이 일어나는 순간! :sparkles:)

INCLUDE 키워드로 wait_event 컬럼을 인덱스에 포함시키면?

페이지 번호와 함께 우리가 찾던 문장 전체가 색인에 모두 기록된 특별한 색인입니다.

CREATE INDEX idx_backend_events 
ON table_name (backend_id) 
INCLUDE (wait_event);

이제 데이터베이스는:

  • 본문을 펼쳐볼 필요 없이

  • 오직 이 특별한 색인만 읽어서 쿼리 완료

  • 이것이 바로 Index-Only Scan

결과: 디스크에서 읽는 데이터가 1.3MB로 극적으로 감소!

:bar_chart: 최종 결과

  • 초기 대비 디스크 읽기량 500배 감소

  • 해당 쿼리만 빨라지는 게 아니라

  • 시스템 전체 I/O 부하 감소로 다른 쿼리들의 성능까지 향상

이제 당신의 차례입니다

오늘 우리가 배운 내용을 정리하면:

  1. :white_check_mark: 애플리케이션 성능 = 데이터베이스 성능

  2. :white_check_mark: 가장 흔한 성능 병목의 원인은 누락된 인덱스

  3. :white_check_mark: auto_explain으로 느린 쿼리의 근본 원인 파악하기

  4. :white_check_mark: 커버링 인덱스로 500배 성능 개선 달성하기

지금 바로 실천해보세요

당신의 데이터베이스에는 어떤 숨겨진 성능 시한폭탄이 잠자고 있을까요?

오늘 배운 도구들로 한번 확인해보시는 건 어떨까요?

이 글이 도움이 되셨다면 공유해주세요! :rocket: