1M+ 레코드 규모 트랜잭션 B2B 앱에서 Postgres 대 MongoDB
귀사의 B2B 제품은 작년에 제품-시장 적합성(product-market fit)에 도달했습니다. 오늘 기준 주 데이터베이스에는 120만 개의 레코드가 쌓였고, 피크 시간대에는 응답 시간이 400ms를 넘어서기 시작했으며, 인프라 청구서는 방금 두 배로 뛰었습니다. 다음 분기를 또다시 잘못된 엔진 튜닝에 쏟기 전에, 처음부터 올바른 데이터베이스를 선택했는지, 아니면 지금 전환하는 것이 또 한 해의 우회책보다 더 저렴한지를 되짚어볼 필요가 있습니다.
"아무거나 하나 고르라"는 조언이 조용히 무너지는 지점
Postgres 대 MongoDB 논쟁은 오래되었지만, 대다수의 팀은 여전히 감(感)으로 선택을 내립니다. 팀의 누군가가 Postgres를 알고 있었거나, 튜토리얼이 MongoDB를 사용했기 때문에 그것이 기본값이 된 것입니다. 이 선택은 처음 10만 레코드까지는 보이지 않습니다. 100만 행과 수천 명의 동시 사용자를 넘어서면, 잘못된 선택의 대가가 느린 대시보드, 주말 화재 진압, 그리고 엔지니어링 리드가 제출하는 값비싼 재설계 제안서의 형태로 드러나기 시작합니다.
두 엔진 모두 훌륭합니다. 둘 다 거대한 프로덕션 워크로드를 구동하고 있습니다. 그러나 각기 다른 데이터 형태와 다른 보증(guarantee)에 최적화되어 있으며, B2B 트랜잭션 앱은 정확히 이 두 엔진이 갈라지는 축을 압박합니다. 이 유형의 애플리케이션에서 가장 중요한 네 가지 트레이드오프는 일관성, 대규모에서의 쿼리 지연 시간, 소유 비용, 그리고 변경 비용입니다.
일관성은 취향이 아니라 비즈니스 리스크입니다
트랜잭션 B2B 시스템(청구서, 주문, 계약, 재고, 급여)에서 데이터베이스의 기본 일관성 모델은 취향 문제가 아닙니다. 실패했을 때 손익계산서에 드러나는 비즈니스 리스크입니다.
Postgres는 성숙한 관계형 엔진으로, 강력한 ACID 보증, 실제 외래 키(foreign key), 그리고 즉시 사용 가능한 직렬화 가능(serializable) 격리 수준을 제공합니다. 청구 서비스가 인보이스를 커밋할 때, 해당 라인 항목이 존재한다는 것, 고객 크레딧이 원자적으로(atomically) 차감되었다는 것, 그리고 동시 읽기가 미완료된 쓰기를 볼 수 없다는 것을 보장할 수 있습니다. 재무와 인접한 워크플로우에서 이러한 정확성은 비용을 지불할 만한 가치가 있습니다.
MongoDB는 그 격차를 상당히 좁혔습니다. 다중 문서 ACID 트랜잭션은 4.0부터 프로덕션 준비가 완료되었으며, 단일 문서 쓰기는 언제나 원자적이었습니다. 그러나 기본값은 여전히 엄격한 정확성보다 가용성과 유연한 스키마 쪽으로 기울어져 있습니다. 다중 문서 트랜잭션에는 측정 가능한 성능 비용이 따르고, 인덱스는 신중하게 관리되어야 하며, 스키마 드리프트(schema drift)는 잘못된 리포트가 고객 앞에서 이를 노출시킬 때까지 숨어 있을 수 있습니다.
엔지니어링 트레이드오프는 비즈니스 리스크에 직접적으로 매핑됩니다. 고객 대상 리포트의 잘못된 숫자 하나가 고객사를 잃게 만드는 비용을 초래한다면, 기본적으로 정확성을 강제하는 데이터베이스를 선호해야 합니다. 워크로드가 대부분 추가 전용(append-only) 텔레메트리이거나 최종적 일관성(eventual consistency)이 허용되는 사용자 생성 콘텐츠라면, 이 제약은 덜 중요합니다.
1M+ 레코드 규모에서의 지연 시간
두 엔진 모두 100만 레코드를 훨씬 넘어서까지 확장됩니다. 실제 차이는 이들을 빠르게 유지하기 위해 얼마나 많은 작업을 해야 하느냐에 있습니다.
Postgres는 "평범한" 읽기 패턴에서 승리합니다: 경계가 있는 결과 집합, 인덱싱된 조인, 예측 가능한 필터를 가진 잘 구성된 쿼리. 적절히 인덱싱된 Postgres 테이블은 수억 행에 이르기까지 한 자릿수 밀리초 단위로 포인트 조회(point lookup)를 처리하며, 쿼리 플래너는 대개 형편없이 작성된 쿼리에서도 회복할 수 있습니다. Postgres가 힘겨워하는 지점은 경계가 없는 문서 읽기, 깊게 중첩된 비정규화 구조, 그리고 스키마가 극심하게 변동하는 워크로드입니다.
MongoDB는 접근 패턴이 진정으로 문서 형태일 때 승리합니다: 하나의 쿼리가 API 응답에 깔끔하게 매핑되는 하나의 중첩된 객체를 반환하고, 핫 패스(hot path)에 조인이 없는 경우. 이는 네트워크 왕복과 직렬화 오버헤드를 제거합니다. 함정은 이것이 첫날부터 문서 경계(document boundary)를 올바르게 설계했을 때만 유효하다는 점입니다. 그 경계가 잘못되었을 때 (그리고 초기 제품 결정은 추측이었기 때문에 종종 그렇습니다) 결국 MongoDB가 최적화된 적이 없는 컬렉션 간 조회(cross-collection lookup)를 하게 되며, 지연 시간은 동등한 Postgres 조인보다 더 빠르게 저하됩니다.
대시보드, 필터 가능한 목록, 그리고 트랜잭션 데이터 위에 계층화된 분석 리포트를 가진 B2B 앱의 경우, Postgres는 1M+ 레코드 규모에서 중앙값 지연 시간 경쟁에서 거의 항상 승리합니다.
실제 비용 그림
클라우드 가격 페이지는 Postgres와 MongoDB를 비슷하게 보이도록 만듭니다. 실제 소유 비용은 그렇지 않습니다.
Postgres는 범용 상품(commodity)입니다. 모든 주요 클라우드가 관리형 서비스를 제공하고, 많은 엔지니어가 튜닝 방법을 알고 있으며, 오픈 소스 Postgres는 노트북에서와 프로덕션에서 동일하게 실행됩니다. 새벽 2시에 무언가 고장 났을 때, 답을 찾을 수 있습니다.
관리형 MongoDB는 편리하지만, 백업, VPC 피어링, 감사 로깅이 포함된 전용 클러스터로 넘어가는 순간 프리미엄 가격이 매겨집니다. MongoDB를 자체 호스팅하는 것은 가능하지만, 현재 시장에서 Postgres 운영 역량보다 더 드물고 더 비싼 운영 역량을 요구합니다.
더 큰 비용은 이차적 비용(second-order cost)입니다: 스키마 마이그레이션, 인덱스 튜닝, 화재 진압에 연간 몇 명의 엔지니어 시간이 투입되는가? 저희가 함께 일하는 팀들은 일상적으로 이를 3~5배 과소평가합니다. 팀에게 분기당 2주의 엔지니어링 시간을 절약해 주는 데이터베이스는, 인보이스에 찍힌 스티커 가격과 무관하게 그 비용을 여러 배로 회수합니다.
각 엔진이 실제로 승리하는 지점
Postgres를 선택해야 하는 경우는 다음과 같습니다: 데이터가 본질적으로 관계형일 때(고객, 주문, 인보이스, 라인 항목), 강력한 일관성과 실제 참조 무결성이 필요할 때, 팀이 소규모이고 데이터베이스 전문가를 감당할 수 없을 때, 또는 분석 읽기와 대시보드가 쓰기와 같은 시스템에 존재할 때.
MongoDB를 선택해야 하는 경우는 다음과 같습니다: 문서가 진정으로 중첩되어 있고 거의 조인되지 않을 때(제품 카탈로그, CMS 콘텐츠, 대용량 이벤트 페이로드), 리전에 걸친 수평적 쓰기 확장이 필요하고 최종적 일관성을 수용할 수 있을 때, 스키마가 빠르게 진화하고 강제보다 유연성을 중시할 때, 또는 이미 이를 잘 운영할 운영 전문성을 갖추고 있을 때.
대부분의 B2B 트랜잭션 앱의 경우, 정직한 자기 평가는 Postgres에 도달합니다. 그렇다고 MongoDB가 틀렸다는 뜻은 아닙니다. 기본값은 팀의 친숙함이 아니라 워크로드의 형태에 의해 획득되어야 한다는 뜻입니다.
이미 프로덕션에 있다면 실용적인 경로
이미 잘못된 엔진에서 프로덕션을 운영 중이라면, 성급하게 마이그레이션하지 마십시오. 재작성은 데이터베이스 문제를 해결하는 가장 값비싼 방법입니다. 측정으로 시작하십시오: 가장 느린 열 개의 쿼리를 프로파일링하고, 여러분이 흡수하고 있는 운영 오버헤드의 연간 비용을 계산하며, 두세 개의 가장 뜨거운 워크로드에 대한 타겟팅된 마이그레이션 비용을 현상 유지의 비용과 대조하여 산정하십시오.
때로는 올바른 답이 하이브리드입니다. 현재 시스템은 잘하는 것에 대해 유지하고, Postgres 또는 MongoDB는 오직 다른 엔진이 진정으로 더 적합한 워크로드에 대해서만 나란히 도입하십시오. 이는 전면 재작성보다 더 작고 검증 가능한 베팅이며, 전체 제품을 그 가정에 커밋하기 전에 가정을 검증할 수 있게 해줍니다.
1만 레코드 규모에서 선택한 데이터베이스가 1천만 레코드 규모에서 올바른 데이터베이스인 경우는 드뭅니다. 고통스러운 재플랫폼을 피하는 팀은 불이 났을 때가 아니라 정해진 주기에 따라 선택을 재검토하는 팀입니다. 귀사의 제품이 그 규모에 접근하고 있고 아키텍처에 대한 경험 있는 두 번째 의견을 원하신다면, MerkTechs 엔지니어링 팀은 다음 스케일링 청구서가 도착하기 전에 귀사의 CTO와 마주 앉아 실제 워크로드에 대한 트레이드오프를 함께 살펴보게 되어 기쁠 것입니다.