AI 코딩 제대로 하는 법: 규칙·프롬프트·계획·리뷰로 바이브 코딩 탈출

핵심 메시지

• AI에게 코드를 '맡기는' 바이브 코딩과, 개발자가 전략적으로 '안내하는' 코딩은 전혀 다르다.
• 코드베이스 인덱싱과 규칙(rules) 설정으로 기초를 한 번 잡아 두면 매번 같은 지시를 반복할 필요가 없다.
• 프롬프트의 1번 원칙은 '구체성'이다. 무엇을 어떻게 바꿀지 파일·필드 단위로 명시한다.
• 모델을 작업에 맞게 지정하고 대화를 짧게 유지하면 비용과 토큰을 아낄 수 있다.
• 코드는 주니어와 페어 프로그래밍하듯 리뷰하라. AI는 위임 대상이 아니라 협업 상대다.

쉽게 이해하기

이제 거의 모두가 AI로 코드를 짠다. 하지만 발표자는 소프트웨어 개발자가 AI를 전략적으로 안내하는 것과, 그냥 운전대를 넘겨버리는 '바이브 코더' 사이에는 큰 차이가 있다고 말한다. 여기서 다루는 원칙은 특정 도구에 종속되지 않고 어떤 AI 코딩 도구에도 적용된다.

먼저 기초를 한 번만 제대로 세운다. AI가 전체 코드베이스를 인덱싱해 맥락을 갖게 하고, 규칙(rules)을 정해 둔다. 규칙은 두 종류다. 모든 프로젝트에 적용되는 글로벌 규칙(코딩 표준, 선호 라이브러리, 자주 쓰는 명령, 테스트 철학)과, 저장소 안의 파일에 두는 프로젝트별 규칙(기술 스택과 버전, DB 스키마, API 패턴, 브랜치 명명 규칙)이다. 서브모듈마다 다른 규칙이 필요하면 별도 규칙 파일을 둘 수 있다. 규칙을 잡아 두면 같은 지시를 매번 입력하지 않아도 모든 상호작용이 가드레일 안에서 시작된다.

프롬프트의 첫 번째 원칙은 구체성이다. "수정 버튼이 토글되게 해줘"는 게으른 지시이고 수십 가지로 해석될 수 있다. 대신 "users 테이블에 editable 불리언 필드를 추가하고, /api/users/:id 엔드포인트로 노출한 뒤, 그 필드에 따라 edit 버튼 컴포넌트를 조건부로 렌더링하라"처럼 구체적으로 적으면 테스트가 가능하고 환각과 오류의 여지가 줄어든다. 여기에 어떤 파일에 추가할지, 어떤 코드를 참고·리팩터링할지 컨텍스트를 덧붙이고, 필요하면 스크린샷 이미지도 올린다. 또한 모델을 자동 선택에 맡기지 말고 작업에 맞게 지정하며, 대화를 짧고 집중되게 유지한다. 대화 히스토리가 매번 컨텍스트로 붙기 때문에 길수록 비용이 늘기 때문이다.

워크플로우는 실제 소프트웨어 개발 스프린트처럼 다룬다. 작고 반복적이며 테스트 가능한 단위로 쪼갠다. 보통은 '계획 먼저'다. 평문으로 원하는 기능을 설명하고, 데이터 흐름·핵심 함수·잠재적 난관·다른 컴포넌트와의 통합을 고려한 상세 구현 계획을 먼저 요청하되 코드는 아직 쓰지 말라고 한다. 계획을 검토한 뒤 "이 계획대로 구현하되 특정 파일만 수정, 새 의존성 금지, 기존 필터 보존" 같은 제약을 명시한다. 모호한 부분이 있으면 추측하지 말고 트레이드오프가 담긴 두 가지 선택지를 내놓게 한다.

코드가 돌아오면 주니어 개발자와 페어 프로그래밍하듯 리뷰한다. 맹신하지 말고 "왜 이 패턴을 골랐는지, 에러 케이스는 무엇인지, 성능에 어떤 영향이 있는지"를 묻는다. 직접 코드를 들여다보고 고치는 것을 두려워하지 말며, 필요하면 AI에게 그 변경에 맞춰 리팩터링하게 한다. 핵심은 이것이 위임이 아니라 협업이라는 점이다.

주요 인사이트

• 글로벌 규칙(코딩 표준·선호 라이브러리·테스트 철학)과 프로젝트 규칙(기술 스택·DB 스키마·API 패턴)을 나눠 두면 매 프롬프트에 같은 지시를 반복하지 않아도 된다.
• "버튼 토글되게 해줘" 같은 모호한 지시 대신, 테이블 필드 추가·API 노출·조건부 렌더처럼 구체적으로 적으면 환각과 오류 여지가 준다.
• 모델을 대화 중간에 함부로 바꾸면 캐시가 넘어가지 않아 요청과 비용이 늘어난다. 다만 계획용 모델과 코딩용 모델을 구분하는 것은 합리적이다.
• 코딩 전 '코드는 아직 쓰지 말고 상세 구현 계획부터' 요청하고, 모호한 부분은 추측 대신 트레이드오프가 담긴 두 옵션을 받아 고르면 실수가 준다.
• AI 코드를 맹신하지 말고 "왜 이 패턴인가, 에러 케이스는, 성능 영향은"을 물으며 주니어를 리뷰하듯 검토하라.

자주 묻는 질문

관련 AI 소식