도구가 준 답이 내 질문에 대한 게 아니었다

도메인 후보를 한 번에 확인하려고 whois 를 셸 한 줄로 돌린 적이 있다면, 출력이 나왔다는 이유로 결과를 믿었을 가능성이 있다.

블로그에 붙일 도메인이 비어 있는지 확인해야 했다. 후보 5개를 whois 로 한 번에 돌리는 셸 한 줄을 짰다. 출력에 No match 나 NOT FOUND 가 있으면 "사용 가능", 없으면 "등록됨"으로 판정하는 방식이었다.

결과가 5개 전부 「등록됨」 으로 나왔다. 그중에는 아무도 안 쓸 것 같은 조합도 있었다.

넘어갈 수 있었던 지점

여기서 "다 등록됐네"로 넘어갈 수 있었다. 출력이 있었고, 스크립트가 에러를 내지 않았고, 판정도 나왔다. 5개가 전부 같은 결과라는 게 유일한 이상 신호였다.

원문을 열어봤다. whois 가 도메인 등록 정보를 준 게 아니라 IANA 의 TLD 정보를 주고 있었다. .dev 라는 최상위 도메인이 누구 것인지(Charleston Road Registry)를 답한 것이다. 내가 물은 건 "이 도메인이 비었나"였는데, 도구는 ".dev 는 이런 것이다"를 답했다.

질문과 답이 어긋난 채로 형식은 맞았다. No match 가 없었던 건 등록됐기 때문이 아니라 애초에 그 답을 하는 응답이 아니었기 때문이다. 판정 로직은 그 차이를 구분할 수 없었다.

.dev 는 whois 조회를 제한한다. 대신 RDAP 라는 프로토콜로 물어야 하고, 그건 HTTP 로 답한다. 404 면 없는 도메인, 200 이면 있는 도메인이다. 그렇게 다시 물었더니 후보들이 전부 사용 가능으로 나왔다. 처음 결과와 정반대였다.

코드가 아니라 확인 절차를 바꿨다

출력이 있다는 것과 그 출력이 내 질문에 대한 답이라는 것은 다른 사실이다.

도구가 성공적으로 종료했다는 신호(exit code 0, 에러 없음, 형식 맞는 출력)는 전부 두 번째 사실을 보증하지 않는다. 자동 판정을 씌우면 이 어긋남이 특히 안 보인다 — 판정 로직은 자기가 파싱하려던 형식이 아니면 그냥 "해당 없음"으로 처리하고, 그게 의미 있는 답처럼 출력된다.

같은 날 블로그 코드에서도

사이트 주소가 https://example.com 으로 하드코딩돼 있었다. sitemap.xml 과 robots.txt 와 canonical 링크가 전부 그 값을 물고 있었다.

빌드는 통과한다. 파일도 정상적으로 생성된다. 그 파일들이 틀린 주소를 정상적으로 담고 있을 뿐이다. 배포하면 검색엔진이 그 주소로 색인한다.

그래서 빌드가 통과한 다음에 생성된 HTML 을 열어 canonical 태그에 뭐가 들어갔는지 직접 봤다. 파일이 있다는 것과 내용이 맞다는 것도 다른 사실이다.