6개월 후에도 직접 수정 가능한 바이브 코딩 (Vibe Coding)

첫 번째 버전은 거의 항상 작동합니다. 이것이 사람들이 _바이브 코딩 (Vibe Coding)_을 시작할 때 모두를 놀라게 하는 부분입니다. 당신이 필요한 것을 한 문장으로 설명하면, 2분 뒤에 브라우저에서 작은 도구가 실행됩니다. 이 순간은 마치 마법처럼 느껴집니다.

두 번째 순간은 느낌이 다릅니다. 아주 작은 것을 변경하고 싶을 뿐인데, 모델이 파일의 절반을 과도하게 다시 작성해 버리고, 갑자기 이전에는 잘 작동하던 부분이 작동하지 않게 됩니다. 바로 이 지점에서 사용 가능한 바이브 코딩 (Vibe Coding)과 일회용 코드 (Wegwerf-Code)가 갈립니다.

저는 1년 넘게 주로 자연어(Natural Language)를 사용하여, 대부분 백엔드에 Supabase를 사용하는 Next.js 기반의 중소규모 애플리케이션을 구축해 왔습니다. 이 기간 동안 제가 배운 것은 한 문장으로 요약할 수 있습니다: 병목 현상은 더 이상 코드를 타이핑하는 것이 아닙니다. 병목 현상은 당신이 얼마나 정밀하게 설명하는지, 그리고 얼마나 철저하게 검토(Proofreading)하는지입니다. 이를 내면화하는 사람은 6개월 후에도 유지보수가 가능한 결과를 얻습니다. 이를 무시하는 사람은 나중에 아무도 건드리고 싶어 하지 않을 종류의 시스템을 기록적인 속도로 만들어냅니다.

명세(Specification)가 분위기(Stimmung)를 이긴다
"바이브 코딩 (Vibe Coding)"이라는 용어는 단순히 느낌대로(vibe) 해나가는 것처럼 암시하기 때문에 오해의 소지가 있습니다. 실제로는 그 반대입니다. 첫 번째 프롬프트 (Prompt)가 명확할수록, 그 이후에 필요한 반복 횟수가 줄어듭니다.

명세 (Specification)가 분위기 (Stimmung)를 이긴다

"바이브 코딩 (Vibe Coding)"이라는 용어는 단순히 느낌대로 해나가는 것처럼 암시하기 때문에 오해의 소지가 있습니다. 실제로는 그 반대입니다. 첫 번째 프롬프트 (Prompt)가 명확할수록, 그 이후에 필요한 반복 횟수가 줄어듭니다.

나쁜 시작의 예시는 다음과 같습니다:
우리 판매 실적을 위한 대시보드를 만들어줘.

좋은 시작은 모델이 추측해야 할 상황에 맥락(Context)을 제공합니다:
우리 기존 Next.js App Router 프로젝트의 /dashboard 경로에 페이지를 만들어줘. 데이터는 date, region, amount 컬럼이 있는 Supabase의 "sales" 테이블에서 가져와줘. 지역별 합계를 막대그래프(Bar Chart)로 보여주고, 그 아래에는 정렬 가능한 테이블을 만들어줘. 기존 ui 폴더에 있는 컴포넌트들을 사용해줘. 별도의 문의 없이 새로운 의존성(Dependencies)을 추가하지 마.

이 차이는 기계에 대한 예의의 문제가 아닙니다. 차이점은 두 번째 방식이 모델에게 결정을 맡기는 대신, 직접 결정을 내린다는 데 있습니다. 당신이 내리지 않은 모든 결정은 모델이 대신 내리게 되며, 이는 실행할 때마다 매번 달라집니다.

예시의 마지막 문장은 보기보다 훨씬 중요합니다. "별도의 문의 없이 새로운 의존성을 추가하지 마"라는 문구는, 모델이 당장 편리하다는 이유로 package.json에 세 개의 추가 패키지를 작성하는 것을 방지합니다. 프롬프트에 이러한 가드레일(Guardrails)을 설정하는 것은 나중에 몇 시간의 시간을 아껴줍니다.

작은 단계, 그렇지 않으면 고통이 따릅니다

가장 흔한 실수는 모델에게 한꺼번에 너무 많은 것을 요구하고, 기존 코드 전체에 걸쳐 대규모 변경을 실행하는 것입니다. 생성형 모델(Generative Models)은 필요한 것보다 더 많은 부분을 재구성하려는 경향이 있습니다. 만약 당신이 400줄짜리 파일에 "날짜 형식을 변경해줘"라는 명령을 내린다면, 날짜 형식은 맞지만 다른 세 가지 요소가 미묘하게 망가진 400줄짜리 파일을 돌려받게 될 것입니다.

도움이 되는 방법은 평범해 보이지만 효과적입니다. 단위를 작게 유지하세요. 한 번의 실행(Run)당 하나의 함수, 하나의 컴포넌트, 혹은 명확하게 정의된 하나의 작업만 수행하십시오. 그리고 기능이 작동하는 상태가 될 때마다 커밋(Commit)하세요. 바이브 코딩(Vibe Coding)에서 Git은 있으면 좋은 기능(Nice to have)이 아니라, 당신의 안전망입니다. 다음 실행에서 무언가 망가졌을 때, 무엇이 바뀌었는지 추측하는 대신 단 2초 만에 되돌릴 수 있습니다.

