본 콘텐츠의 이미지 및 내용은 AI로 생성되었습니다.
본 콘텐츠의 이미지 및 내용을 무단으로 복제, 배포, 수정하여 사용할 경우 저작권법에 의해 법적 제재를 받을 수 있습니다.
이미지 로딩 중...
AI Generated
2025. 11. 27. · 25 Views
MongoDB Atlas 클라우드 완벽 가이드
MongoDB Atlas 클라우드 서비스를 처음 시작하는 개발자를 위한 실전 가이드입니다. 계정 생성부터 성능 최적화까지, 실무에서 바로 활용할 수 있는 핵심 내용을 담았습니다.
목차
1. Atlas 계정 생성
신입 개발자 김개발 씨는 팀장님으로부터 첫 미션을 받았습니다. "우리 프로젝트 데이터베이스를 MongoDB Atlas로 세팅해 봐요." 김개발 씨는 고개를 끄덕였지만, 속으로는 막막했습니다.
클라우드 데이터베이스라니, 어디서부터 시작해야 할까요?
MongoDB Atlas는 MongoDB에서 공식으로 제공하는 클라우드 데이터베이스 서비스입니다. 마치 전문 요리사가 운영하는 레스토랑처럼, 데이터베이스 운영의 모든 복잡한 일을 Atlas가 대신 처리해줍니다.
계정 생성은 이 여정의 첫걸음이며, 무료 티어로도 충분히 학습하고 작은 프로젝트를 운영할 수 있습니다.
다음 코드를 살펴봅시다.
// MongoDB Atlas 계정 생성 후 연결 문자열 예시
const { MongoClient } = require('mongodb');
// Atlas에서 제공하는 연결 문자열
const uri = "mongodb+srv://<username>:<password>@cluster0.xxxxx.mongodb.net/?retryWrites=true&w=majority";
// MongoClient 인스턴스 생성
const client = new MongoClient(uri);
async function connect() {
// Atlas 클러스터에 연결
await client.connect();
console.log("Atlas 연결 성공!");
// 데이터베이스 목록 확인
const databases = await client.db().admin().listDatabases();
console.log("데이터베이스 목록:", databases);
}
김개발 씨는 먼저 브라우저를 열고 mongodb.com/atlas에 접속했습니다. 화면 중앙에 "Try Free"라는 버튼이 눈에 들어왔습니다.
클릭하니 회원가입 페이지가 나타났습니다. 회원가입 방법은 두 가지였습니다.
이메일로 직접 가입하거나, Google 계정으로 간편하게 로그인할 수 있었습니다. 김개발 씨는 회사 이메일로 가입하기로 했습니다.
그렇다면 MongoDB Atlas란 정확히 무엇일까요? 쉽게 비유하자면, Atlas는 마치 아파트 관리사무소와 같습니다.
직접 집을 지으면 배관, 전기, 보안까지 모든 것을 신경 써야 합니다. 하지만 아파트에 살면 관리사무소가 이런 일들을 대신 처리해줍니다.
Atlas도 마찬가지로 서버 관리, 보안 패치, 백업 같은 귀찮은 일들을 알아서 해줍니다. 예전에는 MongoDB를 사용하려면 직접 서버를 구축해야 했습니다.
서버 컴퓨터를 구매하고, 운영체제를 설치하고, MongoDB를 설치하고, 방화벽을 설정하고... 끝이 없었습니다.
작은 스타트업에서 이 모든 것을 혼자 감당하기란 정말 힘든 일이었습니다. 바로 이런 고민을 해결하기 위해 Atlas가 탄생했습니다.
클릭 몇 번이면 전 세계 어디서나 접속 가능한 데이터베이스가 뚝딱 만들어집니다. 회원가입을 완료하면 Organization을 먼저 만들게 됩니다.
Organization은 회사나 팀 단위라고 생각하면 됩니다. 그 안에 여러 Project를 만들 수 있습니다.
하나의 회사에서 여러 프로젝트를 운영하는 것처럼요. 김개발 씨는 "MyCompany"라는 이름으로 Organization을 만들고, "FirstProject"라는 Project를 생성했습니다.
이제 데이터베이스를 만들 준비가 되었습니다. 특히 반가운 것은 M0 무료 티어였습니다.
512MB의 스토리지와 공유 RAM을 무료로 제공받을 수 있었습니다. 학습 목적이나 작은 사이드 프로젝트에는 충분한 용량이었습니다.
주의할 점도 있었습니다. 무료 티어는 일부 기능에 제한이 있습니다.
예를 들어 백업 기능이나 성능 분석 도구는 유료 플랜에서만 완전하게 사용할 수 있습니다. 하지만 개발 학습 단계에서는 전혀 문제가 되지 않았습니다.
김개발 씨는 성공적으로 계정을 만들었습니다. 화면에 빈 대시보드가 나타났습니다.
"이제 진짜 시작이구나." 김개발 씨는 다음 단계인 클러스터 생성으로 넘어갔습니다.
실전 팁
💡 - 회사 프로젝트라면 회사 이메일로 가입하여 팀원 초대와 권한 관리를 수월하게 하세요
- 무료 티어(M0)는 프로덕션 환경에는 적합하지 않으니 학습과 개발용으로만 사용하세요
2. 클러스터 프로비저닝
계정을 만든 김개발 씨 앞에 "Build a Database"라는 버튼이 나타났습니다. 클릭하니 여러 옵션이 쏟아졌습니다.
Serverless, Dedicated, Shared... 처음 보는 용어들에 머리가 어지러웠습니다.
선배 박시니어 씨에게 슬쩍 물어봤습니다. "선배님, 클러스터가 뭐예요?"
클러스터는 데이터베이스 서버들의 집합입니다. 마치 창고를 여러 개 두고 물건을 나눠 보관하는 것처럼, 데이터를 여러 서버에 분산 저장합니다.
프로비저닝은 이 클러스터를 원하는 사양으로 생성하는 과정입니다. Atlas에서는 클릭 몇 번으로 전 세계 어느 지역에나 클러스터를 만들 수 있습니다.
다음 코드를 살펴봅시다.
// 클러스터 생성 후 데이터베이스와 컬렉션 만들기
const { MongoClient } = require('mongodb');
const uri = "mongodb+srv://myuser:mypassword@cluster0.abc123.mongodb.net/";
const client = new MongoClient(uri);
async function setupDatabase() {
await client.connect();
// 데이터베이스 생성 (없으면 자동 생성)
const db = client.db("myshop");
// 컬렉션 생성
const products = db.collection("products");
// 첫 번째 문서 삽입
await products.insertOne({
name: "노트북",
price: 1500000,
category: "전자기기"
});
console.log("데이터베이스 설정 완료!");
}
박시니어 씨가 친절하게 설명해주었습니다. "클러스터를 쉽게 설명하자면, 편의점 체인이라고 생각해봐." 하나의 편의점만 운영하면 어떨까요?
그 편의점이 문을 닫으면 손님은 물건을 살 수 없습니다. 하지만 여러 편의점이 네트워크로 연결되어 있다면, 한 곳이 문제가 생겨도 다른 곳에서 물건을 살 수 있습니다.
클러스터도 마찬가지로 여러 서버가 함께 동작하여 고가용성을 보장합니다. Atlas에서 클러스터를 만드는 과정은 생각보다 간단했습니다.
"Build a Database" 버튼을 클릭하면 세 가지 옵션이 나타납니다. 첫 번째는 Serverless입니다.
사용한 만큼만 비용을 지불하는 방식입니다. 트래픽이 불규칙한 서비스에 적합합니다.
두 번째는 Dedicated입니다. 전용 서버를 할당받는 방식으로, 안정적인 성능이 필요한 프로덕션 환경에 적합합니다.
세 번째는 Shared입니다. 여러 사용자가 서버 자원을 나눠 쓰는 방식입니다.
무료 티어인 M0가 여기에 속합니다. 김개발 씨는 학습 목적이므로 Shared의 M0를 선택했습니다.
다음으로 클라우드 제공자를 선택해야 합니다. AWS, Google Cloud, Azure 중에서 고를 수 있습니다.
각각 장단점이 있지만, 회사에서 이미 사용 중인 클라우드가 있다면 그것을 선택하는 것이 좋습니다. 같은 클라우드 내에서 통신하면 속도도 빠르고 비용도 절약됩니다.
리전 선택도 중요합니다. 서비스의 주요 사용자가 한국에 있다면 서울 리전을 선택하는 것이 좋습니다.
사용자와 서버가 가까울수록 응답 속도가 빨라지기 때문입니다. 김개발 씨는 AWS의 서울 리전(ap-northeast-2)을 선택했습니다.
클러스터 이름을 입력하는 칸이 나타났습니다. 기본값은 "Cluster0"이었지만, 나중에 여러 클러스터를 운영할 것을 대비해 "dev-cluster"라고 의미 있는 이름을 지었습니다.
"Create Cluster" 버튼을 클릭하자 프로비저닝이 시작되었습니다. 화면에 진행 상황이 표시되었고, 약 3분 후 클러스터 생성이 완료되었습니다.
직접 서버를 구축했다면 반나절은 걸렸을 일이 순식간에 끝난 것입니다. 김개발 씨는 감탄했습니다.
"와, 이렇게 쉽게 데이터베이스가 만들어지다니!" 하지만 아직 끝이 아니었습니다. 보안 설정이 남아 있었습니다.
실전 팁
💡 - 클러스터 이름은 나중에 변경할 수 없으니 처음부터 의미 있는 이름을 지으세요
- 무료 티어는 리전 선택이 제한적이니, 가능한 선택지 중 사용자와 가장 가까운 곳을 선택하세요
3. 네트워크 접근 설정
클러스터가 생성되었지만 김개발 씨는 연결에 실패했습니다. 에러 메시지는 "connection timed out"이었습니다.
박시니어 씨가 어깨 너머로 보더니 웃으며 말했습니다. "IP 허용 목록에 네 IP를 추가했어?" 김개발 씨는 무슨 말인지 몰라 눈만 깜빡였습니다.
네트워크 접근 설정은 데이터베이스의 문지기 역할을 합니다. Atlas는 기본적으로 모든 외부 접속을 차단하고, 허용된 IP 주소에서만 접근을 허용합니다.
마치 아파트 출입문에 비밀번호가 있는 것처럼, 승인된 사람만 들어올 수 있게 하는 보안 장치입니다. 이 설정을 통해 데이터베이스를 외부 위협으로부터 안전하게 보호할 수 있습니다.
다음 코드를 살펴봅시다.
// IP 허용 목록 설정 후 연결 테스트
const { MongoClient } = require('mongodb');
const uri = "mongodb+srv://myuser:mypassword@cluster0.abc123.mongodb.net/";
const client = new MongoClient(uri, {
// 연결 옵션 설정
connectTimeoutMS: 10000,
socketTimeoutMS: 45000,
});
async function testConnection() {
try {
await client.connect();
// 연결 확인용 ping 명령
await client.db("admin").command({ ping: 1 });
console.log("연결 성공! 네트워크 설정이 올바릅니다.");
} catch (error) {
console.error("연결 실패:", error.message);
console.log("IP 허용 목록을 확인해주세요.");
} finally {
await client.close();
}
}
박시니어 씨가 차분하게 설명을 시작했습니다. "데이터베이스는 우리 회사의 금고 같은 거야.
아무나 들어오면 안 되겠지?" 김개발 씨는 고개를 끄덕였습니다. 당연한 이야기였습니다.
고객 정보, 주문 내역, 결제 데이터가 담긴 데이터베이스에 누구나 접속할 수 있다면 큰일이었습니다. Atlas는 IP 화이트리스트 방식을 사용합니다.
화이트리스트란 '허용 목록'이라는 뜻입니다. 목록에 있는 IP 주소에서만 데이터베이스에 접속할 수 있습니다.
목록에 없는 IP에서 접속을 시도하면 무조건 차단됩니다. Atlas 대시보드 왼쪽 메뉴에서 Network Access를 클릭합니다.
처음에는 목록이 비어 있습니다. 여기에 접속을 허용할 IP 주소를 추가해야 합니다.
"Add IP Address" 버튼을 클릭하면 몇 가지 옵션이 나타납니다. Add Current IP Address를 선택하면 지금 사용 중인 컴퓨터의 IP가 자동으로 입력됩니다.
개발 환경에서는 이 방법이 편리합니다. 하지만 주의할 점이 있습니다.
집에서 사용하는 인터넷은 보통 동적 IP입니다. IP 주소가 주기적으로 바뀔 수 있다는 뜻입니다.
어느 날 갑자기 연결이 안 된다면 IP가 바뀌었을 가능성이 높습니다. 개발 편의를 위해 0.0.0.0/0을 입력하면 모든 IP에서 접속을 허용합니다.
"Allow Access from Anywhere" 버튼이 바로 이 설정입니다. 하지만 이 방법은 절대로 프로덕션 환경에서 사용하면 안 됩니다.
보안에 구멍이 뚫리는 것과 같습니다. 프로덕션 환경에서는 어떻게 해야 할까요?
서비스를 운영하는 서버의 고정 IP만 등록해야 합니다. AWS EC2나 다른 클라우드 서비스를 사용한다면 해당 서버의 퍼블릭 IP를 확인해서 등록합니다.
김개발 씨는 일단 개발 환경이니 현재 IP를 추가했습니다. IP 옆에 설명을 추가할 수 있는 칸이 있어서 "김개발 집 IP"라고 적어두었습니다.
나중에 어떤 IP가 누구의 것인지 알 수 있어 관리가 편리합니다. VPC Peering이라는 고급 기능도 있습니다.
이것은 Atlas와 회사의 클라우드 네트워크를 직접 연결하는 방식입니다. 공용 인터넷을 거치지 않아 보안성이 높아지고 속도도 빨라집니다.
규모가 큰 서비스에서 주로 사용합니다. 설정을 마친 김개발 씨는 다시 연결을 시도했습니다.
이번에는 성공이었습니다. "연결 성공!"이라는 메시지를 보며 김개발 씨는 뿌듯한 미소를 지었습니다.
실전 팁
💡 - 개발 환경에서 0.0.0.0/0을 사용할 때는 반드시 강력한 비밀번호와 함께 사용하세요
- IP가 변경되었을 때를 대비해 Atlas 관리자 계정 정보는 안전한 곳에 보관하세요
4. Atlas UI 활용
연결에 성공한 김개발 씨는 데이터를 확인하고 싶었습니다. 터미널에서 명령어를 입력하려다가, 박시니어 씨가 말했습니다.
"Atlas UI에서 바로 볼 수 있어. 훨씬 편해." 김개발 씨는 다시 Atlas 대시보드로 돌아갔습니다.
Atlas UI는 데이터베이스를 시각적으로 관리할 수 있는 웹 인터페이스입니다. 마치 스마트폰의 파일 탐색기처럼, 클릭만으로 데이터를 조회하고 수정할 수 있습니다.
명령어를 몰라도 데이터를 확인할 수 있어 초보자에게 특히 유용합니다. 컬렉션 탐색, 문서 편집, 인덱스 관리까지 대부분의 작업을 UI에서 처리할 수 있습니다.
다음 코드를 살펴봅시다.
// Atlas Data Explorer에서 실행할 수 있는 쿼리 예시
// Collections 탭 > 컬렉션 선택 > Filter에 입력
// 특정 조건으로 문서 검색
{ "status": "active", "price": { "$gte": 10000 } }
// 정렬 조건 추가 (Sort 탭에서)
{ "createdAt": -1 }
// 프로젝션으로 필요한 필드만 조회 (Project 탭에서)
{ "name": 1, "price": 1, "_id": 0 }
// Aggregation 탭에서 집계 파이프라인 실행
[
{ "$match": { "category": "전자기기" } },
{ "$group": { "_id": "$brand", "total": { "$sum": 1 } } },
{ "$sort": { "total": -1 } }
]
김개발 씨는 Atlas 대시보드에서 클러스터 이름 옆의 "Browse Collections" 버튼을 클릭했습니다. 새 화면이 열리며 데이터베이스 목록이 나타났습니다.
이것이 바로 Data Explorer입니다. 왼쪽에는 데이터베이스와 컬렉션 목록이 트리 구조로 보입니다.
마치 윈도우 탐색기에서 폴더를 탐색하는 것과 비슷합니다. 컬렉션을 클릭하니 문서들이 목록으로 표시되었습니다.
JSON 형태의 데이터가 보기 좋게 정렬되어 있었습니다. 각 필드가 색상으로 구분되어 있어 한눈에 구조를 파악할 수 있었습니다.
상단에 Filter 입력창이 있습니다. 여기에 MongoDB 쿼리를 입력하면 조건에 맞는 문서만 필터링됩니다.
예를 들어 { "status": "active" }를 입력하면 status가 active인 문서만 표시됩니다. 옆에 있는 Sort 탭에서는 정렬 조건을 지정할 수 있습니다.
{ "createdAt": -1 }을 입력하면 최신순으로 정렬됩니다. 이 모든 것이 클릭 몇 번으로 가능합니다.
문서를 직접 수정하고 싶다면 해당 문서를 클릭합니다. 편집 모드로 전환되며, 필드 값을 직접 수정할 수 있습니다.
수정 후 "Update" 버튼을 누르면 바로 반영됩니다. Aggregation 탭은 더 강력한 기능을 제공합니다.
여러 단계의 데이터 처리를 파이프라인으로 구성할 수 있습니다. 각 단계를 시각적으로 추가하고, 중간 결과를 미리 확인할 수 있어 복잡한 쿼리도 쉽게 작성할 수 있습니다.
김개발 씨는 상품 컬렉션에서 카테고리별 상품 개수를 집계해보았습니다. Aggregation 탭에서 $match, $group, $sort 단계를 차례로 추가했습니다.
오른쪽에 각 단계의 결과가 실시간으로 표시되어 쿼리가 제대로 작동하는지 바로 확인할 수 있었습니다. Indexes 탭에서는 인덱스를 관리합니다.
어떤 인덱스가 있는지 확인하고, 새 인덱스를 만들거나 삭제할 수 있습니다. 인덱스 사용 통계도 볼 수 있어 불필요한 인덱스를 정리하는 데 도움이 됩니다.
김개발 씨가 특히 좋아한 기능은 Explain Plan이었습니다. 쿼리가 어떻게 실행되는지 시각적으로 보여줍니다.
인덱스를 타는지, 전체 컬렉션을 스캔하는지 한눈에 알 수 있어 성능 문제를 찾는 데 유용합니다. 박시니어 씨가 덧붙였습니다.
"하지만 실제 서비스 코드에서는 항상 코드로 쿼리를 작성해야 해. UI는 확인용이나 일회성 작업에 쓰는 거야." 김개발 씨는 고개를 끄덕이며 메모했습니다.
실전 팁
💡 - 복잡한 쿼리를 작성할 때는 먼저 UI의 Aggregation 탭에서 테스트한 후 코드로 옮기세요
- Explain Plan을 자주 확인하여 쿼리 성능을 미리 점검하는 습관을 들이세요
5. 백업과 복원
어느 날, 김개발 씨가 실수로 중요한 컬렉션의 데이터를 삭제해버렸습니다. 얼굴이 하얗게 질린 김개발 씨에게 박시니어 씨가 차분하게 말했습니다.
"걱정 마, Atlas 백업에서 복원하면 돼." 그제야 김개발 씨는 안도의 한숨을 쉬었습니다.
백업과 복원은 데이터베이스의 생명보험과 같습니다. Atlas는 자동으로 데이터를 백업하고, 필요할 때 원하는 시점으로 복원할 수 있습니다.
마치 게임에서 세이브 포인트를 만들어 두는 것처럼, 문제가 생겼을 때 이전 상태로 돌아갈 수 있습니다. M10 이상의 클러스터에서 사용할 수 있는 기능입니다.
다음 코드를 살펴봅시다.
// mongodump를 사용한 수동 백업 (로컬 환경)
// 터미널에서 실행
// Atlas 클러스터에서 특정 데이터베이스 백업
mongodump --uri="mongodb+srv://user:pass@cluster0.abc123.mongodb.net/mydb" --out=/backup/$(date +%Y%m%d)
// 특정 컬렉션만 백업
mongodump --uri="mongodb+srv://user:pass@cluster0.abc123.mongodb.net/mydb" --collection=products --out=/backup/products_$(date +%Y%m%d)
// 백업 데이터 복원
mongorestore --uri="mongodb+srv://user:pass@cluster0.abc123.mongodb.net" /backup/20240115/mydb
// 특정 컬렉션 복원 (기존 데이터 유지하며 추가)
mongorestore --uri="mongodb+srv://user:pass@cluster0.abc123.mongodb.net" --nsInclude="mydb.products" /backup/products_20240115
데이터는 언제든 사라질 수 있습니다. 실수로 잘못된 쿼리를 실행할 수도 있고, 서버에 장애가 발생할 수도 있습니다.
해커의 공격으로 데이터가 손상될 수도 있습니다. 백업 없이는 이런 상황에서 속수무책입니다.
Atlas의 백업 시스템은 두 가지 방식으로 작동합니다. 첫 번째는 스냅샷 백업입니다.
특정 시점의 데이터 전체를 사진 찍듯이 저장합니다. 기본적으로 매일 자동으로 생성되며, 일정 기간 보관됩니다.
두 번째는 Continuous Backup입니다. 모든 변경 사항을 실시간으로 기록합니다.
이 기능 덕분에 Point-in-Time Recovery가 가능합니다. 특정 날짜의 특정 시간, 심지어 특정 초까지 지정해서 그 시점의 상태로 복원할 수 있습니다.
Atlas 대시보드에서 Backup 메뉴로 들어가봅니다. 왼쪽에 스냅샷 목록이 보입니다.
각 스냅샷 옆에는 생성 시간이 표시되어 있습니다. 복원하려면 원하는 스냅샷을 선택하고 "Restore" 버튼을 클릭합니다.
두 가지 옵션이 나타납니다. Restore to this cluster는 현재 클러스터에 덮어씌웁니다.
Restore to another cluster는 다른 클러스터에 복원합니다. 김개발 씨의 경우처럼 특정 컬렉션만 실수로 삭제했다면 어떻게 할까요?
전체를 복원하면 다른 데이터까지 이전 상태로 돌아가버립니다. 이럴 때는 새 클러스터에 복원한 후, 필요한 컬렉션만 추출해서 원래 클러스터로 옮기는 방법을 사용합니다.
조금 번거롭지만 안전한 방법입니다. Backup Policy에서 백업 주기와 보관 기간을 설정할 수 있습니다.
기본 설정은 매일 스냅샷을 생성하고 7일간 보관합니다. 필요에 따라 주간 스냅샷, 월간 스냅샷을 추가로 설정할 수 있습니다.
무료 티어(M0)에서는 이 기능을 사용할 수 없다는 점을 기억해야 합니다. M10 이상의 유료 클러스터에서만 자동 백업이 활성화됩니다.
무료 티어에서는 mongodump를 사용해 수동으로 백업해야 합니다. mongodump는 MongoDB에서 제공하는 명령줄 도구입니다.
Atlas 클러스터에 연결해서 데이터를 로컬 파일로 내려받습니다. 정기적으로 스크립트를 실행하도록 설정하면 자동 백업과 비슷한 효과를 얻을 수 있습니다.
박시니어 씨가 마지막으로 당부했습니다. "백업이 있다고 안심하면 안 돼.
복원 테스트를 해봐야 진짜 백업이야." 백업 파일이 손상되었거나 복원 절차에 문제가 있을 수 있기 때문입니다. 주기적으로 복원 테스트를 해보는 것이 좋습니다.
김개발 씨는 그날 이후로 중요한 작업 전에는 항상 백업 상태를 확인하는 습관을 들였습니다.
실전 팁
💡 - 프로덕션 환경에서는 M10 이상 클러스터를 사용하여 자동 백업을 활성화하세요
- 백업 정책 설정 시 규정 준수 요구사항(데이터 보관 기간 등)을 확인하세요
6. Performance Advisor
서비스 오픈 후 한 달이 지났습니다. 사용자가 늘어나자 페이지 로딩이 느려졌다는 불만이 들어오기 시작했습니다.
김개발 씨는 데이터베이스 쿼리를 의심했지만, 어디서부터 손을 대야 할지 막막했습니다. 그때 박시니어 씨가 알려준 것이 바로 Performance Advisor였습니다.
Performance Advisor는 Atlas가 제공하는 자동 성능 분석 도구입니다. 마치 자동차의 진단 시스템처럼, 데이터베이스의 느린 쿼리를 찾아내고 개선 방법을 제안해줍니다.
인덱스 추천 기능이 특히 유용하며, 클릭 한 번으로 제안된 인덱스를 생성할 수 있습니다. M10 이상의 클러스터에서 사용할 수 있습니다.
다음 코드를 살펴봅시다.
// Performance Advisor가 제안할 수 있는 인덱스 예시
const { MongoClient } = require('mongodb');
const client = new MongoClient(uri);
async function createRecommendedIndex() {
const db = client.db("myshop");
const orders = db.collection("orders");
// Performance Advisor가 제안한 복합 인덱스 생성
await orders.createIndex(
{ "userId": 1, "createdAt": -1 },
{ name: "userId_createdAt_idx" }
);
// 인덱스 생성 전후 쿼리 성능 비교
const explain = await orders.find({
userId: "user123",
createdAt: { $gte: new Date("2024-01-01") }
}).explain("executionStats");
console.log("실행 시간:", explain.executionStats.executionTimeMillis, "ms");
console.log("스캔한 문서:", explain.executionStats.totalDocsExamined);
}
데이터베이스 성능 문제는 서비스 성장의 피할 수 없는 관문입니다. 사용자가 늘어나고 데이터가 쌓일수록 쿼리는 점점 느려집니다.
적절한 조치를 취하지 않으면 서비스 전체가 멈출 수도 있습니다. 성능 문제의 가장 흔한 원인은 인덱스 부재입니다.
인덱스가 없으면 MongoDB는 모든 문서를 하나하나 확인해야 합니다. 이것을 컬렉션 스캔이라고 합니다.
문서가 10개일 때는 괜찮지만, 100만 개가 되면 심각한 문제가 됩니다. Atlas Performance Advisor는 이런 문제를 자동으로 찾아줍니다.
대시보드에서 클러스터를 선택하고 Performance Advisor 탭을 클릭합니다. 화면에 성능 개선이 필요한 쿼리 목록이 나타납니다.
각 쿼리 옆에는 예상 성능 향상 정도가 표시됩니다. "High Impact"라고 표시된 것부터 해결하는 것이 좋습니다.
쿼리를 클릭하면 상세 정보가 나타납니다. 어떤 컬렉션에서 실행되는 쿼리인지, 평균 실행 시간이 얼마인지, 하루에 몇 번이나 실행되는지 알 수 있습니다.
가장 유용한 것은 인덱스 추천 기능입니다. Advisor가 분석 결과를 바탕으로 생성해야 할 인덱스를 알려줍니다.
어떤 필드에 어떤 순서로 인덱스를 만들어야 하는지 구체적으로 제안합니다. "Create Index" 버튼을 클릭하면 제안된 인덱스가 바로 생성됩니다.
터미널에서 명령어를 입력할 필요가 없습니다. 물론 프로덕션 환경에서는 신중하게 판단해야 합니다.
인덱스 생성도 시스템에 부하를 주기 때문입니다. Real-Time Performance Panel도 함께 활용하면 좋습니다.
현재 실행 중인 쿼리를 실시간으로 모니터링합니다. 비정상적으로 오래 걸리는 쿼리를 발견하면 바로 조치를 취할 수 있습니다.
김개발 씨는 Performance Advisor의 제안에 따라 3개의 인덱스를 추가했습니다. 결과는 놀라웠습니다.
평균 쿼리 응답 시간이 800ms에서 50ms로 줄었습니다. 사용자들의 불만도 사라졌습니다.
하지만 박시니어 씨는 주의를 당부했습니다. "인덱스가 많다고 무조건 좋은 건 아니야.
쓰기 작업이 많은 컬렉션에서는 인덱스가 오히려 성능을 떨어뜨릴 수 있어." 인덱스는 읽기 성능을 높이지만, 데이터를 추가하거나 수정할 때마다 인덱스도 함께 업데이트해야 하기 때문입니다. Query Profiler를 통해 특정 쿼리의 실행 계획을 상세히 분석할 수도 있습니다.
인덱스를 타는지, COLLSCAN(컬렉션 스캔)을 하는지 확인할 수 있습니다. 쿼리 최적화의 첫걸음은 현재 상태를 정확히 파악하는 것입니다.
김개발 씨는 이제 주기적으로 Performance Advisor를 확인하는 습관을 들였습니다. 문제가 커지기 전에 미리 발견하고 해결하는 것이 최선의 방법이라는 것을 깨달았습니다.
실전 팁
💡 - 인덱스 추가 전에 해당 컬렉션의 읽기/쓰기 비율을 고려하세요
- 운영 시간에 인덱스를 생성할 때는 background 옵션 사용을 고려하세요
이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!
댓글 (0)
함께 보면 좋은 카드 뉴스
서비스 메시 완벽 가이드
마이크로서비스 간 통신을 안전하고 효율적으로 관리하는 서비스 메시의 핵심 개념부터 실전 도입까지, 초급 개발자를 위한 완벽한 입문서입니다. Istio와 Linkerd 비교, 사이드카 패턴, 실무 적용 노하우를 담았습니다.
EFK 스택 로깅 완벽 가이드
마이크로서비스 환경에서 로그를 효과적으로 수집하고 분석하는 EFK 스택(Elasticsearch, Fluentd, Kibana)의 핵심 개념과 실전 활용법을 초급 개발자도 쉽게 이해할 수 있도록 정리한 가이드입니다.
Grafana 대시보드 완벽 가이드
실시간 모니터링의 핵심, Grafana 대시보드를 처음부터 끝까지 배워봅니다. Prometheus 연동부터 알람 설정까지, 초급 개발자도 쉽게 따라할 수 있는 실전 가이드입니다.
분산 추적 완벽 가이드
마이크로서비스 환경에서 요청의 전체 흐름을 추적하는 분산 추적 시스템의 핵심 개념을 배웁니다. Trace, Span, Trace ID 전파, 샘플링 전략까지 실무에 필요한 모든 것을 다룹니다.
Spring MongoDB 완벽 가이드
MongoDB와 NoSQL의 핵심 개념부터 Spring Data MongoDB를 활용한 실전 CRUD까지, 초급 개발자도 쉽게 따라할 수 있는 완벽한 가이드입니다. JPA와의 비교를 통해 언제 MongoDB를 사용해야 하는지 명확하게 이해할 수 있습니다.