바이브코딩은 직접 코딩보다 즐겁지 않음

TL;DR

• 직접 코딩으로 얻는 즐거움과 비교하면, 바이브코딩은 결과물을 빠르게 만드는 데는 유용하지만 과정의 만족감과 성취감은 덜함.
• 바이브코딩은 아이디어와 결과물을 빠르게 연결해 즉각적인 만족감을 주지만, 어려움을 극복한 성취나 학습의 즐거움은 저절로 따라오지 않음.
• 직접 만들기에는 시간이 너무 많이 들어 실현하지 못했을 작업을 AI 코딩으로 완성한 사례도 있음.
• 결과물에 크게 만족한 경우에도, 소프트웨어를 직접 작성할 때 느끼는 즐거움과 바이브코딩의 과정은 다름.
• 바이브코딩은 프로젝트를 충분히 이해하고 현실과 직접 맞닿는 경험을 줄이며, 반복되는 자극은 무뎌질 수 있음.

만들기의 즐거움과 직접 코딩

• 무언가를 만드는 일은 큰 즐거움이며, 배우고 발견하는 일도 좋지만 만드는 일에서 더 큰 만족을 얻음.
• 실제 물건을 만드는 데 능숙하지 않아 소프트웨어 작성이 주된 만들기 경험이 됨. 소프트웨어는 아무것도 없는 상태에서 쓸모 있는 무언가를 만들기 쉬운 방법 중 하나임.
• 최근 취미로 만든 단순한 파이썬(Python) 스크레이퍼 두 개는 오랫동안 원했던 일을 해결했으며, 기본적인 기능만으로도 큰 기쁨을 줌. 수년 만에 프로그래밍이 가장 즐거웠던 경험임. [링크, 링크]
• 이 경험을 통해 만들기가 주는 기쁨을 새삼 실감함. 하지만 이후 인공지능(AI)이 등장함.
• 다른 사람들처럼 AI 보조 코딩을 조심스럽게 시도해 왔으며, AI를 그저 멍청하거나 생산성을 높이지 못한다고 쉽게 치부할 단계는 지남. 이에 따라 한발 물러서서, AI 코딩은 덜 즐겁다는 점을 말하고자 함.
• 바이브코딩은 처음에는 무척 짜릿하지만, 바이브코딩으로 만든 소프트웨어를 리팩터링하는 일은 그렇지 않음.
• 바이브코딩도 무언가를 직접 만드는 짜릿함을 어느 정도 제공함. 바이브코딩이 프로젝트와 경력 차원 모두에서 즐거움을 앞당긴다는 점이 그 확산을 이끄는 요인 중 하나라고 봄.

바이브코딩의 짜릿함 곡선

• 아이디어가 있으면 적은 노력으로 작동하는 시제품을 빠르게 만들 수 있어 즉각적인 도파민을 얻음.
• 코딩 경험이 없는 사람도 앱을 ‘코딩’할 수 있고, 앱이 제대로 작동할 가능성도 있어 즉각적인 도파민을 얻음.
• 즐거움을 미리 당겨 쓰지 않으려는 개인적 원칙이 있음. 하지 않은 일의 대가를 받거나, 빚을 지거나, 오늘 다른 사람이 내 일을 해 주는 대신 내일 내가 그 사람의 일을 하는 방식도 좋아하지 않음.
• 무언가를 만들 때 얻는 짜릿함과 만족감은 여러 갈래임.
• 아이디어를 떠올리는 짜릿함
• 아이디어를 현실로 만드는 짜릿함
• 힘들게 얻은 성취의 만족감
• 일을 잘 마무리한 만족감
• 배우는 즐거움
• 자신의 문제를 해결하는 무언가를 만드는 만족감
• 바이브코딩은 대체로 첫 번째, 두 번째, 여섯 번째 만족감을 줄 수 있지만, 세 번째부터 다섯 번째까지는 자연스럽게 따라오지 않음.

바이브코딩으로 만든 것들

