바이브 코딩에도 도메인이 필요합니다: 흐름을 끊지 않고 등록하기

프롬프트를 입력하고 파일 트리가 채워지는 모습을 지켜보니 삼십 초 만에 채팅에 라이브 URL이 나타났습니다. 이것이 바로 바이브 코딩의 매력입니다. “아이디어가 있다”에서 “인터넷에서 실제로 작동하는 것이 있다”까지의 간격이 커피 한 잔 마실 시간 정도로 줄었습니다. 다만 눈앞의 URL은 my-app-a3f9.vercel.app이나 my-app.lovable.app처럼 끝납니다. 명함에 넣을 만한 이름이 아니라 플랫폼 서브도메인입니다. 여기서 실제로 소유할 수 있는 도메인으로 넘어갈 때 대개 작업 흐름이 끊기지만, 꼭 그래야 하는 것은 아닙니다.

“바이브 코딩”의 실제 의미

아직 이 용어가 익숙하지 않다면, Wikipedia는 바이브 코딩을 “소프트웨어 개발자가 프로젝트나 작업을 프롬프트로 대규모 언어 모델(LLM)에 설명하면 모델이 소스 코드를 자동으로 생성하는, 인공지능(AI)의 도움을 받는 소프트웨어 개발 방식”으로 정의합니다. 핵심 특징은 단지 AI가 코드를 작성한다는 데 있지 않습니다. 이전에도 자동 완성으로 코드를 쓰는 도구는 많았습니다. 바이브 코딩에서는 모델이 생성한 모든 줄을 읽는 대신 결과물을 받아들이고 다음 변경 사항을 자연어로 설명하며 반복 작업을 이어가는 경우가 많습니다. Tesla의 전 AI 책임자이자 OpenAI 공동 창업자인 Andrej Karpathy가 2025년 2월 이 용어를 만들었고, 한 달 만에 Merriam-Webster가 유행 속어로 주목할 만큼 빠르게 퍼졌습니다. 이후 Collins English Dictionary는 이를 올해의 단어 중 하나로 선정했습니다.

그렇다고 이런 방식을 깎아내릴 이유는 없습니다. 원하는 것을 설명하고 실행되는 앱을 돌려받는 것은 분명 새로운 개발 방식입니다. 이를 중심으로 만들어진 Cursor, Lovable, Replit, bolt.new, v0, Claude Code 같은 도구는 이제 작동하는 프로토타입을 만드는 일이 더 이상 가장 어려운 단계가 아닐 만큼 발전했습니다. 어려운 부분, 적어도 여전히 2015년처럼 보이는 부분은 “작동한다” 이후의 모든 일입니다. 앱에 이름을 붙이고 제대로 된 주소를 연결하는 일입니다.

마지막 단계: 플랫폼 서브도메인에서 내 도메인으로

이 플랫폼들은 모두 같은 문제를 같은 방식으로 해결합니다. 먼저 제품을 내보내 플랫폼 자체 도메인의 서브도메인에 배포하고, 커스텀 도메인은 나중에 설정 패널에서 구성할 수 있는 선택 사항으로 남겨 둡니다. 이는 올바른 기본값입니다. 아이디어가 실제로 작동하는지 확인하기도 전에 도메인을 소유할 필요는 없습니다. 하지만 플랫폼 서브도메인은 목적지가 아니라 경유지라는 뜻이기도 합니다. 소리 내어 말하기 불편하고 기억하기 어려우며, 주소 표시줄을 보는 누구에게나 “아직 남의 도구 무료 요금제를 쓰고 있다”는 인상을 줍니다.

실제 도메인을 등록하는 일은 그 자체만 놓고 보면 작은 작업입니다. 이름 검색, 구매, DNS 레코드 몇 개면 됩니다. 하지만 전통적으로 바이브 코딩의 전체 순환에서 유일하게 완전히 다른 곳에서 처리해야 하는 단계이기도 합니다.

에디터를 벗어나면 흐름이 끊기는 이유

실제 마찰은 도메인 등록이 어렵다는 데 있지 않습니다. 등록 작업이 다른 곳에 있다는 점입니다. 전통적인 방식으로 도메인을 등록하려면 코딩 에이전트와 나누던 대화를 멈추고 브라우저 탭을 열어 등록대행자 홈페이지로 이동해야 합니다. 이름을 검색하면 개인정보 보호, 이메일 호스팅, 필요하지 않은 웹사이트 빌더를 권하는 세 가지 추가 판매 항목이 나타납니다. 어떤 체크박스를 해제해야 할지 알아내 결제한 다음, 여기서 일반적인 도메인 가이드가 건너뛰는 과정이 시작됩니다. 사용 중인 호스팅 플랫폼에 어떤 DNS 레코드가 필요한지 파악하고, 다른 대시보드에서 해당 값을 찾아 세 번째 탭에 붙여 넣어야 합니다.

