바이브 코딩은 프롬프트에서 시작해 PRD, 규칙, 맥락 관리, 하네스 설계로 진화해 왔다. 결국 핵심 역량은 특정 도구가 아니라 구조적 사고 능력 자체다.
바이브 코딩을 처음 시도해 본 것은 24년 11월 경 이였다.
처음에는 단순히 프롬프트 한 줄 잘 쓰는 게 전부인 줄 알았지만, 이제는 시스템을 어떻게 규정하고 AI가 일을 할 수 있는 환경을 구성하고, 어떤 제약을 주느냐가 핵심이 되어가고 있는 것 같다.
내가 1년 반이 넘게 매일 해외 유튜브를 체크하면서 배우고 실습했던 것을 기반으로 지금까지 흐름을 정리해 보려고 한다. 거창하게 말하면, 바이브 코딩의 진화이고, 간단히 말하면 생각 정리이다.
한 가지 미리 짚고 가자면, 아래 단계들은 대체되는 것이 아니다. 순차적으로 레이어로 쌓인 것이다. 지금도 좋은 프롬프트를 쓰는 것은 중요하고, PRD도 여전히 작성한다. 다만 그것만으로는 부족해서 하나씩 더해지는 것으로 이해하면 된다.
1단계 프롬프트의 시대 (The Era of Prompts)
초기에는 **'어떻게 AI에게 잘 내 의도를 전달하느냐'**가 핵심이었다.
당신은 OOO입니다라면서 페르소나를 부여하고, 제약 조건을 걸고, **'Prompt Engineering'**이라는 이름 아래 AI로부터 최선의 답변을 이끌어내는 기술이 전부였던 시절이 있었다.
하지만, AI는 일관성 있게(?) 항상 같은 질문에 다른 답을 줬고, 다른 방법을 찾아야만 했다. 딸깍에서도 썼지만, 딸깍 한 번으로는 안 되고 지속적인 시도가 필요했다.
2단계 PRD와 기획의 부활
요건이 복잡해지고 하고 싶은 것이 많아질수록 프롬프트만으로는 한계가 있음을 빠르게 느꼈다. AI가 맥락을 놓치고 산으로 가기 일쑤였고, AI에게 막말을 하기 시작했던 시기였다. 나도 어느 정도 익숙해졌는데, AI는 더 안 좋아진다고 느꼈던 시기였다.
여기서 PRD(제품 요구 설명서)의 중요성이 다시 부각되었다.
같은 사람도, 시점, 기분에 따라 다른 프롬프트 대신 구현하고 싶은 기능을 논리적이고 구조적으로 기술하는 기획 역량이 핵심 엔진이 되는 것처럼 보였다.
그래서 기획자가 유리하니, 개발자가 유리하는 하는 말이 나왔던 시기였던 것으로 기억한다.
3단계 The Rules of the Game
사람들이 인지하기 시작했다. AI는 의욕이 많은 주니어 개발자라는 것을.
동일한 PRD를 제공해도 AI가 매번 다르게 해석하는 일이 너무 빈번하게 발생했고, 일관성이 가장 중요한 화두였던 시기였다. 일관성을 유지하기 위해서 AI에게 이거 해줘가 아니라, 이건 하지 말고 이거 할 때는 이걸 반드시 지켜야 해 와 같이 프로젝트 전체를 관통하는 '.cursorrules, CLAUDE.md, Agents.md' 같은 설정 파일들을 정의하기 시작했다. 디자인 시스템에 대한 개념도 이때 알게 되기 시작했다.
4단계 Context Engineering
전달하고 싶은 정보는 많아지고, AI가 기억할 수 있는 공간은 한정적이라 쳇바퀴가 도는 현상이 발생했었다. 그러면서 이제는 Promt Engineering 도 중요하지만 이제는 Context Engieering 즉 의도와 맥락을 어떻게 관리할 것인지가 중요하게 되었다. AGENTS.md를 백과사전이 아닌 목차로 취급하고 실제 지식은 구조화된 docs/ 디렉터리에 두는 패턴이 나타났다. 한방에 모두 메모리에 올리는 것이 아니라, 필요할 때 찾아서 쓰게끔 하는 방식으로 변화했다. (Progressive Context Loading — 단계적으로 맥락을 확장해가는 패턴)
5단계: Harness Engineering
Rules에 이것을 지켜라라고 해도 AI는 종종 이걸 무시한다. Harness Engineering에서는 다양한 기술을 활용해서 룰을 강제하게 만든다. 정보로 전달하느냐, 기술 등으로 강제하느냐 이것이 Rules와 Harness의 결정적인 차이다.
내가 이해하는 Harness Engineering은 다음과 같다.
프로젝트를 시작하기 전에 Skills, Hook, MCP, Rules 등을 모두 설정하는 것이다.
MCP 서버 — AI가 접근할 수 있는 외부 도구와 데이터 소스의 경계를 정한다
Hook — 특정 이벤트(커밋 전, 파일 저장 후 등)에 자동 실행되는 검증 로직을 건다
Skills — AI가 필요할 때 스스로 로드할 수 있는 능력 단위를 구성한다
Rules — 코딩 스타일, 아키텍처 원칙 등 지켜야 할 규칙을 명시한다
룰과 능력(Skills, MCP) 부여, 그리고 자동화된 피드백 루프(Hook)이 잘 결합된 환경 설계를 미리 하는 것이다.
이런 준비된 환경 위에서, 나는 어떻게 맥락과 요구사항을 넣을지를 고민하는 것이다.
그 너머: Agent Orchestration
이걸 별도의 단계로 쳐야 할지는 모르겠지만 Harness 위에서 이제 이런 환경 구성조차 전문적으로 해주는 Agent를 만들고, Agent들을 지휘(Orchestration) 하는 단계까지 가고 있다. 하위의 Agent들은 각자만의 고유한 무기(Skills)를 가지고 맡은 일을 수행하며, 상위 Agent에게 보고한다.
점점 인간 조직을 따라가고 있다고 느낀다.
프로젝트 = 팀
팀별 규칙을 정하고, 각 팀원이 하는 일을 정한다
팀원들은 팀장에게 보고하고, 팀장은 상위 리더에게 보고한다
AI가 발전하는 방향은 팀의 시스템화이다. 점점 개인의 단일 능력보다 시스템을 설계하고 운영하는 능력이 중요해지는 방향으로 나아가고 있다.
마치며
사람들이 불편함을 없애기 위해 도구를 만들고, 그 도구가 다시 사람의 역할을 바꿔놓는다.
그래서 이렇게 공부해도 공부한 것이 의미 없어질까 걱정이 들 때가 있다.
Claude가 본 나에서도 확인했지만, 끊어진 것이 아니라 하나가 다음으로 흘러간 것이다. 하지만 되돌아보면, 1년 반 동안 내가 실제로 쌓은 것은 특정 도구의 사용법 뿐만 아니라 "AI를 어떻게 인지하고, AI를 어떻게 활용하고 더 나아가 어떻게 협업할 것인가"라는 문제를 구조적으로 사고하는 능력 자체라고 생각한다.
도구는 바뀌어도, 이런 구조적/체계적 사고방식은 계속 유효할 거라고 — 적어도 지금은 — 믿고 있다.
이 흐름이 결국 어디로 향하는 걸까? 어디까지 갈까?
두려우면서도 기대가 된다.
불러오는 중...