<div id="readability-page-1" class="page"><div id="contents">
      <article id="entry">
         <div> 
	
	
<p id="block-200aa989-ad37-4d1b-a763-21a9c6a460c3">저는 새로운 기술 조류를 마케팅 용어로 포장하는 것에 대해 나쁘게 생각하지 않습니다. 특정 시대를 살아가는 세대 끼리 통하는 맥락을 공유하면서, 대화를 이어 갈 수 있기 때문인데요. 불과 한 달 만에 만들어진 따끈따끈한 용어인 ‘<a href="https://github.com/filipecalegario/awesome-vibe-coding">바이브 코딩(Vibe Coding)</a>‘ 역시 최근 논란의 중심에 섰습니다.</p>



<figure><img fetchpriority="high" decoding="async" width="768" height="430" src="https://channy.creation.net/data/channy/2025/03/21082825/2025-vibe-coding.jpg" alt="" sizes="(max-width: 768px) 100vw, 768px"></figure>



<p>뉴스 기사에 회자되는 내용만 보자면, 대규모 언어 모델(LLM)을 통한 생성형 AI의 도움을 받아 자유로운 느낌에 따라 코딩을 하는 활동을 지칭하는 것이라고 합니다만… 실제로 <a href="https://twitter.com/karpathy/status/1886192184808149383">Andrej Karpathy</a>가 처음 그 용어를 사용한 맥락은 다음과 같습니다.</p>


<blockquote>
<p>제가 “바이브 코딩”이라고 부르는 새로운 종류의 코딩 방식이 있는데, 느낌에 따라서 만든 엄청나게 많은 코드를 받아들이고, 실제로 코드가 존재한다는 사실조차 잊어버리는 것입니다. LLM(예: Cursor Composer w Sonnet)이 너무 좋아지고 있기 때문에 가능합니다. 또한 SuperWhisper로 Composer와 대화하기 때문에 키보드를 거의 건드리지 않습니다.</p>
</blockquote>


<p>Andrej Karpathy가 말한 원문에서 말하는 바이브 코딩은 새로운 아이디어를 구현하거나 실험하기 위해 LLM을 이용해서 좀 더 빠르게 프로토타이핑을 하기 위한 방안의 하나로 LLM을 사용하는 것입니다. AI가 생성한 코드를 직접 읽어보거나, 코드 리뷰를 하지도 않고, 그냥 다 수락하면서, 원래 원했던 기능 구현에만 중점을 둡니다. 오류가 생겨도 그냥 LLM에게 수정하라고 명령만 내리고, 어떤 코드가 어떻게 수정됐는지에 상관없이 다음 기능 개발로 나아가는 것이죠. 원래 맥락으로 보자면, 한마디로 바이브코딩은 AI가 해주는 대로 하는 사실상 무대뽀 개발 방식입니다.</p>



<p><strong>◼ 바이브 코딩, SW 개발의 진입 장벽을 낮추다</strong><br>여기까지 들으면, 기존 소프트웨어 개발자들은 AI가 생성하는 코드를 어떻게 믿느냐? 이걸 회사에서 쓸 수 있냐? 이런 말을 할 것 하실 것 같습니다. 원래 소프트웨어 개발은 프로그램 코드를 직접 작성 혹은 리뷰하면서 성능, 접근성, 보안, 비용 효율성을 고려해야 합니다. 특히나, 다른 개발자들과 협업을 통해 계속 변화하 나가기 위한 유지 보수와 코드 관리 및 배포 등에도 신경써야 합니다. 따라서, 전통적인 방식의 SW 개발에는 맞지 않는 방식일 것입니다.</p>



<p>하지만, 세상이 변하는 걸 느끼는 분들은 이게 무엇을 의미하는지 직관적으로 느끼실 것 같습니다. 제가 생성형 AI가 처음 뜨기 시작했을 때, <a href="https://channy.creation.net/blog/1772">스테이블 디퓨전과 ChatGPT를 다룬 글</a>에서 인용을 하자면요. </p>


