<div id="readability-page-1" class="page"><div tabindex="-1" id="___gatsby"><article><div id="article-body" itemprop="articleBody"><figure data-url="vibe-coding.webp" data-alt="안드레 카파시 말처럼 바이브에 몸을 맡기자.">
    <span>
      <a href="/static/6f1ddd64dda716fb7d15ea7a59b631fe/a4772/vibe-coding.webp" target="_blank" rel="noopener">
    <span></span>
  <img alt="안드레 카파시 말처럼 바이브에 몸을 맡기자." title="" src="https://jiniya.net/static/6f1ddd64dda716fb7d15ea7a59b631fe/7df04/vibe-coding.webp" sizes="(max-width: 760px) 100vw, 760px" loading="lazy" decoding="async">
  </a>
    </span>
    <figcaption><p>안드레 카파시 말처럼 바이브에 몸을 맡기자.</p></figcaption>
  </figure>
<p><a href="https://en.wikipedia.org/wiki/Vibe_coding">바이브 코딩이</a> 유행이다. 직접 코딩하지 않고 자연어로 인공지능에 명령만 해서 코딩을 하는 것을 말하는 의미다. 통상 80% 이상을 인공지능이 작성하면 바이브 코딩으로 보는 추세인 것 같다. 바이브 코딩으로 게임을 만들어서 큰 돈을 벌었다는 사람도 있고, SNS에는 온갖 것들을 바이브 코딩으로 만들었다는 개발자 또는 비개발자들의 글이 넘쳐난다.</p>
<p>한편, 이를 바라보는 직업 프로그래머의 반응은 엇갈린다. 바이브에 올라타는 사람도 있고, 그로인한 리팩토링 대란이 벌어질 것이라는 얘기를 하는 사람들도 있다. 어쨌든 나는 바이브에 올라탄 사람 중에 한 명이긴 하다.</p>
<h3>#0</h3>
<p>내가 처음 바이브 코딩을 해본 건 작년 한글날 정도였던 것 같다. 한창 새로운 제품 코드를 작성하고 있었다. 이 제품은 몇 년을 개발이 지지부진한 것 중에 하나였다. 내가 코드를 쓰지 않은 것도 있었지만 새로운 제품을 우리가 감당할 수 있을까, 라는 생각도 컸었다. 새로운 제품은, 새로운 테스트를, 새로운 지원을, 새로운 영업을, 새로운 홍보를 필요로하는 일이니 말이다. 하지만 우리는 힘든 시기를 겪고 있었고, 더이상 미룰 수는 없었다. 마침 o1-preview가 출시되기도 했었다. 거기다 세월을 묵힌 시간만큼 리서치 자료는 많이 쌓여 있었다. 벤치마킹할 타사 제품도 수두룩했다.</p>
<p>처음에는 ChatGPT와 함께 작성하기 시작했다. 주로 4o에게 작업을 지시하고 결과를 내가 복붙해서 확인하는 작업이었다. ChatGPT로는 전체 프로그램을 한번에 작성하는 것은 쉽지 않기 때문에 전체 구조는 내가 생각했고 주로 함수 단위로 코딩을 지시해서 붙여넣었다. 당연히 출발은 우리의 리서치 자료에서 시작했다. 얼추 해당 자료대로 모두 구현을 했다. 그런데 테스트를 돌리니 예외가 너무 많이 발생했다. 리서치 자료가 크게 도움이 되지 않은 상황이었다.</p>
<p>여기서부터는 멘붕, 과연 이걸 해결할 수 있을까, 라는 생각. 대충 땜빵식으로 해결할수도 있겠지만 리얼월드에서는 무슨 일이 벌어질지 모르는 것이라 그것도 한계가 있었다. 모든걸 원점 재검토가 필요한 상황이었다. 그렇게 새로운 방법을 시도했다. 하지만 번번히 예외 케이스들이 너무 많이 발생하는게 문제였다. 코딩이 문제가 아니라 문서화되지 않은 것들에 대한 구조를 이해하는 게 핵심이었는데 그건 나도 모르고, ChatGPT도 모르는 게 큰 일이었다. 당연한 얘기였지만 다른 제품들도 모두 안되기는 마찬가지였다. 왜냐하면 타사 제품도 모두 동일한 오픈소스를 사용하고 있었고, 그 오픈소스 코드가 잘 동작하지 않는 경우가 많은게 문제였기 때문이다.</p>
<p>그렇게 설계를 3-4번은 뒤집어 엎었다. 최종적으로는 ChatGPT와 함께 오픈소스를 이해하기로 했다. 오픈소스는 너무 커서 거기서 내가 필요한 부분을 찾는 것도 일이었는데 웃긴 건 ChatGPT가 그걸 학습해서 그런지 오픈소스에서 내가 필요한 코드가 어디 있는지 물어보면 기가 막히게 알려줬다. 물론 오픈소스라는게 코드만 있다고 이해가 되는 건 아니다. 이해가 되지 않는 부분은 ChatGPT에 넣어서 다시 설명을 요청했다. 그 이해한 걸 토대로 ChatGPT한테 코딩을 시켜서 코드를 작성했다. 그 모든 작업을 하는 동안 o1-preview를 사용할 일은 한 번 밖에 없었다.</p>
<p>그러다 커서라는 걸 알게됐고 커서로 코딩을 시작했다. 커서는 전체 컨텍스트를 자동으로 llm에 보내 주기 때문에 코딩이 훨씬 편했다. 인라인 에디팅이나 블록을 지정해서 고치기가 훨씬 쉬운게 장점이었다. 그리고 브라우저로 와리가리 안해도 되서 시간이 많이 절약됐다. 그렇게 돌아보니 80%는 아니라도 얼추 70%는 인공지능이 코딩한 제품이 완성됐다. 그때는 바이브 코딩이란 말도 없던 시기라 묘한 기분이 들었다. 제품이 다 작성됐고 빌드 후 테스트를 진행하는 단계가 되니 뭔가 ChatGPT랑 뒷풀이라도 해야 할 것 같다는 생각이 들었다.</p>
<p>사람이면 설계를 3-4번 뒤집는 일을 참지 못했을 것 같다는 생각. 작성했지만 버렸던 수많은 코드에 엄청난 에고로 집착했을거라는 생각. 그리고 웃기게도 이 거대한 작업에서의 나에게 아하 모멘트는 이런 부분이었다. A라는 오픈소스에서 B라는 기능 관련된 코드가 어디있는지 알려줘. 이걸 당연히 답할거라고 생각을 안해서 물어볼 생각을 안했는데 하도 답답해서 물어봤는데 정말 어처구니 없을 정도로 정확하게 코드 위치를 잘 알려주었다.</p>
<h3>#1</h3>
<p>해가 바뀌었고 deepseek가 미국 주도 인공지능 세계에 한차례 충격을 가했다. 더불어 인공지능 오픈소스 생태계는 더욱 풍성해졌다. 장비를 구성할 능력만 되면 로컬에서도 o1 급의 리즈닝 모델을 돌릴 수 있는 세상이 된 것이다. 물론 deepseek-r1은 아직 로컬에서는 돌리기 부담스러운 671b 모델이긴 하다. 하지만 뒤따라 출시된 qwen2.5-coder-32b나 qwq-32b 같은 모델만 사용해도 나쁘지 않은 성능을 보여주었다. 그도 그럴것이 앞서도 언급했지만 대부분의 보통 프로그래머가 작성하는 코드란게 뭔가 대단한 코드가 아니기 때문이다. 안타깝게도 우리는 너무나 뻔한 코드를 대부분 작성하는 경우가 다반사니까 말이다.</p>
<p>최근에 일감이 하나 올라왔다. 고객사에서 api 사용에 문제를 겪는 일감이었다. 업체측에서 친절하게도 본인들이 구현한 코드를 보내주었다. 신입 개발자에게 확인해보라고 했지만 쉽지 않을거라는 생각이 들긴 했다. 그렇다고 내가 앉아서 그 모든 걸 보고 있기엔 다른 급한 일감도 너무 많았다. 그래서 딸깍 코딩을 해보기로 했다. 일감 내용과 업체 코드를 집어 넣고 문제를 재현할 수 있는 테스트 코드를 작성하라고 했다. 아키텍트로 qwq:32b_q4, 에디터로 qwen2.5-coder:32b_q4를 사용했다. 생각했던 것보다 아주 잘 작성했다. 웃긴건 걔가 제대로 작성했는데 내가 틀린 것 같아서 수정을 지시했는데, 업체측에 확인 요청한 결과 내가 지시한 부분이 잘못된 부분이었다. 걔가 원래 작성한 코드가 맞는 코드였다. 업체 측에서 우리가 봐도 되는 부분만 발췌해서 보낸 코드라 빠진 코드가 더러 있었다. 그런 코드는 나머지를 토대로 추론해서 작성하라고 지시를 했는데 그것도 잘 작성했다.</p>
<p>어쨌든 잘 만들 필요는 없지만 재현시키기 위해서는 복잡한 귀찮은 작업이 필요한 그런 작업이었다. 내가 한다고 해도 몇일은 걸릴 것 같은 일이었다. 그런데 정말 딸깍 코딩으로 모든 게 만들어졌다. 내가 일부 수정한 건 경로가 맞지 않아서 포함 경로를 수정하고 포함 파일이 빠진 걸 몇 개 추가한 게 다였다. 물론 이 또한 바이브 코딩을 할 수 있겠지만 그걸 타이핑하는 시간에 코드 고치는 게 훨씬 빠르기에 내가 직접 했다. 결과적으로 그렇게 전체 작업을 하는 데 걸린 시간은 1-2 시간도 채 되지 않았다. 물론 그 마저도 대부분의 시간은 걔가 코딩 하는 걸 대기하는 시간이었다. 왜냐하면 우리 장비는 그리 좋은 장비가 아니라 느리다는 점. 모델 2개를 한번에 메모리에 로딩할 수가 없어서 아키텍트하고 에디팅할 때 항상 모델 교체를 위한 시간이 낭비된다는 점 때문이다. 지시도 몇개 안했지만 대부분 생각보다 너무 잘해서 놀랐다.</p>
<h3>#2</h3>
<p>모든 코드를 잘 작성할 필요는 없다. 그냥 확인을 위해서 임시로 작성하는 코드도 수도 없이 많다. 그런 코딩은 인공지능에게 시키고 나는 중요한 다른 코드를 쓴다면 동시에 두가지 일을 하는 셈이 되는거니 생산성은 배가 된다. 시스템 프로그래머들에게 한참 전에 파이썬을 써야 한다고 하면 C/C++로도 다 할 수 있다는 핀잔을 듣던 시기가 있었다. 하지만 세월이 지나서 이제는 파이썬이 세상을 지배하고 있다. 인공지능도 머지 않아 그렇게 될 거라 본다. 직접해도 다 할 수 있다. 다만 인공지능을 사용하면 더 빨리 할 수 있다. 그리고 열린 마음으로 함께 한다면 나도 모르고, 인공지능도 모르는 것에 대한 작업도 함께 할 수 있다.</p>
<p>인정하기 싫지만 인공지능이 나보다 코드도 더 잘 읽고, 코드도 더 잘 작성한지는 생각보다 제법 오래되었다. 많은 경험을 토대로 느낀 점은 컨텍스트만 제대로 제공하면 거의 상당수 경우에 인간보다 훨씬 나은 결과가 나온다는 것이다. 그러니 이제, 안드레 카파시 말처럼 바이브에 몸을 맡기자.</p></div><div id="bio"><p>돌아보니 좋은 날도 있었고, 나쁜 날도 있었다. 그런 나의 모든 소소한 일상과 배움을 기록한다. 여기에 기록된 모든 내용은 한 개인의 관점이고 의견이다. 내가 속한 조직과는 1도 상관이 없다.</p></div></article></div></div>

