1. 웹 프로그래밍 기초

웹 프로그래밍을 처음 배우면 Servlet, JSP, WAS, MVC 같은 말이 한꺼번에 나오기 때문에 구조가 잘 안 잡힐 수 있다.
그래서 이 구간은 세부 기술을 바로 외우기보다, 웹이 어떤 흐름으로 동작하는지 큰 구조부터 먼저 이해하는 것이 중요하다.


브라우저가 서버에 요청을 보내고, 서버가 그 요청을 처리한 뒤 결과를 다시 돌려주는 구조를 먼저 잡아 두면, 뒤에서 배우는 Servlet과 JSP도 훨씬 자연스럽게 연결된다.
이 주제는 웹 애플리케이션 전체 구조를 처음 잡아 주는 시작점이다.

1-1. World Wide Web의 의미

웹은 무엇을 뜻하는가

World Wide Web, 줄여서 WWW는 인터넷에 연결된 컴퓨터들 사이에서 정보를 주고받고 공유할 수 있도록 만든 거대한 정보 공간이다.
쉽게 말하면, 우리가 브라우저로 주소를 입력하고 사이트에 들어가서 문서, 이미지, 영상, 링크를 보는 환경 전체를 웹이라고 이해하면 된다.


웹은 단순히 페이지 몇 개를 보는 공간이 아니다.
서로 다른 문서와 자료가 연결되어 있고, 사용자는 그 연결을 따라가면서 필요한 정보를 찾아간다.
그래서 웹은 단순한 파일 묶음이 아니라, 정보가 연결되어 움직이는 구조라고 보는 것이 더 정확하다.

Internet과 WWW는 같은 것이 아니다

가장 헷갈리기 쉬운 부분이 바로 이것이다.
Internet은 전 세계 컴퓨터를 연결하는 네트워크 자체에 가깝고, WWW는 그 네트워크 위에서 정보를 보여 주고 연결하는 서비스 방식에 가깝다.
즉, Internet이 길이라면 WWW는 그 길 위에서 문서를 연결하고 보여 주는 체계라고 볼 수 있다.


이 차이를 구분해야 웹을 더 정확하게 이해할 수 있다.
우리가 브라우저로 보는 화면은 Internet 전체가 아니라, 그 위에서 동작하는 WWW 서비스의 결과다.

hypertext가 웹을 특별하게 만든다

웹이 특별한 이유는 문서가 따로 떨어져 있는 것이 아니라 서로 연결된다는 점에 있다.
이 연결 방식이 hypertext다.
hypertext는 문서 안에서 다른 문서로 바로 이동할 수 있게 만든 연결 구조를 뜻한다.


그래서 사용자는 한 문서를 읽다가 필요한 다른 문서로 바로 넘어갈 수 있다.
이 연결이 계속 이어지기 때문에 웹 전체가 하나의 거대한 정보 공간처럼 동작한다.


또 웹은 글만 다루는 것이 아니다.
이미지, 오디오, 동영상 같은 여러 자료도 함께 다룬다.
그래서 웹은 단순 문서 모음이 아니라, 다양한 자료를 연결해서 보여 주는 멀티미디어 정보 환경이라고 이해하면 된다.

W3C는 왜 중요한가

웹에서는 모든 브라우저가 제각각 동작하면 안 된다.
같은 문서를 열었는데 브라우저마다 해석 방식이 크게 다르면 사용자는 같은 웹을 보고도 다른 결과를 보게 된다.
이 문제를 줄이기 위해 공통 규칙이 필요하다.


이 공통 규칙을 만들고 유지하는 역할을 하는 곳이 W3C다.
HTML, HTTP 같은 웹 핵심 기술도 이런 표준 위에서 동작한다.
즉, W3C는 웹을 예쁘게 만드는 조직이 아니라, 웹이 서로 다르게 깨지지 않고 공통 규칙 안에서 안정적으로 동작하게 만드는 기준을 제공하는 조직이다.


정리하면 WWW는 인터넷 위에서 정보를 연결하고 공유하는 구조이고, W3C는 그 구조가 모두에게 같은 규칙으로 동작하도록 표준을 만드는 역할을 한다.
이 흐름을 알고 있어야 뒤에서 나오는 웹 통신 구조도 자연스럽게 이어진다.

