AI가 "등록 완료 ✅"라고 보고했는데, DB에는 아무것도 없었습니다

영업 건 하나를 채팅으로 등록해 달라고 시켰습니다. 내부 프로젝트 관리 도구에 붙여둔 웹 채팅 AI였고, 오픈소스 모델을 직접 서빙하는 구성이었습니다. AI는 곧바로 답했습니다. "영업 건을 등록 완료했습니다 ✅"

목록을 열어봤는데 아무것도 없었습니다. 데이터는 만들어지지 않았는데 완료 보고만 온 겁니다. 이게 사내 데모 자리였다면 그 자리에서 "역시 AI는 못 믿겠다"는 결론이 났을 상황입니다.

실제로 AI 도입 논의에서 가장 자주 나오는 반대가 이 문장입니다. "쟤네는 거짓말을 한다." 이번 사건을 층위별로 파보니 그 문장은 절반만 맞았습니다. 거짓 보고는 맞는데, 거짓말을 만든 건 모델이 아니라 시스템이었습니다. 결함은 세 겹이었습니다.

결함 1층 — 그 도구는 애초에 존재하지 않았다

첫 확인은 단순했습니다. 모델이 호출한 도구명이 실행 로그에 있는지부터 봤습니다. 호출 기록은 있는데, 채팅 에이전트에 등록된 도구 목록에는 그 이름이 없었습니다.

원인은 레지스트리 이원화였습니다. 같은 도구 목록이 MCP 서버용 레지스트리와 채팅 에이전트용 레지스트리 두 곳에 갈라져 있었고, 영업 도구들은 MCP 쪽에만 추가돼 있었습니다. 채팅 에이전트 입장에서는 영업 도구가 세상에 없는 상태였습니다.

그런데 모델은 "그런 도구는 없습니다"라고 하지 않았습니다. 학습된 관례대로 그럴듯한 도구명을 만들어 호출했습니다. 도구명 환각입니다. 여기까지만 보면 모델 탓 같지만, 다음 층에서 얘기가 달라집니다.

결함 2층 — 모르는 것이 덜 안전한 쪽으로 떨어졌다

이 시스템의 쓰기 도구는 화이트리스트 기반으로 게이트를 거칩니다. 쓰기로 분류되면 프리뷰 카드를 띄우고 사용자가 승인해야 실행됩니다. 읽기로 분류되면 확인 없이 자동 실행됩니다.

미등록 도구는 화이트리스트에 이름이 없으니 읽기로 오분류됐습니다. 데이터를 만들려는 호출이 승인 게이트를 그대로 통과해 자동 실행된 겁니다. 실행기는 미지원 도구라며 400을 반환했습니다.

여기서 설계 결함 하나가 드러납니다. 미지의 입력이 더 보수적인 분기가 아니라 덜 안전한 분기로 떨어지고 있었습니다. "목록에 없으면 읽기 취급"이라는 규칙은 사실상 미등록 도구에게 게이트 우회로를 열어주는 규칙이었습니다.

결함 3층 — 실패가 로그에만 남고 모델에게 가지 않았다

가장 무거운 결함은 마지막에 있었습니다. 실행기가 반환한 400을 서버는 warn 로그로만 남기고, 모델에게 돌려주는 도구 결과 목록에는 넣지 않았습니다.

모델 입장에서 재구성하면 이렇습니다. 도구를 호출했고, 에러가 돌아오지 않았고, 거부도 없었습니다. 호출이 조용히 사라진 겁니다. 그 상태에서 다음 턴이 오면 모델이 할 수 있는 가장 그럴듯한 추론은 "성공했다"입니다.

로그는 사람을 위한 것이고, 컨텍스트는 모델을 위한 것입니다. 로그에만 남은 실패는 모델에게는 일어나지 않은 일입니다. 성공 환각의 직접 원인은 모델의 상상력이 아니라, 실패 신호를 삼킨 파이프라인이었습니다.

