Lv.2 초급PostgreSQL

2026.04.1232분 읽기Lv.2 초급

시리즈왜 PostgreSQL이죠? · 파트 4/5시리즈 허브 보기

왜 PostgreSQL이죠? Part 4 — MongoDB·Oracle 탈출기: 실제 마이그레이션 사례

이미 MongoDB나 Oracle을 쓰고 있다면, PostgreSQL 이전은 ‘언젠가’가 아니라 예산·성능·운영으로 바로 직결됩니다. 이 글은 ‘간단하다’와 ‘절대 하지 마라’ 사이의 현실을 다루며, Infisical의 MongoDB→PostgreSQL 전환과 비용 변화, NoSQL에서 반복되는 구조적 부담, Oracle 탈출이 기술·조직 양쪽에서 왜 느려지는지를 사례 중심으로 정리합니다. 인용되는 비율·TCO 수치는 공개 블로그·케이스 스터디·벤더 리포트 성격이 강하므로, 비교 기간과 포함 비용(라이선스·인력·마이그레이션 공사비)을 나누어 읽을 필요가 있습니다. 스키마 재설계와 쿼리 정리처럼 DB 교체와 함께 들어간 개선 효과도 분리해서 보는 편이 안전합니다. 마지막에는 이전을 서두를지 말지 스스로 점검할 짧은 진단 프레임을 덧붙였습니다.

시리즈 구성

Part 1 — 숫자로 보는 PostgreSQL의 현재 위치

Part 2 — 빅테크는 왜 PostgreSQL을 선택했나

Part 3 — 스타트업의 선택: 속도와 비용의 최적점

Part 4 — MongoDB·Oracle 탈출기: 실제 마이그레이션 사례 (현재 편)

Part 5 — 생태계 확장: pgvector, PostGIS, TimescaleDB

들어가며: "이미 다른 DB를 쓰고 있다"는 말이 이유가 되지 않는 시대
MongoDB → PostgreSQL: Infisical의 전환 — 비용 50% 절감의 실체
MongoDB가 만들어내는 고통들: 구조적 문제를 직시하다
Oracle → PostgreSQL: 엔터프라이즈의 수십 년 관행을 바꾸는 것
마이그레이션의 현실: 장밋빛 약속과 실제 고통
성공한 마이그레이션의 공통 패턴
마치며: 언제 이전해야 하고, 언제 그냥 있어야 하나

1. 들어가며: "이미 다른 DB를 쓰고 있다"는 말이 이유가 되지 않는 시대

"지금 MongoDB 씁니다. 이전하면 얼마나 힘든가요?"

이 질문에 정직하게 답하는 글은 드뭅니다. 대부분은 두 극단 중 하나입니다 — "간단합니다, 이전하세요"이거나, "절대 하지 마세요, 너무 복잡합니다"이거나.

Part 4에서는 그 중간 어딘가의 진실을 다룹니다. MongoDB에서, Oracle에서 PostgreSQL로 실제로 전환한 조직들의 경험 — 무엇이 계기였고, 얼마나 걸렸으며, 무엇이 생각보다 힘들었고, 결과는 어땠는지를 구체적으로 살펴봅니다.

결론부터 말하면: 이전은 쉽지 않습니다. 그리고 대부분의 경우 여전히 할 만한 가치가 있습니다.

수치를 읽는 방법

아래에 등장하는 비용 절감 비율·TCO 감소는 설득력 있는 신호이지만, 출처가 공개 블로그·벤더·케이스 스터디인 경우가 많습니다. 비교에 포함된 비용 항목(CPU·스토리지·인건비·마이그레이션 공사비·지원 계약)과 기간이 문서마다 다르므로, 방향성으로 읽고 세부는 원문 전제를 확인하는 편이 안전합니다.

또한 실제로는 스키마 재설계·쿼리 정리·운영 방식 개선이 동시에 들어가 효과가 섞였을 가능성이 큽니다. "엔진만 바꿔서"와 "같은 프로젝트에서 함께 한 리팩터링"을 구분하지 않으면 주장이 과해 보일 수 있습니다. 본문에서는 가능한 곳에서 그 경계를 짚습니다.

