바이브 코딩 다음 단계: 멀티 에이전트 조율과 만든 뒤의 일

자연어로 앱을 한 번에 만드는 단계 다음은, 여러 AI 에이전트를 나눠 돌리고 품질을 검증하는 쪽으로 이야기가 옮겨가고 있다. 다만 시장 점유율이 그쪽으로 ’급상승’했다는 수치는 확인하지 못했다.

바이브 코딩(Vibe Coding)은 자연어로 의도를 말하고 AI가 코드를 짜 주는 방식을 가리킨다. Andrej Karpathy가 2025년에 쓴 표현이고, 2026년 4월 20일 Sequoia Capital의 AI Ascent에서 Stephanie Zhan과 나눈 대화에서는 한 걸음 더 나갔다. 바이브 코딩이 누구나 소프트웨어를 만들 수 있는 하한을 올린다면, 에이전틱 엔지니어링(Agentic Engineering)은 품질·보안·유지보수 기준을 지키면서 에이전트를 조율하는 전문 영역이라는 구분이다.

업계에서는 ’새로 만드는 일(0→1)’과 ’만든 뒤의 일’을 구분하기도 한다. 앞쪽은 프로토타입을 빠르게 올리는 일이고, 뒤쪽은 대규모 리팩토링·마이그레이션·일관된 UI·코드 리뷰처럼 이미 있는 시스템을 안전하게 바꾸는 일인데, 이 대비는 Karpathy나 앤트로픽이 고정한 용어는 아니다.

바이브 코딩에서 에이전틱 엔지니어링으로

Karpathy의 요약에 따르면, 바이브 코딩으로 취약점을 들여보내면 안 된다. 소프트웨어에 대한 책임은 그대로다. 에이전트는 강력하지만 들쭉날쭉하고 실수할 수 있는 존재라서, 스펙·테스트·권한·diff 검토·격리된 작업 공간 같은 공학적 장치가 필요하다는 이야기다.

앤트로픽이 2026년 초 공개한 Agentic Coding Trends Report도 같은 방향을 예측한다. 단일 에이전트가 한 컨텍스트 창에서 순차로 일하던 흐름에서, 오케스트레이터가 일을 쪼개고 전용 컨텍스트를 가진 전문 에이전트가 병렬로 일한 뒤 결과를 합치는 멀티 에이전트 구조로 넘어간다는 것이다. 여기서 에이전트는 사용자 대신 여러 단계의 일을 스스로 처리하는 AI를 말한다.

같은 자료는 장기 실행 에이전트가 수일에서 수주에 걸쳐 시스템을 만들고, 사람이 손대기 어려웠던 기술 부채를 줄일 수 있다고도 적었다. Rakuten 사례로는 Claude Code가 약 1,250만 줄 규모의 vLLM(AI 모델을 서버에서 돌리는 엔진) 관련 작업을 약 7시간 자율 실행해 참고 구현 대비 수치 정확도 99.9%를 냈다고 한다. 다만 이는 앤트로픽이 고른 사례이지, 모든 리팩토링이 그렇게 끝난다는 뜻은 아니다.

도구가 실제로 약속하는 것

메모에서 예로 든 Verdent AI와 Lovable은 방향이 조금 다르다. 하나는 기존 코드베이스에서 에이전트를 병렬로 돌리는 쪽이고, 다른 하나는 생성형 앱 빌더에서 브랜드·컴포넌트 일관성을 묶는 쪽이다.

Verdent AI는 2025년 9월 23일 Business Wire 보도자료에서 Verdent와 Verdent Deck을 발표했다. Verdent는 계획을 세우고 검증하며 기능 단위 작업을 반복하는 에이전틱 코딩 스위트이고, Deck은 여러 Verdent 에이전트를 병렬로 관리하는 데스크톱 앱이다. Deck은 Mac에서 격리된 에이전트 세션과 Git worktree를 지원한다고 밝혔다. 공식 문서도 에이전트마다 격리된 워크스페이스에서 돌리고, 결과를 비교한 뒤 main으로 rebase하는 흐름을 설명한다. 리팩토링 가이드에는 인증·API·유틸처럼 모듈을 나눠 서로 다른 워크스페이스에 맡기는 병렬 패턴이 나온다. 백엔드 API 마이그레이션과 프론트엔드 리팩토링을 ‘동시에’ 돌린다는 문구는 공식 슬로건으로 확인하지 못했고, 문서상으로는 겹치지 않는 모듈을 병렬로 나누는 패턴에 가깝다.

Lovable은 2026년 8월 19일, 디자인 시스템을 모든 유료 플랜에서 쓸 수 있게 했다고 커뮤니티에 올렸다. 브랜드 가이드·스크린샷·Figma를 올려 시스템을 만들거나, 기존 시스템을 프로젝트에 연결하면 타이포·색·간격·컴포넌트를 물려받는다. 문서 기준으로는 React 컴포넌트 라이브러리가 중심이고, 연결·업데이트 뒤 빌드 설정과 CSS·테마 프로바이더를 점검하며, 작업 중 임의 색이나 커스텀 컴포넌트처럼 시스템을 벗어난 사용을 잡는다. 프로젝트당 디자인 시스템 연결은 최대 하나다. 기존 npm 패키지를 감싸는 방식은 Enterprise만 해당한다.

숫자가 말해 주는 것과 말해 주지 않는 것

앤트로픽 요약 글은 Societal Impacts 팀 연구를 인용해, 개발자가 AI를 업무의 약 60%에서 쓰면서도 완전히 위임할 수 있다고 느끼는 비율은 0~20%에 그친다고 적었다. 코딩을 맡기는 빈도와, 결과를 검증 없이 맡기는 정도는 다르다는 뜻이다.

시장 전체에서 Verdent·Lovable·멀티 에이전트 도구의 사용률이 얼마나 올랐는지는 이 글에서 확인하지 못했다. 도구 순위 자체는 JetBrains 설문 등 다른 조사가 따로 있다. 여기서는 Karpathy의 구분, 앤트로픽의 예측, 제품 문서에 적힌 기능을 기준으로만 본다.

오해하기 쉬운 부분

바이브 코딩이 ’끝났다’고 읽으면 안 된다. Karpathy 표현대로면 하한을 올린 뒤, 천장 쪽을 에이전틱 엔지니어링으로 밀어 올리는 그림이다. 프로토타입과 개인 도구에서는 바이브 코딩이 여전히 유효하다.

멀티 에이전트가 무조건 더 낫다는 주장도 앤트로픽 글과 어긋날 수 있다. 앤트로픽은 컨텍스트가 오염되거나 병렬이 가능하거나 역할 분담이 이득일 때 멀티 에이전트가 이기고, 그렇지 않으면 조율 비용이 더 크다고 따로 정리한 글도 있다. 이 글의 범위에서는 그 세부 패턴까지 깊게 들어가지 않는다.

Verdent를 ’마이그레이션 전용 제품’으로, Lovable을 ’모든 스택 디자인 시스템 자동화’로 보면 과장이다. 확인된 범위는 각각 격리된 병렬 에이전트·리팩토링 워크플로, React 중심 디자인 시스템 연결이다.

앞으로 볼 것

Verdent 문서·요금·Windows 지원이 발표 시점 이후 어떻게 바뀌었는지
Lovable 디자인 시스템이 연결된 프로젝트에 버전 업데이트를 실제로 얼마나 자주 반영하는지
앤트로픽·다른 설문에서 멀티 에이전트 워크플로 채택률이 따로 집계되는지
팀 안에서 에이전트 병렬 실행 시 테스트·리뷰·머지 규칙이 어떻게 잡히는지