프롬프트 하나로 앱이 뚝딱—그런데 그다음은?
Google AI Studio의 Gemini Build Mode를 쓰면 정말이다. 프롬프트 하나면 Next.js + Tailwind 기반 앱이 수 분 안에 돌아간다. Annotation Mode로 UI 위에 직접 메모를 붙여 "이 버튼 네온으로 바꿔줘"라고 지시하고, GitHub 연동으로 레포를 밀어 넣고, Vercel에 배포까지—전 과정이 하나의 흐름으로 이어진다. Vibe Coding이라는 이름이 딱 맞는 경험이다.
그런데 이 흥분이 가시고 나면, 실제로 매일 이 흐름을 반복할 때 무엇이 남는지 물어봐야 한다. 빠른 프로토타이핑은 분명히 가치 있다. 하지만 "AI가 빠르게 만들어준다"는 사실은 출발점일 뿐, 그것이 지속 가능한 워크플로우가 되려면 세 가지 질문을 먼저 설계해야 한다. 어디에 토큰을 쓸 것인가, 어떤 맥락을 AI에게 넘길 것인가, 그리고 파이프라인을 누가 어떻게 조율할 것인가.
토큰은 공짜가 아니다—MCP의 숨겨진 세금
dev.to의 Runtime Snapshots #13는 불편한 숫자를 직접 꺼낸다. MCP(Model Context Protocol)로 Claude Desktop이나 Cursor 같은 AI 클라이언트에 도구를 연결하는 순간, 첫 프롬프트를 입력하기도 전에 40,000~50,000 토큰이 이미 소비된다. 파일시스템, 브라우저 도구, 코드 검색 도구—이 셋만 붙여도 그렇다. MCP 프로토콜이 세션 시작 시 연결된 모든 도구의 이름, 설명, 입력 스키마, 출력 포맷을 한꺼번에 로드하기 때문이다.
$3/M 토큰 기준으로 DOM 디버깅 세션을 하루 20번만 돌려도 매일 $2.70가 아무런 문제도 풀지 못한 채 사라진다. 이게 버그가 아니라 설계라는 게 핵심이다. MCP는 "에이전트가 환경 전체를 자유롭게 탐색"하는 시나리오에 최적화되어 있다. 하지만 "버튼이 왜 안 눌리는지" 한 가지를 알고 싶을 때, 스위스 아미 나이프 전체를 꺼낼 필요는 없다.
이 글이 소개하는 E2LLM은 정반대 철학으로 움직인다. 클릭 한 번으로 해당 DOM 요소의 computed styles, ARIA 역할, z-index, 바운딩 렉트를 JSON 스냅샷으로 뽑아낸다. 세션도 없고, 서버도 없고, 사전 토큰 비용도 0이다. 정밀한 문제에는 정밀한 도구—워크플로우 설계의 첫 번째 원칙이 여기서 드러난다.
맥락 수집을 파이프라인으로 구조화한다는 것
브라질 개발자 Clinton Rocha가 dev.to에 공개한 OpenCode 플래닝 파이프라인 사례는 또 다른 각도에서 같은 문제를 건드린다. 그는 OpenCode에서 세 가지 커뮤니티 플러그인—Octto, Subtask2, Plannotator—을 조합해 단 하나의 명령어로 전체 플래닝 흐름을 오케스트레이션했다.
핵심은 맥락 수집을 AI에게 떠넘기지 않고, 구조화된 인터페이스로 사람이 직접 채운다는 점이다. Octto는 첫 프롬프트를 받으면 브라우저에 인터랙티브 브레인스토밍 페이지를 열어 동기, 제약 조건, 비기능 요구사항을 질문한다. 답변을 바탕으로 더 깊은 질문이 생성되고, 최종적으로 /docs/plans/ 에 구조화된 .md 파일이 남는다. Subtask2는 이 결과물을 다음 명령어로 자동으로 넘기고, Plannotator는 최종 플랜을 브라우저에서 시각적으로 검토·승인할 수 있게 한다.
/generate-plan "인증 시스템 리팩토링"이라는 한 줄이 컨텍스트 수집 → 플랜 생성 → 시각적 검토 → 빌드 승인의 전 과정을 순차적으로 실행한다. AI가 혼자 추측하는 게 아니라, 사람이 설계한 질문 구조 위에서 AI가 움직이는 것이다.
세 사례가 수렴하는 하나의 결론
세 기사는 서로 다른 도구를 다루지만, 같은 방향을 가리킨다. Vibe Coding은 "아이디어를 빠르게 가시화"하는 능력을 준다. 하지만 그것이 반복 가능한 워크플로우가 되려면 두 가지가 먼저 설계되어야 한다.
첫째, 비용 구조를 이해하고 도구를 선택해야 한다. MCP는 에이전트 파이프라인에 맞고, E2LLM은 단일 UI 디버깅에 맞다. 같은 상황에 같은 도구를 쓰는 게 아니라, 문제의 범위에 따라 도구의 크기를 맞춰야 한다.
둘째, 맥락 수집을 AI에게 위임하지 말고 파이프라인으로 설계해야 한다. OpenCode 사례처럼, AI가 답을 잘 내놓으려면 사람이 먼저 질문의 구조를 만들어야 한다. "더 잘 만들어줘"가 아니라 "이 맥락에서, 이 제약 조건으로, 이 순서로"라고 지시하는 구조 자체가 결과물의 품질을 결정한다.
프론트엔드 개발자에게 남는 실용적 질문
Vibe Coding의 흥분은 진짜다. 프롬프트 하나로 피트니스 트래커 앱을 만들고 Vercel에 올리는 경험은—솔직히—재미있다. 하지만 그 흥분 직후에 이 질문을 던져야 한다. 이 흐름을 내일도, 다음 주에도 같은 품질로 반복할 수 있는가?
AI 프로토타이핑 워크플로우를 지속 가능하게 만드는 건 더 좋은 모델을 쓰는 게 아니다. 어떤 도구에 어느 크기의 컨텍스트를 넘길지 결정하고, 맥락 수집 단계를 구조화하고, 토큰 비용이 어디서 새는지 추적하는—워크플로우 설계 능력이다. AI가 빠를수록, 그 속도를 올바른 방향으로 쓰는 설계권은 여전히 사람 손에 있다.