Lv.1 입문MongoDB

2026.05.2520분 읽기Lv.1 입문

시리즈MongoDB Atlas 완전 정복 · 파트 1시리즈 허브 보기

MongoDB Atlas 완전 정복 Part 1 — Atlas란 무엇인가: 개념, 구조, 그리고 왜 쓰는가

MongoDB를 직접 운영할 때 겪는 레플리카셋 구성·백업·패치 관리 같은 운영 부담을 Atlas가 어떻게 흡수하는지, 그리고 Organization·Project·Cluster 3계층이 왜 첫 번째로 잡아야 할 개념인지 설명합니다. AWS DocumentDB·Firestore·DynamoDB와의 비교, 2025-2026년 주요 변화(Auto-scaling 5배 향상·Vector Search GA·CLI 완전 지원), M0 클러스터 빠른 시작까지 한 글에 담았습니다.

시리즈 구성

• Part 1 ← 지금 여기 | Atlas 개념·구조·왜 쓰는가
• Part 2 | 클러스터 설계 전략 — Serverless vs Dedicated vs Free Tier
• Part 3 | 보안, 네트워크, 접근 제어 완전 해부
• Part 4 | 성능 최적화 — 인덱싱, 쿼리 튜닝, Auto-scaling
• Part 5 | AI 시대의 Atlas — Vector Search, Stream Processing, RAG 파이프라인

목차

1. Atlas가 탄생한 배경
2. MongoDB Atlas의 핵심 아키텍처
3. Atlas를 구성하는 3가지 계층
4. 경쟁 서비스와의 비교
5. 2025-2026 Atlas의 변화 — 무엇이 달라졌나
6. 빠른 시작: 첫 번째 클러스터 만들기
7. 실무 적용 노트

1. Atlas가 탄생한 배경

MongoDB는 2009년 오픈소스로 공개되며 "스키마 없는 유연한 NoSQL DB"라는 포지셔닝으로 개발자 커뮤니티에 빠르게 자리 잡았다. 그러나 MongoDB를 직접 운영하는 것은 만만치 않았다.

레플리카셋을 구성하고, 샤딩 전략을 설계하고, 백업 스케줄을 관리하고, 버전 패치를 안전하게 적용하는 일은 모두 운영팀의 몫이었다. 여기에 모니터링, 장애 대응, 용량 계획까지 더하면 데이터베이스 자체를 운영하는 데만 상당한 엔지니어링 리소스가 소모된다.

MongoDB Atlas는 이 고통을 해소하기 위해 2016년에 출시되었다. 핵심 철학은 명확하다.

"We run the database, you focus on the app."

2025년부터 2026년 현재까지 Atlas는 단순 DBaaS(Database as a Service)를 넘어 벡터 검색, 스트림 처리, AI 파이프라인을 아우르는 데이터 플랫폼으로 진화했다. "MongoDB를 대신 운영해준다"는 출발점에서, Control Plane 중심 자동화로 운영 부담 전체를 흡수하는 구조로 옮겨간 것이 본질적인 변화다.

2. MongoDB Atlas의 핵심 아키텍처

Atlas는 AWS, Google Cloud, Azure 세 클라우드 위에서 동작한다. 사용자는 어떤 클라우드 위에 데이터가 있는지 직접 신경 쓸 필요 없이, Atlas가 제공하는 Control Plane을 통해 모든 것을 조작한다.

핵심 구성요소는 네 가지다.

Control Plane이 핵심이다. 클러스터 생성, 스케일 업·다운, 백업 실행, 패치 적용, 장애 감지 후 복구까지 — 이 모든 운영 행위가 Control Plane을 통해 자동화된다. 사용자는 API나 UI로 의도를 전달하고, Atlas가 실행한다.

Atlas Agent는 Data Plane의 각 노드에 설치되는 경량 프로세스다. 상태 지표를 Control Plane으로 전송하고, Control Plane의 지시를 받아 로컬에서 작업을 수행한다. 이 구조 덕분에 사용자가 직접 SSH로 서버에 접근하지 않아도 된다.