이것은 한 가지 작업이 아니라 서로 다른 세 가지 제품에 걸친 다섯 가지 작업입니다. 어느 제품도 방금 무엇을 만들었는지, 어느 플랫폼에 배포했는지 알지 못합니다. 컨텍스트를 전환할 때마다 실제 비용이 듭니다. 하던 일의 맥락을 잃고, 다른 탭에서 무언가에 정신이 팔려 한 시간 뒤에야 돌아올 가능성도 분명히 있습니다. 다섯 분짜리 작업치고는 부담이 큽니다.

채팅을 벗어나지 않고 등록하기

해결책은 도메인을 배포와 같은 방식으로 다루는 것입니다. 별도의 볼일이 아니라 같은 대화 안에서 실행하는 또 하나의 도구 호출로 취급하는 것입니다. 앱의 뼈대를 만들고 배포까지 푸시한 에이전트는 이미 앱 이름과 실행 중인 플랫폼이라는 컨텍스트를 알고 있습니다. 따라서 이름을 확인하고 등록하고 DNS를 연결하기에도 적합한 도구입니다.

핵심만 추리면 흐름은 세 단계입니다.

1. 에이전트에게 이름을 확인해 달라고 요청합니다. “myapp.com을 사용할 수 있나요?”는 읽기 전용 호출이므로 쓰기 권한이 있는 항목을 연결하기 전에도 작동합니다.
2. 확인하고 등록합니다. “일 년 동안 등록해 줘”라고 하면 주문이 제출되고, 에이전트는 완료될 때까지 상태를 확인합니다.
3. 배포 위치를 가리키게 합니다. 호스팅 플랫폼에서 요구하는 레코드(루트 도메인에는 A 레코드, 서브도메인에는 CNAME)를 에이전트에게 주면 에이전트가 해당 DNS 레코드를 설정합니다. DNS를 호스트에 완전히 맡기는 경우라면 대신 도메인의 네임서버 (NS 레코드) 수준 위임이 호스트를 가리키도록 변경합니다.

전체적인 모습은 이렇습니다. 각 에디터가 읽는 설정 파일과 Vercel 및 Cloudflare Pages에서 요구하는 실제 DNS 값 등 정확한 절차는 이미 Namefi MCP 빠른 시작: Claude Code, Cursor, Windsurf에서 단계별로 설명했으므로 여기서 반복하지 않습니다. 이 세 에디터가 아닌 OpenAI Codex, Gemini CLI, Claude Desktop 또는 MCP를 지원하는 다른 도구로 코딩한다면 Namefi에서 AI 에이전트로 도메인을 등록하는 방법에서 각 도구별로 검증된 설정을 확인할 수 있습니다. MCP 네이티브가 아닌 도구를 위한 직접 REST 방식도 함께 제공합니다.

이름 아이디어도 에이전트에게 맡기기

이름을 정하는 단계도 따로 언급할 가치가 있습니다. 대개 결제만큼이나 작업 흐름을 끊기 때문입니다. 전통적인 방식은 이렇습니다. 이름을 생각하고 등록대행자 탭으로 이동했더니 이미 등록되어 있습니다. 다른 이름을 생각하고 다시 탭을 옮기는 일을, 쓸 수 있는 이름을 찾거나 포기하고 이름 끝에 숫자를 붙일 때까지 반복합니다.

Namefi의 API는 대량 가용성 확인 기능을 제공합니다. 모든 에이전트가 읽는 namefi.io/llms.txt에서도 이 기능을 “여러 이름을 한 번에 선별하는” 방법으로 설명합니다. 따라서 후보를 하나씩 시험하는 대신 전체 후보 목록을 에이전트에게 건네 한 번의 요청과 응답으로 실제 사용할 수 있는 이름을 확인할 수 있습니다. 실제로는 이름 정하기가 프롬프트 하나로 끝납니다. “앱은 Streaky라는 습관 추적기야. streaky.com, streaky.app, getstreaky.com, streaky.io를 확인하고 어떤 이름을 사용할 수 있는지 알려 줘.” 에이전트가 일괄 확인한 뒤 결과를 보고하면, 이미 등록된 이름에 마음을 빼앗기는 대신 실제로 가질 수 있는 이름 중에서 고르면 됩니다.

실전 예시: 프롬프트에서 라이브 URL까지

어느 오후에 소규모 도구를 바이브 코딩으로 만들었다고 해 보겠습니다. 기존 앱이 마음에 들지 않아 직접 만든 공유 장보기 목록 앱입니다. 플랫폼 서브도메인에서 실행되고 있고 제대로 작동하며 친구 몇 명이 링크를 원합니다. 같은 채팅 창에서 이어지는 나머지 과정은 다음과 같습니다.

