Example.com이 수십 년 만에 가장 큰 리디자인을 단행했습니다

요약

Example.com이 여섯 개 언어를 한 화면에 보여 주는 새 디자인으로 바뀌었습니다.

웹 성능 모니터링 업체 디버그베어의 코너 매카시가 2002년부터 이어진 example.com의 변화를 정리했습니다. 이 주소는 IANA(인터넷 주소와 번호를 관리하는 기관)가 문서 예시용으로 누구나 허락 없이 쓰도록 예약해 둔 도메인입니다.

왜 중요한가

몇 년에 한 번 바뀌던 페이지가 최근 1년 새 여러 번 바뀌어, 내용에 기대던 테스트가 깨질 수 있습니다.
페이지에는 테스트와 모니터링에 쓰지 말라는 문구가 들어가 있습니다.
IANA는 접속 대부분이 자동화된 프로그램이라 페이지를 기본 HTML과 JavaScript로 나눠 전송량을 줄였다고 밝혔습니다.

핵심 내용

2026년 9월 28일 영어, 아랍어, 중국어 등 여섯 개 언어를 5초마다 바꿔 보여 주는 스크립트가 들어갔습니다.
글자마다 시차를 두고 나타나던 효과는 10월 3일 빠졌고, 지금은 모든 언어를 한꺼번에 보여 줍니다.
2013년 Apache 서버에서 EdgeCast CDN으로 옮기면서 'Example Domain' 제목의 카드 디자인이 처음 나왔습니다.
2025년 10월 카드 디자인이 사라졌고, 12월에는 클라우드플레어로 옮겼습니다.
디버그베어의 모니터링 기록에서도 이 사이트는 가끔 제대로 응답하지 않았습니다.

HN 반응

옛 디자인을 그대로 재현한 대체 페이지를 내놓은 이용자도 있었지만, 애초에 테스트를 이 주소에 기대지 말라는 지적이 더 많았습니다.
코딩 에이전트가 example.com으로 연결 테스트를 만든다는 경험담과 함께, 문서에 없어도 공개된 것은 누군가 기대게 된다는 사례가 이어졌습니다.

30개 표시 · 전체 231개

pimterry3일 전 HN

테스트가 전부 깨져서 절망하신 분들을 위해, 제가 운영하는 공개 엔드포인트 테스트 서버에 예전 디자인을 그대로 재현한 페이지를 만들어 뒀습니다. https://example.testserver.host/ 입니다. URL만 바꾸면 다시 아무것도 모르던 행복한 시절로 돌아갈 수 있어요.

오픈소스이고 직접 호스팅할 수도 있습니다. https://github.com/httptoolkit/testserver . 다른 엔드포인트도 많이 있고, 전체 문서는 여기 있습니다. https://testserver.host/
Cthulhu_3일 전 HN

그 사이트에 기대는 테스트가 있다면... 제발 그만두세요.

This is not a service; avoid relying on it for testing and monitoring purposes. (이것은 서비스가 아닙니다. 테스트나 모니터링 용도로 의존하지 마십시오.)
zahlman3일 전 HN

이 글을 보기 전까지는 example.com이 살아 있다는 전제로 테스트를 짜는 사람이 있을 거라고는 생각도 못 했습니다. 내용에 의존하는 경우는 말할 것도 없고요.
n8m83일 전 HN

저도요. 지금 입이 귀에 걸렸네요!
smashed3일 전 HN

어제 제가 만들고 있는 프로젝트에서 Claude Code의 Opus 5.5가 example.com을 대상으로 DNS와 인터넷 접속을 확인하는 단위 테스트를 추가했습니다. 에이전트 샌드박스(알아요, 또 하나 나왔다는 거)라서 그 호출은 실패하는 게 정상이긴 했지만, 그래도 말이죠... 하다못해 captive portal 엔드포인트나 프로젝트가 직접 소유한 도메인을 대상으로 삼았어야 하잖습니까.

저는 리뷰하다 잡아냈지만, 그러지 못한 수천 명이 있을 겁니다.

이미 배는 떠났다고 봐야죠.
nemomarx3일 전 HN