• 바이브코딩을 옹호할 만한 점도 있음. AI를 이용해 그렇지 않았다면 만들 수 없었거나 만들지 않았을 결과물을 실제로 만들었음. 손으로 몇 주를 들여 만들 가치는 없지만 몇 분이나 며칠이면 만들 만한 경우가 주로 해당함.
• Taylor Troesh의 ‘Discuss on HN’ 코드 조각을 바탕으로, Hacker News에 이미 제출됐는지 확인하는 북마클릿을 한 번에 만들었음. 상당한 만족감을 줬고 실제 문제를 해결했으며, Wallabag 즐겨찾기 페이지에서 정기적으로 사용함.
• 예측 시장에 관한 짧은 강의에 곁들일 파티 게임인 ‘Party Market’을 짧은 시간 안에 바이브코딩으로 만들었음. 강의 중 ‘내가 얼마나 오래 떠들까’를 주제로 실제 시장을 운영해, 건조하고 지루한 강의를 수준 높은 오락으로 바꿈. 코드는 엉망이고 버그도 많았지만, 같은 시간 안에 직접 코딩으로 만들 수는 없었음. AI로 만들기와 손으로 만들기 중 하나를 고르는 상황이 아니라, AI로 만들기와 아예 만들지 않기 중 하나를 고르는 상황이었음.
• 아는 소방서장이 엔비디아(Nvidia) 카드나 제온(Xeon) 모델·세대조차 밝히지 않은 ‘AI 기기’에 지나치게 많은 돈을 투자하려 하자, 무료 요금제 Lumo를 이용해 두 차례 오후 작업으로 Pyronear 기반 산불 조기 경보 시스템을 바이브코딩으로 만들었음. 노트북에서 실시간 영상 피드를 처리했고, 제공한 발화 영상에서 연기가 처음 나타나는 프레임을 감지할 수 있었음.
• SQLite를 잘 모르는 사람도 새 기기로 책과 주석을 옮길 수 있도록 브라우저 기반 Kobo 데이터베이스 이전 도우미를 만들었음. [링크]
• 보컬 코치와의 노래 수업이 취소되자, 거의 10년 동안 만들 계획만 세웠던 실시간 음정 훈련 앱을 만들었음.
• 이들 결과물 대부분에 크게 만족했지만, 만드는 과정은 단순한 스크레이퍼를 직접 작성할 때처럼 즐겁지 않았음.

직접 코딩이 주는 성취감

• 직접 소프트웨어를 개발하는 일이 항상 즐거운 것은 아님. 첫 Go 프로젝트는 마감이 있는 상황에서 상당 시간 동안 전혀 즐겁지 않았고, 처음 Rust 코드를 스무 줄쯤 작성하려 했을 때 컴파일러와 씨름하는 일도 마찬가지였음.
• 그러나 장기적으로는 성취감을 주는 ‘유형 2의 즐거움(Type II fun)’이었음. 해냈다는 기분이 들었고, 다음에는 더 쉬워질 것이라는 감각도 얻음.
• llama-server에서 실행하는 로컬 모델부터 Phind, Lumo 같은 무료·가입 불필요 서비스에서 결과를 복사해 쓰는 일회성 스크립트, 원격 서버의 Clod Masterpiece 200™ 무제한 요금제와 위험할 정도로 --dangerously-skip-permissions에 가까운 사용자 작성 자동 승인 훅, 알고리즘 트레이딩 모델 개발까지 여러 방식을 시도했음.
• 어떤 방식을 택해도 비슷한 결과임. 생산성은 있지만 그 방식이 주는 느낌과 결과물의 품질이 마음에 들지 않음. 존중할 만한 결과를 얻지 못한 채 스스로를 무능하고 불필요하게 느끼게 하며, 때로는 사용했다는 사실만으로도 불쾌함을 느낌.

도파민과 현실 사이의 거리

• 도파민이라는 말을 떠올리면 바이브코딩은 연속되는 첫 데이트나 하룻밤 만남과 비슷함. 프로젝트와 관계를 쌓지 못하고, 따뜻한 애착이나 옥시토신, 유대감을 같은 방식으로 얻지 못함. 도파민만 좇는 삶에서는 자극이 반복될수록 무뎌짐.
• 바이브코딩은 사람과 현실 사이에 층을 하나 더함. 대체로 현실을 직접 경험할 때 더 즐겁다고 생각함.
• 바이브코딩은 통제권을 거의 쥐지 못한 대기업의 임원이 되는 것과 비슷함. 무슨 일이 일어나는지 제대로 알지 못하고, 방해와 태만이 있다는 의심도 늘 남음. 결과물은 완성된 형태로 나타나지만 상상한 것과 조금씩 다름. 작동할 때도 있고 그렇지 않을 때도 있으며, 블랙박스에 더 많은 돈을 붓고 더 크게 소리치는 것 외에는 할 수 있는 일이 없음. 그래서 결국 그렇게 함.
• 이 글의 개요는 촛불 아래 파란 잉크로 작성했으며, AI는 오탈자도 고치지 못하게 했음. 오탈자도 그대로 즐기기를 바람.

주석

• 1. 어릴 때 발명가가 되고 싶었음. 발명가는 만들기와 발견을 깔끔하게 결합하는 직업임. 글쓰기와 노래 만들기도 주요 활동이며, 소프트웨어처럼 물리적 현실이나 다른 사람과 접촉할 일이 다행히 적은 만들기의 한 형태임.
• 2. 주로 셸 스크립트를 작성해 왔으며, Bash는 즐거운 언어로 알려져 있지 않음.