6강까지의 흐름에서 중요한 전제는 하나였습니다. AI 코딩 도구는 “코드를 대신 써주는 존재”에 가깝지만, “무엇을 왜 만들어야 하는지”까지 자동으로 책임지지는 않습니다. ChatGPT, Claude Code, Cursor, Codex가 아무리 강력해도 입력된 맥락이 부족하거나, 요구가 흐릿하거나, 검수 없이 계속 덧붙이면 결과물은 빠르게 흔들립니다.

바이브 코딩에서 코드 품질이 무너지는 이유는 대개 도구 자체의 성능 부족보다 작업 방식에 있습니다. 특히 초반에는 AI가 그럴듯한 코드를 내놓기 때문에 문제가 늦게 드러납니다. 화면은 뜨는데 저장이 안 되거나, 한 기능을 고치면 다른 기능이 깨지거나, 파일 구조가 점점 복잡해지는 식입니다.

1. 컨텍스트 부족: AI가 맥락을 잃을 때

AI는 현재 대화나 열려 있는 파일, 전달받은 문서 안에서 판단합니다. 프로젝트 전체의 의도, 과거 결정, 숨은 제약을 항상 완벽하게 기억한다고 보기 어렵습니다. 그래서 “이 버튼 고쳐줘”라고만 말하면 어떤 화면의 버튼인지, 기존 상태 관리 방식은 무엇인지, 디자인 규칙은 어떤지 놓칠 수 있습니다.

예를 들어 Cursor에서 특정 컴포넌트를 수정할 때 관련 파일을 충분히 열지 않은 상태로 요청하면, AI는 현재 보이는 파일만 기준으로 임시 해결책을 만들 가능성이 있습니다. Claude Code나 Codex처럼 저장소 단위 작업에 강한 도구를 쓰더라도, 요구사항과 프로젝트 규칙이 명확하지 않으면 엉뚱한 방향의 변경이 생길 수 있습니다.

좋은 요청은 “무엇을 바꿀지”보다 “어떤 맥락에서 왜 바꿀지”를 함께 줍니다.

현재 Next.js로 만든 할 일 관리 앱을 수정 중입니다.
목표는 할 일 목록에서 완료된 항목을 숨기는 필터를 추가하는 것입니다.

관련 조건:
- 기존 상태 관리는 useState로만 처리합니다.
- 새로운 라이브러리는 추가하지 않습니다.
- 기존 TodoList 컴포넌트 구조는 최대한 유지합니다.
- UI는 현재 버튼 스타일을 그대로 따릅니다.

먼저 관련 파일을 읽고, 수정 계획을 3단계로 설명한 뒤 코드 변경을 제안해 주세요.

이 정도만 적어도 AI가 갑자기 상태 관리 라이브러리를 추가하거나, 컴포넌트를 통째로 갈아엎는 일을 줄일 수 있습니다. 핵심은 “AI가 알아서 이해하겠지”가 아니라 “판단에 필요한 배경을 먼저 준다”입니다.

2. 요구사항 모호함이 부르는 엉뚱한 결과

“예쁘게 만들어줘”, “로그인 기능 붙여줘”, “관리자 페이지 만들어줘” 같은 요청은 편하지만 위험합니다. 사람끼리도 이런 말만으로는 같은 결과를 상상하기 어렵습니다. AI 역시 빈칸을 추측으로 채웁니다.

문제는 그 추측이 꽤 자연스러워 보인다는 점입니다. 로그인 기능을 요청했더니 임시 사용자 배열을 만들고, 토큰처럼 보이는 문자열을 저장하고, 실제 보안과는 거리가 먼 코드를 만들어낼 수 있습니다. 화면 개선을 요청했더니 프로젝트에서 쓰지 않던 CSS 방식이나 UI 라이브러리를 추가할 수도 있습니다.

요구사항은 최소한 다음 네 가지로 나누면 안정적입니다.

기능: 사용자가 이메일과 비밀번호로 로그인한다.
범위: 프론트엔드 로그인 폼 UI와 입력 검증까지만 만든다.
제외: 실제 인증 API 연동, 회원가입, 비밀번호 찾기는 만들지 않는다.
제약: React Hook Form이나 새 UI 라이브러리는 추가하지 않는다.

