바이브 코딩의 함정과 의도 기반 협업

"AI에게 다 시키면 되지"의 달콤한 유혹

"GPT한테 시키면 5분이면 만들어주던데?" 이 말을 들을 때마다 복잡한 감정이 든다. 틀린 말은 아니다. AI에게 "타로 앱 만들어줘"라고 하면 정말로 동작하는 코드가 나온다. 화면에 카드가 보이고, 클릭하면 뒤집어지고, 해석 텍스트가 나타난다. 5분은 과장이지만, 30분이면 충분하다.

문제는 그 다음이다. "카드 애니메이션을 바꾸고 싶어." "리딩 히스토리를 추가하고 싶어." "모바일에서 레이아웃이 깨지는데." 이런 요구가 오는 순간, AI가 5분 만에 만들어준 코드 위에서 개발자가 할 수 있는 일이 거의 없다. 코드를 이해하지 못하니까.

이것이 바이브 코딩의 함정이다. 그리고 이 글은 타로 마스터 프로젝트 전체를 관통하는 핵심 주제, "바이브 코딩과 의도 기반 협업의 차이"에 대한 이야기다.

바이브 코딩이란 무엇인가

바이브 코딩은 간단히 말해 "AI에게 코드를 쓰게 하고, 분위기(vibe)만 확인하면서 개발하는 것"이다. 코드의 내부 구조를 이해하지 않고, 결과물이 원하는 대로 동작하면 넘어가는 방식이다. 빠르고, 편하고, 즉각적인 만족감을 준다.

이 방식이 유효한 경우도 분명 있다. 일회성 스크립트, 빠른 프로토타입, 학습 목적의 코드. 한 번 쓰고 버릴 코드라면 내부 구조를 깊이 이해할 필요가 없다. 문제는 이 방식을 "지속되는 프로젝트"에 적용할 때 발생한다.

타로 마스터는 한 달이 넘는 기간 동안 점진적으로 기능이 추가되고, 디자인이 바뀌고, 버그가 수정되는 프로젝트였다. 초기에 만들어진 코드 위에 계속 새로운 코드가 쌓인다. 기초가 이해되지 않은 상태에서 쌓아올린 코드는 모래 위의 성이다.

결정적 차이: "만들어줘" vs "이렇게 설계하고"

바이브 코딩과 의도 기반 협업의 차이를 가장 잘 보여주는 건 AI에게 던지는 질문의 형태다.

바이브 코딩: "타로 앱 만들어줘."
의도 기반 협업: "78장 카드의 데이터 스키마를 이렇게 정의하고, 메이저 아르카나 22장과 마이너 아르카나 56장을 구분해서, 각 카드에 정방향/역방향 해석을 포함하는 구조를 만들자."

결과물은 비슷해 보일 수 있다. 하지만 과정에서 개발자가 가져가는 것이 완전히 다르다. 바이브 코딩에서 개발자는 "동작하는 코드"를 얻는다. 의도 기반 협업에서 개발자는 "이해한 코드"를 얻는다.

이 차이가 드러나는 순간은 문제가 발생할 때다. 카드 데이터가 undefined로 표시되는 버그가 생겼다고 하자. 데이터 스키마를 이해하고 있는 개발자는 "아, 역방향 해석 필드가 optional인데 기본값 처리가 빠져있네"라고 즉시 파악한다. 바이브 코딩을 한 개발자는 AI에게 "카드 데이터가 안 나와"라고 또 다시 던진다. AI가 수정해주면 되지만, 다음에 비슷한 문제가 생기면 또 AI에게 물어야 한다. 영원히 AI 없이는 한 발짝도 못 나가는 의존 관계가 만들어진다.

코드를 이해하지 못하면 생기는 일

타로 마스터 개발 과정에서 의도적으로 코드를 이해하려고 노력한 구체적인 장면이 있다. 켈틱 크로스 스프레드의 10장 레이아웃을 구현할 때였다. Claude가 CSS Grid와 절대 위치 지정을 조합한 레이아웃 코드를 제안했다.

바이브 코딩 방식이라면 이 코드를 그대로 복사해서 동작 여부만 확인하고 넘어갔을 것이다. 하지만 나는 각 카드의 위치가 왜 이렇게 설정됐는지, Grid 영역 이름이 왜 이렇게 나뉘었는지를 물었다. AI의 설명을 듣고, 직접 값을 바꿔보면서 레이아웃이 어떻게 변하는지 확인했다.

이 시간 투자가 빛을 발한 건 모바일 레이아웃을 따로 만들어야 할 때였다. 데스크톱 레이아웃의 구조를 이해하고 있었기 때문에, 모바일에서 어떤 부분을 바꿔야 하는지 스스로 판단할 수 있었다. 이해 없이 복사한 코드였다면, 모바일 레이아웃도 처음부터 AI에게 다시 만들어달라고 했을 것이다.

디버깅에서의 차이는 더 극적이다. 서비스 워커의 캐싱 문제로 업데이트가 반영되지 않는 버그가 있었다. 서비스 워커의 동작 원리를 이해하고 있었기 때문에 "캐시 무효화 로직을 확인해야겠다"는 방향을 잡을 수 있었다. 이 방향 설정 능력이 바이브 코딩과 의도 기반 협업의 가장 실질적인 차이다.

AI가 생성한 코드의 "왜"를 이해하는 것

AI가 작성한 모든 코드에는 이유가 있다. 정확히 말하면, 이유가 있어야 한다. 하지만 AI는 그 이유를 자발적으로 설명하지 않는 경우가 많다. "이렇게 하면 됩니다"라고 결과만 제시한다.

