MongoDB macOS 설치와 로컬 실행: Homebrew·mongosh·보안 확인

2023년 초 채팅 서버를 구현할 프로젝트를 준비하면서 MongoDB의 특징과 macOS 설치 자료를 모았다. 당시 글은 참고 링크만 이어져 있어, 지금 다시 실행하려면 version과 설치 경로, 실행 확인, 보안 경계를 알기 어려웠다. 이번에는 “왜 MongoDB를 검토하는가”부터 로컬 개발 환경을 안전하게 닫는 과정까지 한 흐름으로 정리한다.

명령 예시는 MongoDB 8.0 Community Edition 공식 문서를 기준으로 확인했다. MongoDB와 macOS 지원 범위는 바뀔 수 있으므로 실제 설치 전에는 공식 문서 왼쪽의 version selector와 platform requirement를 다시 확인한다.

MongoDB를 먼저 이해하기

MongoDB는 data를 BSON document로 저장하는 document database다. 같은 collection의 document가 완전히 같은 field set을 가질 필요는 없지만, 이를 “schema가 필요 없다”로 이해하면 곤란하다.

• 함께 조회되는 data를 함께 두는 document model
• embedded document와 array를 통한 계층 표현
• field와 compound key에 index 생성
• replica set을 통한 redundancy와 availability
• shard를 통한 horizontal scale-out
• replica set과 sharded cluster에서 multi-document transaction 지원

flexible schema는 변경을 쉽게 시작하게 해 주지만, application validation과 MongoDB schema validation, index 설계는 여전히 필요하다. access pattern 없이 관계형 table을 document로 그대로 옮기거나 모든 관계를 embedding하면 오히려 query와 update가 어려워진다.

채팅 data를 모델링할 때 볼 질문

채팅 server라면 “MongoDB니까 message를 배열 하나에 계속 넣는다”부터 결정하지 않는다. conversation document 안에 끝없이 커지는 message array를 두면 document size와 update contention 문제가 생길 수 있다.

먼저 access pattern을 적는다.

• 대화방별 최신 message를 시간순으로 읽는가
• 특정 시점 이전 message를 pagination하는가
• unread count와 last message를 얼마나 자주 갱신하는가
• message 수정·삭제 이력을 보존하는가
• 참여자와 권한을 어느 경계에서 확인하는가

message를 별도 document로 둘 경우 (conversationId, createdAt, _id) 같은 query shape에 맞춰 compound index를 검토할 수 있다. index 순서와 선택도 판단은 복합 인덱스 설계 기준으로 이어서 살펴볼 수 있다.

macOS 사전 확인

Homebrew는 macOS 기본 구성요소가 아니다. 이미 설치했다면 실행 위치와 architecture를 확인한다.

uname -m
command -v brew
brew --prefix

Apple Silicon의 기본 Homebrew prefix는 보통 /opt/homebrew, Intel Mac은 /usr/local이지만 사용자 설치 방식에 따라 달라질 수 있다. path를 문서에서 복사해 고정하기보다 brew --prefix 결과를 기준으로 본다.

Homebrew가 없다면 Homebrew 공식 설치 안내를 사용한다. 인터넷에서 복사한 install script는 실행 전에 source와 내용을 확인한다.

MongoDB Community 설치

공식 MongoDB tap을 등록하고 formula를 설치한다.

brew tap mongodb/brew
brew update
brew install mongodb-community@8.0

여기서 8.0은 이 글의 검증 version이다. 다른 major version을 쓰는 project라면 server·driver compatibility를 확인하고 공식 문서의 해당 version command를 선택한다.

설치된 항목은 다음처럼 확인한다.

brew list --versions mongodb-community@8.0
command -v mongod
command -v mongosh
mongod --version
mongosh --version

Service 시작과 연결 확인

로컬 개발에서는 Homebrew service로 시작할 수 있다.

brew services start mongodb-community@8.0
brew services list

새 terminal에서 shell로 접속한다.

mongosh

연결 후 server가 응답하는지 확인한다.

db.runCommand({ ping: 1 })

대화식 shell 없이 자동 확인하려면 다음처럼 exit status까지 본다.

mongosh --quiet --eval 'quit(db.runCommand({ ping: 1 }).ok ? 0 : 1)'

interactive와 automation 환경 차이는 Interactive Shell과 Non-Interactive Shell에서 정리했다.

사용을 마쳤다면 service를 멈출 수 있다.

brew services stop mongodb-community@8.0

설정 파일과 log 위치 찾기

공식 Homebrew 설치의 기본 경로는 architecture에 따라 다르다.

항목	Apple Silicon 기본	Intel 기본
설정	/opt/homebrew/etc/mongod.conf	/usr/local/etc/mongod.conf
data	/opt/homebrew/var/mongodb	/usr/local/var/mongodb
log	/opt/homebrew/var/log/mongodb	/usr/local/var/log/mongodb

고정 경로만 믿지 말고 실제 prefix와 config를 확인한다.

brew --prefix
brew services info mongodb-community@8.0

설정을 바꿀 때는 변경 전 파일을 보관하고, YAML indentation과 option 이름을 공식 version 문서에서 확인한다. start에 실패하면 service를 반복 재시작하기보다 log의 첫 오류와 실제 config path부터 본다.

localhost 밖으로 열기 전에 멈춰야 하는 이유

기본 설치는 bindIp가 localhost인 구성을 사용해 외부 client의 직접 접속을 막는다. 개발 편의를 위해 0.0.0.0으로 바꾸고 public network에 노출하는 방식은 피한다.

remote access가 정말 필요하다면 최소한 다음을 먼저 설계한다.

• authentication과 access control 활성화
• user별 최소 권한 role
• trusted network와 firewall allowlist
• TLS를 통한 in-transit encryption
• backup과 restore test
• secret을 source code와 shell history에 남기지 않는 전달 방식
• production용 replica set과 monitoring

bindIp 변경 하나는 보안 구성이 아니다. local learning, shared development, production deployment를 서로 다른 환경으로 분리한다. 운영 목적이라면 MongoDB의 self-managed production note와 security checklist 전체를 먼저 검토한다.

Local 설치와 Atlas 중 무엇을 고를까

목적	먼저 볼 선택
document model·query 학습	local Community
network 없이 빠른 반복	local Community
팀이 공유하는 managed cluster	Atlas 검토
OS·storage·replica 운영까지 학습	isolated self-managed environment
production	workload·규정·backup·운영 역량을 기준으로 별도 판단

managed service를 쓴다고 schema와 index, access control 책임이 사라지는 것은 아니다. 반대로 local 설치가 됐다고 production topology가 준비된 것도 아니다.

자주 묻는 질문

mongo command가 없고 mongosh만 보이는 이유는 무엇인가

현재 공식 shell은 mongosh다. 오래된 글의 legacy mongo shell command를 그대로 따라가지 말고 설치한 server version의 공식 문서를 사용한다.

MongoDB는 schema가 없는 database인가

document마다 field가 달라질 수 있는 flexible schema를 제공한다. 그러나 안정적인 application에는 schema validation, application type, migration, index 설계가 필요하다.

macOS에 설치한 MongoDB를 그대로 운영해도 되나

로컬 설치 절차는 개발·학습용 출발점이다. production에는 supported platform, authentication, TLS, network isolation, replica set, backup, observability를 별도로 설계해야 한다.

참고 자료

• MongoDB: Install Community Edition on macOS
• MongoDB: Data Modeling
• MongoDB: Replication
• MongoDB: Transactions
• MongoDB: Security Checklist
• Homebrew