“무엇을 할지”만큼 “무엇을 하지 않을지”가 중요합니다. 특히 바이브 코딩에서는 제외 범위를 적지 않으면 AI가 친절하게 기능을 확장해 버립니다. 처음에는 좋아 보이지만, 나중에는 이해하지 못하는 코드가 늘어나는 원인이 됩니다.

ChatGPT로 기획을 정리할 때도 바로 “코드 짜줘”로 넘어가기보다 요구사항을 먼저 고정하는 편이 좋습니다.

아래 기능 설명을 개발 요청서 형태로 정리해 주세요.
단, 구현 코드는 작성하지 말고 기능 범위, 제외 범위, 화면 구성, 검수 기준만 작성해 주세요.

기능 설명:
개인용 독서 기록 앱을 만들고 싶습니다.
책 제목, 저자, 읽은 날짜, 메모를 저장하고 목록에서 볼 수 있으면 됩니다.

이렇게 만든 요청서를 Cursor, Claude Code, Codex에 넘기면 코드 생성의 방향이 훨씬 안정됩니다.

3. 검수 부재로 쌓이는 오류

AI가 만든 코드에서 가장 위험한 순간은 “일단 실행되니까 다음 기능으로 넘어가는 때”입니다. 작은 오류가 누적되면 나중에는 어디서부터 잘못됐는지 찾기 어려워집니다. 바이브 코딩 초보자에게 많이 생기는 상황입니다.

예를 들어 처음에는 목록 추가 기능만 있었습니다. 여기에 수정 기능, 삭제 기능, 검색 기능, 정렬 기능을 계속 붙입니다. 매번 화면은 대충 동작합니다. 그런데 어느 날 새로고침하면 데이터가 사라지고, 검색 후 삭제하면 다른 항목이 지워지고, 정렬을 바꾸면 수정 중이던 값이 초기화됩니다. 이때는 단일 문제가 아니라 여러 변경이 얽힌 상태가 됩니다.

검수는 거창한 테스트 자동화부터 시작할 필요가 없습니다. 기능 하나가 추가될 때마다 사람이 확인할 기준을 적고, 그 기준대로 눌러보는 것만으로도 품질이 크게 달라집니다.

검수 기준:
1. 빈 제목으로 저장을 누르면 저장되지 않아야 한다.
2. 정상 제목을 입력하면 목록 맨 위에 추가되어야 한다.
3. 추가된 항목은 새로고침 후에도 유지되어야 한다.
4. 삭제 버튼을 누르면 해당 항목만 삭제되어야 한다.
5. 삭제 후 다른 항목의 내용은 바뀌지 않아야 한다.

AI에게도 검수 기준을 기준으로 점검하게 만들 수 있습니다.

방금 수정한 코드가 아래 검수 기준을 만족하는지 확인해 주세요.
코드를 바로 고치지 말고, 먼저 통과/실패 가능성을 표로 정리해 주세요.

검수 기준:
1. 빈 제목으로 저장을 누르면 저장되지 않아야 한다.
2. 정상 제목을 입력하면 목록 맨 위에 추가되어야 한다.
3. 추가된 항목은 새로고침 후에도 유지되어야 한다.
4. 삭제 버튼을 누르면 해당 항목만 삭제되어야 한다.
5. 삭제 후 다른 항목의 내용은 바뀌지 않아야 한다.

여기서 중요한 점은 AI의 검토 결과를 그대로 믿고 끝내지 않는 것입니다. AI는 코드를 읽고 추론할 수 있지만, 실제 브라우저 동작이나 환경 차이까지 항상 보장하지는 않습니다. 사람이 직접 실행해 보고, 이상한 부분을 다시 좁혀서 요청해야 합니다.

4. 한 번에 너무 많이 시키는 실수

“전체 앱을 완성해줘”라는 요청은 바이브 코딩의 가장 큰 함정 중 하나입니다. AI가 긴 코드를 한 번에 만들어주면 빠르게 개발되는 것처럼 느껴집니다. 하지만 한 번에 생성된 코드는 요구사항 누락, 파일 구조 혼선, 중복 로직, 불필요한 패키지 추가가 섞이기 쉽습니다.

특히 초보자에게 문제는 코드 양입니다. 한 번에 너무 많은 파일이 바뀌면 사용자는 무엇이 중요한 변경인지 알기 어렵습니다. 에러가 나도 원인을 좁히기 어렵고, AI에게 다시 물어봐도 앞선 변경의 의도를 놓칠 수 있습니다.

