지난 15년 동안 저는 UC 샌디에이고에서 인지과학 및 디자인 교수로 재직하며 기술, 교육, 디자인의 교차점을 탐구해 왔습니다. 여러분 중에는 최근 제가 O’Reilly Radar에 기고한 글을 읽으신 분들도 계실 텐데요. 그 글에서는 수백만 명의 프로그래밍 학습자들이 코드 실행을 이해하도록 도와온 무료 시각화 도구인 Python Tutor에 AI 채팅 기능을 추가한 과정을 상세히 소개했습니다. 이 경험은 도구이자 협력자로서 생성형 AI와 맺는 관계가 어떻게 변화하고 있는지를 깊이 성찰하게 만든 계기였습니다.

최근 저는 “바이브 코딩(vibe coding)”이라는 새로운 프로그래밍 방식에 큰 매력을 느끼고 있습니다. 이는 안드레이 카르파시가 만든 용어로, 기술 업계에서 상당한 반향을 불러일으키고 있습니다. 사이먼 윌리슨은 이를 이렇게 설명합니다. “바이브 코딩은 LLM을 활용해 소프트웨어를 만들면서도, AI가 생성한 코드를 일일이 검토하지 않는 방식입니다.” 이 개념은 자유로우면서도 한편으로는 다소 두렵게 느껴지기도 합니다. 사용자가 원하는 바를 설명하면 AI가 전체 코드를 생성하고, 우리는 그 ‘바이브’를 신뢰하며 코드의 세부 줄을 일일이 확인하지 않고 실행하는 것이죠.

이 접근 방식에 대한 저의 태도 역시 상당한 진화를 겪어왔습니다. 처음에는 AI 코딩 보조 도구를 사용할 때 생성된 코드를 꼼꼼히 검토하고 상당 부분을 직접 다시 작성하곤 했습니다. 그러나 시간이 지나면서, 그리고 도구들이 점점 정교해지면서, 특정 상황에서는 자연스레 운전대를 AI에게 맡기게 되었습니다. 그렇다고 해서 완전히 바이브 코딩 철학을 수용한 것은 아닙니다. 교수라는 직업 특성상 일정 수준 이상의 품질 보증이 필요했기 때문입니다. 그래서 저는 ‘바이브 체크(vibe check)’라 부르는 전략적 검증 지점을 도입하게 되었고, 이는 줄 단위 검토 없이도 충분한 신뢰를 가능하게 해주었습니다. 이 방식은 개인 프로젝트와도 놀라울 정도로 잘 맞아떨어졌으며, 오늘은 그 여정에서 얻은 통찰을 여러분과 공유하고자 합니다.

실제 사례: 250개의 HTML 파일을 마크다운으로 변환하기

저는 특정 작업 흐름 속에서 반복되지 않는 문제를 해결할 일회성 스크립트를 만들 때 바이브 코딩을 자주 활용하고 있습니다. 특히 데이터 처리나 파일 조작처럼, 직접 코드를 작성하는 것보다 원하는 작업을 설명하고 결과를 검토하는 편이 더 수월한 경우에 유용합니다.

예를 들어, 제가 강의하는 수업에서는 학생들이 독점 웹 앱을 통해 설문에 응답했고, 이 앱은 HTML로 데이터를 내보내는 기능만 제공했습니다. 결과적으로 250개의 HTML 파일이 생성되었지만, 그 안에는 복잡한 마크업과 스타일링 코드가 뒤섞여 있었습니다. 제가 원하는 것은 텍스트 내용, 섹션 제목, 학생들이 포함한 하이퍼링크만 남긴 깔끔한 마크다운 형식의 문서였습니다.

직접 변환 스크립트를 작성하는 대신, 저는 Claude에게 이렇게 요청했습니다: “이 HTML 파일들을 텍스트와 기본 서식, 하이퍼링크를 유지한 채 마크다운으로 변환하는 파이썬 스크립트를 작성해줘.” Claude는 BeautifulSoup 라이브러리를 사용하는 방식을 제안했고(꽤 괜찮은 선택이었습니다), 디렉터리의 모든 HTML 파일을 읽어 각각 대응되는 마크다운 파일을 생성하는 완전한 스크립트를 내놓았습니다.

