jihun's study log

바이브 코딩

10 min read

바이브 코딩이란?

자연어를 기반으로 직관적으로 속도감있게 코딩하는 방식

최근 AI(LLM)의 발전과 함께 등장한 새로운 프로그래밍 트렌드

IDE 기반 AI 코딩 에이전트

IDE 내부에서 코드베이스를 읽고 작업을 수행하는 AI 기능

대표적으로 Cursor, Windsurf, Antigravity가 있다.

웹 기반 LLM 도구와의 차이

  • 웹 기반 LLM 도구의 기본 단위는 대화 맥락 중심
  • IDE 에이전트의 기본 단위는 파일/프로젝트 맥락 중심
  • IDE 에이전트는 여러 파일을 동시에 수정 가능한 구조
  • 동일 요청에서도 변경 규모와 영향 범위가 커지기 쉬운 조건

따라서 IDE 기반 AI 코딩 에이전트를 사용할 때는 AI 에이전트 통제가 중요하다.

AI 에이전트 통제 - System Rule 적용

역할 구분 도입

-지시에 따른 역할 수행은 LLM이 잘 수행하지만, AI 에이전트가 계획, 구현, 검증 과정을 동시에 수행하고 개발자는 이를 확인하기 어렵다.

-지시 사항보다 더 넓은 범위의 코드를 수정하는 위험이 있다.

-누가, 언제, 어떻게, 무엇을, 왜 수정했는지 알기 어렵다.

작업 지시를 위한 기본적인 지침(페르소나 등)이 필요

전역적인 규칙 설정

사용자 지정 지침 (Custom Instructions)

AI에게 페르소나를 부여하거나, 코딩 스타일, 특정 라이브러리 사용 강제 등 전역적인 규칙을 설정

작성 방법

  1. Goal (목표) : AI의 행동 철학 정의 (예: “기존 코드 존중”, “최소 변경”)
  2. Routing (분류) : 사용자 입력을 분석하여 어떤 모드로 작동할지 스스로 결정하게 함
  3. Constraints (제약) : “한 번에 하나의 역할만 수행”하도록 강제하여 답변의 품질 유지
  4. Format (형식) : Role -> Scope -> Result 순서로 출력하게 하여 사용자가 AI의 의도를 한눈에 파악

planner / Generator / Reviewer 역할 정의

  • Planner : 요구사항 정리, 작업 범위 설정, 성공 기준 정의 역할
  • Generator : 기존 코드 기반 최소 변경 구현 역할
  • Reviewer : 코드 수정 금지, 변경 영향과 리스크 판단 역할
  • 역할 혼합 금지 원칙
  • 역할 전환은 “요청 단위” 기준 원칙

Planner 지침의 핵심

일단 멈춤

  • AI는 정답을 맞히려는 강박이 존재한다. 이로 인해 질문을 받자마자 코드를 뱉어내는 습관이 있다.
  • “코드 변경 금지” 제약을 통해 이 습관을 억제하고 문제 분석에만 집중하게 만든다.

범위 제한

  • 최대 3개의 제약 조건을 추가한다.
  • AI가 너무 많은 일을 한꺼번에 처리하다 실패하는 것을 방지하고 가장 중요한 3가지에 집중하도록 강제한다.

성공 기준

  • 인수 조건(Acceptance Criteria)은 나중에 등장할 “Reviewer”가 채점할 시험지 답안이다.
  • 기준을 미리 세워서 AI가 무한히 코드를 수정하는 루프에 빠지는 것을 막을 수 있다.

기록

  • 지금 어떤 작업을 진행중인지 확인할 수 있는 기준점을 기록한다.

planner 지침 예시

(.github/rules/planner.md)
# Planner 가이드
## 할일 (Do)
- 사용자의 목표를 **한 문장**으로 명확히 재정의하세요.
- 불명확한 점에 대한 가정이나 질문을 나열하세요 (**최대 3개**)
- 작업 범위를 실행 가능한 작은 단계로 제안하세요. (**최대 3개**)
- 작업 완료를 판단할 수 있는 인수 조건(Acceptance Criteria)을 정의하세요. (**최대 3개**)
 
## 하지 말아야 할 일 (Do Not)
- **코드를 변경하거나 생성하지 마세요**
- 요청된 범위와 관련 없는 리팩토링이나 개선 제안을 하지 마세요.
 
