Well-Known URI를 언제 사용해야 하고 언제 피해야 하는지, 그리고 설계 시 고려해야 할 함정과 절충점을 정리합니다.
Friday, 19 June 2026
Well-Known URI specification의 저자 가운데 한 명이자 현재 registry의 Designated Expert로서, 저는 이것들을 어떻게 사용해야 하는지에 관한 질문을 많이 받으며, 많은 분들에게 이를 가장 잘 활용하는 방법을 안내하게 됩니다. 아래에는 제가 이것들을 어떻게 생각하는지 요약해 두었습니다. 이것들이 등록을 위한 모든 요구사항은 아니라는 점에 유의하세요. 그저 제가 좋은 관행이라고 생각하는 내용입니다.
Well-Known 위치는 클라이언트가 브라우저, 봇, 또는 다른 소프트웨어이든 간에 사이트1를 알고 있고, 그 전체 사이트에 대해 무언가를 효율적인 방식으로 발견해야 할 때 가장 잘 작동합니다.
robots.txt는 완벽한 예시입니다. 이것은 RFC보다 먼저 나왔기 때문에 well-known 위치를 사용하지 않지만, 우리가 그것들을 위해 공간을 예약한 주된 이유 가운데 하나였습니다. 크롤러는 사이트의 접근 정책이 무엇인지 알아야 하고, 그것을 사이트를 위한 하나의 중앙 위치에 두면 모든 응답에서 헤더와 콘텐츠를 확인할 필요가 없어집니다. 그렇게 하면 그러한 정책을 두는 목적의 상당 부분이 무력화될 것이기 때문입니다.
하지만 well-known 위치가 반드시 정책을 담아야 하는 것은 아닙니다. 클라이언트가 이미 사이트를 알고 있지만 사이트 전체에 대해 무언가를 알아내거나 그것과 상호작용해야 하는 모든 메커니즘은 well-known 위치가 될 후보입니다. 예를 들어 change-password well-known 위치는 클라이언트가 사이트에서 자신의 비밀번호를 변경할 수 있게 해줍니다.
Well-known 위치가 일부 프로토콜의 실제 문제를 해결해 주기는 하지만, 다른 경우에는 설계자들이 그렇게 하는 것이 맞아 보인다는 이유로 well-known 위치를 명시하는 듯 보입니다. 어떤 제안은 그것이 정당성을 부여하거나 채택을 높여줄 것이라고 기대하며 등록합니다. 마치 레지스트리의 한 자리가 자격 증명인 것처럼 말입니다. 그렇지 않습니다. Well-known 위치는 특정한 문제를 해결합니다. 즉, 클라이언트가 사이트를 알고 있고 사이트 전반에 걸친 무언가가 필요하다는 문제입니다. 여러분의 프로토콜에 그런 문제가 없다면, 등록은 새로운 문제만 만들 수 있고, 기대하는 채택도 가져오지 못할 것입니다.
비슷하게, well-known 위치에 대한 일부 제안은 사실상 그것들을 URL 단축기처럼 사용합니다. 프로토콜에서 전체 URL을 전달하는 대신 관련 사이트만 전달하면 되고, 나머지는 well-known 위치가 채우는 식입니다.
문제는 이 패턴이 서비스와 사이트 사이를 1:1 관계에 묶어 둔다는 것입니다. 배포 환경이 언젠가 둘 이상의 서비스를 필요로 하게 되면, 다른 사이트를 만들어야 하고, 사용자를 적절한 사이트로 안내할 방법도 찾아야 합니다.
여러분의 프로토콜이 진정으로 호스트명만 실어 나를 수 있다면 well-known 위치를 사용하는 것은 타당합니다. 하지만 종종 그것은 단지 편의 때문에, 어쩌면 프로토콜을 더 “공식적”으로 보이게 하기 위해 이루어지며, 그 결과 배포에 불필요한 경직성을 초래합니다. 여러분의 프로토콜이 실제 URL을 사용할 수 있다면, well-known 위치에 굳이 신경 쓰지 마세요.
well-known 위치가 올바른 도구일 때조차도, 우리가 사이트에 대해 하는 가정이 항상 사실인 것은 아니며, 상당한 복잡성을 만들어낼 수 있습니다. 여러분이 자신의 프로토콜을 위해 well-known 위치를 정의하고 있다면, 아래의 문제들을 알고 있어야 합니다.
많은 프로토콜이 well-known 위치를 발견 메커니즘으로 사용하려고 하며, 그 발상은 “사용자는 이미 사이트를 알고 있다”는 것입니다.
문제는 현실이 처음 들리는 것보다 더 모호하다는 점입니다. 즉, 사용자의 현재 상호작용 범위와 발견이 일어나는 위치 사이에 불일치가 있을 수 있습니다. 예를 들어, 클라이언트가 “login.example.com”으로 시작한다면, 그 사이트에서 well-known 위치를 조회해야 할까요, 아니면 “example.com”에서 해야 할까요? 한쪽에서 다른 쪽으로의 리다이렉트를 따라가야 할까요? 상호운용성을 보장하려면 발행자는 어떤 사이트에 well-known 위치를 제공해야 할까요?
이 점은 특히 프로토콜이 실제로는 Web 사이트에 관한 것이 아니라, 단지 다른 일을 해내기 위해 HTTP를 활용하고 있을 뿐인 경우에 중요합니다. 예를 들어, 등록 가능한 도메인 이름에 대한 well-known 위치를 apex에 두도록 명시하고 싶을 수 있지만, 이는 일부에게 운영상 어려울 수 있습니다.
여러분의 프로토콜이 이 범주에 속한다면, 무엇이 발견되고 있는지와 사용자가 무엇으로 시작하는지를 모두 고려한 뒤, 그들의 아키텍처에 대해 너무 많은 것을 가정하지 않고도 올바른 호스트명을 신뢰성 있게 찾는 방법을 설계하세요.
일부 프로토콜은 well-known 위치를 사이트의 콘텐츠에 대해 알아내는 방법으로 사용하려 합니다. 결국 /robots.txt가 그렇게 동작하니까요.
그 패턴이 일부 종류의 메타데이터에는 작동하지만, 많은 사이트는 여러 발행자를 대표합니다. 예를 들어 오래된 /~username/ 관례가 있습니다. 콘텐츠 메타데이터를 중앙 위치에 두면, 그런 사용자들은 그 메커니즘을 사용할 수 없게 되거나, 아니면 관리자가 그것에 대한 사용자들의 통제를 지원하고 감독하기 위한 복잡한 인프라를 개발해야 합니다.
이러한 종류의 배포는 편의성과 세분성 사이의 절충점을 드러내며, 종종 병렬적인 메타데이터 메커니즘의 생성을 필요로 합니다. 예를 들어 HTTP 응답 헤더나 콘텐츠 자체 안의 메커니즘이 그렇고, 이와 함께 서로 다른 메타데이터 부착 메커니즘을 합리화하는 작업도 필요합니다.
그렇다고 Well-Known 위치를 콘텐츠 메타데이터에 사용할 수 없다는 뜻은 아닙니다. 다만 여러분이 생각하는 것보다 훨씬 일이 많다는 뜻입니다. 따라서 여러분의 프로토콜이 리소스 메타데이터를 위해 well-known 위치를 사용하고 있다면, 이러한 절충점을 반드시 신중하게 고려하세요. 모든 사이트가 여러분이 익숙한 사이트와 같은 것은 아닙니다. Web은 매우 큰 공간입니다.
그 밖에도 자주 나오는 몇 가지가 있습니다.
첫째, 일부 제안은 이미 루트에 고정된 위치를 정의해 두었습니다. (/robots.txt처럼, 대개는 나중에야 Well-Known 위치를 알게 되었기 때문입니다.) 그렇다면 기존 배포를 위한 전환 계획이 있어야 합니다. 일반적으로 제안자들은 현재의 배포 규모에 지나치게 집중합니다. 합리적인 시간 동안의 좋은 전환 계획이 있다면, Well-known 위치로 옮기는 일은 관리 가능합니다.
많은 제안은 http와 https URL을 암묵적으로 가정합니다. Well-known 위치는 다른 URL 스킴에도 적용되므로, 관련 스킴을 명시적으로 열거해야 합니다.
마지막으로, 반드시 여러분의 well-known 위치를 등록하세요. 그 링크에는 언제 등록해야 하는지와 이름을 어떻게 선택해야 하는지에 관한 안내가 있습니다. 여기의 조언과는 달리, 그것은 성공적으로 등록될 가능성에 실제로 영향을 줍니다.
(scheme, host, port)의 튜플입니다.↩