3. Atlas를 구성하는 3가지 계층

Atlas를 처음 접할 때 가장 자주 혼란이 생기는 지점이 바로 Organization → Project → Cluster 계층 구조다. 각 계층이 담당하는 역할이 다르기 때문에, 이 구분을 먼저 잡아야 설정과 권한 구성을 올바르게 할 수 있다.

Organization — 청구와 멤버 관리

Organization은 가장 상위 단위다. 팀 멤버를 초대하고, 청구 정보를 등록하며, SSO(Single Sign-On)나 조직 수준 접근 정책을 전체에 적용한다. 회사 단위로 하나를 만든다고 생각하면 된다.

Project — 보안과 네트워크 정책의 단위

Project는 보안 경계다. IP Access List, 데이터베이스 사용자, 네트워크 피어링, VPC 구성이 Project 단위로 분리된다. 환경(dev / staging / prod)마다 Project를 나누는 것이 일반적인 권장 패턴이다.

2025년 Atlas는 Atlas Resource Policies 기능을 도입해, 조직 수준에서 클러스터 구성 표준을 강제할 수 있게 되었다. 예를 들어 특정 인스턴스 크기 이하의 클러스터 생성을 프로덕션 Project에서 제한하거나, 백업 활성화를 강제할 수 있다.

Cluster — 실제 MongoDB 런타임

Cluster는 실제로 MongoDB가 실행되는 단위다. 기본 구성은 3노드 Replica Set이며, 노드 수, 인스턴스 크기, 리전, 클라우드 공급자를 여기서 선택한다. 사용량에 따라 Auto-scaling도 이 단위에서 동작한다.

4. 경쟁 서비스와의 비교

"왜 Atlas를 써야 하는가"라는 질문에는 "무조건 Atlas가 낫다"가 아니라 선택 조건을 분명히 하는 방식으로 답하는 것이 정확하다.

AWS DocumentDB가 "MongoDB 호환"을 표방하지만, 집계 파이프라인 연산자 일부와 일부 드라이버 기능을 지원하지 않는다. 기존 MongoDB 애플리케이션을 무수정 이전하거나 집계 파이프라인을 적극적으로 사용하는 팀이라면 호환성 갭을 사전에 검증해야 한다.

Atlas가 강한 경우:

• 진정한 MongoDB 생태계(드라이버, 집계, Change Streams)가 필요한 팀
• 멀티 클라우드 이식성이 요구되는 환경
• Vector Search, Stream Processing을 같은 플랫폼에서 함께 사용하려는 팀

다른 선택지를 검토할 경우:

• 단순 key-value 패턴 위주이고 DynamoDB의 서버리스 모델이 비용에 유리한 경우
• GCP 환경에 이미 깊이 종속되어 있고 Firestore의 모바일 SDK 생태계가 필요한 경우

5. 2025-2026 Atlas의 변화 — 무엇이 달라졌나

2025년 이후 Atlas에는 운영 측면과 AI 측면 모두에서 굵직한 변화가 있었다.

UI/UX 전면 개편 (2025년 4월)

2020년 이후 약 5년 만에 네비게이션이 전면 재설계되었다. 기존 클러스터 중심 구조에서 워크플로우 중심으로 개편되어, Search·Charts·Stream Processing 같은 서비스 접근성이 크게 향상되었다.

Auto-scaling 속도 5배 향상

M10, M20 클러스터의 Auto-scaling이 리소스 수요에 최대 5배 빠르게 반응하도록 개선되었다. 트래픽 스파이크 대응 능력이 한 단계 올라간 것으로, 간헐적 부하를 받는 서비스에서 체감 차이가 크다.

Atlas CLI 완전한 API 커버리지 (2025년 6월)

Atlas Administration API의 전체 기능을 CLI로 사용할 수 있게 되었다. OpenAPI Spec 기반으로 자동 생성되는 구조이기 때문에, 새 기능이 출시되면 수일 내에 CLI에서도 사용 가능해진다. GitOps 파이프라인에서 Atlas를 코드로 관리하는 흐름이 훨씬 자연스러워졌다.

