바이브 코딩 AI 수정 요청법
AI가 코드를 전부 바꿔버리지
않게 하는 방법
생성보다 수정이 더 중요합니다.
범위를 통제하는 사람이 결국 끝까지 만듭니다.
📋 목차
AI가 갑자기 모든 것을 바꿔버린 그 순간
Todo 앱이 드디어 완성됐습니다. 로그인도 되고, 데이터도 저장됩니다. 디자인만 조금 손보면 됩니다.
"헤더 배경색을 파란색으로 바꿔줘"라고 했습니다.
AI가 작업을 마쳤습니다. 확인해보니 헤더뿐만 아니라 전체 색상 시스템이 바뀌어 있었습니다. 로그인 버튼도 사라졌습니다. 저장 기능도 작동을 안 합니다.
"되돌려줘"라고 했더니 AI가 다시 다른 것을 고쳐버렸습니다. 더 이상해졌습니다.
인터넷에는 "좋은 프롬프트 만드는 법"이 넘쳐납니다. 하지만 실제 바이브 코딩에서 시간을 가장 많이 쓰는 것은 처음 생성이 아닙니다. 수정, 또 수정, 그리고 또 수정입니다. 이 글은 그 수정 과정에서 AI가 의도하지 않은 것까지 건드리지 않도록 하는 방법을 다룹니다.
코드를 몰라도 됩니다. 필요한 건 AI에게 범위를 명확하게 말하는 능력입니다.
왜 '생성'보다 '수정'이 더 중요한가
바이브 코딩을 처음 시작할 때는 생성이 전부인 것처럼 느껴집니다. "앱 만들어줘"라고 하면 화면이 뚝딱 나오는 그 경험. 하지만 실제로 앱을 만드는 시간의 분포를 보면 이렇습니다.
📊 실제 바이브 코딩의 시간 분포
이 분포가 보여주는 것은 하나입니다. 바이브 코딩을 오래 지속하는 능력 = 수정을 잘 요청하는 능력입니다. 처음 생성을 잘 하는 것보다, 수정 요청을 구조화하는 것이 실제 완성률을 결정합니다.
일반적인 AI 사용법이 "좋은 결과 한 번 얻기"라면, 바이브 코딩에서 중요한 것은 "긴 작업을 안 무너지고 이어가는 것"입니다. 이 두 가지는 완전히 다른 능력입니다.
AI 폭주가 시작되는 3가지 순간
AI가 갑자기 의도하지 않은 것까지 수정하기 시작하는 데는 패턴이 있습니다. 이 3가지 순간을 미리 알면 사전에 막을 수 있습니다.
💥 순간 1 — 너무 광범위한 요청
"예뻐 보이게 해줘", "전체적으로 개선해줘", "리팩토링해줘" — 범위가 없는 요청은 AI가 자체적으로 범위를 결정합니다. 그 범위는 항상 예상보다 넓습니다.
💥 순간 2 — 오류가 났을 때 "고쳐줘"만 반복
빨간 오류 메시지가 뜨면 "고쳐줘"를 반복하는 경우가 많습니다. AI는 매번 다른 방식으로 고치려 하고, 결국 코드 전체가 뒤엉킵니다. 오류를 고치다 다른 기능이 망가지는 악순환이 시작됩니다.
💥 순간 3 — 대화가 너무 길어졌을 때의 "전체 수정" 요청
대화를 20~30번 이어가다 보면 AI는 초반에 만든 구조를 점점 잊습니다. 이 상태에서 "전체적으로 바꿔줘"라고 하면, AI가 처음부터 자기 방식대로 새로 짭니다. 기존 구조가 무시됩니다.
수정 요청의 핵심 원칙 — 범위를 먼저 정해라
수정 요청을 잘 하는 방법은 하나입니다. AI에게 "무엇을 수정할지"와 "무엇은 건드리지 말아야 할지"를 동시에 알려주는 것입니다. 코드를 알 필요가 없습니다. 영역을 말로 구분하면 됩니다.
🎯 수정 요청 3원칙
- 작게 나눠서 요청하라 — 한 번에 하나씩. "전체 리디자인"보다 "헤더 배경색만"이 훨씬 안전합니다.
- 건드리지 말 것을 명시하라 — "로그인 UI는 그대로 두고", "라우팅 구조는 수정하지 말고"처럼 보존할 것을 먼저 말하세요.
- 수정 전에 커밋부터 — GitHub에 현재 상태를 저장한 후 수정을 요청하세요. AI가 잘못 수정해도 즉시 복구됩니다.
아래 세 가지 실제 패턴으로 어떻게 달라지는지 보겠습니다.
패턴 1 — 디자인 수정
패턴 2 — 기능 추가
패턴 3 — 오류 수정
대화가 길어질 때 — AI가 기억을 잃기 시작하는 순간
범위 통제 다음으로 중요한 것이 있습니다. AI는 대화가 길어질수록 앱의 초반 구조를 잊기 시작합니다. 이것을 모르고 광범위한 요청을 계속하면 갑자기 AI가 전혀 다른 방식으로 구조를 짜기 시작합니다.
💬 대화가 길어지면 일어나는 일
새 대화를 시작해야 할 때
아래 상황 중 하나라도 해당되면 새 대화를 시작하는 것이 더 안전합니다.
🔄 새 대화 시작 신호
- 대화가 30회를 넘어가고 AI 응답 품질이 떨어지는 느낌이 들 때
- AI가 같은 실수를 계속 반복할 때 (3번 이상)
- 지금까지 만든 것과 전혀 다른 새 기능을 만들기 시작할 때
- AI가 "이전에 어떻게 만들었는지 알 수 없습니다"라고 말할 때
새 대화를 시작할 때 첫 메시지로 "이 앱은 현재 [Todo 관리 앱]입니다. Supabase로 데이터를 저장하고, React 기반이며 Vercel에 배포되어 있습니다. 현재 추가하려는 것은 [검색 기능]입니다."처럼 현재 상태를 한 문단으로 요약해 붙여넣으면 빠르게 맥락을 복원할 수 있습니다.
실전 수정 요청 템플릿 3가지
아래 템플릿을 상황에 맞게 복붙해서 쓰세요. 코드를 몰라도 됩니다. 괄호 안만 바꾸면 됩니다.
이전 글 → [[비개발자가 바이브 코딩을 시작하면 GitHub를 가장 먼저 배워야 하는 이유]] — 수정 요청 전에 커밋하는 습관의 중요성 다음 글 → [[AI가 오류를 냈을 때 비개발자가 당황하지 않는 대처법]]
✅ AI 수정 요청 실전 체크리스트
📌 핵심 정리
- 바이브 코딩에서 시간의 대부분은 '생성'이 아니라 '수정'에 씁니다. 수정 요청을 잘 구조화하는 능력이 실제 완성률을 결정합니다.
- AI 폭주의 3가지 원인은 광범위한 요청, "고쳐줘" 반복, 맥락이 소실된 상태에서의 전체 수정 요청입니다. 세 가지 모두 범위를 명시하면 방지할 수 있습니다.
- 수정 요청의 핵심 원칙은 "수정할 것"과 "건드리지 말 것"을 동시에 알려주는 것입니다. 코드를 몰라도 영역을 말로 구분하면 됩니다.
- 대화가 길어질수록 AI는 초반 맥락을 잃습니다. 대화 30회를 넘어가거나 AI가 같은 실수를 반복하면 새 대화를 시작하는 것이 더 효율적입니다.
- 새 대화를 시작할 때는 현재 앱 상태(기술 스택, 작동 기능, 오늘 할 작업)를 한 문단으로 요약해 첫 메시지에 붙여넣으면 맥락이 빠르게 복원됩니다.
- 수정 요청 전에 GitHub 커밋이 먼저입니다. 범위 통제와 버전 관리, 이 두 가지가 함께 있어야 바이브 코딩을 오래 지속할 수 있습니다.
❓ 자주 묻는 질문
바이브 코딩에서 AI가 요청하지 않은 부분까지 바꾸는 이유가 뭔가요?
AI는 요청의 범위를 스스로 판단합니다. "로그인 기능 추가해줘"처럼 범위가 불명확하면 AI는 관련돼 보이는 모든 파일을 수정하려 합니다. 해결 방법은 요청할 때 "수정할 영역"과 "건드리지 말 것"을 명시하는 것입니다. 범위를 명확히 할수록 AI는 그 안에서만 작업합니다.
바이브 코딩에서 AI와 대화를 언제 새로 시작해야 하나요?
대화가 30회를 넘어가거나, AI가 같은 실수를 반복하거나, 전혀 다른 기능을 새로 만들 때 새 대화를 시작하는 것이 좋습니다. 대화가 길어질수록 AI는 초반 맥락을 잃어버립니다. 새 대화를 시작할 때는 "이 앱은 현재 ~한 구조입니다"처럼 현재 상태를 한 문단으로 요약해 붙여넣으면 빠르게 맥락을 복원할 수 있습니다.
바이브 코딩에서 AI 수정 요청을 잘 하기 위한 가장 쉬운 방법은 무엇인가요?
요청을 작게 나누는 것이 가장 효과적입니다. "전체 리디자인해줘" 대신 "헤더 배경색만 바꿔줘"처럼 한 번에 하나씩 요청하세요. 그리고 수정 요청 전에 GitHub에 커밋을 먼저 하면, AI가 잘못 수정하더라도 이전 상태로 즉시 복구할 수 있습니다.
AI에게 "이 부분은 건드리지 마"라고 어떻게 말해야 하나요?
직접적으로 명시하면 됩니다. "절대 수정하지 말 것: 대시보드 UI, 라우팅 구조"처럼 구체적으로 적을수록 효과적입니다. 파일 이름을 알면 "다음 파일만 수정해줘: login.tsx"처럼 파일 단위로 제한할 수도 있습니다. AI는 명확한 제약을 주면 그 범위 안에서만 작업합니다.
오늘 수정 요청 전에
커밋 먼저 하세요
범위를 명시하고, 커밋을 먼저 하고, 작게 나눠서 요청하세요.
이 세 가지만 지켜도 바이브 코딩의 완성률이 크게 달라집니다.
AI와 계속 만들 수 있는 사람이 되는 것은 기술이 아니라 습관입니다.
댓글 쓰기