AI 조사 보고서 검증하는 순서: 사이트 50곳에서 많다던 문제가 세 곳뿐이었던 이유

영업 메일에 넣을 자료를 만들려고 AI 서브에이전트에 사이트 50곳(기관 30곳, 프랜차이즈 가맹본부 20곳)의 상태를 조사시켰습니다. 보고서에는 “본문이 검색엔진에 안 잡히는 곳이 꽤 많다”는 항목이 있었는데, 몇 곳을 직접 열어 보니 정말 그런 곳은 세 곳이었습니다. 나머지는 제목 태그 앞뒤에 들어간 공백을 검사 코드가 빈 값으로 읽은 것이었습니다. 이 글은 그 뒤로 AI가 올린 조사 결과를 확인하는 순서를 정리한 것입니다.

AI 조사 보고서에서 틀린 결론이 맞는 결론처럼 보이는 이유

보고서 내용은 그럴듯했습니다. 본문이 검색엔진에 안 잡히는 사이트는 실제로 흔하기도 합니다. 그대로 메일에 쓰려다가 숫자가 커 보여서 몇 곳만 열어 봤고, 세 개째에서 이상하다는 게 드러났습니다.

조사를 대충 한 건 아니었습니다. 어긋난 건 판정에 쓴 확인 방법이었는데, 보고서에는 그 방법이 아니라 결론만 올라옵니다. 그래서 읽는 쪽에서는 제대로 확인해서 나온 “많다”와 잘못 확인해서 나온 “많다”가 똑같은 문장으로 보입니다.

사람에게 시켰다면 애매한 대목에서 “이거 좀 이상한데요” 하고 물어 왔을 겁니다. 자동으로 도는 쪽은 애매해도 결론을 내고 넘어갑니다.

같은 보고서를 다시 확인한 결과는 이렇습니다.

보고 내용	다시 확인한 결과	원인
본문이 안 잡히는 곳이 꽤 많다	세 곳만 사실	제목 태그 공백을 빈 값으로 읽음
https가 http로 내려가는 곳 1건	다시 해 보니 재현 안 됨	확인 못 함

제목 태그 공백 때문에 빈 값으로 읽히는 경우

사람이 보면 제목이 멀쩡히 있었습니다. 그런데 HTML 원문에서는 <title> 안쪽 앞뒤에 공백이 들어가 있었고, 확인하는 코드는 이걸 “제목 없음”으로 처리했습니다. 제목이 없다는 판정이 본문이 안 잡힌다는 결론으로 이어진 것입니다.

이런 판정을 손으로 확인할 때는 브라우저 화면보다 서버가 보내는 HTML 원문을 보는 게 빠릅니다.

curl -s https://example.com | grep -i -A2 "<title"

원문에 제목 글자가 있으면 공백이나 줄바꿈이 섞여 있어도 제목은 있는 겁니다. 본문이 실제로 비어 있는지 볼 때도 같은 방법으로, 원문에 본문 문장이 들어 있는지 찾아 보면 됩니다. 원문에는 없고 화면에만 보이면 자바스크립트가 나중에 채우는 구조입니다.

내가 관리하는 사이트라면 Google Search Console의 URL 검사 도구로 구글이 가져간 정보를 볼 수 있습니다. 기본 결과는 지금 서비스 중인 페이지가 아니라 가장 최근에 색인된 버전 기준이고, 실시간 테스트를 돌리면 테스트한 페이지의 HTML과 스크린샷을 볼 수 있습니다. 소유하지 않은 사이트의 주소는 검사할 수 없어서, 이번처럼 다른 회사 사이트를 조사할 때는 원문을 직접 보는 수밖에 없습니다.

AI 조사 결과는 숫자가 큰 항목부터 표본으로 확인

전부 다시 확인하면 조사시킨 의미가 없어서 고르는 기준을 정했습니다.

