같은 Cursor를 써도 어떤 사람은 10분 만에 기능을 뽑고, 어떤 사람은 2시간째 “다시 해줘”를 반복해요.
차이는 도구가 아니라 프롬프트에 있었어요. 저도 처음에는 “로그인 기능 만들어줘”처럼 던지고 나오는 코드를 보면서 ‘이게 맞나?’ 싶었거든요. 고치다가 다른 데가 망가지고, 또 고치고, 또 망가지고. 그런 삽질을 6개월쯤 반복한 끝에, 프롬프트를 어떻게 쓰느냐가 결과의 80%를 결정한다는 걸 체감했어요.
결론부터 말하면, 대단한 기술이 아니에요. 습관이에요. 이 5가지만 잡으면 같은 시간에 뽑아내는 결과물이 확 달라집니다.
습관 1: 한 번에 하나만 시킨다
가장 흔한 실수예요. “로그인 기능 만들고, DB 연동하고, 에러 핸들링도 넣어줘”를 한 프롬프트에 때려 넣는 거. 기분은 이해해요. 빨리 끝내고 싶잖아요. 근데 이렇게 하면 AI가 길을 잃어요.
한번은 채팅 기능을 붙이면서 실시간 알림이랑 읽음 표시까지 한 프롬프트에 요청한 적이 있어요. 결과? 스피너가 엉뚱한 곳에서 돌고, 고치면 다른 곳이 망가지더라고요. 결국 처음부터 다시 했어요.
그 뒤로는 인형뽑기 한다고 생각해요. 한 번에 하나. 집게를 정확한 위치에 놓고 엔터를 누르는 거예요.
❌ "로그인 페이지 만들고 JWT 인증 달고 리프레시 토큰도 구현해줘"
✅ "이메일/비밀번호 입력 폼이 있는 로그인 페이지를 만들어줘.
제출하면 POST /api/auth/login을 호출하고,
성공 시 /dashboard로 리다이렉트해줘."두 번째 프롬프트에는 JWT가 없어요. 그건 로그인 페이지가 동작하는 걸 확인한 다음에 시키면 돼요. 작은 단위로 나눠서 각 단계마다 결과를 확인하면, 뭔가 틀어졌을 때 어디서 틀어졌는지 바로 보이거든요.
연구 데이터도 이걸 뒷받침해요. 바이브코딩으로 프로토타이핑 속도가 60~80% 빨라진다는 결과가 있는데, 그건 작업을 잘게 쪼갠 경우의 이야기예요. 큰 작업을 한 덩어리로 던지면 오히려 더 느려져요.
습관 2: 프로젝트 룰 파일을 세팅한다
매번 “TypeScript로 짜줘”, “snake_case 쓰지 마” 같은 걸 프롬프트에 반복하고 있다면, 시간 낭비예요. 프로젝트 룰 파일 하나면 이 문제가 사라져요.
Cursor를 쓰면 .cursorrules, Claude Code를 쓰면 CLAUDE.md를 프로젝트 루트에 놓으면 돼요. AI가 세션을 시작할 때 이 파일을 자동으로 읽거든요. 코딩 스타일, 프로젝트 구조, 금지 사항 같은 걸 한 번만 적어두면 매번 반복할 필요가 없어요.
저는 이런 식으로 써요:
## 코드 컨벤션
- Python: snake_case, 타입 힌트 필수, async/await 우선
- TypeScript: camelCase, Svelte 5 runes 사용
- 새 파일 만들지 말고 기존 파일 수정 우선
## 아키텍처
- 모든 API 호출은 서버사이드에서 처리
- 브라우저에서 직접 백엔드 API 호출 금지이걸 세팅하고 나니까 “아 또 CommonJS로 짰네” 같은 일이 확 줄었어요. AI가 프로젝트 맥락을 이해한 상태에서 시작하니까, 프롬프트도 짧아지고 결과물도 일관성이 생기더라고요.
여러 AI 도구를 동시에 쓴다면 AGENTS.md라는 크로스 툴 표준도 나왔어요. 하나만 관리하면 Claude Code, Cursor, GitHub Copilot 전부에서 읽혀요. 근데 솔직히, 도구 하나만 쓴다면 그 도구 전용 파일만 있어도 충분해요.
습관 3: “뭘 해줘” 대신 “왜” 를 말한다
이게 체감 차이가 제일 커요.
❌ "이 함수를 async로 바꿔줘"
✅ "이 API 호출이 UI를 블로킹하고 있어. 사용자가 버튼 클릭 후
로딩 중에도 다른 탭을 전환할 수 있어야 해."첫 번째 프롬프트는 해결책을 지정해요. AI는 시키는 대로 async를 붙이겠죠. 근데 진짜 원인이 async가 아니라 상태 관리 문제였다면? 시간만 날린 거예요.
두 번째 프롬프트는 문제를 설명해요. AI가 “아, UI 블로킹이 문제구나”를 이해하면, async로 바꾸는 것보다 더 나은 방법을 제안할 수도 있어요. 실제로 제 경우에 Suspense 패턴을 추천해줘서 코드가 훨씬 깔끔해진 적이 있거든요.
의도 기반 프롬프팅(Intent-Based Prompting)이라고 불리는 접근인데, 이름이 거창할 뿐 핵심은 단순해요. 해결책이 아니라 문제를 던져라. AI한테 생각할 여지를 주면, 내가 생각 못 한 방향으로 더 좋은 답이 나올 때가 있어요.
물론 항상 그런 건 아니에요. “이 변수명을 userId로 바꿔줘”처럼 명확한 지시가 맞는 상황도 있어요. 요점은, 복잡한 문제일수록 “왜”를 먼저 말하면 AI가 더 넓은 범위에서 해결책을 찾는다는 거예요.
습관 4: AI가 짠 코드를 AI에게 리뷰시킨다
바이브코딩의 가장 위험한 함정이 “돌아간다 = 완성이다”라는 착각이에요. AI가 생성한 코드는 로직 에러가 75% 더 빈번하다는 데이터가 있어요. 눈으로 보면 깔끔한데, edge case에서 터지는 거죠.
그래서 저는 코드를 생성한 뒤에 바로 이런 프롬프트를 던져요:
"방금 만든 코드에서 보안 취약점이나 edge case 빠진 부분 찾아줘.
특히 인증 안 된 사용자가 접근하는 경우를 체크해줘."한 발 더 나가면, 테스트를 먼저 만들어달라고 하는 것도 좋아요:
"이 API 엔드포인트에 대한 테스트 케이스를 먼저 작성해줘.
정상 케이스, 인증 실패, 잘못된 입력값 세 가지로."테스트가 먼저 있으면 구현 코드를 생성할 때 AI가 그 테스트를 통과하는 방향으로 짜거든요. Test-First 접근이 바이브코딩에서도 먹혀요.
Claude Code를 쓴다면 숨겨진 리뷰 기능도 있으니 참고하세요.
습관 5: Before/After 예시를 보여준다
“깔끔하게 짜줘”라고 하면 AI마다, 세션마다 “깔끔함”의 기준이 달라요. 내가 원하는 코드 스타일이 있다면, 말로 설명하는 것보다 예시를 보여주는 게 10배 빠르고 정확해요.
❌ "에러 핸들링 잘 해줘"
✅ "에러 핸들링을 이런 패턴으로 통일해줘:
try:
result = await service.create_user(data)
return {"ok": True, "data": result}
except ValidationError as e:
raise HTTPException(status_code=422, detail=str(e))
except Exception as e:
logger.error(f"User creation failed: {e}")
raise HTTPException(status_code=500, detail="Internal server error")
모든 API 엔드포인트에 이 패턴을 적용해줘."이게 Few-Shot 프롬프팅이에요. 원하는 결과의 예시를 1~2개만 보여주면 AI의 정확도가 확 올라가요. PRD(Product Requirements Document) 스타일로 “When X happens, do Y”를 써주는 것도 같은 원리예요.
특히 기존 코드와 스타일을 맞춰야 할 때 이 습관이 빛나요. “기존 코드 스타일을 따라줘”라고만 하면 AI가 어떤 파일의 스타일을 따를지 모르거든요. 참고할 파일이나 코드 블록을 직접 넣어주면 혼선이 없어요.
이 습관들을 묶으면 이런 흐름이 돼요
정리하면 이런 루프예요:
- 프로젝트 룰 파일 세팅 (한 번만)
- 작업을 작은 단위로 쪼갠다
- 각 단위마다 “왜”를 중심으로 프롬프트를 쓴다
- 예시가 필요하면 Before/After를 첨부한다
- 결과물을 AI에게 리뷰시킨다
- 확인 후 다음 단위로 넘어간다
이걸 한 바퀴 돌 때마다 코드가 쌓이면서도 품질이 유지돼요. 반대로, 이 루프 없이 큰 작업을 한 번에 던지면 처음엔 빨라 보여도 나중에 고치는 시간이 더 들어요. METR이라는 AI 평가 기관 실험에서 숙련된 개발자들이 AI를 썼는데 오히려 19% 느려진 이유가 바로 이거예요 — 생성은 빠른데 이해하고 검증하는 데 시간을 다 뺏겨버린 거죠.
도구가 좋아지는 속도를 보면, 2026년 바이브코딩 툴 순위는 계속 바뀔 거예요. 근데 프롬프트 습관은 도구가 바뀌어도 그대로 써먹을 수 있어요. 도구를 바꾸기 전에 프롬프트부터 바꿔보세요.
결국 바이브코딩의 생산성은 AI가 아니라 프롬프트를 쓰는 사람이 결정해요. 5가지 습관, 오늘부터 하나씩 시작해보세요.