저는 주로 혼자서 운영하며, AI 하위 에이전트(Subagents)가 많은 잡무를 수행하도록 하는 소규모 오픈 소스 비즈니스 도구들을 운영하고 있습니다. 이 에이전트들은 여러 저장소(repos)를 읽고, 문서를 초안하고, 실제 코드와 대조하여 주장을 교차 검증하는 등의 일을 합니다.

한동안 이 설정에서 제가 겪었던 문제는 잘못된 코드가 아니었습니다. 바로 '자신감 넘치는 문체'였습니다.

에이전트가 "이것은 프레임워크 내에서 표준화되었습니다"라고 작성하면, 그것은 매우 그럴듯하게 들립니다. 실제로 프레임워크에 그와 '유사한' 무언가가 있기도 해서, 만약 제가 직접 확인하지 않았다면 단순히 사실이 아닌 문장을 그대로 배포했을 것입니다. 악의적인 의도가 있었던 것은 아닙니다. 그저 모델이 공백을 그럴듯한 내용으로 메우려 했던 것뿐입니다.

그래서 저는 모든 하위 에이전트가 받는 지침(instructions)에 한 단락을 추가했습니다.

추가된 단락

그리 영리한 방법은 아닙니다. 모든 작업에 적용되는 고정 규칙입니다:

• 인용하거나 버려라 (Cite it or drop it). 모든 주장은 명시된 출처(파일, PR, 코드 라인 등)로부터 나와야 한다. 출처를 밝힐 수 없다면 단정 짓지 마라. 해당 내용을 건너뛰고 건너뛰었다고 말하라.
• 존재 여부를 확인하지 않은 앵커(anchors)로 링크를 걸지 마라.
• 수행하지 못한 것을 보고하라. 건너뛴 단계는 정보이지, 숨겨야 할 실패가 아니다.
• 관련 없는 변경 사항에는 손대지 마라. 시작하기 전에 git status를 확인하라.

이것이 전부입니다. 프레임워크도, 평가 하네스(eval harness)도 없습니다. "자신감 있게 말하기"를 "증거를 제시하기"로 바꾸는 짧은 목록일 뿐입니다.

에이전트들이 이 규칙을 적용한 방식

흥미로운 점은 에이전트들이 스스로를 감시하기 시작했다는 것입니다.

한 실행 사례에서, 에이전트가 기능을 문서화하던 중 형제 저장소(sibling repo)의 문구를 재사용하려 했습니다 — "여기서 동기화가 표준화되었습니다." 에이전트는 확인 결과 형제 저장소에 그런 내용이 없음을 발견했고, 스스로 해당 주장을 제외한 뒤 출처를 찾을 수 없다는 노트를 남겼습니다.

또 다른 사례에서는 존재하지 않는 특정 섹션으로 딥링크(deep-link)를 걸려고 했습니다. 에이전트는 앵커를 지어내는 대신, 파일 수준의 링크로 대체하고 이를 플래그(flag) 처리했습니다.

그리고 제가 계속 생각하는 사례가 있습니다. 에이전트에게 어떤 작업물이 '2단계(Phase 2), 진행 중'이라고 지시를 받은 적이 있습니다. 에이전트는 현재 상태를 확인하러 갔고, 해당 단계가 이미 며칠 전에 배포된 것을 발견하여 제가 준 지시 자체를 수정했습니다.

마지막 사례가 중요합니다. 가드레일은 단순히 _에이전트_가 거짓말하는 것을 막는 것이 아니었습니다. '기록과 대조하라(verify against the record)'라는 것은 양방향으로 작용하기 때문에, 저의 오래된 가정까지 잡아냈던 것입니다.

그리고 실제로 저를 잡았습니다

이 부분이 이 모든 것의 핵심입니다.

저는 에이전트에게 기술 아티클을 작성하도록 했습니다. 공유 호스팅 환경에서 발생했던 버그에 대한 실패 사례였습니다. 코드 스니펫 하나하나가 정확했습니다. 기본값(default value), 설정 세부 사항 등 모든 것이 레포지토리와 대조하여 확인되었습니다. 기술적으로는 완벽했습니다.

문제는 서술 방식이 허구였다는 것입니다.