돌이켜보면 Pandoc 같은 툴을 사용할 수도 있었겠지만, 바이브 코딩 정신에 따라 Claude의 제안을 깊이 고민하지 않고 그대로 실행했습니다. 바이브 코딩의 매력 중 하나는 다양한 대안을 비교하는 탐색 단계를 생략하고, 원하는 바를 설명한 뒤 결과를 바로 활용할 수 있다는 점입니다.

저는 Claude가 생성한 코드를 줄 단위로 확인하지 않았습니다. 그냥 해당 스크립트를 저장한 후, 250개의 HTML 파일이 있는 디렉터리에서 실행하고 결과를 기다렸죠. 이 “실행 후 확인” 방식은 해방감을 주면서도 동시에 약간의 긴장감을 동반합니다. 코드가 정확히 내가 요청한 작업만 수행할 것이라는 신뢰 위에서 이루어지기 때문입니다.

신뢰와 위험 사이의 줄타기: 검토되지 않은 코드 실행하기

스크립트를 실행하는 그 순간, 한 가지 사실이 떠올랐습니다. 저는 실존하는 데이터를 대상으로 검토되지 않은 코드를 제 컴퓨터에서 실행하고 있었던 겁니다. 전통적인 소프트웨어 개발 관점에서 보면, 이는 상당히 무모한 행위일 수 있습니다. 그러나 Claude 3.7 Sonnet 같은 최신 AI 도구는 꽤 안정적이고 실용적인 코드를 생성한다는 평판을 얻고 있기에, 상황은 조금 다르게 느껴졌습니다.

제 판단은 스크립트의 제한된 범위를 고려한 것이었습니다. 이 코드는 HTML을 읽고 마크다운 파일을 생성하는 작업만 수행합니다. 기존 파일을 수정하거나 삭제하지 않으며, 네트워크를 통해 데이터를 전송하지도 않습니다. 물론, 이는 코드가 정말로 제가 지시한 작업만 수행한다는 가정 하에서만 가능한 이야기입니다. 한 줄도 들여다보지 않았기 때문에 예기치 않은 동작이 있을 가능성을 완전히 배제할 수는 없습니다.

이러한 경험은 개발자와 AI 도구 간의 진화하는 신뢰 관계를 상징적으로 보여줍니다. 저 역시 Claude나 ChatGPT 같은 잘 알려진 도구에 비해 생소한 웹 기반 AI에는 더 많은 경계를 두게 됩니다. 이러한 신뢰는 해당 도구들이 유지해야 할 명성과, 악의적인 코드 생성을 방지하려는 개발사들의 강한 동기에서 비롯됩니다.

물론, 저는 AI가 생성한 스크립트를 좀 더 안전하게 실행할 수 있는 “제한 실행 모드”가 운영 체제 차원에서 제공되기를 바랍니다. 예를 들어 “이 스크립트는 특정 디렉터리 내에서만 새 파일을 만들 수 있으며, 기존 파일은 덮어쓰지 않고, 외부 네트워크 접근도 불가능하다”는 조건을 명시할 수 있다면, 훨씬 안심하고 실행할 수 있겠죠.

물론 Docker나 클라우드 환경도 가능하겠지만, 개인 규모의 프로젝트에서는 로컬 실행이 주는 편리함을 대체하긴 어렵습니다. Docker 설정이나 250개 파일을 클라우드에 업로드하는 일은 바이브 코딩의 민첩성과 상충되며, 본질적인 실험 정신을 해칠 수 있습니다.

바이브 체크: 신뢰를 위한 간단한 검증 도구

그래서 등장한 것이 바로 “바이브 체크”입니다. 이 방식은 생성된 스크립트가 기대한 대로 작동했는지를 간단한 기준으로 검증해 주는 보조 스크립트입니다. 핵심은, 이 검증 스크립트가 반드시 원래 스크립트보다 훨씬 단순해야 한다는 점입니다.

HTML에서 마크다운으로 변환하는 프로젝트에서는 다음과 같은 간단한 기준을 설정했습니다. 마크다운 파일은 태그 제거로 인해 HTML보다 파일 크기가 작아야 하며, 만약 마크다운 파일이 HTML 크기의 40%보다 작다면 중요한 내용이 누락되었을 가능성이 있습니다.

