바이브코딩의 다음 단계는 코드 생성이 아니라 퍼징이다
AI가 코드를 빠르게 써줄수록 사람이 해야 할 일은 코드의 양을 늘리는 것이 아니라 코드가 무너지는 경계를 찾는 것이다. 퍼징은 그 경계를 값싸고 반복적으로 탐색하는 방법이다.
TL;DR
- AI 코딩의 병목은 구현 속도에서 입력과 실패 검증으로 이동한다.
- 작은 퍼징 하네스도 사람이 떠올리기 어려운 경계 조건을 탐색할 수 있다.
- 좋은 AI 유틸은 결과만 내놓지 않고 실패 입력과 재현 경로를 함께 남긴다.
왜 지금 중요한가
코드 생성 비용이 내려가면 “무엇을 만들 수 있는가”보다 “만든 것을 얼마나 빨리 의심할 수 있는가”가 중요해진다. 정상적인 예시 몇 개를 사람이 확인하는 방식은 생성 속도를 따라가기 어렵다.
파일 파서, 변환기, API 입력처럼 경계 조건이 많은 소프트웨어는 정상 입력보다 이상한 입력에서 문제가 드러난다. 검증이 수동 확인에 머물면 빠른 생성은 곧 품질 부채가 된다.
핵심 흐름: 생성 → 변형 → 관찰 → 재현
퍼징은 복잡한 마법이라기보다 입력을 체계적으로 바꾸고 프로그램의 반응을 관찰하는 루프다.
- 생성 — 작은 프로그램 또는 테스트 하네스를 만든다.
- 변형 — 길이, 형식, 경계값, 손상된 바이트를 바꾼다.
- 관찰 — 충돌, 예외, 비정상 종료, 결과 불일치를 기록한다.
- 재현 — 문제를 일으킨 최소 입력과 실행 명령을 보존한다.
AI는 초안과 변형 규칙을 빠르게 만들 수 있다. 하지만 어떤 실패가 실제 결함인지, 영향 범위가 어디까지인지 판단하는 일은 별도의 검증 작업이다.
실제 사례 / 신호
GeekNews는 바이브코딩으로 만든 퍼저가 FFmpeg의 Sony PS2 VPK 디먹서에서 0 나누기 버그를 발견한 사례를 소개했다. 원문에 따르면 21바이트 입력으로 재현되는 결함이었고, 악성 파일이나 스트림을 여는 애플리케이션이 충돌할 수 있었다.
이 사례의 핵심은 AI가 완성품을 만들었다는 데 있지 않다. 작은 하네스가 입력 공간을 넓혀 사람이 정상적으로 떠올리기 어려운 경계 조건을 발견했다는 데 있다. 생성 모델의 역할이 코드 작성에서 테스트 공간 확장으로 넓어진다.
또 다른 보도는 취약점 수정 정보가 공개된 뒤 공격 탐색과 코드 생성이 매우 짧은 시간 안에 이뤄질 수 있다는 사례를 전한다. 개별 사례를 일반화할 수는 없지만, 공개·패치·검증의 순서를 제품 운영 계약으로 다뤄야 한다는 경고로 읽을 수 있다.
실전 활용 팁: 먼저 로컬 입력 계약을 만든다
처음부터 인터넷에 연결된 자동화 도구를 만들 필요는 없다. 로컬 샘플만으로도 다음 계약을 시작할 수 있다.
- 정상 파일 3개와 의도적으로 손상한 파일 3개를 준비한다.
- 입력 크기와 실행 시간을 제한한다.
- 예외·종료 코드·출력 해시를 기록한다.
- 실패한 입력을 별도 폴더에 복사한다.
- 같은 명령으로 다른 사람이 재현할 수 있게 한다.
이 계약은 파일 유틸뿐 아니라 SQL 파서, 문서 변환기, 이미지 리사이저, API payload 검증기에도 적용할 수 있다.
바로 해볼 실험
- 허가된 로컬 파일 포맷을 하나 고른다.
- AI에게 정상 입력을 처리하는 최소 프로그램과 입력 변형 테스트를 각각 요청한다.
- 변형 횟수보다 실패의 재현 가능성을 측정한다.
input,command,exit code,stderr,hash를 한 JSON에 저장한다.- 30분 안에 발견한 문제를 사람이 분류한다.
첫 번째 KPI는 발견한 버그 개수가 아니다. 실패를 재현하는 데 걸리는 시간과 오탐을 버리는 데 걸리는 시간이다.
리스크 / 반론
퍼징은 모든 품질 문제를 해결하지 않는다. 의미적으로 잘못된 결과, 인증·권한 설계, 성능 저하, 사용자 경험 문제는 입력 변형만으로 잡히지 않을 수 있다.
또한 보안 관련 도구는 대상과 권한을 잘못 설정하면 안전 문제가 된다. 범위를 로컬·허가된 샘플로 제한하고, 실행 시간과 파일 크기에 상한을 둬야 한다. 데모용 검증과 외부 시스템에 대한 실행 권한도 분리해야 한다.
결론
바이브코딩은 개발자를 없애지 않는다. 개발자의 업무를 코드 작성에서 가능한 실패를 설계하고 검증하는 일로 옮긴다.
다음에 AI로 작은 유틸을 만들 때는 기능 버튼 하나를 더 넣기 전에 질문해 보자. 이 결과를 어떤 입력으로 깨뜨릴 수 있고, 실패를 다른 사람이 다시 실행할 수 있는가? 그 질문에 답하는 순간 바이브코딩은 데모를 넘어 제품 개발 루프가 된다.