Spring Boot3 min read

SPRING_APPLICATION_JSON의 null로 기존 설정값을 지울 수 없는 이유

2026년 11월 6일3 min read작성자 Flature

SPRING_APPLICATION_JSON의 null은 프로퍼티 조회에서 누락된 값으로 처리되므로 application.properties의 기존 값을 덮어쓰지 못합니다. 동일한 키에 null과 문자열을 각각 지정하는 예제로 해석 규칙과 확인 순서를 설명합니다.

SPRING_APPLICATION_JSON의 null로 기존 설정값을 지울 수 없는 이유

SPRING_APPLICATION_JSON에 넣은 null은 기존 설정을 삭제하는 표시가 아닙니다. JSON 설정 소스에는 포함되지만, PropertySourcesPropertyResolver가 이를 누락된 값으로 취급하므로 우선순위가 낮은 application.properties의 값이 계속 사용됩니다.

설정 우선순위가 높은데도 기존 값이 남는 이유

Spring Boot는 여러 설정 소스에서 프로퍼티를 읽습니다. 제공된 외부 설정 문서의 순서에 따르면 JSON 애플리케이션 설정은 application.properties 같은 설정 데이터보다 우선합니다. 따라서 JSON에 실제 값을 지정하면 파일의 값을 덮어쓸 수 있습니다.

다만 우선순위와 null의 해석은 별개의 규칙입니다. 높은 우선순위의 소스에 키가 있더라도 그 값이 null이면, 프로퍼티 리졸버는 해당 소스에서 사용할 값을 찾지 못한 것으로 처리합니다. 이어서 낮은 우선순위의 소스를 조회하므로 파일에 있는 값이 선택될 수 있습니다.

  • JSON에 문자열 지정: 해당 값으로 파일 설정을 덮어쓸 수 있습니다.
  • JSON에 null 지정: 낮은 우선순위의 값을 가리지 못합니다.
  • JSON에서 키 생략: 해당 JSON 소스가 그 키의 값을 제공하지 않습니다.

null과 키 생략은 JSON 설정 소스 내부의 표현은 다르지만, 낮은 우선순위의 기존 값을 지우지 못한다는 점에서는 같습니다.

예제: null과 문자열을 번갈아 지정하기

전제는 Java로 실행할 수 있는 Spring Boot 실행 JAR인 demo.jar가 있고, 다음 application.properties가 정상적으로 로드되는 것입니다. 같은 키를 지정하는 다른 환경변수, 실행 인자, 프로필별 설정이나 사용자 정의 설정 소스는 없다고 가정합니다. 아래 명령은 Bash 같은 유닉스 계열 셸을 기준으로 한 예시입니다.

# application.properties
notice.message=Hello

먼저 JSON에서 같은 키에 null을 지정해 실행합니다.

SPRING_APPLICATION_JSON='{"notice":{"message":null}}' java -jar demo.jar

중첩된 JSON의 대상 키는 notice.message입니다. 이 조건에서 Spring의 Environment로 해당 키를 조회하면 예상 값은 Hello입니다. null이 파일의 값을 삭제하지 못하기 때문입니다.

반면 실제 문자열을 지정하면 해석이 달라집니다.

SPRING_APPLICATION_JSON='{"notice":{"message":"Welcome"}}' java -jar demo.jar

이번에는 notice.message의 예상 조회 값이 Welcome입니다. JSON 소스가 사용할 수 있는 값을 제공하고, 파일 설정보다 우선하기 때문입니다. 두 실행 명령 자체가 값을 출력하는 것은 아니므로 애플리케이션에서 해당 프로퍼티를 읽는 지점을 확인해야 합니다.

JSON의 notice.message 파일의 값 예상 조회 값
null Hello Hello
키 생략 Hello Hello
"Welcome" Hello Welcome

JSON 전달 실패와 null 처리 규칙을 구분하는 순서

  1. 설정 키를 맞춥니다. 파일의 notice.message와 JSON의 중첩 구조가 같은 프로퍼티를 가리키는지 확인합니다.
  2. null 대신 구분 가능한 문자열을 넣습니다. 위 예제처럼 Welcome으로 바뀐다면 JSON 설정이 전달되고 덮어쓰기에 참여한다는 근거가 됩니다.
  3. 문자열도 반영되지 않으면 다른 소스를 확인합니다. JSON 전달 방식과 함께 같은 키를 지정하는 명령행 인자 등 더 높은 우선순위의 설정을 살펴봅니다.
  4. null로 바꾼 뒤 파일 값이 다시 선택되는지 해석합니다. 다른 조건이 같다면 이는 null을 누락된 값으로 처리하는 규칙에 부합합니다.

Actuator를 이미 사용하는 환경에서는 env와 configprops도 설정 진단에 도움이 될 수 있습니다. 다만 엔드포인트의 접근 허용과 노출이 필요하며, 민감값 마스킹 때문에 실제 값이 보이지 않을 수 있습니다. 이 예제 확인에 Actuator가 필수인 것은 아닙니다.

설정을 없애려는 목적이라면 구분할 것

기존 값 자체를 없애려면 그 값을 제공하는 파일이나 다른 설정 소스를 수정해야 합니다. JSON의 키를 삭제하거나 null로 바꾸는 것만으로는 낮은 우선순위의 값이 제거되지 않습니다. 다른 소스에도 같은 키가 있다면 그 값이 다시 선택될 수 있습니다.

기능을 끄려는 목적이라면 애플리케이션이 지원하는 활성화 설정 등 명시적인 값을 사용하는 방식을 검토할 수 있습니다. 이는 애플리케이션의 설정 계약에 달려 있습니다. 빈 문자열이나 문자열 "null"을 넣는 것도 JSON null과는 다르며, 이를 삭제나 비활성화로 해석한다고 가정해서는 안 됩니다.

이 설명의 범위는 JSON 설정 소스와 프로퍼티 조회 규칙입니다. 바인딩 대상 객체의 초기값, 타입 변환, 애플리케이션 내부의 후처리까지 모두 같은 규칙으로 단정할 수는 없습니다.

실무에서는 먼저 실제 문자열로 JSON 전달 여부를 확인하고, 값을 변경하려는지 설정 자체를 없애려는지 구분해 수정할 소스를 정하면 됩니다.

참고한 공식 문서

이어서 확인할 내용