작업 단위를 작게 나누면 품질이 올라갑니다. 예를 들어 독서 기록 앱을 만든다면 다음처럼 쪼개는 편이 안전합니다.

1단계: 책 목록을 보여주는 정적 UI를 만든다.
2단계: 입력 폼을 추가하고 새 책을 목록에 추가한다.
3단계: 삭제 기능을 붙인다.
4단계: localStorage에 저장한다.
5단계: 검색 기능을 추가한다.

각 단계마다 요청도 짧아야 합니다.

1단계만 진행해 주세요.
React 컴포넌트로 독서 기록 목록 UI를 만듭니다.

조건:
- 아직 입력, 삭제, 저장 기능은 만들지 않습니다.
- 샘플 데이터 3개를 코드 안에 두고 화면에 표시합니다.
- CSS는 기존 방식만 사용합니다.
- 변경할 파일과 변경 이유를 먼저 설명한 뒤 코드 수정안을 제시해 주세요.

이 방식은 느려 보이지만 실제로는 되돌리기 쉽고, 이해하기 쉽고, 검수하기 쉽습니다. 바이브 코딩에서 속도는 “한 번에 많이 만드는 속도”가 아니라 “깨지지 않게 계속 전진하는 속도”에 가깝습니다.

5. 코드 품질을 지키는 습관

AI가 만든 코드 품질을 지키려면 요청 습관, 변경 습관, 검수 습관이 함께 필요합니다. 도구를 바꾸는 것만으로 해결되지 않습니다. ChatGPT는 요구사항 정리와 검토에 강하고, Cursor는 현재 코드베이스 안에서 수정하기 편하며, Claude Code와 Codex는 저장소 맥락을 다루는 작업에 유용합니다. 다만 어떤 도구를 쓰든 사람의 지시가 흐릿하면 결과도 흔들립니다.

작업 전에는 항상 목표와 범위를 짧게 씁니다.

목표:
할 일 목록에 완료/미완료 필터를 추가한다.

범위:
필터 버튼 3개를 만든다.
전체, 완료, 미완료 상태로 목록을 걸러 보여준다.

제외:
디자인 전면 개편은 하지 않는다.
상태 관리 라이브러리는 추가하지 않는다.
백엔드 연동은 하지 않는다.

작업 중에는 AI에게 바로 코드를 바꾸게 하지 말고 계획을 먼저 요구하는 편이 좋습니다.

코드를 수정하기 전에 먼저 작업 계획을 작성해 주세요.
다음 형식으로만 답변해 주세요.

1. 수정할 파일
2. 수정 이유
3. 예상되는 영향 범위
4. 검수해야 할 항목

작업 후에는 변경 내용을 설명하게 하고, 사용자가 직접 확인할 체크리스트를 받습니다.

이번 변경 내용을 초보자도 이해할 수 있게 요약해 주세요.
그리고 브라우저에서 직접 확인해야 할 검수 체크리스트를 작성해 주세요.
새로운 기능 제안은 하지 말고, 현재 변경 범위 안에서만 작성해 주세요.

코드가 마음에 들지 않을 때도 “다시 제대로 해줘”보다는 문제가 되는 지점을 좁혀야 합니다.

현재 코드는 기능은 동작하지만 TodoItem 컴포넌트 안에 조건문이 너무 많아졌습니다.
동작은 바꾸지 말고, 읽기 쉽게 정리할 방법을 제안해 주세요.
먼저 리팩터링 계획만 설명하고 코드 수정은 아직 하지 마세요.

이런 요청은 AI가 무리하게 전체 구조를 바꾸는 일을 막아줍니다. “동작은 바꾸지 말라”, “계획만 먼저”, “새 라이브러리 금지”, “현재 변경 범위 안에서만” 같은 문장은 코드 품질을 지키는 안전장치입니다.

바이브 코딩에서 좋은 결과를 만드는 사람은 AI에게 많은 일을 한꺼번에 맡기는 사람이 아니라, AI가 실수하기 어려운 환경을 만들어주는 사람입니다. 맥락을 주고, 범위를 자르고, 검수 기준을 세우고, 작은 단위로 반복하면 AI 코드의 품질은 눈에 띄게 안정됩니다. 다음 기능을 더 붙이기 전에 지금 코드가 이해 가능한 상태인지 확인하는 습관이 결국 가장 빠른 길이 됩니다.