앞에 쓴 Servlets과 Spring에서 몇번 나온 단어인 JSP. 해당 내용에 대해 간략하게라도 써서 남겨둘까 하다가 따로 작성하기로 하기도 했고 잠깐 찾아보니 간단히 적기 어렵기도 해서 이렇게 적게 되었다.
Spring 글에서 언급한 JSP의 부분을 가져와보자.
-
이에 HTML 생성을 편하게 할 수 있는 JSP를 개발하게 되었고 이를 이용해 동적 웹페이지를 구성할 수 있게 되었다. 하지만 JSP는 하나의 파일 안에 HTML과 java 코드가 같이 있어 알아보기 어렵고 로직이 조금만 복잡해도 코드가 꼬일 수 있었다.
-
여기서 Servlet과 JSP를 섞어서 사용하면서 서로의 단점을 보완할 수 있게 사용하면서 MVC 패턴을 적용해 서로의 관심사를 나누게 되었다. MVC 패턴은 프로젝트를 구성할 때 Model, View, Controller로 구성요소를 세가지로 나눠 구분한 패턴이다.
이때도 간단하게 HTML을 생성하기 편한 것이 JSP 라고 하며 장단점을 하나씩 적었었다. 또한 최근에는 Servlet과 JSP를 섞어서 쓴다고 했다.
이 부분에 대하여 JSP의 개념과 사용, Servlet과의 차이와 사용까지 정리해본다.
JSP(JavaServer Pages / Jakarta Server Pages)
개념
자바 서버에서 사용하는 페이지..? 무슨 페이지를 말하는 것인지 감이 잘 안오니 사전적 개념을 먼저 본다.
- HTML내에 자바코드를 삽입하여 웹 서버에서 동적으로 웹 페이지를 생성하여 웹 브라우저에 돌려주는 서버 사이드 스크립트 언어이다. Java EE 스펙 중 일부로 웹 애플리케이션 서버에서 동작한다.
- 자카르타 서버 페이지는 실행시에는 자바 서블릿으로 변환된 후 실행되므로 서블릿과 거의 유사하다고 볼 수 있다. 하지만, 서블릿과는 달리 HTML 표준에 따라 작성되므로 웹 디자인하기에 편리하다. 1999년 썬 마이크로시스템즈에 의해 배포되었으며 이와 비슷한 구조로 PHP, ASP, ASP.NET 등이 있다.
위의 내용을 보면
- HTML에 자바 코드를 넣어 웹 브라우저를 동작하는 서버측 스크립트 언어
- Java EE 스펙 중 일부, 웹 애플리케이션 서버에서 동작한다.
- 실행 시 자바 Servlet으로 변환 후 실행된다.
로 말할 수 있다.
이 중 마지막 부분이 조금 걸린다. 굳이 변환 할거면 왜 JSP를 사용하는 거지?
우선 특징과 구성, 그에 따른 동작과 장단점을 살펴본다.
특징
- HTML 페이지에 자바 코드를 직접 사용한다
- Servlet 컨테이너에 의해 관리되는 내장 객체의 생명주기를 이용하여 페이지 간 속성을 관리한다.
- 커스텀 태그 기술을 사용하여 코드를 태그화(action, JSTL) 한다.
- EL(Expression Language)을 통해 데이터를 표현한다.
이 특징 부분만 봐도 왜 JSP를 쓰는 지 어느정도 알 수 있다. 바로 Servlet에서의 데이터 표현이 불편하다는 점이다. JSP는 HTML에 Java를 사용할 수 있게 하여 Servlet보다 프로그램 요소를 더 쉽게 구현할 수 있도록 도와준다. 하지만 이를 서버에서 이해하기 위해 Servlet으로 관리 되는 것이다.
구성요소
- 지시어(Standard Directives)
- 액션(Standard Action)
- 템플릿 데이터(Template Data)
- 스크립트 요소(Script Element)
- 커스텀 태그(Custom Tag)와 EL(Expression Language)
각각의 구성요소는 고유의 표기법과 속성을 가지지만 Servlet 형태의 소스로 변환되는 과정에서 자바 코드로 바뀌게 된다.
태그
결국 JSP도 HTML 기반이기 때문에 HTML의 특징인 태그를 통한 구분을 해야 한다. 따라서 Java를 이용한 구현도 HTML의 태그 안에서 구성되어야 한다. 아래는 이런 JSP에서 사용하는 태그이다.

