옥스턴님의 면접 결과

Filter와 Interceptor의 기본적인 차이점과 실행 위치에 대해 잘 설명해주셨고, 실무에서의 활용 예시도 적절하게 제시해주셨습니다. 다만 몇 가지 보완이 필요한 부분이 있는데, 먼저 Interceptor도 postHandle과 afterCompletion을 통해 응답 처리 시점에도 동작할 수 있다는 점을 알아두시면 좋겠습니다. 또한 Filter에서도 DelegatingFilterProxy나 @Component를 통해 스프링 빈 주입이 가능하므로, 이 부분에 대한 정확한 이해가 필요할 것 같습니다. 추가로 Filter는 서블릿 스펙의 일부이고 Interceptor는 Spring MVC의 기능이라는 점, 그리고 실행 순서(Filter → DispatcherServlet → Interceptor → Controller)에 대해서도 학습해보시길 권합니다.

설계적 관점에서 Filter에서 데이터베이스 접근을 피해야 한다는 인식을 가지고 계신 점은 매우 좋습니다. 하지만 실제로는 Filter에서도 스프링 빈 주입이 가능한 방법들이 존재합니다. @Component를 사용하여 Filter를 스프링 빈으로 등록하거나, DelegatingFilterProxy를 활용하면 스프링 컨텍스트 내에서 Filter가 동작하여 의존성 주입을 받을 수 있습니다. 또한 ApplicationContext.getBean()을 통해 수동으로 빈을 가져오는 방법도 있어서, 기술적으로 불가능한 것은 아닙니다. 스프링 Filter의 빈 등록 방법과 DelegatingFilterProxy의 동작 원리에 대해 추가로 학습해보시면 도움이 될 것 같습니다.

좋은 답변이었습니다. 특히 DataSource 설정과 스프링 컨텍스트의 관계를 잘 이해하고 계시고, 보안 관점에서 DB 연결 정보가 분리되어 관리되어야 한다는 점을 언급한 것이 매우 좋았습니다. 다만 한 가지 정정할 부분이 있는데, 실제로는 Filter에서도 스프링 빈을 주입받을 수 있는 방법들이 존재합니다(DelegatingFilterProxy, @Component 등을 활용). 추가로 아키텍처 관점에서 Filter는 웹 레이어의 기술적 관심사(로깅, 인코딩 등)를, Interceptor는 비즈니스적 관심사(인증, 권한 등)를 처리하는 것이 적절하다는 관점을 더 학습하시면 설계 원칙에 대한 이해가 더욱 깊어질 것 같습니다.