1-2. 웹의 처리 구조와 HTTP

웹은 요청과 응답으로 움직인다

웹은 겉으로 보면 사용자가 주소를 입력하거나 버튼을 누르고, 잠시 뒤 화면이 바뀌는 단순한 구조처럼 보인다.
하지만 내부에서는 브라우저와 서버가 정해진 규칙에 따라 요청과 응답을 주고받고 있다.
이 기본 흐름을 이해하는 것이 웹 프로그래밍의 출발점이다.


가장 먼저 기억해야 할 것은 웹이 클라이언트와 서버 구조로 동작한다는 점이다.
클라이언트는 서비스를 요청하는 쪽이고, 보통 사용자의 브라우저가 여기에 해당한다.
서버는 요청을 받아 처리하고 결과를 돌려주는 쪽이다.
즉, 브라우저가 먼저 서버에 요청을 보내고, 서버가 그 요청을 처리한 뒤 결과를 응답하는 구조다.

HTTP는 웹에서 대화하는 규칙이다

이때 브라우저와 서버가 대화할 때 사용하는 공통 규칙이 HTTP다.
HTTP는 HyperText Transfer Protocol의 줄임말이고, 웹에서 정보를 주고받기 위한 통신 규칙이다.
쉽게 말하면 브라우저와 서버가 서로 이해할 수 있도록 약속해 둔 웹 전용 대화 방식이라고 보면 된다.


문서를 열 때도, 이미지를 불러올 때도, 로그인 요청을 보낼 때도, 검색을 할 때도 결국은 모두 HTTP 요청과 응답 형태로 움직인다.
그래서 뒤에서 GET, POST, 요청 객체, 응답 객체를 배우게 되더라도, 그 바탕에는 항상 HTTP가 있다고 보면 된다.

요청이 먼저이고 응답이 나중이다

예를 들어 사용자가 주소창에 어떤 사이트 주소를 입력하면, 브라우저는 서버에 “이 문서를 보여 달라”는 요청을 보낸다.
그러면 서버는 요청을 확인하고, 해당 문서나 처리 결과를 다시 브라우저에 보내 준다.
브라우저는 그 응답을 받아 화면에 보여 준다.
우리가 평소에 당연하게 보는 웹 페이지는 이 과정을 아주 빠르게 반복해서 만들어지는 결과다.


여기서 중요한 점은 웹의 기본 출발이 항상 요청이 먼저이고 응답이 나중이라는 것이다.
서버가 먼저 사용자 화면을 바꾸는 것이 아니라, 사용자의 동작이나 브라우저의 요청이 먼저 발생하고 그 뒤에 서버가 반응한다.
그래서 웹 프로그래밍에서는 “무엇을 요청했고, 서버가 무엇을 응답했는가”를 기준으로 구조를 이해해야 한다.


지금 단계에서는 HTTP를 세세하게 외우기보다, 브라우저와 서버가 HTTP라는 규칙으로 요청과 응답을 주고받는다는 큰 구조를 먼저 잡는 것이 중요하다.
이 흐름이 잡혀야 다음 단계에서 요청 메시지와 응답 메시지 구조도 자연스럽게 이어진다.

이 그림은 웹의 가장 기본적인 흐름을 보여 준다.
클라이언트가 서버에 문서를 요청하고, 서버가 그 요청을 처리한 뒤 결과를 응답하는 구조다.
즉, 웹은 요청과 응답이 한 쌍으로 움직이는 방식이라고 이해하면 된다.

1-3. HTTP 요청과 응답 메시지 구조

HTTP는 그냥 “요청하고 응답한다”로만 끝나는 것이 아니다.
브라우저와 서버가 주고받는 메시지 안에는 어떤 방식으로 요청했는지, 어떤 자원을 원하는지, 어떤 형식의 데이터를 보내는지, 실제 내용이 무엇인지가 구역별로 나뉘어 담긴다.
그래서 이 구간은 설명만 먼저 읽기보다, 메시지 예시를 먼저 보고 그 안에서 각 부분이 어떤 역할을 하는지 끼워서 이해하는 방식이 더 쉽다.


