💡 JSP (JavaServer Pages)
- 정의: JSP는 HTML 코드 안에 Java 코드를 삽입하여 동적 웹페이지를 생성하는 웹 애플리케이션 도구입니다.
- 역할: JSP는 주로 프레젠테이션(뷰) 레이어에서 사용되어 클라이언트에게 보여지는 화면을 동적으로 렌더링하는 데 사용됩니다.
- 장점: HTML 코드 작성이 편리하며, HTML 안에 쉽게 Java 코드를 삽입할 수 있어 웹 디자이너나 프런트엔드 개발자가 작업하기에 용이합니다.
- 주 용도: 클라이언트에게 동적인 콘텐츠를 보여주는 작업을 담당합니다.
💡 자바 서블릿(Java Servlet)
- 정의: 서블릿은 웹페이지를 동적으로 생성하기 위한 서버 측 프로그램으로, Java 언어를 기반으로 만들어집니다. 웹 애플리케이션 서버(Web Application Server) 위에서 컴파일되고 실행됩니다.
- 역할: 서블릿은 주로 비즈니스 로직 처리 및 클라이언트의 요청을 처리하는 역할을 수행하며, HTTP 요청을 받아 적절한 응답을 반환합니다.
- 단점: 서블릿에서는 자바 코드 내에 HTML 코드를 포함해야 하므로 코드가 복잡하고 가독성이 떨어집니다. 이는 작업 효율성을 저하시킵니다.
- 주 용도: 클라이언트의 요청을 처리하고, 데이터베이스와 상호작용하는 비즈니스 로직을 처리합니다.
💡 JSP와 서블릿의 차이점
- JSP: HTML 코드 안에 Java 소스코드를 삽입하는 방식으로 HTML 작성이 간편하며, 화면을 동적으로 렌더링하는 데 적합합니다.
- 서블릿: 자바 코드 내에 HTML 코드가 삽입되는 방식이기 때문에 읽고 쓰기가 불편하며, 프런트엔드와의 작업 효율성이 떨어집니다.
💡 JSP와 서블릿의 관계
- JSP는 내부적으로 서블릿으로 변환됩니다. 즉, JSP는 서블릿의 상위 레벨에서 동작하는 기술로, HTML을 다루기 쉽게 해줍니다.
- JSP는 프레젠테이션(뷰), 서블릿은 비즈니스 로직(컨트롤러) 역할을 수행합니다. 이 두 기술은 MVC 패턴에서 각각 다른 역할을 담당하며, 이를 통해 코드의 유지 보수성과 효율성을 높일 수 있습니다.
그러면 HTML 안에 자바 코드 삽입하는게 훨씬 좋은거아닌가?
💡 HTML 안에 Java 코드를 삽입하는 장점 (JSP의 장점)
- 코드 작성이 직관적: JSP에서는 HTML과 Java 코드를 함께 작성할 수 있어, 화면을 구성하면서 필요한 동적 처리를 쉽게 추가할 수 있습니다. 즉, 디자이너나 프런트엔드 개발자가 HTML을 직접 다루면서 Java 로직을 포함시킬 수 있다는 점에서 직관적입니다.
- 빠른 개발: 동적인 웹 페이지를 빠르게 개발할 수 있습니다. 화면 설계와 비즈니스 로직을 한 파일에서 처리할 수 있기 때문에 빠르게 웹 페이지를 생성할 수 있습니다.
- UI와 로직을 동시에 처리 가능: 하나의 페이지 안에서 UI 렌더링과 간단한 로직을 동시에 처리할 수 있어, 작은 프로젝트나 단순한 웹 페이지 개발에 유리합니다.
💡 HTML 안에 Java 코드를 삽입하는 단점 (JSP의 단점)
- 유지보수가 어려움: HTML과 Java 코드가 한 페이지에 혼합되어 있을 경우, 시간이 지날수록 유지보수가 어렵습니다. 특히, 규모가 커지면 로직과 UI 코드가 뒤섞여 있어서 가독성이 떨어지고, 수정할 때 실수가 발생하기 쉽습니다.
- MVC 패턴 위배: JSP에서 Java 코드를 많이 사용하는 경우, 프레젠테이션(뷰) 레이어에 비즈니스 로직이 포함되어 MVC 패턴의 원칙을 위배하게 됩니다. 이로 인해 코드의 구조화가 어려워지고, 재사용성이 떨어지며 테스트하기 어려워집니다.
- 복잡한 로직 처리 비효율: JSP에서 복잡한 비즈니스 로직이나 데이터베이스 처리를 포함할 경우, 로직이 지저분해지고 페이지 처리 속도가 느려질 수 있습니다. 이러한 로직은 서블릿이나 서비스 계층에서 처리하는 것이 더 적합합니다.
- 테스트 및 디버깅 어려움: JSP는 동적으로 HTML을 생성하기 때문에, 디버깅이 어렵고 코드가 제대로 동작하는지 확인하기 어려운 경우가 많습니다. Java 코드와 HTML 코드가 섞여 있기 때문에, 어느 부분에서 에러가 발생하는지 찾기가 까다로울 수 있습니다.
💡 JSP 대신 사용하는 대안
HTML과 Java 코드를 분리하여 더 나은 구조로 개발하는 방법으로는 다음과 같은 기술들이 있습니다:
- JSTL (JavaServer Pages Standard Tag Library): Java 코드를 직접 HTML에 쓰는 대신, JSTL 같은 태그 라이브러리를 사용해 HTML에서 로직을 처리할 수 있습니다. 이를 통해 코드의 가독성과 유지보수성을 높일 수 있습니다.
- EL (Expression Language): JSP의 표현 언어로, 간단한 로직을 처리할 수 있으며 Java 코드 대신 사용할 수 있어 HTML 코드가 더 깔끔해집니다.
- Spring MVC: MVC 패턴을 적극 활용하여 **서블릿(Controller)**는 비즈니스 로직을 처리하고, **JSP(View)**는 프레젠테이션 역할만 수행하는 구조로 개발할 수 있습니다. 이 방식은 로직과 UI를 명확히 분리하여 유지보수성과 확장성을 높여줍니다.
결론
HTML 안에 Java 코드를 삽입하는 방식(JSP)은 작고 단순한 웹 애플리케이션에서는 빠르게 개발할 수 있는 이점이 있지만, 복잡한 웹 애플리케이션에서는 유지보수가 어렵고 가독성이 떨어질 수 있습니다. 규모가 커질수록 Java 코드와 HTML 코드를 분리하고, MVC 패턴과 같은 구조적인 방법을 사용하는 것이 더 좋습니다.
💡 View Resolver = 뷰 템플릿 엔진
View Resolver는 스프링 웹 MVC에서 뷰(View)를 찾는 역할을 하는 컴포넌트입니다. 클라이언트 요청이 컨트롤러에서 처리된 후, 그 결과를 화면에 표시하기 위해서는 뷰(View)가 필요합니다. 스프링 MVC는 뷰 리졸버(View Resolver)를 사용해 요청에 맞는 뷰 파일(JSP, Thymeleaf, FreeMarker 등)을 찾아서 렌더링할 수 있도록 돕습니다.
- 뷰 리졸버는 뷰 템플릿 엔진을 사용해 뷰를 결정합니다. 예를 들어, 스프링은 Thymeleaf, JSP, FreeMarker 같은 템플릿 엔진을 지원하며, 이 엔진들이 HTML이나 기타 클라이언트에 반환할 화면을 생성합니다.
- 뷰 템플릿 엔진은 주로 모델 데이터를 이용해 동적으로 HTML 페이지를 생성하는 데 사용됩니다.
예시:
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="prefix" value="/WEB-INF/views/" />
<property name="suffix" value=".jsp" />
</bean>위 설정에서 뷰 리졸버는 prefix와 suffix를 사용하여 컨트롤러에서 반환한 뷰 이름을 /WEB-INF/views/ 디렉토리의 .jsp 파일로 매핑합니다.
💡 아웃고잉 파라미터(Outgoing Parameter)와 인풋 파라미터(Input Parameter)
- 아웃고잉 파라미터는 서버가 클라이언트로 보낼 데이터를 의미합니다. 서버는 이 파라미터를 HTTP 응답의 일부로 보내며, 클라이언트(예: 웹 브라우저)는 이를 수신하여 화면에 표시하거나, 추가적인 동작을 수행할 수 있습니다.
{ "status": "success", "data": { "id": 123, "name": "John Doe" } } - 예: API 요청에 대한 JSON 응답의 필드, 서버에서 보내는 쿠키, 헤더 정보 등이 아웃고잉 파라미터에 해당합니다.
- 인풋 파라미터는 클라이언트가 서버로 보내는 데이터를 의미합니다. 클라이언트가 요청을 보내면서 함께 전달하는 데이터는 주로 HTTP 요청 파라미터, 쿼리 스트링, 헤더 정보, 폼 데이터 등을 통해 전달됩니다.
POST /login Content-Type: application/x-www-form-urlencoded username=johndoe&password=123456 - 예: 로그인 요청 시 클라이언트가 보내는 사용자 이름과 비밀번호가 인풋 파라미터에 해당합니다.
💡 호스트가 URL의 도메인에 매핑
호스트(Host)는 네트워크 상에서 웹 서버를 식별하는 역할을 하며, 도메인 이름으로 매핑됩니다. 도메인은 특정 IP 주소에 대해 사람이 읽기 쉬운 이름을 제공하는 방식입니다.
- 예를 들어, www.example.com이라는 도메인은 실제로 특정 IP 주소로 매핑됩니다. DNS(Domain Name System) 서버가 도메인 이름을 해당 IP 주소로 변환하여 클라이언트가 해당 서버에 접근할 수 있게 합니다.
- 호스트는 서버에서 다수의 도메인을 처리할 수 있으며, 이들 각각을 가상 호스트(Virtual Host)라고도 부릅니다. Tomcat 같은 웹 서버에서는 여러 호스트를 설정하여 하나의 서버가 여러 도메인을 처리할 수 있습니다.
예시:
www.example.com이라는 도메인이 IP 주소 192.168.1.1에 매핑되면, 사용자가 브라우저에 www.example.com을 입력할 때 이 도메인은 DNS를 통해 해당 IP 주소로 변환됩니다.
💡 컨텍스트(Context)
컨텍스트(Context)는 웹 애플리케이션에서 애플리케이션의 경로와 관련된 개념으로, 애플리케이션의 고유한 경로를 나타냅니다. 각 웹 애플리케이션은 서버 내에서 고유한 경로를 가질 수 있으며, 이는 URL의 도메인 뒤에 이어지는 경로로 나타납니다.
- 예를 들어, http://www.example.com/myapp에서 myapp이 바로 컨텍스트 경로(context path)입니다.
- 컨텍스트는 여러 애플리케이션이 동일한 서버에서 구동될 때, 각 애플리케이션을 구분하는 역할을 합니다.
- 스프링 웹 애플리케이션에서는 컨텍스트를 통해 각 애플리케이션에 대한 요청을 정확히 처리할 수 있습니다.
예시:
<Context path="/myapp" docBase="/path/to/myapp" />위 설정에서 myapp은 애플리케이션의 컨텍스트 경로입니다. 즉, 클라이언트는 http://localhost:8080/myapp로 접속하여 해당 애플리케이션에 접근할 수 있습니다.
💡 도메인 생략 == 상대적 URL
도메인 생략은 상대적 URL(relative URL)을 의미합니다. 상대적 URL은 현재 위치를 기준으로 한 URL로, 도메인(또는 프로토콜) 정보를 포함하지 않고 경로만 명시합니다.
- 절대 URL은 전체 경로를 포함하여 URL을 명시합니다. 예: http://www.example.com/page.html
- 상대적 URL은 현재 페이지를 기준으로 다른 페이지를 참조합니다. 예: /page.html 또는 page.html
예시:
- 절대 URL: http://www.example.com/resources/css/style.css
- 상대적 URL: /resources/css/style.css
상대적 URL은 현재 페이지의 도메인과 상관없이, 동일한 서버에서의 다른 리소스나 페이지를 참조할 때 유용합니다. 예를 들어, HTML 파일 내에서 다른 페이지로 링크를 걸 때, 상대 경로를 사용하면 동일한 서버 내의 경로에서 올바르게 동작합니다.
결론
- View Resolver는 뷰 템플릿 엔진을 사용해 클라이언트에 보일 뷰를 결정하는 역할을 합니다.
- 아웃고잉 파라미터는 서버에서 클라이언트로 전달되는 데이터, 인풋 파라미터는 클라이언트에서 서버로 전달되는 데이터를 의미합니다.
- 호스트는 URL의 도메인과 매핑되며, 도메인 이름을 IP 주소로 변환하는 역할을 합니다.
- 컨텍스트는 애플리케이션의 고유 경로로, 서버 내에서 애플리케이션을 구분하는 역할을 합니다.
- 도메인 생략은 상대적 URL을 의미하며, 도메인 없이 경로만으로 리소스를 참조하는 방식입니다.