<blockquote>
<p>제가 입버릇처럼 하는 말이 있습니다. 세상을 바꾸는 IT 기술은 진입 장벽이 낮추고 누구나 접근 가능(easy to access)하여, 많은 사람이 참여함으로서 새로운 시장을 창출한다구요. IT 역사상 오픈 소스 소프트웨어, 오픈 웹 표준, 오픈 API, 오픈 지식 플랫폼 등이 대표적인 예입니다.</p>
</blockquote>


<p>컴퓨터 프로그래밍 방식 역시 크게 다르지 않습니다. 아주 오래 전 어셈블리 언어로 부터 컴파일언어, 인터프리터언어, 웹 프로그래밍 등으로 발전하면서, 이전에 알아야 했던 지식을 더 이상 필요치 않고 좀 더 쉬운 방식으로 계속 변화해 왔기 때문입니다. 사실 프로그래밍 진입 장벽을 낮추려는 시도는 “Nocode”, “Less-code”라는 이름으로 과거에도 수도 없이 많이 있었습니다만, 이러한 노코드 도구들 역시 우리가 원하는 바이브, 즉 자유도를 충족시켜주지는 못했습니다.</p>



<p>요즘 바이브 코딩 같은 용어가 뜬다는 것은 AI 기반 코딩의 임계점과 장벽도 이미 넘어섰다는 것을 의미합니다. 1인 개발자나 작은 스타트업들이 새로운 아이디어를 구현하고, 프로토타입을 만들때, AI에만 완전히 의존하는 개발 방식이 가능하다는 점을 시사해 주고 있습니다.</p>



<p><strong>◼ 바이브 코딩의 한계점</strong><br>기존 SW 개발자들도 이런 기술 풍조를 완전히 무시하기는 어렵습니다. 현재 하는 일과 상관 없이 우리는 항상 이것 저것 시도를 하면서 새로운 기술과 방식을 배워야 하기 때문이죠. 그 과정에서 현업에 대한 신기술도 익히지만, 언젠가 독립해서 나만의 제품을 만들려는 꿈도 꿀수 있습니다.</p>



<p>AI 기반 코딩에 대해 다양한 실험을 하고 있는 <a href="https://simonwillison.net/2025/Mar/19/vibe-coding/">Simon Willison</a>도 그의 글에서 기존 AI 기반 개발과 차이를 말하면서, 바이브 코딩을 할 때 어떤 점을 유의해야 하는지 알려주고 있습니다. 한마디로, 위험성이 낮은 프로젝트에 대해 SW 보안 및 개인 정보에 대해서 최소한의 검토를 하면서 Cursor 같은 AI 전문 도구와 Claude Artifact 샌드박스 내에서 개발을 하라고 조언합니다. </p>



<p>다만, 저는 바이브코딩의 결과물을 프로덕션에 내보내는 것은 신중해야 한다고 생각합니다. 개인 정보를 다루지 않는 가벼운 기능이나 프로토타입은 괜찮지만, 여러 사람이 함께 개발해 나가는 좀 더 복잡한 프로젝트로 나아갈 때는 아예 처음 부터 다시 코드를 다시 짜는 수준의 리팩토링을 해야 할 수도 있으니까요.</p>



<p>따라서, 바이브코딩을 해서 뭔가를 만들었다고 해서 이것을 다른 사람에게 주면 계속해서 추가 기능 개발 할 수 있다고 생각해서는 안될 것입니다. AI가 만들어 낸 코드의 수준을 못 믿는 것이 아니라, 기능을 만들어 나간 과정에 대한 맥락이 전혀 공유되지 않았기 때문입니다. 바이브코딩이 제품 수준에서 유의미한 수준이 되려면, AI를 이용한 코드 개발로 나아가는 자연어에 대한 완전한 맥락이 공유될 수 있어야 할 것입니다. 또한, 개발 속도와 비용에 더 집중하여 AI가 만든 코드 품질, 유지 보수성 및 기술 부채라는 트레이드오프를 정말 받아들일 것인가라는 기업의 의지에 좌우될 것입니다.</p>



