낙낙님의 면접 결과

스프링 MVC에서 요청이 들어오면, 서블릿 컨테이너 중 어떤 서블릿이 해당 요청을 처리할 수 있는지 확인합니다. 스프링 부트에서는 기본적으로 디스패쳐 서블릿이 맨 앞단에서 모든 요청을 먼저 받고, 이를 실제로 처리할 수 있는 핸들러에게 전달하는 프론트 컨트롤러 패턴을 사용합니다. 그런데 이 디스패쳐 서블릿에 도달하기 전에 먼저 필터를 거치게 됩니다. 디스패쳐 서블릿에게 요청이 넘어가기 전에 처리해야할 일들(XSS 공격 방어, 요청 로깅을 위한 캐싱, 인증 작업 등)을 수행하고 나서 이 요청을 디스패처 서블릿에게 전달합니다. 디스패처 서블릿이 클라이언트로 응답할 때에도, 후처리를 위해 필터를 거치게 됩니다. 필터가 여러개인 경우에는 체이닝 방식으로 동작합니다. 이 후 url과 HTTP method를 보고 어떤 컨트롤러의 메소드, 즉 어떤 핸들러가 처리할 수 있는지 찾는데 이 때 어댑터 패턴을 통해 핸들러 어댑터를 찾습니다. 여기서 어댑터 패턴을 사용하는 이유는 컨트롤러를 구현하는 방식이 1가지가 아니기 때문에 이를 어댑터로 감싸서 통일된 인터페이스로 다루기 위함입니다. 현재는 어노테이션 기반의 컨트롤러를 주로 사용하지만, 과거에는 인터페이스를 구현하는 방식의 컨트롤러를 사용했기 때문에 두가지 방식 모두 하나의 인터페이스로 처리하기 위해 사용하는 것입니다. 이후 해당 핸들러를 처리하기 전 인터셉터가 동작합니다. 핸들러에게 도달하기 전에 수행할 일, 핸들러가 요청을 처리한 뒤 수행할 일들을 정의합니다. 이후 컨트롤러를 지나 서비스, 리포지토리 등을 거치며 비즈니스 로직이 수행되고, 이 응답이 사용자에게 전달됩니다.

필터와 인터셉터는 비슷하게 동작하지만 차이점이 있습니다. 필터는 디스패처 서블릿 외부에서 동작하고, 인터셉터는 디스패처 서블릿 내부에서 동작합니다. 필터는 요청/응답에 대한 수정이 가능합니다. 하지만 인터셉터는 불가능합니다. 필터에서 발생하는 예외는 디스패처 서블릿 밖에서 발생하기 때문에 컨트롤러 어드바이스의 @ExceptionHandler로 처리할 수 없어 직접 처리해야 하지만, 인터셉터에서 발생하는 예외는 @ExceptionHandler로 처리가 가능합니다. 필터는 일반적으로 디스패처 서블릿에 도달하기 전에 동작하고, 기본 설정이 전역에서 동작하기 때문에 전역에서 공통으로 가지는 관심사에 대한 처리를 하는데 주로 사용할 수 있습니다. 가령 모든 요청/응답에 대한 로깅, 모든 요청에 대한 XSS 방어, 요청에 대한 인증 작업 등을 할 수 있습니다. 물론 요청에 대한 인증 작업은 모든 요청에 대한 것은 아니지만, 인터셉터보다는 필터를 통해 인증 처리를 하는 것이 안전합니다. 기본적으로 필터는 전역 적용이고, 인터셉터는 적용할 대상을 직접 고르는 방식으로 동작합니다. 인터셉터는 인증을 적용할 대상에 대해 경로 패턴을 통해 적용하는데, 이 경로가 불일치 될 수 있어 보안과 관련된 작업으로 추천하지 않는다는 공식 문서의 내용도 있습니다. 또한 빠른 실패 관점에서도 디스패처 서블릿에 도달하기 전, 필터에서 먼저 거르는 것이 좋습니다. 인터셉터는 전역의 관심사보다는 특정 관심사를 처리할 때 주로 사용합니다. 특정 경로에 대해서만 실행 시간을 구체적으로 측정하고 싶다거나, 로깅을 좀 더 상세하게 해야한다거나 하는 경우에 사용할 수 있을 것 같습니다.

필터는 체이닝 방식으로, 기본적으로 모든 요청에 대해 필터를 거치게 됩니다. 특정 요청의 경우에만 필터를 거치지 않게 할 수 있는 설정도 제공합니다. @Component를 붙이고 Filter를 구현하기만 하면 자동으로 등록이 됩니다. 인터셉터는 어떤 경로 패턴에 적용시킬지 결정하고, 해당 패턴이 일치하는 경우에만 인터셉터를 거치게 됩니다. WebMvcConfigurer를 통해 수동으로 등록합니다. 성능적으로는 특정 요청을 블록해야 하는 경우 빠른 실패 관점에서 디스패처 서블릿에 도달하기 전에 필터에서 먼저 처리되므로, 응답 시간도 빨라지고 이에 따라 커넥션과 톰캣 스레드를 점유하는 시간도 짧아져 더 성능이 좋을 것이라 생각됩니다. 일반적인 처리 방식에서는 필터와 인터셉터의 성능 차이를 정확하게 모르겠습니다. 필터와 인터셉터는 웹 계층에 대해서만 처리하지만, 이외의 공통 관심사를 처리하고 싶은 경우 AOP를 사용할 수 있습니다. 가령 @Transactional 이 AOP를 통해 구현되었는데, 트랜잭션 관리(롤백, 커밋, 격리수준, 전파옵션 등)라는 횡단 관심사를 AOP를 통해 서비스의 비즈니스 코드에서 분리해줍니다. 앞에서 이야기한 특정 메소드의 실행 시간 추적, 비즈니스 메트릭 등록 등 웹 계층을 너머 다른 계층에서 횡단 관심사를 처리할 때 AOP를 사용할 수 있습니다. 스프링 AOP는 프록시 기반으로 동작하고, 프록시 빈이 대신 주입되어야 하기 때문에 빈으로 등록할 수 없는 경우에 대해서는 스프링 AOP를 적용할 수 없습니다. 이 경우에는 AspectJ를 통해 바이트 코드를 직접 조작하여 횡단 관심사를 처리할 수 있습니다.