AI 에이전트가 짜 준 스크립트가 테스트를 전부 초록으로 통과해서 그대로 돌려 두었는데 며칠 뒤 결과를 열어 보니 숫자가 처음부터 틀려 있었던 경험이 있으신가요?
안녕하세요? 정리하는 개발자 워니즈입니다. 이번 시간에는 필자가 바이브 코딩으로 블로그 운영 도구를 맡기다가 2026년 9월 25일과 26일 이틀 사이에 셀프테스트는 통과했는데 실데이터에서 틀린 도구 세 개를 만난 기록과 그 뒤로 검증 방식을 어떻게 바꿨는지를 정리해보려고 합니다.
한 줄 요약 바이브 코딩으로 만든 도구의 셀프테스트 통과는 코드가 자기 가정대로 움직인다는 뜻일 뿐이었고 세 번 모두 틀린 것은 코드가 아니라 가정이었습니다. 그래서 테스트를 일부러 망가뜨려 보는 변이 테스트와 만든 직후 실데이터 1회 실행과 관측 못 하는 것은 판별 불가로 두기 세 가지를 완료 조건에 넣었습니다.
- 무엇이 초록이었나 서치콘솔 원장 도구와 광고 슬롯 점검 도구와 검색 수요 게이트 세 개가 전부 셀프테스트를 통과했습니다
- 실데이터는 뭐라 했나 원장은 글 261편 중 6편만 서치콘솔 표와 맞았고 광고 도구의 렌더 실패 판정은 브라우저에서 반증됐으며 수요 게이트를 넘긴 글은 실제 주제 검색어의 파생어가 2개뿐이었습니다
- 그래서 바꾼 것 바이브 코딩으로 받은 도구는 테스트가 망가진 코드를 잡는지 먼저 보고 만든 직후 실데이터로 돌려 매칭률 같은 숫자를 눈으로 보며 도구가 볼 수 없는 것은 단정하지 않습니다
목차
- 바이브 코딩으로 무엇을 맡겼나
- 셀프테스트 GATE_OK 는 무엇을 보장하나요?
- 사례 1 서치콘솔 원장은 261편 중 6편만 맞았다
- 사례 2 광고 점검 도구는 산술만으로 렌더 실패를 단정했다
- 사례 3 수요 게이트는 넓은 키워드 하나로 통과됐다
- 세 사례에서 테스트는 왜 같은 식으로 틀렸을까요?
- 바이브 코딩 검증 체크리스트 3가지
- 이 확인에 드는 비용은 얼마나 되나요?
- 이렇게 확인해도 안 되는 것
- 정리와 필자의 결론
1. 바이브 코딩으로 무엇을 맡겼나
바이브 코딩은 코드를 한 줄씩 읽기보다 AI 에게 원하는 결과를 말로 설명하고 나온 코드를 돌려 보며 방향을 잡는 방식을 가리키는 말입니다. 위키백과 정리로는 안드레 카파시가 2025년 초에 붙인 이름으로 알려져 있습니다(
| 도구 | 하는 일 | 초록 신호 |
|---|---|---|
| post-ledger.py | 서치콘솔 실적 표를 긁어 글별 노출과 순위를 원장에 쌓는다 | 셀프테스트 GATE_OK |
| ad-inventory.py | 페이지 HTML 의 광고 슬롯을 세고 실측 노출과 견줘 원인을 판정한다 | 셀프테스트 통과 |
| 수요 게이트 | 구글 자동완성 파생 검색어가 20개 미만이면 발행을 막는다 | 파생어 65개로 발행 허용 |
에이전트에게 혼자 일을 맡기면 늘어나는 것이 산출물이 아니라 검증이라는 이야기는 DevOps 카테고리의 AI 에이전트로 혼자 일하기, 늘어난 건 산출물이 아니라 검증이었습니다 에서 한 번 적었는데요, 이번 기록은 그 검증이 초록불을 내고도 틀릴 수 있다는 쪽의 이야기입니다.
바이브 코딩을 깎아내리려는 글은 아닙니다. 세 도구는 지금도 에이전트가 만든 그대로 돌고 있고 달라진 것은 완료로 치는 기준 하나뿐이라서 맡기되 어디를 확인하면 되는지를 남기는 쪽에 가깝습니다.
2. 셀프테스트 GATE_OK 는 무엇을 보장하나요?
GATE_OK 는 코드가 테스트를 만든 쪽의 가정대로 움직인다는 것까지만 보장하고 그 가정이 맞는지는 보장하지 않습니다. 바이브 코딩에서 셀프테스트는 보통 코드를 쓴 에이전트가 픽스처(테스트용 입력)까지 함께 만드는데, 입력이 어떻게 생겼을지에 대한 가정이 코드와 테스트 양쪽에 똑같이 들어가 있어서 가정이 틀리면 둘이 사이좋게 같이 틀립니다.
이 구조를 모르고 초록불을 보면 틀린 믿음이 오히려 단단해집니다. 테스트가 통과했다는 사실이 확인을 마쳤다는 느낌을 주지만 실제로 확인한 것은 코드와 테스트가 서로 모순되지 않는다는 데까지이기 때문입니다.
| 테스트가 확인하는 것 | 테스트가 확인하지 못하는 것 |
|---|---|
| 내가 만든 입력에서 코드가 기대값을 낸다 | 실제 입력이 내가 만든 입력과 같은 모양이다 |
| 분기와 계산이 의도대로 동작한다 | 판정 기준이 맞는 질문을 하고 있다 |
| 예전에 통과하던 경우가 지금도 통과한다 | 도구가 관측할 수 없는 영역의 결론이 맞다 |
AI 가 완료했다고 보고한 것을 그대로 믿었다가 게재 실패를 놓친 일은 AI 완료 보고를 그대로 믿으면 생기는 일 에서 다뤘습니다. 셀프테스트 통과는 말로 한 완료 보고보다 한 단계 믿음직해 보이는 신호라서 바이브 코딩에서는 오히려 더 조심해야 할 초록불이라고 생각합니다.
3. 사례 1 서치콘솔 원장은 261편 중 6편만 맞았다
무엇이 초록이었나. post-ledger.py 는 서치콘솔 실적 표를 브라우저로 긁어서 표 첫 칸의 페이지 URL 을 키로 삼고 블로그 글 목록과 맞춰 글별 노출과 순위를 원장에 쌓는 도구입니다. 2026-09-25 에 에이전트가 함께 만든 셀프테스트는 URL 이 깔끔하게 들어 있는 픽스처로 매칭과 합산을 확인했고 결과는 GATE_OK 였습니다.
실데이터가 뭐라 했나. 실제로 한 번 돌리자 원장에 등록된 글 261편 가운데 서치콘솔 표와 매칭된 글이 6편뿐이었습니다. 노출이 있는 글이 6편밖에 없을 리는 없어서 첫 칸에 실제로 무엇이 들어왔는지 찍어 보니 URL 뒤에 표 행에 마우스를 올리면 뜨는 버튼 문구가 붙어 있었습니다.
직접 확인 1. 아래가 그날 Aside 브라우저로 연 서치콘솔 실적 표에서 페이지 행 첫 칸의 innerText 를 그대로 옮긴 것이고, 기록을 남길 때 도메인과 날짜 부분은 줄여 적었습니다.
https://.../mcp-server-with-cusor-ai/ 클립보드에 URL 복사 새 탭에서 열기 URL 검사왜 테스트가 못 잡았나. innerText 는 요소와 그 자손이 렌더된 텍스트를 돌려주는 속성이라서 셀 안에 들어 있는 버튼의 글자까지 함께 딸려 옵니다(MDN HTMLElement.innerText). 픽스처는 에이전트가 상상한 깨끗한 표였고 실제 서치콘솔 표는 그렇지 않았으니 테스트는 몇 번을 돌려도 통과할 수밖에 없었습니다.
평소에는 눈에 띄지 않던 버튼 문구가 왜 innerText 에 들어왔는지 CSS 수준의 원인은 이번에 확인하지 않았고, 모든 행이 오염됐을 텐데 6편은 왜 맞았는지도 따로 들여다보지 않아서 두 가지 모두 미확인으로 남깁니다. 필자가 확인한 것은 실제 출력에 그 문구가 붙어 있었다는 데까지입니다.
고친 방법. 셀 텍스트를 통째로 키로 쓰지 않고 그 안에서 URL 만 뽑아 정규화하는 키 정리 함수를 넣었습니다. 원리는 아래 한 줄로 재현할 수 있는데 macOS 27.0 과 Python 3.14.7 에서 돌리면 https://blog.wonizz.com/2025/09/12/mcp-server-with-cusor-ai/ 한 줄만 출력됩니다.
python3 -c "import re; raw='https://blog.wonizz.com/2025/09/12/mcp-server-with-cusor-ai/ 클립보드에 URL 복사 새 탭에서 열기 URL 검사'; print(re.search(r'https?://\S+', raw).group(0))"직접 확인 2. 키를 정리한 뒤 같은 원장을 다시 채우자 261편 중 100편이 서치콘솔 표와 이어졌습니다. 나머지 글은 3개월 창 안에 노출이 없어 표에 행 자체가 없는 경우라서 매칭률이 100%가 아닌 것은 정상 범위로 봤고, 셀프테스트 픽스처에도 버튼 문구가 붙은 실제 모양의 입력을 추가해 같은 오염이 다시 들어오면 테스트가 먼저 떨어지게 했습니다.
서치콘솔 데이터를 믿고 판단하는 일은 블로그운영 카테고리의 제 블로그 글 절반 이상이 구글 색인에 없었습니다 에서 색인 누락을 다룰 때도 나왔는데요, 그때는 사람이 표를 읽었고 이번에는 도구가 읽었다는 점만 다르고 표에 무엇이 실제로 들어 있는지부터 봐야 한다는 교훈은 같았습니다.
바이브 코딩으로 스크래퍼를 맡길 때 이 사례가 특히 아픈 이유는 입력이 남의 화면이라는 데 있습니다. 서치콘솔 화면을 설계한 쪽이 셀 안에 무엇을 넣을지는 필자도 에이전트도 정할 수 없으니 그 모양을 아는 방법은 실제로 한 번 긁어 보는 것밖에 없었습니다.
4. 사례 2 광고 점검 도구는 산술만으로 렌더 실패를 단정했다
무엇이 초록이었나. 같은 날 만든 ad-inventory.py 는 페이지 HTML 에서 명시 광고 슬롯을 세고 실측 광고 노출과 견줘 원인을 판정하는 도구였고 셀프테스트는 역시 통과했습니다. 실데이터로 돌리자 표본 18편의 페이지당 명시 슬롯이 3.67개이고 실측 노출이 페이지당 0.94개로 나왔는데, 도구는 앞의 숫자가 뒤의 2배를 넘는다는 산술 하나로 “원인 판정 렌더 실패”를 출력했습니다.
실데이터가 뭐라 했나. 브라우저로 실제 페이지를 열어 슬롯이 광고 iframe 으로 채워졌는지 세어 보니 렌더는 정상이었고 렌더 실패라는 판정은 그 자리에서 반증됐습니다.
직접 확인 3. Aside 브라우저로 연 긴 글에서는 6슬롯 중 5개가, 짧은 글에서는 7슬롯 전부가, 홈에서는 2슬롯 전부가 iframe 으로 채워져 있었습니다.
왜 테스트가 못 잡았나. 테스트는 계산이 맞는지를 봤고 계산은 실제로 맞았습니다. 틀린 것은 슬롯 수가 노출 수보다 많으면 렌더가 실패한 것이라는 해석이었고 HTML 만 읽는 도구는 브라우저에서 무슨 일이 일어나는지 볼 수 없으니 렌더를 판정할 자격이 처음부터 없었습니다.
고친 방법. 도구의 판정을 “판별 불가”로 바꾸고 이유를 함께 남기게 했습니다. HTML 만 보는 도구는 렌더를 단정할 수 없기 때문입니다. 원인은 그 뒤 광고 콘솔 보고서를 직접 읽어서 좁혔습니다. 28일 동안 페이지당 광고 요청은 2.47로 목표를 이미 넘었고, 손실은 두 단계였습니다. 게재되지 않은 요청이 167건, 게재됐지만 노출로 집계되지 않은 요청이 118건입니다. 슬롯이 모자란 것도 렌더가 깨진 것도 아니라 게재 단계의 문제였습니다. 도구가 판별 불가로 멈췄기 때문에 사람이 다음에 볼 곳을 알 수 있었습니다.
산술로 단정한 판정이 원장에 남으면 다음 주 자동화가 그 판정을 읽고 멀쩡한 슬롯을 고치러 갑니다. 관측하지 못한 것을 판별 불가로 적는 것은 모른다는 고백이 아니라 다음 작업이 엉뚱한 곳을 파지 않게 막는 장치였습니다.
이 사례는 바이브 코딩에서 흔히 떠올리는 버그와 모양이 조금 다른데, 코드가 틀린 값을 낸 것이 아니라 맞는 값을 두고 너무 많이 말한 경우였습니다. 이 도구는 숫자 두 개 사이에 원인 이야기를 붙였고 그래서 판정 문장을 쓰는 도구라면 그 문장의 근거가 도구가 실제로 본 것인지를 따로 확인해야 한다는 것을 이번에 배웠습니다.
5. 사례 3 수요 게이트는 넓은 키워드 하나로 통과됐다
무엇이 초록이었나. 이 블로그에는 글감의 검색 수요를 구글 자동완성으로 재서 파생 검색어가 20개 미만이면 발행을 막는 게이트가 있습니다. 2026-09-26 새벽 자동 제작에서 에이전트는 포커스 키워드를 리눅스 로 적었고, 파생어 65개로 게이트를 넘긴 리눅스 폴더 비교 글이 그날 아침 발행됐습니다.
실데이터가 뭐라 했나. 글이 실제로 답하는 검색어로 다시 재자 숫자가 전혀 달랐고 게이트가 막았어야 할 글이라는 것이 드러나서 그 글은 삭제했습니다.
직접 확인 4. 리눅스 폴더 비교 의 자동완성 파생어는 2개였고 구글 트렌드 12개월 평균은 0이었으며(같은 비교에서 리눅스 명령어 18.9, 2026-09-26 측정), 같은 날 잰 리눅스 diff 도 9개라서 하한 20에 못 미쳤습니다.
왜 테스트가 못 잡았나. 게이트는 frontmatter 에 적힌 키워드 하나만 쟀고 그 키워드가 글이 답하는 검색어인지는 누구도 보지 않았습니다. 게이트의 입력을 게이트를 통과하려는 쪽이 직접 적는 구조였으니 넓은 상위어를 적는 것만으로 어떤 주제든 지나갈 수 있었던 셈입니다.
고친 방법. 포커스 키워드는 글이 답하는 검색어여야 하고 넓은 상위어로 게이트를 넘기지 않는다는 문장을 자동 제작 지시문에 넣었습니다. 다만 이것은 규칙 문장이지 코드 게이트가 아니라서 온전히 막았다고 말하기는 이른데요, 규칙을 알려줘도 안 지켜지는 문제는 AI에게 규칙을 알려줬는데 안 지켜졌습니다 에서 이미 한 번 겪었습니다.
이 글의 포커스 키워드도 같은 기준으로 골랐습니다. 넓은 바이브 코딩 한 단어로 정하고 끝내지 않고 구글 자동완성 기본 목록에 바이브 코딩 현실 이 뜨는 것을 확인한 뒤 그 각도로 제목을 잡았습니다.
6. 세 사례에서 테스트는 왜 같은 식으로 틀렸을까요?
셋 다 코드가 아니라 입력이나 해석에 대한 가정이 틀렸고 그 가정을 코드와 테스트가 똑같이 품고 있었기 때문입니다. 바이브 코딩에서 이 겹침은 더 잘 생기는 것 같은데, 같은 에이전트가 같은 대화 안에서 코드와 테스트를 함께 만들면 가정을 의심해 줄 두 번째 시선이 없습니다.
| 사례 | 셀프테스트 결과 | 실데이터 결과 | 틀린 가정 | 잡은 방법 |
|---|---|---|---|---|
| 서치콘솔 원장 | GATE_OK | 261편 중 6편 매칭 | 표 첫 칸에는 URL 만 있다 | 실수집 뒤 매칭 수를 눈으로 봄 |
| 광고 점검 | 통과, 렌더 실패 판정 | 브라우저에서 슬롯 정상 렌더 | 슬롯이 노출보다 많으면 렌더 실패다 | 실제 페이지를 브라우저로 열어 봄 |
| 수요 게이트 | 파생어 65로 발행 허용 | 실제 주제 파생어 2, 트렌드 0 | 적힌 키워드가 글의 검색어다 | 글 주제 구로 다시 잼 |
표를 세로로 읽으면 공통점이 보입니다. 세 번 모두 실데이터가 잡았고 테스트 케이스를 몇 개 더 늘렸다고 해서 잡혔을 것 같지는 않습니다. 더 많은 테스트가 아니라 다른 종류의 확인이 필요했다는 것이 이 표에서 필자가 읽은 결론입니다.
틀린 가정의 모양도 셋이 조금씩 달랐습니다. 원장은 외부 시스템이 주는 입력의 모양을 잘못 짐작했고 광고 점검은 도구가 볼 수 없는 영역까지 결론을 넓혔으며 수요 게이트는 입력을 누가 적는지를 따지지 않았는데, 다음 절의 확인 세 가지도 이 셋에 하나씩 대응하도록 골랐습니다.
한 가지 덧붙이면 세 도구 모두 코드 리뷰로는 잡기 어려운 결함이었습니다. 원장의 매칭 코드도 광고 점검의 산술도 게이트의 비교문도 읽어 보면 멀쩡했고, 문제가 된 것은 코드 바깥에 있는 세상이 코드의 예상과 달랐다는 점이라서 바이브 코딩에서 코드를 더 꼼꼼히 읽는 것만으로는 같은 결함을 줄이기 어려울 것 같습니다.
7. 바이브 코딩 검증 체크리스트 3가지
세 사례 뒤로 필자는 에이전트가 만든 도구의 완료 조건에 아래 세 가지를 넣었고, 바이브 코딩으로 맡기는 양은 줄이지 않은 채 완료로 치는 기준만 바꿨습니다.
| 순서 | 확인 | 무엇을 막나 | 이번 사례 중 해당 |
|---|---|---|---|
| 1 | 변이 테스트로 테스트가 망가진 코드를 잡는지 본다 | 아무것도 확인하지 않는 테스트 | 테스트 자체의 품질 |
| 2 | 만든 직후 실데이터로 1회 돌리고 기대 수치를 눈으로 본다 | 입력 가정의 오류 | 사례 1, 사례 3 |
| 3 | 관측 못 하는 것은 판별 불가로 둔다 | 산술로 내린 단정 | 사례 2 |
변이 테스트로 테스트를 일부러 망가뜨려 본다
변이 테스트는 코드에 작은 결함을 일부러 심은 변이체를 만들고 테스트가 그 변이를 잡아 실패하는지 보는 방법입니다(위키백과 Mutation testing). 경계값 < 를 <= 로 바꾸거나 조건을 if False 로 바꿨는데도 테스트가 여전히 통과한다면 그 테스트는 그 줄을 사실상 확인하지 않고 있다는 뜻입니다.
수요 게이트처럼 20 미만을 막는 판정으로 재현해 보면 차이가 바로 보입니다. 아래는 원래 조건과 <= 로 바꾼 변이를 입력 5와 65와 20에 돌린 명령이고 macOS 27.0 과 Python 3.14.7 에서 실행한 출력을 그 아래에 붙였습니다.
python3 -c "gate=lambda n: n < 20; mutant=lambda n: n <= 20; [print(n, gate(n), mutant(n)) for n in (5, 65, 20)]"5 True True
65 False False
20 False True입력이 5와 65뿐인 테스트라면 원래 코드와 변이가 같은 답을 내니 변이가 살아남고 경계값 20을 넣어야 비로소 둘이 갈리는데요, 바이브 코딩으로 받은 테스트를 읽을 때 경계값이 입력에 들어 있는지부터 보는 이유가 여기에 있습니다. 9월 26일에 트렌드 수집 도구에 원천을 하나 더 붙일 때도 > 를 >= 로 바꾸기와 라벨 태그 제외 끄기와 카테고리 제한 끄기 세 변이를 셀프테스트가 전부 잡는 것을 보고 나서 완료로 쳤습니다.
손으로 변이를 넣는 대신 도구를 쓸 수도 있는데 자바에는 PIT 가 있고 자바스크립트와 C# 쪽에는 Stryker 가 있습니다. 필자의 스크립트는 작아서 아직 손으로 넣고 있고 이 도구들을 블로그 자동화에 붙여 보지는 않았습니다.
실데이터 1회로 만든 직후에 한 번 흘려 본다
변이 테스트만으로는 사례 1을 못 잡습니다. 픽스처가 실제와 다른 모양이면 변이를 아무리 넣어도 틀린 입력 위에서 잘 잡힐 뿐이라서 입력 가정을 확인하는 길은 실데이터를 한 번 흘려 보는 것밖에 없었습니다.
요령은 돌리기 전에 이 정도는 나와야 한다는 숫자를 먼저 적어 두는 것입니다. 사례 1에서는 글 261편 중 적어도 수십 편은 이어져야 한다는 감각이 있었기에 6이라는 숫자가 이상하게 보였고, 기대값이 없었다면 6편짜리 원장을 그대로 믿고 다음 단계로 넘어갔을 것 같습니다.
- 매칭률 두 목록을 잇는 도구라면 몇 퍼센트가 이어졌는지 보고 기대 범위와 견줘 봅니다
- 건수 수집 도구라면 행이 몇 개 들어왔는지 보고 0이나 1처럼 수상한 숫자가 아닌지 확인합니다
- 표본 한 줄 키로 쓰는 값 하나를 그대로 찍어서 공백이나 덧붙은 문구가 없는지 사람 눈으로 읽어 봅니다
실데이터를 한 번 흘려 보고 나면 그 입력을 픽스처로 떠서 셀프테스트에 넣어 두는 것까지를 한 묶음으로 칩니다. 사례 1에서 버튼 문구가 붙은 셀을 픽스처로 박아 둔 것처럼 한 번 만난 실제 모양을 테스트가 기억하게 하면 다음 수정에서 같은 오염이 되돌아와도 초록불이 먼저 꺼집니다.
판별 불가로 관측 못 하는 것은 단정하지 않는다
도구가 볼 수 있는 범위를 넘어서는 결론은 내지 않게 합니다. HTML 만 읽는 도구가 렌더를 말하거나 자동완성 숫자만 보는 게이트가 글과 검색어가 맞는지를 말하는 것이 이번에 본 범위 초과였습니다.
판별 불가에는 반드시 이유를 붙이게 했는데, 사례 2라면 HTML 에서 슬롯은 셌지만 렌더 여부는 브라우저 없이 볼 수 없다는 식으로 다음에 무엇을 확인해야 하는지가 이유 안에 들어 있어야 판정이 다음 행동으로 이어집니다.
에이전트에게 맡길 때는 어떻게 요청할까요?
세 확인을 사람이 매번 손으로 하면 바이브 코딩의 속도가 사라지니 요청 단계에서 에이전트에게 넘기는 방법이 있습니다. 도구를 맡기는 요청 끝에 붙일 수 있는 문장을 예로 들면 아래와 같고 문구는 상황에 맞게 바꿔 쓰면 됩니다.
- 셀프테스트를 만든 뒤 경계값과 조건을 바꾼 변이를 두세 개 넣어서 테스트가 전부 잡는지 보여 주세요
- 만든 직후 실데이터로 한 번 돌리고 매칭률이나 건수를 기대 범위와 함께 보고해 주세요
- 이 도구가 직접 볼 수 없는 것은 판정하지 말고 판별 불가와 그 이유로 남겨 주세요
다만 기대 범위만큼은 에이전트에게 정하게 두지 않고 사람이 먼저 적는 편이 맞다고 봅니다. 결과를 본 뒤에 정한 기대값은 그 결과에 맞춰지기 쉬워서 돌리기 전에 사람이 적어 두는 숫자 하나가 이 체크리스트에서 가장 값싼 안전장치라고 생각합니다.
8. 이 확인에 드는 비용은 얼마나 되나요?
도구를 한 번 더 돌리고 숫자 하나를 사람이 읽는 정도라서 추가로 드는 것은 크지 않았습니다. 반대로 확인을 건너뛰었을 때 치른 값은 세 사례에서 이미 드러났는데 그 둘을 나란히 놓으면 아래와 같습니다.
| 확인 | 드는 것 | 건너뛰었을 때 치른 것 |
|---|---|---|
| 변이 테스트 | 변이 수만큼 테스트 재실행과 에이전트에게 요청 한 줄 | 아무것도 확인하지 않는 테스트가 초록불을 계속 낸다 |
| 실데이터 1회 | 도구 실행 한 번과 숫자 하나 눈으로 보기 | 6편만 이어진 원장을 매주 자동화가 읽을 뻔했다 |
| 판별 불가 | 판정 문구와 이유 한 줄 | 멀쩡한 광고 슬롯을 고치러 갈 뻔했다 |
| 주제 구로 재측정 | 자동완성 조회 몇 번 | 발행한 글을 지웠고 이미 올린 홍보 게시물이 없는 주소를 가리키게 됐다 |
에이전트 쪽 비용도 조금 늘어납니다. 변이를 넣고 실데이터로 돌려 보라는 요청이 바이브 코딩 대화에 한두 턴을 더하니 토큰이 그만큼 더 들지만, 틀린 원장을 바탕으로 한 주 동안 내린 판단을 되돌리는 비용과 견주면 필자 환경에서는 따져볼 필요가 없는 크기였습니다.
바이브 코딩의 장점이 빨리 만들고 빨리 돌려 보는 데 있다면 이 확인들도 그 속도 안에 들어가는 편입니다. 만든 직후에 하면 싸고 원장에 숫자가 쌓인 뒤에 하면 비싸다는 차이가 있을 뿐입니다.
9. 이렇게 확인해도 안 되는 것
세 가지 확인을 넣었다고 초록불을 믿어도 되는 것은 아니고 이번 기록 안에서도 막히지 않은 자리가 보여서 그대로 적어둡니다.
- 변이 테스트는 입력 가정의 오류를 못 잡습니다. 사례 1처럼 픽스처가 틀린 모양이면 변이는 전부 잡히는데도 테스트는 여전히 실제 입력을 모르는 상태로 남습니다
- 실데이터 1회는 표본 하나입니다. 그날 데이터에 없던 모양의 입력은 다음에 또 새어 들어올 수 있고 서치콘솔이 버튼 문구를 바꾸면 키 정리 함수가 다시 맞는지는 그때 가서 봐야 합니다
- 기대 수치의 감각이 없으면 눈으로 봐도 모릅니다. 처음 만지는 데이터라면 돌리기 전에 사람이 기대 범위를 먼저 정해 두지 않는 한 6이 이상한 숫자인지 판단할 수 없습니다
- 판별 불가는 답이 아니라 다음 행동입니다. 사례 2의 도구는 판별 불가에서 멈췄고, 원인은 광고 콘솔 보고서를 읽은 뒤에야 게재 단계로 좁혀졌습니다
- 규칙 문장은 게이트가 아닙니다. 사례 3의 재발 방지는 아직 지시문 한 줄이라서 코드로 막혔다고 말할 수 없습니다
- 이 기록은 한 블로그의 도구 세 개에서 나왔습니다. 바이브 코딩 전반에서 같은 비율로 일어난다고 말할 근거는 없고 필자가 말할 수 있는 것은 이 세 번의 모양까지입니다
바이브 코딩으로 만든 코드를 누가 어떻게 리뷰해야 하는지처럼 이 글이 다루지 않은 축도 있습니다. 여기서는 테스트와 판정이 무엇을 보장하는지까지만 다뤘고 코드 자체의 품질은 따로 보지 않았습니다.
10. 정리: 바이브 코딩이 맞는 사람과 굳이인 사람, 그리고 필자는 이렇게 봅니다
이 방식이 잘 맞는 쪽은 수집 스크립트나 원장 도구나 판정 게이트처럼 결과를 숫자로 확인할 수 있는 일을 바이브 코딩으로 에이전트에게 맡기는 개발자인데요, 실데이터를 한 번 흘리고 매칭률 하나를 읽는 것만으로 이번 같은 오류를 만든 날 잡을 수 있었습니다.
굳이인 쪽도 있습니다. 한 번 돌리고 버릴 스크립트라면 변이 테스트까지 챙길 이유가 적고, 반대로 결과를 관측할 수단이 아예 없는 일이라면 체크리스트를 채워도 판별 불가만 쌓이니 바이브 코딩으로 맡기기 전에 관측 수단부터 마련하는 편이 먼저입니다.
필자의 결론
바이브 코딩으로 맡긴 도구의 셀프테스트 통과는 완료가 아니라 출발선이라고 봅니다. 세 번의 초록불은 전부 코드가 아니라 가정이 틀린 것이었고 그 가정을 잡은 것은 매번 테스트가 아니라 실데이터였습니다.
그래서 필자는 에이전트에게 도구를 맡길 때 완료 조건을 GATE_OK 한 줄에서 세 줄로 바꿨습니다. 변이 두세 개를 테스트가 잡는지와 실데이터로 한 번 돌린 매칭률이나 건수가 기대 범위에 들어오는지와 관측 못 한 것을 판별 불가로 남겼는지를 함께 보고, 사례 3처럼 아직 규칙 문장으로만 막혀 있는 자리는 코드 게이트로 옮기기 전까지 그 통과를 믿지 않기로 했습니다.