[MVC와 웹 흐름 제어] 6.PRG 패턴: POST 후에는 왜 redirect를 하는가

 

등록/수정/삭제 같은 기능을 만들면 보통 POST 요청을 사용한다.
문제는 “POST 처리 후에 무엇을 응답으로 보여줄 것인가”이다.

초보 단계에서는 이런 흐름을 만들기 쉽다.

• POST로 처리한다
• 처리 결과 화면을 바로 보여준다(HTML)

겉으로는 잘 동작한다.
하지만 브라우저의 “새로고침” 동작 때문에 구조적인 문제가 생긴다.

 

 

PRG가 없으면 발생하는 문제: POST 재전송

POST 처리 후에 결과 화면을 바로 응답하면,
브라우저 입장에서는 “현재 화면을 만든 마지막 요청”이 POST가 된다.

이 상태에서 사용자가 새로고침(F5)을 하면 브라우저는 보통 이렇게 행동한다.

• 마지막 요청이 POST였다
• 그 POST를 다시 보내서 현재 화면을 다시 만들려고 한다
• 그래서 “POST 재전송” 경고가 뜬다

이게 단순히 경고로 끝나면 괜찮은데, 실전에서는 문제가 된다.

• 게시글이 중복 등록될 수 있다
• 주문이 중복으로 생성될 수 있다
• 결제가 중복으로 시도될 수 있다

즉 “새로고침”이 치명적인 부작용을 만들 수 있다.

 

 

PRG는 이 문제를 구조로 해결한다

PRG는 Post-Redirect-Get의 약자이다.

흐름은 단순하다.

1. 사용자는 POST로 처리를 요청한다
2. 서버는 처리를 완료한 뒤 “다른 URL로 이동하라”는 redirect 응답을 보낸다
3. 브라우저는 redirect를 따라 GET 요청을 새로 보낸다
4. 최종 화면은 GET 응답으로 만들어진다

즉 화면을 결정하는 마지막 요청이 POST가 아니라 GET이 되게 만든다.

 

 

PRG의 핵심 효과: 새로고침이 안전해진다

PRG를 적용하면 마지막 화면은 GET의 결과이다.
그래서 사용자가 새로고침을 해도 GET이 다시 실행될 뿐이다.

• GET은 조회 성격이므로 부작용이 적다
• 중복 등록/중복 결제 같은 위험을 크게 줄인다

즉 PRG는 “새로고침에 안전한 흐름”을 만드는 패턴이다.

 

 

코드로 보면 차이가 더 명확하다

나쁜 흐름(POST 후 결과 화면을 바로 보여줌)

• POST 처리 후 forward로 JSP 결과 화면을 응답
• 마지막 요청이 POST가 되어서 새로고침 위험

좋은 흐름(PRG)

• POST 처리 후 sendRedirect로 목록/상세 같은 GET URL로 이동
• 마지막 요청이 GET이 되어서 새로고침이 안전

이게 실무에서 “POST 처리 후 redirect”가 기본이 되는 이유이다.

 

 

정리

• POST 응답으로 바로 화면을 만들면 새로고침 시 POST 재전송이 발생할 수 있다
• PRG는 POST 이후 redirect를 통해 마지막 화면을 GET으로 만든다
• PRG를 쓰면 새로고침이 안전해지고 중복 처리 위험이 줄어든다
• 그래서 등록/수정/삭제 같은 처리는 보통 PRG로 구성한다