[5회] 바이브 코딩 실패 사례와 예방 전략

AI가 만든 코드를 믿기 전에 반드시 확인해야 할 것들

바이브 코딩은 개발 속도를 크게 높여줍니다.

아이디어를 빠르게 화면으로 만들 수 있고, 오류 수정도 빠르고, 문서 작성도 쉬워집니다.
특히 MAUI 앱, C# WinForms, Python 자동화, MES Lite, ERP 보완 시스템처럼 실무형 프로그램을 만들 때 큰 도움이 됩니다.

하지만 좋은 도구일수록 잘못 쓰면 위험도 커집니다.

AI가 만든 코드는 그럴듯해 보입니다.
파일 이름도 맞는 것 같고, 문법도 맞는 것 같고, 설명도 그럴듯합니다.

하지만 실제로 실행해 보면 오류가 나거나, 기존 기능이 사라지거나, DB 저장 방식이 틀리거나, 보안상 위험한 코드가 들어갈 수 있습니다.

이번 글에서는 바이브 코딩에서 자주 발생하는 실패 사례와 예방 방법을 정리하겠습니다.

1. 실패 사례 1: AI가 기존 기능을 지워버리는 경우

가장 흔한 문제입니다.

기존 MainPage.xaml에 여러 기능이 있었는데, AI에게 새 화면을 만들어 달라고 했더니 기존 기능을 모두 지우고 새 화면만 만들어 주는 경우가 있습니다.

C# WinForms에서도 마찬가지입니다.

기존 버튼, 이벤트, 그리드, 입력 필드가 있었는데 AI가 전체 파일을 다시 작성하면서 일부 기능을 삭제해 버릴 수 있습니다.

예방 방법은 간단합니다.

요청할 때 반드시 이렇게 말해야 합니다.

기존 기능은 삭제하지 말고 유지해줘.
새 기능에 필요한 부분만 추가해줘.
수정 전후 변경 내용을 요약해줘.

또는 더 구체적으로 말합니다.

MainPage.xaml의 기존 하단 탭 구조는 유지하고, 홈 화면 중앙에 환기 추천 카드만 추가해줘.
기존 API 호출 로직은 변경하지 마.

AI에게 “유지할 것”과 “변경할 것”을 명확히 알려줘야 합니다.

2. 실패 사례 2: 네임스페이스와 클래스명이 바뀌는 경우

MAUI, WPF, WinForms에서는 파일 간 연결이 중요합니다.

예를 들어 MAUI의 MainPage.xaml에는 다음과 같은 정보가 있습니다.

x:Class="MyApp.MainPage"

그리고 MainPage.xaml.cs에는 다음과 같이 되어 있어야 합니다.

namespace MyApp;

public partial class MainPage : ContentPage
{
}

그런데 AI가 코드를 만들면서 namespace를 임의로 바꾸면 InitializeComponent 오류가 발생할 수 있습니다.

예방하려면 이렇게 요청합니다.

기존 네임스페이스와 클래스명은 절대 변경하지 말아줘.
x:Class와 code-behind의 namespace/class 연결을 유지해줘.

파일을 붙여넣은 후에는 반드시 x와 namespace가 일치하는지 확인해야 합니다.

3. 실패 사례 3: 빌드는 되지만 업무 로직이 틀린 경우

AI가 만든 코드는 문법적으로 맞을 수 있습니다.
하지만 업무적으로는 틀릴 수 있습니다.

예를 들어 재고 계산에서 입고는 더하고 출고는 빼야 합니다.
그런데 AI가 이동, 조정, 반품, 생산투입 같은 업무 구분을 제대로 이해하지 못하면 현재고가 틀어질 수 있습니다.

MES나 ERP에서는 이런 문제가 매우 위험합니다.

빌드는 성공했는데 재고가 틀리면 실제 업무에 큰 문제가 생깁니다.

예방 방법은 업무 규칙을 명확히 문서화하는 것입니다.

예를 들어 DB_SCHEMA.md 또는 BUSINESS_RULES.md에 다음처럼 작성합니다.

# 재고 수불 규칙

- IN: 입고, 재고 증가
- OUT: 출고, 재고 감소
- PROD_IN: 생산입고, 재고 증가
- PROD_OUT: 생산투입, 재고 감소
- MOVE: 창고 이동, 전체 재고 증감 없음
- ADJ_PLUS: 재고조정 증가
- ADJ_MINUS: 재고조정 감소

현재고 계산 시 MOVE는 전체 합계에는 영향을 주지 않는다.

그리고 AI에게 이렇게 요청합니다.

BUSINESS_RULES.md의 재고 수불 규칙을 반드시 지켜서 SQL을 작성해줘.

업무 로직은 AI가 추측하게 두면 안 됩니다.

4. 실패 사례 4: SQL을 문자열 결합으로 작성하는 경우

AI가 빠르게 코드를 만들 때 다음처럼 SQL을 작성할 수 있습니다.

string sql = "SELECT * FROM item WHERE item_code = '" + itemCode + "'";

