부제: 프로토타입부터 프로덕션 팀의 실무까지, 단계별 실험 사례를 통해 확인한 바이브 코딩의 가능성과 한계

들어가며

지난 4월 15일, 사내 개발자들과 ‘바이브 코딩(vibe coding)’을 주제로 라이브 인터뷰를 진행했습니다.
이 글은 그 인터뷰와, 지난 3월 중순부터 진행한 바이브 코딩 실험을 바탕으로 한 기록입니다.
AI 에이전트와의 협업이 실제 개발에 어떤 변화를 가져오는지 직접 느낀 점들을 공유합니다.

바이브 코딩이란?

Q. 바이브 코딩이란 개념이 낯선 분들도 있을 것 같습니다. 간단히 소개해주실 수 있을까요?

‘바이브 코딩’은 2025년 2월, 안드레 카파시(Andrej Karpathy)가 X(구 트위터)를 통해 언급하며 주목을 받기 시작한 개념입니다.

“나는 이걸 ‘바이브 코딩’이라고 부른다. 그냥 바이브(느낌)에 몸을 맡기고, 지수적으로 발전하는 과정을 즐기며, 코드가 있다는 사실조차 잊어버리는 방식이다. 이렇게 할 수 있는 이유는 Cursor Composer와 Sonnet 같은 LLM들이 너무 좋아졌기 때문이다. 나는 SuperWhisper를 통해 Composer에게 그냥 말만 하면 되니까, 키보드에도 거의 손을 대지 않는다.”

👉 원문 보기

요약하자면, 바이브 코딩은 ‘무엇을 만들고 싶은지’를 말로 설명하면, AI가 구현을 대신하는 새로운 형태의 개발 방식입니다.

이전까지의 코드 자동완성이나 챗봇형 코딩을 넘어, 커서(Cursor)와 같은 코딩 에이전트와 최신 LLM 성능의 결합을 통해 “개발자의 의도만으로 구현이 이루어지는” 완전히 새로운 프로그래밍 흐름이 가능해졌다는 점에서 주목받고 있습니다.

사례로 보는 바이브 코딩

Q. 바이브 코딩은 주말에 재미삼아 만드는 프로젝트라면 나쁘지 않다는 말에 대해 어떻게 생각하시나요?

저 역시 안드레 카파시가 말한 ‘순수 바이브 코딩’—즉, AI가 생성한 코드를 일일이 검토하지 않고, 말 그대로 느낌에 따라 개발을 진행하는 방식—은 프로덕션 환경보다는 토이 프로젝트나 실험적인 상황에 적합한 접근이라고 생각했습니다. 이러한 가능성을 검증해보기 위해 짧은 실험을 해보았습니다.

그러나 막상 바이브 코딩을 해보니 단순한 실험에 머무르지 않고 실무 환경에서도 충분히 적용 가능한 방식임을 체감하게 되었습니다. 결과적으로 꽤 준수한 수준의 모바일 앱 프로토타입을 만들 수 있었고, 이 경험을 통해 바이브 코딩이 단순한 '주말 장난감’을 넘어 실무에 적용될 수 있는 현실적인 개발 방식이라는 가능성을 확인할 수 있었습니다.

실제로 사내에서도 다양한 바이브 코딩 사례가 빠르게 등장하고 있습니다:

슈(sue.cream): 비개발자임에도 불구하고, 업무에 필요한 도구를 직접 구현해 사용하고 있습니다.
후크(hook.jeong): 사내 MCP 레지스트리(registry) 서비스를 단 6시간 만에 구현해 공유했습니다.
허셜(herschel.alway): 분류 모델 성능 평가 및 리포트 자동화 시스템을 구현했습니다.
빈즈(beans.go): 사내 플랫폼 기반 MCP 서버를 개발한 첫 사례로, 플랫폼 담당자가 아님에도 바이브 코딩으로 빠르게 구현했고, "다시는 이전 방식으로 돌아가기 어렵다"고 이야기했습니다.

이처럼 바이브 코딩은 단순한 주말 프로젝트를 넘어, 반복 작업의 자동화와 빠른 아이디어 실험이라는 측면에서 실제 업무에서도 생산성을 크게 높일 수 있는 접근으로 자리 잡아가고 있습니다.

Q. 이미 여러 사례가 있군요. 이어서 베네딕트가 진행한 바이브 코딩 프로젝트에 대해서도 이야기해주실 수 있나요?

낯선 개발 스택 위에서 AI 도구만을 활용해 실제 동작하는 모바일 앱을 만드는 프로젝트였습니다. 단순한 코딩을 넘어 기획, 디자인, 설계, 개발, QA까지 전체 개발 프로세스를 AI 중심으로 수행하는 시도를 해보고자 했습니다.

