코드 땜장이

스프링 @Value 가 기대대로 주입되지 않는 이유와 안전하게 사용하는 방법 스프링 부트에서 설정값을 읽을 때 가장 먼저 떠오르는 도구가 @Value("${...}") 입니다. 문법이 짧고 바로 쓸 수 있어서 편하지만, 동작 원리를 모른 채 남용하면 의외로 자주 문제를 만납니다. 어떤 클래스에서는 값이 잘 들어오는데 다른 곳에서는 null 처럼 보이거나, 애플리케이션 시작 시점에 Could not resolve placeholder 예외가 터지는 식입니다. 핵심은 하나입니다. @Value 는 임의의 객체에 값을 꽂아 넣는 기능이 아니라, 스프링 컨테이너가 관리하는 빈에 대해 정해진 생명주기 안에서 실행되는 주입 메커니즘입니다. 이 전제를 이해하면 @Value 가 잘 맞는 범위, 피해야 할 패턴, 그리고 언제 @ConfigurationProperties 로 넘어가야 하는지가 한 번에 정리됩니다. @Value 는 어떤 문제를 풀고, 어디까지 써야 할까 @Value 는 외부 설정에서 단일 값을 읽어올 때 가장 간단합니다. 예를 들어 API 기본 URL, 타임아웃, 기능 플래그처럼 "몇 개 안 되는 설정"을 빠르게 주입하는 데 적합합니다. application.yml , application.properties , 환경 변수, JVM 옵션, 커맨드라인 인자처럼 스프링 Environment 에 올라온 값이라면 대부분 읽을 수 있습니다. 반대로 관련 설정이 여러 개로 늘어나기 시작하면 @Value 의 약점이 드러납니다. 문자열 키가 서비스 클래스 곳곳에 흩어지고, 리스트나 중첩 구조를 다루려면 표현식이 복잡해지며, 설정 검증도 분산됩니다. 그래서 실무에서는 보통 다음 기준으로 나눕니다. 설정 1~2개를 빠르게 읽는다: @Value 하나의 도메인 설정을 묶어서 다룬다: @ConfigurationProperties 중요한 점은 @Value 가 "간단해서 무조건 좋은 방식"은 아니라는 것입니다. 단순한 ...

스프링 @Value 를 안전하게 쓰는 방법: 주입 시점부터 설정 바인딩 선택 기준까지 스프링 부트에서 설정값을 코드 밖으로 빼는 일은 거의 필수에 가깝습니다. 외부 API 주소, 타임아웃, 토큰, 기능 플래그처럼 환경마다 달라지는 값을 소스 코드에 직접 넣어두면 배포와 운영이 빠르게 꼬입니다. 이때 가장 먼저 떠올리기 쉬운 도구가 @Value 입니다. 문제는 @Value 가 간단해 보인다는 점입니다. 한 줄로 값을 넣을 수 있다 보니 동작 조건과 주입 시점을 놓치기 쉽고, 설정이 커졌을 때도 계속 같은 방식으로 밀어붙이기 쉽습니다. @Value 는 분명 유용하지만, 어디까지가 적절한 사용 범위인지 알아두지 않으면 디버깅 비용이 커집니다. @Value 는 어떤 문제를 해결할까 @Value 는 외부 설정값 하나를 스프링 빈에 주입할 때 가장 빠르게 적용할 수 있는 방법입니다. 예를 들어 base-url , timeout , enabled 같은 단일 값을 서비스나 컴포넌트 안으로 가져와야 할 때 코드 양이 적고 이해하기 쉽습니다. 핵심은 @Value 가 “설정 한두 개를 직접 꺼내 쓰는 도구”라는 점입니다. 값이 적고 맥락이 단순하면 충분히 좋은 선택입니다. 반대로 같은 접두사 아래에 여러 설정이 묶여 있고, 그 설정들이 하나의 의미 있는 그룹을 이룬다면 @Value 보다 @ConfigurationProperties 가 더 자연스럽습니다. @Value 가 동작하는 조건과 주입 시점 가장 먼저 기억해야 할 사실은 @Value 가 스프링이 관리하는 객체에서만 동작한다는 점입니다. @Component , @Service , @Configuration 이 붙어 있거나 @Bean 으로 등록된 객체여야 합니다. 직접 new 로 생성한 객체에서는 스프링이 개입하지 않으므로 @Value 도 작동하지 않습니다. 주입 시점도 중요합니다. 생성자 파라미터에 붙인 @Value 는 객체를 만들기 전에 해석되어 전달됩니다. 반면 필드 주입과 세터 주입은 객체 생성 이후에 적...