2. MongoDB → PostgreSQL: Infisical의 전환 — 비용 50% 절감의 실체

Infisical은 애플리케이션 시크릿(API 키, 인증서, SSH 키 등)을 중앙에서 관리하는 오픈소스 플랫폼입니다. 2024년 초 기준으로 플랫폼은 하루 5천만 건 이상의 시크릿을 처리하고 있었고, 그 아래에서 MongoDB가 돌아가고 있었습니다.

왜 MongoDB로 시작했는가

창업 초기 Infisical 팀이 MongoDB를 고른 이유는 지극히 현실적이었습니다. 팀에게 익숙했고, Mongoose ORM과의 조합이 빠른 개발을 허용했으며, 스키마를 고민하지 않고 빠르게 기능을 추가할 수 있었습니다. 스타트업 초기의 전형적인 합리적 선택이었습니다.

문제는 Infisical이 성장하면서 수면 위로 올라왔습니다. 핵심 데이터가 본질적으로 관계형이었기 때문입니다 — 시크릿, 프로젝트, 환경, 사용자, 권한이 서로 복잡하게 연결되어 있었습니다. MongoDB에서 이를 처리하려면 관계형 조인을 흉내 내는 $lookup 연산을 무수히 사용해야 했고, 이 연산들은 비효율적이어서 데이터베이스와 애플리케이션 인스턴스를 계속 스케일업해야 했습니다.

트랜잭션 설정도 골치였습니다. MongoDB에서 트랜잭션을 사용하려면 클러스터 모드 설정이 필요했는데, 이는 Infisical을 자체 호스팅하려는 고객들에게 높은 진입 장벽이 됐습니다. 간단한 PoC 환경을 구성하는 것조차 프로덕션 수준의 MongoDB 설정을 요구했습니다.

스키마리스 설계의 양면성도 드러났습니다. 유연성이라는 이름 아래 Mongoose의 통제 범위를 벗어나 데이터베이스를 직접 접근했을 때 데이터 불일치가 발생하기 시작했습니다.

전환 결정과 실행

Infisical은 PostgreSQL로의 전환을 결정했습니다. 선택 이유는 기술적 우위만이 아니었습니다. 광범위한 커뮤니티, 풍부한 문서, 클라우드 프로바이더들의 관리형 서비스 호환성, 그리고 오픈소스 특성이 자체 호스팅 사용자들의 운영 부담을 줄여준다는 판단이었습니다.

마이그레이션 작업의 규모는 작지 않았습니다. 새 데이터베이스 스키마 설계, 쿼리 로직 재작성, 수천만~수억 건의 레코드 이전이 포함됐습니다. ORM은 Mongoose 대신 Knex.js(쿼리 빌더)를 선택했습니다 — 완전한 SQL 제어를 원했지만 타입 안전성과 마이그레이션 툴링이 필요했기 때문입니다.

전환 방식에서 다운타임은 허용하지 않았습니다. 대신 쓰기 작업만 일시 중단하는 방식으로 타협점을 찾았습니다. 시크릿 플랫폼 특성상 사용자들은 주로 시크릿을 읽어오는 작업을 수행하고, 설정을 변경하는 쓰기 작업은 상대적으로 드물었기 때문에 이 트레이드오프는 수용 가능했습니다.

이 전략이 성립하려면 읽기 비중이 높고, 쓰기를 잠시 줄여도 비즈니스에 치명적이지 않아야 합니다. 주문·결제·실시간 협업처럼 쓰기가 중심인 서비스에 그대로 일반 해법처럼 적용할 수는 없습니다. 트래픽 패턴을 먼저 확인해야 합니다.

마이그레이션 이후의 결과

전환 후 가장 두드러진 변화는 쿼리 최적화로 인한 성능 향상이었습니다. MongoDB에서 자주 발생하던 비효율적인 집계 쿼리와 다중 네트워크 왕복이 조인으로 대체됐고, 이로 인해 데이터베이스와 애플리케이션 인스턴스를 과도하게 스케일업하지 않아도 됐습니다. 공개 사례에 따르면 그 결과 데이터베이스 비용이 50% 감소했다고 합니다.

