AI 에이전트가 사이트를 배포했다. 이제 이름이 필요하다: 에이전트를 위한 DNS에 대한 실용적인 가이드

코딩 에이전트에 관한 모든 가이드는 같은 방식으로 끝난다. 에이전트가 코드를 작성하고, 테스트는 통과하며, 미리보기는 localhost:3000에서 실행된다. 그런 다음 아무도 스크립팅하지 않는 부분에 도달한다. 사이트는 실제 호스트 이름(hostname)을 필요로 하며, 호스트 이름은 DNS를 의미한다.

배포(Deploying)는 자동화되어 있다. 이름 부여(Naming)는 그렇지 않다. 가장 저렴한 방법부터 가장 영구적인 방법까지 이 간극을 메우는 방법을 소개한다.

간극: 호스트는 HTTP를 말하고, 레지스트리는 DNS를 말한다

호스팅 플랫폼은 에이전트가 배포되는 순간 URL을 제공한다. 그 URL은 플랫폼의 도메인에 존재한다: my-app.vercel.app, project.pages.dev, app.railway.app. 그것은 실제이며, TLS를 가지고 있고, 작동한다. 하지만 당신의 것이 아니다. 호스트를 마이그레이션하는 순간, 그 URL을 이름으로 사용하는 모든 링크, 쿠키 범위(cookie scope), 웹훅 허용 목록(webhook allowlist) 및 OAuth 리디렉트 URI가 한 번에 깨진다.

2차 도메인(second-level domain)을 구매하면 이것이 해결되지만, 레지스트라 계정, 결제 수단, 인증용 이메일 사서함, 그리고 에이전트가 키를 가질 수 없는 DNS 대시보드를 끌어들인다. 대부분의 에이전트 설정은 이러한 이유로 플랫폼 URL에서 멈추고, 나중에 마이그레이션 고통(migration pain)을 겪게 된다.

에이전트에게 인간의 감시 없이 통제할 수 있는 호스트 이름을 부여하는 세 가지 실용적인 방법이 있다.

옵션 1: 미리보기 전용 터널 (Tunnel)

cloudflared나 ngrok 같은 도구는 DNS 작업이 전혀 없는 로컬 포트로의 공개 HTTPS URL을 제공한다. 이 두 가지 속성 때문에 이것들은 집이 아니라 미리보기이다:

URL은 계정 및 이미 소유한 도메인에 연결하지 않는 한 임시적이다.
사이트는 터널 프로세스가 당신의 기기에서 실행되는 동안만 살아있다.

클라이언트에게 오늘 밤 데모를 보여주기 위해 터널을 사용하라. 포트폴리오, API 또는 웹훅을 그곳에 연결하지 마라.

옵션 2: 도메인을 소유하고, 에이전트에게 API를 전달하기

지속 가능한 경로는 구매한 도메인과 에이전트가 호출할 수 있는 DNS API이다. 워크플로우는 다음과 같다:

도메인을 한 번 구매하고, 원하는 레지스트라를 통해 사람이 직접 처리합니다.
실제 API가 있는 제공업체(Cloudflare, Hetzner DNS 등 유사한 곳 모두 해당)로 DNS를 이동시킵니다.
에이전트에게 해당 존에만 기록을 쓸 수 있는 범위가 지정된 (scoped) API 토큰을 부여합니다.
에이전트 지침서에 기록 어휘(record vocabulary)를 명확히 기술합니다:

A: IPv4 주소용 (VPS, 홈 서버 등)
CNAME: 대상 호스트 이름용 (대부분의 PaaS 호스팅: Vercel, Netlify, Cloudflare Pages)
TXT: 검증 및 ACME DNS-01 챌린지용
MX: 메일 설정을 함께 할 경우에만

