IPv6 존, URL에서 왜 문제가 될까?
IPv6 인터페이스 스코프(Scope) ID, 즉 존(Zone) 표기가 URL에서 파싱 오류를 유발함
`%` 문자를 URL 인코딩해야 하는 기술적 우회(Workaround)가 필요하며, 이는 표준화 부재에서 기인함
RFC 6874는 존 ID를 지원하나, URL 표준 및 Go `net/url` 라이브러리는 이를 직접적으로 지원하지 않음
브라우저의 'Origin' 개념과의 충돌로 IPv6 존 지원이 제한적이며, 향후 개선이 필요함
IPv6 존(Zone) ID와 URL 파싱 충돌
IPv6 환경에서 여러 네트워크 인터페이스를 가진 호스트는 존(Zone) ID를 사용하여 주소 충돌을 해결합니다. 예를 들어 `fe80::4%eth0`와 같이 인터페이스 이름을 포함하는데, 이 `%` 문자가 URL 파싱 시 예약 문자로 간주되어 오류를 발생시킵니다. Go의 `net/url` 라이브러리는 이러한 존 ID를 직접적으로 해석하지 못해, 개발자는 `%`를 `%25`로 이중 인코딩하는 기술적 우회(Workaround)를 적용해야 합니다. 이는 RFC 6874의 `IPv6addrz` 정의와는 상반되는 동작입니다.
RFC 6874와 브라우저 'Origin' 개념의 괴리
RFC 6874는 `IPv6address%ZoneID` 형식을 정의하며 `ZoneID` 내 `%`를 `%25`로 인코딩하도록 명시하고 있습니다. 하지만 웹 브라우저들은 보안상의 이유로 'Origin' 개념을 엄격하게 적용하며, IPv6 존 ID를 포함한 URL을 표준적으로 지원하지 않습니다. 이는 웹 애플리케이션에서 IPv6 존 주소를 직접 사용하는 데 상당한 제약(Significant Limitations)을 야기하며, RFC 9844 초안이 이를 해결하려 시도하고 있습니다.
프로그래밍 언어 및 라이브러리의 비표준적 처리
Go의 `net/url` 라이브러리뿐만 아니라, 다른 프로그래밍 언어와 프레임워크에서도 IPv6 존 ID를 URL에 포함할 때 유사한 파싱 문제를 겪는 것으로 보입니다. 이는 IPv6 존 ID가 URL 스키마의 주요 사용 사례(Primary Use Case)가 아니기 때문에 발생하는 문제입니다. 결과적으로 개발자는 특정 환경에 맞춰 맞춤형 파싱 로직(Custom Parsing Logic)을 구현하거나, 표준 라이브러리의 한계를 인지하고 우회책을 사용해야 하는 상황입니다.
개발자 경험(DX) 저하와 향후 전망
IPv6 존 ID를 URL에 포함시키기 위해 `%`를 `%25`로 인코딩하는 방식은 개발자 경험(Developer Experience) 측면에서 매우 좋지 않은 UX(Terrible UX)를 제공합니다. 이는 복잡성을 증가시키고 잠재적인 버그를 유발할 수 있습니다. 저자는 Go 표준 라이브러리를 포크(Fork)하지 않는 정책을 유지하며 이 문제를 감수하고 있지만, 장기적으로는 URL 표준 또는 관련 라이브러리의 개선을 통해 더 나은 해결책(Better Option)이 마련되기를 기대하고 있습니다.