cartly.app을 사용할 수 있는지 묻습니다. 사용할 수 있습니다. “일 년 동안 등록하고 방금 배포한 곳을 가리키게 해 줘”라고 말합니다. 에이전트는 등록을 제출하고 완료될 때까지 상태를 확인한 다음, 방금 산 도메인에 어떤 DNS 레코드가 필요한지 호스팅 플랫폼에서 확인해 달라고 합니다. 이 과정은 해당 플랫폼 대시보드를 한 번 확인하면 됩니다. 이 사례에서는 www 서브도메인이 아닌 루트 도메인을 사용하므로 A 레코드가 필요합니다. 그 값을 다시 붙여 넣으면 에이전트가 레코드를 작성합니다. 몇 분 후 DNS 전파에 필요한 짧은 시간이 지나면 cartly.app은 친구들이 이미 다른 탭에서 열어 둔 바로 그 앱으로 연결됩니다. 에디터를 떠난 총시간은 전혀 없습니다. 앱을 만드는 데 이미 사용하던 탭 외에 새로 연 탭도 전혀 없습니다.

자주 묻는 질문

이 작업을 하려면 DNS를 알아야 하나요?

데이터베이스 인덱스를 사용하기 위해 그 작동 원리를 알 필요가 없는 것과 같습니다. 에이전트가 호스팅 플랫폼에 필요한 레코드를 묻고 이를 작성합니다. 사용자는 대부분 값을 직접 작성하는 것이 아니라 확인하기만 하면 됩니다.

모든 바이브 코딩 플랫폼에서 작동하나요, 아니면 특정 플랫폼만 지원하나요?

등록과 DNS 측면은 플랫폼에 구애받지 않습니다. 앱을 무엇으로 만들었든 도메인과 DNS 레코드는 같은 방식으로 작동합니다. 달라지는 것은 호스팅 플랫폼이 요구하는 레코드 유형이며, Namefi MCP 빠른 시작에서는 Vercel과 Cloudflare Pages에 필요한 유형을 구체적으로 설명합니다.

이 방식으로 등록한 도메인은 토큰화되나요?

기본적으로 그렇습니다. Namefi는 ICANN 공인 등록대행자이며, 표준 등록과 함께 도메인을 Base에서 NFT로 발행해 API 키에 연결된 지갑에 등록합니다. 일반적으로 작동하는 도메인과 온체인 소유권 기록을 모두 얻게 되며, 둘 중 하나만 선택하는 방식이 아닙니다.

원하는 이름이 이미 등록되어 있다면 어떻게 하나요?

바로 위의 대량 가용성 확인 기능을 사용하면 됩니다. 후보를 하나씩 시험하지 말고 여러 후보(TLD 변형, 접두사, 동의어)를 에이전트에게 건네 실제로 사용할 수 있는 이름을 보고하게 하세요.

시도하기 전에 Namefi 계정이 필요한가요?

아니요. 가용성 확인은 읽기 전용이며 인증이 필요하지 않습니다. 따라서 API 키를 생성하거나 자금을 예치하기 전에 연결을 구성하고 이름을 시험할 수 있습니다.

지금의 작업 흐름 안에서 이름까지 출시하기

도메인은 별도의 프로젝트가 아닙니다. 호스팅 플랫폼 선택과 같은 종류의 인프라 결정입니다. 앱을 출시하는 과정에서 도메인만 브라우저 탭과 결제 양식을 요구해야 할 타당한 이유는 없습니다. 다음에 에이전트가 플랫폼 서브도메인에서 작동하는 앱을 내놓으면, 대화를 계속 이어 가며 이름을 확인해 달라고 요청하세요.

Namefi API 키를 생성하고 지금 만들고 있는 프로젝트에 사용해 보세요. 또는 Namefi MCP 빠른 시작: Claude Code, Cursor, Windsurf의 전체 안내부터 시작할 수 있습니다.

출처 및 추가 자료

• Wikipedia — 바이브 코딩 (정의, Andrej Karpathy가 2025년 2월 만든 용어, 확산 과정)
• Namefi — namefi.io/llms.txt (대량 가용성 확인 엔드포인트, MCP 서버 URL, 등록 및 DNS 참고 자료)
• Namefi — Namefi MCP 빠른 시작: Claude Code, Cursor, Windsurf (에디터별 설정, 전체 다섯 단계 흐름, Vercel 및 Cloudflare Pages DNS 단계)
• Namefi — Namefi에서 AI 에이전트로 도메인을 등록하는 방법 (Codex, Gemini CLI, Claude Desktop 설정 및 원시 REST 경로)
• Model Context Protocol — modelcontextprotocol.io (프로토콜 개요)