[Spring] 프로퍼티 주입 시 동적으로 핸들링하기

 

🌱 들어가기 전

블로그를 자주 써야겠다고 생각했는데 또 마지막 글을 쓴 지 3개월이 지나버렸다. 그래서, 사내에서 개발하던 중에 발생했던 이슈가 생각나서 간단하게 적어보고자 한다. 사실 해결 방법은 간단했던 문제였는데, 어떤 식으로 문제를 해결해나갔는지 적어두면 좋을 것 같아서 작성해보고자 한다.

현재 사내 시스템에서는 카프카를 통해 비동기로핵심 비즈니스 로직을 처리하는 부분이 많은데, 우리 서비스의 핵심 기능이라고 볼 수 있을 만큼 중요한 기능이다 보니까 작은 피처를 개발하더라도 꼭 테스트를 해주고 넘어가는 부분들이 있다.
이때, 보통은 본인의 로컬 환경에서 띄워서 테스트를 하는 경우도 많지만, 나 같은 경우 로컬에서 처리되는 느린 속도 & 실제 앱 환경에서 어떤 식으로 돌아가는지 (모든 플로우가 정상적으로 동작하는지) 확인하고 싶은 경우가 많아서 개발 환경에 작업물을 띄워서 테스트하는 경우가 많았다.
 
이때, 현재 사내 시스템 상으로는 내가 작업한 branch를 대상으로 내 요청이 자동으로 포워딩 되는 기능을 제공하고 있어 테스트하는데 어렵지는 않지만, 다음과 같은 문제가 발생하고 있었다.

☁︎ 카프카를 사용하는 부분에 대해서는 별도로 토픽, 혹은 컨슈머 그룹을 분리해주지 않으면 내 개인 작업 환경에서 프로듀싱한 데이터가 개발환경에서 컨슘이 되어 원하는대로 테스트가 동작하지 않음
☁︎ 개발 환경에 바로 merge를 하게 되면 타인의 작업물과 겹치기도 하고, 실수로 운영 환경으로 배포본이 나갈 수 있음

 
첫 번째 문제의 경우, 개발 환경과 내가 작업한 브랜치 환경이 둘 다 컨슘을 진행하게 되어서 일부 트래픽은 개발 환경으로, 일부 트래픽은 나의 개인 브랜치 환경으로 컨슘이 되어, 모든 로직들이 정상적으로 동작하는지 확인이 어려운 문제였다.
 
그래서 보통 우리 팀 인원들은 개발 환경에 바로 merge를 진행하여 테스트를 진행하는 경우도 있었는데, 사실 올바른 테스트 방법은 아니라는 생각이 계속 들었었다. (믿음 주도 개발....) 혹은, 개인 작업물 대상으로 매번 토픽이나 컨슈머 그룹을 변경하여 push 하고, merge 시에 제거하는 방법을 활용하는 방법도 있었다. 당연하게도 이는 매우 귀찮다 보니까 자주 사용하지 않는 방법이었다... ㅠㅠ
 
물론! 통합 테스트를 통해서 어느 정도 확인이 가능하지만 (embedded kafka 활용) 앱 내에서 확인하는 것이 조금 더 편하게 느껴져서 다른 방법으로 해결을 하고 싶었다. (사실 통합 테스트를 사용하는 것이 맞다...! 다만 우리의 모든 비즈니스 로직에 대해 완벽하게 적용이 되어 있는 것은 아니라서 테스트에 조금 더 고도화가 필요한 상황이었던 것도 맞다.)
 
그래서, ‘개인 branch에서 테스트를 할 때 사용자에 따라 자동으로 토픽이 변경되도록 만들기’를 목표로 삼고 이번에 작업을 진행해보았었다.

---

 

🌱 빈 후처리기 도입해보기

현재 사내 프로젝트에서는 토픽에 대한 정보가 application.yml 파일에 정의되어 있어, 토픽에 대한 정보를 받아올 때 다음과 같이 @Value 어노테이션을 사용하여 프로퍼티 정보를 읽어왔었다.