다만 앞서 말한 대로, 이 수치는 스키마 재설계와 쿼리 재작성이 함께 이루어진 결과에 가깝습니다. "PostgreSQL이라서 자동으로 반값"이 되는 구조는 아닙니다.

데이터베이스 레벨의 유효성 검증이 강화됐고, 자체 호스팅이 훨씬 간단해졌습니다 — 클러스터 모드 없이도 PostgreSQL의 표준 트랜잭션을 사용할 수 있었기 때문입니다. 새로운 기능 개발도 PostgreSQL 버전에만 집중하기로 공식화됐습니다.

3. MongoDB가 만들어내는 고통들: 구조적 문제를 직시하다

Infisical의 사례는 특수한 것이 아닙니다. MongoDB에서 PostgreSQL로 이전한 조직들 사이에서 반복되는 패턴들이 있습니다.

스키마리스의 역설

MongoDB의 스키마리스 설계는 초기엔 자유처럼 느껴집니다. 그런데 시스템이 성장하면서 "자유"는 "카오스"가 됩니다. 같은 필드가 어떤 문서에서는 숫자, 어떤 문서에서는 문자열로 저장되어 있고, 누구도 정확한 스키마를 알지 못하는 상태. 이 상태를 정리하는 데 엄청난 시간이 소요됩니다.

실제 마이그레이션 경험자들이 공통으로 언급하는 상황이 있습니다. 날짜 필드가 MM/DD/YYYY 형식으로 저장된 문서도 있고 DD/MM/YYYY로 저장된 문서도 있습니다. JavaScript는 둘 다 허용했고, MongoDB는 신경 쓰지 않았습니다. PostgreSQL의 TIMESTAMPTZ 타입은 둘 다 거부합니다. 이런 데이터 불일치를 발견하고 해결하는 작업이 실제 이전 시간의 상당 부분을 차지합니다.

집계 파이프라인의 번역 비용

MongoDB의 집계 파이프라인($lookup, $unwind, $group)은 SQL 조인과 문법이 완전히 다릅니다. 한 건 한 건 수작업으로 번역해야 하고, 동작이 미묘하게 다른 경우도 많습니다. 60건의 실제 마이그레이션 케이스를 분석한 한 보고서에 따르면, 4,500개의 MongoDB 쿼리를 재작성하는 데 예상의 세 배가 넘는 7개월이 걸린 사례가 있었습니다.

JSONB는 만능이 아니다

"그냥 MongoDB 문서를 PostgreSQL의 JSONB 컬럼에 넣으면 되지 않나요?" 이 접근이 실패하는 이유는 명확합니다. 그렇게 하면 PostgreSQL로 이전한 의미가 없습니다. JSONB 컬럼에 모든 것을 넣으면 조인도 없고, 외래 키 제약도 없고, 집계 성능도 제대로 나오지 않습니다. 문서 지향 스토어가 필요했다면 MongoDB에 남아 있는 편이 낫습니다. PostgreSQL로 이전하는 이유는 관계형 모델의 장점을 취하기 위해서입니다. 제대로 된 스키마 설계 없이는 그 장점을 얻을 수 없습니다.

4. Oracle → PostgreSQL: 엔터프라이즈의 수십 년 관행을 바꾸는 것

MongoDB 이전이 "창업 초기의 선택을 수정하는 작업"이라면, Oracle에서 PostgreSQL로의 이전은 다른 차원의 문제입니다. 수십 년간 운영해온 미션 크리티컬 시스템, 수백만 줄의 PL/SQL 코드, 수십 년간 쌓인 Oracle 전용 기능 의존성. 여기에 Oracle의 라이선스 계약과 감사(audit) 위협이 더해집니다.

Oracle 라이선스 비용의 현실

Oracle 데이터베이스 라이선스 구조는 단순하지 않습니다. 코어 수 기반 과금, 고가용성·클러스터링·보안 기능의 별도 패키지 가격, 연간 지원 계약비, 그리고 불시에 찾아오는 라이선스 감사. 미드사이즈 기업의 경우 연간 Oracle 계약 비용이 35만~50만 달러에 달하는 사례가 흔하다고 알려져 있습니다.