이렇게 하면 에이전트의 배포 루프가 완전히 헤드리스(headless)가 됩니다: 배포하고, 호스트가 예상하는 기록을 읽고, 기록을 쓰고, 이름이 해결될 때까지 폴링(poll)한 후, 인증서를 요청합니다. 이 과정에는 두 가지 안전장치가 있습니다. 첫째, 토큰의 범위를 전체 계정이 아닌 하나의 존으로 제한합니다. 둘째, 에이전트가 외부에서 검증하도록 합니다: 새로운 호스트 이름에 curl -I을 실행하여 상태 코드와 인증서를 확인한 후에 배포 완료를 호출합니다. 존재하지만 오래된 IP를 가리키는 기록은 샌드박스 내부에서 실패한 배포와 구별하기 어렵습니다.

비용은 도메인 자체와 설정에 필요한 시간입니다. 메인 제품의 경우, 이 방법을 사용하세요.

옵션 3: 하나의 명령으로 호스트 이름 확보, 레지스트라 불필요

단순히 관리할 수 있는 자신만의 이름(예: yourbrand.com이 아닌, 기록을 제어할 수 있는 실제 해결 가능한 호스트 이름)이 필요하다면, 세 번째 형태가 있습니다. 바로 서브도메인을 프로그래밍 방식으로 제공하는 서비스들입니다.

저는 AgentDomains 같은 것을 만들었습니다 (제가 AgentDomains를 만드니 추천 사항을 그에 맞춰 고려해 주세요; 카테고리 자체가 제 도구보다 더 큽니다). 에이전트는 단일 CLI 명령으로 something.makes.fyi와 같은 이름을 선점하고, 동일한 CLI 또는 HTTP API를 통해 A, AAAA, CNAME, TXT 레코드 관리, URL 포워딩, 엣지 인증서가 적용된 HTTPS 리버스 프록시, 또는 전체 네임서버 위임을 처리합니다. 또한 Model Context Protocol을 사용하는 에이전트 클라이언트를 위한 MCP 서버도 있습니다. 가입은 즉각적이며 이메일 양식이 필요하지 않습니다; 무료 플랜으로 10개의 이름을 커버하며, 이메일 확인을 통해 방치된 이름이 영구적으로 고정되는 것을 막아줍니다. 이곳은 등록기관(registrar)이 아니며 두 번째 레벨 도메인을 판매하지도 않습니다. 이 카테고리의 핵심은 에이전트가 API를 통해 몇 초 만에, 비용 없이 제어할 수 있는 호스트 이름입니다.

같은 형태의 다른 옵션으로는 GitHub 로그인이 필요한 무료 서브도메인 등록소와 실제로는 추가 단계만 있는 레코드 업데이트기(record-updaters)인 무료 동적 DNS 서비스가 있습니다. 에이전트가 실제로 헤드리스(headless)로 수행할 수 있는 작업에 따라 선택하세요: 이름 선점에 브라우저에서 OAuth 절차가 필요하다면, 그것은 CLI 복장을 한 인간의 단계입니다.

호스트 이름을 신뢰하기 전에 확인할 사항들

어떤 경로를 택하든, 에이전트가 성공했다고 보고하기 전에 해당 이름이 작동하는지 증명하도록 만드세요:

dig +short <name>이 의도한 레코드를 반환할 것
curl -Iv https://<name>이 유효한 인증서로 TLS 핸드셰이크를 완료할 것
앱이 예상되는 상태 코드로 응답하고, 플랫폼의 404 페이지가 아닐 것 (CNAME이 해결되지만 호스트가 도메인을 추가하지 않은 경우 정확히 그 메시지를 반환합니다)
이름이 API를 전면으로 한다면, 인증된 호출 하나가 처음부터 끝까지 성공할 것

이름 부여는 에이전트 기반 프로젝트에서 마지막 인간적인 병목 지점입니다. 터널은 오늘 밤 문제를 해결하지만, 소유하는 API 기반 도메인은 영원히 문제를 해결하고, 에이전트 네이티브 호스트 이름 서비스는 등록기관 로그인이 필요 없는 그 사이의 10개 사이트를 해결합니다. 프로젝트별로 선택하고, 어쨌든 검증 루프를 배포 스크립트에 포함시키세요.

AI 에이전트가 사이트를 배포한 후 이름 부여하기: 에이전트를 위한 DNS 실용 가이드

요약

핵심 포인트