바이브 코딩은 어떻게 하나요?

바이브 코딩이 실제로 여러분에게 요구하는 것

바이브 코딩은 방법론이 없는 것처럼 들리는데, 바로 그 때문에 많은 사람에게서 잘못되기 쉽습니다. 모델에게 코드를 쓰게 하면 문법 문제는 사라지지만, 항상 어려운 부분이었던 두 가지 일 — 무엇이 일어나야 하는지 정확히 말하는 것과, 그것이 실제로 일어났는지 확인하는 것 — 은 사라지지 않습니다. 여러분의 노력은 사라지는 것이 아니라 옮겨 갈 뿐입니다 — 코드를 타이핑하는 것에서, 명세를 쓰고 검토하는 것으로. 이 용어가 어디서 왔는지는 바이브 코딩을 참고하세요.

바로 이 때문에 똑같은 도구를 쓰는 두 창업자가 완전히 다른 결과를 얻습니다. "마켓플레이스를 만들어 줘"로 시작하는 사람은 두 번째 기능에서 무너지는 데모를 얻습니다. 사용자, 데이터, 그리고 버전 1이 반드시 해야 할 단 하나의 일을 명시한 한 단락으로 시작하는 사람은 그 위에 계속 지어 나갈 만한 무언가를 얻습니다. 도구 선택은 대부분의 비교 글이 암시하는 것만큼 중요하지 않습니다 — 가장 좋은 바이브 코딩 도구에서 그 부류들이 어떻게 다른지 다루고 있습니다 — 어떤 도구를 고르든 아래의 루프는 동일하기 때문입니다.

단계별 루프

1. 프롬프트 전에 명세부터 쓰세요 ——한 단락이면 됩니다: 누가 이것을 쓰는지, 무엇을 해야 하는지, 어떤 데이터를 저장하는지, 그리고 버전 1에서 명시적으로 하지 않을 일은 무엇인지. 여기에 10분을 쓰면, 여러분이 말하지 않은 모든 것을 모델이 추측하다가 결국 다시 만들어야 하는 상황을 막을 수 있습니다.
2. 한 번에 한 조각씩 만드세요 ——처음부터 끝까지 돌아가는 가장 작은 것을 요청하고, 실제로 돌아가는지 확인한 다음, 거기서 확장하세요. 하나의 거대한 프롬프트는 현실적으로 검토할 방법이 없는 넓은 표면적을 만들어 냅니다.
3. 무언가 작동할 때마다 커밋하세요 ——버전 관리는 생성형 작업을 위한 되돌리기 버튼입니다. 다음 변경이 한 번에 세 가지를 망가뜨렸을 때, 정상 작동이 확인된 커밋만이 되돌아갈 유일하게 믿을 만한 방법이며, 만드는 데는 명령 하나면 충분합니다.
4. 위험한 부분은 직접 읽으세요 ——로그인, 결제, 고객 데이터를 건드리는 모든 것, 그리고 무언가를 삭제하는 모든 것이 해당합니다. 모델은 그럴듯해 보이는 코드를 쓰지만 어떤 검사를 건너뛰었는지는 알려 주지 않으므로, 나머지는 넘어가더라도 이 경로들만큼은 한 줄씩 직접 읽으세요.
5. 낯선 사람처럼 테스트하세요 ——처음 쓰는 사용자처럼 클릭해 보세요: 잘못된 입력, 빈 상태, 뒤로 가기 버튼, 두 번째 계정. 생성된 앱은 대개 프롬프트가 설명한 경로에서는 맞게 동작하고 그 외의 모든 곳에서는 부실합니다.
6. 변경 기록을 남기세요 ——조각을 만들 때마다 모델에게 무엇을 바꿨고 왜 바꿨는지 요약해 달라고 요청하고, 그 글을 프로젝트와 함께 보관하세요. 이는 여러분 자신을 포함해 누구에게도 더 이상 설명할 수 없는 코드베이스가 되는 것을 막는 가장 값싼 방어책입니다.

무너지는 지점

실패 패턴은 도구마다 일관되며, 그중 어느 것도 사실 모델이 코드를 잘 못 써서 생기는 문제가 아닙니다:

• 조용한 가정 ——모델은 여러분이 의도한 것이 아니라 여러분이 말한 것을 만듭니다. 말하지 않은 모든 것은 그럴듯한 무언가로 채워지고, 그 틈은 실제 사용자가 그 부분에 부딪혔을 때 발견됩니다.
• 조용히 멈춰 버리는, 원래 작동하던 것들 ——생성된 수정은 겉으로 보이는 것보다 더 멀리까지 영향을 미칩니다. 매 변경 후에 전체를 실행해 볼 수 없다면, 마지막 변경이 무엇을 망가뜨렸는지 한참 뒤에야 알아차리게 됩니다.
• 여러분이 선택한 적 없는 보안 ——기본 접근 규칙, 지나치게 느슨한 데이터베이스 정책, 커밋되면 안 될 곳에 커밋된 키가 생성된 앱에는 흔하며, 아무것도 경고해 주지 않습니다. 출시 후가 아니라 출시 전에 확인하세요.
• 마지막 20퍼센트 ——처음 80퍼센트는 한나절이면 도착합니다; 나머지는 모델이 여러분에게 시스템을 진짜로 이해하기를 요구하는 지점입니다. 그 구간을 위한 시간을 따로 두거나, 아예 그런 구간이 없도록 버전 1의 범위를 정하세요.

작동한 다음에 일어나는 일

이 루프를 끝내면 아무도 존재를 모르는, 작동하는 소프트웨어를 얻게 되는데, 이는 이제 표준적인 창업자의 상황입니다: 만드는 비용은 극적으로 낮아졌지만 유통은 그렇지 않았습니다. 더 만들기 전에 버전 1이 실제로 무엇을 위한 것인지 정하세요 — 이것이 바로 최소 기능 제품의 핵심입니다 — 그리고 그것이 작동하면, 다음 질문은 바이브 코딩 앱을 마케팅하는 법입니다.

직접 겪은 이야기: agentceres.com의 AI 성장 책임자인 AgentCeres를 만들면서 — 저희 코드와 마케팅 페이지 대부분은 AI가 초안을 쓰고 사람이 검토합니다. 가장 값비쌌던 실수는 나쁜 코드가 아니었습니다. 조용히 사라져 버린 작업이었습니다. 두 개의 변경이 병렬로 생성되었고, 각각은 자신이 작성된 시점의 기준에서는 옳았고 모든 점검을 통과했지만, 둘을 합친 순간 깨져 버렸습니다 — 아무도 합쳐진 결과에 대해 점검을 다시 실행하지 않았기 때문입니다. 이 페이지에서 습관 하나만 가져간다면 이것을 가져가세요: 작게 나누고, 방금 생성한 조각이 아니라 실제로 배포한 것을 검증하세요.