Java 시니어 프레임워크 기술면접
새 면접Q. Spring Container에서 Bean의 생명주기를 관리하는 전체 과정을 설명하고, BeanPostProcessor와 BeanFactoryPostProcessor의 차이점 및 실행 순서를 설명해주세요. 또한 @PostConstruct, InitializingBean, init-method의 실행 순서와 각각을 선택하는 기준은 무엇인가요?
Spring Bean 생명주기는 1) Bean 정의 로딩 → 2) BeanFactoryPostProcessor 실행(Bean 정의 수정) → 3) Bean 인스턴스화 → 4) 의존성 주입 → 5) BeanPostProcessor.postProcessBeforeInitialization → 6) @PostConstruct → 7) InitializingBean.afterPropertiesSet → 8) init-method → 9) BeanPostProcessor.postProcessAfterInitialization 순으로 진행됩니다. BeanFactoryPostProcessor는 Bean 정의 메타데이터를 수정하고, BeanPostProcessor는 Bean 인스턴스를 수정합니다. @PostConstruct는 JSR-250 표준으로 가장 먼저 실행되며 간단한 초기화에 적합하고, InitializingBean은 Spring 의존적이지만 타입 안전성이 보장되며, init-method는 Spring 비의존적이지만 리플렉션 오버헤드가 있어 외부 라이브러리 통합 시 유용합니다.
- • BeanFactoryPostProcessor는 Bean 정의 수정, BeanPostProcessor는 Bean 인스턴스 수정
- • 초기화 순서: @PostConstruct → InitializingBean → init-method
- • 각 방식의 장단점: 표준 준수, 타입 안전성, 프레임워크 의존성 차이
여러 BeanPostProcessor가 등록되어 있을 때 실행 순서를 제어하려면 어떻게 해야 하며, @Order 어노테이션과 Ordered 인터페이스의 차이점은 무엇인가요?
Q. Spring Security의 FilterChainProxy와 SecurityFilterChain의 동작 원리를 설명하고, JWT 인증을 구현할 때 OncePerRequestFilter를 상속받아 커스텀 필터를 만드는 이유는 무엇인가요? 또한 필터 체인에서 예외 처리가 ControllerAdvice로 전달되지 않는 이유와 해결 방법을 설명해주세요.
FilterChainProxy는 Spring Security의 진입점으로 여러 SecurityFilterChain을 관리하며, 요청 URL 패턴에 따라 적절한 필터 체인을 선택합니다. OncePerRequestFilter는 같은 요청에 대해 필터가 중복 실행되는 것을 방지하며, 특히 forward나 include 시에도 한 번만 실행되도록 보장합니다. Security 필터는 DispatcherServlet 이전에 실행되므로 발생한 예외가 ControllerAdvice로 전달되지 않습니다. 해결 방법은 1) 필터 내에서 HandlerExceptionResolver를 주입받아 직접 예외 처리하거나, 2) AuthenticationEntryPoint와 AccessDeniedHandler를 구현하여 인증/인가 예외를 처리하거나, 3) 커스텀 ErrorController를 구현하는 방법이 있습니다.
- • FilterChainProxy는 여러 SecurityFilterChain을 URL 패턴에 따라 관리
- • OncePerRequestFilter는 요청당 한 번만 실행되도록 보장
- • Security 필터는 DispatcherServlet 이전 실행으로 ControllerAdvice 미적용
Stateless JWT 인증 환경에서 SecurityContextHolder의 저장 전략(MODE_THREADLOCAL, MODE_INHERITABLETHREADLOCAL, MODE_GLOBAL)을 어떻게 선택해야 하며, 비동기 처리 시 SecurityContext가 전파되지 않는 문제는 어떻게 해결하나요?
Q. Hibernate의 1차 캐시(Session Level)와 2차 캐시(SessionFactory Level)의 동작 원리와 차이점을 설명하고, 2차 캐시 사용 시 발생할 수 있는 캐시 일관성 문제와 캐시 동시성 전략(READ_ONLY, NONSTRICT_READ_WRITE, READ_WRITE, TRANSACTIONAL)의 적용 시나리오를 설명해주세요.
1차 캐시는 Session(EntityManager) 범위에서 자동으로 활성화되며 동일 트랜잭션 내에서 같은 엔티티의 중복 조회를 방지하고 변경 감지(Dirty Checking)를 지원합니다. 2차 캐시는 SessionFactory 범위로 애플리케이션 전체에서 공유되며 명시적 설정이 필요하고 주로 읽기 빈도가 높고 변경이 적은 데이터에 적합합니다. READ_ONLY는 불변 데이터에 적합하며 가장 빠르고, NONSTRICT_READ_WRITE는 약한 일관성을 허용하며 성능이 좋고, READ_WRITE는 read-committed 수준의 격리를 보장하며 락을 사용하고, TRANSACTIONAL은 JTA 환경에서 완전한 트랜잭션 격리를 제공하지만 가장 느립니다. 분산 환경에서는 Ehcache나 Redis 같은 캐시 제공자와 함께 캐시 무효화 전략을 신중히 설계해야 합니다.
- • 1차 캐시는 Session 범위 자동 활성화, 2차 캐시는 SessionFactory 범위 명시적 설정
- • 2차 캐시는 읽기 빈도 높고 변경 적은 데이터에 적합
- • 동시성 전략은 데이터 특성과 일관성 요구사항에 따라 선택
대규모 서비스에서 여러 애플리케이션 인스턴스가 Hibernate 2차 캐시를 공유할 때, 한 인스턴스에서 엔티티를 수정하면 다른 인스턴스의 캐시를 어떻게 무효화시킬 수 있으며, 이벤트 기반 캐시 무효화 전략의 장단점은 무엇인가요?
Q. Spring Batch의 Chunk-oriented Processing에서 Reader, Processor, Writer의 트랜잭션 경계와 실행 흐름을 설명하고, 대용량 데이터 처리 시 Skip, Retry, Restart 정책을 어떻게 설계해야 하는지 설명해주세요. 또한 Partitioning과 Multi-threaded Step의 차이점과 적용 시나리오를 비교해주세요.
Chunk-oriented Processing은 Reader에서 chunk-size만큼 아이템을 읽고, Processor에서 각 아이템을 처리한 후, Writer에서 한 번에 쓰는 방식으로 동작하며, 트랜잭션은 chunk 단위로 커밋됩니다. Skip은 특정 예외 발생 시 해당 아이템만 건너뛰고, Retry는 일시적 오류에 대해 재시도하며, Restart는 실패한 Job을 중단 지점부터 재실행합니다. Skip과 Retry는 예외 타입별로 세밀하게 설정하고 최대 횟수를 제한해야 합니다. Partitioning은 데이터를 논리적으로 분할하여 여러 Step을 병렬 실행하며 주로 분산 환경에 적합하고, Multi-threaded Step은 단일 Step 내에서 chunk를 여러 스레드로 병렬 처리하며 단일 JVM 내 성능 향상에 적합합니다.
- • Chunk 단위로 Read-Process-Write 수행 후 트랜잭션 커밋
- • Skip/Retry/Restart 정책은 예외 타입과 비즈니스 요구사항에 따라 설계
- • Partitioning은 분산 처리, Multi-threaded는 단일 JVM 병렬 처리
Spring Batch에서 ItemReader가 thread-safe하지 않을 때 Multi-threaded Step을 사용하면 어떤 문제가 발생하며, 이를 해결하기 위한 SynchronizedItemStreamReader의 동작 원리와 성능 트레이드오프는 무엇인가요?
Q. MSA 환경에서 Spring Cloud Circuit Breaker(Resilience4j)의 동작 원리를 설명하고, Circuit Breaker의 세 가지 상태(CLOSED, OPEN, HALF_OPEN) 전환 조건과 각 상태에서의 동작 방식을 설명해주세요. 또한 Bulkhead 패턴과 Rate Limiter의 차이점 및 함께 사용할 때의 시너지 효과를 설명해주세요.
Circuit Breaker는 외부 서비스 호출 실패를 감지하여 연쇄 장애를 방지하는 패턴입니다. CLOSED 상태에서는 정상적으로 요청을 전달하며 실패율을 모니터링하고, 실패율이 임계값을 초과하면 OPEN 상태로 전환되어 즉시 fallback을 반환하고 외부 호출을 차단합니다. 일정 시간 후 HALF_OPEN 상태로 전환되어 제한된 수의 요청을 허용하고 성공률에 따라 CLOSED 또는 OPEN으로 전환됩니다. Bulkhead는 서비스별로 스레드 풀이나 세마포어를 격리하여 한 서비스의 장애가 다른 서비스에 영향을 주지 않도록 하고, Rate Limiter는 단위 시간당 요청 수를 제한합니다. 함께 사용하면 외부 장애 전파 방지(Circuit Breaker), 리소스 격리(Bulkhead), 과부하 방지(Rate Limiter)를 모두 달성할 수 있습니다.
- • Circuit Breaker는 CLOSED→OPEN→HALF_OPEN 상태로 전환되며 실패율 기반 동작
- • Bulkhead는 리소스 격리, Rate Limiter는 요청 수 제한
- • 세 패턴 조합으로 장애 전파 방지, 리소스 격리, 과부하 방지 달성
Time Limiter와 Retry를 Circuit Breaker와 함께 사용할 때 적절한 타임아웃 값과 재시도 횟수를 결정하는 기준은 무엇이며, Retry와 Circuit Breaker의 실행 순서가 성능과 안정성에 미치는 영향을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!