"앱 코드 수정 없이 PostgreSQL 샤딩 가능한가요"

"'Postgres 샤딩 앱 코드 수정 없이 가능한가 PgDog 실전 검증' 내용에 따르면, PgDog는 애플리케이션과 Postgres 사이에 위치하는 프록시 방식으로 동작해 앱 코드를 전혀 수정하지 않아도 수평 샤딩이 가능합니다. 앱 입장에서는 단순히 Postgres 하나에 연결한 것처럼 보이며, libpq나 psycopg2 등 어떤 드라이버를 사용해도 동작합니다."

"PgDog 크로스 샤드 트랜잭션 지원 되나요"

"PgDog는 현재 크로스-샤드 트랜잭션을 지원하지 않으며, 이는 2026년 2월 Hacker News 토론에서 개발 측이 직접 인정한 사항입니다. 샤딩 키가 없는 복잡한 조인의 경우 전체 샤드 스캔(브로드캐스트)이 발생하는 제약도 함께 존재합니다."

"PgDog vs Citus 어떤 게 더 나은가요"

"'Postgres 샤딩 앱 코드 수정 없이 가능한가 PgDog 실전 검증' 비교에 따르면, PgDog는 설치 편의성과 낮은 학습 곡선에서 앞서지만 2025년 이후 출시된 초기 단계 도구라 프로덕션 레퍼런스가 적습니다. 반면 Citus는 2012년부터 운영되며 Microsoft Azure와 통합된 성숙한 솔루션으로, 크로스-샤드 트랜잭션(2PC)도 지원해 프로덕션 안정성 면에서 우위에 있습니다."

"PostgreSQL 단일 인스턴스 한계 언제 샤딩 고려해야 하나요"

"테이블이 수십억 행을 넘어가면 인덱스 스캔 비용이 급격히 상승하고 VACUUM 작업이 락을 점유하기 시작하며, 수직 확장 비용도 AWS RDS 기준 월 3만 달러를 초과할 수 있어 샤딩을 검토할 시점이 됩니다. 특히 쓰기 처리량이 CPU 코어 수와 디스크 I/O 한계에 부딪히는 시점이 실질적인 수평 확장 전환 신호입니다."

"PgDog 실제 운영 환경에 도입해도 괜찮을까요"

"현재 PgDog는 초기 단계 도구로 프로덕션 레퍼런스가 적고, 크로스-샤드 트랜잭션 미지원 등 실질적 한계가 존재해 단독 프로덕션 도입은 신중히 검토해야 합니다. 단기 검증 목적이나 읽기 부하 분산이 주된 요구사항인 팀에게 가장 현실적인 진입점으로 권장됩니다."

테크 경제

Postgres 샤딩, 앱 코드 수정 없이 가능한가 — PgDog 실전 검증

February 24, 2026 5 min read 한국어

데이터베이스가 버티지 못하면 서비스가 먼저 무너져요. 트래픽이 세 배 뛰던 날, DBA가 새벽 3시에 깨어나 손으로 쿼리 라우팅을 조정하던 시절이 있었죠. 그 문제를 “코드 한 줄 안 바꾸고” 해결한다고 주장하는 도구가 2026년 초 개발자 커뮤니티에서 조용히 화제예요. 바로 PgDog입니다.

핵심 요약
PgDog는 PostgreSQL 앞단에서 동작하는 커넥션 풀러·샤딩 프록시로, 앱 코드를 전혀 수정하지 않아도 수평 샤딩이 가능하다고 주장해요.
Postgres 네이티브 와이어 프로토콜을 직접 파싱해 쿼리를 샤드에 라우팅하기 때문에, 앱 입장에선 그냥 Postgres에 연결한 것처럼 동작해요.
2026년 2월 기준 Hacker News 커뮤니티 토론에서 트랜잭션 레벨 제약, 크로스-샤드 조인 미지원 등 실질적 한계도 함께 드러났어요.
기존 Citus·Vitess와 비교하면 설치 편의성에서 앞서지만, 성숙도 면에서 프로덕션 단독 도입은 아직 신중히 따져봐야 해요.
단기 검증용 또는 읽기 부하 분산 목적의 팀에게 가장 현실적인 진입점이에요.

1. 배경: Postgres 샤딩이 다시 뜨거워진 이유

Postgres가 이미 세계 1위인데, 샤딩이 문제인 이유

DB-Engines 랭킹(2026년 1월 기준)에서 PostgreSQL은 Oracle, MySQL과 함께 상위 3위를 굳건히 유지하고 있어요. 전 세계 개발자 설문(Stack Overflow Developer Survey 2025)에서도 “가장 선호하는 데이터베이스” 1위를 2년 연속 차지했죠.