일주일간 총 7개의 스프린트를 운영했고, 매일 오전에는 리뷰, 회고, 플래닝을, 오후에는 바이브 코딩 방식으로 기능을 구현하는 방식으로 구성했습니다.

팀 구성은 다음과 같았습니다:

개발자: Cursor Agent + Claude-3.7-Sonnet MAX(thinking)
기획자: ChatGPT
디자이너: Cursor Agent
- UIzard, Galileo AI 등 다양한 툴을 시도했으나 Design MVK(Minimum Viable Knowledge) 부족으로 실패했고, 프로젝트 중반 이후 Cursor가 디자이너 역할까지 수행함.

저는 AI 에이전트 팀원들과 협업 방식 전반을 설계하고 조율하는 역할을 맡았습니다. PM, PO, 스크럼 마스터, 개발 리드, 디자인 리드의 역할을 모두 겸했습니다.

그 결과, 처음 접한 기술인 flutter, dart, firebase, firestore 등을 사용해 실제로 실행 가능한 낚시 앱 프로토타입을 완성할 수 있었습니다. 전체 코드의 약 99%는 Cursor가 작성했고, 기획서, 화면 설계서, 보고서 등은 ChatGPT와 협업해 작성했습니다.

이 실험을 통해, AI 에이전트 기반의 개발이 단기간 내 결과물을 만들어내는 데 매우 효과적일 수 있다는 점을 확인할 수 있었습니다. 현재는 이 실험을 확장해, 프로덕션 환경에서의 활용 가능성도 검토하고 있습니다.

바이브 코딩, 실무에서는?

Q.  바이브 코딩이 실제 프로덕션에서도 통하는지, 실험 결과를 들려주실 수 있을까요?

안드레 카파시가 언급한 ‘순수 바이브 코딩’—느낌에 맡기고, 코드를 거의 들여다보지 않으며 개발하는 방식—은, 현실의 프로덕션 개발 환경에서는 그대로 적용되기 어렵습니다. 그리고 그렇게 해서는 안됩니다.

실제 업무 환경에서 바이브 코딩 방식으로 신뢰할 수 있는 산출물을 내려면, 반드시 다음 두 가지 활동이 병행되어야 합니다:

에이전트가 작업을 수행하는 도중, 적절한 타이밍에 방향을 제시하는 개입
AI가 생성한 결과물을 꼼꼼하게 검토하고 품질을 확보하는 검증

그래서 저는 ‘바이브 코딩’보다는, ‘AI 에이전트와 협업하는 개발 방식’이라는 표현이 더 정확하다고 생각합니다.

에이전트는 분명히 많은 작업을 빠르게 해낼 수 있는 강력한 도구입니다. 하지만 그 잠재력을 제대로 이끌어내기 위해서는, 사람의 판단력과 비즈니스 맥락에 대한 이해가 필수적으로 개입되어야 합니다.

이러한 협업 구조가 잘 자리 잡는다면, 단순 반복 작업은 줄이고, 개발자는 더 창의적이고 본질적인 일에 집중할 수 있게 됩니다. 그 결과, 생산성과 품질이라는 두 마리 토끼를 동시에 잡을 수 있는 가능성이 열리게 됩니다.

저는 이러한 협업 방식이 성숙해진다면, 단순히 새로운 개발 도구를 쓰는 차원을 넘어, 소프트웨어 개발 자체의 패러다임이 바뀌는 전환점이 될 수 있다고 믿습니다.

과거 텍스트 에디터에서 IDE로의 전환과는 달리, 단순히 개발 도구가 바뀌는 차원을 넘어, 우리가 일하는 방식 자체가 바뀌는 전환점이거든요.

그리고 이렇게 말씀드릴 수 있는 이유는, 현재는 실험이 대부분 마무리된 상태이며, 실제 프로덕션 환경에서도 생산성과 품질 측면 모두에서 충분히 검증 되었기 때문입니다. 아래 실험 결과를 통해, AI 에이전트 기반 개발이 현실적인 선택지가 되어가고 있음을 확신하게 되었습니다.

🔍 실험 개요 및 결과

프로덕션 제품 개발 환경에서의 실험은 카카오의 오픈소스 검증 플랫폼 OLIVE 프로젝트를 대상으로 진행되었습니다.

실제 운영 중인 마이크로서비스 기반의 코드베이스와 사내 업무 흐름(JIRA, GitHub MCP 연동 등)을 활용해, 단순한 개념 검증이 아닌 실제 프로덕션 환경에서의 적용 가능성을 살펴보는 데 중점을 두었습니다.

