"오늘날 에이전트가 엉망을 만들지 않고 vibecode하는 가장 좋은 방법을 보여드릴게요." 개발자 sammwy가 X에 올린 글은 하루 만에 9만 조회, 좋아요 2600건을 넘겼다. 뉴스라 부르기엔 애매한 한 줄짜리 팁이지만, 반응의 크기는 그만큼 많은 사람이 같은 문제로 골머리를 앓고 있다는 증거이기도 하다. 코딩 에이전트에게 "이거 만들어줘"라고 던지면 초반 몇 시간은 놀랍도록 잘 풀리다가, 어느 순간부터 앞뒤가 안 맞는 코드를 쏟아내기 시작하는 그 익숙한 경험 말이다.
대화가 끝나는 순간, 맥락도 함께 사라진다
바이브 코딩이 무너지는 지점은 대체로 비슷하다. 채팅창에서 이런저런 요구사항을 즉흥적으로 던지고 수정하다 보면, 정작 "지금 우리가 뭘 만들기로 했는지"가 대화 로그 어딘가에 흩어져 남는다. 에이전트는 그 대화의 흐름을 매번 처음부터 다시 추론해야 하고, 세션이 길어지거나 도중에 다른 에이전트로 넘어가면 앞서 합의한 세부사항이 통째로 증발한다. 결과물이 산으로 가는 건 에이전트가 무능해서가 아니라, 애초에 넘겨받은 지시 자체가 모호하고 휘발성이 강하기 때문이다.
대화를 스펙 문서로 응축하는 절차
sammwy가 제시한 해법은 새로운 도구가 아니라 순서를 바꾸는 것이다. 먼저 ChatGPT 같은 일반 채팅 창을 열고, 만들고 싶은 것을 자유롭게 이야기하며 아이디어를 반복적으로 다듬는다. 이 단계는 코드를 짜는 게 아니라 무엇을 만들 것인지 스스로 명확히 하는 과정에 가깝다.
어느 정도 윤곽이 잡히면, 그 대화에서 나온 기술적인 내용 전부를 정리해 SPECS.md 파일로 만들어달라고 요청한다. 화면 구조, 데이터 흐름, 예외 처리, 우선순위 같은 것들이 산문형 대화에서 문서 형태로 응축되는 지점이다. 그다음 이 SPECS.md 파일을 프로젝트 폴더에 넣고, Claude Code 같은 코딩 에이전트에게 그대로 넘겨 구현을 맡긴다. 작업 도중 요구사항이 바뀌면 채팅으로 되돌아가 다시 다듬는 대신, SPECS.md 자체를 갱신하고 에이전트에게 다시 읽게 하는 쪽이 훨씬 안정적이다.
왜 모호한 대화보다 문서 한 장이 더 셀까
원리는 단순하다. 대화는 시간 순서로 쌓이는 맥락이라 앞뒤 모순이 생기기 쉽고, 에이전트가 매번 전체를 다시 읽고 재해석해야 한다. 반면 스펙 문서는 결론만 남긴 정적인 기준점이다. 에이전트 입장에서는 "무엇을 판단해야 하는가"가 아니라 "무엇이 정해져 있는가"만 확인하면 되므로, 컨텍스트 창을 덜 쓰면서도 더 일관된 결과를 낸다. 사람과 에이전트가 대화할 때, 에이전트와 에이전트가 협업할 때 쓰는 언어를 분리한다는 점에서, 이는 최근 Claude Code나 Codex 생태계에서 널리 퍼진 '스펙 주도 개발' 흐름과도 맞닿아 있다.
다만 이 워크플로우가 유일한 정답은 아니다. 팀 단위 프로젝트에서는 SPECS.md 대신 이슈 트래커나 RFC 문서를 스펙 기준점으로 쓰는 경우도 많고, 스펙을 얼마나 세밀하게 쓸지도 프로젝트 성격에 따라 달라진다. 원문 스레드 역시 이 단계 이후 구체적으로 어떤 팁이 이어졌는지는 공개된 부분만으로는 확인할 수 없다. 그럼에도 "대화로 생각을 정리하고, 문서로 응축하고, 에이전트에게 넘긴다"는 3단 구조 자체는 도구나 프로젝트 규모와 무관하게 바로 시도해볼 만한 습관이다.