• “많다”, “대부분”, “다수” 같은 말이 붙은 항목에서 서너 개를 직접 엽니다. 이번에도 세 개째에서 문제가 보였습니다.
• “한 곳에서 발견됐다” 같은 항목은 틀려도 손해가 작아서 뒤로 미룹니다.
• 다시 해 봐서 재현이 안 되는 항목은 결론에서 뺍니다. https 항목 1건이 여기에 해당했습니다.

남에게 나갈 문장만 다시 확인

내부에서 참고만 하는 자료까지 전부 검증하면 시간이 남지 않습니다. 기준은 하나로 잡았습니다. 이 문장이 남한테 그대로 보이는가입니다. 메일에 들어갈 문장, 고객에게 갈 리포트, 발행할 글은 다시 확인하고 나머지는 참고로 둡니다.

이번에는 메일에 넣을 문장을 전부 직접 다시 확인한 것만 남겼습니다. 확인하는 데 걸린 시간이 조사시킨 시간보다 길었지만, 틀린 문장이 밖으로 나가면 돌려받는 비용이 더 큽니다.

결론과 함께 판정 근거를 받는 형식

“몇 곳이 문제였다”만 받으면 확인할 때 처음부터 다시 조사해야 합니다. 조사를 시킬 때 결과를 항목마다 이런 칸으로 달라고 적어 두면 확인이 몇 분으로 줄어듭니다.

• 대상 주소
• 판정 (문제 있음 / 없음 / 확인 못 함)
• 판정에 쓴 실제 값 (예: 읽어 온 제목 문자열)
• 확인한 방법 (어떤 요청을 보내 무엇을 봤는지)

이번에도 판정에 쓴 제목 문자열이 같이 있었다면 빈 값이 아니라 공백이라는 걸 훨씬 빨리 봤을 겁니다. “확인 못 함”을 따로 둔 건, 이 칸이 없으면 애매한 경우도 둘 중 하나로 판정돼서 올라오기 때문입니다. 지시서를 쓰는 쪽 이야기는 AI 워커 지시서를 자기완결로 쓰는 법에 따로 적었습니다.

원격 명령이 0을 돌려줄 때 의심할 것

같은 달에 비슷한 모양의 일이 하나 더 있었습니다. 집 서버에 SSH로 명령을 보내 컨테이너가 몇 개 도는지 셌더니 0개라고 나왔습니다. 실제로는 11개가 정상으로 돌고 있었습니다.

원인은 서버가 아니라 물어보는 방식이었습니다. macOS는 로그인할 때만 프로그램 찾는 경로를 채워 주는데, SSH로 명령 한 줄만 보내면 그 설정을 읽지 않습니다. 그래서 docker 명령을 못 찾았고, 그 실패가 개수를 세는 자리로 흘러가 0이라는 숫자가 됐습니다. 경로 설정을 ~/.zshenv에 넣은 뒤 다시 보내니 11개가 정상으로 나왔습니다. 자세한 원인과 설정은 SSH로 명령을 던지면 command not found 가 나는 이유에 있습니다.

숫자가 나오니 정상적인 대답처럼 보였고, 앞의 보고서도 그렇게 넘어갈 뻔했습니다. 그래서 확인 스크립트를 고칠 때 명령을 못 찾은 경우와 정말 0개인 경우를 나눠서, 앞의 경우에는 숫자 대신 사람이 읽을 문장이 나오게 했습니다.

이 방법으로 안 되는 것

• 표본 확인은 전체가 맞다는 보장이 아닙니다. 서너 개가 맞아도 나머지에 다른 오판이 있을 수 있어서, 밖으로 나갈 문장은 결국 하나씩 봐야 합니다.
• 근거 칸을 받아도 확인 방법 자체가 틀렸다면 근거도 같은 방향으로 틀립니다. 근거로 받은 값을 사람이 한 번은 원문과 대 봐야 합니다.
• 재현이 안 되는 항목은 틀렸다고 단정할 수도 없습니다. 그때만 그랬을 수도 있어서 결론에서 빼는 데까지만 합니다.