MongoDB
"The application data platform as a developer-first, document-based database."
— 개발자 친화적인 도큐먼트 모델을 내세워 개발 생산성을 무한 극대화해 주겠다는 공식 슬로건.
'우리는 스키마가 필요 없다'며 자랑스럽게 개발을 시작했다가, 서비스 오픈 1년 뒤 데이터가 제각각인 기괴한 도큐먼트들을 마주하고 눈물을 흘리며 데이터 마이그레이션 코드를 직접 짜게 만드는 만악의 원천. ORM(Mongoose)을 써서 스키마를 강제할 거라면, 애초에 RDBMS를 쓰지 왜 몽고DB를 골랐던 것일까?
1. 개요
MongoDB는 2009년 10gen사(현재 MongoDB Inc.)가 개발한 오픈소스 도큐먼트 지향 NoSQL 데이터베이스이다. 데이터를 행과 열의 표가 아닌, JSON과 구조가 완벽히 동일한 이진 포맷인 BSON(Binary JSON) 도큐먼트 형태로 저장한다.
테이블 간 복잡한 관계를 지워버리고 하나의 문서 안에 하위 정보를 마음껏 밀어 넣을 수 있어, Node.js로 대표되는 현대 자바스크립트 풀스택 웹 생태계(MEAN, MERN 스택)에서 사실상 교양 필수 도구로 쓰이고 있다. 수평적 스케일아웃(Scale-out)이 매우 수월해 빅데이터 수집이나 빠른 프로토타이핑에 환상적인 성능을 보여준다.(...)
2. BSON의 미학수호와 스키마-리스(Schema-less)의 빛과 어둠
2.1. BSON (Binary JSON)의 내부 사정
JSON은 사람이 읽기엔 좋으나 컴퓨터 파서가 숫자를 읽거나 검색하기엔 파싱 속도가 떨어진다. MongoDB는 이를 해결하기 위해 데이터를 이진화 압축한 BSON 형태로 물리 디스크에 보관한다. 날짜(Date) 타입이나 이진 데이터(Binary Data)를 기본적으로 지원하여 순수 JSON의 한계를 매끄럽게 보완하고 있다.
2.2. 스키마-리스 (Schema-less): 자유의 무거운 대가
MongoDB 최대의 마케팅 포인트는 '스키마가 없다'는 것이다. 컬럼 추가나 타입 정의를 미리 할 필요 없이 그냥 생성한 JSON 도큐먼트를 insert 치면 바로 들어간다. 기획이 매일같이 바뀌어 필드가 수시로 추가/삭제되는 극초기 스타트업에서 개발 속도를 미친 듯이 뽑아낼 수 있는 치트키다.
하지만 이 자유는 훗날 고스란히 업보로 돌아온다.
- 어떤 도큐먼트에는
user_name으로 들어가 있고, 다른 도큐먼트에는userName으로 오타가 나 있거나, - 숫자가 들어가야 할 자리에 문자열
"123"이 박히는 등 데이터의 일관성이 완전히 파괴된다.1
결국 이 쓰레기 데이터들을 정제하느라 백엔드 애플리케이션 코드에 수백 줄의 예외 처리와 유효성 검증 로직을 짜게 되며, '이럴 거면 그냥 RDBMS에 스키마 박고 시작할 걸' 하고 이마를 탁 치는 후회가 몰려오게 된다.(...)
3. 수평 확장의 제왕: 샤딩(Sharding)과 SSPL 라이선스 칼춤
3.1. 무한에 도전하는 샤딩과 복제 셋
MongoDB는 태생부터 분산 환경을 염두에 두고 설계되었다. 데이터를 여러 서버에 고르게 나누어 저장하는 샤딩(Sharding)과, 데이터 유실을 막기 위해 동일한 복제본 서버 여러 대를 동기화하는 복제 셋(Replica Set) 구성이 RDBMS에 비해 눈물겹도록 간결하게 구현되어 있다. 대규모 유저 로그 데이터나 실시간 메시지를 쌓는 용도로는 타의 추종을 불허한다.
3.2. SSPL 라이선스 칼춤과 클라우드사들과의 전쟁
원래 MongoDB는 관대한 오픈소스 라이선스(AGPL)를 따랐으나, 아마존 AWS 같은 거대 빅테크 클라우드사들이 MongoDB 코드를 그대로 가져다가 'DocumentDB'라는 이름의 자체 상용 클라우드 서비스로 팔아먹으며 한 푼의 수수료도 재단에 기부하지 않자 격분했다.2
결국 2018년, MongoDB는 SSPL (Server Side Public License)이라는 독자 라이선스로 선언해 버렸다. '우리 소스로 클라우드 장사를 하려면 소스코드를 공개하든가, 아니면 우리한테 라이선스 비용을 내라!'는 무서운 조치다. 이로 인해 많은 오픈소스 진영과 클라우드사 간에 거대한 진흙탕 법적 분쟁이 현재 진행 중이다.
4. Web Scale 드립과 스키마 유실
4.1. MongoDB is Web Scale (몽고디비는 웹 스케일)
유튜브 초창기에 유행한 플래시 애니메이션 유머다. 어떤 멍청한 신입 개발자가 무조건 RDBMS 대신 MongoDB를 써야 한다며 선배 개발자에게 '왜냐하면 MongoDB는 Web Scale이니까요!'라는 알맹이 없는 기술 마케팅 용어만 무한 반복하며 설득하려 드는 내용이다. 기술의 명확한 동작 아키텍처나 트레이드오프는 모른 채 힙한 유행어만 맹신하는 테크 업계 주니어들을 사정없이 풍자하는 클래식 밈이다.
5. 여담
- 이름의 유래: MongoDB의 이름은 '어마어마하게 거대하다'는 뜻을 지닌 단어인 'Humongous(휴먼거스)'의 가운데 글자 'mongo'에서 따왔다. 즉, 온 세상을 다 덮을 정도로 거대한 빅데이터를 수용하겠다는 야심 찬 칭호인 셈이다.
- 강력한 CLI 터미널: 내부 쿼리 엔진이 자바스크립트 환경으로 돌아가기 때문에, MongoDB의 CLI 콘솔창을 켜면 자바스크립트 엔진처럼
function을 선언하고 반복문을 돌리며 컬렉션 데이터를 가공할 수 있어 프론트엔드 출신 개발자들이 무척 친숙하게 느낀다. - 트랜잭션 미지원 역사: 초기의 MongoDB는 트랜잭션과 조인(Join)을 아예 지원하지 않는 극단적 마이웨이 노선이었으나, 엔터프라이즈 시장을 먹기 위해 버전 4.0 이후 다중 문서 트랜잭션 기능을 억지로(?) 탑재하였다. 하지만 RDBMS에 비해 성능 하락이 매우 심해 여전히 실무에서는 트랜잭션을 최소화하는 도큐먼트 설계를 원칙으로 삼는다.