비개발자가 바이브코딩을 시작하면 제일 먼저 무너지는 것
처음에는 모든 게 쉬워 보였다.
대화창에 “이런 기능 만들어줘”라고 적으면 AI가 구조를 짜고, 파일을 만들고, 코드까지 고쳐줬다. 예전 같으면 며칠 걸릴 일을 몇 시간 만에 해내는 느낌이었다. 그래서 자연스럽게 이렇게 생각했다.
이제 기획만 잘 말하면 제품은 AI가 만들어주겠구나.
하지만 시간이 지나면서 전혀 다른 문제가 생겼다. AI가 코드를 못 짜서가 아니었다. 오히려 코드는 너무 많이, 너무 빠르게 만들었다. 진짜 문제는 무엇을 왜 만들고 있었는지, 어느 폴더에서 작업해야 하는지, 무엇이 최신 문서인지, 완료라는 말이 실제 증거와 맞는지가 점점 흐려지는 데 있었다.
바이브코딩은 출발점일 뿐이었다
Andrej Karpathy가 “vibe coding”이라는 표현을 소개한 이후, 많은 사람이 AI와 흐름을 타듯 코딩하는 방식을 이야기하기 시작했다. 사람이 모든 코드를 직접 쓰는 대신, 의도를 말하고, 결과를 보고, 다시 방향을 조정하는 방식이다.
비개발자 입장에서 이 방식은 특히 매력적이다. 복잡한 문법을 전부 알지 못해도, AI에게 요구사항을 설명하면 프로젝트가 앞으로 나아간다. 나도 그 흐름을 탔다. 문서도 만들고, 코드도 만들고, 아키텍처도 만들어졌다.
그런데 어느 순간부터 “앞으로 나아가는 것처럼 보이는 것”과 “정말 올바른 방향으로 가는 것”이 다르다는 사실을 알게 됐다.
처음 무너진 것은 코드가 아니라 맥락이었다
AI에게 일을 맡기면 대화가 길어진다. 처음에는 PRD를 설명하고, 그다음에는 오류를 설명하고, 그다음에는 대안을 설명한다. 며칠 뒤 다시 이어가면 AI는 과거 맥락을 전부 정확하게 붙잡지 못한다.
내가 실제로 겪은 문제는 이런 식이었다.
- 예전에 실패한 기술 대안을 다시 꺼내왔다.
- 이미 버리기로 한 구조를 새 해결책처럼 제시했다.
- “완료”라고 보고했지만 실제 파일은 그대로였다.
- 초안 문서와 활성 문서가 섞여 무엇이 Source of Truth인지 헷갈렸다.
auto-video-tools에서 해야 할 일과 workspace 루트에서 해야 할 일이 뒤섞였다.- 커밋할 문서와 절대 커밋하면 안 되는 WIP 코드가 같은
git status안에 있었다. - 검토용 dump가 Desktop에 쌓여, 나중에는 무엇이 최신 검토팩인지도 헷갈릴 수 있었다.
이건 단순한 실수가 아니었다. AI가 나빠서가 아니라, 사람이 AI에게 일을 맡기는 방식이 아직 너무 느슨했던 것이다.
“AI가 완료했다”는 말은 결과가 아니라 주장이다
가장 큰 깨달음은 이 문장으로 요약된다.
| AI의 완료 보고는 결과가 아니라 주장이다. 실제 결과는 파일과 git 상태를 봐야 한다. |
AI가 “수정 완료”라고 했지만 실제 파일에는 반영이 안 되어 있거나, 반대로 요청하지 않은 파일이 수정된 경우가 있었다. 특히 여러 프로젝트가 같은 workspace 아래에 있을 때는 더 위험했다.
| <WORKSPACE_ROOT>/ ├─ auto-video-tools/ ├─ blog/ ├─ homepage/ ├─ portfolio-blog/ └─ _ai_workspace_template/ |
이 구조에서는 “지금 어디서 실행하는가”가 곧 안전장치다. workspace 루트에서 해야 할 일이 있고, 프로젝트 내부에서 해야 할 일이 있다. 이 구분이 없으면 AI는 엉뚱한 폴더를 읽거나, 다른 프로젝트의 문서를 기준으로 판단할 수 있다.
그래서 나중에는 명령어별 실행 위치까지 문서화했다.
| !새프로젝트 → <WORKSPACE_ROOT> !마스터PRD등록 → <WORKSPACE_ROOT> !PRD분해 → <WORKSPACE_ROOT> !프로젝트검증 → <WORKSPACE_ROOT> !기록 → <PROJECT_ROOT> !블로그원고업데이트 → <PROJECT_ROOT>/blog !SD2GPT → workspace mode 또는 project mode 명시 |
비개발자에게 더 중요한 것은 코딩 지식보다 운영 방식이었다
처음에는 내가 개발 지식이 부족해서 문제가 생긴다고 생각했다. 물론 개발 지식은 도움이 된다. 하지만 실제로 더 치명적이었던 것은 따로 있었다.
- 기준 문서가 어디인지 모르는 것
- 과거 실패 이력이 정리되지 않은 것
- 현재 작업 상태를 저장하지 않는 것
- 검증 없이 커밋하려는 것
- 프로젝트 경계를 나누지 않는 것
- AI에게 모든 판단을 맡기는 것
- 임시채팅을 바꾸면 흐름이 끊기는 것
이 문제들은 개발자에게도 생길 수 있지만, 비개발자에게는 더 크게 다가온다. 비개발자는 AI가 말한 내용을 코드 레벨에서 즉시 판별하기 어렵기 때문이다.
그래서 필요한 것은 “더 좋은 프롬프트 하나”가 아니었다. 필요한 것은 AI가 길을 잃지 않게 만드는 작업 운영체계였다.
내가 만들기 시작한 것
결국 나는 대화창 중심의 작업을 파일 중심으로 바꾸기 시작했다.
| AGENTS.md GEMINI.md WORKSPACE_INDEX.md WORKSPACE_SYSTEM_BIBLE.md WORKSPACE_USER_MANUAL.md WORKSPACE_COMMANDS.md WORKSPACE_HANDOFF_CURRENT.md _ai_workspace_template/ docs/ _ai_dumps/ |
각 파일은 역할을 가졌다.
AGENTS.md: AI가 따라야 하는 행동 헌법GEMINI.md: 세션 시작 시 무엇을 읽을지 알려주는 부트스트랩WORKSPACE_INDEX.md: 여러 프로젝트의 위치와 경계WORKSPACE_SYSTEM_BIBLE.md: 전체 운영 철학과 구조를 담는 지속형 바이블WORKSPACE_USER_MANUAL.md: 사람이 읽고 명령어 실행 위치를 판단하는 사용자 매뉴얼WORKSPACE_COMMANDS.md:!새프로젝트,!SD2GPT,!커밋계획같은 명령어 카탈로그_ai_workspace_template: 새 프로젝트에 복사할 공통 문서 OS 템플릿_ai_dumps: ChatGPT/외부 AI 검토용 evidence pack을 보관하는 gitignored 저장소
이 구조를 만들면서 알게 된 것은, AI 개발에서 중요한 것은 “AI에게 더 많이 맡기는 것”이 아니라 어디까지 맡기고 어디서 멈추게 할지를 정하는 것이었다.
체크리스트
비개발자가 AI 코딩을 시작하기 전에 최소한 아래를 확인하면 좋다.
- AI가 읽어야 할 기준 문서가 있는가?
- 현재 작업 상태를 저장하는 handoff 문서가 있는가?
- 완료 보고를 파일과 git 상태로 검증하는가?
- 삭제, 커밋, 배포 같은 위험 작업을 사람이 승인하는가?
- 프로젝트가 여러 개라면
<WORKSPACE_ROOT>와<PROJECT_ROOT>가 나뉘어 있는가? - 임시채팅을 바꿔도 이어갈 수 있는
SD2GPT같은 압축 프로토콜이 있는가?
다음 편 예고
다음 편에서는 왜 단순한 프롬프트 모음이 아니라, 파일 기반의 AI 작업 운영체계가 필요했는지 다룬다. AI에게 일을 시키기 전에, AI가 길을 잃지 않을 작업장을 먼저 만들어야 했다.