MongoDB 4.4를 오래 운영한 환경이라면 8.0 업그레이드는 단순 버전 교체가 아니라 아키텍처 점검 + 애플리케이션 호환성 검증 + 순차 업그레이드 계획이 함께 들어가는 큰 작업입니다. 특히 MongoDB는 4.4에서 8.0으로 직접 업그레이드할 수 없고, 메이저 버전을 순서대로 올려야 하며, 각 단계에서 Feature Compatibility Version(FCV) 을 맞춘 뒤 다음 단계로 넘어가야 합니다.

1. 가장 먼저 알아야 할 핵심: 4.4 → 8.0 직접 업그레이드는 안 된다

MongoDB 공식 문서 기준으로 8.0에 올라가려면 먼저 7.0 계열에 있어야 하고, 7.0에 올라가려면 먼저 6.0 계열에 있어야 합니다. 따라서 4.4 환경은 일반적으로 4.4 → 5.0 → 6.0 → 7.0 → 8.0 순으로 메이저 버전을 차례대로 업그레이드해야 합니다. 또한 8.0 업그레이드 전에는 7.0 배포의 FCV가 7.0이어야 하고, 7.0 업그레이드 전에는 6.0 배포의 FCV가 6.0이어야 합니다.

2. 왜 이번 업그레이드가 까다로운가

4.4에서 8.0까지는 중간에 5.0, 6.0, 7.0을 모두 거치게 되므로, 단순히 “최종 버전만 좋다”가 아니라 각 버전의 호환성 변화가 누적됩니다. MongoDB는 메이저 업그레이드마다 별도의 compatibility changes를 제공하고 있고, 7.0부터는 FCV 변경 시 confirm: true가 필요하며, Community Edition의 경우 바이너리 다운그레이드가 더 이상 지원되지 않습니다. 또한 MongoDB는 한 번에 한 버전만 다운그레이드를 지원합니다.

3. 업그레이드 전에 반드시 확인할 체크 포인트

3-1. 최신 패치 버전부터 맞추기

MongoDB는 각 릴리스 시리즈에서 최신 patch release로 먼저 올리는 것을 권장합니다. 패치 릴리스는 보안 패치와 버그 수정이 중심이며, 일반적으로 메이저 업그레이드 전에 가장 먼저 해야 할 작업입니다.

3-2. 백업 확보

공식 업그레이드 문서도 작업 전 최신 백업 확보를 먼저 요구합니다. 특히 4.4에서 8.0으로 가는 긴 경로에서는 한 단계라도 문제가 생기면 복구 비용이 커지므로, 스냅샷이나 논리 백업, 복제본 기반 복구 전략을 사전에 준비해야 합니다.

3-3. 스테이징 환경에서 먼저 재현

MongoDB는 운영 업그레이드 전에 운영과 같은 구조를 재현한 스테이징 환경에서 먼저 검증하라고 안내합니다. 이번처럼 메이저 버전을 여러 번 뛰어넘는 경우에는 사실상 필수입니다.

3-4. 드라이버 버전 선점검

MongoDB는 인증을 사용하는 배포의 경우 서버보다 드라이버를 먼저 업그레이드하라고 안내합니다. 또 드라이버 호환성 표를 통해 서버 버전과 클라이언트 라이브러리 버전의 호환 여부를 미리 확인할 수 있습니다.

4. 실제 업그레이드 순서에서 가장 중요한 것: FCV

MongoDB 업그레이드에서 가장 많이 놓치는 포인트가 FCV입니다. 문서에는 이전 FCV 업그레이드가 완전히 끝나지 않은 상태에서 더 높은 버전의 바이너리로 재시작하면 노드가 크래시할 수 있다고 나와 있습니다. 따라서 각 단계마다 반드시 다음 흐름을 지켜야 합니다.

권장 흐름

  1. 현재 메이저 버전의 최신 패치까지 올림
  2. 모든 노드 상태 정상 확인
  3. FCV 확인
  4. 다음 메이저 버전 바이너리로 업그레이드
  5. 전체 정상화 확인
  6. 새 버전 FCV 적용
  7. 그 다음 메이저 버전으로 진행

5. 배포 형태별 체크 포인트

5-1. Standalone

Standalone은 절차가 가장 단순하지만, 서비스 중단 영향이 가장 직접적입니다. MongoDB 문서는 standalone 업그레이드 시 현재 버전을 종료하고 새 바이너리로 교체한 뒤, 새 버전 기능은 FCV를 올리기 전까지 비활성 상태로 유지된다고 설명합니다.