업계 케이스 스터디들이 일관되게 보고하는 수치가 있습니다. Oracle에서 PostgreSQL로 전환한 뒤 TCO(총소유비용)가 70~90% 감소한다는 것입니다. 이는 라이선스 비용 소멸에만 기인하지 않습니다. 전문 Oracle DBA의 희소성으로 인한 인건비 프리미엄 해소, 고가 특화 하드웨어 요건 완화, 클라우드 플랫폼 이식성 확보도 함께 작용합니다.

12코어 Oracle 배포 환경의 전형적인 케이스에서 연간 라이선스·지원 비용만 38만~42만 달러가 절감된다는 분석도 있습니다. 마이그레이션 자체의 비용(10TB 데이터 기준으로 수십만~수백만 달러 수준)을 감안해도, 대부분의 경우 2~4년 안에 투자 회수가 이루어진다는 주장도 반복됩니다. 다시 한 번, 포함 비용 정의와 비교 연도는 원문을 확인해야 합니다.

Oracle 마이그레이션이 어려운 진짜 이유

비용 절감의 매력은 분명합니다. 그런데 Oracle 마이그레이션이 "하고 싶어도 못 하는" 조직들이 많은 데는 이유가 있습니다.

첫째는 PL/SQL 코드 재작성입니다. Oracle의 저장 프로시저, 패키지, 함수는 PL/SQL로 작성되어 있습니다. PostgreSQL의 PL/pgSQL과 문법이 유사하지만 같지 않습니다. CONNECT BY(계층 쿼리), (+) 조인 표기법, ROWNUM, TO_DATE 동작 방식 등 Oracle 전용 구문들이 PostgreSQL에서는 다르게 처리됩니다. 수십 년간 누적된 수만 줄의 PL/SQL이 있다면, 이 재작성 작업이 몇 달, 혹은 1~2년을 잡아먹습니다.

둘째는 데이터 타입 불일치입니다. Oracle의 VARCHAR2, NUMBER(p,s), DATE(시간 포함), ROWID 같은 타입들은 PostgreSQL에 직접 대응하는 타입이 없거나 동작 방식이 다릅니다. 마이그레이션 도구들이 상당 부분 자동화해주지만, 엣지 케이스는 수작업이 불가피합니다.

셋째는 조직 내 관성입니다. "지금 잘 돌아가는 시스템을 왜 바꾸냐"는 질문은 기술적 질문이 아닙니다. 수십 년간 Oracle에 익숙해진 DBA들, Oracle 전문성을 자산으로 삼는 IT팀, "안 바꾸는 것이 위험 관리"라는 문화가 결합되면 마이그레이션 프로젝트는 기술 문제이기 전에 조직 문제가 됩니다.

돈만이 아닌 손익분기: 기능·운영·규제

비용을 줄이는 대신 새로 떠안는 책임도 짚을 필요가 있습니다. Oracle RAC(Real Application Clusters) 수준의 다중 노드 클러스터링, 일부 고급 보안·감사·암호화 옵션, 벤더가 제공하던 SLA와 전담 지원 체계는 PostgreSQL 생태계에서 다른 제품·운영 패턴으로 대체됩니다. 금융·공공·의료처럼 규제 문서상 "특정 벤더 구성"을 전제로 한 인증이 있다면, 단순 기능 대응표를 넘어서는 검토가 필요합니다.

즉, "라이선스만 없앤다"로 끝나지 않고, 가용성 설계·보안 운영·컴플라이언스 증빙을 누가 어떤 도구로 재구성할지가 별도 과제입니다.

전환 가속화 요인들

그럼에도 Oracle에서 PostgreSQL로의 이전이 가속화되는 이유가 있습니다.

AI 기반 마이그레이션 도구들의 발전입니다. EDB의 마이그레이션 코파일럿, Ora2Pg, AI 어시스턴트 기반 PL/SQL 변환 도구들은 자동화 비율을 높이고 있습니다. 스키마와 데이터 이전의 70% 이상을 자동화할 수 있다는 벤더 주장도 있습니다(물론 비즈니스 로직 검증과 테스트는 여전히 수작업입니다).

