핵심 요약
Vibe Coding은 Andrej Karpathy가 명명한 표현이다. AI에게 대화식으로 지시해 대부분의 코드를 만드는 방식. 얼핏 즉흥 작업처럼 보이지만, 결과 품질은 지시의 구조화 여부에 크게 좌우된다.
7가지 원칙
1) 의도를 먼저, 구현을 나중에
"로그인 기능 만들어 줘"는 실패한다. "OAuth Google + 이메일 2가지를 지원하고, 세션은 JWT 쿠키로, 유효기간 7일"이 성공한다. AI는 제약 조건을 잘 지킨다.
2) 요구사항은 "파일"에 쓴다
대화창에 적으면 두 턴 뒤에 잊힌다. SPEC.md 또는 Cursor Rules에 넣으면 모델이 매번 참조한다. 말보다 파일이 강하다.
3) 한 번에 하나의 변경
"로그인 추가하고 대시보드도 리팩터링하고 테스트 커버리지도 올려 줘"는 품질이 무너진다. 변경 하나 → 테스트 통과 → 커밋 → 다음 변경.
4) 생성과 검증을 분리
같은 모델이 자기 코드를 검증하면 버그를 놓친다. 코드 작성은 Cursor, 테스트 검증은 Claude Code처럼 다른 세션/다른 도구를 쓰는 편이 품질이 높다.
5) "왜 그렇게 고쳤나" 질문하기
AI가 내놓은 수정에 대해 이유를 물어보고, 말이 안 되면 반려한다. 이유를 못 대면 모델이 추측한 것이다. 절대 머지하지 말 것.
6) 작은 단위로 커밋
AI 세션이 꼬이면 복구의 유일한 수단이 git reset이다. 커밋 간격이 짧을수록 안전하다. 기능 단위가 아니라 로직 변경 단위로 쪼개라.
7) 테스트를 선제적으로
"이 기능 만들어 줘" 대신 "이 기능의 테스트를 먼저 짜 줘 → 통과하도록 구현해 줘" 순서가 품질을 끌어올린다. TDD 원칙은 AI 시대에도 유효하다.
실전 프롬프트 템플릿
① 기능 추가 템플릿
아래 요구사항대로 기능을 추가해 주세요.
요구사항:
- [구체적 목표]
- [인풋·아웃풋 명세]
- [제약 조건]
참고 파일:
- src/feature/XXX.ts (비슷한 구조)
- tests/feature/XXX.test.ts (테스트 스타일)
결과물:
- 구현 코드
- 테스트 코드
- 변경 파일 목록과 이유
절대 수정하지 말 것:
- database schema
- 외부 API 계약② 버그 수정 템플릿
증상:
- [재현 단계 1, 2, 3]
- [관찰된 동작 vs 기대 동작]
- [에러 메시지 전문]
가설을 3개 세워 주세요. 각 가설에 대해:
1) 확인 방법
2) 맞다면 수정 범위
3) 리스크
가장 확률 높은 가설부터 확인해 주세요. 확인 전에 수정하지 마세요.③ 리팩터링 템플릿
대상: [파일/모듈 경로]
목표: [명확한 개선 지표 — 예: 함수 100줄 이하, 순환 의존 제거]
규칙:
- 동작은 절대 바꾸지 말 것
- 기존 테스트가 전부 통과해야 함
- 변경 이전 동작을 보존하는 테스트 먼저 추가
단계:
1) 현재 구조 요약 (5줄 이내)
2) 리팩터링 계획 (단계 리스트)
3) 확인받은 후 실행흔한 실패 패턴
- 대화로만 지시하다 요구사항이 소실 → 파일로 고정
- 에이전트가 무한 루프를 돌 때 시간 낭비 → 자주 인터럽트하고 방향 재설정
- 생성된 코드를 눈으로만 확인 → 반드시 테스트 실행
- 문제가 쌓여 복구 불가 → 짧은 간격으로 커밋 필수
하루 워크플로 예시
- 오전: Linear 이슈에서 오늘의 스펙을 파일로 번역
- 기능 1개 → Cursor로 구현 → Claude Code로 테스트·리팩터링
- 점심 전 커밋·PR
- 오후: 리뷰 코멘트 반영 → 다음 기능
- 마지막 1시간: 쌓인 TODO 정리, 코드베이스 health check
자주 묻는 질문
Vibe Coding이 사라지게 할 기술은 없나?
도구는 진화해도 원칙(명확한 의도, 작은 단위, 검증 분리)은 오래 유지된다. 도구 이름은 바뀌어도 방법론은 남는다.
주니어 개발자가 이렇게 배워도 되나?
기초를 건너뛰면 AI 출력이 맞는지 판단하지 못한다. 손코딩과 디버깅의 경험이 오히려 Vibe Coding의 필수 조건이다.
어디까지 AI에 맡기고 어디부터 직접 짜야 하나?
기계적 반복·보일러플레이트·테스트는 AI, 아키텍처 결정·보안 감사·성능 크리티컬 경로는 사람. 이 경계는 사용자마다 조금씩 다르다.
댓글 0