YoungJin Shin

바이브 코딩이 유행이다. 직접 코딩하지 않고 자연어로 인공지능에 명령만 해서 코딩을 하는 것을 말하는 의미다. 통상 80% 이상을 인공지능이 작성하면 바이브 코딩으로 보는 추세인 것 같다. 바이브 코딩으로 게임을 만들어서 큰 돈을 벌었다는 사람도 있고, SNS에는 온갖 것들을 바이브 코딩으로 만들었다는 개발자 또는 비개발자들의 글이 넘쳐난다.
한편, 이를 바라보는 직업 프로그래머의 반응은 엇갈린다. 바이브에 올라타는 사람도 있고, 그로인한 리팩토링 대란이 벌어질 것이라는 얘기를 하는 사람들도 있다. 어쨌든 나는 바이브에 올라탄 사람 중에 한 명이긴 하다.
#0
내가 처음 바이브 코딩을 해본 건 작년 한글날 정도였던 것 같다. 한창 새로운 제품 코드를 작성하고 있었다. 이 제품은 몇 년을 개발이 지지부진한 것 중에 하나였다. 내가 코드를 쓰지 않은 것도 있었지만 새로운 제품을 우리가 감당할 수 있을까, 라는 생각도 컸었다. 새로운 제품은, 새로운 테스트를, 새로운 지원을, 새로운 영업을, 새로운 홍보를 필요로하는 일이니 말이다. 하지만 우리는 힘든 시기를 겪고 있었고, 더이상 미룰 수는 없었다. 마침 o1-preview가 출시되기도 했었다. 거기다 세월을 묵힌 시간만큼 리서치 자료는 많이 쌓여 있었다. 벤치마킹할 타사 제품도 수두룩했다.
처음에는 ChatGPT와 함께 작성하기 시작했다. 주로 4o에게 작업을 지시하고 결과를 내가 복붙해서 확인하는 작업이었다. ChatGPT로는 전체 프로그램을 한번에 작성하는 것은 쉽지 않기 때문에 전체 구조는 내가 생각했고 주로 함수 단위로 코딩을 지시해서 붙여넣었다. 당연히 출발은 우리의 리서치 자료에서 시작했다. 얼추 해당 자료대로 모두 구현을 했다. 그런데 테스트를 돌리니 예외가 너무 많이 발생했다. 리서치 자료가 크게 도움이 되지 않은 상황이었다.
여기서부터는 멘붕, 과연 이걸 해결할 수 있을까, 라는 생각. 대충 땜빵식으로 해결할수도 있겠지만 리얼월드에서는 무슨 일이 벌어질지 모르는 것이라 그것도 한계가 있었다. 모든걸 원점 재검토가 필요한 상황이었다. 그렇게 새로운 방법을 시도했다. 하지만 번번히 예외 케이스들이 너무 많이 발생하는게 문제였다. 코딩이 문제가 아니라 문서화되지 않은 것들에 대한 구조를 이해하는 게 핵심이었는데 그건 나도 모르고, ChatGPT도 모르는 게 큰 일이었다. 당연한 얘기였지만 다른 제품들도 모두 안되기는 마찬가지였다. 왜냐하면 타사 제품도 모두 동일한 오픈소스를 사용하고 있었고, 그 오픈소스 코드가 잘 동작하지 않는 경우가 많은게 문제였기 때문이다.
그렇게 설계를 3-4번은 뒤집어 엎었다. 최종적으로는 ChatGPT와 함께 오픈소스를 이해하기로 했다. 오픈소스는 너무 커서 거기서 내가 필요한 부분을 찾는 것도 일이었는데 웃긴 건 ChatGPT가 그걸 학습해서 그런지 오픈소스에서 내가 필요한 코드가 어디 있는지 물어보면 기가 막히게 알려줬다. 물론 오픈소스라는게 코드만 있다고 이해가 되는 건 아니다. 이해가 되지 않는 부분은 ChatGPT에 넣어서 다시 설명을 요청했다. 그 이해한 걸 토대로 ChatGPT한테 코딩을 시켜서 코드를 작성했다. 그 모든 작업을 하는 동안 o1-preview를 사용할 일은 한 번 밖에 없었다.
그러다 커서라는 걸 알게됐고 커서로 코딩을 시작했다. 커서는 전체 컨텍스트를 자동으로 llm에 보내 주기 때문에 코딩이 훨씬 편했다. 인라인 에디팅이나 블록을 지정해서 고치기가 훨씬 쉬운게 장점이었다. 그리고 브라우저로 와리가리 안해도 되서 시간이 많이 절약됐다. 그렇게 돌아보니 80%는 아니라도 얼추 70%는 인공지능이 코딩한 제품이 완성됐다. 그때는 바이브 코딩이란 말도 없던 시기라 묘한 기분이 들었다. 제품이 다 작성됐고 빌드 후 테스트를 진행하는 단계가 되니 뭔가 ChatGPT랑 뒷풀이라도 해야 할 것 같다는 생각이 들었다.
사람이면 설계를 3-4번 뒤집는 일을 참지 못했을 것 같다는 생각. 작성했지만 버렸던 수많은 코드에 엄청난 에고로 집착했을거라는 생각. 그리고 웃기게도 이 거대한 작업에서의 나에게 아하 모멘트는 이런 부분이었다. A라는 오픈소스에서 B라는 기능 관련된 코드가 어디있는지 알려줘. 이걸 당연히 답할거라고 생각을 안해서 물어볼 생각을 안했는데 하도 답답해서 물어봤는데 정말 어처구니 없을 정도로 정확하게 코드 위치를 잘 알려주었다.
#1
해가 바뀌었고 deepseek가 미국 주도 인공지능 세계에 한차례 충격을 가했다. 더불어 인공지능 오픈소스 생태계는 더욱 풍성해졌다. 장비를 구성할 능력만 되면 로컬에서도 o1 급의 리즈닝 모델을 돌릴 수 있는 세상이 된 것이다. 물론 deepseek-r1은 아직 로컬에서는 돌리기 부담스러운 671b 모델이긴 하다. 하지만 뒤따라 출시된 qwen2.5-coder-32b나 qwq-32b 같은 모델만 사용해도 나쁘지 않은 성능을 보여주었다. 그도 그럴것이 앞서도 언급했지만 대부분의 보통 프로그래머가 작성하는 코드란게 뭔가 대단한 코드가 아니기 때문이다. 안타깝게도 우리는 너무나 뻔한 코드를 대부분 작성하는 경우가 다반사니까 말이다.
최근에 일감이 하나 올라왔다. 고객사에서 api 사용에 문제를 겪는 일감이었다. 업체측에서 친절하게도 본인들이 구현한 코드를 보내주었다. 신입 개발자에게 확인해보라고 했지만 쉽지 않을거라는 생각이 들긴 했다. 그렇다고 내가 앉아서 그 모든 걸 보고 있기엔 다른 급한 일감도 너무 많았다. 그래서 딸깍 코딩을 해보기로 했다. 일감 내용과 업체 코드를 집어 넣고 문제를 재현할 수 있는 테스트 코드를 작성하라고 했다. 아키텍트로 qwq:32b_q4, 에디터로 qwen2.5-coder:32b_q4를 사용했다. 생각했던 것보다 아주 잘 작성했다. 웃긴건 걔가 제대로 작성했는데 내가 틀린 것 같아서 수정을 지시했는데, 업체측에 확인 요청한 결과 내가 지시한 부분이 잘못된 부분이었다. 걔가 원래 작성한 코드가 맞는 코드였다. 업체 측에서 우리가 봐도 되는 부분만 발췌해서 보낸 코드라 빠진 코드가 더러 있었다. 그런 코드는 나머지를 토대로 추론해서 작성하라고 지시를 했는데 그것도 잘 작성했다.
어쨌든 잘 만들 필요는 없지만 재현시키기 위해서는 복잡한 귀찮은 작업이 필요한 그런 작업이었다. 내가 한다고 해도 몇일은 걸릴 것 같은 일이었다. 그런데 정말 딸깍 코딩으로 모든 게 만들어졌다. 내가 일부 수정한 건 경로가 맞지 않아서 포함 경로를 수정하고 포함 파일이 빠진 걸 몇 개 추가한 게 다였다. 물론 이 또한 바이브 코딩을 할 수 있겠지만 그걸 타이핑하는 시간에 코드 고치는 게 훨씬 빠르기에 내가 직접 했다. 결과적으로 그렇게 전체 작업을 하는 데 걸린 시간은 1-2 시간도 채 되지 않았다. 물론 그 마저도 대부분의 시간은 걔가 코딩 하는 걸 대기하는 시간이었다. 왜냐하면 우리 장비는 그리 좋은 장비가 아니라 느리다는 점. 모델 2개를 한번에 메모리에 로딩할 수가 없어서 아키텍트하고 에디팅할 때 항상 모델 교체를 위한 시간이 낭비된다는 점 때문이다. 지시도 몇개 안했지만 대부분 생각보다 너무 잘해서 놀랐다.
#2
모든 코드를 잘 작성할 필요는 없다. 그냥 확인을 위해서 임시로 작성하는 코드도 수도 없이 많다. 그런 코딩은 인공지능에게 시키고 나는 중요한 다른 코드를 쓴다면 동시에 두가지 일을 하는 셈이 되는거니 생산성은 배가 된다. 시스템 프로그래머들에게 한참 전에 파이썬을 써야 한다고 하면 C/C++로도 다 할 수 있다는 핀잔을 듣던 시기가 있었다. 하지만 세월이 지나서 이제는 파이썬이 세상을 지배하고 있다. 인공지능도 머지 않아 그렇게 될 거라 본다. 직접해도 다 할 수 있다. 다만 인공지능을 사용하면 더 빨리 할 수 있다. 그리고 열린 마음으로 함께 한다면 나도 모르고, 인공지능도 모르는 것에 대한 작업도 함께 할 수 있다.
인정하기 싫지만 인공지능이 나보다 코드도 더 잘 읽고, 코드도 더 잘 작성한지는 생각보다 제법 오래되었다. 많은 경험을 토대로 느낀 점은 컨텍스트만 제대로 제공하면 거의 상당수 경우에 인간보다 훨씬 나은 결과가 나온다는 것이다. 그러니 이제, 안드레 카파시 말처럼 바이브에 몸을 맡기자.

[ai] 바이브 코딩의 시대

댓글