Vibe Coding: Endgame
A few months ago, my AI coding workflow looked something like...
개요 #
프롬프트를 던지고, 코드를 받고, 실행하고, 에러를 만나고, 다시 프롬프트를 고치는 무한 루프. AI로 뭔가 만들어 본 사람이라면 익숙한 풍경이다. 개발자 Konark Sharma는 이 방식으로 몇 주 걸리던 프로토타입을 하루 저녁에 완성하며 즐거워했지만, 프로젝트가 커지는 순간 모든 게 무너졌다고 말한다. 그가 내린 결론은 의외로 단순하다. 문제는 AI가 아니라, 계획 없이 코드부터 뽑아낸 자신이었다는 것이다.
재미있지만 오래가지 못한 방식 #
바이브 코딩의 흐름은 아름다울 만큼 단순하다. Claude, Codex, Gemini, Cursor 같은 도구를 열고 "대시보드 하나 만들어줘"라고 치는 순간부터 당신은 바이브 코더가 된다. 프롬프트를 쓰고, AI가 코드를 짜고, 복사해서 실행하고, 뭔가 어색하면 프롬프트를 살짝 고쳐서 다시 뽑는다. 그렇게 "나중에 정리하지 뭐" 싶을 정도로 그럴듯해질 때까지 반복한다.
물론 그 "나중"은 오지 않는다.
Sharma는 이걸 비판이 아니라고 강조한다. 시작할 때의 지루한 부분을 걷어냈기 때문에 바이브 코딩이 인기를 끈 것이고, 몇 달씩 노트에만 머물던 아이디어가 주말 만에 동작하는 프로토타입이 되는 경험은 분명 짜릿하다.
Photo by Daniil Komov on Pexels
프로젝트가 커지면 무너진다 #
문제는 규모가 커질 때 드러난다. 버튼 하나 바꿔달라고 하면 내비게이션 바가 바뀐다. 내비게이션 바를 고쳐달라고 하면 이번엔 인증이 깨진다. 인증을 고치면 스타일 절반이 사라진다. 어느 순간 채팅 기록은 개발 로그가 아니라 커플 상담 대화처럼 보인다.
- "하나만 바꿔달라고 했잖아."
- "아는데, 이게 더 나을 것 같아서."
- "난 그런 거 부탁한 적 없어."
Sharma는 한동안 AI를 탓했다고 고백한다. 그러다 자기 프롬프트를 다시 봤다.
"프로젝트 관리 앱 만들어줘."
그게 전부였다. 요구사항도, 아키텍처도, 제약도 없이 그냥 바이브뿐. 결국 AI에게 독심술을 기대한 셈인데, 그 기능은 아직 업데이트되지 않았다.
코드보다 먼저 와야 하는 것 #
전통적인 소프트웨어 개발은 한 번도 코드로 시작한 적이 없다. 문제를 이해하는 데서 출발한다. 사용자는 누구인가, 무엇을 만드는가, 어떤 기능이 정말 중요한가, 무엇을 다음 버전으로 미뤄도 되는가. SDLC(소프트웨어 개발 생명주기)가 늘 강조해 온 것들이다.
바이브 코딩은 이 과정을 거꾸로 뒤집어 놓았다. 코드부터 뽑고, 대화 중간쯤에서야 원하는 게 뭔지 깨닫는다. 빠른 프로토타입이라면 괜찮다. 하지만 키워 나갈 프로젝트라면 여기서부터 금이 간다.
Sharma는 대화가 길어질수록 AI가 맥락을 잊고, 한 문제를 고치며 다른 문제를 만들고, 시키지도 않은 걸 자신 있게 만들어낸다는 걸 알아챘다. 처음엔 이걸 환각(hallucination)이라 불렀지만, 지금은 다르게 본다. 애초에 명확한 계획을 주지 않은 탓이 컸다는 것이다.
테스트만으로는 부족했다 #
AI가 만든 프로젝트가 커지면서 개발자들은 자연스럽게 엔지니어링 관행을 다시 끌어들였다. 특히 테스트가 중요해졌다. AI가 내놓은 걸 그대로 받지 않고 검증하고, 테스트를 쓰고, 고치고, 반복하니 프로젝트가 훨씬 안정적이 됐다.
하지만 Sharma는 여전히 뭔가 빠졌다고 느꼈다. 테스트는 "제대로 만들었는가"는 알려주지만, "옳은 것을 만들고 있는가"는 알려주지 않는다. 코드를 쓰기 전이 아니라 쓴 다음에 계획하고 있다는 것, 그게 진짜 문제였다.
나도 모르게 스펙 기반 개발자가 되다 #
어느 날 갑자기 "오늘부터 스펙 기반 개발자가 되겠어"라고 결심한 건 아니었다. 최근 프로젝트를 만들다 보니, 코드 한 줄 뽑기 전에 요구사항을 적는 데 거의 한 시간을 쓰고 있는 자신을 발견했다. 어떤 기능이 실제로 필요한가, 절대 바뀌면 안 되는 건 무엇인가, 어떤 컴포넌트를 재사용할 수 있어야 하는가, 성공은 어떤 모습인가.
그 질문들에 답한 뒤에야 AI에게 코드를 맡겼다. 결과는 놀라웠다. 완벽하진 않았지만 — 여전히 AI니까 — 같은 화면을 열 번 다시 뽑는 대신 작은 개선을 반복하고 있었다.
그때 깨달았다. 프롬프트가 좋아진 게 아니라 길어진 것이었고, 그건 더 이상 프롬프트가 아니었다. **명세(specification)**였다. 자기도 모르게 AI에게 알아서 하라고 맡기던 걸 멈추고, 설계도를 건네주기 시작한 것이다.
Photo by Markus Winkler on Pexels
엔드게임은 AI가 아니었다 #
Sharma가 보기에 스펙 기반 개발(Spec-Driven Development)은 바이브 코딩을 대체하는 게 아니다. 방향을 주는 것이다. "포트폴리오 사이트 만들어줘"로 시작하는 대신, 이제 그는 질문에 먼저 답한다. 이 포트폴리오는 누구를 위한 것인가, 어떤 페이지가 필요한가, 어떤 기술을 쓸 것인가, 어떤 컴포넌트를 재사용 가능하게 둘 것인가, 나중에 바뀌면 안 되는 건 무엇인가, 성공한 결과란 어떤 모습인가.
이런 결정을 spec.md, requirements.md, tasks.md 같은 파일에 담는 워크플로도 있지만, 파일 이름은 중요하지 않다. 중요한 건 사고 과정이다. 빈 땅이 아니라 설계도를 건네자, 놀랍게도 AI는 훨씬 나은 개발자가 됐다.
글의 제목이 비로소 이해되는 순간이다. 엔드게임은 Claude도, Gemini도, Codex도, 더 나은 프롬프트도, 심지어 AI도 아니었다. AI에게 생각을 맡기기 전에 스스로 먼저 생각하는 법을 배우는 것이었다.
쿠키 영상: 결국 더 빨라졌다 #
요즘 Sharma는 코드를 부탁하기 전에 구현 계획을 만들거나 검토하는 데 시간을 쓴다. 직접 쓸 때도 있고, AI에게 초안을 받아 편집할 때도 있다. 불필요한 기능을 덜어내고, 빠진 요구사항을 채우고, 제약을 정의한 다음에야 첫 코드를 뽑는다.
역설적이게도 코딩 전에 시간을 더 쓰니 프로젝트가 더 빨리 끝났다. 재생성이 줄고, 토큰 낭비가 줄고, "아니, 그게 아니라..."라고 말하는 시간이 줄었다. 대신 프로젝트를 실제로 앞으로 나아가게 하는 코드를 검토하는 데 더 많은 시간을 썼다.
그는 바이브 코딩이 사라질 거라 생각하지 않는다. 오히려 그러지 않길 바란다. 새벽 2시에 아이디어가 떠오르면 여전히 IDE보다 AI 코딩 도구를 먼저 연다. 달라진 건 기대다. 문장 하나로 AI가 모든 걸 마법처럼 이해해 주리라 더는 바라지 않는다. AI가 강력해질수록, 명확하게 사고하는 능력의 가치는 오히려 커진다.
우리는 이미 모든 코드를 직접 쓰던 시절에서 AI와 협업하는 시절로 넘어왔다. 다음 진화는 더 나은 프롬프트 엔지니어가 되는 게 아닐지도 모른다. AI를 제대로 부릴 줄 아는, 더 나은 소프트웨어 엔지니어가 되는 것일 수도 있다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.