그런데 단일 Postgres 인스턴스의 쓰기 처리량은 CPU 코어 수와 디스크 I/O 한계에 수직으로 부딪혀요. 테이블 하나가 수십억 행을 넘어가면 인덱스 스캔 비용이 급격히 오르고, 버큠(VACUUM) 작업이 락을 잡아먹기 시작해요. 수직 확장(Scale-Up)은 결국 돈의 문제예요. AWS RDS db.r8g.48xlarge 인스턴스는 월 3만 달러를 넘어가거든요.

그래서 수평 확장(Scale-Out), 즉 샤딩이 필요해지는 거예요. 데이터를 여러 서버에 나눠서 넣고, 쿼리가 들어오면 해당 샤드로만 보내는 구조예요.

진짜 문제는 “코드”

기존 샤딩 방법은 대부분 애플리케이션 레이어에 샤딩 로직을 심어야 했어요.

어느 샤드에 쓸지 결정하는 라우팅 함수
크로스-샤드 쿼리를 합치는 집계 로직
트랜잭션 경계 처리

기존 서비스를 이 구조로 바꾸면 코드베이스 전체가 흔들려요. 마이그레이션 비용이 수개월치 엔지니어링 공수로 뛰는 거죠. 바로 이 지점에서 PgDog가 등장해요.

2. PgDog란 무엇인가: 구조와 작동 원리

프록시 방식, 핵심은 여기예요

PgDog는 애플리케이션과 Postgres 사이에 앉는 프록시예요. 앱은 PgDog에 연결하고, PgDog가 내부적으로 여러 Postgres 샤드에 쿼리를 분배해요.

[앱] → [PgDog 프록시] → [Shard 0: Postgres]
                       → [Shard 1: Postgres]
                       → [Shard 2: Postgres]

앱 입장에서는 그냥 Postgres 하나에 연결한 거예요. libpq나 psycopg2, 어떤 드라이버를 써도 상관없어요.

쿼리를 어떻게 나눌까요?

PgDog는 Postgres 와이어 프로토콜을 직접 파싱해요. INSERT INTO users (id, name) VALUES (42, 'Alice') 같은 쿼리가 들어오면, 샤딩 키(여기선 id)를 파싱해서 어느 샤드로 보낼지 계산해요. 해시 기반 샤딩이 기본이에요.

SELECT도 마찬가지예요. WHERE id = 42가 들어오면 42번이 어느 샤드에 있는지 알기 때문에 해당 샤드에만 쿼리를 날려요. 범위 스캔이나 샤딩 키 없는 쿼리는 모든 샤드에 브로드캐스트한 뒤 결과를 합쳐요.

커넥션 풀링은 PgBouncer처럼 동작해요. 수백 개의 앱 커넥션을 소수의 Postgres 커넥션으로 압축해서 서버 부하를 낮춰줘요.

Hacker News 토론에서 드러난 현실

2026년 2월 PgDog가 Hacker News에 올라왔을 때 커뮤니티 반응은 둘로 갈렸어요.

“PgBouncer + 샤딩을 한 번에 해결하는 접근이 깔끔하다"는 긍정적 반응과 “크로스-샤드 트랜잭션을 어떻게 처리하냐"는 실용적 질문이 동시에 올라왔거든요.

개발 측 답변 요지는 이랬어요. 크로스-샤드 트랜잭션은 현재 지원하지 않고, 샤딩 키가 없는 복잡한 조인은 전체 샤드 스캔이 발생한다고요. 투명한 인정이에요.

3. 실전 검증: PgDog vs 대안 솔루션 비교

주요 Postgres 샤딩 옵션 비교

항목	PgDog	Citus (Microsoft)	Vitess (PlanetScale)
설치 방식	독립 프록시	Postgres 확장	별도 클러스터
앱 코드 수정	없음	일부 필요	스키마 재설계 필요
크로스-샤드 조인	제한적 (브로드캐스트)	지원 (colocation 기반)	제한적
크로스-샤드 트랜잭션	미지원	2PC 지원	미지원
성숙도	초기 (2025~)	성숙 (2012~, MS 인수)	성숙 (YouTube 출신)
주 대상 DB	PostgreSQL	PostgreSQL	MySQL
라이선스	오픈소스	AGPLv3 + 유료 클라우드	Apache 2.0
학습 곡선	낮음	중간	높음
프로덕션 레퍼런스	적음	풍부 (Azure 통합)	풍부 (Discord 등)

트레이드오프 분석

Citus는 Postgres 익스텐션 방식이에요. 분산 테이블 생성 시 create_distributed_table 함수를 명시적으로 호출해야 하고, 일부 쿼리 패턴은 재작성이 필요해요. 반면 크로스-샤드 트랜잭션을 2PC(Two-Phase Commit)로 지원하고, Microsoft Azure에서 관리형 서비스로 제공돼요. 성숙도가 가장 높아요.

