Cursor + Claude Code로 바이브코딩을 제대로 하는 법

요즘 "바이브코딩"이라는 말이 쉽게 쓰이는 것 같습니다. 저희는 이 단어가 유행하기 훨씬 전부터 그냥 그렇게 일해왔습니다. Snapdeck을 만들면서도 마찬가지였고요. 처음부터 바이브코딩을 본격적으로 활용했습니다.

처음엔 멋있어서가 아니라 생존이었습니다. 팀이 작고, 해야 할 건 많고, 매주 무언가를 내야 하는데 완벽한 개발 프로세스를 세팅할 시간은 없었습니다. 결국 답이 하나로 수렴하더군요.

"말로 설계하고, 바로 코드로 확인하고, 다시 말로 고치자."

2025년 11월 기준으로, 그 루프를 가장 빠르게 만들어주는 조합이 저희에게는 Cursor + Claude Code였습니다. 팀마다 취향은 다르겠지만, 우리에게는 이 조합이 가장 잘 맞았습니다.

오늘은 "AI 코딩 좋다" 같은 이야기 대신, 개발자 관점에서 어떻게 도입했고, 실제로 생산성을 어떻게 끌어올렸는지 — 그리고 그 과정에서 몇 번이나 넘어졌는지까지 정리해보겠습니다.

빨리 만드는 것보다 "빨리 틀리는" 게 더 중요하다

처음엔 다들 이 모드로 시작합니다. "코드를 뚝딱 써준다." 하지만 며칠만 지나면 바로 깨닫게 됩니다.

AI가 코드를 빨리 쓰는 건 맞지만, 우리가 뭘 만들고 있는지가 흐려지면 속도가 오히려 독이 됩니다.

그래서 우리는 목표를 바꿨습니다.

빨리 만드는 것보다 빨리 틀리기
많이 만드는 것보다 핵심 루프를 빨리 닫기
기능을 늘리는 것보다 품질 기준을 자동화하기

바이브코딩의 본질은 "대충 만들기"가 아닙니다. 학습 루프를 짧게 만드는 것입니다. 그리고 학습 루프가 짧아지면, 완성도는 오히려 올라갑니다.

Cursor는 "개발 환경"이 아니라 "팀의 두 번째 언어"

Cursor를 IDE로만 쓰면 절반만 활용하는 셈입니다. 우리는 Cursor를 사실상 팀 커뮤니케이션 레이어로 썼습니다.

이런 장면이 자주 발생했습니다.

기획/디자인에서 "이 흐름이 어색한데?"
개발에서 "그럼 이 컴포넌트 구조부터 바꿔볼까?"
Cursor에서 바로 리팩터링 초안을 만들고
스펙 문서보다 먼저 코드로 합의가 이루어짐

이게 생각보다 강력합니다. 문서로 합의하면 느리고, 회의로 합의하면 흔들리지만, 코드로 합의하면 빠르고 정확합니다.

Cursor의 강점은 큰 맥락 위에서 대화를 이어갈 수 있다는 점입니다. 대부분의 코딩 AI는 코드 조각 단위로는 잘 하지만, 우리가 진짜 원하는 건 "이 제품이 왜 이렇게 생겼는지"까지 포함한 대화입니다. Cursor가 그 연결을 잘 해줬습니다.

Claude Code는 "생각" 담당, Cursor는 "손" 담당

팀 내에서 체감상 가장 잘 작동한 방식은 역할 분리였습니다.

Claude Code: 설계, 논리, 구조, 테스트 전략, 엣지케이스, 네이밍
Cursor: 실제 구현, 리팩터링, 파일 간 수정, 빠른 반복

이렇게 나누면 "AI가 코드를 뱉어내는 속도"에 끌려가지 않습니다.

Claude Code에게는 정답 코드를 기대하기보다 좋은 질문과 좋은 틀을 뽑아내는 데 집중시키고, Cursor는 그 틀을 가지고 실제로 돌아가게 만드는 역할을 맡겼습니다.

이 조합이 잘 맞물리면 팀의 생산성이 단순히 2배가 아니라, 아예 다른 게임이 됩니다.

프롬프트를 잘 쓰는 팀보다 가드레일을 잘 세우는 팀이 이긴다