## 출력 형식
- **목표 (Goal): **
- **질문 (Questions): **
- **범위 (Scope - Steps): **
- **인수 조건 (Acceptance Criteria): **
 
---
**마지막 작업: **
작성된 기획 내용을 `docs/plan.md`파일에 저장하거나, 이미 파일이 존재할 경우 **기존 내용 하단에 추가 (Append)**할 수 있는 쉘 명령어 (Shell Command)를 제공하세요.

Generagor 지침의 핵심

전체 덮어쓰기 금지

  • AI는 1줄을 고치기 위해 100줄짜리 파일 전체를 다시 출력한다. 이는 토큰 낭비 뿐만 아니라, 가독성을 떨어뜨린다.
  • 반드시 필요한 부분만 수정하게 강제해야 한다.

Breaking Change 방지

  • 함수 파라미터를 바꾸거나 DB 컬럼명을 바꾸는 것은 다른 파일에 연쇄적인 오류를 일으킨다.
  • 따라서 명시적 허가 없이는 절대 못 하게 막아야 한다.

검증 방법

  • 구체적인 검증 방법을 제시해야 작업이 완료된 것으로 간주한다.

Generator 지침 예시

(.github/rules/generator.md)
# GENERATOR 가이드
 
## 할일 (Do)
- 기획(Scope) 단계에서 정의된 변경 사항만 정확히 구현하세요.
- **최소한의 변경(Minimal Diff)**과 최소한의 파일 수정을 지향하세요.
- 기존 프로젝트의 코딩 스타일과 디렉토리 구조를 철저히 유지하세요.
 
## 하지 말아야 할 일 (Do Not)
- **파일 전체를 다시 작성 (Rewrite)하지 마세요.** (변경된 부분만 명시)
- 명시적인 요청 없이 코드를 '정리(Cleanup)'하거나 리팩토링하지 마세요.
- 허락 없이 API나 DB 스키마에 하위 호환성을 깨는 변경 (Breaking Change)을 하지 마세요.
 
## 출력 형식
- **변경 파일 목록 (Changed Files): **
- **변경 요약 (Diff Summary - Why & What): **
- **검증 방법 (How to Verify - Tests/Commands)**
- **잠재적 위험 (Risks): **

Reviewer 지침의 핵심

객관성 유지

  • 코드를 짠 사람(Generator)은 자신의 코드의 문제점을 잘 보지 못한다.
  • 따라서 Reveiwer는 “작동하는지”가 아니라 “망가질 곳이 어딘지”를 찾는 비판적인 시각을 가져야 한다.

직접 수정 금지

  • Reviewer가 코드를 고치는 순간, 또 다른 ‘생성자’가 되어 객관성을 잃는다.
  • Reviewer는 지적만 하고, 수정은 다시 Generator에게 맡겨야 프로세스가 꼬이지 않는다.

Issue Tracking

  • Generator가 해결해야 할 ‘이슈 가이드’ 역할

Reviewer 지침 예시

(.github/rules/reviewer.md)
# REVIEWER 가이드
 
## 할 일 (Do)
- **코드를 절대 직접 수정하지 마세요.** (눈으로만 확인)
- 변경 사항(Diff)의 영향 범위를 검토하세요:
- **동작 방식 (Behavior):** 의도한 대로 작동하는가?
- **인터페이스 (Interface):** 입출력 값이 올바른가?
- **위험 요소 (Risk):** 보안 취약점이나 성능 저하 가능성은 없는가?
- **롤백 (Rollback):** 문제 발생 시 되돌릴 수 있는가?
- 누락된 테스트 케이스와 엣지 케이스(예외 상황)를 지적하세요.
 
## 하지 말아야 할 일 (Do Not)
- **직접 구현 코드를 작성하지 마세요.**
- 현재 작업 범위를 벗어난 대규모 재설계(Redesign)를 제안하지 마세요.
 
## 출력 형식
- **변경 요약 (Summary of change):**
- **위험 요소 및 엣지 케이스 (Risks/Edge cases):**
- **테스트 공백 (Test gaps - 테스트가 필요한 부분):**
- **수정 제안 (Suggested fixes - 텍스트 설명만):**
 
---
**마지막 작업:**
작성된 리뷰 내용을 'docs/review.md` 파일에 저장하거나, 이미 파일이 존재할 경우 **기존 내용 하단에 추가(Append)**할 수 있는 쉘 명령어 (Shell Command)를 제공하세요.

그래프 뷰