Spring

JPA는 표준 API이고, Spring Data JPA는 그 위에 얹힌 코드 생성 계층이다. 인터페이스만 선언하면 구현을 만들어 주고, 그 구현이 내부에서 EntityManager를 호출한다. 같은 동작을 두 방식으로 작성하면 경계가 드러난다. JPA JPA의 중심은 영속성 컨텍스트와 그것을 다루는 EntityManager다. 영속성 컨텍스트는 엔티티를 보관하는 논리적 공간으로 1차 캐시, 변경 감지(Dirty Checking), 지연 로딩, 쓰기 지연을 제공한다. 순수 JPA에서는 EntityManager를 직접 잡고 트랜잭션도 직접 열고 닫는다. EntityManager em = emf.createEntityManager(); EntityTransaction tx = em.getTransaction(); tx.begin(); User user = new User("홍길동", "[email protected]"); em.persist(user); // 영속 상태로 전환 → INSERT 예약 User found = em.find(User.class, user.getId()); // 1차 캐시에서 반환 (추가 쿼리 없음) found.setName("김철수"); // 변경 감지 → flush 시 자동 UPDATE tx.commit(); // 예약된 SQL 실행 em.close(); 동작은 하지만, 모든 엔티티의 모든 CRUD마다 createEntityManager, getTransaction, begin, commit, close가 반복된다. Spring Data JPA가 제거하는 것이 이 반복이다. ...

인터셉터가 필터와 다른 점은 위치다. 인터셉터는 DispatcherServlet 안에서, 핸들러 매핑이 어느 컨트롤러가 요청을 처리할지 결정한 뒤에 실행된다. 따라서 인터셉터는 어떤 핸들러가 곧 실행될지 이미 안다. 그 실행을 컨트롤러 호출 전, 호출 후, 뷰 렌더링 후 세 지점에서 가로채고, 첫 지점에서는 요청 자체를 막을 수 있다. 세 개의 훅 HandlerInterceptor는 가로채는 시점이 다른 세 메서드를 제공한다. preHandle preHandle은 컨트롤러 실행 전에 호출되고 boolean을 반환한다. true면 다음 인터셉터나 컨트롤러로 진행하고, false면 요청 처리가 즉시 중단되어 컨트롤러는 실행되지 않는다. 인증 확인, 권한 검증, 호출 횟수 제한 같은 게이트키퍼 역할에 맞는 이유다. ...

필터는 요청이 들어왔을 때 가장 먼저 손대는 자리다. DispatcherServlet도, 컨트롤러도, 스프링 빈도 아직 없다. 서블릿 컨테이너(Tomcat 등) 레벨에서 동작하기 때문이다. 이 위치가 필터의 성격을 결정하고, CORS 처리와 보안 토큰 검증이 인터셉터가 아니라 필터에 사는 이유를 설명한다. 서블릿(Servlet) 클라이언트의 HTTP 요청을 처리하고 응답을 생성하는 자바 서버 측 컴포넌트. Java EE(현 Jakarta EE) 표준의 핵심이며 대부분의 자바 웹 프레임워크의 기반이다. 필터가 잡는 범위 필터의 적용 범위는 모든 요청이다. 컨트롤러로 가는 요청만이 아니라 정적 리소스 요청도, 잘못된 경로로 들어와 에러로 빠지는 요청도 전부 필터를 통과한다. DispatcherServlet 앞단에 있기 때문이다. 예외 없이 모든 요청에 한 번은 적용해야 하는 일이 필터의 영역이다. 문자 인코딩 통일, CORS 헤더, 보안 토큰 검증, 응답 압축, 요청/응답 로깅이 여기 해당한다. ...