소프트웨어 개발의 미래는 바이브에 달려 있을까요?
인공지능(AI)이 작성한 코드를 이해 없이 사용하는 경향이 점점 늘고 있다고 합니다.
바이브 코딩이란 무엇일까요?
코딩은 컴퓨터에게 무엇을 해야 할지 정확하게 지시하고, 컴퓨터가 그 명령을 반복적으로 수행하도록 하는 것입니다. 하지만 챗GPT(ChatGPT)와 같은 AI 도구의 등장으로, 이제는 영어를 사용하여 프로그램을 설명하면 AI 모델이 코드가 어떻게 작동하는지 이해하지 않고도 실행 가능한 코드로 변환해 줍니다. 전 OpenAI 연구원이었던 안드레이 카파시(Andrej Karpathy)는 이러한 방식을 “바이브 코딩(vibe coding)”이라고 명명했고, 기술 업계에서 인기를 얻고 있다고 해요.
오픈AI(OpenAI)와 앤트로픽(Anthropic) 같은 회사의 대규모 언어 모델(LLM, Large Language Models) 덕분에 가능해진 이 기술은 소프트웨어 제작의 진입 장벽을 낮출 수 있다는 점에서 주목을 받고 있습니다. 하지만 커서 컴포저(Cursor Composer), 깃허브 코파일럿(GitHub Copilot), 레플릿 에이전트(Replit Agent)와 같은 도구들이 비프로그래머들에게도 점점 더 쉽게 접근할 수 있도록 만들고 있지만, 이 접근 방식이 실제 애플리케이션에 적합한 코드를 안정적으로 생성할 수 있는지에 대한 의문은 여전히 남아있습니다.
바이브 코딩은 제어와 정확성보다는 흐름에 몸을 맡기는 것에 가깝습니다. 카파시는 지난 2월 2일, X(구 트위터)에 “저는 ‘바이브 코딩’이라고 부르는 새로운 종류의 코딩을 하고 있습니다. 여기서 여러분은 완전히 바이브에 몸을 맡기고, 지수적인 것을 받아들이고, 코드가 존재한다는 사실조차 잊어버립니다.”라고 게시하며 이 용어를 소개했습니다. 그는 이 과정을 의도적으로 가볍게 표현했습니다. “저는 그냥 보고, 말하고, 실행하고, 복사해서 붙여 넣는데, 대부분 잘 됩니다.”
바이브 코딩을 할 때 오류가 발생하면, 오류를 AI 모델에 다시 입력하고, 변경 사항을 적용하고, 잘 되기를 바라며, 이 과정을 반복합니다. 카파시의 기술은 일반적으로 신중한 계획, 테스트 및 구현 세부 사항에 대한 이해를 강조하는 전통적인 소프트웨어 개발 모범 사례와는 극명한 대조를 이룹니다.
카파시는 자신의 게시물에서 “사이드바의 패딩을 절반으로 줄여달라는 것과 같이 가장 어리석은 것을 요청합니다. 왜냐하면 제가 직접 찾기에는 너무 게으르기 때문입니다. 저는 항상 ‘모두 수락’합니다. 더 이상 차이점을 읽지 않습니다.”라며 이 접근 방식이 궁극적으로 게으른 프로그래머를 위한 경험이라고 유머러스하게 인정했습니다.
핵심적으로 이 기술은 기본적인 의사소통 능력을 가진 사람이라면 누구든 새로운 유형의 자연어 프로그래머로 만들어줍니다. 적어도 간단한 프로젝트에서는요. AI 모델이 한 번에 소화할 수 있는 코드의 양(컨텍스트 크기)에 의해 현재 제약을 받고 있기 때문에, 바이브 코딩된 소프트웨어 프로젝트가 복잡해지기 전에 운전대를 잡은 사람이 AI가 생성한 코드 조각을 더 큰 아키텍처로 수동으로 조립하는 고위 프로젝트 관리자가 되는 경향이 있습니다. 하지만 기술적인 한계가 AI 모델의 각 세대마다 확장됨에 따라, 언젠가는 이러한 한계가 사라질 수도 있습니다.
누가 바이브 코더일까요?
취미 프로젝트나 개발 업무를 통해 바이브 코딩을 하는 사람이 정확히 얼마나 되는지는 알 수 없지만, 커서는 2024년 8월에 4만 명의 유료 사용자를 보고했고, 깃허브는 1년 전(2024년 2월)에 130만 명의 코파일럿 사용자를 보고했습니다. 레플릿 에이전트의 사용자 수는 찾을 수 없지만, 이 사이트는 3천만 명의 사용자를 보유하고 있다고 주장하며, 이 사이트의 AI 기반 코딩 에이전트를 사용하는 비율은 알려지지 않았습니다.
한 가지 확실한 것은 이 접근 방식이 온라인에서 게임을 빠르게 프로토타입하는 재미있는 방법으로 특히 인기를 얻고 있다는 것입니다. 마이크로소프트의 피터 양(Peter Yang)은 최근 커서와 클로드(Claude) 3.7 소넷에 대화형 프롬프트를 입력하여 간단한 3D 1인칭 슈팅 좀비 게임을 만드는 방식으로 X 스레드에서 바이브 코딩을 시연했습니다. 양은 심지어 자신이 보고 싶은 것을 말로 설명하고 시간이 지남에 따라 프로토타입을 개선할 수 있도록 음성-텍스트 변환 앱을 사용했습니다.
몇몇 사람들은 작은 게임을 만들거나, 맞춤형 유틸리티를 만들거나, 처리 스크립트를 작성하는 등 과외 취미 프로젝트를 위해 AI 어시스턴트와 코딩 도구를 사용했습니다. 바이브 기반 코드 지니는 예상치 못한 곳에서 유용할 수 있습니다.
바이브 디버깅
이러한 바이브 코딩이 진행됨에 따라, 우리는 전문가에게 의견을 구해야 했습니다. 독립 소프트웨어 개발자이자 AI 연구원인 사이먼 윌리슨(Simon Willison)은 AI 지원 프로그래밍에 대한 미묘한 관점을 제시했습니다. “저는 바이브 코딩을 정말 즐깁니다.”라고 그는 말했습니다. “아이디어를 시험해보고 그것이 작동하는지 증명하는 재미있는 방법입니다.”
하지만 윌리슨이 얼마나 멀리 갈지는 한계가 있습니다. “바이브 코딩으로 프로덕션 코드베이스를 만드는 것은 분명히 위험합니다. 우리가 소프트웨어 엔지니어로서 하는 대부분의 작업은 기존 시스템을 발전시키는 것과 관련이 있으며, 여기서 기본 코드의 품질과 이해 가능성이 중요합니다.”
AI가 생성한 코드에는 버그, 오해 및 허위 정보(예: AI 모델이 존재하지 않는 함수 또는 라이브러리에 대한 참조를 생성하는 경우)가 포함될 수 있기 때문에, 적어도 코드의 일부를 이해하는 것이 중요합니다.
개발자 벤 사우스(Ben South)는 “바이브 디버깅을 해야 할 때까지는 모든 바이브 코딩이 재미있고 게임입니다.”라고 X에서 지적하며 이 근본적인 문제를 강조했습니다.
윌리슨은 최근 자신의 블로그에서 AI 코딩 도구에서 허위 정보를 접하는 것이 AI가 생성한 잘못된 정보를 서면 보고서에 포함시키는 것만큼 해롭지 않다고 주장했습니다. 왜냐하면 코딩 도구에는 사실 확인 기능이 내장되어 있기 때문입니다. 허위 정보가 있으면 코드가 작동하지 않습니다. 이것은 바이브 코딩의 신뢰성에 대한 자연스러운 경계를 제공합니다. 코드가 실행되거나 실행되지 않거나 둘 중 하나입니다.
그럼에도 불구하고, 바이브 코딩에 대한 위험-보상 계산은 전문적인 환경에서 훨씬 더 복잡해집니다. 개인 프로젝트를 위해 바이브 코딩의 절충안을 수용할 수 있지만, 엔터프라이즈 환경에서는 일반적으로 바이브 코딩된 솔루션이 충족하기 어려울 수 있는 코드 유지 관리 및 신뢰성 표준이 필요합니다. 코드가 예상대로 작동하지 않으면 디버깅을 하려면 코드가 실제로 무엇을 하고 있는지 이해해야 합니다. 이것이 바로 바이브 코딩이 회피하는 경향이 있는 지식입니다.
이해 없이 프로그래밍하기
윌리슨은 바이브 코딩을 정확히 무엇으로 구성하는지 정의할 때 중요한 구분을 합니다. “LLM이 코드의 모든 줄을 작성했지만, 여러분이 그것을 검토하고, 테스트하고, 이해했다면, 그것은 제 생각에는 바이브 코딩이 아닙니다. 그것은 LLM을 타이핑 어시스턴트로 사용하는 것입니다.” 대조적으로, 바이브 코딩은 코드가 어떻게 작동하는지 완전히 이해하지 않고 코드를 수락하는 것을 포함합니다.
바이브 코딩은 카파시에서 장난스러운 용어로 시작되었지만, 일부 개발자가 프로그래밍 작업에 접근하는 방식의 실제 변화를 캡슐화할 수 있습니다. 깊은 기술적 이해보다 속도와 실험을 우선시하는 것이죠. 그리고 어떤 사람들에게는 그것이 끔찍할 수도 있습니다.
윌리슨은 개발자가 자신의 코드에 대한 책임을 져야 한다고 강조합니다. “저는 개발자로서 여러분이 생성하는 코드에 대한 책임을 져야 한다고 굳게 믿습니다. 여러분이 자신의 이름을 붙이려면 그것이 어떻게 그리고 왜 작동하는지 확신해야 합니다. 이상적으로는 다른 사람에게 설명할 수 있을 정도까지요.”
그는 또한 기술 부채에 대한 일반적인 경로에 대해 경고합니다. “가능한 것을 탐색하고 재미있는 프로토타입을 구축하고 싶은 실험과 낮은 지분 프로젝트의 경우? 마음껏 하세요! 하지만 충분히 좋은 프로토타입이 종종 생산에 투입해야 한다는 압력에 직면한다는 매우 현실적인 위험을 인식하세요.”
프로그래밍 직업의 미래
그렇다면 이 모든 바이브 코딩이 인간 프로그래머의 직업을 앗아갈까요? 핵심적으로 프로그래밍은 항상 컴퓨터에게 어떻게 작동해야 하는지 알려주는 것이었습니다. 우리가 그렇게 하는 방법은 시간이 지남에 따라 바뀌었지만, 자연어로도 다른 사람들보다 컴퓨터에게 무엇을 해야 할지 정확하게 알려주는 데 더 능숙한 사람들이 항상 있을 수 있습니다. 어떤 면에서 그 사람들은 새로운 “프로그래머”가 될 수도 있습니다.
1970년대 후반에서 80년대 초반에는 사용 가능한 다양한 컴퓨터 플랫폼에 대한 사전 구축된 애플리케이션이 거의 없었기 때문에 많은 사람들이 컴퓨터를 효과적으로 사용하려면 프로그래밍 기술이 필요하다고 생각했던 시점이 있었습니다. 전 세계의 학교 시스템은 사람들에게 코딩을 가르치기 위해 교육용 컴퓨터 활용 노력을 기울였습니다.
오래지 않아 사람들은 코더가 아닌 사람들이 컴퓨터를 쉽게 사용할 수 있도록 하는 유용한 소프트웨어 애플리케이션을 만들었습니다. 프로그래밍이 필요하지 않았죠. 그렇다고 프로그래머가 사라진 것은 아닙니다. 대신 그들은 애플리케이션을 사용하여 더 나은 프로그램을 만들었습니다. 아마도 AI 코딩 도구에서도 그런 일이 일어날 것입니다.
비유하자면, 자동 조종 장치와 같은 컴퓨터 제어 기술은 가장 고도로 훈련되고 유능한 인간만이 안전하게 제어할 수 있는 비행의 측면을 처리할 수 있었기 때문에 안정적인 초음속 비행을 가능하게 했습니다. AI는 프로그래밍에 대해서도 동일한 작업을 수행하여 인간이 수동으로 코딩하는 데 너무 많은 시간이 걸리는 복잡성을 추상화할 수 있도록 하고, 이를 통해 미래에 더 복잡하고 유용한 소프트웨어 경험을 만들 수 있도록 할 수 있습니다.
하지만 그 시점에서 인간은 여전히 그것들을 이해하거나 디버깅할 수 있을까요? 아마 아닐 겁니다. 우리는 AI 도구에 완전히 의존하게 될 수도 있고, 어떤 사람들은 그것이 약간 무섭거나 현명하지 않다고 생각할 것입니다.
바이브 코딩이 프로그래밍 환경에서 지속될지 아니면 프로토타입 기술로 남을지는 AI 모델의 기능보다는 조직이 코드 품질, 유지 관리 가능성 및 기술 부채에서 위험한 절충안을 수용할 의향에 따라 달라질 것입니다. 현재로서는 바이브 코딩은 AI와 인간 개발자 간의 혼란스럽고 실험적인 관계에 대한 적절한 설명으로 남아 있습니다. 자율적이기보다는 협력적이지만, 누가(또는 무엇이) 실제로 프로그래밍을 하고 있는지에 대한 경계가 점점 더 모호해지고 있습니다.