@Value("\${very.important.topic}")
val topic: String

    
그래서 처음 작업을 들어갈 때는 스프링의 @Value 어노테이션이 어떤 식으로 돌아가는지 살펴보고 싶어, @Value 어노테이션에 적혀 있는 주석을 먼저 읽어보았었다.
 

Note that actual processing of the @Value annotation is performed by a BeanPostProcessor which in turn means that you cannot use @Value within BeanPostProcessor or BeanFactoryPostProcessor types. Please consult the javadoc for the AutowiredAnnotationBeanPostProcessor class (which, by default, checks for the presence of this annotation)

위 내용을 보니, 실질적으로 @Value 어노테이션에 대한 처리는 BeanPostProcessor 에 의해서 수행이 된다고 써있는 것을 볼 수 있었으며, AutowiredAnnotationBeanPostProcessor 을 참고해보라는 내용이었다. 오호, 그러면 이 친구를 통해서 진행하겠다 싶어서 대충 내부 내용을 보았다.

public AutowiredAnnotationBeanPostProcessor() {
    this.autowiredAnnotationTypes.add(Autowired.class);
    this.autowiredAnnotationTypes.add(Value.class);
    ...
}

생성자에서 ‘autowiredAnnotationTypes’ 라는 필드에 @Value 어노테이션을 넣어두는 것을 볼 수 있었다.
그리고, 조금 더 파고 들다 보니 대충 다음과 같이 동작한다는 것을 파악하였다.

@Override
public PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) {
    // 빈에 대한 메타데이터 조회하기
    InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs);
    // 의존성 주입하기
    metadata.inject(bean, beanName, pvs);
    return pvs;
}

private InjectionMetadata findAutowiringMetadata(String beanName, Class<?> clazz, @Nullable PropertyValues pvs) {
    ...
    InjectionMetadata metadata = this.injectionMetadataCache.get(cacheKey);
    ...
    // 메타데이터 생성
    metadata = buildAutowiringMetadata(clazz);
}

private InjectionMetadata buildAutowiringMetadata(Class<?> clazz) {
    // @Value나 @Autowired 가 붙은 게 아니라면 패스
    if (!AnnotationUtils.isCandidateClass(clazz, this.autowiredAnnotationTypes)) {
        return InjectionMetadata.EMPTY;
    }

    ...

    List<InjectionMetadata.InjectedElement> elements = new ArrayList<>();

    final List<InjectionMetadata.InjectedElement> currElements = new ArrayList<>();

    // 어노테이션 찾아서 메타데이터 생성
    ReflectionUtils.doWithLocalFields(targetClass, field -> {
    MergedAnnotation<?> ann = findAutowiredAnnotation(field);
    if (ann != null) {
        if (Modifier.isStatic(field.getModifiers())) {
            if (logger.isInfoEnabled()) {
                logger.info("Autowired annotation is not supported on static fields: " + field);
            }
            return;
        }
        boolean required = determineRequiredStatus(ann);
        currElements.add(new AutowiredFieldElement(field, required));
    }
});

    ...

    return InjectionMetadata.forElements(elements, clazz);
}

- 특정 클래스에서 @Autowired가 붙은 필드와 메서드를 찾아내고, 해당 필드나 메서드가 의존성 주입을 받을 수 있도록 메타데이터를 구축한다.
- 구축된 메타데이터를 바탕으로 실제로 주입을 진행한다.
- 이것을 보고 대충 빈 후처리기를 활용하여 리플렉션을 통해 동적으로 필드 내용을 변경해줄 수 있을 것 같다는 생각이 들었다.
 

---

 

🌱  사용자 구분하기

그렇다면, 이번에는 사용자를 어떻게 식별하면 좋을지가 고민이 되었다.
실제로 개인 branch를 대상으로 애플리케이션이 띄워질 때 서버의 프로퍼티를 동적으로 주입해줄 수 있도록 만들어도 되지만, 인프라 레벨까지 무언가 수정을 하고 싶지 않아서 어떤 정보를 활용할 수 있을지 고민을 했었다.
 
