# Well-Known URI를 정의하고 싶다면
> Clean Markdown view of GeekNews topic #30659. Use the original source for factual precision when an external source URL is present.
## Metadata
- GeekNews HTML: [https://news.hada.io/topic?id=30659](https://news.hada.io/topic?id=30659)
- GeekNews Markdown: [https://news.hada.io/topic/30659.md](https://news.hada.io/topic/30659.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-06-20T15:11:22+09:00
- Updated: 2026-06-20T15:11:22+09:00
- Original source: [mnot.net](https://mnot.net/blog/2026/well_known_uris)
- Points: 1
- Comments: 1
## Topic Body
- 클라이언트가 이미 사이트를 알고 있고 사이트 전체의 정보를 효율적으로 찾아야 할 때 **Well-Known URI**가 가장 잘 맞음
- `robots.txt`처럼 중앙 위치에 정책을 두면 반복 확인을 줄일 수 있지만, `change-password`처럼 사이트 전체 상호작용을 여는 용도로도 쓰일 수 있음
- 실제 URL을 전달할 수 있는 프로토콜이 Well-Known URI를 쓰면 **서비스와 사이트가 1:1로 묶여** 배포와 라우팅이 경직됨
- 발견 메커니즘이나 콘텐츠 메타데이터에 적용할 때는 시작 호스트명, 검색 위치, 리다이렉트, 다중 게시자 사이트 같은 **운영 구조**를 먼저 따져야 함
- 기존 루트 고정 경로에서 옮기려면 전환 계획이 필요하고, `http`·`https` 외 스킴까지 명시해야 등록 성공 가능성이 높아짐
---
### Well-Known URI가 잘 맞는 상황
- [Well-Known URI specification](https://www.rfc-editor.org/info/rfc8615/)의 저자 중 한 명이자 [registry](https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml)의 Designated Expert인 Mark Nottingham은 Well-Known URI를 언제 쓰면 좋은지 실무 기준을 공유함
- 이 기준은 모두 등록 요건은 아니며, **좋은 관행**에 가까움
- Well-Known 위치는 클라이언트가 이미 사이트를 알고 있고, 그 사이트 전체에 대해 무언가를 발견하거나 상호작용해야 할 때 적합함
- 여기서 사이트는 기술적으로 `(scheme, host, port)` 튜플인 **origin**을 뜻함
- [robots.txt](https://www.rfc-editor.org/info/rfc9309/)는 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 위치는 [등록](https://github.com/protocol-registries/well-known-uris)해야 함
- 해당 링크에는 언제 등록해야 하는지와 이름을 고르는 방법에 대한 지침이 있음
- 이 등록 지침은 앞선 조언과 달리 실제 등록 성공 가능성에 영향을 줌
## Comments
### Comment 60012
- Author: neo
- Created: 2026-06-20T15:11:23+09:00
- Points: 1
###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48595331)
- 새 표준을 루트 네임스페이스에 계속 만들지 말고 이런 방식을 따랐으면 함. 예를 들어 **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”이라는 딱지를 붙인다고 해서 실제로 유명해지는 건 아님