Spring Boot + MongoDB 인증 오류: default auth db가 ’test’여서 authenticate가 실패하는 문제

검증 환경

본 절은 원문 사례·문서에 등장한 버전/도구를 정리한 것이다. 별도 실험실 재현이 명시되지 않은 항목은 일반화하지 않는다.

  • 본문에 명시된 오류 메시지·프레임워크 버전을 기준으로 원인을 추적했다.
  • 문서 정리일: 2026-08-31
  • OS/CI 세부 값은 프로젝트마다 다르므로, 적용 전 로컬에서 동일 오류 메시지를 재확인한다.

1. 문제 정의

Spring Boot 애플리케이션을 실행하면서 MongoDB에 연결할 때 아래와 같은 인증 오류가 발생하는 상황을 다룹니다. 요청을 처리하는 스레드(nio-8087-exec-1)에서 소켓 연결이 닫히고, 예외가 전파됩니다.

에러 로그

1
2
3
4
5
6
7
8
9
INFO 5231 --- [nio-8087-exec-1] org.mongodb.driver.connection: Closed connection
  [connectionId{localValue:2}] to 192.168.0.2:27017 because there was a socket exception raised by this connection.

org.springframework.data.mongodb.UncategorizedMongoDbException: Exception authenticating
  MongoCredential{mechanism=SCRAM-SHA-1, userName='admin', source='campbell', password=<hidden>, mechanismProperties={}};
  nested exception is com.mongodb.MongoSecurityException: Exception authenticating
  MongoCredential{mechanism=SCRAM-SHA-1, userName='admin', source='campbell', password=<hidden>, mechanismProperties={}}
    at org.springframework.data.mongodb.core.MongoExceptionTranslator.translateExceptionIfPossible(MongoExceptionTranslator.java:138)
    at org.springframework.data.mongodb.core.Mo...

이 경우 UncategorizedMongoDbException 로 래핑된 MongoSecurityException 이 발생하며, 근본적으로는 인증(Authentication) 단계에서 실패한 것입니다.

증상 fingerprint

  • 에러 메시지: Exception authenticating MongoCredential{mechanism=SCRAM-SHA-1, userName='...', source='...'} + MongoSecurityException
  • 발생 단계: 애플리케이션 런타임 중 MongoDB 커넥션 풀에서 인증이 진행될 때 (요청 처리 스레드에서 소켓 오류와 함께 나타남)
  • 관련 도구/프레임워크: Spring Boot + Spring Data MongoDB, MongoDB 드라이버(SCRAM-SHA-1 메커니즘)
  • 흔한 오해: “비밀번호가 틀렸다"고 단정하는 것. 실제로는 대상 인증 DB가 틀려서 발생하는 경우가 흔합니다.
  • 빠른 판단 기준: MongoCredentialsource='...' 값이 실제 사용자가 생성된 DB명과 같은지 먼저 확인합니다.

2. 원인 탐구 (표면 증상)

표면적으로는 인증 자체가 거부되는 모습이지만, 여기에는 두 가지 서로 다른 실패 지점이 섞여 있을 수 있습니다.

  1. 자격 증명(사용자명/비밀번호)이 잘못된 경우
  2. 올바른 자격 증명인데 ‘어느 DB를 대상으로 인증’할지를 잘못 지정한 경우

Spring Data MongoDB에서 연결에 usernamepassword만 지정하고 인증 DB를 지정하지 않으면, MongoDB 드라이버는 기본값으로 test 데이터베이스를 인증 대상으로 사용합니다. MongoDB에서 인증은 “해당 DB의 사용자"를 기준으로 수행되기 때문에, 사용자가 admin 등 다른 DB에 생성되어 있다면 기본값인 test에 대해서는 인증에 실패하게 됩니다.

아래는 문제가 되는 전형적인 설정입니다.

application.properties (잘못된/누락된 설정)

1
2
3
4
5
spring.data.mongodb.host=192.168.0.2
spring.data.mongodb.port=27017
spring.data.mongodb.database=campbell
spring.data.mongodb.username=admin
spring.data.mongodb.password=your_password

여기서 spring.data.mongodb.database=campbell연결 후 사용할 기본 데이터베이스일 뿐이고, 인증 DB(authentication database)를 지정하지 않았기 때문에 드라이버는 test DB에 대해 admin 사용자로 인증을 시도합니다. 그 결과 MongoCredential{userName='admin', source='test'} 형태가 되어 실패합니다.

원인 후보 매트릭스

원인 후보확인 방법맞는 경우의 증상해결 방향
비밀번호가 틀림mongosh로 해당 DB 사용자 로그인 시도정확한 인증 DB에서도 로그인 실패자격 증명 재확인/재발급
인증 DB가 기본값 ’test’로 잘못 지정됨MongoCredential 로그의 source='...' 값 확인인증 DB만 지정하면 정상 연결됨authentication-database 설정 추가
사용자가 존재하지 않는 DB에 저장됨mongosh에서 확인사용자가 실제로 생성된 DB 확인 필요정확한 생성 DB로 authentication-database 지정
방화벽/네트워크 차단nc -vz <host> <port> 등으로 포트 확인접속 자체가 안 되어 소켓 시도 반복네트워크/방화벽 점검

3. 근본 원인 분석

이 오류의 본질은 **“패키지/네트워크 문제가 아니라, 인증 대상 데이터베이스를 잘못 바라보는 설정 미스매치”**입니다.

MongoDB의 인증 모델에서, 사용자 계정은 전역이 아니라 특정 데이터베이스(또는 admin)에 귀속됩니다. 예를 들어 admin 사용자는 보통 admin DB에 생성됩니다. 드라이버가 인증을 수행할 때는 해당 사용자명을 어떤 DB의 사용자로 취급할지(source / authenticationSource)를 정해야 합니다.

