
AI가 "완료했습니다"라고 말했지만, CSV 행 수를 세어보니 거짓말이었던 이야기
요약
AI 에이전트가 도구(Tool) 사용 결과가 오염되었음에도 불구하고 작업을 완료했다고 잘못 보고하는 사례를 분석합니다. AI의 '성공' 보고를 맹신하지 않기 위해 호출 측에서 수행해야 할 독립적인 검증 절차의 중요성을 강조합니다.
핵심 포인트
- AI의 도구 출력(Tool Output) 오염으로 인한 허위 완료 보고 사례
- AI가 자신의 상정을 사실로 확정 짓는 인지 오류 발생
- AI의 반성보다 호출 측의 독립적인 검증 절차 구축이 필수적
- SHA, 행 수(wc -l), SQL 쿼리 등 다각도 검증 권장
이전 세션에서 AI가 "Block 2 완료했습니다"라고 당당하게 말했기에, 그대로 다음 Block으로 진행하려 했습니다. 만일을 위해 CSV의 행 수를 세어보니, 수정되었어야 할 21행이 수정되어 있지 않았습니다. "A안으로 해소"라고 자신만만하게 적힌 freeze 문서의 주장과 실제 파일의 내용이 정면으로 충돌하고 있었습니다.
저는 직접 manabi-map이라는 "주소를 기점으로 다닐 수 있는 고등학교를 지도로 보고, 부모와 자녀가 비교·기록·검토할 수 있는 진로 관리 서비스"를 만들고 있습니다. 군마(Gunma) 버전의 MVP를 OSS로 공개하고 있습니다.
현재 군마에서 서일본 27개 현으로 데이터를 단계적으로 전개 중이며, AI에게 현별 입시 데이터를 정리하도록 하고 있습니다. 이번 실패는 그 4개 현 분량의 Block 2(시코쿠)를 마무리하던 중에 발생했습니다.
현시점에서 군마 버전이 작동 중입니다 (Star를 눌러주시면 힘이 됩니다): https://manabi-map.app
새로운 세션을 열어 저는 다음 Block(도카이 4개 현)을 부탁할 생각이었습니다. 이전 세션이 "Block 2는 G4 승인 완료"라고 freeze 문서에 적어두었고, contract-freeze-block-3.md의 §1에는 "A안으로 해소(합격자 수 NULL화 18행·quality flag +18·역전 0건·비회귀 0을 재검증)"라고까지 구체적으로 적혀 있었습니다.
숫자가 구체적이고, 심지어 "재검증"까지 적혀 있습니다. 보통은 의심하지 않습니다.
하지만 왠지 모르게 손이 멈췄습니다. 오늘 아침, 다른 CLI에서 검증하던 사람이 "그 18행, 수정되지 않은 것 같다"라고 말했던 것이 떠올랐기 때문입니다. 그래서 만일을 위해 wc -l과 grep을 실행했습니다.
# 해당 현의 flags CSV 행 수
$ wc -l admission-selection-quality-flags-v2.csv
49
...
"A안으로 해소"가 사실이라면, flags는 48행에서 18행이 늘어나 66+헤더 = 67행이어야 했습니다. 실측치는 49행(=48+헤더). 늘어나지 않았습니다. SQL의 경우 해당 플래그 문자열이 단 하나도 들어있지 않았습니다. 참고로 같은 Block의 다른 현(도쿠시마)은 동일한 SQL 내에서 21회 출현했습니다. 기술적으로 불가능한 것은 아니었으며, 단순히 고치(Kochi)만 하지 않았던 것입니다.
freeze 문서의 단정적인 "해소"는 근거 없는 날조였던 셈입니다.
이전 세션의 로그(별도 CLI에서 확인)에는 다음과 같은 고백이 남아 있었습니다.
제 도구(파일 읽기/쓰기·확인 명령어)의 출력이 오염되어 있어서, 저는 "쓸 수 있었다" "반영을 확인했다"라고 오인한 채 완료 보고를 반복하고 있었습니다. Grep의 수치도 Write의 "성공" 표시도 가짜가 섞여 있어서, 실제로는 파일에 저장되지 않았음에도 저는 "저장했다"라고 믿고 있었습니다.
요컨대, AI 측의 tool output이 망가져서, Write는 "성공"이라고 반환하고 직후의 Grep은 기대하는 수를 반환하는, 이러한 불일치를 AI 스스로가 감지할 수 없는 상태가 되어 있었습니다. 반성하는 고백은 솔직해서 호감이 갔지만, 이런 사례의 재발 방지는 "AI 측의 반성"이 아니라 "호출하는 측의 검증 절차"로 구축해야 합니다.
(이 작화가 어떤 유형으로 분류될 수 있는지는 자매 기사에 정리해 두었습니다: 속속 Claude Opus 4.8에서 하루에 2번 겪었다. AI가 "자신의 상정"을 "확정"으로 만드는 4가지 패턴. 본 기사는 "인지 방법과 처방전" 측면, note는 "관찰된 작화의 분류학" 측면에서 동일한 사례를 양면에서 다루고 있습니다.)
이번에 제가 사용한 검증은 3가지뿐입니다. 동일한 Block 내에서 "수정했을 것이라고 주장하는" 결과물이 있다면, 이 3가지를 독립적으로 측정합니다.
파일의 SHA (sha256sum이나 Get-FileHash): 이전 상태와 같다면 "한 번도 바뀌지 않았다"는 증거가 됨
CSV / JSON의 행 수 (wc -l이나 Measure-Object -Line): 건수의 증감 주장과 대조
키워드 개수: 문서가 "N건 추가했다"라고 주장하는 문자열을 실제 파일에서 grep -c로 세기
이 중 하나라도 주장과 맞지 않으면 나머지 두 가지도 의심합니다. 이번에는 3가지 모두가 거짓이라고 말하고 있었기에 판정은 몇 초 만에 끝났습니다.
또 하나, 이 사례에서 깨달은 본질적인 문제가 있었습니다.
애초에 왜 18행의 「합격자 수를 NULL화」하는 식의 잔꾀가 필요했을까. 현(県)의 공식 자료에 「응시 24명 / 합격 31명」이라고 적혀 있는 것을 그대로 보면, 「합격자가 응시자를 상회한다」는 점에서 기괴하게 느껴진다. 하지만 실제로는 「A 학과를 응시하고 떨어진 학생이 B 학과의 빈자리에 배정되어 B의 합격자에 추가되었다」는 제2지망 슬라이드(slide)에서 발생하는, 현 양식 특유의 합산 방식일 뿐이다.
그래서 이전 세션에서는 「해당 행의 합격자 수를 공란으로 두고, 역전된 사실에 대해서만 플래그(flag)로 표시한다」라는 계약 규칙 (§4)을 만들었다. 제대로 운용한다면 그럴싸해 보인다. 하지만 이번에 다른 현에서 적용 누락이 발생했고, 계약과 실제 데이터의 정합성이 깨지면서 논란이 되었다.
그때, 사용자(user)로부터 단 한 마디로 상황이 정리되었다.
"현에서 발표한 데이터를 그대로 내보내면 되는 거 아냐? 상세 내용은 PDF로 볼 수 있잖아, 링크가 있으니까. 아무것도 어렵게 생각할 필요 없을 것 같은데."
이 말 한마디에 계약 자체가 사라졌다. 상세 시트에 출처 PDF 링크를 덧붙이면, 사용자(users)는 「합격 > 응시」의 이유를 스스로 찾아낼 수 있다. 지도의 배율은 다른 분모(지원자 / 정원)로 계산하므로 데이터가 손상되지 않는다. §4라는 예외 규칙을 엄격하게 운용하는 것보다, 생데이터(raw value)를 그대로 내보내는 것이 더 투명하며, 블록(Block)을 넘나드는 운용의 불일치도 일어나지 않는다.
계약을 추가하기 전에 "애초에 이 규칙이 필요한가?"라는 질문을 최소한 하나는 던지는 것이 이번에 얻은 가장 큰 교훈이었다.
복잡한 예외 계약을 쌓아 올려 엄격하게 운용하려고 하면, 이번 AI 오염 사례처럼 「계약서와 실제 데이터가 어긋나는」 사고가 발생했을 때의 탐지 비용이 치솟는다. 생데이터를 그대로 내보내고 출처 URL을 덧붙이는 운용이라면, 애초에 예외 규칙이 필요 없으므로 계약과 실제 데이터의 불일치도 발생하지 않는다.
-
「AI가 완료했습니다」라고 선언하는 성과물은 SHA, 행 수,
grep -c이 세 가지로 검증한다. 단 한 곳이라도 맞지 않으면 전부 의심한다. 이전 세션의 freeze 문서나 manifest의 단정적인 기술은 artifact의 실측 결과보다 먼저 읽고 믿지 않는다. 순서를 「실측 → 문서」로 고정한다. -
계약에 예외 규칙을 추가하기 전에 "애초에 이 규칙이 필요한가?"를 최소 1개는 던진다. 운용의 일관성은 예외의 적음에서 나온다.
-
사용자의 "한 단계 물러선 소박한 위화감"을 계약 논의보다 우선한다. 계약은 쓰면 쓸수록 본질에서 멀어진다.
-
복잡한 운용 규칙으로 데이터를 정형화하기보다, 생데이터 + 출처 URL로 사용자에게 판단 재료를 넘겨주는 것이 장기적으로는 비용이 적게 든다.
-
중학생 자녀와 함께, 통학 가능한 범위의 고등학교를 지도로 보며 비교하고 싶은 보호자
-
학교명·편차치의 나열이 아니라, 지도와 즐겨찾기 메모로 진로를 가족 공유 노트에 담고 싶은 사람
-
상업 사이트의 숫자가 아니라, 공적 자료에 기반한 추정치와 출처 링크로 직접 확인하고 싶은 사람
-
이번 반성을 바탕으로, 서일본 27개 현(府県)으로의 단계적 전개를 진행하고 있습니다.
어느 하나라도 해당한다면, 군마 버전이 이미 작동 중입니다: https://manabi-map.app
- 리포지토리 (Issue / PR 환영): https://github.com/ishizakahiroshi/manabi-map
Star를 눌러주시면 개발에 큰 힘이 됩니다. 사용해 보시고 "이 부분이 불편하다"면 Issue나 X의 DM 모두 대환영입니다.
AI에게 맡기는 범위를 넓힐수록, 「완료했습니다」라는 한마디를 곧이곧대로 믿기 어려워지는 상황이 늘어나고 있습니다. 반성문은 어디에나 쓸 수 있으므로, 중요한 것은 요청하는 쪽의 '3초간의 실측'이라는 당연한 원칙으로 돌아가는 이야기였습니다.
작게 시작하자. SHA와 wc -l, 그리고 grep -c를 실행하는 습관을 앞으로도 계속 이어가겠습니다.
📎 관련 링크를 정리한 페이지가 있습니다: https://ishizakahiroshi.com/articles/2026/2026-07-18_ai-completion-lied/
※ 헤더 이미지와 인포그래픽은 AI(이미지 생성)로 제작했습니다.
※ 본문의 삽화도 AI(이미지 생성)로 제작했습니다.
작성자: ishizakahiroshi
군마 북부에서 유기묘 2마리와 함께 살고 있는 재택 엔지니어 (잡무 전문가)
X (업무 위탁·각종 상담은 이쪽으로):
백엔드·인프라·AI 연동 관련 업무 위탁 상담을 받고 있습니다. 풀 리모트(Full Remote) 방식입니다. 스팟(Spot)이나 주 2~3시간부터라도 환영하며, 다양한 프로젝트에 참여할 수 있다면 기쁘겠습니다. 다음과 같은 상담을 환영합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기