AI Agent를 운영하는 사람이라면 누구나 겪어봤을 법한 순간을 상상해 보세요. 작업이 절반쯤 진행되었는데 상황이 잘못되기 시작합니다. Agent가 몇 단계 전부터 이상한 방향으로 틀어지더니, 이제는 확신에 찬 태도로 잘못된 곳을 향해 가고 있습니다.

당신은 빠르게 결정해야 합니다. 개입해야 할까요? 만약

• 검색할 수 있었던 답변을 스스로 지어냅니다. 필요한 정보가 도구 호출 (tool call) 바로 뒤에 놓여 있음에도 불구하고, 모델은 호출을 수행하지 않은 채 그 공백을 그럴듯한 내용으로 채워버립니다. 예를 들어 "manager: #202"라고 읽고도 #202가 누구인지 찾아보지 않은 채, 그냥 이름을 단정 지어 말해버리는 식입니다.

• 불평하지 않는 도구를 신뢰합니다. 20260730 같은 날짜나 1430 같은 시간을 입력하면, 이를 마치 숫자처럼 취급하여 계산기 (calculator)에 그대로 넘겨버립니다. 계산기는 에러를 발생시키지 않고 어떤 숫자를 반환하며, 이 에러 없는 결과는 전혀 말이 안 되는 계산에 대한 승인 도장이 되어버립니다. 도구가 헛소리를 "검증"해버린 것입니다.

두 번째 사례는 우리가 보통 에러를 분류하는 방식을 교묘하게 빠져나가기 때문에 까다롭습니다. 에러는 발생하지 않았습니다. 실제 도구가 실제로 실행되었습니다. 에러 신호를 감시하는 어떤 모니터링 시스템도 이를 그냥 지나치게 됩니다.

내가 가장 좋아하는 발견: 예의가 아니라 권한의 문제다

이 부분이 에이전트 (agent)를 수정하는 것에 대한 제 생각을 바꿔놓았습니다.

저는 다양한 수정 유도 (repair nudges) 방식들을 테스트했습니다. 어떤 것은 명령문 형태로, 어떤 것은 평서문 형태로 구성했습니다. 저는 문구의 _표현 방식 (phrasing)_이 중요할 것이라고 예상했습니다. 하지만 그렇지 않았습니다. 중요한 것은 더 좁은 범위에 있었습니다. 유도 문구가 에이전트에게 다시 돌아가서 누락된 작업을 수행할 권한을 부여하는가? 하는 점이었습니다.

다음 두 가지를 보십시오. 문법적으로는 거의 동일합니다. 유일한 차이점은 에이전트에게 확인을 허용한다는 짧은 절 (clause) 하나가 포함되었는지 여부입니다.

문장은 같지만, 절 하나가 다릅니다. 이것이 에이전트가 어깨를 으쓱하며 지어낸 답변을 다시 주장하는 것과, 실제로 다시 돌아가서 건너뛰었던 조회를 수행하고 정답을 찾아내는 것 사이의 간극입니다. 저는 이를 **행동 허가 (action-licensing)**라고 부릅니다. 수정 방식이 특정 문구로 작성되었을 때가 아니라, 교정 행동을 허가할 때 수정이 효과를 발휘합니다.

솔직히 말씀드리자면, 이 모든 것의 정신과 관련하여 한 가지 고백할 것이 있습니다. 저는 원래 다른 문구 스타일이 원인이라고 생각했습니다. 하지만 더 많은 데이터가 그 생각을 무너뜨렸습니다. '승리한' 것은 우연히 허가를 내린 것도 같은 경우였기 때문입니다. 그래서 이전 설명을 철회하고 실제 설명만 남겼습니다.

말로 해결할 수 없는 실패 사례들

스키프-룩업(Skipped-lookup)은 복구 가능합니다. 하지만 '도구 검증 무의미값' 문제는 그렇지 않습니다. 적어도 단어로는요. 저는 모든 텍스트 수준의 수정 방식을 시도해봤지만, 복구율은 바닥 근처에 머물렀습니다.

이것이 흥미로운 이유는 다음과 같습니다. 실행을 오염시킨 것은 프롬프트가 아니라 _도구 결과(tool result)_였기 때문입니다. 에이전트는 도구가 '확인'한 깨끗하고 잘 구성되었지만 완전히 틀린 숫자를 가지고 있습니다. 질문을 다시 읽으라고 해도, 그 잘못된 승인의 스탬프를 지우지 못합니다. 왜냐하면 이 스탬프는 프롬프트 안에 존재하지 않기 때문입니다. 따라서 거기서부터는 도달할 수 없습니다.

유용한 결론은 다음과 같습니다. 어떤 실패는 프롬프트의 형태를 띠고 있고, 어떤 실패는 그렇지 않으며, 아무리 프롬프트를 수정해도 후자(도구 결과로 인한 실패)는 해결되지 않는다는 것입니다.

알아두면 좋은 두 가지 추가 사항

초기에 포착하세요. 에이전트가 스킵을 당하기 전에 작업에 깊숙이 들어갈수록, 어떤 수정 방식이 되돌려주는 가치는 줄어듭니다. 초기에 잘 복구되는 명령어 스타일의 넛지(Command-style nudges)는 나중에 실수를 발견했을 때는 거의 0으로 수렴합니다.

모델 간 비교에 주의하세요. 저는 두 번째, 관련 없는 모델을 사용해봤습니다. '답변 지어내기(make-up-an-answer)' 실패가 그 모델에서도 나타났기 때문에, 이것이 단일 모델의 특성만은 아닙니다. 하지만 저는 이 모델에서 복구를 테스트할 수 없었습니다. 애초에 도구 호출 자체가 충분히 신뢰성이 높지 않았고, 모든 수정 방식은 에이전트가 도구 호출을 다시 발행하는 것에 달려있기 때문입니다. 따라서

솔직히 말씀드리면, 과장해서 말씀드리지 않겠습니다. 모든 복구 수치는 하나의 주요 모델로부터 도출되었습니다 (두 번째 모델은 _메커니즘 (mechanism)_은 확인해주었으나 복구 테스트는 수행할 수 없었습니다). 이는 깨끗한 합성 샌드박스 (synthetic sandbox) 환경입니다. 이러한 환경 덕분에 확실한 그라운드 트루스 (ground truth)를 확보할 수 있었지만, 복잡한 실제 환경의 워크로드 (workload)는 아닙니다. 또한 몇몇 작은 수치들은 정밀한 측정값이 아닌 방향성을 나타내는 추세일 뿐입니다. 이것은 초기 단계의 신중한 결과이며, 최종 결론은 아닙니다.

에이전트를 구축한다면, 세 가지 교훈

1. 정체된 에이전트를 독려할 때는, 작업을 다시 수행할 수 있는 권한을 부여하세요 — 단순히 원하는 바를 다시 말하기만 해서는 안 됩니다.
2. 모든 실패를 프롬프트 수정 (prompt-fixable)으로 해결할 수는 없습니다. 만약 도구가 잘못된 데이터를 "검증 (validated)"했다면, 모델과 대화하는 것만으로는 이를 되돌릴 수 없습니다. 그것은 도구 측면의 가드레일 (guardrails)이 담당해야 할 영역입니다.
3. 실패를 조기에 포착하고, 도구 호출을 안정적으로 수행하지 못하는 모델을 대상으로 복구 성능을 벤치마크 (benchmark)하지 마세요.