Vitess는 MySQL 기반이라 Postgres 팀엔 직접 옵션이 아니에요. 그런데 “앱 코드 최소 수정 + 수평 확장” 패턴의 레퍼런스로는 가장 검증된 사례예요. Discord가 수조 개의 메시지를 Vitess로 관리한다고 공식 블로그에서 밝혔거든요.

PgDog는 설치 편의성에서 두 솔루션을 앞서요. Docker 이미지로 띄우고 설정 파일에 샤드 목록 넣으면 끝이에요. 앱 코드 수정이 진짜로 필요 없어요. 단, 복잡한 트랜잭션이 많은 서비스라면 아직 위험 부담이 있어요.

4. 실무 시사점: 누가, 언제, 어떻게 써야 할까요

지금 당장 도입을 검토할 팀

읽기 부하가 쓰기보다 세 배 이상 높은 서비스에 가장 맞아요. PgDog의 읽기 라우팅은 레플리카 분산도 함께 처리하거든요. API 서버가 DB를 병목으로 느끼기 시작했는데 크로스-샤드 트랜잭션 요구사항이 없다면 진지하게 볼 만해요.

POC(개념 검증) 용도로도 좋아요. 기존 코드 한 줄 안 바꾸고 샤딩 프록시를 끼워볼 수 있으니까요. 실패해도 철수가 쉬워요.

반대로 금융 서비스처럼 트랜잭션 무결성이 핵심인 곳은 지금 당장 PgDog만으로 프로덕션 전환하기엔 무리예요. 크로스-샤드 트랜잭션 미지원이 치명적 약점이 될 수 있어요.

단기 액션 (1~3개월)

PgDog를 스테이징 환경에 올리고 기존 쿼리 패턴 중 샤딩 키 없는 쿼리 비율 측정
샤딩 키 후보 선정: user_id, tenant_id 등 가장 자주 필터링되는 컬럼
로드 테스트: 단일 Postgres 대비 2-샤드 구성에서 처리량과 레이턴시 비교 측정

중장기 전략 (6~12개월)

PgDog의 로드맵을 추적하면서 크로스-샤드 트랜잭션 지원 여부를 지켜봐야 해요. 오픈소스 프로젝트다 보니 커뮤니티 기여가 얼마나 붙느냐가 성숙도를 가를 거예요.

Citus를 병행 검토하는 것도 현실적이에요. 특히 Azure를 쓰는 팀이라면 Citus Hyperscale(Azure Database for PostgreSQL)이 관리 부담을 크게 낮춰줘요.

기회와 한계, 있는 그대로

기회: 레거시 서비스를 샤딩하려는 팀에게 진입 장벽이 낮은 첫 번째 옵션이 생겼어요. 기존엔 “코드 다 뜯어야 해요"가 기본값이었거든요. 그 공백을 PgDog가 메울 수 있어요.

한계: 쿼리 파싱 레이어가 추가되니까 레이턴시 오버헤드가 생겨요. 수 마이크로초 단위지만, 고빈도 트랜잭션 서비스에선 체감될 수 있어요. 그리고 프록시 자체가 SPOF(단일 장애점)가 될 수 있으니 HA(고가용성) 구성을 반드시 고려해야 해요.

5. 결론: “코드 수정 없는 샤딩"은 반은 맞고, 반은 아직

결론은 이래요.

단순 읽기·쓰기 워크로드에서 코드 수정 없는 샤딩은 실제로 동작해요.
크로스-샤드 트랜잭션, 복잡한 조인은 현재 한계가 명확해요.
설치 편의성과 낮은 진입 장벽은 진짜 강점이에요.
프로덕션 레퍼런스가 쌓이는 2026년 하반기가 본격 도입 판단 시점이에요.

앞으로 6개월 안에 커뮤니티 기여가 붙으면서 트랜잭션 지원 로드맵이 나올 가능성이 높아요. 그때 다시 한 번 검증이 필요할 거예요.

지금 당장 Postgres 병목으로 고민 중인 팀이라면, 스테이징 환경에서 PgDog를 띄워보세요. 코드 한 줄 안 건드리고 얼마나 버텨줄 수 있는지 직접 확인하는 게 가장 빠른 답이에요.

참고: PgDog 관련 커뮤니티 토론은 Hacker News(2026년 2월)에서 확인할 수 있으며, PostgreSQL 공식 문서(postgresql.org)를 기반으로 샤딩 아키텍처를 분석했어요.

참고자료

Photo by Christopher Gower on Unsplash