쿼리 스트링 논쟁: URL은 깔끔해야 할까?

URL에 쿼리 스트링을 사용하지 말아야 한다는 주장이 개발자 커뮤니티에서 다시 화두에 올랐다. 간결하고 예측 가능한 URL 구조가 SEO, 캐싱, 사용자 경험에 미치는 영향을 두고 다양한 의견이 오간다.

diff --summary

  • URL 쿼리 스트링 사용에 대한 개발자 커뮤니티의 논쟁이 재점화되었다.
  • 쿼리 스트링을 피해야 한다는 주장은 URL의 간결성, 예측 가능성, SEO, 캐싱 효율성 개선을 강조한다.
  • 쿼리 스트링은 특정 상태나 필터링 정보를 전달하는 데 유용하며, 모든 경우에 금지하기 어렵다는 반론도 있다.
  • 이 논쟁은 URL 설계의 철학과 실용성 사이의 균형을 찾는 문제로 이어진다.
  • 사용자 경험, 북마크 가능성, 그리고 개발 편의성 등 다양한 측면에서 고려할 필요가 있다.

URL에 쿼리 스트링을 쓰지 말아야 한다는 주장이 개발자 커뮤니티에서 다시 고개를 들고 있다. Chris Morgan이 쿼리 스트링을 금지했다는 글을 올리자, Susam Pal도 자신의 프로젝트에서 쿼리 스트링을 제거했다는 글을 이어 올렸다. 이쯤 되면 개발자라면 한 번쯤은 고민해 봤을 법한 묵은 논쟁이 또다시 수면 위로 떠오른 셈이다.

쿼리 스트링, 왜 문제인가?

쿼리 스트링을 피해야 한다고 주장하는 이들은 주로 다음과 같은 이유를 댄다.

  1. 깔끔함과 예측 가능성: example.com/products?category=books&sort=price 보다는 example.com/products/books/price가 훨씬 보기 좋고, URL만 봐도 어떤 리소스를 가리키는지 직관적으로 이해하기 쉽다는 것이다. 이는 사용자에게도, 개발자에게도 이점을 준다.
  2. SEO 친화적: 검색 엔진은 깔끔하고 의미 있는 URL을 선호한다. 쿼리 스트링이 많으면 크롤링 효율이 떨어지거나 중복 콘텐츠로 인식될 위험이 있다. 마치 책 제목에 부록 표시가 너무 많으면 본 내용이 가려지는 것과 비슷하다.
  3. 캐싱 효율: 쿼리 스트링은 보통 동적인 콘텐츠를 나타내기 때문에, 프록시 서버나 브라우저 캐싱에 불리할 수 있다. 같은 리소스여도 쿼리 스트링만 다르면 다른 페이지로 인식되어 캐싱이 어렵다는 이야기다.
  4. 북마크 용이성: 사용자가 특정 페이지를 북마크할 때, 길고 복잡한 쿼리 스트링이 덕지덕지 붙은 URL은 저장하기 불편하고 나중에 다시 접근하기도 어렵다.

물론 쿼리 스트링은 특정 상태를 전달하거나, 필터링, 검색어 등 유용한 정보를 담는 데 필수적일 때도 많다. 모든 경우에 쿼리 스트링을 금지하는 건 현실적으로 어렵다는 반론도 만만치 않다. 하지만 이 논쟁의 핵심은 결국 URL 설계의 철학에 닿아있다. 얼마나 깔끔하고 의미론적으로 설계할 것인가, 그리고 그 과정에서 얻는 이점과 잃는 실용성 사이의 균형을 어떻게 잡을 것인가 하는 문제다.

개발자 이름에 대한 오해와 URL의 이름

이 논쟁은 프로그래머가 이름에 대해 오해하는 것들 (2010)이라는 글과도 묘하게 연결된다. 사람에게는 ‘정확히 하나의 표준 이름’이 있다는 오해처럼, URL에도 ‘정확히 하나의 표준 형태’가 있어야 한다는 일종의 강박이 엿보이는 건 아닐까? 물론 사람 이름과 URL은 다르지만, 정보 시스템에서 ‘이름’을 부여하는 방식에 대한 깊은 고민이 필요하다는 점에서는 일맥상통한다.

결국, URL은 웹의 주소이자 자원을 식별하는 중요한 ‘이름’이다. 이 이름을 어떻게 짓고 관리할지는 단순히 기술적인 문제를 넘어, 웹의 접근성, 유지보수성, 그리고 장기적인 확장성에까지 영향을 미친다. 쿼리 스트링을 아예 없애는 건 현실적으로 어려울 수 있지만, 최소한의 정보만 담아 깔끔하게 유지하려는 노력은 계속되어야 할 과제임은 분명하다.

$ sources

  1. [1] 이름에 대한 프로그래머의 오해들 (2010)
  2. [2] 나는 당신의 URL에 쿼리 문자열을 추가하지 않겠다
  3. [3] I Will Not Add Query Strings to Your URLs
  4. [4] I’ve banned query strings