총 3명의 실무 개발자가 기능 개발, 리팩토링, 테스트 작성, 문서 작업, 코드 리뷰, 마이그레이션 등 다양한 업무를 AI 에이전트와 협업하여 수행했습니다.

생산성

작업은 예상 소요 시간의 절반 이하로 완료되었고, 기존 방식 대비 약 2배의 생산성 향상을 확인할 수 있었습니다.

올리브 플랫폼을 개발/운영하는 오픈소스기술 조직은 이미 오랫동안 스토리포인트 기반의 업무 규모 추정을 통해 업무 리소스를 산정하고 있는 조직입니다. 그래서 이번 실험에서 보다 정량적인 생산성 변화를 측정할 수 있었습니다.

품질

AI와 협업하며 충분히 검토하고 개발된 기능은 별도의 리팩토링 없이 프로덕션 수준의 품질을 충족하며 동료 리뷰를 통과했습니다.

실제 사례 요약:

Case 1: (BE, 미들) Dependency Analyzer 기능 확장 (2~3일 예상 → 실제 1일)
Case 2: (FE + BE, 주니어) 파일을 통한 Manual Component 등록 기능 (3~5일 예상 → 실제 2.5일)
Case 3: (FE, 시니어) Angular to React 마이그레이션 프로젝트 초기 태스크 수행(5일 예상 → 실제 2.5일)
- 팀 신규합류 멤버로 도메인 지식 부족, 레거시 Angular 경험 없음.

관찰자(violet.blue, 오픈소스기술 리드) 피드백

“AI Agent 도입은 코드 리팩토링, 테스트 작성, 프론트 UI 구현 등 다양한 개발 영역에서 실질적인 생산성 향상을 입증했습니다. 팀원들이 이 실험에 즐겁게 참여하고 있어, 자발적인 활용과 노하우 공유가 더욱 활성화될 것으로 기대됩니다.”

변화를 맞이하는 우리의 자세

Q. 새로운 패러다임이 안착하면, 개발자의 역할은 정말 줄어들게 될까요?

AI가 사람의 언어나 코드를 넘어서, AI만이 이해할 수 있는 방식으로 코드를 작성하는 세상이 온다면…
그때가 바로 치킨집을 차릴 타이밍이라고 생각합니다. 하지만 아직은 그런 단계가 아니고, 앞으로도 한동안은 아니라고 생각합니다.(그렇게 믿고 싶습니다만, 기술의 발전이 너무 빠르긴 합니다.)

그렇기에 지금 우리가 해야 할 일은, 변화를 외면하고 위축되기보다는 그 흐름을 빠르게 받아들이고 역량으로 전환하는 것입니다.

실제로도 제본스의 역설(Jevons paradox)에서 언급되듯, 기술로 인한 생산성이 높아질수록 오히려 그 기술을 다룰 수 있는 사람에 대한 수요가 늘어날 수 있습니다. 저 역시 예전보다 훨씬 빠르고 많이 일하고 있지만, 여유로워졌다고는 말하기 어렵습니다. (웃음)

‘개발자의 역할이 줄어들 것이다.’, ‘주니어 개발자의 포지션이 애매해질 것이다.’, , ‘오히려 주니어가 더 유리하다’ 같은 담론은 지금의 빠른 변화 속도 앞에서는 큰 의미가 없다고 생각합니다.

기술의 변화는 너무 빠르고,
요즘처럼 한 달 앞도 예측하기 어려운 시대에 우리가 할 수 있는 가장 현명한 대응은,

변화의 흐름에 뒤쳐지지 않는 것,
그리고 그 안에서 자신만의 내공을 빠르게 쌓아나가는 것입니다.

결국 중요한 것은 '주니어냐 시니어냐’가 아니라,
얼마나 빠르게 새로운 흐름을 열린 자세로 받아들이고 자기 것으로 만들 수 있느냐입니다.

빠르게 체화한 사람은 기술을 발판 삼아 자신의 역량을 증폭시킬 수 있고,
그렇게 쌓은 역량으로 더 나은 사용자 경험을 더 자주, 더 빠르게, 더 지속적으로 제공할 수 있는 개발자와 팀은 앞으로도 분명히 살아남을 수 있습니다.

반대로, 그렇지 못하다면… 도태되는 속도도 그만큼 빨라질 수 있습니다.

Q. 앞으로의 변화를 대비해, 지금 우리가 가장 먼저 준비해야 할 것은 무엇일까요?

