바이브 코딩 플랫폼 Lovable이 기업가치 133억 달러(약 18조 8700억 원)를 인정받으며 시리즈C 4억 달러 투자를 유치했다. ZDNet 보도에 따르면 엔비디아·아디다스·젠데스크가 이미 이 플랫폼을 실무에 쓰고 있고, 6000만 개 이상의 프로젝트가 생성됐으며 월간 이용 규모는 9억 건을 넘어섰다. 자연어 한 줄로 웹 앱이 뚝딱 나온다는 약속이 단순한 데모가 아니라 실제 매출과 시장 신뢰로 구체화되고 있다는 신호다.
그런데 거의 같은 시점에, 정반대의 선언이 조용히 주목을 받았다. 20년 경력의 시니어 개발자가 Geek News(GeekNews 요약 기준)에 올린 글에서 "1년 넘게 AI 코딩 도구를 진지하게 써봤는데, 이제 그만두기로 했다"고 밝혔다. Claude Code와 Linear를 연결해 코드 한 줄 직접 건드리지 않고 프로젝트를 완성할 수준까지 자동화를 끌어올렸던 사람이 해고 가능성을 감수하면서까지 원래 방식으로 돌아가겠다고 한 것이다.
두 이야기가 동시에 존재한다는 사실 자체가 지금 AI 코딩 도구의 현실을 압축한다. 도구는 폭발적으로 성장하고 있고, 그 도구를 쓰는 경험은 사람마다 극단적으로 갈린다. 문제는 이 간극이 도구의 품질 차이가 아니라, 어떻게 쓰느냐의 차이에서 비롯된다는 점이다.
무분별한 사용이 만들어낸 청구서
해당 개발자가 겪은 과정은 많은 팀에서 목격되는 패턴과 닮아 있다. 처음엔 Cursor의 탭 자동완성이 신기하게 느껴졌고, 경영진의 요구가 더해지면서 에이전트 방식으로 확장됐다. Claude Code가 Linear 티켓을 받아 스스로 코드를 짜고, 개발자는 그걸 리뷰하는 역할로 서서히 밀려났다. 속도는 빨라졌다. 하지만 동시에 세 가지가 무너졌다.
첫째는 코드 이해도다. AI가 만든 기능이 정확히 어떻게 동작하는지 AI에게 다시 물어보지 않고서는 설명하기 어려워졌다고 그는 고백한다. 직접 짜지 않은 코드에 대한 소유감도, 책임감도 희박해졌다. 둘째는 학습과 성장이다. 어려운 문제를 AI에 넘기기 시작하면서 그 어려움을 통해 얻던 것—디버깅 감각, 설계 직관, 문제 해결 근육—이 함께 사라졌다. 셋째는 소프트웨어 품질이다. 생성되는 코드가 너무 많아 사람이 전부 검토하기 어려웠고, AI가 생성한 코드를 다른 AI가 검토하는 상황까지 벌어졌다.
그가 던진 핵심 문장은 이것이다. "좋은 소프트웨어는 기능 수나 개발 속도보다, 디자이너·개발자·제품 담당자가 얼마나 세심하게 돌보는지에 달렸다." AI 사용량이 늘어날수록 그 '돌봄'의 감각이 희미해졌고, 결국 자신이 만든 제품에 대한 관심 자체가 줄어들었다. 빠르게 티켓을 소화하는 쳇바퀴가 됐다는 표현은, 단순한 감정 토로가 아니라 AI 전면 의존이 가져오는 구조적 문제를 가리킨다.
해결책은 중단이 아니라 분리다
물론 AI 코딩 도구를 완전히 끊는 것이 모두의 정답은 아니다. 실제로 이 주제를 정면으로 다룬 dev.to의 워크플로우 아티클은 꽤 실용적인 대안을 제시한다. 핵심 아이디어는 단순하다. AI 작업을 두 레인으로 나눠라.
레인 1(Volume)은 틀려도 30초짜리 수정으로 끝나는 작업들이다. 보일러플레이트 테스트 스캐폴딩, 이미 동작하는 코드의 docstring 작성, 에러 메시지 다듬기, 스택 트레이스 설명 요청 같은 것들. 이 작업들은 빠르고 저렴한 모델로 대량 처리해도 된다. 레인 2(Judgment)는 틀렸을 때 배포 사고나 데이터 손실로 이어지는 작업들이다. 스키마 설계, 인증·결제·삭제 로직, 동시성 처리, 마이그레이션 계획. 여기엔 가장 강력한 모델을, 그리고 반드시 사람의 최종 판단을 붙여야 한다.
이 구분이 중요한 이유는 경제학적이다. 레인 1이 전체 프롬프트의 80~90%를 차지하지만 리스크는 거의 없다. 레인 2는 빈도는 낮지만 잘못될 경우의 파장이 크다. 문제는 많은 팀이 이 두 레인을 구분 없이 같은 신뢰 수준으로 처리한다는 것이다. 최고급 모델에게 변수 이름을 바꿔달라고 하거나, 반대로 빠른 모델에게 마이그레이션 설계를 맡기거나—둘 다 잘못된 라우팅이다.
이 워크플로우의 또 다른 핵심은 검증 게이트다. 레인 1 결과물이 실제 파일에 닿기 전에 통과해야 하는 60~90초짜리 체크리스트다. 컴파일·린트 통과 여부, 낯선 import나 API 없는지, 내가 모르는 파일 경로를 건드리진 않는지, 테스트가 실제로 실패 케이스를 잡는지. 그리고 마지막 항목이 핵심이다. "이 diff가 사람 코드였어도 리뷰할 수 있는 크기인가?" 이 질문에 '아니오'라면, 그 작업은 처음부터 레인 1이 아니었다.
프론트엔드 개발자에게 이것이 의미하는 것
Lovable 같은 바이브 코딩 플랫폼의 성장은 분명한 신호다. AI 코딩 도구는 사라지지 않는다. Cursor 개발사 Anysphere를 스페이스X가 600억 달러에 인수하는 시대에, "AI를 안 쓰겠다"는 선언은 훌륭한 저항일 수 있지만 현실적인 전략이 되긴 어렵다. 하지만 도구의 성장이 곧 무분별한 사용을 정당화하지는 않는다.
프론트엔드 개발자로서 이 구분은 특히 의미가 크다. UI 컴포넌트 스캐폴딩, 타입 어노테이션, Tailwind 클래스 자동완성, 간단한 훅 설명—이것들은 레인 1이다. 반면 접근성(a11y) 구조 설계, 상태 관리 전략, 인증 플로우, Core Web Vitals에 영향을 미치는 렌더링 결정—이것들은 레인 2다. AI가 생성한 컴포넌트가 스크린 리더에서 어떻게 동작하는지, View Transition이 사용자 경험에 실제로 기여하는지는 도구가 아니라 개발자가 판단해야 한다.
20년 차 개발자가 AI 사용 중단을 선언하면서 다시 찾은 것은 취미로 만들던 작은 게임, 직접 타이핑하는 Rust 코드, AI 없이 문제를 풀어가는 과정에서 오는 만족감이었다. 그것은 향수가 아니다. 소프트웨어에 대한 관심과 오너십—좋은 제품을 만드는 데 실제로 필요한 것—을 회복하는 과정이었다. AI 도구를 잘 쓰는 것의 전제는, 그 관심을 AI에게 위임하지 않는 것이다.
결국 질문은 하나로 귀결된다. AI가 내 워크플로우에서 어떤 결정을 대신하고 있는가. 그 결정이 레인 1에 해당하는 것이라면 위임해도 된다. 레인 2에 해당하는 것이라면, 그 결정을 AI에게 넘기는 순간 당신은 개발자가 아니라 프롬프트 운반자가 된다. Lovable이 18조 밸류에이션을 받는 세상에서도, 좋은 소프트웨어를 만드는 판단은 여전히 사람이 해야 한다.