JSP 중심 웹 개발의 배경2000년대 초·중반까지 대부분의 웹 애플리케이션은 JSP에 대부분의 로직을 포함하는 구조로 개발되었다.이는 자바 진영뿐만 아니라 PHP, ASP 등 다른 웹 기술에서도 공통적으로 나타난 흐름이다.당시의 웹 애플리케이션 구조는 다음과 같은 특징을 가진다.JSP 파일 하나에 화면(HTML)과 로직(Java 코드)이 함께 존재한다데이터 조회, 조건 분기, 반복 처리 등을 JSP 안에서 직접 수행한다초기 개발 속도가 빠르다요구사항이 단순하고 프로젝트 규모가 작을 때는 큰 문제가 없었다.하지만 웹 애플리케이션의 수와 복잡도가 증가하면서 이 구조는 한계가 드러난다. JSP에 로직이 집중되었을 때의 문제점웹 애플리케이션이 점점 복잡해지면서 다음과 같은 문제가 발생한다.JSP 파일이 점점..

웹 애플리케이션 서버에서 세션이 동작하는 원리 실습이 실습은 5장의 web-application-server 프로젝트를 기반으로 이어서 진행한다.지금까지 이론적으로 살펴본 쿠키와 세션의 관계를, 이번에는 직접 코드로 구현해본다.이번 실습의 목표는 다음과 같다.세션에서 사용할 고유한 아이디(Session ID) 를 생성한다이 세션 아이디를 쿠키를 통해 클라이언트에 전달한다이후 요청에서는 이 아이디로 같은 클라이언트를 식별한다즉, 세션이 실제로 어떻게 시작되는지를 바닥부터 구현해보는 단계다. 세션을 위한 “고유한 아이디”가 왜 필요한가세션의 핵심은서버에 상태를 저장하고, 그 상태를 구분할 수 있는 키를 클라이언트가 매 요청마다 보내준다.이때 필요한 것이 바로 세션 아이디(Session ID) 다.같은 클라..

웹 개발을 하다 보면 반드시 마주치는 말이 있다.“HTTP는 무상태 프로토콜이다” 라는 말이다.그리고 이어서 항상 등장하는 개념이 쿠키 와 세션 이다. HTTP는 왜 “무상태 프로토콜”인가HTTP의 본질은 매우 단순하다.클라이언트가 요청(Request)을 보내고서버가 응답(Response)을 보내면그 연결은 즉시 끊어진다.서버는 다음 요청이 들어왔을 때,이 요청이 누가 보낸 것인지이전에 무슨 요청을 했는지로그인한 상태인지를 기억하지 못한다.그래서 HTTP는 기본적으로“이전 요청을 기억하지 않는 프로토콜”,즉 무상태라고 부른다.하지만 실제 웹 애플리케이션은 다르다.로그인 상태 유지장바구니 유지사용자 맞춤 화면같은 기능들은 반드시 상태를 기억해야 한다.이 모순을 해결하기 위해 등장한 것이 쿠키다. 쿠키..

회원 목록은 로그인 사용자만, 개인정보 수정은 “본인만” 가능하게 만들기웹 애플리케이션에서 기능 구현만큼 중요한 것이 접근 제어다.화면에서 버튼을 숨겼다고 보안이 되는 것이 아니다.서버에서 직접 요청을 차단하지 않으면 언제든 우회가 가능하다.이번 단계에서는 다음 두 가지 요구사항을 서버 레벨에서 정확히 구현한다.회원 목록(/user/list)은 로그인한 사용자만 접근 가능개인정보 수정(/user/updateForm, /user/update)은 본인만 가능핵심 도구는 세션(Session) 이다. 회원 목록은 로그인 사용자만 접근 가능하게왜 서블릿에서 막아야 하는가?`/user/list`는 단순한 HTML 페이지가 아니다.서블릿이 DB에서 사용자 목록을 조회하고request에 데이터를 담아서JSP로 for..

웹에서 “로그인 상태”를 만든다는 건 결국 서버가 사용자를 기억하는 기준을 하나 정하는 것이다.이 구현에서는 그 기준을 세션(session) 으로 잡는다.핵심은 단순하다.로그인 성공하면 sessionScope.user에 사용자 객체를 저장한다로그아웃하면 세션을 무효화(invalidate)한다화면(JSP)은 sessionScope.user 존재 여부로 메뉴를 분기한다아래는 그 요구사항을 코드 변경 흐름으로 정확히 정리한 내용이다. 로그인 성공 시 세션에 사용자 저장 (로그인 상태의 기준 만들기)왜 세션에 저장하나?HTTP는 기본적으로 무상태(stateless) 이다.즉, 요청이 끝나면 서버는 “누가 방금 요청했는지”를 기억하지 않는다.그래서 로그인 후에도 다음 요청에서 로그인 상태를 유지하려면 서버 쪽에..

요구사항은 “개인정보 수정”이다.즉 로그인한 사용자가 자기 정보(이름/이메일/비밀번호 등)를 수정할 수 있어야 한다.또한 다른 사용자의 정보를 수정할 수 없어야 한다.그리고 수정 화면에는 기존 정보가 미리 채워져 보여야 한다.이 기능은 “화면을 보여주는 단계”와 “수정 내용을 저장하는 단계”로 나뉜다. 전체 흐름개인정보 수정은 다음 순서로 동작한다.사용자 목록(또는 프로필 화면)에서 “수정” 버튼을 누른다서버가 기존 사용자 정보를 찾아서 수정 폼 화면에 미리 채워서 보여준다사용자가 브라우저에서 값을 바꾼 뒤 “수정” 버튼을 누른다브라우저가 수정된 값들을 POST 요청으로 서버에 보낸다저장소`DataBase`에 수정 내용을 반영한다수정이 끝나면 목록`/user/list` 또는 메인`/`으로 리다이렉트한다..

서블릿에서 HTML을 직접 생성하는 문제회원 목록을 화면에 출력한다고 가정해보자.회원가입 시 저장된 사용자 목록을 조회한 뒤 HTML 테이블로 출력해야 한다.이 작업을 서블릿(ListUserServlet) 에서 직접 처리한다면 다음과 같은 문제가 발생한다.PrintWriter로 , , 를 직접 출력해야 한다문자열로 HTML을 이어 붙여야 한다로직과 화면 코드가 뒤섞인다가독성과 유지보수성이 급격히 나빠진다즉, 서블릿에서 HTML을 직접 생성하는 방식은 확장성과 유지보수 측면에서 한계가 명확하다.이 한계를 극복하기 위해 등장한 기술이 JSP(Java Server Page) 이다. JSP의 핵심 개념JSP의 핵심 아이디어는 단순하다.정적인 HTML은 그대로 두고,동적으로 변하는 부분만 프로그래밍으로 처리하자..

웹 애플리케이션에서 가장 헷갈리는 지점 중 하나는“데이터는 어디에 저장하고, 화면은 누가 그리고, 요청은 어떻게 전달되는가”다. 이 서블릿이 하는 일 한 줄 요약@WebServlet("/user/list")public class ListUserServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setAttribute("users", DataBase.findAll()); RequestDispatcher rd = req.getRe..