조용한 개발 노트

MongoDB를 두고 이런 평가를 자주 본다.“쓰기에는 강한데, 설계가 어렵다.” “확장은 쉬운데, 운영은 복잡하다.”이 평가는 절반만 맞다.MongoDB의 복잡함은 구현이 어설퍼서가 아니라, 처음부터 풀고자 한 문제가 달랐기 때문이다.이 마지막 글에서는 MongoDB 전반을 관통하는 설계 선택의 방향을 정리한다.MongoDB의 출발점은 “관계”가 아니었다MongoDB는 관계형 모델의 연장선에서 출발하지 않았다.대신, 다음 질문을 출발점으로 삼았다.“이 요청은 어떤 데이터를 항상 함께 사용하나?”이 질문은 Document 모델, Embedded 구조, Join 회피로 이어졌다.결과적으로 MongoDB는 관계를 재구성하는 DB가 아니라, 요청 단위 데이터를 빠르게 다루는 DB가 되었다.일관성보다 “접근 경..

MongoDB를 오래 써본 사람일수록 이런 질문을 던진다.“왜 MongoDB는 처음부터 트랜잭션을 제공하지 않았을까?”이 질문에는 “기술력이 부족해서”라는 답이 붙기 쉽다. 하지만 실제 이유는 정반대다.MongoDB는 트랜잭션이 없는 구조를 전제로 최적화된 데이터베이스였고, 그 전제를 깨는 순간 전체 설계가 달라지기 때문이다.MongoDB가 처음부터 보장한 원자성MongoDB는 초기부터 다음 원자성을 강하게 보장해왔다.단일 Document 단위 원자성하나의 Document에 대한 쓰기는 항상 중간 상태 없이 적용되거나, 아예 적용되지 않는다.이 보장은 MongoDB 데이터 모델의 핵심 전제다.이 보장만으로 충분했던 이유MongoDB가 타깃으로 삼은 초기 워크로드는 다음과 같은 특성을 가졌다.요청 단위 데..

MongoDB를 써본 개발자들이 공통으로 느끼는 인상이 있다.“대량 쓰기나 잦은 업데이트에서도 생각보다 잘 버틴다.”이 체감은 우연이 아니다. MongoDB의 Document 모델은 쓰기 경로를 단순화하는 방향으로 설계되었다.이 글에서는 MongoDB 공식 문서를 기준으로, Document 모델이 왜 쓰기에 강한지, 그 내부 구조적 이유를 정리한다.쓰기 성능은 ‘몇 번 만지느냐’의 문제다데이터베이스에서 쓰기 비용은 대체로 다음 질문으로 환원된다.몇 개의 레코드를 수정하는가?몇 개의 구조를 동시에 갱신하는가?얼마나 넓은 범위를 잠그는가?MongoDB는 이 질문들에 대해 가능한 한 단순한 답을 택한다.“하나의 문서만 수정한다.”Document 단위 원자성이 주는 이점MongoDB에서 쓰기의 기본 단위는 Do..

MongoDB를 설명할 때 흔히 이렇게 말한다.“관계형 데이터베이스가 아니다.”하지만 이 설명은 MongoDB를 이해하는 데 거의 도움이 되지 않는다. 중요한 질문은 이것이다.“MongoDB는 무엇을 포기했고, 무엇을 얻으려 했을까?”이 글에서는 MongoDB 공식 문서를 기준으로, MongoDB가 왜 관계형 모델을 버리고 Document 모델을 선택했는지를 내부 구조 관점에서 정리한다.관계형 모델이 전제로 하는 것관계형 데이터베이스는 다음 가정을 전제로 설계되었다.데이터는 정규화된다중복은 피해야 한다Join으로 관계를 복원한다이 모델은 데이터 정합성과 무결성을 유지하는 데 매우 강력하다.하지만 이 강점은 특정 환경에서 비용으로 바뀐다.Join은 언제 비용이 될까Join은 논리적으로 우아하지만, 실행 관..