바이브코딩을 잘 하는 팀이라면 프롬프트 장인일 것 같지만, 진짜 차이는 프롬프트가 아니라 가드레일이었습니다.

초반에 한 번 크게 데였습니다.

기능은 빠르게 붙는데
버그가 자꾸 숨어 들어오고
리뷰가 느슨해지고
"나중에 정리하자"가 쌓이고
어느 순간부터 속도가 급격히 떨어짐

그래서 바이브코딩을 프리패스로 두지 않고 자동으로 제동이 걸리는 구조를 만들었습니다.

PR 템플릿에 변경 이유, 리스크, 롤백 플랜을 강제로 작성
CI에서 lint/test/typecheck는 무조건 실행
AI가 생성한 코드일수록 테스트를 더 두텁게
큰 리팩터링은 쪼개서 넣고, 한 PR은 한 목적만

속도는 품질 시스템이 있을 때만 장점이 됩니다.

코드 작성 전에 체크리스트를 먼저 뽑게 하라

체감이 가장 큰 변화였습니다.

Claude Code에 코드를 바로 요청하지 않고, 항상 먼저 이런 것부터 뽑았습니다.

"이 기능을 추가할 때 실패할 수 있는 지점을 나열해줘" "엣지케이스와 보안/성능 리스크 체크리스트를 만들어줘" "테스트 케이스를 먼저 작성해줘"

그 다음에 Cursor로 구현에 들어가면, AI가 만든 코드가 "그럴듯한 코드"가 아니라 실제 운영 가능한 코드로 바뀌기 시작합니다.

코드는 결국 운영물이고, 운영에서 터지는 건 항상 "예외 케이스"와 "가정의 구멍"입니다.

"한 번에 완성" 대신 얇은 수직 슬라이스로 계속 내라

바이브코딩이 가장 강한 구간은 명확합니다.

기능 전체를 한 번에 만들기가 아니라
전체 흐름이 작동하는 얇은 슬라이스를 빨리 만들기

예를 들면:

로그인 전체를 다 만들기보다, "로그인 → 첫 화면 → 첫 성공"까지를 먼저 관통시키기
에디터 전체를 만들기보다, "입력 → 결과 → 저장"까지 한 줄로 먼저 이어보기

Snapdeck을 만들 때도 '편집'이 가장 어려운 영역이었고, 그래서 더더욱 이 방식이 필요했습니다.

바이브코딩은 기능을 빠르게 추가하게 해주지만, 제품은 기능이 아니라 흐름입니다. 슬라이스 단위로 내는 팀이 결국 더 빠릅니다.

가장 큰 실수: "AI가 해주겠지" 모드

부끄러운 이야기지만, 초기에 "AI가 해주니까"라는 마음이 생긴 적이 있었습니다.

그 순간부터 부작용이 나타납니다.

네이밍이 대충되고
에러 처리가 느슨해지고
아키텍처가 비대해지고
리뷰에서 "돌아가니까"가 통과되고
나중에 그 비용을 전부 갚게 됩니다

바이브코딩은 개발자를 대체하지 않습니다. 오히려 개발자의 기준을 더 날카롭게 요구합니다.

AI가 빨리 만들수록, 사람은 더 까다로워져야 합니다. 이것이 우리가 얻은 가장 큰 교훈입니다.

바이브코딩은 속도가 아니라 학습 루프를 만드는 기술이다

2025년 11월 기준으로 느끼는 것은 이겁니다.

Cursor와 Claude Code를 잘 쓰면, 더 많은 기능을 만들 수 있는 게 아니라 더 자주 틀려보고 더 빨리 고칠 수 있는 팀이 됩니다. 그리고 제품팀에서 그게 진짜 힘입니다.

빨리 만들고
빨리 보여주고
빨리 실패하고
빨리 다시 만들고
그 과정에서 팀의 기준은 더 올라갑니다

우리는 처음부터 바이브코딩을 본격적으로 활용했고, 앞으로도 계속 그럴 것입니다. 다만 이제는 "AI로 빠르게 만들자"가 아니라 "AI로 학습 루프를 더 짧게 만들자"로 전환되었습니다.

그것이 제대로 작동하는 순간, 제품의 완성도까지 같이 따라옵니다.