Hacker News 의견

• 코드 리뷰 시 가능한 한 많은 상태(state) 를 URL에 저장하려고 함
  새로고침 후 완전히 다른 위치로 이동하거나, 공유한 URL이 엉뚱한 화면을 보여주는 건 사용자 입장에서 모욕적임
  이런 방식은 개발 속도를 늦추지만, 팀 내에서 UX 인식이 높아지고 뷰에 얼마나 많은 상태를 담는지 명확히 알 수 있음
  URL이 일종의 공개 API 가 되어 제약이 생긴다는 우려도 있지만, 대부분의 URL은 단기적으로만 사용되므로 큰 문제는 아니라고 생각함
  필요하다면 로드 시 이전 URL을 새 URL로 마이그레이션 하는 코드로 해결 가능함

  • 이 접근법이 마음에 들지만, 브라우저 히스토리 자동완성 때문에 원치 않는 상태가 불려오는 경우가 있음
    경로(path) 대신 쿼리 파라미터를 쓰면 좀 더 낫다고 생각함
  • 내가 쓰는 업무용 웹앱은 자체 “뒤로가기” 버튼을 만들어서 브라우저의 뒤로가기가 완전히 깨져 있음
    사용자 입장에서는 “뒤로가기”라는 단어가 브라우저 버튼과 연결되어 있어서 혼란스러움
    새로고침으로 상태가 초기화되는 건 덜 짜증남. “새로고침 = 처음부터 다시”라는 인식이 있기 때문임
  • 서버 렌더링 페이지라면 새로고침 시 스크롤 위치가 자동으로 복원됨
    JS로 모든 걸 처리하면 이런 기본 기능들이 미묘하게 깨짐
  • URL 설계는 UX 디자인의 일부라고 생각함
    하지만 지금까지 30명 넘는 UX 디자이너와 일했어도 URL에 대한 가이드를 받은 적이 없음
  • 웹이 발전하면서 새로고침의 의미가 상황마다 달라졌음
    특히 모바일에서는 페이지를 초기 상태로 되돌리기 어려워서 새로고침이 가장 빠른 해결책이 됨
    무한 스크롤이나 복잡한 필터 UI에서는 URL에 상태가 많을수록 초기화가 더 귀찮아짐
    이미 UX에 불만이 있는 상황에서 URL까지 정리해야 한다면 그건 사용자에게 이중 스트레스임

• 디지털 리터러시가 높은 사람들조차 URL과 DNS 이해도가 낮다고 느낌
  피싱 위험을 줄이고, URL 파라미터(?t=_, utm_)의 의미를 이해하며, 공유 전 개인정보를 제거할 수 있어야 함
  HTTPS 자물쇠가 ‘신뢰’를 의미하지 않는다는 점도 알아야 함

  • 하지만 브라우저가 기본적으로 URL을 숨기거나 축약하고, 기업들이 QR 코드나 검색어만 홍보하는 환경이라 교육이 어려움

• URL을 상태 컨테이너로 쓰면 내부 구조가 노출되고, 버전 관리가 필요해짐
  브라우저 간 호환성이나 인증 흐름에서도 문제가 생길 수 있음
  그래도 명령줄 인자처럼 가능한 많은 상태를 URL에 노출하려고 함
  다만 이는 의도적 트레이드오프로, 무지나 경험 부족 때문은 아님

• 오래된 라이브러리지만 여전히 유용한 Rison을 추천함
  JSON을 URL에 깔끔하게 저장할 수 있고, Elastic의 Kibana에서도 사용됨
  예시: http://example.com/service?query=q:'*',start:10,count:10

  • 이런 걸 찾고 있었음! 예전엔 직접 임시로 만들었는데, 이건 훨씬 표준적이고 정돈된 방식처럼 보임

• 시스템이 발전하면 상태 구조도 바뀌므로, URL에 상태를 넣으면 진화가 제약됨
  URL은 기본적으로 영구 문자열이기 때문임
  대신 URL을 일종의 프로토콜로 보고, 상태를 인코딩·디코딩하는 방식이 적절하다고 생각함
  단순한 페이지라면 전체 상태를 URL에 담는 것도 가능함

  • 유지 기간이 긴 콘텐츠(예: 블로그 포스트)는 URL 상태 보존이 유용함
    하지만 피드처럼 “새로고침 시 최신 상태로 돌아가야 하는가?” 같은 사용자 기대치에 따라 달라짐
  • 버전 관리를 도입하면 이런 문제를 완화할 수 있음

• URL 길이 제한은 브라우저·서버·CDN·검색엔진 설정에 따라 다르지만, 보통 2000자 이하임
  이 제한 안에서 얼마나 많은 상태를 담을 수 있을지, 혹은 다른 접근법이 필요할지 고민됨

  • 도메인을 제외한 각 문자는 66가지(대소문자, 숫자, 특수문자 - . _ ~)를 쓸 수 있으므로, 정보 밀도는 꽤 높음

• draw.io는 전체 상태를 URL에 저장해 공유할 수 있음
  다이어그램 데이터가 Base64로 인코딩되어 링크 하나로 완전한 복원이 가능함
  다만 이것이 ‘state container’ 정의에 부합하는지는 확신이 없음

• 나는 셀프호스팅 앱에서 hash routing (#/dashboard) 을 사용함
  서버 측 URL 재작성(.htaccess 등)이 필요 없어서, 완벽하진 않아도 배포 환경 제약을 줄일 수 있음

• 최신 Microsoft Teams는 모든 화면이 하나의 URL로 처리되어 북마크 불가임
  특정 팀이나 채널을 바로 열 수 없어서 매우 불편함

• HATEOAS는 이름이 별로라서 주목받지 못하지만, 결국 웹의 기본 개념임

  • 사용자 입장에서는 링크를 따라가고 폼을 제출하는 게 곧 HATEOAS임
    하지만 서버·클라이언트를 모두 제어하는 환경에서는 추가 복잡성만 생김
    특히 클라이언트가 여전히 엔드포인트 구조를 알아야 한다면 URL을 불투명하게 만들 뿐임
  • 이 주제는 사실 HATEOAS와 직접 관련이 없음. 둘 다 URL을 쓰긴 하지만, HATEOAS는 상태 저장이 아니라 탐색 구조에 관한 것임
  • 농담이지만, 결국 HATEOAS는 “시리얼화된 포맷(cerealization) ”이라는 말이 어울림