이 표를 읽어보면 결국 개발자가 모든 동작들에 대한 코드를 하나하나 다 작성해야 한다. 이는 매우 불편하기 때문에 이를 라이브러리화 하여 구현을 간편하게 해주는 JSTL을 사용한다.
- JSTL: JSP Standard Tag Library로 이름 그대로 JSP 표준 태그 라이브러리 이다. 여기엔 JSP에서 사용 가능한 커스컴 태그들이 모여있어 비즈니스 로직과 프리젠테이션 로직을 분리할 수 있도록 해준다.
동작 과정

위의 사진에서 보이듯 전체적인 흐름 자체는 Servlet과 비슷하지만 JSP가 Servlet으로 변환되는 과정이 추가되어있다.
변환 과정
기본적으로 HTML 문서의 텍스트 파일 형식을 가지지만 컴파일된 JSP는 단순한 파일이 아니라 컨테이너에서 Servlet 객체로서 관리된다. 다시 말해 컴파일이 완료되면 JSP는 더 이상 파일로부터 처리되는 구조가 아니라 컨테이너에 로드된 Servlet으로 동작하는 구조가 되는 것이다. 따라서 Servlet 컨테이너는 JSP 파일을 Servlet 구조의 .java 소스 코드로 변환하며 컴파일을 수행한다. 순서를 그림과 글로 다시 본다면 아래와 같다.

- jsp 소스 코드 작성 -> 웹 애플리케이션 배포
- 사용자 요청 시 컨테이너는 해당 jsp 의 클래스 변환 여부 확인
- 변환되지 않았다면 xxx_jsp.java 파일 생성 및 .class로 컴파일
- jspInit() 메서드를 통해 Servlet실행
- _jspService() 메서드를 통해 사용자 요청 처리
- 이후 요청에 대해 메모리 상의 Servlet으로 Servlet과 같이 서비스
- 컨테이너 종료 혹은 관리 도구에 의해 Servlet jspDestroy() 호출로 종료
장점
- HTML 파일에 자바 기술을 거의 무한대로 사용할 수 있다.
- 비교적 쉽게 개발이 가능하다.
- 커스텀 태그 라이브러리 등 JSP 개발에 도움을 주는 확장 태그 구조를 사용할 수 있다.
- Servlet으로 변환되어 실행 되므로 Servlet 기술의 장점을 모두 가진다.
- MVC 패턴, 스프링 프레임워크 등 잘 설계된 구조를 적용할 수 있어 체계가 잡히면 개발 생산성이 향상되고 성능이 보장 된다.
- 모든 개발이 서버에서 이루어지므로 개발의 집중화를 통한 효율이 있을 수 있다.
단점
- 화면 구성 요소의 변경은 jsp -> java -> class -> Servlet 실행의 과정을 거치게 되므로 개발 과정에서 사소한 UI 변경도 매번 확인하는데 시간이 소요된다.
- 개발자와 디자이너 간의 역할 분담에 제약이 있다.
- 서버에 들어가는 파일에 구현을 하기 때문이다.
- jsp 파일의 화면 디자인 확인을 위해서도 반드시 Servlet 컨테이너의 실행이 필요하다.
→ SSR(Server Side Rendering) 방식의 백엔드 웹 개발의 문제라 볼 수 있다.
- SSR: 웹 애플리케이션에서 클라이언트 측에서만 렌더링 되던 부분을 서버에서도 렌더링하여 완전한 HTML 문서를 클라이언트에게 제공하는 기술
Servlet과 JSP
지금까지 보면 JSP는 결국 Servlet으로 변환과정이 추가될 뿐으로 화면의 동적 구성을 하는데 있어 Servlet보다 더 편한 환경을 제공하기 위해 있다는 사실을 알 수 있다. 이를 간략히 적으면
- Servlet은 Java 안에 HTML 코드를 작성한다.
- Java 중심의 복잡한 로직을 구현하는데 강하지만 화면 작성과 수정에 약하다.
- JSP는 HTML 안에 Java를 작성한다.
- 화면의 작성과 수정에 강하지만 복잡한 로직 구현이 힘들 수도 있고 또한 위의 동작 과정에서도 보이듯 JSP의 정보를 사용자가 받기 때문에 소스코드가 공개된다. 만약 이 부분이 중요한 동작을 담당하고 있다면 보안적으로 문제가 될 수도 있다.
→ 중요 로직은 Servlet / HTML의 작성 중심은 JSP에 하는 것이 유리하다.
이렇게 구성과 동작을 분리한다면 유지보수가 용이해진다.
결론
-
JSP는 HTML 작성에 Java 코드를 사용해 동적 구성을 할 수 있다.
-
Servlet으로는 화면 구성에 어려움이 있다는 점을 해결하기 위해 JSP가 등장했다.
-
화면 구성을 주로 할 땐 JSP, 중요 로직을 구현할 땐 Servlet을 사용하는 것이 좋다.