[TS] 민감 정보 관리를 위한 @SecureKey 커스텀 어노테이션 도입기

개요

📌 문제 배경

❗ 구조적 문제

• 설정 클래스가 외부 서비스(SKM)의 세부 구현에 직접 의

• SecureKeyManagerService를 사용하는 곳이 늘어나면서 결합도 증가

• 비즈니스 로직과 설정 로직이 뒤섞이며 유지보수 어려움

🛠️ 해결 방안: @SecureKey 커스텀 어노테이션 도입

"객체는 자신이 필요한 의존성을 직접 생성하거나 탐색하지 않고, 외부에서 주입받는다."

@Service
@RequiredArgsConstructor
public class EmailSendServiceImpl implements EmailSendService {

    @SecureKey("secret.keys.email.account")
    private String USERNAME;

    @SecureKey("secret.keys.email.password")
    private String PASSWORD;

    private final Session EMAIL_SESSION = createEmailSession();
}

🔧 어떻게 동작하는가?

1. @SecureKey 어노테이션 정의

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface SecureKey {
    String value();

2. BeanPostProcessor를 이용해 어노테이션 처리

@Component
public class SecureKeyInjector implements BeanPostProcessor {

    @Autowired
    private SecureKeyManagerService secureKeyManagerService;

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) {
        Field[] fields = bean.getClass().getDeclaredFields();
        for (Field field : fields) {
            if (field.isAnnotationPresent(SecureKey.class)) {
                SecureKey annotation = field.getAnnotation(SecureKey.class);
                String key = annotation.value();
                String value = secureKeyManagerService.fetchSecretFromKeyManager(key);

                field.setAccessible(true);
                try {
                    field.set(bean, value);
                } catch (IllegalAccessException e) {
                    throw new RuntimeException("Failed to inject secure key: " + key, e);
                }
            }
        }
        return bean;
    }
}

✅ 적용 결과

• 민감 정보 로딩 로직 제거 → 비즈니스 로직이 간결해짐

• SecureKeyManagerService 은닉 → 클래스 간 결합도 감소

• 설정과 비즈니스 로직의 완전한 분리 → 응집도 향상, 유지보수성 개선

• 어디서든 동일한 방식으로 민감 정보 사용 가능 → 일관성과 확장성 확보

💡 배운점