AI 에이전트가 '다 했다'고 할 때 믿으면 안 되는 이유
회사에서 AI가 "다 했다"고 해서 열어 보니, 제가 말한 것 이상으로 다른 기능까지 잔뜩 추가해 둔 경우가 있었습니다. "완료"는 일이 끝났다는 뜻도, 요청한 것만 했다는 뜻도 아닙니다. 요청하지 않은 변경이 섞였는지까지 봐야 합니다.
목차
AI 에이전트가 "완료했습니다"라고 말하는 것은 주장입니다. 증거는 따로 확인해야 합니다. 특히 "행동했다"와 "결과가 그렇게 됐다"는 전혀 다른 이야기입니다. 버튼을 눌렀다고 저장된 것이 아니고, 이미지를 올렸다고 제자리에 들어간 것이 아닙니다. 이 블로그를 AI와 함께 정비하고 글을 발행하면서 이 차이를 여러 번 겪었습니다. 작업자가 테스트를 돌리지 못하고 넘긴 일, 글 초안에 사실 오류가 섞여 있던 일은 AI 코딩 에이전트에게 일 맡기는 법에 정리했으니, 여기서는 블로그를 운영하면서 겪은 사례를 모았습니다.
한눈에 보기
- "완료"는 주장, 결과는 따로 확인: 행동(클릭, 업로드)이 아니라 결과(저장된 값, 공개 화면)를 본다
- 검증 항목이 틀리면 검증해도 틀린다: 무엇을 확인해야 성공인지 먼저 정한다
- 바깥에서 본다: 관리 화면이 아니라 사용자가 보는 공개 주소로 확인한다
- 실패 보고도 확인한다: "실패"라는 말도 결과로 다시 본다
- 확인 시점을 고려한다: 캐시나 반영 지연 때문에 너무 이르면 오해한다
사례 1. "이미지가 제자리에 있다"는 보고가 틀렸다
두 번째 글(AGENTS.md·CLAUDE.md 작성법)을 발행한 뒤 AI가 "이미지 2장이 본문의 정해 둔 자리에 정상 표시"된다고 보고했습니다. 그런데 다음 글을 발행하면서 이미지 아래 설명이 왜 안 보이는지 확인하다가, 두 번째 글의 이미지 두 장이 정해 둔 자리가 아니라 글 맨 끝에 붙어 있다는 것을 발견했습니다.
AI의 검증은 "이미지가 로드됐는가"만 봤습니다. 이미지 개수와 크기는 맞았으니 통과였습니다. 하지만 "어디에 있는가"는 보지 않았습니다. 확인한 것과 확인해야 할 것이 달랐던 것입니다.
원인은 티스토리 HTML 편집기였습니다. 편집기 내용을 스크립트로 통째로 바꾸면(setValue) 화면에는 바뀐 것처럼 보여도 저장에는 반영되지 않았습니다. 사람이 직접 입력한 것처럼 처리되는 방식으로 바꿔서 해결했고, 그 뒤로는 이미지가 있는지만이 아니라 이미지 바로 앞뒤 문단까지 확인합니다. 검증 항목이 틀리면 아무리 꼼꼼히 검증해도 틀린 결론이 나옵니다.
사례 2. "클릭 성공"은 "저장 성공"이 아니었다
블로그 이름을 바꾸려고 AI가 설정 화면에서 저장 버튼을 눌렀습니다. 브라우저를 조작하는 도구는 "click ok"를 돌려줬습니다. 그런데 블로그 이름은 그대로였습니다. 화면에는 저장에 실패했다는 메시지가 따로 뜨지 않았습니다. 닉네임 칸 아래에 빨간 안내 문구가 있었을 뿐입니다.
네트워크 응답을 열어 보니 서버가 400 오류와 함께 "사용할 수 없는 닉네임입니다"를 돌려주고 있었습니다. 이 설정 화면은 이름, 닉네임, 설명을 한 번에 저장하는데, 기존 닉네임이 거부되면서 이름까지 저장되지 않았던 것입니다. 닉네임을 바꾸자 그제야 저장됐습니다.
"클릭했다"는 행동이고, "이름이 바뀌었다"는 결과입니다. 도구가 알려 준 것은 행동의 성공뿐이었습니다. 결과를 확인하려면 저장한 뒤 그 값을 다시 읽어 봐야 합니다.
▲ 행동 확인과 결과 확인의 차이
사례 3. 반대로 "실패"라는 보고가 틀렸다
반대 경우도 있었습니다. 글 본문을 편집기에 넣는 도구가 "입력 결과를 확인할 수 없다"는 오류를 냈습니다. 그대로 믿었다면 다시 입력하거나 다른 방법을 찾았을 것입니다. 그런데 편집기 안의 글자 수를 직접 세어 보니 원고와 정확히 같았습니다(5,758자). 입력은 제대로 됐고, 확인하는 단계만 실패한 것이었습니다.
성공 보고만 의심할 일이 아닙니다. 실패 보고도 결과로 확인해야 합니다. 멀쩡한 작업을 실패로 보고 되풀이하면, 같은 내용이 두 번 들어가는 식의 새로운 문제를 만들 수 있습니다.
사례 4. 너무 이르게 확인하면 오해한다
옛 글 6편을 비공개로 바꾼 직후 외부에서 그 글을 열어 보니 여전히 열렸습니다(200). 비공개 처리가 실패한 것처럼 보였습니다. 20초쯤 뒤 다시 확인하니 닫혀 있었습니다(404). 캐시 때문이었습니다.
결과를 확인하는 것도 언제 확인하느냐에 따라 답이 달라집니다. 반영에 시간이 걸리는 작업은 바로 확인하지 말고 조금 기다렸다가 다시 봐야 합니다. 너무 이르게 확인하면 멀쩡한 작업을 실패로 오해합니다.
잘된 검증의 예
옛 글 59편을 비공개로 바꿀 때는 검증이 잘 됐습니다. 관리 화면의 "비공개" 표시를 믿지 않고, 외부에서 59개 주소를 모두 열어 403(접근 불가)이 나오는지 하나씩 확인했습니다. 남겨 둔 37편은 반대로 200(정상)이 나오는지 확인했습니다. 바뀌어야 할 것은 바뀌었고, 바뀌면 안 되는 것은 그대로라는 것을 둘 다 봤습니다.
작업 도중에도 확인을 넣었습니다. 글을 체크할 때마다 "체크한 글 수가 예상과 같은지"를 세게 했고, 그 덕분에 5개를 체크해야 하는데 4개만 체크된 경우를 실행 전에 잡아냈습니다. 결과를 확인하는 것만큼, 실행하기 전에 상태를 확인하는 것도 효과가 있었습니다.
검증 원칙 5가지
위 사례들에서 정리한 원칙입니다.
- 행동이 아니라 결과를 본다. "클릭했다", "업로드했다"가 아니라 "값이 바뀌었다", "제자리에 들어갔다"를 확인합니다.
- 확인 항목을 먼저 정한다. 무엇이 성공인지 정하지 않으면 엉뚱한 것을 확인하고 통과시킵니다. 이미지라면 "로드됨"이 아니라 "정해 둔 자리에 있음"이 성공입니다. 요청한 범위 밖은 바뀌지 않아야 한다는 것도 성공 기준에 넣습니다.
- 바깥에서 본다. 관리 화면이나 도구의 응답보다, 사용자가 실제로 보는 화면과 공개 주소로 확인합니다.
- 실패 보고도 확인한다. "실패"도 주장입니다. 결과를 보고 정말 실패했는지 판단합니다.
- 확인 시점을 고려한다. 캐시나 반영 지연이 있는 작업은 시간을 두고 다시 확인합니다.
체크리스트
AI가 "다 했다"고 보고하면 아래를 확인합니다.
- 이 작업의 성공 기준(무엇이 어떻게 되어야 하는가)을 먼저 적었는가
- 행동의 성공이 아니라 결과(저장된 값, 화면, 파일)를 다시 읽었는가
- 관리 화면이 아니라 바깥(공개 주소, 사용자 화면)에서 확인했는가
- 바뀌면 안 되는 것이 그대로인지도 확인했는가
- 요청하지 않은 기능·변경이 섞이지 않았는가 (diff로 확인)
- "실패" 보고라면 실제 결과를 확인했는가
- 반영 지연이 있을 수 있는 작업이면 시간을 두고 다시 봤는가
직접 해보니
AI와 일해 보면 너무 앞서 나간다는 느낌을 자주 받습니다. 시키지 않은 것까지 하고, 확인이 끝나기도 전에 "다 했다"며 다음으로 넘어갑니다. 그래서 속도를 늦추는 역할, 즉 무엇이 성공인지 정하고 결과를 확인하는 일은 결국 사람 몫이라고 생각합니다.
마무리
AI 에이전트가 빠르게 일을 처리할수록 "완료" 보고도 빠르게 쌓입니다. 하지만 보고는 주장이고, 증거는 결과에 있습니다. 클릭이 성공해도 저장은 실패할 수 있고, 도구가 실패라고 해도 결과는 멀쩡할 수 있습니다. 무엇이 성공인지 먼저 정하고, 바깥에서, 반영될 시간을 두고 결과를 확인하는 습관이 가장 확실한 안전장치였습니다. AI가 어떤 도구로 이런 작업을 하는지는 MCP란? AI 코딩 에이전트에 도구를 붙이는 방법과 실사용기에 정리했습니다.
자주 묻는 질문 (FAQ)
Q. 모든 작업을 이렇게 확인하면 너무 느리지 않나요?
대개는 확인하는 데 드는 시간보다 틀린 결과를 늦게 발견했을 때 드는 시간이 더 큽니다. 다만 모든 것을 같은 깊이로 볼 필요는 없습니다. 되돌리기 어렵거나 바깥에 공개되는 작업부터 결과 확인을 꼼꼼히 합니다.
Q. 검증도 AI에게 맡기면 안 되나요?
맡길 수 있습니다. 이 글의 사례들도 AI와 함께 확인한 것입니다. 중요한 것은 무엇을 확인할지를 사람이 정하는 것입니다. 사례 1처럼 확인 항목이 틀리면 AI는 성실하게 틀린 것을 확인하고 통과시킵니다.
이 글은 AI(Claude)가 초안을 쓰고, 제가 경험과 의견을 채운 뒤 검토해 발행했습니다. 글에 들어간 도식도 AI와 함께 만들었습니다.