Spring 리드·아키텍트 프레임워크 면접

Spring Container 초기화 과정은 ApplicationContextInitializer(컨텍스트 초기화 전) → BeanFactoryPostProcessor(Bean 정의 메타데이터 수정) → BeanPostProcessor 등록 → Bean 인스턴스화 → BeanPostProcessor.postProcessBeforeInitialization → @PostConstruct/@InitializingBean → BeanPostProcessor.postProcessAfterInitialization 순으로 진행됩니다. BeanFactoryPostProcessor는 Bean 정의 자체를 수정할 수 있어 PropertyPlaceholderConfigurer 같은 설정 처리에 사용되며, BeanPostProcessor는 생성된 Bean 인스턴스를 가로채 프록시 생성이나 AOP 적용에 활용됩니다. @DependsOn은 명시적 순서 제어, @Lazy는 실제 사용 시점까지 초기화 지연에 사용하되, 순환 참조나 복잡한 초기화가 필요한 경우 SmartLifecycle 인터페이스를 활용해 phase 기반 순차 초기화를 구현하는 것이 효과적입니다. 대규모 시스템에서는 모듈별로 별도의 ApplicationContext를 구성하고 parent-child 관계로 관리하거나, Spring Boot의 AutoConfiguration 순서 제어(@AutoConfigureBefore, @AutoConfigureAfter)를 활용해 초기화 복잡도를 낮추는 전략을 권장합니다.

JDK Dynamic Proxy는 인터페이스 기반으로 java.lang.reflect.Proxy를 사용해 런타임에 프록시 클래스를 생성하며, InvocationHandler를 통해 메서드 호출을 가로챕니다. CGLIB은 바이트코드 조작으로 타겟 클래스를 상속한 서브클래스를 생성하므로 인터페이스 없이도 동작하지만 final 클래스나 메서드에는 적용 불가하며, 생성 비용이 더 높지만 메서드 호출 성능은 JDK Proxy보다 우수합니다. self-invocation 문제는 프록시를 거치지 않고 내부 메서드를 직접 호출(this.method())할 때 발생하며, AopContext.currentProxy()로 현재 프록시를 가져오거나 self-injection, AspectJ 컴파일 타임 위빙으로 해결 가능합니다. 대규모 환경에서는 @Transactional이나 @Cacheable 같은 선언적 AOP는 유지하되, 성능에 민감한 핫패스에는 프로그래매틱 방식을 사용하고, 프록시 생성 비용을 줄이기 위해 prototype 스코프 Bean은 최소화하며, 필요시 ProxyFactoryBean의 캐싱 전략을 최적화하는 것이 효과적입니다.

REQUIRES_NEW는 기존 트랜잭션을 일시 중단하고 완전히 독립적인 새 물리 트랜잭션을 시작하므로, 외부 트랜잭션 롤백이 내부에 영향을 주지 않으며 감사 로그나 알림 발송처럼 메인 로직 실패와 무관하게 커밋되어야 하는 경우 적합합니다. NESTED는 JDBC 세이브포인트를 사용해 중첩 트랜잭션을 구현하므로 내부 트랜잭션 롤백 시 세이브포인트까지만 롤백되지만 외부 롤백 시 전체가 롤백되며, 부분 실패 허용이 필요한 배치 처리나 선택적 부가 기능 실행에 유용하나 모든 DB가 세이브포인트를 지원하지는 않습니다. 격리 수준은 READ_COMMITTED를 기본으로 하고 필요한 경우에만 REPEATABLE_READ나 SERIALIZABLE을 선택적으로 적용하되, 트랜잭션 범위를 최소화하고 락 대기 시간을 모니터링해야 합니다. 데드락 예방을 위해 테이블 접근 순서를 일관되게 유지하고, 긴 트랜잭션은 비동기 처리나 이벤트 기반 아키텍처로 분리하며, Spring Actuator와 APM 도구로 트랜잭션 지속 시간과 락 경합을 실시간 추적하는 것이 중요합니다.