저는 이제 거의 항상 다음과 같은 방식으로 작업합니다: 작동하는 상태 유지, 커밋(commit), 한 가지 사항 변경, 테스트, 커밋(commit). 이것이 더 많은 노력이 드는 것처럼 들릴 수 있지만, 결과적으로는 더 빠릅니다. 왜냐하면 뒤섞인 수많은 변경 사항을 일일이 풀어내야 하는 상황에 더 이상 처하지 않게 되기 때문입니다.

코드는 당신의 소유입니다, 그러니 읽으세요

바이브 코딩 (Vibe Coding)에서 가장 위험한 문장은 "잘 돌아가네"입니다. 무언가가 돌아간다는 사실은 그것이 올바른 일을 하고 있는지, 혹은 안전한지에 대해 아무것도 말해주지 않습니다.

일상적인 구체적인 예: 모델에게 Supabase에서 데이터를 불러오도록 요청하면, 모델은 종종 행 레벨 보안 (Row Level Security, RLS)에 대해 언급하지 않은 채 클라이언트 컴포넌트 (Client Component)에 직접 접근하는 코드를 작성합니다. 테스트 데이터로 진행하는 데모 운영 중에는 이것이 전혀 눈에 띄지 않습니다. 하지만 실제 사용자와 실제 데이터가 유입되는 순간, 당신은 자신도 모르는 사이에 데이터 유출 사고를 만든 셈이 됩니다. 모델은 "코드가 컴파일되지 않는다"는 의미에서는 틀린 것을 하지 않았습니다. 단지 당신의 컨텍스트 (context)에서 맞지 않는 가정을 했을 뿐입니다.

따라서 다음 원칙이 적용됩니다: 생성된 코드는 초안이지 최종 제품이 아닙니다. 당신이 모든 코드를 한 줄 한 줄 직접 쓸 수 있어야 할 필요는 없지만, 코드를 읽고 이해할 수는 있어야 합니다. 특정 부분에서 어떤 일이 일어나는지 알 수 없다면, 모델에게 물어보고 그것을 수용하기 전에 설명을 요구하세요. 이 5분의 시간은 전체 프로세스에서 가장 가치 있는 투자입니다.

가치가 있는 곳과 그렇지 않은 곳

충분한 프로젝트를 수행한 결과, 어떤 작업에서 바이브 코딩 (Vibe Coding)이 실제로 시간을 절약해 주는지 명확한 패턴이 나타납니다.

바이브 코딩은 규모가 적당한 내부 도구에서 빛을 발합니다: 설정기 (Configurators), 분석 도구, 프로토타입 (Prototypes), 소규모 자동화 도구 등 명확한 작업이 있고 피해 위험이 제한적인 것들입니다. 위에서 언급한 사항들을 준수한다면, 2주가 걸릴 프로젝트가 이곳에서는 정기적으로 단 한 오후 만에 완성되기도 하며, 이 과정에서 품질 저하는 발생하지 않습니다.

시스템이 거대해지고, 강력하게 연결되며, 비즈니스에 핵심적인(business-critical) 역할을 수행하게 되면 상황은 힘들어집니다. 움직이는 부품(moving parts)이 많아질수록, 오직 언어만으로 제어력을 유지하는 것은 더욱 어려워집니다. 그렇다고 그곳에서 AI를 전혀 사용하지 말아야 한다는 뜻은 아닙니다. 생성된 제안들을 맹목적으로 받아들이는 대신, 이를 적절히 판단하고 배치할 수 있는 숙련된 개발자가 루프(in the loop) 안에 있어야 한다는 의미입니다.

이러한 한계를 솔직하게 인정하는 것은 약함을 시인하는 것이 아닙니다. 그것은 바이브 코딩(Vibe Coding)을 생산적으로 활용하는 사람과, 그저 새로운 문제들을 사들이고 있는 사람 사이의 차이입니다.

진정한 레버리지 (The actual lever)

이 모든 것을 단 한 가지로 요약해야 한다면, 바로 이것입니다: 바이브 코딩은 프로그래밍 자체를 빠르게 만드는 것이 아니라, 소프트웨어를 구축할 수 있는 주체가 누구인지를 변화시킵니다. 자신의 문제를 정확히 알고 있지만 프로그래밍을 배운 적이 없는 전문가라도, 제가 여기서 설명한 몇 가지 원칙들을 배운다면 오늘날 쓸만한 솔루션을 구축할 수 있습니다.

명확하게 명세(specification)를 작성할 것. 작은 단계로 작업할 것. 채택할 코드를 읽을 것. 자신의 한계가 어디인지 알 것. 이것은 거창한 비밀도 아니고 마법도 아닙니다. 새로운 도구를 사용하는 숙련된 기술(craftsmanship)일 뿐입니다. 그리고 모든 도구가 그렇듯, 결과물을 결정하는 것은 도구가 아니라 그것을 다루는 손입니다.