클라우드 이전 압력도 Oracle 탈출의 촉매입니다. AWS, GCP, Azure로의 마이그레이션을 추진하는 기업들이 동시에 "이 참에 Oracle도 정리하자"는 결정을 내리는 경우가 많습니다. 클라우드 네이티브 아키텍처와 Oracle의 조합은 비효율이 큽니다.

5. 마이그레이션의 현실: 장밋빛 약속과 실제 고통

마이그레이션 성공 사례들이 강조하는 것과 실제 과정에서 만나는 어려움은 다를 때가 많습니다. 솔직하게 정리하면 다음과 같습니다.

예상보다 오래 걸립니다. MongoDB 마이그레이션의 경우 쿼리 재작성 작업이 예상의 두세 배 시간을 소요하는 경우가 일반적입니다. Oracle 마이그레이션은 규모에 따라 수개월에서 2년까지 걸립니다. "일주일이면 됩니다"라고 말하는 사람의 말은 의심해야 합니다.

데이터 품질 문제는 이전 직전에 발견됩니다. 오랫동안 축적된 데이터의 불일치와 타입 혼용은 마이그레이션 스크립트를 실행하면서 갑자기 표면으로 올라옵니다. 이를 해결하는 데이터 정제 작업이 전체 일정의 발목을 잡습니다.

제로 다운타임 전략은 공짜가 아닙니다. 이중 쓰기(dual-write) + CDC(Change Data Capture) 기반 무중단 마이그레이션은 기술적으로 가장 안전하지만, 구현 비용이 상당합니다. 소규모 팀이라면 짧은 쓰기 중단을 감수하는 것이 현실적일 수 있습니다.

PostgreSQL 튜닝은 별도 학습입니다. PostgreSQL로 전환했다고 해서 곧바로 최적 성능이 나오지 않습니다. shared_buffers, work_mem, max_connections, 인덱스 전략 등 PostgreSQL 고유의 튜닝이 필요합니다. 이 지식이 팀 내에 없다면 습득 시간이 필요합니다.

-- 운영 전 점검 시 자주 만나는 파라미터 예시 (환경마다 값은 다름)
SELECT
  current_setting('shared_buffers') AS shared_buffers,
  current_setting('work_mem') AS work_mem,
  current_setting('max_connections') AS max_connections;

6. 성공한 마이그레이션의 공통 패턴

60건 이상의 실제 마이그레이션 케이스를 분석하면 성공한 프로젝트들에서 반복되는 패턴이 보입니다.

스키마 설계를 가장 먼저, 가장 많은 시간을 들여서 합니다. MongoDB 문서를 JSONB에 그냥 넣는 '쉬운 길'을 택한 프로젝트는 나중에 다시 제대로 된 정규화 작업을 해야 합니다. 처음부터 화이트보드 앞에서 팀 전체가 새 스키마를 설계하는 시간을 투자하는 것이 전체 프로젝트에서 가장 효율적인 투자입니다.

이중 쓰기로 안전망을 먼저 깔고 시작합니다. Reddit이 Aurora PostgreSQL 이전에서 사용한 것과 동일한 패턴입니다. 양쪽 시스템에 동시에 쓰고, 읽기를 점진적으로 전환하며, 이상 없음을 확인한 후 쓰기를 전환합니다. 데이터 소스 전환의 위험을 최소화하는 가장 검증된 방법입니다.

마이그레이션을 근대화 기회로 활용합니다. 단순한 "같은 것을 다른 DB에" 이전이 아니라, 아키텍처를 다시 생각하는 기회로 삼습니다. 파티셔닝 전략 재검토, 불필요한 레거시 데이터 정리, 마이크로서비스 분리 등을 함께 진행한 프로젝트가 순수 기술 이전만 한 프로젝트보다 장기적 성과가 높았습니다.

