'바이브'가 현실이 된 2025년
바이브 코딩(Vibe Coding)이 유행어에서 실제 워크플로우로 자리잡고 있습니다. dev.to에 올라온 한 Swift 개발자의 사례가 이를 잘 보여줍니다. iOS 프로필 화면 하나를 만드는 데 과거엔 75분이 걸렸던 작업이, Cursor + Claude Code 조합으로 20분으로 줄었습니다. 보일러플레이트 작성, 포맷 컨버팅, 반복 패턴 구현—이 모든 루틴을 AI가 처리하는 동안 개발자는 아키텍처 결정과 리뷰에만 집중합니다.
요즘IT가 인터뷰한 도연희 님의 사례는 더 극적입니다. 코딩 비전공 대학생이 Lovable + Claude Code + Gemini만으로 웹소설 팬픽 인트라넷을 만들었고, 링크드인 조회수 300만에 방문자 49만 명을 기록했습니다. 워크플로우는 단순했습니다. Gemini로 기획 문서를 만들고 → Lovable로 MVP를 뽑고 → Claude Code로 세부 구현을 다듬는 방식입니다. "AI가 해줄 수 있을 거라고 믿었다"는 그의 말처럼, 바이브 코딩의 본질은 기술 장벽을 허물고 실행력을 극대화하는 데 있습니다.
Cursor vs Claude Code: 무엇을 언제 쓸까
이 두 도구는 역할이 다릅니다. Cursor는 VS Code 포크 기반의 맥락 인식 IDE입니다. 열린 파일, 프로젝트 구조, 터미널 에러까지 AI가 통합적으로 보기 때문에 Cmd+K 한 번으로 프로젝트에 자연스럽게 맞는 코드를 생성합니다. Composer 기능은 여러 파일에 걸친 변경사항을 diff로 보여주고, Accept/Reject로 즉시 반영하거나 되돌릴 수 있어 실험적 개발에 최적입니다.
Claude Code는 터미널 기반 CLI 도구로, 파일 구조를 읽고 편집하며 명령어를 직접 실행할 수 있는 자율형 에이전트에 가깝습니다. 단일 파일을 넘어서는 모듈 리팩토링, 기존 코드 기반의 테스트 자동 생성, 외부 라이브러리 분석, 문서화 작업 등에서 강점을 보입니다. 우아한테크코스 사례에서도 확인됩니다. .claude 폴더에 프로젝트 컨텍스트(구조, 기술 스택, 개발 워크플로우)를 담아두면 Claude가 이를 가이드라인으로 삼아 더 적절한 코드를 생성합니다. AI 활용은 결국 문서화와의 싸움이기도 합니다.
바이브 코딩이 작동하지 않는 순간
실전 경험자들이 공통으로 꼽는 한계가 있습니다. 첫째, 요구사항이 불명확할 때입니다. AI는 당신이 설명한 대로 코드를 만듭니다. 도연희 님이 데이터 스키마 설계 없이 개발을 진행하다 3~4일을 날린 사례가 대표적입니다. "처음에 이걸 잘 만들어놔야 나중에 관리가 된다"는 깨달음은 AI 시대에도 유효합니다. 둘째, 커스텀 알고리즘과 복잡한 비즈니스 로직입니다. 표준 패턴을 벗어난 요구사항은 AI가 '그럴듯하지만 틀린' 코드를 내놓을 가능성이 높습니다. 셋째, 레거시 코드베이스입니다. 10년 된 스파게티 코드는 AI도 맥락을 잃습니다.
속도의 이면: 보안 책임은 누가 지나
여기서 불편한 진실을 직면해야 합니다. dev.to의 보안 분석 글은 이렇게 지적합니다. "AI가 백엔드를 작성했다는 말은 결국, 보안 모델이 '바이브'인 시스템을 배포했다는 뜻입니다."
AI 생성 코드는 threat model 없이 만들어집니다. 인증 로직, DB 쿼리, API 연동, 에러 핸들링—이 모든 것이 AI 출력물로 채워질 때, privilege separation이나 input sanitization 같은 보안 기본기는 검증되지 않은 채 배포됩니다. 실제로 한 사례에서는 클라이언트가 AI 에이전트가 생성한 7,000줄 코드를 리뷰 없이 프로덕션에 그대로 올렸고, 기존 설정을 덮어쓰는 사고가 발생했습니다. 법적으로도 명확합니다. Claude가 썼든 GPT가 썼든, PII나 금융 데이터가 유출되면 코드를 배포한 사람이 책임을 집니다.
특히 프롬프트 인젝션은 단순한 버그가 아닙니다. 모델이 명령과 컨텍스트를 구분하지 못하는 구조적 특성이기 때문에, AI 생성 앱은 태생적으로 이 취약점을 내포합니다. 인증, 암호화, 결제 처리에 관련된 코드는 반드시 사람이 직접 검토해야 합니다.
AI-First 워크플로우를 제대로 구축하는 법
바이브 코딩을 실전에 적용하려면 속도만큼 책임 구조도 설계해야 합니다. 제가 팀에서 실험해온 레이어를 정리하면 이렇습니다.
기획 단계: Gemini나 Claude로 요구사항 문서와 데이터 스키마를 먼저 만드세요. 도연희 님처럼 Gemini와 티키타카로 기획안을 구체화한 뒤 개발에 들어가면 나중에 삽질하는 시간을 줄일 수 있습니다.
개발 단계: Cursor Composer로 UI·비즈니스 로직을 빠르게 생성하고, Claude Code로 모듈 단위 리팩토링과 테스트 생성을 맡기세요. .claude 폴더에 프로젝트 컨텍스트를 잘 정리해두면 AI의 코드 품질이 눈에 띄게 올라갑니다.
리뷰 단계: AI가 생성한 코드를 그대로 머지하지 마세요. 특히 보안 관련 코드(인증, 권한, 암호화, 외부 API 연동)는 반드시 사람이 직접 리뷰하고 threat modeling을 돌려야 합니다. "AI로 리뷰 받아보니까 이런 게 나오더라고요"로 끝나면 안 됩니다.
시사점: '이해하면서 빠른' 개발자가 살아남는다
바이브 코딩에 대한 가장 흔한 반론—"AI가 쓰면 배울 수 없다"—은 절반만 맞습니다. Swift 개발자의 말이 핵심을 찌릅니다. "for-loop 문법을 아는 것이 개발자를 만드는 게 아니다. 아키텍처를 이해하고, 문제를 분해하고, 디버깅하는 능력이 중요하다." AI가 보일러플레이트를 맡는 동안 더 많은 패턴을 보고, 더 빠르게 다양한 접근을 실험할 수 있다면 오히려 학습이 가속됩니다.
반면 아무것도 이해하지 않고 AI 출력을 그대로 배포하는 것은 다른 문제입니다. 규모가 커질수록, 민감한 데이터를 다룰수록, "AI가 썼다"는 말은 면죄부가 아니라 면책 불가 사유가 됩니다. 속도와 책임은 트레이드오프가 아닙니다. 제대로 된 AI-First 워크플로우는 둘 다 가져가는 구조여야 합니다.
전망: 바이브 코딩의 다음 단계
도구는 이미 충분히 성숙했습니다. Lovable로 MVP를, Cursor로 일상적 개발을, Claude Code로 복잡한 리팩토링을 처리하는 멀티 에이전트 스택은 이제 개인 프로젝트부터 스타트업 MVP까지 현실적으로 작동합니다. 다음 관문은 거버넌스입니다. AI 생성 코드의 추적성, 보안 검증 자동화, 책임 소재 명문화—이것들이 팀과 조직 수준에서 정착되어야 바이브 코딩이 단순한 유행을 넘어 지속 가능한 개발 문화로 자리잡을 수 있습니다. 일단 만들어보는 실행력과, 만든 것에 책임지는 엔지니어링 마인드. 이 둘이 함께여야 합니다.