그러다가 발견한 것이, 처음 스프링이 시작될 때 뜨는 문구였다.
처음 스프링이 시작되면 ‘Starting TestApplication using Java 17.0.10 on jwjw-1 with PID …‘ 와 같은 문구가 뜬다는 것을 보고, 여기에서 ‘jwjw-1’라는 이름은 어디에서 가져오는지 궁금해졌었다.
 
실제로 다른 개발자분들이 서버를 뜰 때 다 다른 이름이 노출되는 것을 보고, 이 이름을 사용하여 토픽의 postfix로 붙여준다면 딱 사용자 수만큼만 신규 토픽이 생성되니 괜찮을 것이라고 판단하였다.
 
그래서, 이 문구를 어디에서 찍어줄지 확인해보기 위해서 또 다시 하나씩 파고 들기 시작했다.
기본적으로 코틀린 + 스프링 부트를 사용한다면 main 함수에 다음과 같은 실행 함수가 있는 것을 볼 수 있다.

fun main(args: Array<String>) {
    runApplication<TestApplication>(*args)
}

inline fun <reified T : Any> runApplication(vararg args: String): ConfigurableApplicationContext =
    SpringApplication.run(T::class.java, *args)

    
여기에서 내부를 계속 파고 들어가다 보면, 다음과 같이 start messsage를 만드는 것을 볼 수 있는데, 여기에서 appendOn() 함수를 보면, 내부적으로 InetAddress.getLocalHost().getHostName() 를 통해서 받아오는 것을 알 수 있었다!
 

private CharSequence getStartingMessage() {
    StringBuilder message = new StringBuilder();
    message.append("Starting ");
    appendApplicationName(message);
    appendVersion(message, this.sourceClass);
    appendJavaVersion(message);
    // 여기!
    appendOn(message);
    appendPid(message);
    appendContext(message);
    return message;
}

private void appendOn(StringBuilder message) {
    long startTime = System.currentTimeMillis();
    append(message, "on ", () -> InetAddress.getLocalHost().getHostName());
    ...
}

호스트 이름을 활용하게 되면 개인 branch에서 작성한 내용이 나간 서버의 경우 해당 branch를 트리거한 사용자의 정보가 남기 때문에 이를 바탕으로 식별을 하면 좋을 것 같다고 판단하였다.
 

---

 

🌱  빈 후처리기를 활용한 초기 구성

 
어느 정도 윤곽이 잡혔으니, 실제로 코드를 작성해보자.
초기에는 `@ConvertTopic` 이라는 어노테이션을 만들어서, 해당 어노테이션이 붙어 있는 필드들에 대해 리플렉션으로 접근하여 객체를 다시 만들어주는 방법을 생각하였다.

@Target(AnnotationTarget.FIELD)
@Retention(AnnotationRetention.RUNTIME)
annotation class ConvertTopic(
    val topic: String
)

 
여기에서 필드로 가지고 있는 ‘topic’에 실제 토픽 정보를 담은 프로퍼티 이름을 담을 수 있도록 설정하였다.
이후, 빈 후처리기 함수의 인터페이스 중에서 스프링 빈이 생성된 이후, 초기화 콜백이 호출되기 이전에 호출될 수 있도록 postProcessBeforeInitialization() 함수를 활용하였다.
    

@Component
class ConvertTopicAnnotationBeanPostProcessor(
    private val environment: Environment,
    @Value("\${spring.profiles.active}")
    private val profile: String,
) : BeanPostProcessor {

    override fun postProcessBeforeInitialization(bean: Any, beanName: String): Any? {
        ReflectionUtils.doWithFields(bean::class.java, ConvertTopicCallback(bean, environment, profile))
        return bean
    }
}

다행히도 스프링에서는 ReflectionUtils 라는 고급 도구를 제공해주고 있기 때문에, 조금 더 간결하게 코드를 작성할 수 있었다.
두 번째 인자로 작성한 FieldCallback 을 통하여 특정 필드에 대해 해당 콜백 내부에서 조작해 첫 번째 인자로 받은 클래스를 원하는대로 바꿀 수 있게 된다.
 

