찐 개발자의 바이브 코딩은 다릅니다 - 클로드코드 바이브코딩 실전 워크플로우 모두 공개

🧑‍💻⚙️ 문제의식: “프롬프트 딸깍”은 복잡해지는 순간 무너집니다

AI 코딩 도구를 프롬프트로 돌리고 에러를 고치는 방식, 혹은 플랫 모드·루프·MCP·에이전트 조합을 늘리는 방식은 일정 수준을 넘는 복잡도에서 결과물이 쉽게 붕괴된다는 진단입니다. 핵심 원인은 AI가 코드를 쓰기 시작하면 아키텍처와 변경 범위를 통제하기 어려워지고, 토큰은 빠르게 소모되며, 수정이 누적될수록 시스템 전반을 망가뜨리는 구현이 숨어들기 쉽기 때문입니다. 따라서 “기획과 코딩을 분리하고, 계획을 내가 검토·승인하기 전에는 절대 코드를 쓰게 하지 않는다”는 단 하나의 원칙이 생산성과 품질을 동시에 끌어올리는 중심 규율로 제시됩니다.

🧭📌 핵심 원칙: 계획 승인 전 코딩 금지, 주도권은 사람이 잡습니다

워크플로우의 목적은 클로드가 “코드를 잘 쓰게” 만드는 것이 아니라, 코드를 쓰기 전에 “무엇을 써야 하는지”를 확실히 정의하는 데 있습니다. 계획을 먼저 문서로 만들고 사람이 검토해 방향을 주입하면, 불필요한 삽질이 줄고 아키텍처 결정권이 인간에게 남으며, 무작정 코드부터 작성할 때보다 토큰을 덜 쓰고도 더 일관된 결과를 얻을 수 있다는 주장입니다. 특히 AI 코딩에서 가장 비싼 실패는 문법 오류가 아니라, 겉보기에는 돌아가지만 레이어를 무시하거나 ORM·마이그레이션·기존 로직을 훼손하는 방식으로 주변 시스템을 서서히 망가뜨리는 변경이며, 이를 구조적으로 차단하는 장치가 리서치와 계획 단계라는 점이 강조됩니다.

🔍📚 1단계 리서치: “깊이 읽기”를 문서 산출물로 고정합니다

모든 의미 있는 작업은 코드베이스를 깊이 읽고 이해하는 것에서 시작하며, AI에게 관련 폴더와 기능을 “매우 상세히, 세부 사항까지” 파악하도록 지시한 뒤 결과를 채팅 요약으로 끝내지 않고 반드시 리서치.md 같은 마크다운 파일로 작성하게 합니다. ‘깊이/상세/세부사항’ 같은 강한 표현을 넣지 않으면 AI가 파일을 대충 훑고 함수 시그니처 수준에서 넘어가는 경향이 있어, 입력을 사람 다루듯 강하게 설계해야 한다는 운영 팁이 제시됩니다. 이 리서치 문서화는 변경이 기존 구조와 어떻게 맞물리는지 확인하는 근거가 되며, 겉보기 정상 동작 뒤에 숨어드는 구조적 파손을 예방하는 안전장치 역할을 합니다.

🧠🗺️ 2단계 계획: 상세 구현 플랜을 별도 MD로 만들고 트레이드오프까지 담습니다

리서치 검토 후에는 구현 계획을 별도 마크다운 파일(예: plan.md)로 작성하게 하며, 계획에는 접근 방식 설명, 실제 변경 예시 코드 스니펫, 수정될 파일 경로, 고려사항과 트레이드오프까지 포함시키는 방식입니다. 또한 계획을 쓰기 전에 실제 코드베이스를 읽고 “현 상태를 기반으로” 설계를 세우라고 지시해 공중설계를 방지합니다. 내장 플랫 모드 대신 MD 파일을 고집하는 이유는 에디터에서 직접 편집하며 인라인 메모를 달 수 있고, 세션이 날아가도 프로젝트 내부에 산출물이 남아 작업 연속성이 유지되기 때문입니다.

📝🔁 3단계 주석 루프: 문서의 ‘정확한 위치’에 인간 판단을 주입합니다

가장 중요한 구간은 ‘계획 작성 → 사람 검토·주석 → AI 업데이트’의 반복 루프입니다. 사람은 에디터에서 계획 문서의 특정 위치에 인라인 메모로 잘못된 가정 수정, 접근 방식 거부, 제약 조건 추가, 도메인 지식 전달 등을 수행하며, 메모는 “선택 사항 아님”, “여기 캐싱 불필요”, “중복 로직 제거”, “스키마 구조 재설계”처럼 짧을 수도 있고 한 문단 이상의 상세 조건이 될 수도 있습니다. 이후 AI에게 “메모를 반영해 문서를 업데이트하되 아직 구현하지 말라”를 명시적으로 반복해, AI가 임의로 ‘충분하다’고 판단하고 코딩에 들어가는 것을 차단하며, 만족할 때까지 1~수회 반복하는 방식으로 계획의 정확도를 끌어올립니다.

🧱🚧 구현 전 제어: “아직 구현하지 마”가 없으면 주도권이 넘어갑니다