아티클은 마치 실제로 발생한 운영 사고처럼 이야기했습니다: "저는 인메모리(in-memory) 버전을 배포했고, 테스트는 성공적이었으며, 실제 운영 환경에서는 한 번도 작동하지 않았습니다." 설득력이 있었습니다. 하지만 이것 역시 일어나지 않은 일이었습니다. git 히스토리는 명확했습니다. 해당 컴포넌트는 최초 커밋부터 파일 기반(file-backed)이었다는 것입니다. 인메모리 버전은 배포된 적이 없었습니다. 제가 1인칭 시점으로 서술하려 했던 '운영 사고'에는 코드나 기록상으로 흔적이 전혀 없었습니다.

가드레일 검토를 통해 이것이 출판되기 전에 잡혔습니다. 저는 새로운 초안들을 적대적 패스(adversarial pass)를 거치게 했습니다. 몇몇 리뷰어 페르소나와 실제 레포지토리 및 저의 작업 로그와의 엄격한 교차 확인을 거쳤고, 평가는 만장일치였습니다: 기술 내용은 사실이지만, 이야기는 꾸며낸 것이라는 것이었습니다. 해결책은 가짜 사고를 실제로 일어난 설계 결정(

교훈은 'AI를 더 신뢰하라'가 아니다

정반대입니다. 이 가드(guard)는 신뢰에 의존하지 않기 때문에 작동합니다. 따라서 출처를 명시하거나 아예 언급하지 않는 것이 가장 쉬운 방법이 되며, 그 덕분에 저렴한 움직임이 곧 정직한 움직임이 됩니다.

그리고 저는 제가 무엇을 방어하고 있었는지의 개념 자체를 재정립했습니다. 처음에는 에이전트가 API를 발명하는 것에 대해 걱정했습니다. 실제로 저를 위협했던 실패 모드는 더 미묘했습니다: 코드 수준에서는 사실이지만 이야기 수준에서는 허구인 산문(prose). 테스트 스위트로는 그것을 잡을 수 없습니다. 린터(linter)로도 그것을 잡을 수 없습니다. 오직 _서사(narrative)_를 기록과 대조하여 확인하는 것만이 가능합니다. 이는 가드가 이미 사실에 대해 요구했던 것과 같은 움직임이, 한 단계 높은 수준에서 적용된 것입니다.

그래서 정직성 가드는 첫 번째 인칭으로 작성된 모든 내용에 대해 두 번째 조항을 추가했습니다: 이야기 역시 검증 가능해야 하며, 코드뿐만이 아니다. '이것이 프로덕션 환경에서 고장 났다'는 것은 사실적 주장입니다. 이는 로그가 필요하며, 벤치마크(benchmark)가 숫자가 필요한 것과 같은 방식으로요.

제가 주장할 수 있는 것과 할 수 없는 것

제가 허위 정보가 영원히 제로가 되었다고 말씀드리지는 않을 것입니다. 저는 그에 대한 반증이 없으며, 정직한 증거 자체가 깨끗한 버전과는 상반되기 때문입니다. 제가 말할 수 있는 것은 더 좁고, 그리고 더 유용하다고 생각합니다:

• 가드(guard)가 프롬프트에 포함된 실행에서는 에이전트들이 그럴듯하지만 출처가 없는 주장으로 공백을 채우는 것을 멈추고, 대신 공백 자체를 보고하기 시작했습니다.
• 허위 정보가 초안까지 도달했을 때, 가드 검토(guarded review) — 페르소나와 기록 교차 확인 — 가 이를 출판 전에 포착했습니다.

두 가지 다른 메커니즘이지만 원칙은 같습니다: 영수증을 의무화하는 것. 사실 수준과 이야기 수준 모두에서요.

이 모든 것은 제가 판매할 프레임워크가 아닙니다. 이것은 프롬프트에 들어가는 네 문장과, 숫자가 아닌 서사를 확인하는 습관입니다.

당신의 AI 에이전트 지침에는 무엇이 포함되어 있나요? 그것들이 꾸며내는 것을 멈추게 하는 것은요 — 그리고 그것은 _사실_만을 다루고 있나요, 아니면 _이야기_까지 다루고 있나요?

── Hideyuki Mori (Ayane International) 🔗 hideyuki-mori.com

hideyukimori image

](/hideyukimori)

HideyukiMORI팔로우

자체 호스팅 비즈니스 워크플로우를 위한 API 우선 PHP 도구 구축 중. NENE2 및 NeNe OSS 시리즈의 제작자.