[MVC와 웹 흐름 제어] 5. forward vs redirect: 언제 무엇을 써야 하는가

 

MVC에서 흐름 제어를 하다 보면 결국 매번 이 선택을 하게 된다.

• forward로 JSP를 보여줄 것인가
• redirect로 다른 URL로 이동시킬 것인가

둘의 차이를 정확히 잡아두면
“왜 PRG가 필요한지”, “왜 WEB-INF에 JSP를 두는지”도 자연스럽게 이해된다.

 

 

한 줄로 정리하면 이렇게 된다

• forward: 서버 내부에서 같은 요청을 들고 View(JSP)로 넘긴다
• redirect: 브라우저에게 새 요청을 보내게 해서 다른 URL로 이동시킨다

즉 핵심 차이는 “request가 유지되느냐, 끊기느냐”이다.

 

1) 이동 주체가 다르다

forward

서버 내부 이동이다.
컨트롤러가 RequestDispatcher로 JSP에게 처리를 넘긴다.

브라우저는 이 사실을 모른다.

redirect

브라우저 이동이다.
서버가 Location 헤더를 보내고, 브라우저가 그 주소로 다시 요청한다.

 

2) request/response의 연속성이 다르다

forward는 request/response가 유지된다

그래서 컨트롤러에서 request.setAttribute()로 담아둔 데이터가
JSP에서 그대로 보인다.

즉 “조회 화면 렌더링”에서 가장 자연스럽다.

redirect는 request/response가 끊긴다

브라우저가 새 요청을 보내므로 request/response는 새로 만들어진다.

그래서 컨트롤러에서 request에 담아둔 값은 redirect 이후에 사라진다.

redirect 후에 값을 넘기려면 다른 전략을 써야 한다.

• 쿼리 스트링으로 붙이기
• 세션에 저장하기
• (프레임워크가 있으면) flash attribute 같은 임시 저장소 쓰기

 

3) 주소창(URL)이 다르다

forward는 URL이 안 바뀐다

서버 내부에서만 이동했기 때문이다.

사용자 입장에서는
“처리된 JSP 화면을 보고 있지만 주소는 여전히 컨트롤러 URL”인 상태가 된다.

redirect는 URL이 바뀐다

브라우저가 Location으로 새 요청을 보내기 때문이다.

사용자 입장에서는
“주소창이 실제 화면에 해당하는 URL로 바뀐 상태”가 된다.

 

4) 언제 무엇을 쓰는가 (실무 기준)

forward가 자연스러운 경우: 조회 화면

• 목록 조회 화면
• 상세 조회 화면
• 입력 폼 화면(GET)

즉 “화면을 만들어 보여주는 목적”일 때 forward가 기본이다.

redirect가 자연스러운 경우: 처리 후 이동

• 등록 처리(POST) 후 목록으로 이동
• 수정 처리(POST) 후 상세로 이동
• 삭제 처리(POST) 후 목록으로 이동

즉 “상태를 바꾸는 처리”를 하고 난 뒤에는 redirect가 기본이다.

이 패턴이 바로 PRG(Post-Redirect-Get)로 이어진다.

 

정리

• forward: 서버 내부 이동, request 유지, URL 안 바뀜, setAttribute로 데이터 전달 가능
• redirect: 브라우저 새 요청, request 끊김, URL 바뀜, setAttribute로 데이터 전달 불가
• 조회(화면 렌더링)는 forward가 자연스럽고
• 등록/수정/삭제 같은 처리 후에는 redirect가 자연스럽다