왜 지금 PostgreSQL 성능 관리가 다시 화두인가
엔터프라이즈 환경에서 DB 성능 저하는 단순한 '느린 쿼리' 문제로 끝나지 않습니다. SLA 미준수, 릴리스 지연, 개발팀 번아웃, 운영 리스크 증가로 이어지고, 최종적으로는 고객 이탈과 매출 손실로 귀결되죠.
문제는 팀에 도구가 없어서가 아닙니다. 통합이 안 되어 있기 때문입니다. 느린 쿼리 하나를 진단하려고 SQL 에디터, 모니터링 대시보드, 클라우드 포털, 문서 사이트를 전전하다 보면 컨텍스트가 다 끊겨버립니다. 인사이트는 한 곳에, 실행은 다른 곳에 있는 구조죠.
Microsoft가 Azure Database for PostgreSQL에 대해 밀고 있는 방향은 명확합니다. 개발, 진단, 튜닝을 하나의 워크플로우로 묶는 것. 그 중심에 VS Code용 PostgreSQL 확장이 있습니다. 근거자료는 Azure 공식 블로그에서 확인할 수 있어요.
국내 SI/SaaS 환경에서 특히 주목할 지점은 '개발자와 DBA의 경계 허물기'입니다. 그동안 DBA가 야간에만 볼 수 있었던 메트릭과 튜닝 포인트가, 이제 개발자의 에디터 안에 들어옵니다.

VS Code 안으로 들어온 PostgreSQL 퍼포먼스 툴킷
1. Server Metrics Dashboard — 스냅샷이 아니라 트렌드
CPU, 메모리, 스토리지, 커넥션 지표가 VS Code 안에 그대로 표시됩니다. Azure 텔레메트리와 연동되기 때문에 단순 스냅샷이 아니라 시계열 히스토리로 문제를 볼 수 있어요.
# VS Code에서 PostgreSQL 확장 설치 후 Azure 구독 연결
# Command Palette (Ctrl+Shift+P) → "PostgreSQL: Add Connection"
# → Azure 리소스 자동 탐색 → Database for PostgreSQL 선택
컨텍스트 스위칭 비용이 사라지는 게 핵심입니다. 장애 대응 시 '탐지 → 조사' 사이의 시간이 눈에 띄게 줄어듭니다.
2. Azure Advisor in VS Code — 인사이트를 액션으로
관찰은 액션으로 이어질 때만 의미가 있습니다. 확장은 Azure Advisor 추천(인덱싱, 설정, 리소스 최적화)을 에디터 안에 띄워줍니다. 워크로드에 맞춘 제안이기 때문에, 매뉴얼과 메트릭을 머릿속에서 짝짓는 수고가 사라집니다.
3. Query Plan 시각화 + AI 분석
실행 계획을 읽기 쉽게 시각화하고, AI가 병목 후보와 최적화 옵션을 제안합니다. PostgreSQL 전문가를 대체하는 건 아니지만, 전문가가 아닌 개발자도 초기에 더 나은 판단을 내릴 수 있게 해줍니다.
-- 예: 느린 쿼리 원인 파악 시 EXPLAIN ANALYZE 활용
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT u.id, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > NOW() - INTERVAL '30 days'
GROUP BY u.id
ORDER BY order_count DESC
LIMIT 100;
-- VS Code 확장에서는 이 결과가 트리/그래프 뷰로 렌더링됩니다
4. 스키마 인지 IntelliSense, search_path 대응
성능 문제는 프로덕션이 아니라 스키마 설계와 쿼리 작성 시점에 이미 시작됩니다. 대규모 스키마에서도 안정적으로 동작하는 Object Explorer, search_path를 인지하는 자동완성, Entra ID 인증까지 갖춰져 있어 개발/운영 경계 없이 안전하게 작업할 수 있습니다.
참고로 이런 '에디터 안에서 인프라까지 다루는' 흐름은 Ray on TPU, GKE로 10분 만에 시작하는 실전 가이드에서 다룬 클라우드 네이티브 워크플로우와도 같은 맥락입니다.

Azure HorizonDB — 다음 단계의 AI-native PostgreSQL
Microsoft는 퍼블릭 프리뷰로 Azure HorizonDB를 소개했습니다. 클라우드 네이티브, AI-ready PostgreSQL 호환 워크로드를 겨냥하며, 셀프 매니지드 대비 최대 3배 성능을 주장합니다.
| 항목 | Azure Database for PostgreSQL | Azure HorizonDB (Preview) |
|---|---|---|
| 포지션 | 프로덕션 표준 (권장) | AI-native 차세대 옵션 |
| 성능 | 매니지드 기본 성능 | 셀프 매니지드 대비 3x (주장) |
| AI 통합 | 확장 기반 | 네이티브 AI 기능 내장 |
| 확장성 | 엔터프라이즈 표준 | 고급 스케일링 지향 |
| 적합 대상 | 대부분의 실서비스 | AI 파워드 앱 실험/신규 |
주의할 점: HorizonDB는 아직 프리뷰입니다. 프로덕션 트래픽을 바로 옮기는 건 권장되지 않아요. 기존 워크로드는 Database for PostgreSQL을 유지하면서, 신규 AI 기능 실험에 HorizonDB를 병행하는 전략이 현실적입니다.
또 하나 짚을 부분은 AI 추천의 한계입니다. AI가 제안한 인덱스가 쓰기 부하를 늘리거나, 통계 정보가 낡아 잘못된 플랜을 추천할 수 있습니다. 결국 최종 판단은 사람의 몫입니다.

실무 적용을 위한 정리
정리하면 이렇습니다.
- 도구가 아니라 통합이 문제였고, VS Code 확장은 그 간극을 메웁니다.
- Server Metrics + Azure Advisor + Query Plan 시각화 + AI 분석이 하나의 에디터 안에서 순환합니다.
- 스키마 인지 IntelliSense와 Entra ID 인증으로 개발/운영 경계 없이 안전하게 작업 가능.
- HorizonDB는 '다음 단계' 옵션이며, 지금 당장 프로덕션 대체는 시기상조.
국내 환경에서는 특히 소규모 팀일수록 효과가 큽니다. DBA 전담 인력 없이 개발자가 성능 문제를 1차 진단할 수 있게 되니까요. 다만 AI 추천을 맹신하지 말고, EXPLAIN ANALYZE 결과와 실제 워크로드 특성을 함께 보는 습관은 여전히 필수입니다.
다음 단계로는 (1) VS Code 확장을 스테이징 DB에 먼저 붙여 메트릭 대시보드에 익숙해지고, (2) Azure Advisor 추천을 인덱스 리뷰 프로세스에 편입하고, (3) HorizonDB는 별도 샌드박스에서 AI 워크로드 실험용으로만 다뤄보는 걸 추천합니다.