AI 에이전트는 지금 이 순간에도 빠르게 진화하고 있습니다.
MCP(Model Context Protocol)는 사실상 업계 표준으로 자리잡아가며 다양한 도구와 에이전트를 연결하는 기반이 되고 있고, 최근 구글이 발표한 A2A(Agent-to-Agent)는 그 상위 개념으로, 에이전트 간의 직접적인 상호작용과 협업을 제안하고 있습니다.

저는 일주일 간의 바이브 코딩 실험을 하면서, 기획자(ChatGPT)와 개발자&디자이너(Cursor)가 직접 대화하며 협업할 수 있으면 얼마나 좋을까 상상했는데요.

가벼운 실험으로 MCP를 통해 Cursor와 ChatGPT가 토론하는 장면을 구성해보기도 했습니다.

“조만간(아마도 한 달 뒤쯤) 관련된 기술이 공개되겠지”라고 생각했는데, 며칠 뒤 실제로 A2A가 발표되어 정신이 아찔할 정도로 변화의 속도를 체감했습니다.

이제는 단일 에이전트를 넘어, 여러 에이전트가 유기적으로 협업하는 에이전트 클러스터, 그리고 이를 지휘하는 수퍼 에이전트, 궁극적으로는 개발자가 전체 에이전트 집합을 조율하는 ‘에이전트 플릿(Agent Fleet)’ 환경이 다가오고 있습니다.

실제로 최근 구글 클라우드 넥스트 키노트에서는, 칸반 보드 위에서 에이전트가 전체 소프트웨어 개발 생명 주기(Software Development Life Cycle, SDLC)에 걸쳐 문제를 해결하는 장면(57’50")이 시연되기도 했습니다.

👉 시연 영상 보기

그렇다면 지금 우리가 가장 먼저 해야 할 일은 무엇일까요?
거창한 전략이나 장기 계획 이전에, 지금 당장 ‘코딩 에이전트와 협업하는 방법’을 직접 경험하고 체득해보는 것이라고 생각합니다.

에이전트와 첫 대화를 시작하는 그 순간부터, 앞으로의 변화가 실감나기 시작할 것이고, 그 경험은 이후의 기술 적응 속도를 완전히 바꿔놓을 수 있습니다.

Q. 마지막으로 AI 에이전트와 빠르게 친해지는 베네딕트만의 팁이 있다면 공유해주세요.

에이전트와 빠르게 친해지기 위한 첫걸음은, 에이전트를 어떤 존재로 대하느냐에 대한 인식 전환에서 시작된다고 생각합니다. 단순히 코드를 완성해주는 도구나 질문에 답하는 검색창처럼 대하는 것이 아니라, 함께 일하는 '협업 동료’로 받아들이는 태도가 중요합니다.

AI 에이전트는 매우 강력한 가능성을 지닌 존재입니다. 하지만 우리가 그 가능성을 ‘도구’라는 틀에 가두어버리면, 결국 그 이상으로는 활용하지 못하게 됩니다. 진짜 팀원처럼 협업하고 조율하며 함께 일하는 방식을 익히는 것이, 앞으로의 개발 환경에서 훨씬 더 중요해질 것이라 생각합니다.

마무리하며

이번 인터뷰에서는 ‘바이브 코딩’이라는 새로운 개발 패러다임을 중심으로, 실제 실험 경험과 사내 적용 사례를 바탕으로 다음과 같은 핵심 메시지를 나누었습니다:

개발자 의도를 코드로 구현하는 바이브 코딩과 같은 AI 기반 개발은 실제 생산성 향상에 기여할 수 있음
인간이 AI에게 방향을 제시하고 품질을 검토하는 협업 구조가 중요함
변화에 빠르게 적응하고 내재화하는 역량이 경력보다 더 큰 가치로 작용함
다중 에이전트 시대를 대비해 지금부터 코딩 에이전트와 직접 협업하고, 도구가 아닌 동료로 받아들이는 인식 전환 필요

AI와 협업하는 방식은 이제 더 이상 먼 미래가 아니라, 이미 우리 곁에 도착해 있는 변화입니다. 이 변화를 가장 먼저 경험하고, 활용해보는 개발자가 결국 그 흐름 위에 서게 될 것입니다.

마무리는 눈물 흘리며 봤던 폭싹 속았수다 14편 속 금명이의 말을 인용하며 대신하겠습니다:

“파도에 쓸리느냐, 파도에 올라타느냐, 그것은 주자의 몫이었다.”

감사합니다.

Vibe-Coding 관련 글 모아보기:

Vibe Coding, 새로운 개발 패러다임의 시작일까요?