그 수천 개 프로젝트가 깨지면 에이전트가 만든 걸 더 꼼꼼히 리뷰해야 한다는 중요한 교훈이 되겠네요. 그러면 결과적으로 이득 아닌가요?
vikramkr3일 전 HN

그보다는 에이전트가 만들 때만큼 빠르게 고쳐 버리고, 사람들은 크게 신경 쓰지 않는 경우(그런 경우가 꽤 많죠)에는 에이전트가 하는 일을 계속 대충 볼 가능성이 더 높아 보입니다.
SamuelAdams3일 전 HN

그럼 테스트에 captive.apple.com을 쓰는 것도 잘못인가요? 네트워크가 인터넷에 닿는지 확인하기에 좋고, 이런 페이지들은 대체로 꽤 안정적이잖아요.
TowerTall3일 전 HN

http://www.msftncsi.com/ncsi.txt 에 HTTP 요청을 보내면 200 OK와 함께 Microsoft NCSI라는 텍스트가 돌아옵니다. 윈도가 수십 년 동안 기기가 온라인인지 판단하는 데 써 온 URL이고, 신뢰도가 아주 높습니다.
lxgr3일 전 HN

안타깝게도 요즘은 이런 페이지를 특별 취급하는 네트워크가 꽤 많습니다. 기내 엔터테인먼트 시스템처럼 로컬 전용 네트워크에서 iOS 사용자가 "연결이 안 된다"는 OS 판단 때문에 접속과 끊김을 무한 반복하는 일을 막으려는 목적도 있고요.

인터넷 도달 가능 여부를 표준적인 방식으로 확인하고, 네트워크 사용자를 결제용 captive portal로 권위 있게 리디렉션하는 표준이 없다는 게 아쉽습니다. (TLS와 부딪혀서 자주 깨지는 지저분한 편법에 기대지 않고 말이죠.)
Ajedi323일 전 HN

2020년에 나온 RFC8910이 있습니다. https://www.rfc-editor.org/rfc/rfc8910.html
lxgr3일 전 HN

우와, 대단하네요! 이걸 실제로 지원하는 유명 네트워크 스택이 있는지 아세요?

그래도 불평할 때 들이밀 RFC가 있다는 것만으로도 좋네요. 감사합니다 :)
nemomarx3일 전 HN

테스트용으로 안정적인 서비스를 제공할 의도가 아니라고 밝혔다면 그렇게 믿을 만하지는 않다는 얘기고, 언제든 임의로 내리거나 구조를 바꿀 수 있다는 뜻이기도 하죠.

그러니 네트워크 접속 테스트에는 아마 더 단순한 걸 고르겠습니다.
98codes3일 전 HN

의존하던 서비스가 필연적으로 터졌을 때, 사용자나 사용자의 인터넷 회선 탓만 하지 마세요.
patmorgan233일 전 HN

8.8.8.8이나 1.1.1.1이나 time.windows.com에 ping을 보내면 되지 않나요? 애초에 고가용성 서비스로 설계된 것들이잖아요.
ceejayoz3일 전 HN
captive.apple.com이 time.windows.com보다 "고가용성으로 설계되지" 않았다고 볼 이유가 있나요?

모든 애플 기기가 의존하는 정적 페이지이고, 내용은 이게 전부입니다.
```
  <HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
```
mixdup3일 전 HN

유일한 위험은 애플이 이 페이지가 안정적이라고 공표하거나, 계속 유지하겠다거나 형식을 바꾸지 않겠다고 약속한 적이 없다는 점입니다. 변경에 맞춰 OS를 미리 수정해 놓고 모두의 발밑에서 이 페이지를 치워 버릴 수도 있어요, 얼마든지요.
simondotau3일 전 HN

게다가 일부 captive portal은 이 서비스의 응답을 위조하거나 흉내 냅니다.

encom3일 전 HN

1.1이면 충분합니다.

  ~$ ping -c1 1.1
  PING 1.1 (1.0.0.1) 56(84) bytes of data.
  64 bytes from 1.0.0.1: icmp_seq=1 ttl=56 time=7.89 ms

