[TIL] 동일 페이지 navigation클릭 시 새로고침 여부 결정

[sgoldenbird]

📌 배운 내용

• 동일 경로의 내비게이션 클릭 시 새로고침이 발생하는 UX는 사용자의 수동 갱신 의도를 반영한 흔한 패턴이다.
• 하지만 새로고침으로 인해 전체 데이터 로딩이 느릴 경우 오히려 사용자 경험이 저하될 수 있다.
• 새로고침 대신 리렌더 수준에서 데이터를 다시 불러오는 방식도 고려할 수 있다.

---

🔍 배경 / 문제 상황

동일 페이지 navigation 클릭 시 현재 페이지가 새로고침되도록 구현해두었습니다.
개인적으로는 네이버 등 주요 웹사이트에서도 동일한 UX를 자주 경험해 익숙했고,
사용자 입장에서도 명확한 갱신 의도를 가지고 클릭하는 경우가 많아 자연스럽다고 생각했습니다.
하지만 팀원 중 지섭님이 이 방식에 대해 의견을 제시했습니다.
데이터를 다시 불러오는 동안 느려지기 때문에, 굳이 새로고침을 유도할 필요가 없다는 의견이었습니다.

---

✅ 핵심 정리 / 해결 방법

• 서버 에러로 인해 속도가 느린 건 프론트 쪽에서 당장 해결할 수 없는 문제였습니다.
• 그렇다고 해서 새로고침을 없애면 UX가 더 모호해지고 사용자에게 오히려 불친절할 수 있었습니다.
• 사용자가 직접 '갱신' 의도를 가지고 클릭하는 상황이라면, 새로고침이 가장 직관적이고 명확한 방법이었습니다.
• 따라서 느린 로딩을 감수하고서라도, 새로고침이라는 행동을 보장해주는 쪽을 선택했습니다.

---

🧠 느낀점 또는 생각 메모

"사용자에게 익숙한가?"와 "지금 서비스에 적절한가?"는 별개 문제라는 점을 명확히 느꼈습니다.
단순히 익숙하다는 이유만으로 UX 방식을 결정해서는 안 되고,
현재 서비스의 성능과 상황 맥락에 따라 적절한 설계 판단이 필요하다는 것을 배웠습니다.
동일 페이지를 다시 클릭했을 때 새로고침하는 UX는 분명 사용자에게 익숙한 행동일 수 있습니다.
하지만 성능이나 데이터 로딩 속도를 고려했을 때는,
필요에 따라 리렌더 수준의 리페치로 대체하는 선택도 가능해야 한다는 점을 알게 되었습니다.
사용자의 행동 의도를 파악하는 것도 중요하지만, 현재 시스템이 감당할 수 있는 한계 역시 함께 고려해야 한다는 것을 느꼈습니다.

또한 프론트엔드에서는 항상 "빠르게 보여주는 것"만이 목표가 아니라,
사용자가 하는 행동의 의미를 정확히 이어주는 것 역시 중요하다는 사실을 다시 깨달았습니다.
성능 이슈가 있다고 해서 사용자 흐름 자체를 바꿔버리는 것은 오히려 혼란을 줄 수 있으며, 외부 요인(예: 서버 지연 등)이 있을 때는
"성능 최적화"와 "행동 의도 전달" 중 어떤 가치를 우선할지 명확히 판단하는 습관이 필요하다고 느꼈습니다.

---