AI와 함께 MVP를 만들 때 운영자가 붙잡아야 할 것은 코드가 아니라 판단이다

2026년 6월 7일

AI협업개발바이브코딩로컬MVP운영판단Claude Code

바이브 코딩은 AI에게 전부 맡기는 것이 아니다

쇼츠/릴스 생성기를 만들 때 Claude Code에게 코드 구현을 맡겼다. 그런데 AI에게 구현을 맡긴다는 것이 AI에게 전부를 맡긴다는 뜻은 아니었다.

AI는 “어떻게”를 구현하는 데 강하다. 그런데 “무엇을 왜 만드는지”, “어디까지 만들고 어디서 멈출지”는 운영자가 판단해야 한다. 이 판단이 없으면 AI는 계속 기능을 추가하거나, 이미 충분한 상태에서도 더 많은 것을 제안하게 된다.

구현은 Claude Code가, 방향·검증·판단은 운영자가 맡았다

이번 개발에서 역할은 명확하게 나뉘었다.

Claude Code는 Next.js, FastAPI, FFmpeg, Pillow를 연결하고 기능을 코드로 구현했다. 운영자는 어떤 기능이 필요한지 우선순위를 정하고, 기능이 실제로 의도대로 작동하는지 직접 확인하고, 언제 다음 단계로 넘어갈지 판단했다.

이 역할 분리가 잘 작동할 때는 실행 속도가 빠르다. 운영자가 방향을 잡고 검증하면, AI는 그 방향에서 구현을 처리한다. 그런데 역할 경계가 흐릿해지면—예를 들어 운영자가 검증 없이 AI의 제안을 그대로 수용하면—MVP가 아니라 기능이 과다한 미완성 프로덕트가 된다.

MVP에서 가장 중요한 것은 기능 수가 아니라 완료 기준이다

이번 MVP를 돌아보면 가장 중요한 결정은 기능을 추가하는 것이 아니라 “여기서 1단계를 마친다”고 선언하는 일이었다.

완료 기준을 정하지 않으면 MVP는 끝나지 않는다. 언제나 추가할 기능이 있고, 더 다듬을 여지가 있다. 이번에는 세 가지 기준을 정했다: 핵심 기능이 실제로 작동하는가, 최소 편집 기능이 갖춰졌는가, 문서화로 재현 가능한가. 세 가지를 충족했을 때 1단계 완료로 판단했다.

기능 추가보다 어디서 멈출지 판단하는 것이 더 어렵다

드래그 편집, AI 장면 분석, OCR, 배포 기능 모두 “있으면 좋겠다”는 생각이 드는 것들이었다. 하지만 모두 2단계 보류로 분류했다.

멈추는 판단이 더 어렵다. 기능을 추가하는 것은 AI에게 요청하면 된다. 하지만 “지금 이 기능을 넣을 이유가 충분한가”를 판단하는 것은 운영자가 해야 한다. 멈추는 능력이 MVP의 핵심이다.

오류 설명 능력이 AI 협업 개발의 핵심이다

개발 과정에서 오류는 반드시 생긴다. AI가 오류를 해결하는 속도는 빠르지만, 그 속도는 운영자가 오류를 얼마나 명확하게 설명하느냐에 달려 있다.

“안 돼요”는 AI가 활용할 수 없는 정보다. “어떤 기능을, 어떤 입력으로 테스트했을 때, 어떤 오류 메시지가 나왔다”는 정보가 있어야 AI가 정확하게 대응할 수 있다. 오류를 설명하는 능력이 AI 협업 개발의 실질적인 병목이다.

문서화는 개발 기록이 아니라 다음 작업을 위한 운영 자산이다

README, CHANGELOG, LOCAL_RUN, FEATURES, KNOWN_ISSUES, ROADMAP을 만들었다. 이 문서들은 기록을 위한 기록이 아니다.

LOCAL_RUN이 없으면 다음에 같은 환경에서 다시 실행하려고 할 때 처음부터 시작해야 한다. KNOWN_ISSUES가 없으면 이미 알고 있는 문제를 다시 발견하는 시간을 낭비한다. ROADMAP이 없으면 2단계를 시작할 때 무엇을 검토해야 하는지 기억에 의존해야 한다.

문서화는 개발이 끝난 뒤의 정리가 아니라, 다음 작업을 가능하게 하는 준비다.

이번 경험을 다른 MVP에 적용할 때의 기준

이번 경험에서 얻은 기준을 정리하면 이렇다.

시작 전에 완료 기준을 먼저 정한다. 기준이 없으면 끝이 없다.
역할을 분리한다. 운영자는 판단, AI는 구현.
최소 기능부터 작동시킨다. 처음부터 완성된 기능을 만들려 하지 않는다.
오류는 구체적으로 설명한다. “안 된다”가 아니라 “무엇을 어떻게 했을 때 어떤 오류가 났다”.
멈출 줄 안다. 기능을 더 넣는 것보다 1단계를 완료로 닫는 것이 더 중요할 수 있다.
문서화는 마지막이 아니라 1단계의 일부다.