처음에는 복잡한 전문 용어를 다 외우기보다, HTTP 메시지는 크게 시작줄, header, body로 나뉜다는 구조만 먼저 잡으면 된다.
이 구조가 잡혀야 뒤에서 GET, POST, 요청 객체, 응답 객체도 자연스럽게 연결된다.

먼저 요청 메시지 예시부터 보기

아래는 브라우저가 서버에 보내는 아주 단순한 HTTP request 예시다.

GET /edu/index.html HTTP/1.1
Host: localhost:8080
User-Agent: Chrome
Accept: text/html

이 예시는 줄 수는 적지만, 요청 메시지의 핵심 구조를 그대로 보여 준다.
첫 줄이 있고, 그 아래에 여러 개의 header가 있고, 마지막에는 필요하면 body가 올 수 있는 구조다.
지금 예시는 학습 단계에서 보는 가장 기본적인 GET 요청 형태라서 body 없이 끝나는 모습으로 이해하면 된다.


여기서 한 가지 더 봐야 할 것은 header와 body 사이의 구분이다.
실제 HTTP 메시지에서는 header가 끝나고 body가 시작되기 전에 빈 줄로 경계를 나눈다.
즉, 메시지는 그냥 이어지는 것이 아니라, 설명 정보 구역과 실제 내용 구역이 구분되어 전달된다.

요청 메시지의 첫 줄은 무엇을 뜻하는가

요청 메시지의 첫 줄은 가장 먼저 봐야 하는 부분이다.
이 줄에는 어떤 방식으로, 무엇을, 어떤 규칙 버전으로 요청하는지가 들어 있다.


위 예시의 첫 줄인 GET /edu/index.html HTTP/1.1을 나눠서 보면 이렇다.

• GET은 요청 방식이다.
• /edu/index.html은 요청 대상 자원이다.
• HTTP/1.1은 사용하는 HTTP 버전이다.
  
  
  즉, 요청 메시지의 첫 줄만 봐도 서버는 “브라우저가 어떤 방식으로 어떤 문서를 원하고 있구나”를 가장 먼저 파악할 수 있다.
  그래서 이 줄은 요청 메시지의 출발점이라고 보면 된다.
  
  
  

request header는 무엇인가

첫 줄 아래에 오는 부분이 request header다.
header는 실제 내용 그 자체라기보다, 이 요청이 어떤 성격을 가진 요청인지 설명하는 정보가 들어가는 구역이다.


예를 들어 위 예시에서

• Host는 어느 서버로 요청하는지 알려 준다.
• User-Agent는 어떤 브라우저나 클라이언트가 요청했는지 알려 준다.
• Accept는 어떤 형식의 응답을 받을 수 있는지 알려 준다.
  
  
  즉, header는 서버가 요청을 더 정확하게 해석할 수 있도록 도와주는 안내 정보다.
  이 단계에서는 각 항목을 전부 외우기보다, header는 요청에 대한 설명 정보가 들어가는 곳이라고 이해하면 충분하다.
  
  
  

request body는 언제 필요한가

body는 서버로 보내는 실제 내용이 들어가는 부분이다.
하지만 모든 요청에 항상 body가 있는 것은 아니다.


방금 본 GET 요청 예시는 보통 문서를 조회하거나 페이지를 달라고 요청하는 쪽에 가깝기 때문에, 학습 단계에서는 먼저 body 없이 이해해도 된다.
반대로 사용자가 입력한 값이나 서버로 보낼 데이터가 많을 때는 요청 본문에 실제 데이터를 담아 보내는 방식이 등장한다.
이 흐름이 뒤에서 배우는 POST와 연결된다.


즉, 요청 메시지는 무조건 body가 있어야 하는 구조가 아니라, 필요한 경우에 실제 데이터를 담는 칸이 body라고 이해하면 된다.
처음에는 GET은 주소를 통해 전달하는 쪽, POST는 본문에 데이터를 담는 쪽으로 이해하면 흐름을 잡기 쉽다.