도구 호출이 서버 단에서 소리 없이 사라지는 무음 실패는 이번이 처음도 아니었습니다. 지난번에는 도구 왕복 자체가 조용히 끊기고 있었습니다.

수정 — 도구 하나가 아니라 재발 클래스를 닫았다

선택지는 세 개였습니다. 프롬프트에 "없는 도구를 부르지 마라"를 추가하는 증상 대응, 누락된 그 도구 하나만 추가하는 부분 수정, 그리고 실패 되먹임의 일반화. 앞의 둘은 다음 미등록 도구에서 같은 사건이 재발합니다.

실제 수정은 두 갈래로 갔습니다. 하나는 누락된 영업 도구를 채팅 레지스트리에 추가하는 것. 당연히 쓰기로 분류해 다른 쓰기 도구와 같은 승인 게이트를 태웠습니다.

다른 하나가 본질 수정입니다. 도구 실행이 실패하면 에러 내용을 그대로 도구 결과에 담아 모델에게 되먹이도록 바꿨습니다. 특정 도구가 아니라 전 도구에 일반 적용했습니다. 이제 모델은 "그 도구는 존재하지 않는다", "실행이 실패했다"를 같은 턴에 알고 스스로 정정합니다.

다만 되먹임에도 주의점이 있습니다. 외부 시스템이 만든 에러 문자열을 모델 컨텍스트에 넣는 것이므로 프롬프트 인젝션 표면이 넓어질 수 있고, 모든 실패를 되먹이면 모델이 같은 호출을 반복하는 재시도 루프가 생길 수 있습니다. 재시도 한도나 "이 도구는 존재하지 않음" 같은 종결형 메시지가 함께 가야 합니다.

"AI가 거짓말한다"는 보고를 받았을 때

이 사건의 세 결함 중 모델 탓은 하나도 없었습니다. 모델은 주어진 불완전한 정보 안에서 일관되게 행동했습니다. 도구 목록에 없으니 이름을 지어냈고, 실패를 보지 못했으니 성공을 보고했습니다.

물론 모델 쪽이 원인인 반대 사례도 있습니다. 로컬 LLM이 할 수 있는 일을 "못 한다"고 보고했던 사건은 시스템이 아니라 모델의 메타인지가 문제였습니다. 두 사례를 나란히 보면 어느 쪽부터 의심할지 감이 잡힙니다.

그래서 AI 도입 의사결정자에게 드릴 수 있는 해석 기준은 이렇습니다. "AI가 거짓말한다"는 보고는 대개 모델의 도덕성 문제가 아니라, 시스템이 실패 신호를 삼키고 있다는 신호입니다. 모델 교체를 검토하기 전에 파이프라인 감사를 먼저 하는 쪽이 싸고 빠릅니다.

에이전트 파이프라인을 점검할 때 이번 사건에서 나온 항목들입니다.

도구 실행 결과가 성공이든 실패든 반드시 모델 컨텍스트로 돌아가는가 — 로그에만 남는 실패가 없는가

화이트리스트 미등록 항목이 차단·확인 등 가장 보수적인 분기로 떨어지는가

같은 도구 목록을 두 곳 이상에서 들고 있지 않은가 — 단일 소스에서 파생하고 채널별 노출은 필터로 처리하는가

에러 문자열을 모델에 되먹일 때 신뢰 경계(프롬프트 인젝션)를 검토했는가

실패 되먹임에 재시도 한도나 종결형 메시지가 함께 설계돼 있는가

수정 이후 같은 요청을 다시 시키면, 모델은 도구가 없거나 실패했다는 사실을 그 턴에 보고받고 정정합니다. 거짓 성공 보고의 재발 경로는 구조적으로 막혔습니다. 같은 보고를 받게 된다면, 모델을 의심하기 전에 실패가 모델에게 돌아가고 있는지부터 확인해 보시기 바랍니다.