Well-Known URI를 정의하고 싶다면

 (mnot.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 클라이언트가 이미 사이트를 알고 있고 사이트 전체의 정보를 효율적으로 찾아야 할 때 Well-Known URI가 가장 잘 맞음
  • robots.txt처럼 중앙 위치에 정책을 두면 반복 확인을 줄일 수 있지만, change-password처럼 사이트 전체 상호작용을 여는 용도로도 쓰일 수 있음
  • 실제 URL을 전달할 수 있는 프로토콜이 Well-Known URI를 쓰면 서비스와 사이트가 1:1로 묶여 배포와 라우팅이 경직됨
  • 발견 메커니즘이나 콘텐츠 메타데이터에 적용할 때는 시작 호스트명, 검색 위치, 리다이렉트, 다중 게시자 사이트 같은 운영 구조를 먼저 따져야 함
  • 기존 루트 고정 경로에서 옮기려면 전환 계획이 필요하고, http·https 외 스킴까지 명시해야 등록 성공 가능성이 높아짐

Well-Known URI가 잘 맞는 상황

  • Well-Known URI specification의 저자 중 한 명이자 registry의 Designated Expert인 Mark Nottingham은 Well-Known URI를 언제 쓰면 좋은지 실무 기준을 공유함
  • 이 기준은 모두 등록 요건은 아니며, 좋은 관행에 가까움
  • Well-Known 위치는 클라이언트가 이미 사이트를 알고 있고, 그 사이트 전체에 대해 무언가를 발견하거나 상호작용해야 할 때 적합함
    • 여기서 사이트는 기술적으로 (scheme, host, port) 튜플인 origin을 뜻함
  • robots.txt는 RFC보다 먼저 존재했지만, Well-Known 공간을 예약하게 된 주요 이유 중 하나였음
    • 크롤러는 사이트의 접근 정책을 알아야 함
    • 중앙 위치에 정책을 두면 모든 응답마다 헤더와 콘텐츠를 확인하지 않아도 됨
  • Well-Known 위치가 반드시 정책만 담아야 하는 것은 아님
    • 클라이언트가 사이트를 이미 알고 있고 사이트 전체에 대해 학습하거나 상호작용해야 하는 메커니즘이면 후보가 될 수 있음
    • change-password Well-Known 위치는 클라이언트가 사이트의 비밀번호를 변경할 수 있게 함

잘못된 도구가 되는 경우

  • 일부 설계는 실제 문제 때문이 아니라 그렇게 해야 할 것처럼 보여서 Well-Known 위치를 지정함
  • 등록 공간에 항목이 생긴다고 해서 정당성이나 채택률이 따라오지는 않음
    • Well-Known 위치는 “클라이언트가 사이트를 알고 있고, 사이트 전체에 필요한 것이 있다”는 특정 문제를 해결함
    • 프로토콜에 그런 문제가 없다면 등록은 새 문제를 만들 수 있고, 기대한 채택으로 이어지지 않음
  • 어떤 제안은 Well-Known 위치를 사실상 URL 단축기처럼 사용함
    • 프로토콜에서 전체 URL을 전달하지 않고 관련 사이트만 전달함
    • Well-Known 위치가 나머지 경로를 채움
  • 이 패턴은 서비스와 사이트를 1:1 관계로 고정함
    • 배포가 여러 서비스를 필요로 하면 다른 사이트를 만들어야 함
    • 사용자를 적절한 사이트로 보내는 별도 방법도 필요해짐
  • 프로토콜이 정말 호스트명만 전달할 수 있다면 Well-Known 위치 사용이 타당할 수 있음
  • 실제 URL을 사용할 수 있다면 굳이 Well-Known 위치를 쓰지 않는 편이 낫고, 편의나 공식적인 느낌 때문에 선택하면 배포가 불필요하게 경직됨

발견 메커니즘에서 생기는 함정

  • 많은 프로토콜은 “사용자가 이미 사이트를 안다”는 전제로 Well-Known 위치를 발견 메커니즘에 사용하려 함
  • 실제로는 사용자의 현재 상호작용 범위와 발견이 일어나는 위치가 어긋날 수 있음
    • 클라이언트가 login.example.com에서 시작했다면 Well-Known 위치를 그 사이트에서 찾아야 하는지, example.com에서 찾아야 하는지 문제가 됨
    • 한쪽에서 다른 쪽으로의 리다이렉트를 따라야 하는지도 정해야 함
    • 게시자는 상호운용성을 보장하기 위해 어떤 사이트에 Well-Known 위치를 제공해야 하는지도 불명확할 수 있음
  • 이 문제는 프로토콜이 실제 웹사이트 자체를 다루지 않고, HTTP를 다른 목적에 활용할 때 특히 중요함
  • 등록 가능한 도메인 이름의 Well-Known 위치를 apex에 두도록 지정하고 싶을 수 있지만, 일부 환경에서는 운영상 어려울 수 있음
  • 이런 범주의 프로토콜은 무엇을 발견하는지와 사용자가 어디서 시작하는지를 함께 고려해야 함
    • 웹 아키텍처에 대해 과도하게 가정하지 않고 올바른 호스트명을 안정적으로 찾는 방법을 정해야 함

콘텐츠 메타데이터에 쓸 때의 절충

  • 일부 프로토콜은 사이트 콘텐츠를 학습하기 위해 Well-Known 위치를 사용하려 함
  • /robots.txt가 이런 방식으로 동작하지만, 이 패턴이 모든 콘텐츠 메타데이터에 쉽게 맞지는 않음
  • 많은 사이트는 여러 게시자를 대표함
    • 예로 과거의 /~username/ 관례가 있음
  • 중앙 위치에 콘텐츠 메타데이터를 두면 두 가지 문제가 생김
    • 해당 메커니즘이 개별 사용자에게 사실상 사용 불가능해질 수 있음
    • 관리자가 사용자의 제어를 지원하고 감독하기 위한 복잡한 인프라를 만들어야 할 수 있음
  • 이런 배포는 편의성과 세분성 사이의 절충을 드러냄
    • HTTP 응답 헤더나 콘텐츠 자체에 병렬 메타데이터 메커니즘을 만들 필요가 생길 수 있음
    • 서로 다른 메타데이터 부착 방식도 정리해야 함
  • 콘텐츠 메타데이터에 Well-Known 위치를 못 쓰는 것은 아니지만, 예상보다 훨씬 많은 작업이 필요할 수 있음
  • 리소스 메타데이터에 Well-Known 위치를 쓰는 프로토콜은 웹의 다양한 사이트 구조를 고려해야 함

등록과 전환 시 고려할 점

  • 이미 루트의 고정 위치를 정의한 제안도 있음
    • /robots.txt처럼 Well-Known 위치를 나중에 알게 된 경우가 해당함
  • 이런 경우 기존 배포를 위한 전환 계획이 필요함
    • 제안자는 현재 배포 기반에 과도하게 집중하는 경향이 있음
    • 합리적인 기간 동안 좋은 전환 계획을 두면 Well-Known 위치로의 이동을 관리할 수 있음
  • 많은 제안은 http와 https URL을 암묵적으로 가정함
  • Well-Known 위치는 다른 URL 스킴에도 적용되므로, 관련 스킴을 명시적으로 열거해야 함
  • Well-Known 위치는 등록해야 함
    • 해당 링크에는 언제 등록해야 하는지와 이름을 고르는 방법에 대한 지침이 있음
    • 이 등록 지침은 앞선 조언과 달리 실제 등록 성공 가능성에 영향을 줌

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 새 표준을 루트 네임스페이스에 계속 만들지 말고 이런 방식을 따랐으면 함. 예를 들어 llms.txt가 떠오름
    도메인 루트를 더럽히는 일은 이제 그만했으면 좋겠음
    https://llmstxt.org/

    • LLMs.txt는 주요 AI 업체들이 채택하지 않았으니 그 자체로도 별 의미가 없어 보임

  • 동의하지 않음. 이 글은 어차피 별 도움이 안 됨. 내용이 거의 없고 뻔한 사실만 말하는 느낌임
    실제 권고로 이어지는 예시가 없다면, 저자가 내세우는 전문성도 쓸모가 크지 않음

    • 저자는 예전에 NodeJS에서 HTTP 418 "I'm a teapot" 지원을 제거하려 했고, 그 결과 반발이 생기면서 Python이 오히려 지원을 추가한 전력이 있음
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • 너무 harsh함. 저자는 실제로 well-known 경로를 등록하고 싶어 하는 사람들에게 질문을 받았을 가능성이 높고, 그중 일부는 ~user 경로 같은 사이트 구조를 고려하지 못했을 수 있음
      이 글이 그런 사람들에게 더 나은 해법을 쓰게 만들 수도 있음. 그래도 well-known URL이 필요하다고 확신하면 등록 절차 링크도 제공하고 있음
    • 글의 핵심은 robots.txt 같은 것을 추가해야 한다면 그냥 임의로 두지 말고, 어디에 있는지 알려야 한다는 데 있음

  • 왜 이렇게 구체적인지 모르겠음. password-reset 대신 더 범용적인 링크 트리를 두면 안 되나?
    Discord 도메인 검증도 domain-verifications 아래에 동적 목록을 두는 방식이면 될 텐데, 시간 낭비처럼 보임. 내 용도라면 well-known 바깥에 자체 명세를 정의할 것 같음

    • 자체 명세를 만들면 다른 사람이 쓰지 않음
      password-reset well-known 엔드포인트는 비밀번호 관리자가 UI에 "Change password..." 버튼을 보여주고, 그 well-known 파일에 적힌 비밀번호 변경 페이지로 바로 연결하는 데 쓰임
    • discord domain verification은 TXT 레코드 자체가 이미 동적 항목 목록이라서 별도 구조보다 단순함
      목록을 순회하면서 각 값의 시작 부분을 검색 문자열과 비교해 discord domain verification을 찾는 편이 훨씬 쉽다는 뜻임
      예를 들면 ycombinator.com의 TXT 레코드에는 openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=..., rippling-domain-verification=... 같은 값들이 함께 들어 있음
    • discord domain verification은 Discord 쪽 문제임. IANA 레지스트리에는 없음: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      password-reset을 더 범용적인 링크 트리로 만들자는 부분은 형제 스레드에서 더 자세히 답해 둠: https://news.ycombinator.com/item?id=48596286

  • .well-known, DNS 레코드, DNS over HTTP 중 어떤 방식이든 도메인에 고정된 신뢰를 바탕으로 자율적으로 발견 가능하게 만드는 건 중요하다고 봄
    Cloudflare는 이미 이 영역의 관측 가능성을 제품에 꽤 추가한 것 같고, 나도 조사 중임: https://instagrate-me.sudoscience.dev/
    에이전트형 활용이 늘수록 이런 것을 필요로 하는 서비스 수와 조직당 필요한 양이 모두 늘어날 듯함. auth.md도 .well-known을 쓰는 최근 예로 보임

  • “이 웹사이트는 안전하게 동작하려면 더 현대적인 브라우저가 필요합니다. 브라우저를 업그레이드하세요.”
    대안으로는 SNI 없이도 가능함
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • SNI는 좋은 것 아닌가? 어떤 상황에서 문제가 되는지 궁금함
    • 웹 사용자를 감시하거나 검열하는 입장이라면 SNI는 좋지 않음
      그래서 아주 좋음

  • change-password 레지스트리가 실제로 쓰이긴 하나? 봇조차 쓰는지 모르겠음
    내 사이트들에서는 봇이 .well-known/change-password URL을 확인하는 걸 본 적이 없음. 공개 설정을 둘 장소로는 괜찮지만, 발견 수단으로는 아닌 것 같음

    • Chrome 같은 일부 비밀번호 관리자는 비밀번호가 유출됐을 때 UI에 "change password" 버튼을 보여줌
      이 기능이 .well-known/change-password를 기반으로 함

  • .well-known은 처음엔 깔끔하게 시작했지만 조용히 웹 루트의 잡동사니 서랍이 됐음. security.txt, ACME, app-site-association 등 계속 늘어나는 중임

    • 무슨 뜻인지 모르겠음. 애초에 잡동사니 서랍으로 설계된 것임
    • 흩어진 잡동사니보다는 잡동사니 서랍이 낫음
    • 그게 목적 아닌가? 잡동사니를 부엌 조리대 위에 흩어놓는 대신, 잡동사니라고 라벨 붙은 서랍에 넣어두는 것임

  • 한 도메인에 well-known 항목이 여러 개 있을 수 있다는 점은 자주 간과되는 것 같음

  • 제목은 URI라고 되어 있지만 글은 URI의 한 종류인 URL만 다루고 있음

  • 그런데 그 URI들이 정말 얼마나 well-known한 건가? :-\

    • 글, RFC, Wikipedia, Google을 10분 동안 뒤져서 .well-known 예시를 찾으려 했지만 하나도 못 찾았음
      GitHub OIDC 작업을 하면서 예전에 하나 읽은 적은 있고, 그때는 꽤 유용했음
      기술 문서는 왜 그렇게 많은 말로 개념을 깊게 설명하면서도 예시는 하나도 안 주는지 모르겠음. 이런 경우가 처음도 아님
    • 여기 레지스트리에 모여 있음: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • Wikipedia에 흥미로운 목록이 있음: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • 동의함. 좋은 예시 몇 개를 기대했는데 보이지 않았음. 내가 아는 유일한 예는 OIDC discovery endpoint임
    • Linux 대상 소프트웨어 개발자들 사이의 XDG 디렉터리보다도 덜 알려진 것 같음
      진지하게 말하면 이름이 모순적임. /index.html은 말 그대로 잘 알려진 URL이고 대부분의 웹 개발자가 알고 있음. 하지만 미리 정의된 의미를 가진 URL을 잔뜩 만들어 놓고 “well-known”이라는 딱지를 붙인다고 해서 실제로 유명해지는 건 아님
답변달기