이번에는 응답 메시지 예시 보기

이번에는 서버가 브라우저에게 돌려주는 HTTP response 예시를 보면 구조가 더 분명해진다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 46

<html><body><h1>Hello</h1></body></html>

이 메시지도 요청과 비슷하게 나뉜다.
맨 위에 상태를 알려 주는 첫 줄이 있고, 그 아래에 여러 개의 header가 있고, 마지막에 실제 내용인 body가 들어 있다.
즉, 요청이든 응답이든 큰 구조는 비슷하다고 보면 된다.

응답 메시지의 첫 줄은 무엇을 뜻하는가

응답 메시지의 첫 줄은 서버가 처리 결과를 한 줄로 먼저 알려 주는 부분이다.
위 예시의 HTTP/1.1 200 OK를 나눠서 보면 이렇다.

• HTTP/1.1은 사용하는 HTTP 버전이다.
• 200은 상태 코드다.
• OK는 그 상태를 글로 풀어 준 설명이다.
  
  
  즉, 이 첫 줄은 “서버가 요청을 어떻게 처리했는가”를 가장 먼저 보여 준다.
  브라우저는 이 정보를 보고 요청이 정상 처리됐는지, 문제가 있었는지 먼저 판단할 수 있다.
  그래서 응답 메시지의 첫 줄은 단순한 장식이 아니라, 처리 결과를 가장 먼저 알려 주는 핵심 정보다.
  
  
  

response header는 무엇인가

응답 메시지의 header도 설명 정보가 들어가는 부분이다.
다만 이번에는 요청이 아니라 응답 결과에 대한 설명이 들어간다.


예를 들어 위 예시에서

• Content-Type은 응답 데이터가 어떤 형식인지 알려 준다.
• charset=UTF-8은 어떤 문자 인코딩 방식으로 해석해야 하는지 알려 준다.
• Content-Length는 응답 내용의 길이를 알려 준다.
  
  
  즉, 응답 header는 브라우저가 서버 결과를 올바르게 해석하도록 도와주는 정보다.
  브라우저는 이 설명을 보고 지금 받은 것이 HTML인지, 이미지인지, JSON인지 같은 것을 판단한다.
  
  
  

response body는 무엇인가

응답 메시지의 body에는 브라우저가 실제로 받아서 사용할 내용이 들어간다.
위 예시에서는 HTML 문서 조각이 들어 있다.
그래서 브라우저는 이 내용을 읽고 화면에 <h1>Hello</h1>를 보여 줄 수 있다.


즉, 응답 body는 단순한 글 덩어리가 아니라 사용자가 실제로 보게 될 문서나 데이터가 들어가는 부분이다.
그리고 이 내용은 항상 HTML만 오는 것이 아니다.
상황에 따라 JSON, 이미지 데이터, 파일 내용 같은 것도 응답 본문에 들어갈 수 있다.

HTTP 요청 메시지와 응답 메시지는 설명 정보인 header와 실제 내용인 body로 나뉘어 전달된다.