이 방식은 위험합니다.

사용자 입력값이 SQL에 직접 들어가면 SQL Injection 문제가 생길 수 있습니다.
또한 작은따옴표 같은 특수문자가 들어가면 오류가 날 수 있습니다.

예방하려면 반드시 파라미터 바인딩을 요구해야 합니다.

모든 SQL은 문자열 결합을 사용하지 말고 파라미터 바인딩으로 작성해줘.

좋은 방식은 다음과 같습니다.

string sql = "SELECT * FROM item WHERE item_code = @itemCode";
cmd.Parameters.AddWithValue("@itemCode", itemCode);

DB 관련 바이브 코딩에서는 이 원칙을 반드시 지켜야 합니다.

5. 실패 사례 5: 운영 DB를 대상으로 테스트하는 경우

AI가 만든 코드를 테스트한다고 운영 DB에 바로 연결하면 위험합니다.

잘못된 INSERT, UPDATE, DELETE가 실행될 수 있습니다.
특히 DELETE나 UPDATE에 WHERE 조건이 빠지면 전체 데이터가 변경될 수 있습니다.

예방 방법은 명확합니다.

개발 DB
테스트 DB
운영 DB

이 세 가지를 구분해야 합니다.

AI에게도 이렇게 요청해야 합니다.

테스트 DB 기준으로만 동작하도록 작성해줘.
운영 DB 접속정보는 코드에 포함하지 마.
DELETE SQL은 작성하지 말고 삭제 여부만 use_yn으로 변경하는 방식으로 처리해줘.

운영 DB는 바이브 코딩 실험 대상이 아닙니다.

6. 실패 사례 6: API Key와 비밀번호를 코드에 넣는 경우

AI가 예제 코드를 만들 때 API Key나 DB 비밀번호를 코드에 직접 넣는 경우가 있습니다.

string password = "1234";
string apiKey = "abcd1234";

이런 코드는 위험합니다.

소스가 유출되면 DB나 API가 노출될 수 있습니다.
GitHub에 올리면 더 큰 문제가 됩니다.

예방 방법은 다음과 같습니다.

비밀번호는 환경변수 사용
appsettings.json 사용
Secret Manager 사용
배포 환경별 설정 분리
.gitignore에 민감 파일 제외

AI에게는 이렇게 요청합니다.

DB 비밀번호와 API Key는 코드에 직접 작성하지 말고 설정 파일 또는 환경변수에서 읽도록 작성해줘.
예제 값은 placeholder로만 표시해줘.

7. 실패 사례 7: 필요 없는 패키지를 계속 추가하는 경우

AI는 문제를 해결하기 위해 외부 라이브러리를 추가하려는 경향이 있습니다.

작은 기능 하나를 위해 NuGet 패키지를 여러 개 추가하거나, 프로젝트에 맞지 않는 라이브러리를 추천할 수 있습니다.

그 결과 프로젝트가 무거워지고, 빌드 오류가 늘어나고, 보안 취약점이 생길 수 있습니다.

예방하려면 이렇게 요청합니다.

가능하면 기존 .NET 기본 기능과 현재 프로젝트에 설치된 패키지만 사용해줘.
새 NuGet 패키지가 꼭 필요하면 이유와 패키지명을 먼저 설명해줘.

패키지 추가는 개발자가 승인하는 방식이 좋습니다.

8. 실패 사례 8: 화면은 예쁘지만 사용성이 떨어지는 경우

AI가 만든 화면이 겉보기에는 예쁠 수 있습니다.

하지만 실제 현장에서는 불편할 수 있습니다.

버튼이 너무 작다.
입력 필드가 너무 많다.
작업자가 장갑을 끼고 누르기 어렵다.
태블릿 화면에서 스크롤이 불편하다.
오류 메시지가 사용자가 이해하기 어렵다.
현장에서는 잘 안 쓰는 항목이 앞에 배치되어 있다.

특히 제조 현장용 앱이나 MES 화면에서는 예쁜 디자인보다 사용성이 중요합니다.

예방하려면 DESIGN_GUIDE.md에 사용 기준을 적어야 합니다.

# DESIGN_GUIDE.md

- 현장 작업자는 10인치 태블릿 사용을 기준으로 한다.
- 주요 버튼 높이는 최소 48dp 이상으로 한다.
- 자주 사용하는 버튼은 화면 하단 또는 우측에 고정한다.
- 필수 입력만 먼저 보이게 한다.
- 오류 메시지는 개발 용어를 제외하고 한글로 표시한다.
- 입력 필드는 긴 필드 기준으로 좌우 정렬을 맞춘다.

AI에게는 이렇게 요청합니다.

DESIGN_GUIDE.md 기준으로 현장 작업자가 태블릿에서 쉽게 사용할 수 있게 화면을 구성해줘.

9. 실패 사례 9: 테스트 없이 “완료”라고 판단하는 경우

AI가 코드를 만들면 설명도 잘합니다.

“저장 기능을 구현했습니다.”
“오류 처리를 추가했습니다.”
“테스트 방법은 다음과 같습니다.”

