서블릿 API

서블릿 API의 핵심은 서블릿 인터페이스이다. 이 인터페이스는 모든 서블릿 클래스가 구현해야 하는 기본 규약을 정의한다. 서블릿 인터페이스는 javax.servlet 패키지에 포함되어 있으며, 서블릿의 생명주기 메서드인 init(), service(), destroy()를 포함하고 있다. 웹 컨테이너는 이 인터페이스를 통해 서블릿 인스턴스를 생성하고 관리하며, 클라이언트의 요청을 적절한 서블릿으로 라우팅한다.

개발자는 일반적으로 서블릿 인터페이스를 직접 구현하기보다는 이를 확장한 추상 클래스를 사용한다. 가장 대표적인 클래스는 javax.servlet.http.HttpServlet이다. 이 클래스는 HTTP 프로토콜에 특화되어 있으며, GET, POST와 같은 HTTP 메서드에 따라 doGet(), doPost() 등의 메서드를 오버라이드하여 비즈니스 로직을 구현하는 방식으로 사용된다. 이를 통해 개발자는 네트워크 통신이나 프로토콜 파싱과 같은 저수준 작업보다 애플리케이션 로직 자체에 집중할 수 있다.

서블릿 인터페이스는 자바의 객체지향 특성을 활용하여 웹 애플리케이션 개발을 표준화했다. 이 인터페이스를 기준으로 다양한 웹 서버와 애플리케이션 서버가 호환되는 서블릿 컨테이너를 제공하게 되었으며, 이는 자바 기반 웹 개발 생태계의 확장성과 이식성의 기반이 되었다. 서블릿 인터페이스의 존재 덕분에, 서블릿으로 작성된 코드는 톰캣, 제티, 웹로직 등 서로 다른 벤더의 서블릿 컨테이너에서도 대부분 변경 없이 실행될 수 있다.

서블릿 컨테이너는 서블릿의 생명주기를 관리하고, 클라이언트의 요청을 서블릿에 전달하며, 서블릿이 생성한 응답을 클라이언트에게 반환하는 역할을 한다. 이 컨테이너는 웹 서버와 서블릿 사이의 중간 계층으로 작동하여, 서블릿이 네트워크 통신이나 프로토콜 처리와 같은 저수준 작업에 직접 관여하지 않고 비즈니스 로직에 집중할 수 있게 해준다. 서블릿 컨테이너는 자바 가상 머신 위에서 실행되며, 자바 플랫폼, 엔터프라이즈 에디션 스펙의 일부로 정의된다.

서블릿 컨테이너의 핵심 기능은 서블릿의 로딩, 초기화, 실행, 소멸을 제어하는 생명주기 관리다. 클라이언트로부터 HTTP 요청이 들어오면, 컨테이너는 해당 요청을 처리할 적절한 서블릿 인스턴스를 찾거나 생성하여 요청과 응답 객체를 전달한다. 또한, 세션 관리, 보안, 동시성 제어와 같은 웹 애플리케이션 운영에 필요한 공통 서비스를 제공한다.

대표적인 서블릿 컨테이너 구현체로는 아파치 톰캣, 이클립스 제티, 레드햇의 와일드플라이에 포함된 언더토우 등이 있다. 이러한 컨테이너는 독립 실행형 서버로 사용되거나, 아파치 HTTP 서버와 같은 웹 서버와 연동하여 사용될 수 있다. 서블릿 컨테이너는 자바 서버 페이지 기술의 기반이 되며, 이를 통해 동적인 웹 페이지를 효율적으로 생성할 수 있다.

HTTP 서블릿은 서블릿 API의 핵심 구성 요소 중 하나로, HTTP 프로토콜을 통해 클라이언트의 요청을 처리하고 응답을 생성하는 데 특화된 서블릿이다. 일반적으로 웹 애플리케이션을 개발할 때 사용하는 서블릿은 대부분 이 HTTP 서블릿을 상속받아 구현한다. 이는 서블릿 인터페이스를 직접 구현하는 것보다 편리하게 GET과 POST 같은 HTTP 메서드를 처리할 수 있도록 설계되었다.

HTTP 서블릿은 javax.servlet.http.HttpServlet 클래스를 통해 제공된다. 이 클래스는 service() 메서드를 오버라이드하여 들어오는 HTTP 요청의 메서드 타입을 분석하고, 해당하는 doGet(), doPost(), doPut(), doDelete() 등의 메서드를 자동으로 호출한다. 따라서 개발자는 특정 HTTP 메서드에 대한 비즈니스 로직만을 해당 메서드에 구현하면 된다. 이는 웹 서버 측 프로그램의 구조를 명확하게 만들어 준다.

HTTP 서블릿은 HttpServletRequest와 HttpServletResponse 객체를 매개변수로 받아 작업을 수행한다. HttpServletRequest 객체는 클라이언트가 전송한 요청 파라미터, 헤더 정보, 쿠키, 세션 정보 등을 조회하는 기능을 제공한다. 반면 HttpServletResponse 객체는 응답 상태 코드 설정, 응답 헤더 추가, 그리고 최종적으로 HTML이나 JSON 같은 콘텐츠를 클라이언트에게 출력하는 기능을 담당한다.

