Lv.1 입문PostgreSQL / MongoDB

2026.04.2713분 읽기Lv.1 입문

시리즈PostgreSQL vs MongoDB · 파트 1/3시리즈 허브 보기

PostgreSQL vs MongoDB — Part 1: 설계 철학부터 이해하는 데이터베이스 선택

PostgreSQL vs MongoDB 선택 질문에 단순한 SQL/NoSQL 구분 대신 데이터 설계 철학의 관점에서 답합니다. PostgreSQL은 '어떤 구조인가?'에서 시작하고, MongoDB는 '어떻게 읽힐 것인가?'에서 시작한다는 근본 차이를 구체적인 쿼리·도큐먼트 예제와 함께 설명합니다. 두 진영이 서로의 강점을 흡수하며 성숙해가는 2026년 현재 생태계(pgvector, Atlas Vector Search, Supabase, Neon)도 함께 짚습니다. Part 2에서는 트랜잭션이 필요한 결제 시스템, 실시간 이벤트 로그, Nest.js + TypeScript 환경 등 실전 시나리오별 선택 기준을 다룹니다.

시리즈 구성

• Part 1 — 설계 철학부터 이해하는 데이터베이스 선택 (현재 편)
• Part 2 — 실전 시나리오별 선택 기준 (트랜잭션·리포팅·중첩 데이터) (연재 예정)
• Part 3 — 하이브리드 아키텍처와 마이그레이션 전략 (연재 예정)

목차

1. 들어가며: 이 질문이 어려운 이유
2. PostgreSQL의 철학: 구조가 곧 힘이다
3. MongoDB의 철학: 유연성이 곧 속도다
4. 핵심 차이 한눈에 보기
5. 2026년 현재 생태계 현황
6. 마치며: Part 2 예고

1. 들어가며

백엔드 개발을 시작하면 반드시 한 번은 맞닥뜨리는 질문이 있다.

"PostgreSQL 쓸까요, MongoDB 쓸까요?"

주니어 개발자 시절엔 이 질문이 단순히 SQL이냐 NoSQL이냐의 문제처럼 느껴진다. 하지만 실제 프로덕션 환경에서 두 DB를 모두 다뤄본 입장에서 말하자면, 이건 기술 스택의 선택이 아니라 데이터 설계 철학의 선택이다.

잘못된 선택은 수개월 후 "왜 이걸 썼지?"라는 후회로 돌아온다. 리포팅이 지옥이 되거나, 마이그레이션이 악몽이 되거나. 반대로 잘된 선택은 팀 생산성을 눈에 띄게 끌어올린다.

이 시리즈에서는 단순한 스펙 비교가 아니라, 실제로 어떤 상황에서 무엇을 고를지를 중심으로 이야기한다.

2. PostgreSQL의 철학

"구조가 곧 힘이다"

PostgreSQL은 1986년 UC 버클리에서 시작된, 40년 가까운 역사를 가진 오픈소스 관계형 데이터베이스다. 2026년 현재도 DB-Engines 랭킹에서 꾸준히 상위권을 유지하며, 엔터프라이즈와 스타트업 양쪽에서 폭넓게 채택되고 있다.

PostgreSQL의 핵심 모델은 테이블, 행, 외래 키, SQL이다. 데이터는 명시적인 스키마 위에 올라가고, 마이그레이션을 통해 구조가 변경된다. 딱딱하게 느껴질 수 있지만, 이 구조가 주는 이점은 크다.

PostgreSQL이 빛나는 순간:

• 사용자·주문·상품·권한처럼 명확한 엔티티와 관계가 있는 도메인
• 한 트랜잭션 안에서 여러 테이블을 동시에 수정해야 하는 멀티 테이블 ACID 보장이 필요한 상황
• GROUP BY, SUM, JOIN이 빈번한 리포팅 및 분석 쿼리
• Prisma, TypeORM 등 ORM과 타입 안전성을 중시하는 팀

-- 최근 30일 사용자별 주문 집계 — JOIN + GROUP BY가 자연스러운 환경이라면 PostgreSQL이 제격이다
SELECT
  u.name,
  COUNT(o.id)   AS order_count,
  SUM(o.total)  AS total_spent
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created_at >= NOW() - INTERVAL '30 days'
GROUP BY u.id
ORDER BY total_spent DESC;

PostGIS(지리정보), pgvector(벡터 검색), TimescaleDB(시계열) 등 풍부한 확장 생태계도 PostgreSQL의 강점이다. 특히 AI 임베딩과 연계한 벡터 검색 용도로 PostgreSQL + pgvector 조합이 주목받고 있다.