<p><strong>◼ AI가 바이브 코더에게 경고를 하다</strong><br>한편으로 이런 에피소드도 있습니다. 코딩 어시스턴트인 커서(Cursor)가 Janswist라고 소위 바이브 코더에게 Cursor에 너무 의존하지 말고 대신 직접 코드를 작성하라고 조언을 했다고 합니다. 해커뉴스에 올라오면서 입소문을 타서 <a href="https://arstechnica.com/ai/2025/03/ai-coding-assistant-refuses-to-write-code-tells-user-to-learn-programming-instead/">Arstechnica</a> 같은 뉴스 매체에도 많이 기사화 되었는데요.</p>



<figure><img decoding="async" width="940" height="693" src="https://channy.creation.net/data/channy/2025/03/21083109/cursor_forum_screenshot-940x693.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<p>한 시간 정도 커서로 코드 작성을 하고 난 후, 특정 시점에서 비즈니스 로직은 직접 짜라고 말하면서, 그래야 시스템을 이해하고 적절하게 유지 관리할 수 있다고 조언했다고 하네요. <em>(정말 똑똑한 조언이죠.) </em>AI가 어느 정도 분량의 코드를 생성하고 나면, 어떤 시점에서 그런 응답을 하는 버그라고 추측하는 사람도 있습니다. 스택오버플로 같은 개발자 포럼에서 초보자들에게 하는 답변과 매우 유사하기 때문에, 자연스런 LLM 학습의 결과라고 보는 분들도 많습니다.</p>



<p>세상의 모든 일이 그렇듯 뭔가 새로운 것을 시작하거나 배울 때는 즐겁거나 쉬워야 합니다. 다만, 거기에서 멈추지 말고, 좀 더 잘하고 전문가가 되려면, 다른 사람이 알 수 없는 끝없는 훈련과 고뇌의 과정이 있게 됩니다. 프로그래밍을 처음 시작할 때는 바이브 코딩이든 뭐든 쉬운 것을 성취하는 즐거운 과정을 거치세요. 어느 정도 익숙해지면, 한계를 극복해 나가면서 새로운 기술을 받아들이며 자신만의 방식 만들어 나가야 합니다. 시대에 따라 코딩을 하는 도구와 방식은 변화했지만, 학습을 통한 성숙의 과정은 변하지 않았습니다.</p>
<div><h3>더 읽어 볼 글</h3></div>	

<p><small>- ;</small></p>

	<p>※ <a href="http://channy.creation.net/about/#disclaimer" target="new">Disclaimer</a>- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)</p>


	
  </div></article>
</div></div>

Channy's Blog

저는 새로운 기술 조류를 마케팅 용어로 포장하는 것에 대해 나쁘게 생각하지 않습니다. 특정 시대를 살아가는 세대 끼리 통하는 맥락을 공유하면서, 대화를 이어 갈 수 있기 때문인데요. 불과 한 달 만에 만들어진 따끈따끈한 용어인 ‘바이브 코딩(Vibe Coding)‘ 역시 최근 논란의 중심에 섰습니다.
뉴스 기사에 회자되는 내용만 보자면, 대규모 언어 모델(LLM)을 통한 생성형 AI의 도움을 받아 자유로운 느낌에 따라 코딩을 하는 활동을 지칭하는 것이라고 합니다만… 실제로 Andrej Karpathy가 처음 그 용어를 사용한 맥락은 다음과 같습니다.
제가 “바이브 코딩”이라고 부르는 새로운 종류의 코딩 방식이 있는데, 느낌에 따라서 만든 엄청나게 많은 코드를 받아들이고, 실제로 코드가 존재한다는 사실조차 잊어버리는 것입니다. LLM(예: Cursor Composer w Sonnet)이 너무 좋아지고 있기 때문에 가능합니다. 또한 SuperWhisper로 Composer와 대화하기 때문에 키보드를 거의 건드리지 않습니다.
Andrej Karpathy가 말한 원문에서 말하는 바이브 코딩은 새로운 아이디어를 구현하거나 실험하기 위해 LLM을 이용해서 좀 더 빠르게 프로토타이핑을 하기 위한 방안의 하나로 LLM을 사용하는 것입니다. AI가 생성한 코드를 직접 읽어보거나, 코드 리뷰를 하지도 않고, 그냥 다 수락하면서, 원래 원했던 기능 구현에만 중점을 둡니다. 오류가 생겨도 그냥 LLM에게 수정하라고 명령만 내리고, 어떤 코드가 어떻게 수정됐는지에 상관없이 다음 기능 개발로 나아가는 것이죠. 원래 맥락으로 보자면, 한마디로 바이브코딩은 AI가 해주는 대로 하는 사실상 무대뽀 개발 방식입니다.
 바이브 코딩, SW 개발의 진입 장벽을 낮추다