작은 단위로 먼저 검증합니다. 전체 시스템을 한 번에 이전하는 대신, 가장 변경이 잦은 서비스나 가장 비용이 많이 드는 쿼리 패턴을 가진 모듈부터 시작합니다. 이 과정에서 팀이 PostgreSQL 운영 경험을 쌓고, 조직 내 신뢰도를 높입니다.

7. 마치며: 언제 이전해야 하고, 언제 그냥 있어야 하나

빠르게 점검하는 진단 프레임

아래는 즉시 실행 체크리스트라기보다, 우선순위를 정하기 위한 짧은 점검표입니다.

점검 항목	이전을 더 진지하게 볼 신호
데이터 모델	관계·조인·트랜잭션이 중심인데 NoSQL에서 계속 우회하고 있다
팀 역량	SQL·운영 인력을 6~12개월 안에 확보하거나 학습할 여력이 있다
다운타임	짧은 쓰기 중단 또는 이중 쓰기 도입을 감당할 수 있다
예산·일정	마이그레이션 공사비를 회계적으로 별도 라인으로 볼 수 있다

반대로 당장 서두르지 않아도 될 신호는 다음과 같습니다.

데이터가 진정한 문서 지향적 특성을 가지며, 관계형 쿼리가 거의 없다.
팀 전체가 MongoDB에 깊이 숙련되어 있고, 시스템이 안정적으로 운영되고 있다.
재작성 비용을 감당할 여력(시간, 인력, 예산)이 지금 당장 없다.

이전은 목적이 아니라 수단입니다. 비용을 줄이고, 성능을 개선하고, 개발 생산성을 높이기 위한 수단으로서 PostgreSQL로의 이전이 의미 있는 상황인지를 먼저 판단하는 것이 순서입니다.

그 판단이 "예스"라면, Infisical의 50% 비용 절감과 Oracle 탈출 기업들의 TCO 감소는 단순한 마케팅 수치가 아니라 같은 고민을 먼저 해결한 사람들의 실제 경험에 가깝습니다. 다만 어떤 전제와 어떤 추가 작업이 깔렸는지를 함께 읽어야 합니다.

Part 5에서는 이전의 이유보다 이전 이후의 세계를 다룹니다. PostgreSQL 위에서 단 하나의 확장만 추가함으로써 전혀 다른 문제를 해결하는 생태계 — pgvector, PostGIS, TimescaleDB, ParadeDB — 의 현재를 살펴봅니다.

다음 편 예고 — Part 5: 생태계 확장 — pgvector, PostGIS, TimescaleDB

벡터 검색, 지리정보, 시계열, 전문 검색. 네 가지 전혀 다른 문제를 PostgreSQL 하나 위에서 해결하는 확장들의 현재 수준을 벤치마크와 실제 사례로 들여다봅니다. "단 하나의 데이터베이스로 스택을 단순화한다"는 아이디어가 2026년 기준으로 얼마나 현실적인지를 평가합니다.

참고·출처

Infisical — The Great Migration from MongoDB to PostgreSQL · 마이그레이션 개요 · 셀프호스팅 가이드(문서)
MongoDB — BSON 타입·스키마 검증 (스키마를 강제하지 않으면 필드 형식 혼용이 쌓이기 쉬움)
PostgreSQL — 날짜/시간 타입 · 리소스 설정(shared_buffers 등)
Oracle → PostgreSQL — PostgreSQL Wiki — Oracle 호환·변환 노트 · Ora2Pg · EDB — 마이그레이션 제품 개요
무중단·이중 쓰기 패턴 — Reddit 등 사례는 공개 자료마다 범위가 다름. Aurora 이전·운영 배경은 예를 들어 AWS — Reddit과 Amazon Aurora 사례 등을 참고(본문의 dual-write 설명은 일반적인 단계적 전환 패턴과의 대응)
TCO·Oracle 절감률 — 벤더·컨설팅 리포트마다 전제가 다름. 인용 시 보고서의 비용 항목 정의를 확인할 것(예: EDB 공개 자료 등)

작성: 2026년 4월 · 사례별 수치·구성은 공개 시점의 블로그·발표·보도를 기준으로 하며, 이후 인프라·과금은 변경될 수 있습니다. 인용 시 원문을 확인하세요.