[MVC와 웹 흐름 제어] 7. WEB-INF에 JSP를 두는 이유: “JSP 직접 호출”을 구조적으로 막는다

 

MVC 구조를 제대로 만들려면 한 가지를 강제로 지켜야 한다.

• 브라우저는 JSP를 직접 호출하지 않는다
• 브라우저는 Controller(서블릿) URL만 호출한다
• Controller가 처리한 뒤 JSP(View)로 forward 한다

그런데 문제는 JSP가 파일 경로 기반으로 접근 가능하면
사용자가 주소창에 JSP URL을 직접 입력해서 들어올 수 있다는 점이다.

이걸 “규칙”으로만 막으려 하면 항상 구멍이 생긴다.
그래서 웹 애플리케이션에는 아예 “직접 접근이 불가능한 보호 영역”이 있다.

그게 WEB-INF이다.

 

 

WEB-INF는 브라우저에서 직접 접근할 수 없는 특별한 경로이다

WEB-INF 아래에 있는 자원은
브라우저의 외부 요청으로 직접 접근할 수 없다.

즉 아래 같은 URL을 브라우저에서 직접 입력해도 실행되지 않는다.

• /WEB-INF/views/todo/list.jsp

이 특성 때문에 WEB-INF는 “외부 접근 차단 구역”으로 쓰인다.

 

 

JSP를 WEB-INF 아래에 두면 뭐가 달라지나

JSP가 일반 경로에 있으면 이런 일이 가능하다.

• 사용자가 JSP URL만 알면 직접 GET 요청으로 들어온다
• Controller를 거치지 않는다
• GET/POST 제어, 데이터 준비, 권한 체크 같은 흐름이 무너진다

반대로 JSP를 WEB-INF 아래에 두면 구조가 바뀐다.

• 브라우저는 JSP에 직접 접근할 수 없다
• Controller만 RequestDispatcher.forward로 접근할 수 있다
• 즉 반드시 Controller를 거치게 강제된다

이게 MVC 구조를 코드 규칙이 아니라 배치 구조로 보장해주는 장치이다.

 

 

WEB-INF는 “View는 내부 자원”이라는 의도를 강제한다

MVC에서 View(JSP)는 사용자에게 노출되는 엔드포인트가 아니다.
View는 Controller가 내부적으로 선택해서 렌더링하는 내부 자원이다.

WEB-INF 아래로 JSP를 숨기면
이 의도가 구조적으로 강제된다.

• URL 설계는 Controller 기준으로 한다
• JSP 파일명/폴더 구조는 내부 구현이다
• 화면 파일이 바뀌어도 외부 URL은 유지할 수 있다

즉 유지보수에 유리해진다.

 

 

실전에서 흔한 배치 형태

그래서 MVC 구조에서는 JSP를 보통 이런 위치에 둔다.

• /WEB-INF/views/...

그리고 Controller는 항상 이 경로로 forward 한다.

• request.getRequestDispatcher("/WEB-INF/views/...").forward(...)

이 흐름이 “브라우저 → Controller → View” 구조를 안정적으로 만든다.

 

 

정리

• WEB-INF는 브라우저에서 직접 접근할 수 없는 보호 영역이다
• JSP를 WEB-INF 아래에 두면 JSP 직접 호출을 구조적으로 차단할 수 있다
• 결과적으로 브라우저는 반드시 Controller를 통해서만 화면을 보게 된다
• URL은 Controller 기준으로 설계되고, JSP는 내부 구현으로 숨겨진다