여기까지 들으면, 기존 소프트웨어 개발자들은 AI가 생성하는 코드를 어떻게 믿느냐? 이걸 회사에서 쓸 수 있냐? 이런 말을 할 것 하실 것 같습니다. 원래 소프트웨어 개발은 프로그램 코드를 직접 작성 혹은 리뷰하면서 성능, 접근성, 보안, 비용 효율성을 고려해야 합니다. 특히나, 다른 개발자들과 협업을 통해 계속 변화하 나가기 위한 유지 보수와 코드 관리 및 배포 등에도 신경써야 합니다. 따라서, 전통적인 방식의 SW 개발에는 맞지 않는 방식일 것입니다.
하지만, 세상이 변하는 걸 느끼는 분들은 이게 무엇을 의미하는지 직관적으로 느끼실 것 같습니다. 제가 생성형 AI가 처음 뜨기 시작했을 때, 스테이블 디퓨전과 ChatGPT를 다룬 글에서 인용을 하자면요. 
제가 입버릇처럼 하는 말이 있습니다. 세상을 바꾸는 IT 기술은 진입 장벽이 낮추고 누구나 접근 가능(easy to access)하여, 많은 사람이 참여함으로서 새로운 시장을 창출한다구요. IT 역사상 오픈 소스 소프트웨어, 오픈 웹 표준, 오픈 API, 오픈 지식 플랫폼 등이 대표적인 예입니다.
컴퓨터 프로그래밍 방식 역시 크게 다르지 않습니다. 아주 오래 전 어셈블리 언어로 부터 컴파일언어, 인터프리터언어, 웹 프로그래밍 등으로 발전하면서, 이전에 알아야 했던 지식을 더 이상 필요치 않고 좀 더 쉬운 방식으로 계속 변화해 왔기 때문입니다. 사실 프로그래밍 진입 장벽을 낮추려는 시도는 “Nocode”, “Less-code”라는 이름으로 과거에도 수도 없이 많이 있었습니다만, 이러한 노코드 도구들 역시 우리가 원하는 바이브, 즉 자유도를 충족시켜주지는 못했습니다.
요즘 바이브 코딩 같은 용어가 뜬다는 것은 AI 기반 코딩의 임계점과 장벽도 이미 넘어섰다는 것을 의미합니다. 1인 개발자나 작은 스타트업들이 새로운 아이디어를 구현하고, 프로토타입을 만들때, AI에만 완전히 의존하는 개발 방식이 가능하다는 점을 시사해 주고 있습니다.
 바이브 코딩의 한계점
