history.back() 대신 뭘 써야 할까? 웹앱에서의 뒤로 가기 정리

웹에서 뒤로 가기 버튼을 만들다 보면 가장 먼저 떠오르는 코드가 있습니다.

history.back();

 

짧고, 간단하고, 눈에 띄게 문제없어 보입니다.
저도 한동안은 아무 생각 없이 이 코드를 썼습니다.

 

그런데 웹앱 형태로 화면이 점점 복잡해지고,
Ajax나 로그인 흐름이 섞이기 시작하면서 문제가 하나씩 튀어나오기 시작했습니다.

---

history.back()은 “이전 페이지”가 아닙니다

처음엔 저도 이렇게 생각했습니다.

“그냥 이전 페이지로 가는 거 아닌가?”

 

하지만 실제로는 조금 다릅니다.
history.back()은 URL이 아니라 브라우저의 히스토리 상태로 이동합니다.

 

즉, 페이지를 다시 불러오는 게 아니라
브라우저가 기억하고 있던 화면 상태를 그대로 꺼내오는 경우가 많습니다.

이 차이가 웹앱에서는 꽤 큰 문제로 이어집니다.

---

페이지가 돌아왔는데, 자바스크립트가 안 돕니다.

가장 먼저 겪었던 문제는 이거였습니다.

$(function(){
  console.log("페이지 초기화");
});

 

뒤로 가기를 했는데,
이 코드가 다시 실행되지 않는 겁니다.

 

처음엔 “내가 뭘 잘못 썼나?” 싶었는데
알고 보니 브라우저가 페이지를 새로 로드하지 않고 캐시된 상태로 복원하고 있었습니다.

결과적으로 이런 일이 벌어집니다.

• 이벤트가 다시 안 걸림
• Ajax 호출이 안 됨
• 폼 값이 이전 상태 그대로 남아 있음

화면은 돌아왔는데, 뭔가 반쯤 죽어 있는 느낌.
운영 화면에서는 꽤 치명적입니다.

---

Ajax 화면에서는 더 헷갈립니다

웹앱 화면 흐름은 보통 이렇습니다.

목록 → 클릭 → Ajax로 상세 로딩 → 상세 화면

 

여기서 history.back()을 쓰면, 목록 화면은 돌아오지만

데이터는 새로 안 불러오고 예전에 보던 상태 그대로 남아 있습니다.

 

사용자 입장에서는 “왜 화면이 이상하지?”가 됩니다.

---

모바일 웹에서는 더 위험합니다

모바일에서 특히 많이 겪었습니다.

 

뒤로 가기 버튼을 눌렀는데…

앱이 그냥 꺼져버립니다.

 

우리 서비스의 이전 화면이 아니라
외부 앱으로 돌아가거나 빈 화면이 되는 거죠.

 

사용자는 오류라고 생각합니다.
설명할 방법도 없습니다.

---

그래서 저는 이렇게 처리합니다

지금은 뒤로 가기 버튼을 이렇게 만들고 있습니다.

location.href = "/project/page";

 

단순해 보이지만,

페이지가 확실히 새로 로드되고 자바스크립트 초기화가 보장되고

화면 흐름이 예측 가능합니다

 

뒤로 가기처럼 보이게 만들되,
실제로는 어디로 갈지 개발자가 정해주는 방식입니다.

---

정리하면 이렇습니다

history.back()은 편합니다.
하지만 웹앱에서는 너무 많은 걸 브라우저에게 맡기게 됩니다.

 

정적 페이지라면 큰 문제가 없을 수도 있지만,
로그인, 관리자 화면, Ajax가 섞인 화면이라면 가능하면 피하는 게 낫다고 생각합니다.

 

뒤로 가기 버튼은 UX 요소이지,

브라우저 히스토리를 그대로 믿고 처리할 문제는 아니었습니다.