8. 결과가 이상할 때, 내부에선 무슨 일이

5장에서 배운 파이프라인 기억나? 조립→추론→해석→실행→재조립. 문제가 생겼다는 건 이 중 어느 한 단계에서 어긋난 거야. 첫 번째로 의심할 곳은 어디일까?

맞아, 실무에서 가장 흔한 원인이야. 모델은 빠진 정보를 "그럴듯하게" 채워넣게 설계돼 있어서, 지시가 애매하면 니가 기대한 것과 다른(하지만 나름 말이 되는) 방향으로 갈 수 있어. 해결책은 지시를 더 구체적으로 주거나, 모델이 스스로 되묻게 유도하는 거야.

그건 3장에서 배운 컨텍스트 윈도우 압축 문제일 확률이 높아. 세션이 길어지면 오래된 부분을 요약해서 압축하는데, 그 과정에서 디테일이 손실될 수 있거든. 이럴 땐 중요한 정보는 다시 한번 짧게 상기시켜주는 게 실용적인 해결책이야.

그건 ②추론이나 ③해석 단계 문제야. 두 가지 경우가 있어 — (a) 도구 설명 자체가 모호해서 모델이 헷갈렸거나, (b) 비슷한 이름의 도구가 여러 개 있어서 잘못 골랐거나. 4장에서 배운 MCP 쪽 얘기인데, 도구를 설계할 때 이름과 설명을 명확히 하는 게 실제로 결과 품질에 큰 영향을 줘.

제일 중요한 지점을 짚었어. 기억해봐 — 모델은 결국 "다음 토큰을 그럴듯하게 예측"하는 애야. "완료했습니다"라는 문장도 실제로 확인해서 쓴 게 아니라, 대화 흐름상 그럴듯해서 예측해버릴 수 있어. 그래서 잘 설계된 하네스는 "완료"라고 말하기 전에 반드시 실제로 확인하는 도구 호출(파일이 있는지, 서버가 응답하는지)을 거치도록 규칙을 심어둬. 이게 바로 검증 없는 완료 선언이라는 대표적인 실패 패턴이고, 이 가이드를 만든 나(에이전트)도 실제로 이 규칙을 지키도록 설계돼 있어 — 무언가 "다 됐다"고 말할 땐 항상 URL, 파일 경로, 실행 결과 같은 증거를 같이 보여주는 식으로.