저는 Claude에게 또 요청했습니다: 각 HTML/마크다운 파일 쌍을 비교하고, 크기 비율이 기준 이하인 경우 이를 표시해달라고 말이죠. Claude는 이에 맞는 간단한 체크 스크립트를 만들어 주었고, 실제로 몇몇 마크다운 파일이 불완전하게 변환되었다는 사실을 밝혀냈습니다. 저는 해당 파일들을 Claude에게 보여주며 원래의 변환 스크립트를 개선하도록 했습니다.

이처럼 변환 → 확인 → 문제 식별 → 개선의 피드백 루프를 반복하며, 더 이상 수상하게 작은 마크다운 파일은 나타나지 않았습니다. 물론 여전히 기준 이하인 파일이 몇 개 있었지만, 수동 검사를 통해 이것들이 원래 콘텐츠가 적은 HTML 파일이라는 사실을 확인할 수 있었습니다.

여기서 당연한 의문이 생깁니다. “바이브 체크도 바이브 코딩으로 만들었다면, 그 결과는 어떻게 믿을 수 있죠?” 다행히도 체크 스크립트는 원래 작업보다 훨씬 단순하기 때문에 수작업 검토가 가능했습니다. 제 경우, HTML 파싱이 아닌 파일 크기 비교였으므로 직접 확인할 수 있었습니다.

바이브 코딩 + 바이브 체크: 실용적 균형점

이 접근 방식의 핵심은 단순하지만 강력합니다. 바이브 코딩을 할 때는 반드시 간단한 바이브 체크를 함께 사용하세요. “생성된 결과를 검증할 수 있는 가장 단순한 방법은 무엇일까?”라는 질문이 출발점이 되어야 합니다. 이 간단한 검증조차도 코드 줄 단위 검토 없이도 결과에 대한 확신을 크게 높여줍니다.

이 방식은 순수한 바이브 코딩의 속도와 흐름을 유지하면서도, 전통적인 소프트웨어 개발에서 요구하는 신뢰성을 부분적으로 만족시키는 현명한 절충안입니다. 바이브 체크는 테스트 스위트처럼 포괄적인 것이 아니라, 명백한 오류만 잡아낼 수 있는 가벼운 확인 단계라고 생각하면 됩니다.

앞으로 기대되는 점은 AI 도구가 이와 같은 체크 스크립트를 자동으로 제안할 수 있는 방향으로 발전할 가능성입니다. 사용자가 요청하지 않아도 AI가 “모든 게 잘 작동했는지 확인할 수 있는 간단한 스크립트도 함께 생성해 드릴게요”라고 제안하는 것이죠. 그 순간, AI 코딩 도우미는 더 똑똑하고 실용적인 협력자로 진화하게 될 것입니다.

에필로그: 바이브 블로깅의 메타 실험

흥미롭게도, 이 블로그 게시물 전체도 일종의 “바이브 블로깅” 프로젝트였습니다. 저는 이전 O’Reilly 기사를 Claude에게 제공해, 마치 새로운 협력자가 기존 작업을 먼저 읽고 이해하듯, 스타일과 구조를 학습하도록 했습니다. 그 후 각 섹션의 개요와 핵심 메시지를 제공했고, Claude는 이를 제 스타일에 맞춰 확장해 작성했습니다.

전체 글을 한 번에 작성하지 않고, 섹션별로 검토와 수정을 거치는 이 반복적 접근은 제가 앞서 소개한 바이브 코딩 철학과 완전히 일치합니다. 저는 고수준의 지침을 제공했고, Claude는 실행 세부를 맡았으며, 최종 검토와 수정을 통해 제가 원하는 표현과 메시지를 구현해냈습니다.

마지막 한 마디

이제 제가 직접 쓴 유일한 문장을 남깁니다. 이 글의 품질에 대해 자랑스럽지는 않지만(미안해, Claude!), 만약 Claude 같은 도구가 없었다면 저는 이 글을 아예 쓰지 못했을 것입니다. 간단한 아이디어 정도는 있었지만, 2,500단어 분량의 포스트를 직접 쓰고 다듬을 에너지는 없었으니까요. 바이브 코딩과 마찬가지로, 바이브 블로깅은 창의적인 실험을 시작하는 데 필요한 문턱을 낮춰주는 도구였습니다. 그리고 그것만으로도, 저는 큰 영감을 받았습니다.
 

원문 : Vibe Coding, Vibe Checking, and Vibe Blogging