바이브 코딩은 어떤 방식이며 코드 변경 뒤 무엇을 확인해야 하나요?
바이브 코딩은 자연어로 의도를 전달하고 코드 변경과 검증을 반복하는 작업 방식입니다. AI에게 맡긴다고 요구사항이나 확인이 없어지는 것은 아닙니다.
본문 근거: cursor.com
먼저 기준을 정합니다
바이브 코딩은 자연어로 구현 의도를 빠르게 전달하는 개발 방식이지만, 요구사항·상태·검증을 생략해도 된다는 뜻은 아닙니다. 속도를 얻을수록 사람이 확인해야 할 diff와 실행 결과가 더 중요해집니다.
AI 코딩 도구의 제품 이름이나 UI는 바뀔 수 있지만, 저장소를 읽고 변경하고 검증한다는 기본 흐름은 같습니다. 따라서 특정 버튼 위치를 외우기보다 다음 질문에 답할 수 있어야 합니다.
- AI가 지금 어떤 파일을 읽을 수 있는가?
- 어떤 파일을 수정해도 되는가?
- 어떤 명령을 실행해도 되는가?
- 비밀정보가 컨텍스트에 포함되지 않았는가?
- 완료를 무엇으로 증명할 것인가?
요청을 작업 계약으로 바꾸기
요청
- 구현 목표를 한 문장으로 설명
- 기존 파일을 먼저 읽기
- 새 라이브러리 추가 금지
- 변경 후 diff 설명
- 실행 가능한 검증 명령 수행
좋은 요청은 구현 방법을 모두 대신 결정하는 문서가 아닙니다. 목표와 경계, 완료 조건을 명확히 해서 AI가 불필요한 범위를 추측하지 않게 만드는 것이 목적입니다.
직접 해볼 일 · 입력과 검토 기준
독자 질문: 바이브 코딩으로 빠르게 만들 때 무엇을 검증할까?
실습: 로컬 예제의 할 일 목록에 ‘완료 항목 숨기기’를 한 기능으로 정하고, 바로 구현하라는 요청을 작업 계약으로 고쳐 보세요.
입력 예시: 별도 연습 앱의 완료 항목만 숨기는 토글을 제안해 주세요. 먼저 관련 파일과 기존 필터를 찾고 계획만 제시하세요. 허용 파일은 확인 후 정합니다. 새 의존성·저장 방식 변경은 금지합니다. 완료/미완료 항목을 각각 확인할 방법도 적어 주세요.
결과 검토: 계획에 목표·비목표·파일 범위·검증이 있는지 봅니다. 구현 후 실제 diff와 토글 전후 화면을 대조하고, 새로고침 시 기존 목록 동작이 유지되는지 확인합니다.
수정 요청: 범위 밖 리팩터링이 섞이면 ‘토글과 직접 관련된 변경만 남기고 별도 작업으로 분리하세요’라고 고칩니다.
다음 학습: 3회차에서 이 변경의 품질 기준을 먼저 문장으로 고정합니다.
확인 범위: 공식 자료 cursor.com를 대조했습니다. 이 글의 AI 도구 조작·저장소 변경·명령 실행은 편집자가 직접 수행하지 않았으므로 미확인입니다. 독자는 자신의 환경에서 결과를 기록해 주세요.
독립 실습: 같은 요청을 검증 가능한 요청으로 고치기
TaskFlow 없이 종이에 “검색 기능을 만들어 줘”를 적고 다음처럼 구체화합니다.
입력: [{ title: "회의 준비" }, { title: "문서 정리" }]
검색어: "회의"
기대 결과: "회의 준비" 한 건
빈 검색어: 전체 항목 반환
비목표: 서버 검색, 새 라이브러리, UI 재설계
채팅형 도구는 제안 코드를 사람이 옮길 수 있고, 편집기·에이전트형 도구는 저장소를 읽고 파일과 명령을 직접 다룰 수 있습니다. 같은 모델이라도 도구 권한과 컨텍스트가 달라 결과가 달라집니다. 프로토타입에서 결과가 한 번 나오는 것과 기존 앱에 안전하게 통합되는 것은 서로 다른 완료 조건입니다.
자가 확인용 입력은 [{ title: “문서 읽기”, done: true }, { title: “코드 쓰기”, done: false }]입니다. 완료 숨기기 OFF이면 두 항목, ON이면 코드 쓰기만 남는다는 기대 결과를 계약에 적습니다. 원본 배열과 저장값을 삭제하는 요구가 아니라 화면 필터 요구라는 점도 포함합니다.
자주 발생하는 오류와 해결
검색 결과만 맞고 빈 검색어에서 오류가 나면 경계 조건을 계약에 추가합니다. AI가 실제로 실행하지 않은 결과를 설명하면 실행 로그 또는 직접 재현을 요청합니다. 구현 파일이 예상보다 늘면 요구사항과 무관한 변경을 분리합니다.
선택 실습: 같은 프로젝트로 연습하기
이 선택 실습은 TaskFlow 작업 관리 앱의 변경 요청을 AI와 함께 검토하는 연습입니다. 요청·코드·검증 결과를 구분해 기록합니다.
이번 주제: 바이브 코딩이란 Cursor Claude Code Codex로 앱 만드는 방식과 현실.
TaskFlow 실습
이어서 읽기: AI 코딩 도구 시작 가이드 저장소 컨텍스트 권한 첫 수정 검증. 누적 작업 기록은 docs/ai-log.md에 회차별로 추가합니다. 새로 진입하면 실제 개발환경 시작 ZIP을 별도 폴더에 풉니다. 이 앱에는 상태 문구와 API URL 표시가 있으며 작업 목록·검색·완료 필터는 없습니다. 상단의 필터 예시는 독립 설계 문제이고, 현재 앱에서 그대로 실행된 기능으로 기록하지 않습니다.
제공 스타터에는 검색할 작업 목록이 없으므로 상단 필터 계약을 바로 구현할 파일이 있다고 가정하지 않습니다. 하단에서는 apps/web/src/main.js의 상태 문구 변경 한 건을 막연한 요청과 범위·완료 조건이 있는 요청으로 비교합니다. 실제 수정이 있다면 파일별 diff와 표시 문구를 대조하고, 계약만 작성했다면 구현 결과와 구분해 기록합니다.
실습은 가능한 한 작은 변경으로 시작합니다. 변경 전에 현재 working tree를 확인하고, AI가 작업한 뒤에는 대화 내용보다 실제 diff를 기준으로 판단합니다.
git status --short
git diff
프로젝트에 맞는 검증 명령이 있다면 함께 실행합니다.
pnpm lint
pnpm build
이 과정의 TaskFlow 기준은 pnpm 11.19.0이며 lint·build 스크립트를 사용합니다. test 스크립트는 없으므로 npm test나 pnpm test가 통과한다고 기록하지 않습니다. 별도 테스트가 있는 저장소는 package.json의 실제 명령을 추가하고, TaskFlow 동작은 브라우저 확인으로 별도 기록합니다.
변경을 검토하는 방법
Before: 결과가 나오면 성공
After: 요구사항 충족 + 변경 범위 적절 + 기존 기능 유지 + 검증 성공
검토할 때는 “코드가 그럴듯한가”가 아니라 요구사항과 diff를 비교합니다.
요청한 파일만 바뀌었는가
기존 규칙을 재사용했는가
새 dependency가 필요한가
오류 처리와 접근성을 놓치지 않았는가
검증 결과가 실제 실행 결과인가
되돌리기 쉬운 변경인가
실패와 위험
- 특정 모델의 성능 순위 글로 만들지 않음
- 도구별 가격·모델명·지원 기능은 본문 작성 시 공식 문서 확인
- 바이브 코딩을 무검토 자동 개발과 동일시하지 않음
AI가 틀릴 수 있다는 추상적인 경고보다 실패를 발견할 구조를 만드는 것이 중요합니다. 작은 diff, 명확한 검증 명령, 사람 승인 지점이 있으면 모델이 달라져도 같은 작업 원칙을 유지할 수 있습니다.
완료 체크리스트
- 독립 과제가 TaskFlow 없이도 이해 가능
- 하단 TaskFlow 작업은 1회차 체크포인트에서 이어짐
- 결과보다 검토 절차가 중심인지 확인
누적 기록과 실행 결과
이전 회차 ai-step-01-start에 남긴 기록을 시작점으로 사용합니다.
현재 구조는 기존 TaskFlow 소스와 package.json을 유지하고, 학습 기록은 새로 만드는 docs/ai-log.md에 누적합니다. 이 경로는 앱 실행 파일이 아닌 실습용 기록 위치입니다. 기존 동명 파일이 있으면 덮어쓰지 않고 회차 항목을 추가합니다. 앱 수정 파일은 저장소 탐색 후 계약에 확정하며 문서의 예시 경로를 실제 파일로 가정하지 않습니다.
Before는 해당 회차의 기록 항목이 없는 상태이고, 적용은 위 실습을 수행하며 관찰 내용을 채우는 과정입니다. After는 아래 항목의 근거와 미검증 범위가 남은 상태입니다. 문서 제목을 바꾸는 것만으로 기능 구현이 완료된 것은 아닙니다.
아래는 docs/ai-log.md에 추가하는 회차 항목 전체입니다. 앱 전체 코드가 아닌 개발 로그 양식이며, 빈칸은 직접 확인한 결과로 채웁니다.
체크포인트: ai-step-02-vibe
작업 요청 / 목표 / 비목표:
시작 상태 / 적용 지침:
허용 파일 / 실제 변경 파일:
계획 / diff 요약:
실행 명령 / 실제 결과 / 증거 위치:
미검증 항목 / 필요한 조건:
사람이 확인·수정한 내용:
승인 여부 / 승인 대상:
commit: 미생성 또는 실제 확인한 식별자
실패 지점 / 복구점 / 다음 행동:
검증란은 성공·실패·미실행을 구분합니다. 이 양식 자체는 실행 성공이나 사람 승인 증거가 아닙니다. 앱을 바꿨다면 diff → pnpm lint·pnpm build → 필요한 브라우저 확인 → 사람 검토 → 승인 → commit 순서로 기록합니다. 로그만 편집한 단계는 내용 대조가 검증이며 앱 테스트 통과로 부풀리지 않습니다.
완료 체크포인트
ai-step-02-vibe
다음 학습
3회차 AI 바이브 코딩 기준: 코드 품질이 무너지기 전 확인할 것
도구별 기능·권한 명칭·설치 방법은 발행 시점 공식 문서를 기준으로 다시 확인하고, 이 글의 원칙과 제품별 UI를 구분합니다.
글 소개·학습 준비·전체 목차
AI 코딩 도구 · 2 / 11
바이브 코딩이란 Cursor Claude Code Codex로 앱 만드는 방식과 현실
바이브 코딩을 “AI가 대신 개발해 주는 방식”으로 단순화하지 않고, 자연어 요청→코드 변경→검증 반복이라는 작업 방식으로 정의합니다. Cursor·Claude Code·Codex 등 도구 이름은 예시이며 과정의 핵심은 도구보다 작업 방식입니다.
선수 지식
자연어 요청과 코드의 차이, 파일 저장·변경 비교의 기초가 필요합니다.
이번 글에서 배우는 내용
- 바이브 코딩의 장점과 한계
- 빠른 프로토타입과 유지보수 코드의 차이
- 채팅형·IDE형·에이전트형 도구의 역할 차이
- 모델이 프로젝트 맥락을 틀릴 수 있는 이유
- 작은 기능 요청에서 diff 검토가 필요한 이유
- “작동함”과 “좋은 변경”을 구분
목차
이 글이 도움이 되었나요?
읽음 기록
읽음 — / 전체 11개 · 필수 9개
새 글 받아보기
RSS 리더에서 BlogFlow의 새 글을 확인할 수 있습니다.
