[MVC와 웹 흐름 제어] 4. redirect(sendRedirect)

 

“브라우저에게 새 요청을 시키는 방식”

forward는 서버 내부 이동이었다.
즉 같은 request/response를 들고 JSP로 넘기는 방식이었다.

redirect는 완전히 다르다.

redirect는 서버가 브라우저에게 “다른 곳으로 다시 요청하라”고 지시하는 방식이다

 

즉 redirect는 “서버 내부에서 처리 담당자를 바꾸는 것”이 아니라
“브라우저에게 새 요청을 유도하는 것”이다.

 

 

sendRedirect는 무엇을 하는가

컨트롤러에서 보통 이렇게 쓴다.

• response.sendRedirect("/todo/list")

이 한 줄의 의미는 다음이다.

• 서버는 응답을 만들 때 Location 헤더를 포함해서 보낸다
• 브라우저는 이 응답을 받으면 화면을 그대로 유지하지 않는다
• 주소창을 Location 값으로 바꾸고, 그 주소로 새 요청을 보낸다

즉 redirect는 1번 요청으로 끝나는 게 아니라
“추가 요청”이 자동으로 발생하는 구조이다.

 

 

redirect의 가장 중요한 특징: request가 끊긴다

forward와 redirect의 가장 큰 차이는 request의 연속성이다.

• forward: 같은 request/response 유지
• redirect: 브라우저가 새 요청을 보내므로 request/response가 새로 만들어짐

그래서 redirect 이후에는 컨트롤러에서 request.setAttribute()로 담아둔 값이 유지되지 않는다.

왜냐하면 그 값은 “이전 요청”의 request scope에 있던 것이고,
redirect는 “새 요청”을 발생시키기 때문이다.

즉 다음은 성립하지 않는다.

• POST 컨트롤러에서 req.setAttribute("msg","ok")
• redirect 이후 JSP에서 ${msg} 출력

이건 request가 끊겨서 값이 사라진다.

(redirect 후에도 값을 넘기려면 쿼리 스트링, 세션, flash scope 같은 전략이 필요하다)

 

 

redirect는 언제 쓰는가

redirect는 보통 “처리 작업” 이후에 많이 쓴다.

예를 들어 이런 것들이다.

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

이 패턴이 중요한 이유는 다음 글에서 다룰 PRG(Post-Redirect-Get)로 이어진다.

 

 

redirect는 브라우저 입장에서 어떤 일이 일어나는가

redirect 응답을 받으면 브라우저는 이렇게 행동한다.

1. 서버 응답에 Location이 있는지 확인한다
2. 주소창을 Location 값으로 바꾼다
3. Location으로 새 요청을 보낸다(보통 GET)
4. 새 응답을 받아서 화면을 만든다

그래서 redirect를 쓰면 사용자 입장에서는

• 주소창이 바뀐다
• 새로고침을 해도 “마지막이 GET”인 상태로 남기 쉬워진다

이 장점 때문에 처리 후 redirect가 자주 쓰인다.

 

 

핵심 정리

• forward는 서버 내부 이동이다(request 유지, URL 안 바뀜)
• redirect는 브라우저가 새 요청을 보내는 방식이다(request 끊김, URL 바뀜)
• sendRedirect는 Location 헤더로 브라우저를 다른 URL로 이동시킨다
• 처리(POST) 후에는 redirect가 자주 쓰이고, 이는 PRG 패턴으로 이어진다