하지만 실제 테스트를 하지 않으면 완료가 아닙니다.

개발자는 반드시 직접 확인해야 합니다.

빌드 테스트
실행 테스트
화면 테스트
버튼 테스트
DB 저장 테스트
오류 상황 테스트
권한 테스트
실제 기기 테스트

특히 Android 앱은 Emulator에서 잘 되더라도 실제 폰에서 문제가 생길 수 있습니다.

APK 설치
권한 요청
네트워크 연결
GPS
카메라
알림
절전모드
백그라운드 동작

이런 항목은 실제 폰에서 확인해야 합니다.

10. 실패 사례 10: 구글플레이 배포 준비 부족

앱은 개발만 끝나면 바로 출시되는 것이 아닙니다.

Google Play에 올리려면 준비할 것이 많습니다.

패키지명
앱 이름
앱 아이콘
스크린샷
개인정보 처리방침
데이터 보안 항목
콘텐츠 등급
앱 설명
AAB 파일
서명키
버전코드
테스트 계정
비공개 테스트
정책 검토

바이브 코딩으로 앱을 빠르게 만들었더라도 배포 준비가 부족하면 Play Console에서 막힐 수 있습니다.

예방하려면 개발 초기에 배포 체크리스트를 만들어야 합니다.

# RELEASE_CHECKLIST.md

- ApplicationId 확정
- 앱 이름 확정
- 앱 아이콘 준비
- 스크린샷 준비
- 개인정보 처리방침 URL 준비
- 데이터 보안 항목 검토
- 권한 사용 목적 정리
- AAB 생성 테스트
- 버전코드 증가 확인
- 비공개 테스트 테스터 목록 준비
- 출시노트 작성

앱 개발은 코드 작성으로 끝나지 않습니다.
배포와 테스트까지 포함해야 완성입니다.

11. 실패를 줄이는 문서 세트

바이브 코딩 프로젝트에는 다음 문서를 추천합니다.

AGENTS.md
PROJECT_RULES.md
CODING_GUIDE.md
DESIGN_GUIDE.md
DB_SCHEMA.md
BUSINESS_RULES.md
API_SPEC.md
TEST_SCENARIO.md
SECURITY_GUIDE.md
BUILD_GUIDE.md
RELEASE_CHECKLIST.md

처음부터 모두 완벽하게 만들 필요는 없습니다.

하지만 최소한 다음 5개는 강력히 추천합니다.

AGENTS.md
CODING_GUIDE.md
DB_SCHEMA.md
DESIGN_GUIDE.md
TEST_SCENARIO.md

이 문서들이 있으면 AI가 프로젝트를 훨씬 안정적으로 이해합니다.

12. 바이브 코딩 안전 원칙 10가지

첫째, AI에게 한 번에 너무 큰 일을 맡기지 않습니다.

둘째, 작업 전 소스를 백업합니다.

셋째, 수정할 파일 범위를 지정합니다.

넷째, 기존 기능 유지 조건을 명확히 합니다.

다섯째, DB 작업은 테스트 DB에서만 진행합니다.

여섯째, SQL은 파라미터 바인딩을 사용합니다.

일곱째, 비밀번호와 API Key를 코드에 넣지 않습니다.

여덟째, AI가 만든 코드는 반드시 diff로 확인합니다.

아홉째, 빌드와 실행 테스트를 직접 합니다.

열째, 운영 반영 전에는 사용자 테스트를 거칩니다.

13. 좋은 바이브 코딩은 사람의 기준에서 시작된다

AI가 좋은 코드를 만들려면 기준이 있어야 합니다.

좋은 기준은 사람이 만듭니다.

어떤 화면이 사용하기 좋은지
어떤 DB 구조가 유지보수하기 좋은지
어떤 오류 메시지가 사용자에게 친절한지
어떤 기능이 업무에 꼭 필요한지
어떤 코드는 보안상 위험한지
어떤 테스트를 통과해야 완료인지

이 판단은 AI가 아니라 개발자와 업무 담당자가 해야 합니다.

AI는 빠른 실행 도구입니다.
하지만 방향을 잡는 것은 사람입니다.

마무리

바이브 코딩은 매우 강력합니다.

하지만 무조건 빠르게 만드는 것이 목적이 되어서는 안 됩니다.

빠르게 만들되,
망가지지 않게 만들고,
테스트할 수 있게 만들고,
운영할 수 있게 만들고,
유지보수할 수 있게 만들어야 합니다.

AI가 만든 코드는 시작점입니다.
최종 결과물은 사람의 검토와 테스트를 거쳐 완성됩니다.

바이브 코딩의 성공 공식은 간단합니다.

작게 지시하고,
문서로 기준을 주고,
변경 내용을 확인하고,
테스트로 검증하고,
운영 기준에 맞게 정리한다.

이 원칙을 지키면 바이브 코딩은 단순한 유행이 아니라, 실제 개발 생산성을 높이는 강력한 개발 방식이 됩니다.