3. MongoDB의 철학

"유연성이 곧 속도다"

MongoDB는 2009년 등장한 문서 지향(Document-Oriented) 데이터베이스로, JSON 유사 형태인 BSON 도큐먼트를 컬렉션에 저장한다. 유연한 스키마 덕분에 초기 개발 속도가 빠르고, 데이터 구조가 자주 바뀌는 환경에 강하다.

MongoDB의 핵심 모델은 컬렉션과 도큐먼트다. 하나의 도큐먼트 안에 중첩된 배열, 선택적 필드, 다양한 구조가 공존할 수 있다. 이는 정규화보다 비정규화(Denormalization) 를 우선시하는 설계 철학으로 이어진다 — "읽는 방식에 맞게 저장하라."

MongoDB가 빛나는 순간:

• 사용자 프로필·이벤트 로그처럼 문서마다 구조가 다를 수 있는 데이터
• "프로젝트와 그 안의 모든 태스크·댓글을 한 번에 가져오기"처럼 중첩 데이터를 단위로 읽는 경우
• 빠른 프로토타이핑이 필요하거나 스키마가 자주 진화하는 초기 단계
• 대규모 수평 확장(샤딩)이 예상되는 시스템

// 중첩 도큐먼트 구조가 자연스러운 환경이라면 MongoDB가 어울린다
{
  "_id": "proj_123",
  "title": "2026 리뉴얼 프로젝트",
  "owner": { "id": "user_42", "name": "김개발" },
  "tags": ["urgent", "design"],
  "tasks": [
    {
      "title": "와이어프레임 작성",
      "status": "done",
      "comments": [
        { "author": "이기획", "text": "LGTM!", "at": "2026-03-01" }
      ]
    }
  ]
}

한 가지 주의할 점이 있다. "유연한 스키마"를 "설계 불필요"로 오해하면 안 된다. 인덱스 전략, 도큐먼트 크기 관리, 쿼리 패턴 설계는 MongoDB에서도 동일하게 중요하다. 설계를 안 해도 된다는 게 아니라, 다르게 설계한다는 것이다.

4. 핵심 차이 한눈에 보기

선택의 핵심은 아래 두 질문으로 압축된다.

5. 2026년 현재 생태계 현황

2026년 현재 두 데이터베이스 모두 성숙도가 높다. 주목할 만한 흐름을 짚어보면:

PostgreSQL 진영

• Supabase와 Neon의 부상으로 PostgreSQL의 서버리스·클라우드 접근성이 대폭 향상됐다. 특히 Neon의 브랜치 기능은 개발·스테이징 환경 관리를 편리하게 만들었다.
• pgvector 확장의 성숙으로 AI 임베딩 저장소로서 PostgreSQL 활용이 급증했다. RAG(Retrieval-Augmented Generation) 파이프라인에서 별도의 벡터 DB 없이 PostgreSQL 하나로 해결하는 사례가 늘고 있다.

MongoDB 진영

• MongoDB Atlas가 멀티클라우드 전략의 핵심으로 자리잡았다. Atlas Vector Search를 통해 MongoDB 역시 AI 워크로드를 적극 수용하고 있다.
• Prisma가 MongoDB를 지원하면서 타입 안전한 문서 DB 접근이 가능해졌다.

흥미로운 점은 두 진영 모두 상대방의 강점을 흡수하고 있다는 것이다. PostgreSQL은 JSONB와 확장으로 유연성을 높이고, MongoDB는 트랜잭션과 스키마 검증을 강화했다. 그럼에도 설계 철학의 근본 차이는 여전히 유효하다.

6. 마치며

이번 Part 1에서는 두 데이터베이스의 근본적인 철학과 2026년 현재 생태계 흐름을 살펴봤다.

핵심 메시지를 한 줄로 요약하자면:

PostgreSQL은 "어떤 구조인가"로 시작하고, MongoDB는 "어떻게 읽힐 것인가"로 시작한다.

이 차이를 이해하면 선택이 한결 명확해진다.

Part 2 예고:

• 트랜잭션이 필요한 결제 시스템 — 무엇을 써야 하나?
• 실시간 이벤트 로그, 가변 폼 데이터 — 문서 DB의 진가
• Nest.js + TypeScript 환경에서의 실전 판단 기준
• SQL을 모르는 팀, 집계 파이프라인이 두려운 팀을 위한 조언