새 프로젝트를 시작할 때 기술 스택을 고르는 회의가 있었다. 캐시는 Redis, 검색은 Elasticsearch, 벡터 저장은 Pinecone, 메인 데이터는 MongoDB... 각각의 선택에는 그럴듯한 이유가 있었다. 그런데 6개월이 지나자 문제가 생겼다. 데이터가 여기저기 흩어져서 일관성을 유지하기가 너무 어려웠고, 모니터링 포인트가 네 군데나 됐다.
2026년의 반전 - "그냥 Postgres를 쓰자"
2026년 개발자 커뮤니티에서 조용히 퍼지고 있는 철학이 있다. "It's 2026. Just Use PostgreSQL." 한국 개발자 뉴스 사이트 GeekNews에서도 이 주제가 뜨거운 토론을 불러일으켰다.
핵심 주장은 이렇다. 대부분(사스상 99%)의 서비스는 여러 데이터베이스를 조합할 필요가 없다. PostgreSQL 하나로 관계형 데이터, JSON 문서, 전문 검색, 벡터 임베딩(pgvector 익스텐션)까지 처리할 수 있다. 복잡한 다중 DB 아키텍처는 스타트업 단계에서는 오히려 독이 된다.
PostgreSQL이 모든 걸 할 수 있다는 증거
Redis로 처리하던 캐시를 PostgreSQL의 UNLOGGED TABLE + partial index로 대체했더니 오히력 빨랐다는 실제 사례가 2026년 1월 Medium에 올라와 큰 반향을 일으켰다. UNLOGGED TABLE은 WAL(Write-Ahead Log)을 사용하지 않아 쓰기 속도가 극적으로 빠르고, 세션 캐시 같이 재시작 시 초기화해도 되는 데이터에 완벽히 맞는다.
전문 검색은 어떨까. Elasticsearch 없이 PostgreSQL의 tsvector\uc640 GIN 인덱스만으로 한국 전문 검색을 구현하는 것이 가능하다. 물론 초대형 서비스에서는 한계가 있지만, 월간 활성 사용자 수십만 명규모까지는 충분히 커버된다.
AI 시대의 핵심인 벡터 검색도 마찬가지다. pgvector 익스텐션을 설치하면 임베딩 벡터를 저장하고 코사인 유사도 검색을 바로 할 수 있다. Pinecone이나 Qdrant 없이 RAG 파이프라인을 Postgres 하나로 구축할 수 있다는 것이다.
그렇다면 Redis, MongoDB는 언제 필요한가
모든 것에 Postgres가 정답인 건 아니다. 초당 수십만 건의 실시간 이벤트 스트림 처리가 필요하다면 Redis Streams나 Kafka가 낫다. 스키마가 극도로 유동적이고 수평 샤딩이 필수적인 경우에는 MongoDB가 여전히 좋은 선택일 수 있다.
결국 기준을 이렇다. 서비스가 성장해서 실제 병목이 생기기 전까지는 Postgres 하나로 버텨라. 특정 기능의 병목이 명확히 측정됐을 때 빂로소 전문 도구를 추가하라. 추측으로 복잡한 스택을 미리 도입하는 것은 오버엔지니어링이다.
PostgreSQL 기본 세팅 - 처음부터 제대로
Postgres를 도입할 때 반드시 해야 하는 기본 설정이 있다.
-- 연결 풀링: PgBouncer 사용 권장
-- postgresql.conf 주요 설정
max_connections = 100
shared_buffers = 256MB -- RAM의 25%
effective_cache_size = 1GB -- RAM의 75%
work_mem = 4MB
maintenance_work_mem = 64MB
-- 슬로우 쿼리 로깅
log_min_duration_statement = 1000 -- 1초 이상 쿼리 로깅
그리고 반드시 explain analyze로 쿼리 실행 계획을 확인하는 습관을 팀 전체에 심어야 한다. 인덱스 없는 쿼리 하나가 전체 서비스를 멈출 수 있다.
함께 읽으면 좋은 글
- 벡터 데이터베이스 완전 정복 - RAG 구현을 위한 Pinecone vs Qdrant vs Milvus 실전 비교
- 6개월 후의 나를 위해 코드를 짜다 - 2026년 AI 시대에 더 중요해진 클린코드 5원칙
참고자료
'IT & 개발' 카테고리의 다른 글
| 코드 리뷰에서 진짜 봐야 할 것 — 스타일 지적을 넘어 설계를 읽는 기술 (0) | 2026.03.30 |
|---|---|
| AI 시대 개발자의 생존법 - 코더에서 오케스트레이터로의 전환 (0) | 2026.03.17 |
| AI 에이전트가 내 코드를 리뷰한다 - 추론형 LLM이 바꾸는 2026년 개발 워크플로우 (0) | 2026.03.16 |
| 바이브 코딩의 시대, 진짜 웹 개발자에게 남은 것 - 2026년 프론트엔드 생존 전략 (0) | 2026.03.16 |
| Docker에서 Podman으로 - 데모늬리스 아키텍처가 2026년 DevOps 표준이 되는 이유 (0) | 2026.03.16 |
댓글