MenuGen이 보여준 것: 20% 데모와 80% 제품화는 왜 다른가 | DAKER 커뮤니티

AI로 로컬 데모를 만드는 속도는 분명히 빨라졌습니다. 화면이 빠르게 돌아가고 핵심 기능이 눈앞에서 작동하면, 이제 제품도 거의 다 왔다고 느끼기 쉽습니다. 하지만 MenuGen 사례는 그 다음 단계가 전혀 다른 종류의 일이라는 점을 또렷하게 보여줍니다.

Karpathy가 직접 만든 첫 end-to-end vibe coded 앱 사례인 MenuGen은, 바이브 코딩이 어디까지 쉬워졌고 어디서부터 다시 현실의 복잡도가 시작되는지를 잘 드러냅니다. 지금 이 구분을 분명히 해두면, 데모를 제품으로 착각해 일정과 기대를 함께 흔드는 일을 줄이는 데 도움이 됩니다.

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

로컬 데모가 빨라져도 제품화가 남는 이유

바이브 코딩에서는 코드 작성 자체가 훨씬 쉬워진 것처럼 보입니다. 하지만 코드가 빨라졌다고 해서 제품이 저절로 완성되지는 않습니다. 실제 제품으로 이어가려면 브라우저 설정, API 문서, OAuth, 결제, 배포 환경변수, rate limit, 데이터베이스, 큐 같은 접착 작업이 남습니다.

코드가 공짜에 가까워졌다고 해서 제품이 공짜가 된 것은 아닙니다.

이 구분이 중요한 이유는, 좋은 프롬프트만으로 운영 복잡도까지 사라지지는 않기 때문입니다. 특히 AI가 직접 다루기 어려운 브라우저 기반 상태와 설정은 새로운 병목이 되기 쉽습니다. 그래서 진행률을 판단할 때도 단순히 화면이 돌아가는지보다, 사용자가 가입하고 결제하고 다시 방문하는 흐름까지 통과하는지를 기준으로 보는 것이 좋습니다.

진행률은 화면이 돌아가는지가 아니라 사용자가 가입·결제·재방문까지 통과하는지로 재야 합니다.

데모와 제품화 체크리스트를 나눠서 보는 방법

이 문제를 가장 단순하게 다루는 방법은 체크리스트를 처음부터 두 장으로 나누는 것입니다. 하나는 로컬 데모용, 다른 하나는 제품화용입니다. 데모 칸에는 UI와 핵심 경로만 두고, 제품화 칸에는 인증·결제·배포·데이터 저장·rate limit 같은 항목을 따로 적어두면 됩니다.

이때 중요한 점은 제품화 항목을 뒤로 미루지 않는 것입니다. 각 항목마다 누가 설정하는지, 어디서 검증하는지를 한 줄씩 적어두면 막연한 불안이 실제 리스크로 바뀝니다. 그러면 무엇이 아직 구현이 아니라 검증의 문제인지도 더 분명해집니다.

초기에 리스크로 표시해야 할 항목

인증·결제·배포·데이터 저장·rate limit은 초기에 리스크로 표시해두는 편이 좋습니다. 이 항목들은 마지막에 한꺼번에 붙이기 시작하면 전체 일정이 흔들리기 쉽기 때문입니다.

또한 AI에게 코드만 맡기기보다, 공식 문서 확인과 설정 검증 단계까지 함께 요청하는 방식이 더 현실적입니다. 예를 들어 OAuth를 붙일 때는 단순 구현보다 이 OAuth 콜백 URL이 문서와 일치하는지 확인하라처럼 검증 가능한 요청으로 바꾸는 것이 도움이 됩니다.

제품화의 핵심은 기능 추가보다 설정과 검증을 통과시키는 데 있습니다.

자주 막히는 지점과 대응 방식

가장 흔한 막힘은 로컬에서 예쁘게 보이는 순간을 제품 완성과 혼동하는 경우입니다. 또 다른 막힘은 인증·결제·배포를 마지막에 몰아넣다가 일정 전체가 흔들리는 경우입니다.

이럴 때는 기능을 더 늘리기보다, 제품화 체크리스트의 빈칸 하나를 닫는 데 집중하는 것이 좋습니다. 데모가 돌아가더라도 제품화 칸이 비어 있다면 완료라고 부르지 않는 기준이 필요합니다. 다음 수정도 가장 큰 리스크 한 칸만 닫는 방식으로 잡으면 우선순위가 흐트러지지 않습니다.

다음 학습으로 이어가기

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

참고 자료

https://daker.ai/community/karpathy-nn-recipe-debug-one-change-at-a-time
https://daker.ai/community/post-mtuo1zv7-40351d93
https://daker.ai/community/post-mtuo1yky-6e2a7d78
https://daker.ai/community?directory=learning

여러분은 로컬 데모가 제품처럼 보였던 순간을 어떻게 구분하고 계신가요?