AI에게 일을 맡기면 대부분 "완료했습니다"로 돌아옵니다. 문제는 그 보고에 붙은 근거가 형식적으로는 통과인데 실질적으로는 아무것도 검증하지 않은 경우가 드물지 않다는 점입니다. 이 글은 통과라는 결과가 거짓 증거가 되는 세 가지 패턴과, 그것을 걸러내는 변이 검증이라는 절차를 정리합니다.
"통과"는 왜 증거가 아닌가?
검증 스크립트가 성공 코드(exit 0)를 반환했다는 사실은 두 가지 중 하나를 뜻합니다. 검사 대상이 정상이었거나, 검사가 애초에 일어나지 않았거나입니다. 후자는 생각보다 흔합니다.
실무에서 반복적으로 관찰되는 패턴은 세 가지입니다.
| 패턴 | 무엇이 일어나는가 | 겉으로 보이는 결과 |
|---|---|---|
| 빈 대상 | 검사할 파일·목록이 비어 있다 | 검사 0건 = 전부 통과 |
| 동어반복 테스트 | 코드가 계산한 값을 그대로 기대값으로 쓴다 | 항상 통과 |
| 파괴 후 비교 | 값이 바뀐 뒤에 지문을 찍어 비교한다 | 무결로 보고 |
세 번째 패턴은 특히 잡기 어렵습니다. 파일이 이미 손상된 뒤에 그 손상된 값을 기준으로 비교하면, 비교 결과는 언제나 "동일"이 됩니다. 검사 도구는 정직하게 초록불을 켜고, 데이터는 이미 깨져 있습니다.
이런 결과를 그대로 수락하면 사람은 검증했다고 믿고, 시스템은 검증되지 않은 상태로 남습니다. AI의 환각보다 위험한 것은 이렇게 형식을 갖춘 거짓 증거입니다. 환각은 어색해서 눈에 띄지만, 통과한 테스트는 아무도 다시 보지 않기 때문입니다.
변이 검증: 일부러 망가뜨려서 실패를 확인한다
해결책은 단순합니다. 검증 도구를 신뢰하기 전에, 그 도구가 실패할 수 있는지 먼저 확인하는 것입니다. 절차는 네 단계입니다.
- 정상 상태에서 검증을 돌린다. 통과(초록불)를 확인합니다.
- 검사 대상을 일부러 한 군데 망가뜨린다. 값 하나를 바꾸거나 항목 하나를 지웁니다.
- 다시 검증을 돌린다. 여기서 실패(빨간불)가 떠야 합니다. 통과가 뜨면 그 검증은 아무것도 검사하지 않고 있습니다.
- 원래대로 복구하고 다시 통과를 확인한다. 복구 확인까지 해야 절차가 닫힙니다.
2단계에서 실패가 뜨지 않는 검증은 존재 가치가 없습니다. 반대로 실패가 정확히 어떤 항목 때문인지 이름까지 지목한다면, 그 검증은 신뢰할 수 있습니다.
변이는 여러 종류로 시도할수록 좋습니다. 값 변경, 항목 삭제, 순서 뒤바꿈, 잘못된 우선순위 적용처럼 서로 다른 방식의 훼손을 각각 넣어보면, 검증이 실제로 덮는 범위가 드러납니다.
증거 양식: 무엇을 받아야 하는가
완료 보고를 받을 때 요구할 항목을 미리 정해두면, 판단이 매번 흔들리지 않습니다.
- 명령 원문과 출력 원문의 쌍. "확인했습니다", "정상 동작합니다" 같은 서술은 증거가 아닙니다. 실행한 명령과 그 명령이 출력한 내용을 함께 받습니다.
- 숫자. "빌드 성공"이 아니라 "빌드 10페이지·에러 0", "테스트 48/48"처럼 셀 수 있는 형태로 받습니다. 숫자는 나중에 다시 확인할 수 있습니다.
- 실패 증거. 통과 화면만이 아니라 2단계에서 얻은 실패 출력도 함께 받습니다. 실패를 재현할 수 있다는 것이 검증이 살아 있다는 증거입니다.
- 대상의 실체 확인. 검사 대상 파일이 실제로 내용을 갖고 있는지(줄 수, 특정 문자열 포함 여부) 확인한 결과를 붙입니다. 빈 대상 패턴을 막는 최소 장치입니다.
검증 결과를 의심해야 하는 신호
다음 상황에서는 통과 결과를 한 번 더 확인할 가치가 있습니다.
- 예상과 정확히 일치하는 깔끔한 결과가 나왔을 때. 사람도 AI도 자기 예상과 맞는 결과가 나오면 검증을 멈춥니다. 오히려 이때가 가장 위험합니다.
- 검증이 지나치게 빨리 끝났을 때. 검사 건수가 0에 가까울 가능성이 있습니다.
- 보고에 숫자가 없을 때. "정상", "이상 없음"만 있는 보고는 재현 불가능합니다.
- 작성자가 자기 결과를 검수했을 때. 만든 쪽은 자기 결과를 정당화하는 방향으로 결론을 냅니다.
마지막 항목 때문에, 검수는 작성한 주체와 분리하는 편이 낫습니다. 검수 담당에게 줄 지시는 한 줄로 충분합니다. "이 보고가 거짓이라고 가정하고 무너뜨려 보세요." 그리고 검수는 남이 만든 증거를 다시 읽는 것이 아니라 직접 재현하거나 직접 망가뜨리는 것이어야 합니다. 여러 에이전트를 함께 운영하는 환경이라면 멀티에이전트 운영법에서 이 역할 분리를 어떻게 배치하는지 함께 볼 수 있습니다.
실패 메시지에 피해를 적어둔다
작은 습관이지만 효과가 큽니다. 검증이 실패할 때 출력하는 문장에 무엇이 잘못됐는지가 아니라 누가 다치는지를 적어두면, 몇 주 뒤 그 실패를 처음 본 사람도 심각성을 즉시 이해합니다.
FAIL 항목 식별자 대조 — 값이 바뀌면 이 항목을 체크한 사용자의 진행률이 사라진다
이렇게 적혀 있으면 "그냥 문자열 비교 실패"로 넘기지 않게 됩니다. 검증은 기술 장치이면서 동시에 인수인계 문서입니다.
자주 묻는 질문
- Q. 테스트가 통과했는데도 의심해야 하나요?
- A. 통과는 두 가지를 뜻할 수 있습니다. 대상이 정상이었거나, 검사가 일어나지 않았거나입니다. 검사 대상이 비어 있으면 검증 스크립트는 아무것도 확인하지 않고 성공 코드를 반환할 수 있으므로, 통과만으로는 구분이 되지 않습니다.
- Q. 변이 검증은 무엇인가요?
- A. 검사 대상을 일부러 한 군데 훼손한 뒤 검증을 다시 돌려, 실패가 뜨는지 확인하는 절차입니다. 실패가 뜨지 않으면 그 검증은 아무것도 검사하지 않고 있다는 뜻입니다. 확인 후에는 원래 상태로 복구하고 통과를 재확인합니다.
- Q. AI에게 어떤 형식으로 증거를 요구해야 하나요?
- A. 실행한 명령 원문과 그 출력 원문을 쌍으로 요구하고, 결과를 셀 수 있는 숫자로 받으세요. 통과 화면만이 아니라 일부러 망가뜨렸을 때의 실패 출력까지 함께 받으면 검증이 살아 있음을 확인할 수 있습니다.
- Q. 검수를 같은 AI에게 맡겨도 되나요?
- A. 권하지 않습니다. 작성한 주체는 자기 결과를 정당화하는 방향으로 결론을 내기 쉽습니다. 검수는 별도 세션이나 별도 에이전트에 맡기고, 남이 만든 증거를 읽는 대신 직접 재현하게 하는 편이 낫습니다.
더 읽을거리
AI 출력의 사실성을 높이는 접근은 AI 환각 줄이는 방법에서, 규칙 파일로 작업 방식을 고정하는 방법은 CLAUDE.md 작성법에서 다룹니다. 에이전트 개념 정리는 AI 에이전트 용어 페이지를 참고하세요.
이 글의 절차가 실제 운영에서 어떻게 적용됐는지 궁금하다면, 이 사이트를 운영하는 1인 AI 회사의 기록을 정리한 전자책 『1인 AI 회사 실전기』에 거짓 증거를 적발한 사례가 운영 로그 원문과 함께 실려 있습니다.
증거 양식과 지시서·결과보고 서식을 파일로 바로 쓰려면 멀티에이전트 스타터 키트를 참고할 수 있습니다. 이 글의 증거 규약(명령 원문+출력 원문)이 실제 양식으로 들어 있고, 그 규약을 만들게 한 사고 5건도 함께 정리돼 있습니다.