코드 땜장이

톰캣이 하는 일: 서블릿 컨테이너부터 요청 처리 흐름까지 이해하기 빠른 답 톰캣은 HTTP 요청을 받아 서블릿 코드로 연결하고 응답까지 돌려주는 자바 웹 실행 환경이다. 핵심 흐름은 요청 수신, URL 매핑, 필터 실행, 서블릿 호출, 응답 반환 순서로 이해하면 된다. 서블릿은 매 요청마다 새로 만들어지는 것이 아니라 컨테이너가 생명주기를 관리한다. 실무에서는 포트 설정, 스레드 풀, 배포 경로, 로그 확인 포인트를 함께 알아야 운영이 쉬워진다. 목차 흐름으로 보기 톰캣은 무엇이고 왜 자바 웹 개발에서 자주 등장할까 브라우저 요청이 톰캣 안에서 처리되는 전체 흐름 서블릿 생명주기와 톰캣이 객체를 관리하는 방식 바인딩, 검증, 직렬화는 어디서 일어날까 설정 포인트로 보는 톰캣 운영 감각 예외와 디버깅에서 먼저 볼 단서 톰캣을 이해하면 스프링도 더 잘 보인다 흐름으로 보기 톰캣을 이해할 때는 이 다섯 단계를 먼저 잡는 것이 가장 좋습니다. 브라우저나 API 클라이언트가 보낸 요청은 톰캣의 포트로 들어오고, 톰캣은 어떤 애플리케이션과 어떤 서블릿이 이 요청을 처리해야 하는지 찾습니다. 그다음 필터 같은 공통 처리 단계를 거쳐 실제 자바 코드가 실행되고, 최종 결과가 다시 HTTP 응답으로 나갑니다. 스프링 부트를 쓰더라도 이 흐름이 사라지는 것은 아닙니다. 눈앞에 보이는 코드가 @RestController 로 바뀔 뿐, 아래쪽에서는 여전히 톰캣이 요청을 받고 서블릿 체인으로 넘겨주는 구조가 유지됩니다. 톰캣은 무엇이고 왜 자바 웹 개발에서 자주 등장할까 톰캣은 흔히 WAS라고 부르지만, 실제로는 HTTP 서버 기능과 서블릿 컨테이너를 함께 제공하는 자바 웹 실행 환경이라고 보는 편이 더 정확합니다. 핵심 역할은 단순합니다. HTTP 요청을 읽고, 그 요청을 처리할 자바 웹 컴포넌트를 찾아 실행한 뒤, 결과를 다시 HTTP 응답으로 포장해 돌려보냅니다. 정적 파일만 내려주는 서버와 비교하면 차이가 분명해집니다. /logo.png 같은 요청은...

스프링 MVC에서 Filter와 Interceptor를 언제 어떻게 나눠 써야 할까 목차 왜 둘이 자꾸 헷갈릴까 요청이 들어왔을 때 실제로 어떤 순서로 실행될까 어떤 경우에 Filter를 써야 할까 어떤 경우에 Interceptor를 써야 할까 Spring Boot에서 함께 등록하는 방법 실전 코드로 보기: 로깅은 Filter, 핸들러 기반 인증은 Interceptor curl과 로그로 실행 순서를 검증하는 방법 자주 생기는 실수와 선택 기준 빠른 답 서블릿 단위 공통 처리라면 Filter, 컨트롤러 전후 제어라면 Interceptor가 먼저 후보입니다. 요청 본문/응답 자체를 직접 다뤄야 하면 Filter가 더 유연합니다. 핸들러 정보나 애노테이션 기반 분기가 필요하면 Interceptor가 더 적합합니다. 순서 문제와 중복 실행은 실제 장애로 이어지기 쉬우니 등록 위치와 실행 로그를 함께 확인해야 합니다. 빠른 답 서블릿 레벨에서 모든 요청과 응답을 공통 처리해야 하면 Filter , 컨트롤러 실행 전후를 제어해야 하면 Interceptor 가 먼저 후보입니다. 헤더, 인코딩, CORS, 요청 본문, 응답 감싸기처럼 HTTP 자체를 다뤄야 하면 Filter 가 더 맞습니다. 어떤 컨트롤러 메서드가 호출되는지, 특정 애노테이션이 붙었는지 보고 분기해야 하면 Interceptor 가 더 적합합니다. 스프링 시큐리티를 쓰는 프로젝트라면 인증과 인가의 중심은 보통 시큐리티 필터 체인에 두고, Filter 와 Interceptor 는 보조 역할로 좁히는 편이 안전합니다. 왜 둘이 자꾸 헷갈릴까 Filter 와 Interceptor 는 둘 다 "공통 로직을 한곳에 모아 넣는다"는 점에서 비슷합니다. 그래서 로깅, 인증, 권한 확인, 성능 측정 같은 요구가 나오면 둘 중 어디에 넣어도 될 것처럼 보입니다. 하지만 둘은 동작하는 계층이 다릅니다. Filter 는 서블릿 컨테이너 쪽에서 동작하고, Interceptor 는 스...