[기고] ‘바이브 코딩’은 왜 실패하는가

김응창 SK텔레콤 Agent플랫폼개발팀 매니저

바이브 코딩은 멋지다. 너무 재밌어서 바이브 코딩에 중독되는 사람들이 쏟아지고 있다. 하지만 바이브만으로 할 수 있는 것은 생각보다 적다. 보통 인공지능(AI)을 활용하는 프로그래밍을 모두 바이브 코딩이라고 부르지만, 정확한 용법은 아니다. 이 용어를 처음 사용한 안드레 카파시는 이렇게 정의했다. “바이브 코딩은 바이브에 완전히 몸을 맡기고, 기하급수적인 변화를 자연스럽게 받아들이며, 코드가 존재하는지조차 잊어버리는 새로운 방식이다.” 또 그는 바이브 코딩이 너무 잘 된다며 “그저 보고, 말하고, 실행하고, 복사하고 붙여넣을 뿐인데, 웬만하면 잘 돌아갔다”고 했다.

여기서 말하는 ‘바이브’(vibe)는 분위기, 흐름, 느낌이 섞인 말이다. 엄밀한 설계보다는 “대충 이런 느낌으로”, 논리적 구성보다는 “잘 모르겠지만 그냥 해줘”라고 하는 것에 가깝다. 즉 골치 썩이지 않고 “딸깍” 하는 것이 핵심이다. 대화창을 열어서 모호한 지시를 내리고(“멋진 데이팅 앱을 만들어줘”), 이후의 작업도 대화로 풀어간다면(“좀 더 따뜻한 분위기면 좋겠어”), 그게 바로 바이브 코딩이다.

마법 같은 일이 아닐 수 없다. 수천만원, 수억원을 들여 개발사와 계약해도 개발자들에게 요건을 설명하는 것은 절대 쉬운 일이 아니다. 인간 개발자들은 모호한 요건에는 일을 시작하지 않고, 구체적인 요건이 주어지면 딱 그것만 개발하며, 항상 왜 그것도 모르냐는 한심한 표정으로 쳐다본다. 반면 우리가 챗GPT에 아무렇게나 말하듯 AI 개발자에게 말하면, AI 개발자는 정말 좋은 아이디어라는 칭찬과 함께 내가 시키지 않은 것들까지 만들어준다.

문제는 그것이 너무 마법 같다는 데 있다. ‘견습 마법사의 함정’이라는 오래된 표현이 있는데, 괴테가 1797년에 쓴 시에 나오는 이야기다. 마법사의 제자는 스승이 없을 때 물 떠오는 일을 하기 싫어 빗자루에게 마법을 걸어 그 일을 대신 시킨다. 그런데 제자는 빗자루를 멈추게 하는 마법은 몰랐다. 온 바닥이 물로 넘쳐나자 제자는 억지로 멈추기 위해 도끼로 빗자루를 반으로 잘랐다. 하지만 빗자루는 두 개가 되어 두배 빠르게 온 집을 물바다로 만든다. 결국은 스승이 돌아와 이를 멈추고 말한다. “너희를 목적에 따라 불러낼 수 있는 이는 오직 늙은 스승뿐이다.”

우리는 마법의 동작 원리를 모르기 때문에 견습 마법사의 함정에 빠진다. 바이브 코딩도 마찬가지다. 많은 사람들이 바이브 코딩으로 만든 앱을 실제로 서비스하는 데 애를 먹는다. 올해 3월 미국의 작가이자 창업가인 댄 시퍼는 문서 편집기 프루프(Proof)를 공식 출시했다. 다행히 서비스는 바이럴을 탔고 4000개 이상의 문서가 생성됐지만, 하루 종일 원인을 알 수 없는 문제로 사용자들은 문서에 접근하지 못했다. 시퍼는 24시간 잠을 자지 못한 채로 코덱스(Codex) 에이전트가 버그를 조사하는 것을 지켜볼 수 밖에 없었다고 썼다.

그래서 이제 개발자 커뮤니티에서는 바이브 코딩이라는 용어를 약간 깎아내리는 말로 쓰기도 한다. “뭘 하는지도 모르고 한 줄 프롬프트로 만든 앱”이라거나, “시연은 될지 몰라도 성능, 안정성, 보안성은 의심되는 프로그램”이라는 뉘앙스다.

제미나이가 그린 일러스트.

물론 이제는 모든 개발자가 AI를 이용한다. 바이브 코딩이라는 용어의 창시자인 안드레 카파시도 이후 좀더 전문적인 개발 방식으로 ‘에이전틱 엔지니어링’(Agentic Engineering)이라는 표현을 사용했다. AI의 코드 작성 능력에 의존하는 것이 아니라 AI를 조율하고 검증하는 기술적인 역량이 필요하다는 것이 핵심이다.

AI가 그렇게 좋아졌는데도 왜 ‘딸깍’이 안 된다고들 하는 걸까? 큰 이유 중 하나는 인간의 속도에 비해 ‘너무 빨리’ 만든다는 점이다. 미국 몬태나 주립대의 카슨 그로스 교수는 컴퓨터 프로그래밍은 근본적으로 두 가지라고 정의한다. 첫째는 컴퓨터를 이용해 문제를 해결하는 것이고, 둘째는 그 문제를 해결하는 과정에서 복잡도를 제어하는 방법을 배우는 것이다.

AI가 컴퓨터를 이용해 하나의 문제를 푸는 능력은 벌써 인간이 따라잡을 수 없는 수준처럼 보인다. 맞는 답을 내놓기만 하면 되고, 그 다음에는 잊어버려도 된다면 AI가 대부분의 사람보다 훨씬 낫다. 하지만 AI는 복잡도를 제어하는 데는 관심이 적어 보인다. 현실에서의 프로그래밍은 매일 작은 문제들을 풀어가면서도 최대한 일관적인 형태, 되도록 쉬운 형태로 유지하는 과정이다. 동작은 하지만 지저분한 코드를 유지보수하기 쉽도록 간단하게 만드는 작업, 즉 리팩토링(Refactoring)은 대부분 업무 성과로 인정받지 못한다.

하지만 개발자들은 ‘자신이 살기 위해’ 이 작업을 한다. 바이브 코딩으로 자신이 이해하지 못하는 코드를 만들었다면, 어느 부분이 더 쉬워져야 하는지 모르는 것이 당연하다. 아이러니하게도 인간이 보기에 잘 정리된 코드를 AI도 더 잘 이해하는 것처럼 보인다.

그러니까 코드를 잘 읽을 수 있는 능력은 아직 중요해 보인다. 이를 위해 코드를 짤 수 있는 능력을 키워야 한다. 따라서 코딩 공부는 헛된 것이 아니다. 2026년 6월 현재까지는 말이다.