MongoDB Developer Day 2025 Seoul 후기

 

 

올해 MongoDB Developer Day 2025에 참석했습니다.

 

행사장에는 다양한 분야의 개발자들이 모여 있어서

MongoDB를 어디서 어떻게 활용하는지 서로 이야기를 나누는 모습도 종종 보였습니다.

전체적으로 실습과 사례 중심 세션이 많았는데요.

 

개인적으로는 몽고디비의 컨셉에 대한 1번섹션이 도움이 많이 되었습니다.

실습 중심 세션이 많아서 실제 모델링 흐름을 따라가 볼 수 있었고,

컨퍼런스 자체 경험도 만족스러웠습니다.

 

1번 섹션들으면서 개인적으로 중요하다고 생각했던 부분 정리 내용도 공유해보려고 합니다.

 

MongoDB 를 몽고디비 답게 사용하는법

RDB는 어떤 어플리케이션에 최적화되어있다고 보기는 어렵습니다.

즉, DB에 집중한 schema입니다.

반면에, MongoDB는 어플리케이션 워크로드에 따른 최적화에 중점을 둔 설계가 가능합니다.

 

 

MongoDB 설계 핵심 컨셉

내장(Embedded Document)

문서 안에 문서를 자연스럽게 포함할 수 있는 구조입니다.

데이터가 함께 조회되는 경우 내장하는 방식을 고려해볼 수 있었습니다.

 

배열(Array)

배열 기반 데이터 모델링이 매우 자연스럽습니다.

 

RDB에서는 일대다/다대다를 표현하기 위해 테이블 분리, 조인, 중간 테이블까지 고민이 많지만,

MongoDB에서는 배열 + 내장 문서로 직관적으로 표현 가능했습니다.

 

실습하면서 “댓글”, “sub-items”같은 구조가

굳이 테이블을 나누지 않아도 되는 게 꽤 편했습니다.

 

참고로 PostgreSQL 같은 RDB에서도 배열 기능은 있지만

배열 원소를 기반으로 한 find 쿼리 자체가 자연스럽지 않습니다.

 

다형성(Polymorphism)

하나의 컬렉션에 여러형태의 document 형태가 가능합니다.

예를 들면, 예약 문서, 대출 문서와 같이 구조가 달라도 하나의 컬렉션에서 관리해도 된다는 것입니다.

RDB에서는 이 구조를 만들기 위해 공통 테이블 + 서브 테이블 등 추가 설계가 필요하지만

MongoDB에서는 컬렉션 단위에서 유연하게 처리됩니다.

 

MongoDB가 제공하는 실질적인 장점

RDBMS는 디스크 최적화를 위해 테이블을 분리하고 JOIN을 시키지만,

MongoDB는 디스크를 더 사용하더라도 더 효율적인 읽기 성능을 올리는 컨셉입니다.

단일 쿼리로 필요한 데이터를 읽을 수 있도록 설계하는 방향으로 갑니다.

 

스키마 유효성 검사

필수 필드, 값의 타입, 배열 크기같은 조건을 정해두고 잘못된 데이터가 들어오면

로그를 남기거나 쓰기를 막을 수 있습니다.

문서 모델이라고 해서 자유도만 큰 줄 알았는데

검증적인 부분도 잘 마련되어 있었습니다.

 

워크로드에서 시작하는 데이터 모델링

오늘 실습과 세션을 통해 가장 크게 배운 건

데이터 모델링을 할 때 “데이터 자체”보다 “워크로드”를 먼저 본다는 흐름이었습니다.

• 얼마나 자주 읽히는가
• 어떤 화면에서 함께 조회되는가
• 쓰기/읽기 중 어디에 비용을 두는가

이 기준으로 내장/참조/계산 필드 등을 선택하는 과정이

문서 모델링의 핵심입니다.

 

 

이번 Developer Day에서 가장 좋았던 점은,

개념으로만 알고 있던 데이터 모델링 패턴들을 직접 손으로 만들어보며 체감할 수 있었던 점인데요.

 

“어플리케이션이 어떻게 데이터를 조회하고 활용하는지”를 먼저 생각하는 흐름은

앞으로 프로젝트에서도 많이 참고하게 될 것 같습니다.

 

이번 경험을 바탕으로

제가 만드는 API와 데이터 흐름에서 어떤 부분을 내장하고 어떤 부분을 분리할지,

읽기와 쓰기 중 어디에 비용을 둘지,

더 심도 있게 고민해볼 수 있을 것 같습니다.