class ConvertTopicCallback(
    private val bean: Any,
    private val environment: Environment,
    private val profile: String,
) : ReflectionUtils.FieldCallback {

    override fun doWith(field: Field) {
        // 원하는 profile이 아니면 조작 X
        if (profile != "...") {
            return
        }

        val targetAnnotation = field.getAnnotation(ConvertTopic::class.java) ?: return
        field.isAccessible = true

        // topic 필드에 담긴 프로퍼티 정보를 바탕으로 실제 값 가져오기
        val original = environment.getProperty(targetAnnotation.topic)

        // 바뀐 값
        val hostName = InetAddress.getLocalHost().hostName
        val new = original.plus(".$hostName")
        field.set(bean, new)
    }
}

 
그리고, 해당 어노테이션이 달려 있는 필드에 대해서만 동작할 수 있도록 간단한 검증 조건을 추가해주고, 흔한 리플렉션 코드에서 많이 볼 수 있는 isAccessible 처리를 통해 필드 값을 조작할 수 있게 해주었다. 실제로는 profile 별로 조금 더 컨버팅 하는 로직을 분리하였지만, 여기에서는 간략하게 호스트 이름을 불러온 프로퍼티에 추가하는 정도로만 작성해두었다.
굉장히 복잡해 보여도, 실제 코드를 보면 단순히 필드 값을 원하는대로 바꾸어서 셋팅해주는 정도이다.
 
정상적으로 기능이 동작하는지 테스트 코드를 통해 확인해보자.

@Component
class TestClass(
    @Value("\${test-topic1}")
    private val testTopic1: String
) {
    @ConvertTopic("test-topic2")
    private lateinit var testTopic2: String

    fun getTestTopic1(): String {
        return testTopic1
    }

    fun getTestTopic2(): String {
        return testTopic2
    }
}

먼저, 테스트 클래스를 하나 정의하여 만들어준 @ConvertTopic 어노테이션을 붙인 필드와 기본 @Value 를 통하여 정의한 필드를 각각 선언해주었다.
   

@Import(TestClass::class)
@TestPropertySource(
    properties = [
        "test-topic1=topic1",
        "test-topic2=topic2"
    ]
)
class ConvertTopicAnnotationBeanPostProcessorTest(
    private val testClass: TestClass,
) : BehaviorSpec({

    Given("토픽 치환 테스트") {
        When("@ConvertTopic 가 붙어 있지 않은 변수에 대해서") {
            Then("컨버팅을 진행하지 않는다.") {
                testClass.getTestTopic1() shouldBe "topic1"
            }
        }

        When("@ConvertTopic 가 붙은 변수에 대해서") {
            Then("컨버팅을 진행한다.") {
                testClass.getTestTopic2() shouldBe "topic2.test"
            }
        }
    }
})

그리고, @TestPropertySource 를 통해서 실제 테스트 클래스에서 사용할 테스트 프로퍼티를 정의해주었다. application-test.yml 등을 활용해도 좋지만, 해당 테스트 클래스에서만 유효하기를 바랬고, 무엇보다 명시적으로 테스트에 드러나기를 바랬다. (별도의 파일로 분리하게 되면 아무래도 해당 파일을 다시 들어가서 확인을 해봐야 하니까 불편하게 느껴질 수도 있겠다는 생각이 들었다,)
 
실제로 테스트를 돌려보면 의도대로 잘 동작을 하였으며, test-topic1의 경우 그대로 topic1 이라는 값으로, test-topic2의 경우 topic2가 아닌 topic2.test로 컨버팅이 잘 된 것을 볼 수 있었다!
 
그러나, 여기에서 한 가지 찜찜한 점이 있었다. 바로, TestClass에서도 볼 수 있는 것처럼 생성자 주입을 할 수 없었던 것이었다.
아무래도 클래스의 생성자 파라미터가 아닌 필드 파라미터를 접근하도록 하려고 하다 보니 그랬던 것 같았었다. 이를 해결하기 위해 다음과 같이 @Value + @ConvertTopic 을 함께 혼용하여 사용하고, 필드에 대한 콜백 로직을 살짝 수정해주었다.
 

