AI가 "약속했다"고 적었는데, 그런 약속은 없었습니다 🪞

돈독(제가 만드는 자산관리 앱, https://don-doc.com )을 매일 점검하는 AI 에이전트가 넷 있습니다. 기획·개발·디자인·마케팅을 하나씩 맡아서, 어제 코드가 어떻게 바뀌었는지 오늘 아침 리포트로 남깁니다. 저는 그걸 커피 마시면서 훑어보는 게 하루 루틴입니다.
지난주 그 루틴 중에 좀 이상한 걸 봤습니다. 기획 담당 에이전트가 “디자인 담당이 며칠 전에 하기로 약속한 일을 아직 안 했다”고 적어놨습니다. 반나절쯤 지나서 디자인 담당 리포트를 열었더니, 정정문이 붙어 있었습니다. 그런 약속을 한 적이 없다는 겁니다.
아침엔 이런 문장이 붙어 있었습니다
8월 27일 아침, 기획 담당 에이전트가 “부부 v2”라는 기능 스펙 문서가 아직 vault에 없다고 지적하면서 이렇게 적었습니다. “8/24 팀 결정에서 디자인 담당이 ‘다음 세션 1순위 착수’를 약속했다고 기록에 남아 있는데, 아직 착수 흔적이 없다.” 우선순위 P1로 다시 올라갔습니다.
원문에는 그런 말이 없었습니다 🧐
그날 오후, 디자인 담당 에이전트가 자기 몫의 점검을 돌리다가 이 지적을 마주쳤습니다. 그런데 그냥 넘어가지 않고 원문을 다시 열었습니다. 8월 24일 자 자기 리포트를요. 거기엔 그런 문장이 없었습니다. 워드마크 오탈자 확인, 이전에 지적한 것들 재확인 — 그게 전부였고, “부부 v2”는 언급조차 안 돼 있었습니다.
진짜 근거는 다른 곳에 있었습니다. 사용자(저)가 몇 주 전 프로젝트 개요 문서에 직접 남긴 문장이었습니다. “부부 v2는 신호를 더 모을 때까지 보류한다.” 누군가 착수를 미룬 게 아니라, 애초에 미루기로 정해둔 일이었던 겁니다.

다음 날 아침, 기획 담당 에이전트가 다시 돌면서 스스로 이렇게 적었습니다. “지난 라운드에서 근거 없이 갭으로 잘못 짚은 점을 바로잡는다.” 있지도 않은 약속을 지적하고, 하루 만에 스스로 정정한 겁니다.
없는 약속을 지적한 것도, 그걸 바로잡은 것도 같은 시스템 안에서 벌어졌습니다.
왜 이런 문장이 생겼을까
정확히 어느 지점에서 “약속”이라는 표현이 처음 붙었는지는 로그를 다시 뒤져봐도 재구성이 안 됩니다. 다만 구조는 짐작이 갑니다. 이 네 에이전트는 매번 새로 도는 게 아니라, 직전 라운드들이 남긴 기록(vault의 로그·리포트)을 먼저 읽고 그 위에 이번 라운드 리포트를 씁니다. 리포트가 리포트를 요약하는 체인이 며칠씩 이어지면, “보류하기로 했다”가 “착수하기로 했는데 안 했다”로 슬쩍 뒤집혀도 이상하지 않습니다. 둘 다 “부부 v2”와 “8/24”라는 같은 단어를 공유하고 있으니까요.
이게 잡힌 이유는 운이 아니었습니다. 이 에이전트들은 애초에 “이전 리포트 요약”이 아니라 “vault 원문 파일”을 매번 다시 읽도록 만들어 놨습니다. 디자인 담당이 지적을 그대로 받아 적지 않고 8월 24일 자 자기 리포트 파일을 실제로 다시 열어본 것도 그 설계 때문입니다. 만약 “요약의 요약”만 참고하는 구조였다면, 이 문장은 아마 다음 라운드로, 그다음 라운드로 계속 넘어갔을 겁니다.
하루 안에 잡혔다는 것도 중요합니다. 기획 담당 에이전트는 격주로 돕니다. 만약 정정이 다음 정기 라운드까지 늦어졌다면, 그 사이 저는 리포트만 보고 “그럼 착수 승인해야겠네” 하고 실제로 뭔가를 움직였을 수도 있습니다. 있지도 않은 근거로요.
사람도 똑같이 걸립니다
이 일을 겪고 나서 든 생각은, 에이전트만의 문제가 아니라는 겁니다. 저도 회의록을 요약하고, 그 요약을 다시 누군가에게 전달할 때 비슷한 실수를 합니다. “A가 하기로 했다”와 “A가 언젠가 하면 좋겠다고 했다”는 원문에선 분명히 다른 문장인데, 두세 다리 건너면 자주 뒤섞입니다. 에이전트가 이번에 보여준 건 그 실수를 더 빠르게, 더 자주 반복할 수 있다는 것과, 동시에 그만큼 빠르게 잡아낼 수도 있다는 것이었습니다.
따라 하기
여러 AI 에이전트가 서로의 산출물을 이어받는 구조를 짜고 있다면, 아래 한 가지를 에이전트 정의에 못 박아 두는 걸 권합니다.
다른 에이전트의 주장을 인용할 때는 원문을 다시 연다
다른 에이전트의 리포트에서 "~를 약속했다"·"~가 미이행됐다" 같은
결론성 문장을 발견하면, 그 문장을 그대로 재인용하지 않는다.
대신 그 주장의 출처로 지목된 원문 파일을 직접 다시 읽어
같은 문장이 실제로 있는지 확인한다.
확인이 안 되면 "근거 확인 안 됨"이라고 쓰고, 있는 그대로 넘기지 않는다.
왜 필요한가 — 이번 일에서 정정이 가능했던 유일한 이유가 이겁니다. 디자인 담당이 “그런 말 한 적 없다”를 확인할 수 있었던 건, 구체적인 파일 하나를 다시 열 수 있었기 때문입니다. 에이전트 정의에 이 한 줄이 없으면, 다음에도 “재인용이 재인용을 부르는” 라운드가 반복될 수 있습니다. 저는 이번 일 이후로 이 문장을 기획·개발·디자인·마케팅 네 에이전트 정의에 공통으로 추가하기로 했습니다.
작은 파이프라인이라도 마찬가지입니다. 정기 리포트든, 요약 자동화든, 어떤 산출물이 다른 산출물을 요약해서 다음 산출물의 입력이 되는 구조라면, “원문 대조 없이 재인용 금지” 한 줄이 이번처럼 하루 안에 문제를 잡아주는 방어선이 됩니다.
마무리
에이전트를 여러 개 굴리면서 은근히 안심했던 부분이 있습니다. “기록이 vault에 다 남으니까 나중에 확인하면 되지.” 그런데 이번에 보니 기록 자체가 틀릴 수 있다는 걸 놓치고 있었습니다. 다행히 이번엔 같은 날 안에, 같은 시스템 안에서 잡혔습니다. 그게 우연이 아니라 설계였다는 걸 확인한 것만으로도, 이번 일은 저한테 하나 벌어놓은 셈입니다.

오늘도 차분히 한 걸음. 🐴
이 글은 산업 구조와 만드는 과정을 정리한 개인 기록입니다.
특정 종목의 매수·매도 추천이 아니며, 투자 판단과 그 결과는 독자 본인에게 있습니다.