5-2. Replica Set

Replica Set은 secondary부터 하나씩 업그레이드하고 마지막에 primary를 업그레이드하는 것이 기본 절차입니다. 각 secondary는 업그레이드 후 다시 SECONDARY 상태로 복귀한 뒤 다음 노드로 넘어가야 하며, 업그레이드/다운그레이드 전에는 모든 멤버가 실행 중이어야 합니다.

5-3. Sharded Cluster

Sharded Cluster는 순서가 더 중요합니다. 공식 문서 기준으로 balancer를 비활성화한 뒤 config server를 먼저 업그레이드하고, 그 다음 각 shard를 업그레이드합니다. 샤딩 환경에서는 버전 호환성뿐 아니라 메타데이터 일관성도 함께 봐야 합니다.

6. 4.4 → 8.0 업그레이드에서 특히 조심할 변경사항

6-1. 7.0부터 Free Monitoring 제거

MongoDB 7.0에서는 Free Monitoring이 종료(decommissioned) 되었습니다. 따라서 기존에 free monitoring 관련 옵션이나 명령을 의존하던 운영 절차가 있다면, Ops Manager나 다른 관측 도구로 미리 전환해두는 것이 좋습니다.

6-2. 7.0부터 $natural 허용값 엄격화

이전 버전에서는 $natural에 잘못된 타입이 들어가도 동작하는 경우가 있었지만, 7.0부터는 1과 -1이 아닌 값을 주면 에러를 반환합니다. 오래된 내부 쿼리 유틸이나 레거시 코드가 있다면 사전 점검이 필요합니다.

6-3. Queryable Encryption Preview 사용 중이면 별도 검토

7.0부터 Queryable Encryption equality queries가 GA가 되었는데, 6.x 시절 Public Preview와는 호환되지 않습니다. 즉, 6.x Preview 기반 컬렉션과 드라이버를 그대로 둔 채 7.0+로 가는 것은 문제가 될 수 있습니다. 이 기능을 이미 쓰고 있다면 일반 업그레이드보다 더 보수적으로 접근해야 합니다.

6-4. Compound Wildcard Index 사용 시 주의

7.0 compatibility 문서에는 compound wildcard index는 FCV 7.0 이상이 필요하며, pre-7.0 mongod는 해당 인덱스를 사용 중이면 시작되지 않을 수 있다고 나와 있습니다. 롤백이나 중간 버전 혼재 구간에서 특히 주의할 항목입니다.

6-5. 8.0에서 정렬과 집계 일부 동작 변화

8.0에서는 존재하지 않는 필드로 정렬할 때 출력 순서가 보장되지 않는다는 점이 다시 강조되고, $rank와 $denseRank에서 null과 missing field 값을 동일하게 취급하도록 바뀌었습니다. 보고서나 분석 파이프라인 결과가 미세하게 달라질 수 있으므로, 집계 결과 비교 테스트를 해보는 편이 좋습니다.

6-6. 8.0에서 TCMalloc 동작 변화

8.0은 업그레이드된 TCMalloc을 사용하며, per-thread cache 대신 per-CPU cache를 사용합니다. MongoDB는 이것이 메모리 단편화를 줄이고 고부하 환경에서 더 견고하게 만든다고 설명합니다. 대신 tcmallocReleaseRate의 의미와 기본값도 바뀌므로, 메모리 튜닝을 수동으로 해오던 환경은 파라미터를 다시 검토해야 합니다.

7. 애플리케이션 관점 체크 포인트

7-1. 드라이버 호환성

서버만 올리고 드라이버를 방치하면 실제 운영에서 장애가 더 잘 납니다. MongoDB는 드라이버 호환성 표를 제공하며, 서버 메이저 버전 업그레이드 전후에 애플리케이션이 사용하는 드라이버 버전이 해당 서버를 안정적으로 지원하는지 확인해야 합니다.

7-2. 정렬/집계 결과 비교 테스트

8.0은 $rank, $denseRank, 정렬 관련 동작이 바뀐 부분이 있으므로, 집계 리포트나 배치 결과를 많이 쓰는 서비스라면 샘플 데이터셋으로 4.4/현행 결과와 8.0 결과를 비교하는 것이 좋습니다.

7-3. 운영 스크립트 점검