override fun doWith(field: Field) {
    // 필드에 어노테이션이 존재하는지 확인
    if (field.isAnnotationPresent(ConvertTopic::class.java).not()) {
        return
    }

    // ...

    // bean 객체에 대해 field로 지정된 필드 값을 조회할 수 있도록 수정
    // 원본 값
    val original = field.get(bean).toString()

    // 바뀐 값
    val hostName = InetAddress.getLocalHost().hostName
    val new = original.plus(".$hostName")
    field.set(bean, new)
}

어노테이션의 필드로 주어졌던 값을 활용했던 것과 다르게, 이번에는 bean 객체의 field 값을 직접 접근하도록 만들었다. 이 코드가 잘 이해가 안 될 수 있는데, 아래 테스트 클래스의 예제를 바탕으로 알아보자.
 

@Component
class TestClass(
    @Value("\${test-topic1}")
    private val testTopic1: String,

    @ConvertTopic
    @Value("\${test-topic2}")
    private val testTopic2: String,
)

 
빈 후처리기의 경우 빈이 생성된 이후, 즉 스프링에서 프로퍼티에 대한 placeHolder 작업이 완료된 이후에 처리되기 때문에 testTopic2에는 @Value 로 부터 주입받은 ‘topic2’ 라는 값이 들어가 있게 된다.
이후, field.get(bean) 를 하게 되면 주입된 값인 ‘topic2’ 라는 값이 반환되기 때문에, environment에 대해서도 접근할 필요 없이 바로 해당 값을 original로 판단하여 호스트 이름을 postfix로 붙여주면 된다.
 

---

🌱 하지만 문제가 발생하였다

그러나, 항상 그렇듯이 이렇게 끝나면 참 좋았겠지만… 위의 로직에는 2가지 정도의 문제가 있었다.

☁︎ 처음 보면 이해하기 어려운 코드 + 리플렉션 사용으로 인한 거부감
☁︎ lazy 대리자에 대해서 제대로 작동되지 않음

 
먼저, 리플렉션의 경우 성능 저하가 발생할 수는 있으나, 어차피 처음에 빈이 띄워질 때 수정이 되는 것이라서 크게 우려되지 않았다. 그러나, 이것보다는 너무 스프링에 의존적인 코드이기 때문에 처음 보는 사람이 읽기 어려운 코드가 될 수 있겠다는 생각이 들었다.
또한, 사실상 실제 비즈니스 로직은 호스트 이름을 가져와서 프로퍼티에 붙여주기만 하면 되는 것인데, bean이나 ReflectionUtils 같은 것들이 들어가면서 왜인지 모를 거부감이 들 수 있겠다는 생각이 들었다.

사실, 위의 문제보다 그 아래 문제가 더 크게 걸리는 부분이었다. 이전 문제의 경우 팀원들에게 충분한 공유를 하고 사용할 수 있도록 리딩할 예정이었기에 괜찮았지만, 이는 아예 정상적으로 동작하지 않는 문제가 나타났던 것이었다.
 
사내 프로젝트에서는 다음과 같이 코틀린에서 제공하는 lazy 대리자를 활용하여 기본적인 기능들에 대해 추상화를 진행해두어 사용하고 있었다. 실제 코드를 발췌할 수 없기 때문에, 대략 이런 느낌으로 사용한다고만 생각해두자.

@Component
class ImportantHandler(
    @Value("\${very.important.topic}")
    topic: String,
    factory: Factory,
    ...
): Handler by factory.create(
    topic = topic
    ...
)

inline fun <reified T: ...> Factory.create(
    topic: String
    ...
): ConcurrentHandler<String, T> {
    ...
}

다만, 위의 상황에서 @ConvertTopic을 사용하면 어떻게 될까?

@Component
class ImportantHandler(
    @ConvertTopic
    @Value("\${very.important.topic}")
    topic: String,
    factory: Factory,
    ...
): Handler by factory.create(
    topic = topic
    ...
)