문제는 Spring Data MongoDB가 authSource를 명시적으로 주지 않을 때 기본값으로 test DB를 사용한다는 점입니다. 사용자가 실제로 생성된 DB(admin — 필자의 개별 DB명일 수도 있음)가 아니라 test를 대상으로 인증하므로, 올바른 비밀번호를 넣어도 MongoSecurityException이 발생합니다.

즉, 표면 증상은 “인증 실패” 이지만, 근본 원인은 “인증을 수행할 DB의 기본값 불일치” 입니다. DB 드라이버가 DB별 사용자를 어떻게 검증하는지 이해하면, 비밀번호를 바꾸기 전에 인증 DB부터 점검해야 한다는 점이 분명해집니다.

잘못된 해결책

  • 비밀번호를 임의로 바꿔보기: 인증 DB가 맞지 않은 상황에서는 비밀번호를 아무리 수정해도 해결되지 않으며, 운영 환경에서 계정을 망가뜨릴 위험이 있습니다.
  • 인증 없이 연결(비밀번호 제거): 보안상 허용되지 않으며 MongoSecurityException이 아니라 다른 권한 오류가 나거나 데이터베이스 보호 정책에 차단됩니다. 임시방편으로 쓰지 않습니다.

4. 코드 해결책

인증 대상 DB를 실제 사용자가 생성된 DB로 지정하면 됩니다. 사용자가 admin DB에 생성되었다면 아래처럼 설정합니다.

application.properties

1
2
3
4
5
6
spring.data.mongodb.host=192.168.0.2
spring.data.mongodb.port=27017
spring.data.mongodb.database=campbell
spring.data.mongodb.username=admin
spring.data.mongodb.password=your_password
spring.data.mongodb.authentication-database=admin

application.yml 로 작성하는 경우

1
2
3
4
5
6
7
8
9
spring:
  data:
    mongodb:
      host: 192.168.0.2
      port: 27017
      database: campbell
      username: admin
      password: your_password
      authentication-database: admin

여기서 authentication-database 값은 실제 인증 대상(사용자 생성) DB 이름입니다. admin이 아니라 다른 DB에 사용자가 생성되어 있다면 그 DB명을 지정해야 합니다. spring.data.mongodb.database(연결 후 기본 DB)와는 별개의 값임을 주의합니다.

실전 적용 체크

환경확인할 점
로컬사용자가 생성된 DB명을 정확히 확인 후 authentication-database 지정
CI시크릿/환경변수로 spring.data.mongodb.* 주입 시 인증 DB 값도 함께 주입
프로덕션mongosh로 생성 DB 확인 후 동일 값을 설정, 설정 주입 경로별로 누락 방지

5. 검증 명령 및 재발 방지 조치

설정을 반영한 뒤 아래 방법으로 정상 연결을 검증합니다.

검증 명령 1 — mongosh로 해당 DB 사용자 인증 확인 (환경과 사용자에 맞게 조정)

1
mongosh "mongodb://admin:[email protected]:27017/campbell?authSource=admin"

인증이 성공하면 authSource(=인증 DB)가 admin일 때 정상 접속되는 것을 확인할 수 있습니다. ?authSource=admin을 빼고 실행해 다시 실패한다면, 그동안에 문제였던 인증 DB 불일치가 정확히 재현되는 것입니다.

검증 명령 2 — Spring Boot 기동/헬스체크

1
2
3
4
5
# 애플리케이션 기동 로그에서 MongoDB 연결 인증 통과 확인
./gradlew bootRun

# 또는 기동 중 헬스 엔드포인트로 상태 확인
curl -s http://localhost:8080/actuator/health | grep -i up

앱이 정상 기동되고 MongoDB 인증 관련 예외가 사라지면 해결된 것입니다.

재발 방지 조치 (향후 예방)

  • MongoDB 사용자는 “비밀번호"만이 아니라 “어느 DB에 생성되었는지"까지 같이 관리하고, authentication-database를 명시적으로 설정합니다.
  • 인증 정보를 환경변수/시크릿으로 분리하고, 설정 주입 경로(로컬/CI/프로덕션)마다 인증 DB 값이 누락되지 않도록 템플릿에 포함합니다.
  • MongoCredential 로그의 source='...' 값을 보고 인증 DB가 의도한 DB와 일치하는지 점검하는 습관을 들입니다.

DevTrace verdict

이 문제의 핵심은 비밀번호가 틀린 것이 아니라, Spring Data MongoDB가 기본 인증 DB로 test를 사용해 실제 사용자가 생성된 DB(admin)와 어긋난 데 있으며, spring.data.mongodb.authentication-database로 인증 대상 DB를 정확히 지정하면 해결된다는 점입니다.


출처: StackOverflow — Exception authenticating MongoCredential and Uncategorized Mongo Db Exception

인증 DB의 기본값이 test라는 동작 특성과 authentication-database 설정으로 해결한다는 내용은 위 StackOverflow 답변을 기준으로 하였습니다. 실제 사용자 생성 DB명 및 명령 예시(mongosh, authSource, 헬스체크)는 일반적인 점검 기준으로서 환경에 따라 다를 수 있습니다.

DevTrace 결론

이 오류의 핵심은 비밀번호가 틀린 것이 아니라 Spring Data MongoDB가 기본 인증 DB로 ’test’를 사용해 실제 사용자가 생성된 DB(‘admin’)와 어긋나는 것이며, authentication-database 설정으로 인증 대상 DB를 맞춰주면 해결된다.

원문 출처는 문제 발견의 단서이며, 위 판단과 점검 항목은 DevTrace의 독자 분석이다.