Karpathy Vibe Coding MenuGen: 20% 데모와 80% 제품화의 차이를 가릅니다 | DAKER 커뮤니티

MenuGen은 Karpathy가 직접 만든 첫 end-to-end vibe coded 앱 사례입니다. 로컬 데모는 놀랄 만큼 빨라졌지만, 인증·결제·배포·API 키·rate limit·데이터베이스·큐는 여전히 현실의 복잡도입니다.

오늘 배울 것

바이브 코딩에서 “코드가 공짜가 됐다”와 “제품이 공짜가 됐다”를 구분하는 방법을 배웁니다. 오늘은 로컬 데모와 제품화 체크리스트를 분리하고, 초기에 리스크로 표시할 항목을 고정합니다.

핵심 개념

AI로 로컬 데모를 만드는 일은 매우 빨라졌습니다. 하지만 실제 제품으로 만들려면 브라우저 설정, API 문서, OAuth, 결제, 배포 환경변수, rate limit, 데이터베이스, 큐 같은 접착 작업이 남습니다. 좋은 프롬프트만으로는 운영 복잡도가 사라지지 않습니다.

오히려 AI가 직접 다루기 어려운 브라우저 기반 상태와 설정이 새 병목이 됩니다. 그래서 진행률을 “화면이 돌아간다”로 재지 말고, “사용자가 가입·결제·재방문까지 통과한다”로 재야 합니다.

설명용 생성 이미지입니다.

따라 해볼 실습

1) 로컬 데모 체크리스트와 제품화 체크리스트를 두 장으로 분리합니다. 데모 칸에는 UI·핵심 경로만 둡니다.

2) 인증·결제·배포·데이터 저장·rate limit을 초기에 리스크로 표시합니다. 각각에 “누가 설정하는지”, “어디서 검증하는지”를 한 줄씩 적습니다.

3) AI에게 코드만 맡기지 말고, 공식 문서 확인과 설정 검증 단계를 요청합니다. 예: “이 OAuth 콜백 URL이 문서와 일치하는지 확인하라.”

4) 데모가 돌아가도 제품화 칸이 비어 있으면 “완료”로 부르지 않습니다. 다음 한 수정은 가장 큰 리스크 한 칸만 닫습니다.

자주 막히는 지점

가장 흔한 막힘은 로컬에서 예쁘게 보이는 순간을 제품 완성과 혼동하는 경우입니다. 또 다른 막힘은 인증·결제·배포를 마지막에 몰아넣다가 일정 전체가 흔들리는 경우입니다. 막히면 기능을 늘리지 말고, 제품화 체크리스트의 빈칸 하나부터 닫습니다.

다음 학습 연결

데모와 제품화를 구분했다면, 한 번에 하나만 바꾸는 디버깅 습관과 Software 2.0의 목적함수·평가 설계로 이어가면 좋습니다. 검증 가능한 제출 루프를 학습 디렉터리에서 이어서 연습할 수 있습니다.