Free Monitoring 관련 명령, $natural 잘못된 값 사용, 특정 내부 명령 의존, 오래된 프로파일링/정렬/인덱스 생성 스크립트는 7.0~8.0 구간에서 깨질 수 있습니다. 특히 오래된 셸 스크립트는 한번에 점검하는 것이 안전합니다.

8. 업그레이드 장점: 왜 8.0까지 갈 가치가 있나

8-1. 성능 향상

MongoDB 8.0 릴리스 노트는 7.0 대비 최대 36% 읽기 처리량 향상, 전형적인 웹 애플리케이션 성능 최대 32% 개선, 복제 중 동시 쓰기 최대 20% 향상을 안내합니다. 다만 실제 개선 폭은 워크로드와 인스턴스 구성에 따라 달라질 수 있습니다.

8-2. 새로운 bulkWrite 명령

8.0에서는 여러 컬렉션에 걸친 insert/update/delete를 한 요청으로 처리할 수 있는 새 bulkWrite 명령이 추가되었습니다. 기존 db.collection.bulkWrite()가 컬렉션 하나만 대상으로 하던 것과 비교하면, 대량 처리 파이프라인에서 구조적으로 더 유연합니다. MongoDB는 8.0의 bulkWrite가 7.0 대비 최대 56% 더 빠를 수 있다고 설명합니다.

8-3. 시계열 처리 향상

8.0은 time series 쿼리에 대해 block processing을 사용할 수 있으며, 일부 $group 및 분석성 쿼리에서 200% 이상 처리량 향상 가능성을 제시합니다. 시계열 데이터가 많은 서비스라면 체감 효과가 클 수 있습니다.

8-4. 샤딩 운영 개선

8.0은 resharding 성능 개선이 포함되어 있고, 조건을 만족하면 같은 키로 재분산(same-key resharding) 도 가능합니다. 또한 트랜잭션 안에서 sharded collection 대상 $lookup 사용이 가능해졌습니다. 샤딩 클러스터를 운영 중이라면 장점이 분명합니다.

8-5. 보안 기능 강화

8.0에서는 Queryable Encryption이 encrypted field에 대한 range query를 지원합니다. 또한 감사 로그를 OCSF schema 형식으로 지정할 수 있어, 보안 로그 파이프라인과의 연계가 쉬워집니다.

8-6. 느린 쿼리 분석 정확도 개선

8.0은 느린 쿼리 로깅과 Query Profiler, Performance Advisor, Search Query Telemetry가 durationMillis보다 workingMillis 기준으로 더 정확하게 문제 쿼리를 보고하도록 바뀌었습니다. 운영자 입장에서는 병목 원인 파악이 더 쉬워질 수 있습니다.

9. 실무용 체크리스트

아래 순서로 진행하면 가장 안전합니다.

업그레이드 전

  • 현재 배포 구조 확인: standalone / replica set / sharded cluster
  • 전체 백업 확보
  • 현재 드라이버 및 라이브러리 버전 조사
  • Free Monitoring, Queryable Encryption Preview, wildcard index, $natural 사용 여부 점검
  • 스테이징 환경에서 사전 리허설 수행

업그레이드 중

  • 각 메이저 버전의 최신 patch로 먼저 올림
  • 4.4 → 5.0 → 6.0 → 7.0 → 8.0 순차 진행
  • 각 단계마다 FCV 확인 후 다음 단계 진행
  • replica set은 secondary부터, sharded cluster는 balancer 중지 후 config server → shards 순서로 진행

업그레이드 후

  • FCV 최종값 확인
  • 앱 기능 테스트, 정렬/집계 결과 비교
  • 슬로우 쿼리, 메모리 사용 패턴, 복제 상태 점검
  • 드라이버와 운영 스크립트 재검증

10. 결론

MongoDB 4.4에서 8.0으로 가는 업그레이드는 한 번에 점프하는 작업이 아니라, 여러 번의 메이저 업그레이드를 안전하게 통과하는 프로젝트에 가깝습니다. 핵심은 세 가지입니다. 첫째, 직접 업그레이드는 안 되므로 순차 업그레이드가 필요합니다. 둘째, 각 단계에서 FCV와 드라이버 호환성을 반드시 점검해야 합니다. 셋째, 최종적으로 8.0에 도달하면 성능, bulkWrite, 시계열 처리, 샤딩 운영, 보안 기능 면에서 얻는 이점이 꽤 큽니다.