조용한 개발 노트

34편에서는 여러 Spring Boot 애플리케이션을 운영할 때 배포·운영 단위를 어떻게 나누는지를 다뤘다.이번 글에서는 그 구조 위에서 반드시 다시 마주치게 되는 주제, PropertySource 우선순위를 다룬다.이 주제는 대부분 이렇게 시작된다. “분명 설정을 바꿨는데, 왜 반영이 안 되지?” 이 질문에 답하려면 Spring Boot의 설정 우선순위를 “기능 목록”이 아니라 설계 의도로 이해해야 한다.1) Spring Boot 설정 우선순위의 기본 철학Spring Boot의 설정 우선순위는 무작위 규칙의 집합이 아니다.핵심 철학은 단순하다. “더 늦게, 더 명시적으로 전달된 설정이 더 강한 의도를 가진다.” 그래서 일반적으로:코드에 가까운 설정 ❌실행 시점에 주입된 설정 ⭕이 원칙 덕분에 같은 바이..

8편에서는 Spring Boot의 Externalized Configuration이 왜 복잡해 보이지만 필요한 설계인지 살펴봤다.설정 이야기를 조금 더 깊게 들어가면, 결국 반드시 마주치는 주제가 하나 있다.Profile은 어떻게 나눠야 할까?많은 프로젝트가 dev / prod 두 개의 Profile로 시작한다. 하지만 규모가 조금만 커져도 이 구조는 빠르게 한계에 부딪힌다.이번 글에서는 왜 dev/prod만으로는 부족한지, 그리고 실무에서 유지 가능한 Profile 설계 기준을 YAML 예시와 함께 정리해본다.1) Profile은 “환경 이름”이 아니다Profile을 이야기할 때 가장 흔한 오해는 이것이다.“Profile = 실행 환경”물론 환경을 표현하는 데 쓰이지만, Profile의 본질은 거기에 ..

7편에서는 Auto-Configuration과 사용자 설정 사이에서 어디까지 개입해야 하는지를 기준으로 정리했다.설정 이야기를 하다 보면, 결국 반드시 마주치는 주제가 하나 있다.“Spring Boot의 설정은 왜 이렇게 복잡해 보일까?”properties, yaml, profile, 환경 변수, 커맨드라인 인자까지. 처음 보면 설정 위치도 많고, 우선순위도 헷갈린다.이번 글에서는 이 복잡함의 정체인 Externalized Configuration을 “왜 이렇게 설계됐는지” 관점에서 풀어본다.1) Externalized Configuration의 목표는 단 하나다Spring Boot가 Externalized Configuration을 도입한 이유는 명확하다.“같은 코드로, 서로 다른 환경에서 실행할 수 ..