조용한 개발 노트

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

MongoDB를 운영해 본 팀에서 자주 나오는 말이 있다.“쓰기 트래픽이 늘어도 생각보다 잘 버틴다.”이 체감의 핵심에는 MongoDB의 동시성 제어 모델이 있다. 정확히 말하면, MongoDB는 “락이 없다”기보다는 락의 범위를 극도로 좁힌다.동시성 문제의 본질동시성 문제는 결국 이 질문으로 수렴한다.“누가, 어디까지 동시에 바꿀 수 있는가?”관계형 데이터베이스에서는 이 질문에 대한 답이 비교적 넓다.행 단위 락범위 락인덱스 간 간접 충돌이 구조에서는 의도하지 않게 넓은 영역이 잠길 수 있다.MongoDB의 선택: Document 단위MongoDB는 동시성 제어의 기준 단위를 Document로 한정한다.즉, 하나의 Document에 대한 변경은 해당 Document 안에서만 조율된다.다른 Documen..

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

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

앞선 12편에서는 MongoDB Auditing을 통해 데이터 변경의 추적과 책임을 다뤘습니다. 이번 편에서는 운영 환경에서 MongoDB를 사용할 때 성능 문제를 어떻게 감지하고, 무엇을 봐야 하는지를 정리합니다.MongoDB 성능 문제는 보통“어느 날 갑자기 느려졌다”라는 형태로 발견됩니다. 하지만 실제로는 그 전에 이미 여러 신호가 나타나고 있는 경우가 대부분입니다.이번 편에서 다룰 내용MongoDB 성능 이슈의 특징가장 먼저 확인해야 할 지표느린 쿼리를 찾는 방법Index와 성능 지표의 관계실무에서의 점검 순서1) MongoDB 성능 문제의 특징MongoDB 성능 이슈는 다음과 같은 특징을 가집니다.초기에는 잘 드러나지 않는다데이터가 쌓이면서 점진적으로 악화된다특정 쿼리나 특정 시간대에만 발생한다..

앞선 11편에서는 MongoDB에서의 스키마 변경과 운영 환경에서의 마이그레이션 전략을 다뤘습니다. 이번 편에서는 운영 관점에서 빠질 수 없는 주제인 Auditing을 정리합니다.Auditing은 단순히“createdAt, updatedAt을 넣는 것”이 아니라, 데이터 변경에 대한 책임과 추적 가능성을 확보하는 문제입니다.이번 편에서 다룰 내용MongoDB에서 Auditing이 필요한 이유Spring Data MongoDB Auditing 개요@CreatedDate / @LastModifiedDateAuditor(누가 변경했는가) 처리 전략실무에서 자주 하는 실수1) 왜 Auditing이 중요한가?운영 환경에서 가장 자주 받는 질문 중 하나는 이것입니다.“이 데이터, 언제 이렇게 바뀌었나요?”Audit..

앞선 7편에서는 MongoDB 조회 전략을 Query Method → MongoTemplate 흐름으로 정리했습니다. 이번 편에서는 단순 조회를 넘어, 집계·통계·가공이 필요한 순간에 등장하는 Aggregation Pipeline을 다룹니다.Aggregation은 MongoDB에서 “조회 결과를 가공하는 공식적인 방법”에 가깝습니다.이번 편에서 다룰 내용Aggregation이 필요한 이유Aggregation Pipeline의 개념주요 Stage의 역할Spring Data MongoDB에서 Aggregation 사용하기실무에서 Aggregation을 쓰는 기준1) 단순 조회로 해결되지 않는 순간다음과 같은 요구는 단순한 find 조회로는 해결하기 어렵습니다.상태별 주문 건수 집계기간별 매출 합계카테고리별 ..

앞선 6편에서는 MongoDB 성능의 핵심인 Index 설계를 다뤘습니다. 이번 편에서는 그 인덱스를 실제로 활용하는 조회(Query) 전략을 정리합니다.Spring Data MongoDB에서 조회를 구현하다 보면 다음과 같은 고민을 하게 됩니다.“이 조회는 Repository로 충분할까?”“언제부터 MongoTemplate으로 내려가야 할까?”이 글의 목표는 조회 방식을 모두 나열하는 것이 아니라, 언제 내려가야 하는지 판단 기준을 만드는 것입니다.이번 편에서 다룰 내용Query Method의 역할과 장점Query Method가 잘 맞는 조회의 특징Query Method의 한계가 드러나는 순간MongoTemplate + Criteria의 등장 이유실무에서 쓰기 좋은 선택 기준1) Query Method..

앞선 3편에서는 Spring Data MongoDB의 아키텍처와 Repository, MongoTemplate의 역할을 구분했습니다. 이번 편부터는 본격적으로 MongoDB 도메인 모델링으로 들어갑니다.그 출발점이 바로 @Document입니다.이번 편에서 다룰 내용@Document의 역할과 의미Collection 이름 설계 기준@Id와 MongoDB의 _idObjectId를 그대로 쓸지, 변환할지@Field로 필드명을 명시하는 이유1) @Document는 무엇을 의미하는가?Spring Data MongoDB에서 @Document는 이 클래스가 MongoDB의 Document와 매핑된다는 것을 의미합니다.@Document(collection = "orders")data class Order( @Id ..

앞선 2편에서는 MongoDB의 기본 개념을 Spring 관점에서 정리했습니다. 이번 편에서는 Spring Data MongoDB가 MongoDB를 어떻게 추상화하고 있는지, 그리고 실무에서 가장 많이 헷갈리는 두 가지 선택지, Repository와 MongoTemplate의 역할을 명확히 구분해 봅니다.Mongo를 처음 Spring에서 사용하면 이런 고민이 생깁니다.“Repository만 써도 되는 걸까?”“MongoTemplate은 언제 등장하는 걸까?”이 글의 목표는 정답을 하나로 정하는 것이 아니라, 공식 문서가 의도한 역할 분담을 이해하고 상황에 맞게 선택할 수 있는 기준을 만드는 것입니다.이번 편에서 다룰 내용Spring Data MongoDB 전체 구조Repository 추상화의 역할Repo..