바이브코딩, 빠르게 만드는 것보다 중요한 것

AI에게 코드를 잘 만들게 하는 가장 좋은 방법은 화려한 프롬프트가 아니라 “어떻게 작업해야 하는지”를 먼저 알려주는 것입니다. 특히 기존 홈페이지나 운영 중인 프로그램을 수정할 때는 AI가 새로운 코드를 만드는 능력보다 기존 기능을 해치지 않는 능력이 더 중요합니다.

1. 첫 번째 규칙: 반드시 최신 파일을 기준으로 작업하기

같은 파일을 여러 번 수정하다 보면 이전 버전과 현재 버전이 섞이기 쉽습니다. AI에게 과거 파일을 전달한 상태에서 새 기능을 요청하면 이미 수정된 내용을 다시 없애거나 예전 구조로 되돌릴 수 있습니다.

작업 시작 전에 “지금 전달하는 파일이 최신 기준본이며, 이전 코드로 되돌리지 않는다”는 기준을 명확히 하고, 변경 작업도 그 파일에서만 시작하는 것이 좋습니다.

2. 두 번째 규칙: 수정 범위를 파일과 기능 단위로 지정하기

“디자인을 조금 수정해줘”보다 “이 페이지의 이 섹션과 관련 CSS만 수정하고, 헤더·푸터·공통 JS는 변경하지 않는다”처럼 범위를 구체적으로 알려주는 편이 안전합니다.

수정 범위를 좁히면 AI가 불필요한 리팩토링이나 전체 재작성으로 문제를 키우는 것을 막을 수 있습니다. 파일 단위, 함수 단위, 화면 단위 중 가능한 수준까지 범위를 지정하는 것이 좋습니다.

3. 세 번째 규칙: 기존 정상 기능을 보존 대상으로 선언하기

개발에서는 “새 기능이 된다”만큼 “기존 기능이 계속 된다”가 중요합니다. 로그인, 검색, 저장, 수정, 삭제, 권한, 모바일 반응형처럼 이미 정상 동작하는 기능을 보존 대상으로 명시해야 합니다.

특히 공통 모듈을 수정할 때는 영향받을 수 있는 기능을 먼저 나열하고, 변경 후 다시 확인하도록 요구하는 것이 좋습니다.

4. 네 번째 규칙: 새로 만들기 전에 기존 구조를 먼저 분석하기

AI가 기존 함수나 컴포넌트가 있는지 확인하지 않고 비슷한 코드를 새로 만들면 중복이 생깁니다. 따라서 “새 함수 작성 전 기존 구현을 먼저 찾고 재사용 가능 여부를 확인한다”는 규칙이 유용합니다.

이 원칙은 CSS에도 적용됩니다. 새 클래스를 계속 추가하기보다 현재 선택자와 공통 스타일을 확인한 뒤 최소한의 변경으로 처리하는 편이 유지보수에 유리합니다.

5. 다섯 번째 규칙: 예외와 실패 상황까지 처리하기

정상 입력만 기준으로 만든 기능은 실제 운영에서 쉽게 깨집니다. 빈 값, 중복 데이터, 권한 없는 접근, 네트워크 실패, DB 저장 실패, 파일 업로드 오류 같은 예외 상황을 함께 정의해야 합니다.

AI에게 “정상 처리뿐 아니라 실패 시 사용자 메시지와 복구 가능한 흐름도 포함한다”고 알려주면 운영 환경에서 훨씬 안정적인 결과를 얻을 수 있습니다.

6. 여섯 번째 규칙: 변경 후 검증 항목을 미리 정하기

작업이 끝난 뒤 무엇을 확인할지 정하는 것이 아니라 시작 전에 완료 조건을 정하는 것이 좋습니다. 예를 들어 “PC·모바일에서 정상 노출, 저장 후 재조회 가능, 기존 검색 기능 정상, PHP 오류 없음”처럼 확인 기준을 명확히 합니다.

이렇게 하면 AI도 무엇을 완료로 판단해야 하는지 알 수 있고, 사람도 결과를 빠르게 검토할 수 있습니다.

7. 실무에서 바로 쓰는 기본 지시문

이 정도의 작업 규칙을 프로젝트 시작 시 고정해두면 매번 같은 내용을 길게 설명하지 않아도 되고, AI와의 개발 작업도 훨씬 일관되게 진행할 수 있습니다.