블로그 목록으로AI에게 테스트를 맡겼는데, 왜 오류가 났을까요?
By 원영2026년 7월 25일6분이 글의 목차
AI가 만든 코드를 그 AI에게 테스트시켰는데도 사용자에게 오류가 났다면, 당신이 잘못 시킨 게 아닙니다. 만든 쪽이 테스트까지 맡으면 "통과"가 통과가 아니게 되기 때문입니다. 이건 AI 성능 문제가 아니라 역할을 어떻게 나누느냐의 문제입니다. 이 글은 왜 그런지, 그리고 지금 쓰는 도구를 그대로 두고 무엇만 바꾸면 되는지 이야기합니다.
- 만든 AI가 스스로 테스트하면 통과 기준도, 판정도 같은 쪽이 쥡니다 — 자기 결과물을 후하게 보는 편향은 연구에서 반복 확인됐습니다.
- 무엇을 통과로 볼지는 사람이 승인하고, 판정은 글이 아니라 실제 브라우저가 눌러본 결과여야 합니다.
- AI가 더 좋아져도 이 구조는 남습니다. 도구를 바꿀 필요는 없고, 테스트만 밖으로 빼면 됩니다.
"테스트해줘" 하고 통과를 받았는데
Cursor 나 Claude Code 에 테스트를 시켜본 적 있으실 겁니다.
"회원가입 잘 되는지 테스트해줘."
잠시 뒤 답이 옵니다. "테스트를 작성해 실행했습니다. 모두 통과했습니다." 안심하고 배포합니다. 그리고 다음 날, 사용자에게 메시지가 옵니다 — "회원가입이 안 돼요."
무엇이 잘못됐을까요. 대개는 프롬프트가 아닙니다. 더 자세히 시켰어도 같은 일이 벌어집니다. 문제는 누가 테스트했는가에 있습니다.
이 글은 그다음 질문 — "그럼 AI한테 시키면 되지 않나?" — 에 답합니다. 애초에 이 확인이 왜 그렇게 어려운지는 앞 글에서 다뤘습니다.
이어서 읽기바이브 코딩으로 만든 앱, 코드 없이 E2E 테스트하는 법E2E 테스트바이브코딩6분
개발한 AI가 테스트까지 맡으면
코드를 만든 AI에게 그 코드의 테스트까지 맡기면, 무엇을 통과로 볼지 정하는 쪽과 통과 여부를 판정하는 쪽이 같아집니다. 개발과 테스트가 한 손에 들어간 상태입니다.
만든 쪽이 통과 기준까지 정하면, 일부러 봐주지 않아도 판정은 후해집니다. 무엇을 통과로 볼지부터 같은 쪽이 정했기 때문입니다.
그리고 이건 느낌이 아니라 측정된 현상입니다. 2024년 연구 LLM Evaluators Recognize and Favor Their Own Generations 는 GPT-4 같은 모델이 자기가 만든 결과물을 남의 것보다 후하게 평가한다는 것을 실험으로 보였습니다.
더 뼈아픈 건 2026년 연구 Self-Preference Bias in Rubric-Based Evaluation 입니다. 통과·실패가 프로그램으로 자동 판정되는 객관적인 기준표를 줬는데도 편향이 남았습니다. 실제로 실패한 항목을 두고, 그 결과물이 자기 것일 때 "충족했다"고 잘못 표시할 확률이 50% 넘게 높았습니다. 코드 벤치마크에서도 마찬가지였습니다.
기준을 아무리 명확히 줘도, 개발한 쪽이 테스트까지 맡으면 판정이 기울어집니다.
통과 판정과 실제 사용자 경험 사이에 하루가 있었다
AI가 짜 준 단위 테스트가 안심되지 않는 이유
"그럼 AI가 테스트 코드까지 만들어 주면?" 이 방법은 개발자에게는 유효합니다. 코드를 읽고 고칠 수 있으니까요.
코드를 못 읽는 사람에게는 문제가 하나 더 늘어날 뿐입니다. 받은 테스트 코드를 두고 이런 것들을 판단할 수 없습니다.
- 이게 무엇을 검사하는지
- "통과"가 정확히 어디까지 됐다는 뜻인지
- 실패했을 때 앱이 문제인지 테스트가 문제인지
세 번째가 특히 위험합니다. 테스트가 잘못 짜여 늘 통과한다면, 그 초록불은 아무 의미가 없는데도 안심하게 만듭니다. 읽을 수 없는 검증은 검증이 아니라 또 하나의 믿음입니다.
그럼 사람이 다 눌러봐야 하나요
아닙니다. 바꿀 것은 도구가 아니라 역할 배치 하나입니다.
만드는 일은 그대로 AI에게 맡기고, 테스트만 밖으로 빼면 됩니다. 그러면 두 가지가 달라집니다.
첫째, 통과 기준을 사람이 승인합니다. "로그인 화면에 들어간다 → 이메일과 비밀번호를 넣는다 → 대시보드가 뜬다" 처럼 평범한 말로 적힌 단계라, 무엇을 확인할지 당신이 읽고 정할 수 있습니다.
둘째, 판정을 글이 아니라 실행으로 합니다. AI가 "됐다"고 말하는 대신, 진짜 크로미움 브라우저가 그 단계를 사람처럼 눌러보고 통과·실패를 표시합니다. 전 과정은 영상으로 남습니다.
쓰던 도구는 그대로 — 가운데 한 칸의 담당만 바뀐다
Specnote 는 이 테스트 자리에 들어갑니다. 쓰던 AI 코딩 도구에 연결해두면 평소 하던 대로 말하는 것으로 시나리오가 만들어지고, 판정은 실제 브라우저가 합니다. 도구를 바꾸는 게 아니라, 테스트만 밖으로 빼는 것입니다.
다섯 단계가 무엇을 확인했는지 한 줄씩 읽을 수 있다
AI가 더 좋아지면 해결될까요
이 질문은 정당합니다. 모델은 계속 좋아지고 있으니까요.
그런데 지금 다루는 건 성능이 아니라 배치의 문제입니다. 아무리 뛰어난 모델이라도 자기 결과를 자기가 판정하는 구조에 놓이면 편향이 생긴다는 것이 위 연구들의 요지입니다. 모델이 좋아진다고 개발과 테스트가 저절로 분리되지는 않습니다.
비용도 남습니다. 판정을 매번 AI에게 시키면 실행할 때마다 느리고, 비싸고, 같은 앱을 같은 조건으로 돌려도 답이 조금씩 달라집니다. 회귀 검증은 1년에 수백 번 반복하는 일이라 실행 한 번의 비용과 판정의 일관성이 지배합니다.
지금 테스트해보기
테스트만 밖으로 빼보세요자주 묻는 질문
AI가 짜 준 단위 테스트나 AI 코드 리뷰로는 부족한가요?
도움은 됩니다. 다만 둘 다 만든 쪽이 스스로를 검사하는 구조라 같은 사각지대를 물려받습니다. 단위 테스트는 함수 하나가 제 몫을 하는지 보고, AI 코드 리뷰는 코드의 모양을 보지만, 사용자가 실제로 거치는 흐름이 끝까지 이어지는지는 둘 다 확인하지 않습니다. AI 테스트 자동화를 쓰더라도 판정하는 쪽만큼은 만든 쪽 밖에 있어야 합니다.
AI 가 통과라고 했는데 왜 에러가 날까요?
안 되는 게 아니라, 만든 쪽이 테스트까지 하면 판정이 기울어집니다. 연구에서도 객관적인 기준표를 줬을 때조차 자기 결과물의 실패를 통과로 표시할 확률이 더 높았습니다. 만드는 일은 AI에게 맡기고 테스트만 밖으로 빼는 것이 요점입니다.
그럼 Cursor·Claude Code 를 쓰지 말라는 건가요?
아닙니다. 계속 쓰시면 됩니다. Specnote 는 그 도구에 연결해 테스트 자리만 맡습니다 — 말로 시키면 시나리오가 만들어지고, 판정은 실제 브라우저가 합니다.
AI가 만든 테스트 코드를 쓰면 안 되나요?
코드를 읽을 수 있다면 좋은 선택입니다. 못 읽는다면 무엇을 검사하는지·통과가 무슨 뜻인지·실패했을 때 앱과 테스트 중 무엇이 문제인지를 판단할 수 없습니다. 읽을 수 없는 초록불은 안심만 줍니다.
실제 브라우저로 한다는 게 무슨 뜻인가요?
코드를 분석해 추측하는 것이 아니라, 진짜 크로미움 브라우저를 열어 사람처럼 클릭하고 입력하고 화면을 확인한다는 뜻입니다. 사용자가 겪는 것과 같은 경로를 그대로 지나갑니다.
테스트가 아니라 코드 품질도 봐주나요?
아닙니다. 하는 일은 하나입니다 — 사용자가 실제로 겪을 흐름이 실제로 되는지 확인하는 것. 코드 품질·보안 점검은 다른 도구의 몫입니다.
앞 글을 안 읽었는데 이해할 수 있나요?
이 글만으로도 충분합니다. 다만 왜 애초에 확인이 어려운지가 궁금하시면 바이브 코딩으로 만든 앱, 진짜 되는지 어떻게 확인하나요? 를 먼저 보셔도 좋습니다.