이러한 HTTP 서블릿의 구조는 MVC 패턴에서 컨트롤러의 역할을 수행하는 기반이 된다. 사용자의 요청을 받아 적절한 모델(JavaBeans 또는 EJB)과 상호작용하고, 그 결과를 뷰(JSP)에 전달하는 흐름을 구성할 수 있다. 현대의 많은 자바 기반 웹 프레임워크들은 내부적으로 이 HTTP 서블릿 메커니즘을 기반으로 동작하고 있다.

서블릿 API에서 클라이언트의 요청을 처리하고 결과를 반환하는 핵심적인 역할은 요청과 응답 객체가 담당한다. 이 객체들은 서블릿의 service 메서드가 호출될 때 서블릿 컨테이너에 의해 생성되어 서블릿에 전달된다. 개발자는 이 객체들을 통해 사용자가 보낸 데이터를 읽고, 처리한 결과를 사용자에게 다시 전송할 수 있다.

요청을 나타내는 HttpServletRequest 객체는 클라이언트로부터 전송된 모든 정보를 캡슐화한다. 여기에는 HTTP 요청 헤더, 쿼리 문자열 또는 폼 데이터 형태의 파라미터, 클라이언트의 IP 주소 정보 등이 포함된다. 또한, 이 객체는 세션 관리와 관련된 getSession 메서드, 요청 속성을 설정하고 가져오는 기능을 제공하여 요청 처리 과정에서 데이터를 공유할 수 있게 한다.

반면, 응답을 구성하는 HttpServletResponse 객체는 서블릿이 클라이언트에게 보낼 응답을 조작하는 데 사용된다. 이 객체를 통해 개발자는 HTTP 상태 코드를 설정하거나, Content-Type과 같은 응답 헤더를 추가하며, 최종적으로 출력 스트림(getWriter 또는 getOutputStream)을 얻어 HTML, JSON, XML 등의 실제 응답 데이터를 작성한다. 서블릿은 이 스트림에 데이터를 기록함으로써 동적인 웹 페이지나 API 응답을 생성한다.

이 두 객체는 서블릿 프로그래밍의 기본이 되며, MVC 패턴에서 컨트롤러 계층이 모델과 상호작용하기 위한 주요 통로 역할을 한다. 요청 객체로부터 입력을 받아 비즈니스 로직을 처리한 후, 그 결과를 응답 객체를 통해 클라이언트에게 반환하는 흐름은 모든 서블릿 기반 웹 애플리케이션의 근간을 이룬다.

세션 관리는 웹 애플리케이션이 사용자의 여러 HTTP 요청에 걸쳐 상태 정보를 유지할 수 있게 해주는 서블릿 API의 핵심 기능이다. 기본적으로 HTTP는 상태를 유지하지 않는 프로토콜이기 때문에, 서버는 각 요청을 독립적으로 처리하며 이전 요청과의 관계를 알 수 없다. 세션 관리는 이러한 한계를 극복하여, 사용자가 로그인 상태를 유지하거나 쇼핑 카트에 상품을 담는 것과 같은 연속적인 상호작용을 가능하게 한다.

세션 관리는 일반적으로 쿠키나 URL 재작성을 통해 구현된다. 가장 일반적인 방식은 서버가 세션을 생성할 때 고유한 세션 ID를 발급하고, 이 ID를 사용자의 브라우저에 쿠키로 저장하는 것이다. 이후 사용자가 요청을 보낼 때마다 브라우저는 이 쿠키를 함께 전송하고, 서버는 전달받은 세션 ID를 통해 해당 사용자의 세션을 식별하여 연결된 데이터에 접근한다. 쿠키를 사용할 수 없는 환경에서는 URL에 세션 ID를 포함시키는 URL 재작성 방식을 사용하기도 한다.

서블릿 API에서는 HttpServletRequest 객체의 getSession() 메서드를 호출하여 현재 요청과 관련된 HttpSession 객체를 얻을 수 있다. 이 HttpSession 객체는 setAttribute(), getAttribute(), removeAttribute()와 같은 메서드를 제공하여, 세션 범위 내에서 데이터를 저장, 조회, 삭제하는 기능을 담당한다. 서버는 일정 시간 동안 활동이 없는 세션을 자동으로 만료시켜 메모리 자원을 관리한다.

이러한 세션 관리 메커니즘은 웹 보안과 밀접한 관련이 있다. 세션 ID가 탈취당하면 공격자가 사용자의 세션을 하이재킹할 수 있기 때문에, HTTPS를 통한 통신 암호화, 세션 타임아웃 시간 적절히 설정, 세션 ID의 안전한 생성과 전송 등이 중요하게 고려된다.

서블릿 API의 필터는 서블릿이나 자바 서버 페이지(JSP)와 같은 웹 자원에 대한 요청과 응답을 가로채어 전처리 또는 후처리 작업을 수행하는 객체이다. 필터는 웹 애플리케이션의 여러 서블릿에 걸쳐 공통적으로 적용해야 하는 기능을 모듈화하는 데 사용된다. 예를 들어, 사용자 인증, 로깅, 데이터 인코딩 변환, 입력 유효성 검사 등의 작업을 필터를 통해 효율적으로 구현할 수 있다.

