HTTP URL 경로에서 '//'를 멋대로 합치면 안 되는 이유

왜 이 얘기가 지금 나오는 걸까

웹 개발을 하다 보면 URL 경로에 슬래시가 두 개 연속으로 들어가는 경우를 종종 보게 돼요. 예를 들어 https://example.com//docs/page 같은 주소요. 많은 프레임워크나 프록시 서버, 그리고 어떤 개발자들은 이걸 보면 “아, 실수했네” 하면서 자동으로 /로 합쳐버리거든요. 그런데 이번에 runxiyu.org에 올라온 글은 이 '친절한 교정'이 사실은 HTTP 표준 관점에서 틀렸다는 얘기를 합니다.

언뜻 보면 사소해 보이는 주제인데요, 실제로는 URL 라우팅, 리디렉션, 캐싱, 심지어 보안 이슈까지 건드리는 꽤 중요한 이야기예요. 익숙하다고 넘어가기엔 영향 범위가 넓거든요.

URL 경로는 '파일 경로'가 아니에요

많은 사람이 URL 경로를 파일 시스템 경로와 비슷하게 생각해요. 리눅스 쉘에서 /var//log라고 쳐도 /var/log랑 똑같이 동작하니까요. 그런데 HTTP 명세(RFC 3986)를 따라가 보면 URL의 경로는 그냥 서버에게 전달되는 문자열 식별자일 뿐이에요. 서버가 그걸 파일로 해석할지, 라우팅 키로 쓸지, 아예 무시할지는 전적으로 서버 마음이거든요.

즉 /a/b와 /a//b는 의미적으로 다른 리소스일 수도 있다는 거예요. 경로 세그먼트 사이에 빈 세그먼트가 들어간 것이기 때문에, 이걸 마음대로 합쳐버리면 원래 개발자가 의도한 리소스와 다른 곳을 가리키게 될 수도 있어요.

뭐가 실제로 문제가 되는데요?

첫 번째는 라우팅 오작동이에요. 어떤 API는 빈 path 세그먼트를 의도적으로 사용해요. 예를 들어 /users//posts에서 가운데 빈 부분이 '현재 로그인한 사용자' 같은 컨텍스트 값을 나타내도록 설계한 경우가 있어요. 프록시가 이걸 /users/posts로 합쳐버리면 라우팅이 완전히 다른 핸들러로 가버리죠.

두 번째는 캐시 키 문제예요. CDN이나 리버스 프록시는 URL을 기준으로 캐시를 쌓는데, 어떤 레이어에서는 //를 합치고 어떤 레이어에서는 그대로 두면, 같은 요청인데 캐시 히트가 엇갈려요. 이게 쌓이면 디버깅이 정말 어려워지거든요.

세 번째이자 가장 무서운 건 보안 우회예요. 경로 기반 접근 제어를 하는 시스템에서, 인증 미들웨어는 /admin/을 검사하는데 뒤쪽 라우터는 //admin/도 /admin/으로 해석해버린다면, 검사를 건너뛰고 관리자 페이지에 접근되는 사고가 날 수 있어요. 실제로 과거 여러 WAF 우회 CVE가 이런 정규화 불일치(parser differential)에서 나왔어요.

그럼 어떻게 해야 하나요

원칙은 간단해요. 받은 URL 경로는 바이트 그대로 존중하라는 거죠. 서버가 리디렉트하거나 정규화할 거라면, 그건 애플리케이션 계층에서 의도적으로 선택하는 정책이어야지, 프록시나 라우터가 '착한 일'이랍시고 몰래 하면 안 돼요.

Nginx의 merge_slashes 옵션, Apache의 MergeSlashes, Go net/http의 CleanPath, Express의 strict routing 같은 설정이 전부 이 문제와 얽혀 있어요. 프록시와 애플리케이션 서버가 서로 다른 정책을 쓰고 있진 않은지 한 번쯤 점검해 볼 필요가 있어요. 특히 인증이나 권한 체크가 경로 문자열에 의존한다면 더더욱요.

한국 개발자에게 주는 시사점

국내에서도 Spring Security + Nginx 조합이나 API Gateway + Kubernetes Ingress 조합을 많이 쓰는데, 각 레이어의 경로 정규화 동작이 전부 다르다는 걸 의식하는 사람은 의외로 적어요. 특히 Spring Security 5에서도 관련 CVE가 여러 번 나왔었고요. 오늘 자기 서비스의 Nginx 설정에서 merge_slashes가 어떻게 돼 있는지, 백엔드가 빈 세그먼트를 어떻게 처리하는지 한 번 확인해 보는 것만으로도 숨어 있던 버그를 찾을 수 있을지 몰라요.