Vector Search 및 자동 임베딩 GA

외부 벡터 DB(Pinecone, Weaviate 등) 없이 MongoDB Atlas 내에서 벡터 검색과 자동 임베딩 생성이 가능해졌다. autoEmbed 필드 타입과 Voyage AI 모델 연동이 도입되었다. RAG 파이프라인을 MongoDB만으로 구성하려는 팀에게 의미 있는 변화다.

Azure Key Vault Secretless 인증

정적 크리덴셜 대신 단기 OAuth 2.0 토큰을 사용하는 Secretless 인증이 Azure Key Vault와 통합되었다. 보안 정책상 장기 시크릿 보관을 허용하지 않는 엔터프라이즈 환경에서의 채택 장벽이 낮아졌다.

6. 빠른 시작: 첫 번째 클러스터 만들기

Atlas 무료 계정으로 M0 클러스터를 띄우고 Node.js로 연결 테스트까지 해보자. 여기서 다루는 설정은 빠른 시작 수준이며, 운영 보안·비용 최적화·클러스터 사이징은 Part 2, 3, 4에서 다룬다.

Step 1: 회원가입 및 프로젝트 생성

1. cloud.mongodb.com 접속 후 구글 계정으로 가입 (권장)
2. Organization 이름, Project 이름 설정
3. 최초 로그인 시 무료 클러스터 생성 안내가 바로 나온다

Step 2: 클러스터 생성 (Atlas CLI 사용)

# Atlas CLI 로그인
atlas auth login

# M0 Free Tier 클러스터 생성 (MongoDB 8.x 기준)
atlas clusters create myFirstCluster \
  --provider AWS \
  --region AP_NORTHEAST_1 \
  --tier M0 \
  --mdbVersion 8.0

UI에서도 동일하게 진행할 수 있다: Create Cluster → M0 Free → AWS → Seoul (ap-northeast-2) 선택.

M0 클러스터는 서울 리전 기준으로 512 MB 스토리지와 공유 RAM이 제공된다. 개발·학습 용도로만 사용하며, 프로덕션에는 적합하지 않다.

Step 3: 데이터베이스 사용자 생성

atlas dbusers create \
  --username myUser \
  --password "SecurePass123!" \
  --role readWriteAnyDatabase

실제 운영에서는 최소 권한 원칙(Least Privilege)에 따라 특정 데이터베이스와 컬렉션에만 접근권을 부여한다. 이 예시의 readWriteAnyDatabase 권한은 전체 접근을 허용하므로 빠른 시작 목적으로만 사용한다.

Step 4: IP Access List 등록

# 현재 클라이언트 IP 자동 등록
atlas accessLists create --currentIp

IP Access List는 Project 단위로 관리된다. 0.0.0.0/0(전체 허용)은 빠른 시작 시에만 일시적으로 사용하고, 실제 운영에서는 VPC 피어링 또는 특정 IP 범위로 제한한다.

Step 5: 연결 테스트 (Node.js)

const { MongoClient, ServerApiVersion } = require('mongodb');

const uri = "mongodb+srv://myUser:<password>@myfirstcluster.xxxxx.mongodb.net/";

const client = new MongoClient(uri, {
  serverApi: {
    version: ServerApiVersion.v1,
    strict: true,
    deprecationErrors: true,
  }
});

async function run() {
  try {
    await client.connect();
    await client.db("admin").command({ ping: 1 });
    console.log("MongoDB Atlas 연결 성공");
  } finally {
    await client.close();
  }
}

run().catch(console.dir);

연결 문자열은 Atlas UI의 Connect → Drivers 메뉴에서 자동 생성된다. <password>를 Step 3에서 설정한 값으로 교체한다.

Part 1 요약

참고

• MongoDB Atlas 문서
• MongoDB Atlas Architecture Center
• MongoDB Atlas CLI 문서
• MongoDB Atlas Vector Search 문서
• Amazon DocumentDB 호환성 문서