header와 body는 어떻게 구분하면 쉬운가`

여기까지 보면 요청이든 응답이든 header와 body가 왜 나뉘는지 감이 잡힌다.
쉽게 정리하면 이렇다.

• header는 설명 정보다.
• body는 실제 내용이다.
  
  
  요청에서는 header가 “어떤 요청인지”를 설명하고, 필요하면 body에 서버로 보낼 실제 데이터가 들어간다.
  응답에서는 header가 “어떤 결과인지”를 설명하고, body에 브라우저가 실제로 사용할 결과 내용이 들어간다.
  즉, header는 안내판이고, body는 실제 전달물이라고 이해하면 가장 쉽다.
  
  
  

왜 이 구조를 먼저 알아야 하는가

이 구조가 중요한 이유는 뒤에서 배우는 GET과 POST, 요청 객체와 응답 객체가 전부 이 메시지 구조와 연결되기 때문이다.
예를 들어 어떤 데이터는 주소에 붙어서 전달되고, 어떤 데이터는 요청 본문에 담겨 전달된다.
또 서버는 응답 상태와 실제 응답 내용을 구분해서 브라우저에 보낸다.


또 이 구조는 특정 기기에서만 쓰이는 것이 아니다.
노트북 브라우저든, 모바일 브라우저든, 다른 웹 클라이언트든 웹을 사용한다면 결국 같은 HTTP 요청과 응답 구조를 따른다.
즉, 장치는 달라도 웹 통신 방식의 기본 규칙은 같다고 보면 된다.

클라이언트 종류가 달라도 웹에서는 같은 HTTP request와 HTTP response 구조를 사용한다.


정리하면 요청 메시지는 브라우저가 서버에 무엇을 원하는지 알려 주는 구조이고, 응답 메시지는 서버가 그 요청을 어떻게 처리했고 무엇을 돌려주는지 알려 주는 구조다.
즉, HTTP 요청과 응답 메시지는 단순한 한 줄 문장이 아니라 시작줄이 있고, header가 있고, 필요하면 body가 있는 구조로 이루어져 있다.
이 구조를 먼저 잡아 두면 뒤에서 나오는 GET, POST, HttpServletRequest, HttpServletResponse도 훨씬 덜 헷갈리게 된다.

1-4. Web Server와 WAS

정적 페이지와 동적 페이지

웹에서 서버가 하는 일을 이해하려면 먼저 정적 페이지와 동적 페이지를 구분해야 한다.
정적 페이지는 미리 만들어 둔 파일을 그대로 보여 주는 페이지다.
예를 들어 정적인 HTML 문서, 이미지, CSS, JavaScript 파일은 요청이 들어오면 준비된 내용을 그대로 전달하면 된다.


반면 동적 페이지는 요청이 들어온 뒤에 서버가 새 결과를 만들어야 하는 페이지다.
로그인한 사용자에 따라 다른 화면을 보여 주거나, 검색 결과를 만들거나, 데이터베이스 값을 읽어서 화면에 출력하는 경우가 여기에 해당한다.
즉, 정적 페이지는 준비된 파일 전달, 동적 페이지는 요청에 따라 새 결과 생성이라고 이해하면 된다.

이 그림은 정적 페이지와 동적 페이지의 차이를 비교해서 보여 준다.
정적 페이지는 준비된 파일을 그대로 전달하지만, 동적 페이지는 요청에 따라 서버 프로그램이 새 결과를 만든다.

Web Server의 역할

Web Server는 이미 준비된 자원을 전달하는 데 강하다.
쉽게 말하면 브라우저가 요청한 파일을 찾아서 보내 주는 역할에 가깝다.
그래서 정적인 HTML 문서, 이미지, CSS, JavaScript 파일을 전달하는 데 적합하다.


즉, Web Server는 파일 전달 중심의 서버라고 보면 된다.
이 단계에서는 “요청이 들어오면 준비된 자료를 찾아서 보내 준다” 정도로 이해하면 충분하다.

WAS의 역할

하지만 실제 웹 서비스는 파일만 전달해서 끝나는 경우가 많지 않다.
사용자 입력을 처리해야 하고, 조건을 판단해야 하고, 데이터베이스와 연결해서 값을 읽거나 저장해야 하는 경우가 많다.
이런 처리를 담당하는 쪽이 WAS다.


WAS는 Web Application Server의 줄임말이다.
이름 그대로 웹 애플리케이션을 실행하는 서버다.
즉, 단순히 파일만 보내는 것이 아니라, 서버 프로그램을 실행해서 동적인 결과를 만들어 응답할 수 있다.


쉽게 말하면 Web Server가 전달 중심이라면, WAS는 처리 중심의 서버라고 이해하면 된다.

이 그림은 WAS 안에서 웹 애플리케이션 실행 구조가 어떻게 연결되는지를 보여 준다.
즉, WAS는 단순 파일 전달이 아니라, 웹 애플리케이션 실행까지 담당하는 서버다.

Servlet이 실행되는 자리

WAS 안에서는 웹 애플리케이션을 실행하는 환경이 함께 동작한다.
이 환경 안에서 Servlet, JSP 같은 서버 프로그램이 실행된다.
즉, 브라우저 요청이 들어오면 서버가 그 요청을 받아 필요한 프로그램을 실행하고, 처리 결과를 다시 응답으로 돌려주는 구조다.


쉽게 말하면 Servlet은 서버 안에서 요청을 받아 필요한 처리를 수행하고 결과를 만드는 핵심 프로그램이다.
그래서 동적인 웹 처리를 이해할 때 Servlet은 중심에 놓이는 기술이라고 보면 된다.

이 그림은 요청이 여러 개 들어왔을 때 실행 환경이 각각의 요청을 처리 흐름에 연결하고, 그 안에서 Servlet이 동작한다는 점을 보여 준다.
즉, 요청을 관리하는 환경과 실제 처리에 참여하는 Servlet을 구분해서 이해해야 한다.

Web Server와 실행 환경의 역할 분리

학습 단계에서는 WAS 안에서 여러 역할이 함께 보이는 그림을 많이 보게 된다.
하지만 중요한 것은 역할을 나눠서 이해하는 것이다.
정적인 자원 전달에 강한 쪽과, 동적인 요청을 처리하는 쪽은 맡는 일이 다르다.


그래서 구조를 볼 때는 “누가 파일을 전달하는가”와 “누가 서버 프로그램을 실행하는가”를 구분해서 보는 습관이 필요하다.
이 구분이 있어야 뒤에서 Servlet과 JSP의 위치도 덜 헷갈린다.

이 그림은 정적인 자원을 다루는 쪽과 JSP, Servlet 같은 동적 처리를 담당하는 쪽의 역할 분리를 보여 준다.
즉, 둘은 비슷해 보여도 맡는 역할이 다르다.


정리하면, 정적 자료를 그대로 전달하는 데 강한 것이 Web Server이고, 요청에 따라 처리 결과를 새로 만들어 내는 역할까지 담당하는 것이 WAS다.
그리고 Servlet은 그 동적 처리 흐름 안에서 요청을 받아 실제 처리를 수행하는 중요한 서버 프로그램이다.

1-5. Servlet과 JSP

둘 다 서버에서 실행되는 기술이다

Servlet과 JSP는 둘 다 서버에서 실행되는 웹 기술이다.
즉, 브라우저 안에서 직접 실행되는 것이 아니라 서버 쪽 환경에서 동작한 뒤, 그 결과만 브라우저로 전달된다.
이 점을 먼저 잡아 두면 둘의 차이를 이해하기가 훨씬 쉽다.

Servlet의 성격

Servlet은 Java 코드 중심의 서버 프로그램이다.
요청을 받고, 필요한 값을 읽고, 처리 방향을 정하고, 결과를 응답으로 연결하는 쪽에 더 가깝다.
즉, 처리 흐름 중심의 기술이다.


처음 배우는 입장에서는 Servlet을 “서버 안에서 요청을 처리하는 Java 프로그램”이라고 이해하면 가장 쉽다.
이 설명이 핵심이다.

JSP의 성격

JSP는 화면을 만들기 쉽게 만든 기술이다.
HTML 문서 안에 필요한 동적 처리 요소를 넣어서 서버가 실행한 뒤 결과 화면을 만들어 준다.
그래서 JSP는 화면 표현 중심에 더 가깝다.


즉, Servlet이 처리 쪽에 더 가깝다면, JSP는 사용자가 보게 될 출력 화면 쪽에 더 가깝다.
이렇게 역할을 나눠서 이해하면 두 기술이 왜 같이 나오는지도 자연스럽게 보인다.

Servlet과 JSP의 차이

둘의 가장 큰 차이는 중심이 어디에 있느냐이다.
Servlet은 Java 코드 중심으로 요청을 처리한다.
JSP는 HTML 중심으로 화면을 만든다.


예전 설명에서는 Servlet은 Java 안에서 HTML을 만들고, JSP는 HTML 안에 Java를 넣는 방식이라고 많이 비교했다.
이 비교 자체는 방향을 잡는 데 도움이 된다.
다만 이 설명만 그대로 받아들이면 “그럼 Servlet에서 HTML을 직접 계속 만들어도 되는구나”라고 오해할 수 있다.


실제로는 큰 화면을 Servlet에서 직접 만드는 방식보다, Servlet은 처리 흐름을 맡고 화면은 JSP가 맡는 쪽이 구조상 더 깔끔하다.
그래서 이 둘은 경쟁 관계라기보다 역할을 나누어 함께 쓰는 관계라고 이해하는 것이 더 정확하다.

이 그림은 Servlet과 JSP의 차이를 한눈에 보여 준다.
Servlet은 처리 중심, JSP는 화면 중심으로 보면 큰 방향을 잡기 쉽다.

왜 같이 배우는가

웹 애플리케이션에서는 요청을 받고 처리하는 부분과, 최종 화면을 보여 주는 부분이 같이 필요하다.
이때 처리 쪽에는 Servlet, 화면 쪽에는 JSP를 두면 역할이 나뉘어서 구조가 정리된다.


즉, 하나는 입력과 흐름 제어에 가깝고, 다른 하나는 출력과 화면 표현에 가깝다.
이 역할 분리가 뒤에서 배우는 MVC 구조와도 바로 연결된다.

1-6. 웹 애플리케이션 디렉토리 구조

왜 폴더 구조를 따로 알아야 할까

웹 애플리케이션은 파일을 아무 데나 두고 실행하는 구조가 아니다.
설정 파일, 실행 파일, 라이브러리 파일이 각각 정해진 역할에 따라 배치된다.
이 구조를 알아야 Servlet 등록, 클래스 위치, 라이브러리 추가 같은 내용도 자연스럽게 이해된다.

`WEB-INF의 의미`

가장 먼저 기억할 폴더는 WEB-INF다.
이 폴더는 웹 애플리케이션 내부에서 중요한 설정과 실행 자원을 담는 공간이다.
즉, 웹 애플리케이션의 핵심 내부 영역이라고 보면 된다.

web.xml의 역할

web.xml은 웹 애플리케이션의 설정 파일이다.
쉽게 말하면 이 웹 애플리케이션이 어떤 설정으로 동작해야 하는지를 서버에게 알려 주는 문서다.
예전 방식에서는 Servlet 등록과 URL 매핑 정보도 여기에서 관리했다.


즉, web.xml은 웹 애플리케이션의 동작 규칙을 적어 두는 설정 문서다.

classes와 lib의 역할

classes 폴더에는 서버에서 실행할 클래스 파일이 들어간다.
예를 들어 작성한 Servlet을 컴파일하면 .class 파일이 되는데, 이런 실행용 클래스가 여기에 들어간다.


lib 폴더에는 외부 라이브러리 파일이 들어간다.
보통 .jar 파일 형태의 라이브러리를 넣어 사용한다.
즉, 직접 만든 코드만으로 부족한 기능을 외부 라이브러리로 보충할 때 사용하는 공간이다.


지금 단계에서는 “설정은 web.xml, 실행 클래스는 classes, 외부 라이브러리는 lib” 정도로 구조를 잡아 두면 충분하다.

이 그림은 웹 애플리케이션이 설정 파일, 클래스 파일, 라이브러리 파일을 역할별로 나누어 관리한다는 점을 보여 준다.
즉, 웹 애플리케이션은 단순 폴더가 아니라 실행 구조를 고려해 정리된 프로그램 묶음이다.

1-7. MVC 패턴

왜 MVC가 필요한가

웹 애플리케이션을 만들 때 화면, 처리, 데이터를 한 파일이나 한 클래스 안에 전부 섞어 넣으면 처음에는 빨라 보일 수 있다.
하지만 기능이 조금만 늘어나도 수정하기 어려워지고, 어디를 고쳐야 하는지 찾기도 힘들어진다.
이 문제를 줄이기 위해 사용하는 대표적인 구조가 MVC 패턴이다.


MVC의 핵심은 역할 분리다.
화면, 처리 흐름, 데이터 처리를 나누어 관리하면 구조가 훨씬 깔끔해진다.

Model, View, Controller의 역할

View는 사용자에게 보여 주는 화면을 담당한다.
웹에서는 보통 JSP가 이 역할에 가깝다.


Controller는 사용자의 요청을 먼저 받고, 어떤 처리로 보낼지 정하고, 전체 흐름을 조정한다.
웹에서는 보통 Servlet이 이 역할에 가깝다.
즉, Controller는 흐름 관리자다.


Model은 데이터를 다루는 영역이다.
단순히 값만 담는 객체뿐 아니라, 비즈니스 로직이나 데이터베이스 연동 로직도 함께 포함될 수 있다.
예를 들어 VO, DTO, DAO 같은 개념이 여기에 연결된다.
즉, Model은 데이터를 만들고, 가공하고, 저장하고, 꺼내는 쪽 전체라고 이해하는 것이 더 정확하다.

이 그림은 MVC의 가장 기본 구조를 보여 준다.
사용자의 요청은 Controller로 들어가고, Model에서 데이터를 처리한 뒤, View가 결과 화면을 응답한다.

Servlet은 MVC에서 어디에 있나

이 구간에서 가장 중요한 연결점이 바로 이것이다.
Servlet은 보통 MVC에서 Controller 역할에 가깝다.
즉, 요청을 먼저 받고, 어떤 로직을 실행할지 정하고, 처리 결과를 어떤 화면으로 넘길지 결정하는 쪽이다.


그래서 Servlet을 그냥 “모든 걸 다 하는 서버 프로그램”으로 이해하면 뒤에서 구조가 헷갈리기 쉽다.
더 정확하게는 요청을 받아 전체 처리 흐름을 조정하는 중심점이라고 이해하는 것이 좋다.


필요한 데이터 처리는 Model에 맡기고, 최종 화면 출력은 View로 넘기는 흐름으로 보면 Servlet의 자리가 훨씬 분명해진다.

이 그림은 웹 애플리케이션에서 Servlet, JSP, Beans, DAO가 MVC 구조 안에서 어떻게 연결되는지를 보여 준다.
보통 Servlet은 Controller, JSP는 View, Beans와 DAO는 Model 쪽에 가깝다.

웹 애플리케이션에서의 흐름

웹 애플리케이션에서 사용자가 요청을 보내면, 먼저 Controller가 그 요청을 받는다.
그다음 필요한 데이터를 Model에 요청하고, 처리된 결과를 View에 넘겨서 화면으로 보여 준다.
즉, 흐름은 보통 다음처럼 정리할 수 있다.


브라우저 요청 → Controller(Servlet) → Model 처리 → View(JSP) 출력


이 흐름을 이해하면 Servlet, JSP, DAO, VO, DTO가 왜 한꺼번에 등장하는지도 훨씬 덜 헷갈린다.

Model을 너무 좁게 보면 안 된다

Model을 단순히 데이터 한 개라고 생각하기 쉽다.
하지만 실제로는 데이터만 담는 객체, 비즈니스 로직을 수행하는 객체, 데이터베이스와 연결하는 객체가 함께 들어갈 수 있다.
즉, Model은 단순 값 하나가 아니라, 데이터를 다루는 영역 전체라고 보는 것이 더 맞다.

이 그림은 Model 안이 단순 데이터 하나로 끝나지 않고, Domain Model, 비즈니스 객체, DAO까지 포함할 수 있다는 점을 보여 준다.
즉, Model은 데이터를 다루는 쪽 전체를 묶어 보는 개념에 가깝다.

핵심 정리

Web Server는 정적인 파일 전달에 강하다.
WAS는 동적 처리를 담당한다.
Servlet은 서버 안에서 요청을 받아 처리 흐름을 움직이는 핵심 프로그램이다.
JSP는 화면 표현에 더 가깝다.


그리고 이 둘의 역할을 더 깔끔하게 나누어 이해하는 구조가 MVC다.
즉, 이 구간에서 가장 중요한 것은 개별 용어를 따로 외우는 것이 아니라, 웹 통신 구조 → 서버 처리 구조 → Servlet과 JSP의 역할 → MVC에서의 위치라는 흐름을 한 번에 잡는 것이다.
이 흐름이 잡히면 뒤에서 나오는 Servlet 프로그래밍도 훨씬 쉽게 이어진다.