172. 폴리글랏 퍼시스턴스 (Polyglot Persistence)

핵심 인사이트: 모든 데이터를 오라클(RDBMS) 하나에 억지로 쑤셔 넣던 시절이 있었다. 하지만 장바구니 데이터는 Redis에, 수억 개의 로그는 Cassandra에, 친구 관계는 Neo4j에 담는 것이 훨씬 빠르다. 마이크로서비스마다 "자신의 특성에 가장 잘 맞는 DB"를 골라서 섞어 쓰는 화려한 뷔페 전략이 바로 폴리글랏 퍼시스턴스다.

Ⅰ. 폴리글랏 퍼시스턴스 (Polyglot Persistence)의 개념

'여러 언어를 구사하는(Polyglot)'이라는 뜻과 '데이터 지속성(Persistence)'이 결합된 단어입니다. 마이크로서비스 아키텍처(MSA) 환경에서 전체 시스템을 단일 데이터베이스(RDBMS 등)로 통합하지 않고, 각 마이크로서비스가 다루는 데이터의 성격과 요구사항(속도, 구조, 복잡도)에 맞춰 서로 다른 종류의 DB(NoSQL, Graph DB, RDBMS)를 혼합하여 선택하고 운영하는 아키텍처 설계 패턴입니다.

Ⅱ. MSA와 데이터베이스 분리 (Database per Service)

MSA의 절대 원칙 중 하나는 "각 마이크로서비스는 자신만의 독립적인 DB를 가져야 한다(Database per Service)"입니다. DB가 쪼개졌으니, 굳이 모든 서비스가 똑같은 MySQL을 쓸 이유가 사라진 것입니다.

[ e-커머스 시스템의 폴리글랏 퍼시스턴스 적용 예시 ]

   (MSA 클라이언트)
         │
 ┌───────┴───────┐
 │ API Gateway   │
 └─┬───┬───┬───┬─┘
   │   │   │   │
   ▼   │   │   │ [상품 카탈로그 서비스] ──▶ (문서형 DB) MongoDB (상품 스펙이 제각각임)
       │   │   │
       ▼   │   │ [결제/재고 서비스]    ──▶ (RDBMS) MySQL / Oracle (ACID 트랜잭션과 무결성이 생명임)
           │   │
           ▼   │ [쇼핑 카트 서비스]    ──▶ (Key-Value) Redis (초고속 읽기/쓰기가 필요하며 데이터가 날아가도 치명적이지 않음)
               │
               ▼ [추천 서비스]         ──▶ (Graph DB) Neo4j ("A상품을 산 고객이 B상품도 샀다"는 복잡한 관계망 쿼리가 필요함)

Ⅲ. 폴리글랏 퍼시스턴스의 장점

  • 데이터 처리 최적화: 각 서비스가 자신의 데이터 성격에 가장 완벽하게 부합하는 DB 엔진을 사용하므로, 시스템 전체의 응답 속도와 성능이 극대화됩니다.
  • 벤더 종속성(Lock-in) 탈피: 비싼 오라클 라이선스를 결제 시스템에만 쓰고, 나머지 단순 서비스는 무료 오픈소스 DB로 대체하여 IT 인프라 비용을 극적으로 낮출 수 있습니다.

Ⅳ. 도입 시 치명적 한계 및 과제

  • 학습 곡선 폭발: 개발팀과 DBA가 관리해야 할 DB 종류가 5~6개로 늘어나므로, 모니터링, 백업, 장애 복구 지식을 모두 마스터해야 하는 끔찍한 운영 부하가 발생합니다.
  • 분산 트랜잭션의 악몽: MongoDB에 있는 상품 데이터를 지울 때 MySQL에 있는 결제 데이터도 같이 취소해야 할 경우, 전통적인 2PC(Two-Phase Commit)나 Saga 패턴 같은 복잡한 분산 트랜잭션 설계가 강제됩니다.

📢 섹션 요약 비유: 모놀리식 시절에는 김치찌개, 스테이크, 초밥을 전부 '뚝배기(RDBMS)' 하나에 담아 내왔습니다. 하지만 폴리글랏 퍼시스턴스 시대에는 김치찌개는 뚝배기에, 스테이크는 뜨거운 철판(Redis)에, 초밥은 시원한 나무 도마(MongoDB)에 담아내어 각 음식의 맛을 100% 끌어올리는 맞춤형 플레이팅 시스템입니다. 식기 세척(DBA 관리)이 힘들어진다는 단점만 빼면 말이죠.