"바이브 코딩의 한 해"라는 제목의 기사를 봤는데, 지난 한 해 동안의 바이브 코딩을 아주 잘 요약해 놓은 기사였어요. 많은 사람들이 아르민 로나허라는 저자를 잘 모를 수도 있지만, 파이썬을 사용해 본 적이 있다면 10년도 더 전에 그가 만든 Flask 프레임워크를 사용해 봤을 가능성이 높습니다. 문서의 첫 문장이 제 마음에 와닿았습니다. "2025년에는 더 이상 예전처럼 코드를 작성하지 않을 것이다." 그의 경험과 유사하게, 거의 20년 동안 코딩을 해온 한 사람은 이제 인공지능에게 코드 작성을 지시하는 일을 주 업무로 삼고 있습니다. 그는 이를 "키보드를 직접 두드리는 프로그래머"에서 "가상 인턴을 이끄는 기술 리더"로의 전환에 비유합니다. 제가 바이브 코딩으로 전환하게 된 계기는 클로드 코드 덕분이었고, 그 역시 마찬가지였습니다. 올해 4월이나 5월쯤, 그는 클로드 코드 사용에 푹 빠졌습니다. 몇 달 동안 그는 자신의 블로그에 36개의 글을 게시했는데, 이는 2007년 이후 블로그에 올라온 전체 글의 18%에 해당합니다. 이는 그에게 시간이 더 많아져서가 아니라, AI 덕분에 지루한 구현 작업에서 벗어날 수 있었기 때문입니다. 그는 현재 Amp, Claude Code, Pi라는 세 가지 AI 프로그래밍 도구를 동시에 사용하고 있습니다. 그는 이 세 가지 도구를 포르쉐에 비유했는데, 포르쉐는 세련되고 정교하며, Claude Code는 폭스바겐처럼 저렴하면서도 강력하고, Pi는 해커들을 위한 오픈 소스 장난감과 같다고 했습니다. 세 가지 도구는 각각 다른 스타일을 가지고 있지만, 어느 것이 더 나은지는 꼽을 수 없다고 했습니다. 저 개인적으로는 주로 Codex를 사용하고, GitHub Copilot과 Claude Code를 보조적으로 활용합니다. 설문조사를 실시한다면, 모두가 '분위기'를 사용하고 있기 때문에 각자 다른 AI 프로그래밍 도구를 선택할 것이라고 예상합니다. "바이브(Vibes)"라는 단어는 글 전체에 걸쳐 등장하며, 제목의 어원이기도 합니다. 문자 그대로 "분위기" 또는 "느낌"을 의미하지만, 여기서는 수량화할 수 없고 직관적으로만 느낄 수 있는 판단 기준을 가리킵니다. 2025년 인공지능 프로그래밍에서 가장 이상한 점은 아마도 50년 넘게 축적된 업계 엔지니어링 경험이 갑자기 효력을 잃는다는 사실일 것입니다. 인공지능이 생성한 코드에 직면했을 때, 코드 표준과 모범 사례는 결국 일종의 신비에 의존하게 됩니다. 이 모델이 "더 편하게 느껴진다", 저 도구가 "더 사용하기 편하게 느껴진다"는 식이죠. 가장 이성적인 프로그래머 집단이 이제는 가장 감정적인 방식으로 기술 스택을 선택하고 있다. 아르민은 MCP(모델 컨텍스트 프로토콜)를 사용하며 1년 내내 애를 먹었고, 신뢰성이 떨어진다고 생각했다. 하지만 이를 뒷받침할 데이터가 부족했기에, 그는 그저 "어쨌든 나한테는 안 맞는 것 같아"라고 말할 수밖에 없었다. 그러는 동안 다른 사람들은 MCP를 열정적으로 사용하고 있었다. 연초에 클로드를 소개해 준 친구 피터는 코덱스를 사용하며 매우 만족해했다. 아르민도 코덱스를 사용해 봤지만, 그다지 매력적이라고 느끼지 못했다. 누가 옳고 누가 그른가? 정답은 없다. 모두가 어둠 속에서 더듬거리고 있을 뿐이다. 인간과 기계의 관계에서 비롯되는 더욱 깊은 불안감이 존재한다. 그는 이러한 도구들과 일종의 '준사회적 유대감'을 형성하기 시작했는데, 이는 일방적인 친밀감으로 이해할 수 있습니다. 마치 특정 스트리머나 아이돌에게 감정을 투영하는 것과 같은 것으로, 상대방은 실제로 나를 알지 못하지만 항상 매우 친숙함을 느끼는 것입니다. 인공지능 도구가 왜 이런 감정을 불러일으킬까요? 현대 인공지능은 기억력이 뛰어나기 때문입니다. 이전에 나눴던 대화 내용까지 떠올릴 수 있죠. 마치 '인격'을 가진 것처럼 보이기 시작했습니다. 아르민은 지난 2년간 이러한 모델들을 '토큰 믹서'처럼, 즉 순전히 확률적인 기계로 다루며 스스로 훈련해 왔다고 합니다. 하지만 이제 그런 단순한 관점은 더 이상 통하지 않는다고 생각합니다. 이러한 시스템들은 인간과 유사한 경향을 보이지만, 그것들을 인간 수준으로 격상시키는 것은 잘못된 판단이다. 그렇다면 그것들은 정확히 무엇일까? 누구도 명확한 정의를 내릴 수 없다. 아르민은 심지어 "에이전트"라는 단어조차 어려워했다. 왜냐하면 에이전트라는 단어는 자율성과 책임감을 내포하는데, 이 두 가지는 인간의 손에 남아 있어야 하기 때문이다. "그것을 뭐라고 불러야 할지 모르겠다"는 이 혼란 자체가 많은 것을 말해준다. 기사 말미에서 그는 업계가 해결해야 할 몇 가지 문제점을 나열했습니다. 첫 번째는 버전 관리입니다. Git과 GitHub는 프로그래머에게 필수적인 도구이지만, 현재 중요한 정보 하나가 부족합니다. 바로 명령어 입력 과정입니다. AI가 코드를 생성할 때, 최종 버전만으로는 변경 사항의 품질을 판단할 수 없습니다. 어떤 명령어를 통해 이 코드가 생성되었는지, 그리고 그 과정에서 어떤 단계를 거쳤는지 알아야 합니다. 더욱 흥미로운 점은 그의 발견 중 하나인 '실패한 시도가 AI에게 가치 있다'는 것입니다. AI를 이전 상태로 되돌리려면 어떤 경로가 실패했는지 기억하도록 해야 합니다. 하지만 현재 우리가 사용하는 도구들은 이러한 기능을 고려하여 설계되지 않았습니다. 대화 기록을 삭제하면 AI는 같은 실수를 반복하게 됩니다. 두 번째 문제는 코드 리뷰입니다. 현재 GitHub의 리뷰 인터페이스는 디자인이 터무니없습니다. 자신의 코드를 공식적으로 리뷰할 수 없고, 댓글만 남길 수 있습니다. 하지만 AI 프로그래밍 시나리오에서는 프로그래머가 풀 리퀘스트에 AI에게 지시사항을 남겨야 하는 경우가 많습니다. 기존 방식은 이러한 인간-기계 협업을 전혀 고려하지 않습니다. 세 번째는 관찰 가능성입니다. 이는 다소 기술적인 주제이지만, 핵심 아이디어는 많은 모니터링 및 디버깅 도구가 너무 복잡해서 이전에는 사용되지 않았지만, AI는 복잡한 것을 처리하는 데 탁월하다는 것입니다. 따라서 그동안 외면당했던 솔루션들을 다시 주목받게 할 필요가 있습니다. 마지막으로 그는 다소 민감한 주제를 언급했습니다. 일부 사람들은 AI가 생성한 코드를 더 이상 검토하지 않고 그냥 실행에 옮기는 방식으로 완전히 "손을 놓았다"는 것입니다. 미친 짓일까요? 네, 미친 짓입니다. 하지만 아르민은 이런 방식으로 꽤 성공적으로 코드를 실행하는 사람들을 본 적이 있습니다. 그 자신은 아직 그렇게 할 수 없습니다. 여전히 모든 코드 줄을 꼼꼼히 검토합니다. 어떤 것이 존재한다는 것은 그것에 대한 합리적인 근거가 있음을 의미하며, 이러한 "간섭하지 않는" 접근 방식은 완전히 새로운 작업 방식이 형성되고 있음을 나타냅니다. 이 접근 방식은 그가 익숙한 소프트웨어 엔지니어링 방법론과는 완전히 다릅니다. 이로 인해 오픈소스 커뮤니티에 골칫거리가 되고 있습니다. 인공지능(AI)이 인간의 필터링 없이 무분별하게 풀 리퀘스트(PR)를 생성하고 있기 때문입니다. 전통적인 프로세스를 고수하는 관리자들에게 이러한 PR은 사실상 모욕이나 다름없습니다. 아르민은 상세한 기여 가이드라인과 PR 템플릿을 작성하는 것으로 해결책을 제시했지만, 이는 마치 돈키호테가 풍차를 향해 돌진하는 것과 같다는 것을 알고 있습니다. 어쩌면 해결책은 다른 사람들이 수정하도록 하는 것이 아니라, AI 프로그래밍을 적극적으로 지지하는 사용자들이 나서서 "AI를 이용해 책임감 있게 코드를 작성한다"는 것이 무엇을 의미하는지 보여주는 것일지도 모릅니다. 이 글을 읽고 깊은 공감을 느꼈습니다. 선임 엔지니어의 진솔한 혼란이 느껴졌습니다. 그는 AI를 찬양하는 설교자도 아니고, 변화를 거부하는 완고한 사람도 아닙니다. AI를 깊이 있게 사용하면서도 동시에 깊은 회의감을 품고 있는, 어정쩡한 입장에 서 있는 것입니다. 2025년이 저물어가는 지금, 그가 제기했던 질문들 중 어느 하나도 답을 찾지 못했습니다. 인공지능의 코드를 어떻게 검열할 것인가? 인공지능의 실패에 대한 기억을 어떻게 보존할 것인가? 우리에게 감정을 불러일으키는 도구와 어떻게 적절한 거리를 유지할 것인가? 이 질문들에 대한 답이 차세대 성공 제품의 방향을 제시할 수 있을 것입니다.