먼저, 위와 같이 사용하기 위해서는 @ConvertTopic의 타겟 타입에 value parameter도 추가해줘야 한다.

@Target(AnnotationTarget.FIELD, AnnotationTarget.VALUE_PARAMETER)
@Retention(AnnotationRetention.RUNTIME)
annotation class ConvertTopic

이러면, factory.create() 로 넘어가는 topic 값이 변화가 될 것이라 생각할 수 있지만 실제로는 그렇게 동작하지 않는다. 이는, 이 함수가 실제로 자바에서 어떻게 동작하는지 확인하면 알 수 있기에 디컴파일을 진행해보자.

public class ImportantHandler implements Handler {
    private final ConcurrentHandler $$delegate_0;

    public ImportantHandler(@ConvertTopic @Value("\${very.important.topic}") @NotNull String topic, ...) {
    Intrinsics.checkNotNullParameter(topic, "topic");
    ...
    String[] var12 = new String[]{topic};
    this.$$delegate_0 = DefaultImpls.create$default(var12, ...)
}

    // 실제 비즈니스 로직을 담은 함수. 대리자에 의해 다음과 같이 수행된다.
    public void run() {
        this.$$delegate_0.run();
    }
}

위임을 위해 ImportantHandler의 필드로 ConcurrentHandler 를 가지고, 생성자 내부에서 delegate 필드가 채워지는 것을 볼 수 있다. 앞서 말했던 것처럼, 빈 후처리기의 초기화 과정은 빈이 생성된 이후 = 즉, 객체가 생성된 이후에 진행된다. delegate 필드가 초기화되는 시점에서 topic 필드는 아직 컨버팅이 되기 이전의 값이기 때문에, 컨버팅이 되기 이전의 값으로 데이터가 초기화가 되면서 정상적으로 동작하지 않게 되는 것이다.

이후 빈 후처리기 과정에서 topic이 초기화가 되더라도, 이미 delegate 필드가 가지고 있는 속성은 초기화가 완료가 된 상태이기 때문에 변화되지 않는다. 그래서 비즈니스 로직으로 인해 run() 메서드가 수행이 되더라도 topic 값이 변하지 않은 속성을 가진 delegate.run()이 수행이 되기 때문에 의도대로 동작하지 않는 것이다.
 
그래서, 위의 문제를 해결하기 위해 처음에는 lazy 대리자를 사용하지 않고 다음과 같이 직접 위임을 하는 것은 어떨지 생각해보았다.

@Component
class ImportantHandler(
    @ConvertTopic
    @Value("\${very.important.topic}")
    topic: String,
    factory: Factory,
    ...
): Handler {

    private lateinit var delegate: ConcurrentHandler

    @PostConsturct
    fun init() {
        delegate = factory.create(topic, ..)
    }

    override fun run() {
        delegate.run()
    }

    // ...
}

이때, @PostConsturct 를 통해서 빈 후처리기가 동작한 이후에 delegate 필드가 초기화가 될 수 있도록 만들었다. 이러면 컨버팅이 된 topic 값을 통해 delegate 객체가 생성되기 때문에 의도대로 잘 동작은 하였다.
 
그러나, override를 통해 모든 메서드들을 다시 재정의하는 것도 너무 번거롭고, 코틀린 언어의 장점을 하나도 사용하지 못하는 코드인 것 같았다. 코드의 길이 역시 이전보다 훨씬 길어지기 때문에 위와 같은 방식을 사용하는 것은 팀원들의 동의를 얻는 것도 어려울 것 같다는 생각이 들었다.
 

---

 

🌱 SpEL 활용하기

그러던 중, 공식 문서에서 SpEL 이라는 친구를 발견하게 되었다. SpEL은 ‘런타임’에 객체 그래프를 쿼리하고 조작할 수 있는 강력한 표현식 언어로, @Value 어노테이션을 활용하여 런타임에 조작이 가능하다는 것이었다!
실제로 공식 문서를 보면, 다음과 같이 함께 사용할 수 있는 예제를 보여주고 있다.
 