--- 1.1 ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 7.888/7.888/7.888/0.000 ms

nhecker3일 전 HN

감사합니다! 1.1과 1.1.1이 resolve된다는 걸 잊고 있었네요. 저는 너무 열심히 치다가 1.1.1.1.1에 ping을 보내는 일이 종종 있거든요. 아쉽게도 그건 resolve가 안 되죠.
stavros3일 전 HN

아직은요!
stavros3일 전 HN

이게 언제부터 됐어요? IPv6식 주소 축약을 거꾸로 적용해 준 건가요, 아니면 제가 여태 몰랐던 건가요?
bevr13373일 전 HN

저는 브라우저에서 아무 생각 없이 example.com을 써 왔습니다. WHATWG URL은 URL을 생성할 때 origin이 없으면 예외를 던지거든요. 그래서 경로(pathname)만 만들어야 하는 웹 앱은 이런 번거로운 절차를 거쳐야 합니다. new URL("/blah", " https://example.com").pathname 이건 외부 example.com 서비스에 의존하는 건 아니지만, 어쨌든 교훈을 얻는 중입니다.
oneeyedpigeon3일 전 HN

이게 어떤 테스트를 깨뜨린다는 거죠? 페이지 자체에 적힌 안내문(제 기억으로는 이것도 새로 생긴 거고요)을 빼면, 왜 테스트가 페이지의 내용이나 디자인을 실제로 건드리는지 궁금합니다. 그냥 이상한 '건전성' 확인인가요?
voidUpdate3일 전 HN

사람들은 온갖 이상한 것들이 정확히 예상대로 동작하는 데 의존합니다. https://www.hyrumslaw.com/

예를 들면 "man -w"가 stderr에 아무것도 출력하지 않는다는 데 의존하는 경우가 있습니다. https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030
madeofpalk3일 전 HN

저희 SaaS에는 내부용으로 만든, 문서화되지 않은 헬스 엔드포인트가 있었습니다. 공개적으로 접근은 되지만 (저희는) 공개적으로 쓰지 않던 것이었고, 내부 버전 번호가 들어 있었어요.

그 버전을 없앴더니 몇몇 고객이 저희 때문에 자기네 시스템이 망가졌다고 항의했습니다.
bonesss3일 전 HN

몇 년 전에 급여 시스템의 대규모 데이터베이스 업그레이드를 배포한 적이 있습니다. 처음부터 끝까지 표준화하고 정리하고 개선했고, 롤아웃도 매끄러웠습니다.

서로 등을 두드리며 자축하던 중에 화난 고객의 전화가 왔습니다. 고객 한 곳이 우리 내부 스키마에 접근해서, Access로 대규모 리포팅 환경을 만들어 필요한 걸 대부분 해결하고 있었던 겁니다.

결국 사내 도구를 이용해 그 고객의 리포트를 변환해 줬습니다. 고객은 쓸 수 있는 건 뭐든 가져다 씁니다.

[그 리포트의 수준과 깊이가 얼마나 대단했던지, 몇 달씩 걸려 우리 리포트를 직접 만드느니 차라리 그걸 사 올 걸 싶었습니다.]
eru3일 전 HN

[그 리포트의 수준과 깊이가 얼마나 대단했던지, 몇 달씩 걸려 우리 리포트를 직접 만드느니 차라리 그걸 사 올 걸 싶었습니다.]

고객에게 배우는 게 가장 값진 배움 중 하나죠. :)
sumtechguy3일 전 HN

어떤 고객은 우리가 쓰는 리포트마다 어느 저장 프로시저가 연결돼 있는지 알아냈습니다. 그러고는 일부러 미묘하고 이상한 방식으로 그걸 망가뜨려 놓고, "우리가 어떻게 반응하는지 보려고" 기술 지원에 전화를 걸곤 했습니다.
datsci_est_20153일 전 HN

API 표면은 문서화된 부분만이 아니라 노출된 부분 전체입니다.

이 원칙은 LLM 시대에 더 중요할 겁니다.

Hacker News에서 보기 ↗