이 방식에서 구현 금지 문구는 단순한 예절이 아니라 통제 장치입니다. AI는 일정 수준의 계획이 모였다고 느끼면 스스로 구현을 시작하려는 경향이 있어, 사람이 승인하기 전까지는 계획 문서 완성도를 끌어올리는 데만 집중하게 만들어야 합니다. 결과적으로 설계 판단은 주석 루프에서 끝나고, 구현 단계는 결정된 내용을 기계적으로 실행하는 단계로 격하되며, 이것이 의도된 품질관리 구조라는 설명입니다.

🛠️🏃 4단계 구현: “지루한 구현”을 목표로 표준 프롬프트로 밀어붙입니다

계획이 확정되면 구현을 시작하며, 이때는 세션마다 재사용하는 표준 프롬프트로 실행 규율을 고정합니다. 예를 들어 전체 구현을 진행하고, 완료한 작업은 계획 문서에서 완료로 표시하며, 모든 작업이 끝날 때까지 멈추지 말고, 느슨한 타입을 쓰지 말며, 타입 체크를 지속적으로 돌려 새 문제를 만들지 말라는 식의 지침을 포함합니다. 이 단계의 핵심은 ‘창의성’이 아니라 ‘집행’이며, 설계가 이미 끝났기 때문에 구현이 지루할수록 성공이라는 관점입니다. 구현 중 사람의 역할은 아키텍트에서 감독자로 바뀌며, 프롬프트는 “빠진 함수 구현”, “잘못 놓인 설정 페이지 이동”, “UI 간격 2px 수정”처럼 짧고 구체적인 수정 지시로 전환됩니다.

🧪🖼️ 프론트엔드·검증: 반복 수정은 짧게, 시각 문제는 스크린샷이 효율적입니다

특히 프론트엔드 작업은 브라우저에서 테스트하며 빠른 수정 지시를 반복하는 형태가 많아지고, 정렬·간격·테이블 어긋남 같은 시각적 문제는 말로 설명하기보다 스크린샷 한 장으로 전달하는 것이 효율적이라는 운영 팁이 제시됩니다. 즉, 구현 단계에서는 긴 설명보다 명확한 관찰 결과와 최소 지시로 피드백 루프를 빠르게 돌리는 방식이 생산성을 좌우합니다.

🔄🧨 잘못된 방향 처리: 패치보다 ‘깃 리셋/리버트 + 범위 축소’가 낫습니다

AI가 잘못된 방향으로 가기 시작하면 그 위에서 조금씩 패치해 고치려 하지 말고, 깃을 통째로 되돌린 뒤 범위를 다시 좁히는 방식이 거의 항상 더 좋은 결과를 만들었다는 경험칙이 제시됩니다. 점진 수정은 잘못된 기반(모래성) 위에 계속 쌓는 형태가 되어 복잡도와 부작용을 키우기 쉬우며, “전부 되돌리고 이번에는 이것만 하라”처럼 목표 범위를 재정의하는 방식이 통제력과 품질을 회복하는 빠른 길이라는 결론입니다.

🎛️🧭 운전대 유지: 무엇을 만들지는 인간이, 실행은 AI가 담당합니다

AI에게 실행을 맡기되 “뭘 만들지”에 대한 결정권은 넘기지 않는 것이 원칙이며, 방향 조정은 대부분 플랜 MD 문서 위에서 이뤄집니다. 좋은 옵션은 취하고 불필요한 복잡성은 버리며, 읽기 쉬운 함수 분리, ROI가 낮은 기능 삭제(예: 다운로드 기능은 지금 제외), 건드리면 안 되는 API 시그니처 고정, 기술 선택은 사람이 결정(특정 모델/라이브러리 사용 강제) 같은 통제 항목들이 예시로 제시됩니다. 이는 AI가 ‘만들고 싶은 것’을 만들어버리는 위험을 차단하고, 제품·기술 의사결정을 인간에게 고정시키는 운영 방식입니다.

🧵🕰️ 하나의 긴 세션: 리서치→계획→주석→구현을 끊지 않고 이어갑니다

리서치·기획·구현을 세션으로 쪼개지 않고 하나의 긴 세션에서 이어가는 방식이 소개되며, 컨텍스트 윈도우가 커지면 성능이 떨어진다는 통념을 크게 체감하지 않는 이유로 “이미 세션 내에서 이해가 누적된 상태”와 “오토 컴팩션이 충분한 맥락을 유지”한다는 경험이 제시됩니다. 또한 핵심 계획과 리서치는 MD 파일로 프로젝트에 남기 때문에, 세션이 압축되거나 종료돼도 의사결정의 원본 근거가 보존된다는 점이 장점으로 강조됩니다.

🧩📌 최종 정리: ‘쉐어드 뮤터블 스테이트’ 기반 인간 주도 루핑입니다

전체 방법론은 마법 같은 프롬프트나 복잡한 해킹이 아니라, 생각(리서치·계획·판단)과 타이핑(구현)을 분리하는 규율 있는 파이프라인으로 요약됩니다. 리서치는 무지한 변경을 막고, 계획은 잘못된 변경을 막으며, 주석 루프는 인간의 판단과 제약을 문서의 정확한 위치에 주입해 AI의 실행을 올바른 궤도로 고정합니다. 채팅창에서 장황하게 설명하기보다 계획 MD라는 공유 문서를 “함께 수정 가능한 상태”로 두고 반복 업데이트시키는 방식이 에이전트 코딩에서 가장 실용적인 인간 주도 워크플로우라는 결론입니다.