Using @Value :: Spring Framework

 
 

@Component
class MovieRecommender(
    @Value("#{systemProperties['user.catalog'] + 'Catalog' }") private val catalog: String
)

위의 예제처럼 작성하고 싶은 표현식을 #{} 내부에 작성하게 되면, 내부적으로 컨버팅을 진행해준다.
 
적용 방법은 완전 쉬우니, 한 번 이전 코드에 적용을 해보자.
기존에 작성하였던 콜백 로직을 조금 더 적합한 이름의 클래스로 추출을 진행해주었다. 또한, 이제는 이 클래스 자체를 빈으로 등록하면 되기 때문에 다른 빈에 대해 주입도 받을 수 있어서 더 편리하게 사용이 가능해졌다.

@Component
class TopicConverter(
    private val environment: Environment,
    private val profile: String,
) {

    fun execute(property: String): String {
        // ... 기존의 로직 작성
        return original.plus(".$hostName")
    }
}

 

함수의 인자로는 변경을 원하는 프로퍼티의 키를, 함수의 반환 값으로는 컨버팅된 값을 반환하도록 만들어주었다.
그리고, 실제로 사용할 때는 다음과 같이 사용해주면 된다.

@Value("#{topicConverter.execute('very.important.topic')}")
topic: String,

더 이상 별도의 어노테이션도 필요하지 않고, 기존 @Value 내부에서 함수를 호출하는 것처럼 만들면 되기 때문에 사용성 역시 훨씬 편리해졌다! 또한, intellij 기능 덕분인지, 하이라이팅도 해주기 때문에 코드를 따라가기도 쉬워져서 더 마음에 들었다.

그래서 최종적으로는 위와 같이 기존 코드에 모두 적용을 완료하였으며, 덕분에 개인 branch 작업물에 대해 개발자마다 트래픽을 제어할 수 있도록 쉽게 핸들링이 가능해졌다.
 

---

🌱 마무리

꽤나 여러 가지로 삽질을 했었지만, 덕분에 공식 문서를 꼭 봐야겠다는 생각이 들었던 시간이었다. (사실, 처음에 @Value 어노테이션의 설명에서도 다음과 같이 나와있었기 때문에 제대로 읽지 않은 내 문제도 컸었다... ㅎㅎ

A common use case is to inject values using #{systemProperties. myProp} style SpEL (Spring Expression Language) expressions. Alternatively, values may be injected using ${my. app. myProp} style property placeholders.

 
처음에는 내가 직면한 문제를 spEL이랑 엮어봐야겠다는 생각조차 못했었다가 나중에 공식 문서 스터디를 진행하면서 spEL에 대한 정보를 알게 되고 그때 눈에 띄었던 것 같다. 사람들이 이래서 공식 문서를 읽으라고 하는 건가... 하면서 많이 배웠던 시간이었다.
 
사실 정말 이 방법이 올바른 방법이 되는지는 잘 모르겠다. 보통의 사람들이라면 테스트 코드로 잘 검증할 수 있는게 맞지 않나요? 라고 충분히 반박할 수도 있다고 생각이 든다.
 
아직까지는 E2E 테스트를 완전히 믿고 신뢰할 수 있을 만큼 내가 정교하게 작성하지 못한 탓도 큰 것 같다. 실제로 메인 비즈니스 로직에 대한 통합 테스트 코드는 작성이 되어 있으나, 해당 테스트 코드를 돌리고 항상 개발 앱 환경에서 다시 한 번 테스트를 돌려보는 내 모습을 바라보면서 아직은 많이 부족하다는 생각이 들었다. 개발에는 정답이 없는 것이니까... 우선은 현 자리에서 최대한 열심히 노력해봐야겠다. ㅎㅎ
 
 
아무튼, 오랜만에 글을 쓰다 보니 길어진 것 같다.
쓰고 싶은 글은 많은데 게으름으로 인해 글을 많이 못 쓰고 있는 것 같다… 종종 생각날 때 조금씩 써야겠다… 끝!