기존 SW 개발자들도 이런 기술 풍조를 완전히 무시하기는 어렵습니다. 현재 하는 일과 상관 없이 우리는 항상 이것 저것 시도를 하면서 새로운 기술과 방식을 배워야 하기 때문이죠. 그 과정에서 현업에 대한 신기술도 익히지만, 언젠가 독립해서 나만의 제품을 만들려는 꿈도 꿀수 있습니다.
AI 기반 코딩에 대해 다양한 실험을 하고 있는 Simon Willison도 그의 글에서 기존 AI 기반 개발과 차이를 말하면서, 바이브 코딩을 할 때 어떤 점을 유의해야 하는지 알려주고 있습니다. 한마디로, 위험성이 낮은 프로젝트에 대해 SW 보안 및 개인 정보에 대해서 최소한의 검토를 하면서 Cursor 같은 AI 전문 도구와 Claude Artifact 샌드박스 내에서 개발을 하라고 조언합니다. 
다만, 저는 바이브코딩의 결과물을 프로덕션에 내보내는 것은 신중해야 한다고 생각합니다. 개인 정보를 다루지 않는 가벼운 기능이나 프로토타입은 괜찮지만, 여러 사람이 함께 개발해 나가는 좀 더 복잡한 프로젝트로 나아갈 때는 아예 처음 부터 다시 코드를 다시 짜는 수준의 리팩토링을 해야 할 수도 있으니까요.
따라서, 바이브코딩을 해서 뭔가를 만들었다고 해서 이것을 다른 사람에게 주면 계속해서 추가 기능 개발 할 수 있다고 생각해서는 안될 것입니다. AI가 만들어 낸 코드의 수준을 못 믿는 것이 아니라, 기능을 만들어 나간 과정에 대한 맥락이 전혀 공유되지 않았기 때문입니다. 바이브코딩이 제품 수준에서 유의미한 수준이 되려면, AI를 이용한 코드 개발로 나아가는 자연어에 대한 완전한 맥락이 공유될 수 있어야 할 것입니다. 또한, 개발 속도와 비용에 더 집중하여 AI가 만든 코드 품질, 유지 보수성 및 기술 부채라는 트레이드오프를 정말 받아들일 것인가라는 기업의 의지에 좌우될 것입니다.
 AI가 바이브 코더에게 경고를 하다
한편으로 이런 에피소드도 있습니다. 코딩 어시스턴트인 커서(Cursor)가 Janswist라고 소위 바이브 코더에게 Cursor에 너무 의존하지 말고 대신 직접 코드를 작성하라고 조언을 했다고 합니다. 해커뉴스에 올라오면서 입소문을 타서 Arstechnica 같은 뉴스 매체에도 많이 기사화 되었는데요.
한 시간 정도 커서로 코드 작성을 하고 난 후, 특정 시점에서 비즈니스 로직은 직접 짜라고 말하면서, 그래야 시스템을 이해하고 적절하게 유지 관리할 수 있다고 조언했다고 하네요. (정말 똑똑한 조언이죠.) AI가 어느 정도 분량의 코드를 생성하고 나면, 어떤 시점에서 그런 응답을 하는 버그라고 추측하는 사람도 있습니다. 스택오버플로 같은 개발자 포럼에서 초보자들에게 하는 답변과 매우 유사하기 때문에, 자연스런 LLM 학습의 결과라고 보는 분들도 많습니다.
세상의 모든 일이 그렇듯 뭔가 새로운 것을 시작하거나 배울 때는 즐겁거나 쉬워야 합니다. 다만, 거기에서 멈추지 말고, 좀 더 잘하고 전문가가 되려면, 다른 사람이 알 수 없는 끝없는 훈련과 고뇌의 과정이 있게 됩니다. 프로그래밍을 처음 시작할 때는 바이브 코딩이든 뭐든 쉬운 것을 성취하는 즐거운 과정을 거치세요. 어느 정도 익숙해지면, 한계를 극복해 나가면서 새로운 기술을 받아들이며 자신만의 방식 만들어 나가야 합니다. 시대에 따라 코딩을 하는 도구와 방식은 변화했지만, 학습을 통한 성숙의 과정은 변하지 않았습니다.

바이브 코딩(Vibe Coding)이 시사하는 점

댓글