필터는 javax.servlet.Filter 인터페이스를 구현하여 생성하며, init(), doFilter(), destroy() 메서드를 정의한다. 이 중 핵심은 doFilter() 메서드로, 서블릿 컨테이너가 요청을 가로챌 때마다 호출된다. 이 메서드 내에서는 요청과 응답 객체를 조작하거나, 체인의 다음 필터로 요청을 전달하거나, 요청 처리를 중단할 수 있다. 필터는 배포 설명자(web.xml) 파일에 선언하거나, 애너테이션을 사용하여 특정 URL 패턴이나 서블릿 이름에 매핑된다.

여러 필터는 필터 체인을 구성하여 순차적으로 실행될 수 있다. 이는 파이프라인 패턴을 따르며, 각 필터는 체인의 다음 구성 요소에 제어를 넘기기 전에 자신의 작업을 수행한다. 이를 통해 인가 후 로깅을 하거나, 요청 압축 후 응답 암호화를 하는 등 복잡한 처리 흐름을 모듈별로 분리하여 관리할 수 있다. 필터는 서블릿의 비즈니스 로직과는 독립적으로 교차 관심사를 처리하므로, 관심사의 분리 원칙을 실현하고 코드의 재사용성을 높이는 데 기여한다.

리스너는 서블릿 API에서 특정 이벤트의 발생을 감지하고 그에 대한 처리를 수행하는 객체이다. 이벤트는 주로 웹 애플리케이션의 생명주기나 세션의 상태 변화, HTTP 요청의 속성 변경과 관련된다. 리스너는 특정 이벤트에 대한 인터페이스를 구현하여 작성하며, 서블릿 컨테이너가 해당 이벤트가 발생했을 때 리스너의 메서드를 자동으로 호출한다. 이를 통해 개발자는 애플리케이션의 주요 상태 변화 시점에 원하는 로직을 삽입할 수 있다.

리스너는 크게 세 가지 범주로 구분된다. 첫째는 서블릿 컨텍스트의 생성과 소멸, 속성 변경을 감지하는 서블릿 컨텍스트 리스너이다. 둘째는 HTTP 세션의 생성과 소멸, 속성 변경, 활성화/비활성화 상태 변화를 감지하는 세션 리스너이다. 셋째는 서블릿 요청 객체의 생성과 소멸, 속성 변경을 감지하는 서블릿 요청 리스너이다. 각 범주 내에는 다시 이벤트 유형에 따라 세부적인 인터페이스가 정의되어 있다.

리스너의 주요 활용 사례로는 애플리케이션 시작 시 데이터베이스 연결 풀을 초기화하거나, 세션이 생성될 때 사용자 로그를 기록하거나, 세션이 타임아웃될 때 리소스를 정리하는 작업 등이 있다. 이러한 기능은 웹 애플리케이션의 배포 설명자인 web.xml 파일에 리스너 클래스를 등록함으로써 활성화된다. 리스너는 필터와 함께 서블릿의 핵심 요청-응답 처리 흐름을 보조하는 중요한 보조 컴포넌트 역할을 한다.

배포 설명자는 웹 애플리케이션의 구성과 설정을 정의하는 XML 기반의 파일이다. 이 파일의 이름은 일반적으로 web.xml이며, WAR 파일 내의 WEB-INF 디렉토리에 위치한다. 배포 설명자는 서블릿 컨테이너가 애플리케이션을 시작할 때 참조하는 핵심 설정 파일로, 서블릿, 필터, 리스너 등 다양한 구성 요소를 선언하고 그들 간의 매핑을 관리한다.

web.xml 파일은 주로 서블릿의 이름과 클래스 경로를 정의하고, 해당 서블릿을 특정 URL 패턴에 매핑하는 역할을 한다. 또한 초기화 매개변수를 설정하거나, 세션의 유효 시간, MIME 타입 매핑, 환경 변수 등을 지정할 수 있다. 애플리케이션의 보안 제약 조건을 정의하여 특정 URL에 대한 접근을 제어하는 기능도 제공한다.

자바 서블릿 스펙 3.0 버전부터는 어노테이션을 이용한 프로그래밍 방식의 설정이 도입되었다. 이로 인해 많은 기본적인 설정을 web.xml 파일에 명시적으로 작성하지 않고, 자바 소스 코드 내에서 @WebServlet, @WebFilter, @WebListener 등의 어노테이션을 사용하여 선언할 수 있게 되었다. 그러나 복잡한 매핑이나 컨테이너 수준의 설정, 어노테이션으로 표현하기 어려운 상세 구성은 여전히 배포 설명자를 통해 관리된다.

따라서 현대의 자바 웹 개발에서는 어노테이션을 주로 사용하지만, web.xml은 여전히 중요한 설정 수단으로 남아 있다. 두 방식은 상호 보완적으로 사용될 수 있으며, 동일한 설정이 두 곳에 존재할 경우 web.xml에 정의된 내용이 어노테이션 기반 설정보다 우선순위를 가진다.