PostgreSQL vs MongoDB — Part 3: 하이브리드 아키텍처와 마이그레이션 전략
PostgreSQL vs MongoDB 3부작의 완결 편입니다. 하이브리드 아키텍처를 진짜로 써야 할 때와 결정 회피로 남용할 때를 구분하는 법, 그리고 트랜잭션 코어 분리, ETL 파이프라인, PostgreSQL JSONB 흡수 등 3가지 설계 패턴을 구체적인 코드 예제와 함께 설명합니다. MongoDB에서 PostgreSQL로, 또는 그 반대 방향의 단계적 마이그레이션 전략과 Big Bang을 피하는 방법도 다룹니다. Neon, PlanetScale, SurrealDB, Atlas Vector Search, pgvector 등 2026년 주목할 대안들을 짚고, 3부작의 핵심을 하나의 의사결정 프레임워크로 정리합니다.
시리즈 구성
- Part 1 — 설계 철학부터 이해하는 데이터베이스 선택
- Part 2 — 실전 시나리오별 선택 기준
- Part 3 — 하이브리드 아키텍처와 마이그레이션 전략 (현재 편)
목차
- 들어가며: 둘 다 쓰면 안 되나요?
- 하이브리드 아키텍처: 언제 두 DB를 함께 쓰는가
- 하이브리드 설계 패턴 3가지
- 마이그레이션: MongoDB에서 PostgreSQL로
- 마이그레이션: PostgreSQL에서 MongoDB로
- 2026년 주목할 대안 DB들
- 최종 결론: 나만의 선택 프레임워크
1. 들어가며
Part 1에서 철학을 이해했고, Part 2에서 시나리오별 판단 기준을 익혔다. 이제 마지막 질문이 남는다.
"하나만 골라야 하나요? 둘 다 쓰면 안 되나요?"
정답은 — 상황에 따라 둘 다 써도 된다. 다만, 그 선택에는 명확한 이유와 설계가 뒷받침되어야 한다. "그냥 둘 다 쓰면 커버가 되겠지"라는 생각으로 하이브리드를 택했다간, 운영 복잡도만 두 배가 되고 팀은 두 DB를 모두 잘 알아야 하는 부담을 진다.
이번 파트에서는 하이브리드가 진짜로 필요한 경우와 그 설계 패턴, 그리고 한 DB에서 다른 DB로 마이그레이션해야 할 때의 전략을 다룬다. 마지막으로 2026년 현재 주목받고 있는 대안 DB들도 짚어본다.
2. 하이브리드 아키텍처
언제 두 DB를 함께 쓰는가
무조건 피해야 할 패턴이 있다. "어느 쪽이 더 좋을지 모르겠으니 둘 다" — 이건 하이브리드가 아니라 결정 회피다.
하이브리드가 진짜 의미를 갖는 경우는 시스템의 두 부분이 본질적으로 다른 데이터 특성을 가질 때다.
하이브리드를 고려할 신호:
| 상황 | 관계형 (PostgreSQL) | 문서형 (MongoDB) |
|---|---|---|
| 결제·주문·회원 | 핵심 트랜잭션 데이터 | — |
| 상품 상세 페이지 | — | 카테고리마다 속성 다름 |
| 정기 리포팅 | BI 도구 연동 | — |
| 사용자 활동 로그 | — | 구조 다양, 쓰기 폭발적 |
| 권한·역할 관리 | 복잡한 관계 | — |
| 알림·메시지 페이로드 | — | 가변 구조 |
이처럼 도메인을 수직으로 잘랐을 때, 한쪽은 명백히 관계형이고 다른 쪽은 명백히 문서형이라면 하이브리드는 합리적인 선택이다. 반대로 전체 도메인이 어느 한쪽에 자연스럽게 맞는다면 굳이 두 DB를 도입할 이유가 없다.
3. 하이브리드 설계 패턴 3가지
패턴 1: 트랜잭션 코어 + 유연 콘텐츠 분리
가장 일반적인 하이브리드 패턴이다. 비즈니스 핵심 데이터(결제, 회원, 주문)는 PostgreSQL, 콘텐츠·이벤트·로그처럼 구조가 유연한 데이터는 MongoDB로 분리한다.
이 패턴에서 핵심은 두 DB 간에 직접적인 JOIN이 없도록 경계를 명확히 그어야 한다는 것이다. 주문 데이터(PostgreSQL)와 상품 상세(MongoDB)를 동시에 보여줘야 하는 API라면, 애플리케이션 레이어에서 두 쿼리를 각각 실행하고 결합한다.
// 애플리케이션 레이어에서 두 DB 결과를 조합
async function getOrderDetail(orderId: string) {
// PostgreSQL: 주문·결제 정보
const order = await prisma.order.findUnique({
where: { id: orderId },
include: { user: true, payment: true },
});
// MongoDB: 상품 상세 (카테고리별 가변 속성)
const product = await ProductModel.findById(order.productId).lean();
return { ...order, product };
}
패턴 2: 쓰기(MongoDB) → 집계(PostgreSQL) ETL 파이프라인
이벤트나 로그처럼 쓰기는 빠르게 MongoDB에 저장하고, 주기적으로 집계·정제해서 리포팅용 PostgreSQL 테이블로 ETL하는 패턴이다.
이 패턴은 실시간성과 분석 정확도를 동시에 잡을 수 있다. 다만 ETL 파이프라인의 지연(Lag)을 팀과 이해관계자가 인지하고 있어야 한다. "실시간 대시보드"를 요구받는다면 이 패턴은 맞지 않는다.
패턴 3: PostgreSQL JSONB로 하이브리드 흡수
두 DB를 운영하는 복잡도를 피하고 싶다면, PostgreSQL의 JSONB 컬럼이 좋은 타협점이 된다. 구조적인 데이터는 일반 컬럼으로, 가변적인 데이터는 JSONB 컬럼으로 저장한다.
CREATE TABLE products (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name TEXT NOT NULL,
category TEXT NOT NULL,
base_price NUMERIC(10, 2) NOT NULL,
-- 카테고리별로 다른 속성을 JSONB로 저장
attributes JSONB
);
-- 전자제품 상품 예시
INSERT INTO products (name, category, base_price, attributes) VALUES (
'갤럭시 S26',
'electronics',
1299000,
'{"storage": "256GB", "color": ["black", "silver"], "5g": true}'
);
-- JSONB 필드에 GIN 인덱스 적용
CREATE INDEX idx_products_attrs ON products USING GIN (attributes);
-- JSONB 필드로 쿼리
SELECT name FROM products
WHERE attributes->>'storage' = '256GB'
AND (attributes->>'5g')::boolean = true;
JSONB는 MongoDB만큼 유연하진 않지만, DB를 하나로 유지하면서 유연성을 얻는 실용적인 선택이다. 특히 팀 규모가 작거나 인프라 운영 부담을 최소화하고 싶을 때 유용하다.
4. 마이그레이션: MongoDB에서 PostgreSQL로
MongoDB로 시작했는데 점점 리포팅이 고통스러워지거나, 데이터 간 관계가 복잡해지면서 JOIN이 자꾸 필요해지는 경우다.
이전을 결심하는 신호:
- 집계 파이프라인이 너무 길고 복잡해져서 유지보수가 어렵다
- 팀에 SQL에 익숙한 데이터 분석가가 합류했다
- 핵심 비즈니스 로직에 트랜잭션이 점점 많이 필요해진다
- BI 도구 연동이 MongoDB로는 계속 불편하다
마이그레이션 전략
1단계 — 스키마 설계: MongoDB 도큐먼트를 분석해 관계형 테이블 구조로 정규화한다. 중첩 배열이나 선택적 필드가 어떤 테이블로 매핑될지 먼저 설계도를 그려야 한다.
| MongoDB 도큐먼트 | PostgreSQL 테이블 |
|---|---|
_id, name, email | users (id, name, email) |
orders[].total, orders[].status | orders (id, user_id, total, status) |
orders[].items[] | order_items (id, order_id, product_id, qty) |
2단계 — 이중 쓰기(Dual Write): 새로운 데이터는 MongoDB와 PostgreSQL 양쪽에 동시에 쓴다. 이 기간 동안 두 DB의 데이터 일관성을 검증한다.
async function createOrder(data: CreateOrderDTO) {
// 기존 MongoDB에도 쓰기 (롤백 대비)
await OrderModel.create(data);
// 새 PostgreSQL에도 쓰기
await prisma.order.create({ data: transformToRelational(data) });
}
3단계 — 백필(Backfill): 이중 쓰기 시작 이전의 기존 데이터를 배치 스크립트로 마이그레이션한다. 데이터 양이 많다면 청크 단위로 나눠서 처리한다.
4단계 — 읽기 전환 → 쓰기 전환: PostgreSQL 데이터가 검증되면 읽기를 먼저 전환하고, 문제가 없으면 쓰기도 PostgreSQL로 완전히 전환한 후 MongoDB를 내린다.
주의: 한 번에 다 바꾸려는 Big Bang 마이그레이션은 피하라. 항상 단계적으로, 롤백 플랜과 함께 움직여야 한다.
5. 마이그레이션: PostgreSQL에서 MongoDB로
반대의 경우다. 처음엔 PostgreSQL로 잘 쓰고 있었는데, 시간이 지나면서 데이터 구조가 너무 다양해지고 스키마 변경이 잦아지면서 마이그레이션 비용이 팀 발목을 잡는 상황이다.
이전을 결심하는 신호:
- 스키마 마이그레이션 파일이 수백 개를 넘어 관리가 힘들어졌다
- 컬럼의 절반 이상이 nullable이거나 거의 사용되지 않는다
- 도큐먼트처럼 통째로 읽히는 데이터가 너무 많은 테이블 JOIN을 필요로 한다
- 수평 확장이 필요한데 PostgreSQL 샤딩이 지나치게 복잡하다
마이그레이션 전략
PostgreSQL → MongoDB 방향은 오히려 더 신중해야 한다. 트랜잭션이나 복잡한 JOIN에 의존하던 비즈니스 로직을 애플리케이션 레이어로 올려야 하기 때문이다.
이전에 앞서 반드시 확인해야 할 체크리스트:
- 현재 멀티 테이블 트랜잭션이 얼마나 사용되는가?
- 복잡한 집계 쿼리들을 집계 파이프라인으로 재작성할 수 있는가?
- 팀이 MongoDB 운영 경험이 있는가?
- 외래 키로 보장되던 참조 무결성을 애플리케이션에서 직접 관리할 준비가 됐는가?
이 중 하나라도 "아니오"가 나온다면, 전체 마이그레이션보다 PostgreSQL JSONB로 유연성을 추가하는 방향이 더 현실적일 수 있다.
6. 2026년 주목할 대안 DB들
PostgreSQL과 MongoDB 외에도, 2026년 현재 특정 유스케이스에서 주목받는 DB들이 있다. 선택지가 두 가지만은 아니라는 것을 알아두는 것이 좋다.
Neon (서버리스 PostgreSQL)
PostgreSQL을 그대로 사용하면서 서버리스로 운영할 수 있다. 브랜치 기능이 특히 강력한데, Git 브랜치처럼 DB를 분기해서 개발·스테이징 환경을 독립적으로 관리할 수 있다. 스타트업과 Next.js 생태계에서 빠르게 채택되고 있다.
PlanetScale (MySQL 기반)
MySQL 기반이지만 스키마 변경을 무중단으로 처리하는 것이 강점이다. 대규모 테이블 마이그레이션이 잦은 팀에게 매력적인 선택지다.
SurrealDB
SQL과 NoSQL을 하나의 쿼리 언어(SurrealQL)로 통합한 실험적인 DB다. 그래프, 문서, 관계형을 동시에 지원한다. 아직 프로덕션 레퍼런스가 많지 않지만, 2026년에 커뮤니티가 성장하고 있다.
MongoDB Atlas Vector Search
별도의 벡터 DB(Pinecone, Weaviate 등) 없이 MongoDB 안에서 AI 임베딩 검색을 처리할 수 있다. 이미 MongoDB를 쓰고 있는 팀이 RAG 파이프라인을 추가할 때 인프라를 늘리지 않아도 된다는 점이 매력이다.
PostgreSQL + pgvector
마찬가지로 PostgreSQL에서 벡터 검색을 처리한다. 2026년 AI 애플리케이션 붐과 함께 가장 빠르게 채택이 늘고 있는 조합 중 하나다.
7. 최종 결론: 나만의 선택 프레임워크
3편에 걸쳐 이야기한 내용을 하나의 의사결정 흐름으로 정리한다.
요약하면 이렇다:
- 기본값은 PostgreSQL이다. 모르겠으면 PostgreSQL. 구조적이고 관계가 있는 데이터는 PostgreSQL. 팀이 SQL에 익숙하다면 PostgreSQL.
- MongoDB는 명확한 이유가 있을 때 선택한다. 문서형 데이터, 가변 구조, 통째로 읽히는 단위, 수평 확장 — 이 조건들이 충족될 때.
- 하이브리드는 도메인 경계가 명확할 때만 도입한다. 복잡도를 감당할 준비가 된 팀과 함께.
- 유행보다 도메인의 형태를 봐라. 기술 선택은 트렌드가 아니라 데이터의 본질에서 시작해야 한다.
시리즈를 마치며
이 3부작 시리즈를 통해 PostgreSQL과 MongoDB를 단순한 기능 비교가 아닌, 설계 철학과 실전 판단의 관점에서 살펴봤다. 어느 쪽이 우월한 DB는 없다. 다만 특정 상황에 더 잘 맞는 DB가 있을 뿐이다.
데이터베이스를 고를 때마다 이 질문으로 돌아오길 권한다.
"내 데이터는 어떤 모양인가? 어떻게 읽히고, 어떻게 쓰이고, 어떻게 변하는가?"
그 답이 곧 선택의 답이다.