의도 기반 협업에서 개발자의 역할은 그 "왜"를 끈질기게 물어보는 것이다. "왜 이 컴포넌트를 이렇게 분리했어?" "이 상태 관리 방식을 선택한 이유가 뭐야?" "다른 접근 방식과 비교하면 어떤 트레이드오프가 있어?"

이런 질문을 던지면 AI는 놀라울 정도로 상세한 설명을 해준다. 대안이 무엇이 있었는지, 각 대안의 장단점은 무엇인지, 왜 이 선택이 현재 상황에 더 적합한지를. 이 과정에서 개발자는 코드뿐 아니라 설계의 맥락까지 이해하게 된다.

타로 마스터에서 localStorage를 선택한 것, Framer Motion을 선택한 것, vite-plugin-pwa를 선택한 것. 각각의 선택에는 이유가 있었고, 그 이유를 이해하고 있기 때문에 나중에 "IndexedDB로 바꿔야 할까?" 같은 판단이 가능해진다. 이유를 모르면 판단도 못 한다.

의도 기반 협업의 실천 방법

타로 마스터를 개발하면서 정립한 의도 기반 협업의 실천 방법을 정리하면 이렇다.

첫째, 구조 설계는 내가 한다. 컴포넌트를 어떻게 나눌지, 데이터 흐름을 어떻게 구성할지, 상태 관리를 어떻게 할지. 큰 그림은 내가 그린다. AI에게는 "이런 구조로 만들어달라"고 요청한다. AI가 구조를 제안하면 그것을 검토하고 수정하는 것도 내 역할이다.

둘째, 실행은 AI에게 맡긴다. 구조가 잡히면 구체적인 코드 작성은 AI가 훨씬 빠르다. 반복적인 패턴, 보일러플레이트, 라이브러리 연동 코드 같은 건 AI의 강점이다. 이 부분에서 시간을 아끼는 것이 AI 협업의 핵심 가치다.

셋째, 이해 없이 넘어가지 않는다. AI가 만든 코드를 복사하기 전에 읽는다. 이해되지 않는 부분은 물어본다. "이 줄이 하는 역할이 뭐야?" "이 패턴의 이름이 뭐야?" 하나하나 확인하는 과정이 느리게 느껴지지만, 이 시간이 나중에 열 배로 돌아온다.

넷째, 항상 대안을 물어본다. AI가 제안한 첫 번째 방법이 최선이 아닐 수 있다. "다른 방법은 없어?" "이 방법의 단점은 뭐야?" 이런 질문이 더 나은 해결책을 끌어내고, 개발자의 시야를 넓혀준다.

다섯째, 최종 판단은 내가 한다. AI의 제안을 참고하되, 프로젝트의 맥락과 우선순위를 고려한 최종 결정은 개발자의 몫이다. AI는 맥락 전체를 파악하지 못한다. 지금 가장 중요한 게 뭔지, 어디에 시간을 투자해야 하는지는 프로젝트를 운영하는 사람만이 판단할 수 있다.

AI 시대 개발자의 핵심 역량: "왜"를 만드는 능력

코드를 작성하는 속도에서 인간은 AI를 이길 수 없다. 그건 인정해야 한다. 하지만 AI가 대신할 수 없는 영역이 있다. "왜 이것을 만들어야 하는가"를 결정하는 것이다.

타로 마스터에서 "78장 카드 중 직접 고르는 자유 선택 모드를 추가하자"는 결정. "Instagram 스토리로 공유 가능한 이미지를 생성하자"는 결정. "Linear 스타일로 UI를 전면 개편하자"는 결정. 이것들은 AI가 스스로 만들어낸 것이 아니다. 사용자의 니즈를 관찰하고, 프로젝트의 방향성을 고려하고, 투입 대비 효과를 판단해서 내가 내린 결정이다.

AI에게 "이 프로젝트에 뭘 추가하면 좋을까?"라고 물으면 답을 준다. 그 답이 나쁘지 않을 수도 있다. 하지만 그 답은 일반적인 제안이지, 이 프로젝트의 맥락과 이 프로젝트를 사용하는 사람들의 구체적인 상황을 반영한 결정이 아니다.

"왜"를 만드는 능력은 경험에서 나온다. 코드를 작성하고, 사용자의 반응을 관찰하고, 실패하고, 수정하는 반복에서. AI가 이 과정을 가속해줄 수는 있지만, 대신 경험해줄 수는 없다.

결국 개발자는 무엇을 하는 사람인가

타로 마스터 프로젝트를 통해 내가 도달한 결론은 이렇다. AI 시대의 개발자는 "코드를 쓰는 사람"이 아니라 "무엇을 왜 만들지를 결정하고, AI와 협업해서 그것을 구현하는 사람"이다.

바이브 코딩은 이 역할을 포기하는 것이다. "AI에게 다 시키기"는 편하지만, 개발자로서의 성장을 멈추게 한다. 의도 기반 협업은 AI의 속도를 활용하면서도 개발자의 이해와 판단을 유지하는 방법이다.

쉬운 길은 아니다. "그냥 복사하면 되는데 왜 일일이 이해해야 해?"라는 유혹이 매번 온다. 하지만 지금 투자하는 이 시간이 앞으로의 모든 프로젝트에서 복리로 돌아온다. 이해한 코드는 자산이 되고, 이해하지 못한 코드는 부채가 된다. 이 차이를 아는 것이 AI 시대를 살아가는 개발자의 첫 번째 무기다.

다음 편 예고

마지막 편이다. 20편에 걸친 타로 마스터 프로젝트의 전체 여정을 돌아보고, AI가 잘한 것과 못한 것을 솔직하게 정리한다. 그리고 AI와 함께한 사이드 프로젝트가 내게 남긴 것, 앞으로의 가능성을 이야기한다.