무슨 일이 있었나요?
PostgreSQL(줄여서 포스트그레스, 오픈소스 관계형 데이터베이스예요)을 쓰다 보면 언젠가 마주치는 벽이 있어요. 바로 "데이터가 너무 많아져서 서버 한 대로는 감당이 안 된다"는 순간이죠. 이때 흔히 쓰는 방법이 샤딩(sharding)인데, 이번에 PgDog라는 프로젝트가 투자를 유치하면서 "애플리케이션 코드를 거의 안 바꾸고도 포스트그레스를 샤딩해주겠다"는 목표를 내걸었어요.
샤딩이 뭐냐면, 쉽게 말해 큰 데이터를 여러 데이터베이스 서버에 나눠 담는 것이에요. 예를 들어 회원 천만 명의 데이터를 한 대에 다 넣는 대신, 회원 ID를 기준으로 나눠서 1~500만 번은 A 서버, 500만~1000만 번은 B 서버에 저장하는 식이죠. 식당에 손님이 너무 많으면 지점을 늘리는 것과 비슷해요. 문제는 이렇게 나누면 "이 손님은 어느 지점에 있지?"를 매번 따져야 해서 애플리케이션 코드가 엄청 복잡해진다는 거예요.
PgDog는 뭐가 다른가요?
PgDog의 핵심 아이디어는 애플리케이션과 데이터베이스 사이에 끼어드는 '프록시(proxy)'라는 거예요. 프록시는 중간에서 요청을 받아 적절한 곳으로 넘겨주는 중개자라고 보면 돼요. 우리 앱은 그냥 평소처럼 포스트그레스 하나에 연결한다고 생각하고 쿼리를 날리는데, 실제로는 PgDog가 그 쿼리를 가로채서 "이 데이터는 3번 샤드에 있으니 거기로 보내자"고 알아서 라우팅해주는 거죠.
기술적으로 흥미로운 점들을 짚어볼게요.
- Rust로 작성: 성능과 안정성을 동시에 노린 선택이에요. Rust는 메모리 안전성을 컴파일 단계에서 보장해줘서, 중간에서 모든 트래픽을 처리하는 프록시처럼 절대 죽으면 안 되는 부품에 잘 맞아요.
- PgBouncer 호환을 지향: PgBouncer는 포스트그레스 진영에서 가장 널리 쓰이는 커넥션 풀러(연결을 미리 만들어두고 재사용해 부하를 줄이는 도구)예요. PgDog는 이걸 대체하면서 샤딩 기능까지 얹는 걸 노려요.
- 쿼리 파싱과 라우팅: 들어온 SQL을 분석해서 어느 샤드로 보낼지 판단하고, 여러 샤드에 흩어진 결과를 모아서 합쳐주는(스캐터-개더) 일까지 처리하려고 해요.
업계 맥락
사실 "포스트그레스 샤딩"은 오래된 숙제예요. 비슷한 시도로는 Citus(여러 노드로 포스트그레스를 확장해주는 확장 기능, 마이크로소프트가 인수했죠), Vitess(원래 MySQL용으로 유튜브가 만든 샤딩 솔루션), 그리고 아예 분산을 내장한 CockroachDB, YugabyteDB 같은 NewSQL 데이터베이스들이 있어요.
PgDog의 차별점은 "기존 포스트그레스를 그대로 두고, 앞단에 가벼운 프록시만 얹는다"는 접근이에요. CockroachDB처럼 데이터베이스 자체를 갈아엎는 게 아니라서 이미 포스트그레스로 운영 중인 팀이 점진적으로 도입하기 좋다는 그림이죠. 투자를 받았다는 건 이 프로젝트가 단발성 토이가 아니라 장기적으로 유지·발전될 가능성이 커졌다는 신호이기도 해요.
한국 개발자에게 주는 시사점
스타트업이 빠르게 크다 보면 "DB 한 대로 버티다가 어느 날 갑자기 한계"를 맞는 경우가 많아요. 그때 코드를 전부 샤딩 친화적으로 갈아엎는 건 정말 큰 공사거든요. PgDog 같은 프록시형 솔루션은 그 시점을 좀 더 부드럽게 넘기게 도와줄 수 있어요.
다만 아직 성숙도와 운영 사례를 잘 살펴봐야 해요. 중간에 프록시가 끼면 그게 새로운 단일 장애점(여기 죽으면 전체가 멈추는 지점)이 될 수 있고, 트랜잭션이나 조인이 여러 샤드에 걸칠 때의 동작도 꼼꼼히 확인해야 하거든요. 당장 프로덕션에 넣기보다는, 샤딩이라는 개념과 프록시 아키텍처를 학습하는 좋은 교재로 먼저 접근하는 걸 추천해요. 커넥션 풀링, 쿼리 라우팅, 스캐터-개더 같은 개념은 어디 가도 쓰이니까요.
마무리
PgDog는 "포스트그레스를 버리지 않고도 수평 확장하고 싶다"는 오래된 바람에 대한 또 하나의 답이에요. 여러분은 DB 확장이 필요할 때 프록시로 샤딩하는 방식과, 아예 분산 DB로 갈아타는 방식 중 어느 쪽이 더 끌리나요?
🔗 출처: Hacker News