바이브 코딩(Vibe coding)은 무언가를 변경하려고 시도하기 전까지만 작동합니다

첫 번째 버전은 거의 항상 작동합니다. 그것이 바로 아무도 준비되지 않은 부분입니다. 당신은 원하는 것을 한 문장으로 설명하고, 2분 동안 기다리면, 작은 도구가 당신의 브라우저에서 실행됩니다. 마치 마술처럼 느껴집니다.
두 번째 순간은 느낌이 다릅니다. 당신은 작은 것 하나를 바꾸고 싶어 합니다. 모델은 즐겁게 파일의 절반을 다시 작성합니다. 이제 방금 전까지 작동하던 부분이 고장 났고, 당신은 왜 그런지 알 수 없습니다. 이곳이 바로 유용한 바이브 코딩(vibe coding)이 일회용 코드(throwaway code)와 갈라지는 정확한 지점입니다.
나는 지난 1년 동안 주로 자연어(natural language)를 통해, 보통 Next.js와 그 뒤에 Supabase를 사용하여 중소규모 앱을 구축하며 시간을 보냈습니다. 내가 배운 것의 짧은 요약은 다음과 같습니다. 병목 현상은 더 이상 코드를 타이핑하는 것이 아닙니다. 그것은 당신이 사물을 얼마나 정확하게 설명하는지, 그리고 돌아온 결과물을 얼마나 주의 깊게 읽는지에 달려 있습니다. 그것을 제대로 하면 6개월 후에도 여전히 유지보수할 수 있는 결과물을 얻게 됩니다. 그것을 무시하면, 당신은 기록적인 속도로 아무도 건드리고 싶어 하지 않는 바로 그런 종류의 시스템을 만들어내게 됩니다.

바이브(vibe)보다는 명세(spec)가 낫다

"바이브 코딩(vibe coding)"이라는 문구는 약간 오해의 소지가 있습니다. 이는 당신이 그저 분위기(vibe)를 타면 코드가 나타난다는 것을 암시합니다. 실제로 그 반대가 사실입니다. 첫 번째 프롬프트(prompt)가 명확할수록, 그 이후에 필요한 반복 횟수가 줄어듭니다.

약한 시작은 다음과 같습니다:
우리 판매 수치를 위한 대시보드를 만들어줘.

좋은 시작은 모델에게 추측해야 할 컨텍스트(context)를 직접 전달합니다:
기존의 Next.js App Router 프로젝트의 /dashboard에 페이지를 추가해줘. 데이터는 date, region, amount 컬럼이 있는 "sales"라는 이름의 Supabase 테이블에서 가져와. 지역별 총액을 보여주는 막대 차트를 보여주고, 그 아래에는 정렬 가능한 테이블을 보여줘. 기존 ui 폴더에 있는 컴포넌트들을 재사용해. 먼저 묻지 않고 새로운 의존성(dependencies)을 추가하지 마.

그 차이는 기계에게 예의를 갖추느냐의 문제가 아닙니다. 차이점은 두 번째 버전이 결정을 열어두는 대신 스스로 결정을 내린다는 데 있습니다. 당신이 건너뛰는 모든 결정은 모델이 대신 내리게 되며, 모델은 실행할 때마다 매번 조금씩 다른 결정을 내립니다.

이 마지막 문장은 보기보다 훨씬 중요합니다. "묻지 않고 새로운 의존성(dependencies)을 추가하지 마"라는 문구는, 모델이 당장 편리해 보인다는 이유로 package.json에 세 개의 추가 패키지를 몰래 작성하는 것을 방지합니다. 프롬프트에 한 번 작성해 둔 이러한 가드레일(Guardrails)은 나중에 당신의 시간을 몇 시간이나 아껴줍니다.

작은 단계, 아니면 고통

가장 흔한 실수는 모델에게 한꺼번에 너무 많은 것을 맡기고, 큰 변경 사항이 기존 코드 전체에 걸쳐 실행되도록 방치하는 것입니다. 이 모델들은 당신이 요청한 것보다 더 많은 것을 다시 쓰는 것을 좋아합니다. 400줄짜리 파일에 "날짜 형식을 변경해줘"라는 작업 하나만 지정해도, 날짜 형식은 맞지만 다른 세 가지 요소가 미묘하게 망가진 400줄짜리 파일을 돌려받게 됩니다.

도움이 되는 방법은 지루하지만 효과적입니다. 단위를 작게 유지하세요. 실행당 하나의 함수, 하나의 컴포넌트, 또는 명확하게 범위가 지정된 하나의 작업만 수행하세요. 그리고 작동하는 상태가 될 때마다 커밋(commit)하세요. 여기서 Git은 단순히 있으면 좋은 추가 기능이 아닙니다. 그것은 당신의 안전벨트입니다. 다음 실행에서 무언가 망가졌을 때, 탐정 놀이를 하는 대신 2초 만에 되돌릴 수 있습니다.

이제 저의 루프(loop)는 거의 항상 동일합니다. 작동하는 상태 확인, 커밋, 한 가지 변경, 테스트, 커밋. 이것이 더 많은 오버헤드(overhead)처럼 들릴 수도 있습니다. 하지만 결국에는 더 빠릅니다. 왜냐하면 한꺼번에 몰려온 뒤섞인 변경 사항들을 하나하나 풀어내야 하는 상황에 결코 빠지지 않기 때문입니다.

당신이 코드를 소유하므로, 코드를 읽으세요

바이브 코딩 (vibe coding)에서 가장 위험한 문장은 "뭐, 일단 돌아가긴 하네"입니다. 무언가가 실행된다는 사실은 그것이 올바른 일을 수행하는지, 혹은 안전한지에 대해 아무것도 알려주지 않습니다.

실제 사례를 들어보겠습니다. 모델에게 Supabase에서 데이터를 로드하도록 요청하면, 모델은 종종 쿼리를 클라이언트 컴포넌트 (client component)에 직접 작성하고 행 레벨 보안 (Row Level Security, RLS)에 대해서는 전혀 언급하지 않습니다. 테스트 데이터로 진행하는 데모에서는 이런 문제가 전혀 드러나지 않습니다. 하지만 실제 사용자와 실제 데이터가 유입되는 순간, 당신은 인지하지도 못한 채 데이터 유출 사고를 배포하게 됩니다. 모델은 "코드가 컴파일된다"는 관점에서는 아무런 잘못을 하지 않았습니다. 단지 당신의 설정에서 틀린 것으로 판명될 가정을 했을 뿐입니다.

따라서 생성된 코드를 완성된 제품이 아닌 초안 (draft)으로 취급하십시오. 모든 코드를 기억력에 의존해 직접 한 줄 한 줄 쓸 수 있을 필요는 없습니다. 하지만 코드를 읽고 그것이 무엇을 하는지 따라갈 수 있어야 합니다. 이해되지 않는 지점에 도달하면, 코드를 수락하기 전에 모델에게 설명을 요구하십시오. 그 5분의 시간은 전체 프로세스에서 가장 가치 있는 투자입니다.

이득을 보는 지점과 그렇지 않은 지점

충분한 프로젝트를 거치고 나면, 바이브 코딩이 실제로 시간을 절약해 주는 작업의 패턴이 나타납니다.

범위가 제한된 내부 도구(internal tools)에서 빛을 발합니다. 설정 도구 (configurators), 보고서 (reports), 프로토타입 (prototypes), 작은 자동화 도구 등이 이에 해당합니다. 명확한 작업이 있고, 잘못되었을 때의 영향 범위 (blast radius)가 낮은 것이라면 무엇이든 좋습니다. 위에서 언급한 사항들을 따른다면, 2주짜리 프로젝트가 이곳에서는 품질 저하 없이 단 몇 시간 만에 끝나는 일도 흔합니다.

하지만 시스템이 거대하고, 밀접하게 연결되어 있으며, 비즈니스에 핵심적 (business critical)인 경우에는 상황이 비참해집니다. 움직이는 부품이 많아질수록, 언어만으로 통제력을 유지하기는 더 어려워집니다. 그렇다고 해서 해당 시스템에서 AI를 완전히 배제하라는 뜻은 아닙니다. 제안을 맹목적으로 수용하는 대신, 그 제안을 판단할 수 있는 숙련된 개발자를 프로세스에 포함시키라는 의미입니다.

이 경계선을 솔직하게 아는 것은 결코 약점이 아닙니다. 그것은 바이브 코딩을 생산적으로 사용하는 사람과, 스스로에게 새로운 문제 세트를 안겨주는 사람 사이의 차이입니다.

실제적인 변화

만약 제가 이 모든 것을 한 가지로 요약해야 한다면, 그것은 바로 이것입니다. 바이브 코딩 (Vibe coding)은 프로그래밍을 더 빠르게 만들어주지 않습니다. 그것은 소프트웨어를 구축할 수 있는 사람의 범위를 변화시킵니다. 자신의 문제를 완벽하게 파악하고 있지만 코딩을 배운 적이 없는 사람이라도, 제가 여기서 설명한 몇 가지 습관만 익힌다면 이제 작동하는 솔루션을 구축할 수 있습니다.

명확한 사양 (spec)을 작성하세요. 작은 단계로 작업하세요. 수락한 코드를 읽으세요. 자신의 한계가 어디인지 파악하세요. 이 중 어느 것도 비밀이 아니며 마법도 아닙니다. 이것은 새로운 도구가 포함된 하나의 기술 (craft)입니다. 그리고 다른 모든 도구와 마찬가지로, 결과는 도구가 아니라 그것을 쥐고 있는 손에 달려 있습니다.