AI 에이전트가 왜 죽는지 로그를 남겨봤는데, 모델이 멍청해서 그런 경우는 거의 없었음
I started logging why my agent runs die and almost none of it was the model being dumb
핵심 요약
AI 에이전트 실패 원인을 분석한 결과, 모델의 지능 문제보다는 도구 호출 오류나 빈 결과값 처리가 주된 원인임을 발견함.
- 실패 원인 분석 — 도구 호출 오류와 상태 드리프트가 실패의 대부분을 차지함.
- 빈 결과값 문제 — 에이전트가 빈 결과를 성공으로 오인하여 후속 작업이 오염되는 현상이 발생함.
- 도구 호출 최적화 — 모델의 성능보다 도구 호출의 구조적 안정성이 에이전트 운영에 더 중요함.
- 실패 모드 공유 — 커뮤니티에서 에이전트 실패 사례와 해결책을 공유하며 논의함.
4주간의 로그, 하나의 프로젝트를 바탕으로 한 것이니 샘플의 한계는 감안해 주세요. 실패한 모든 실행에 대해, 표면적으로 드러난 문제보다는 실제로 무엇이 잘못되었는지 첫 번째 원인을 기록했습니다.
대략 이렇게 나뉘더군요. 대부분은 도구 호출 형식이 잘못되었거나 잘린 경우였습니다. 상태가 세 단계 전으로 돌아가 버려서 올바른 도구를 엉뚱한 경로에 사용한 경우도 있었고요. 호출은 맞았는데 결과가 비어있는 경우, 에이전트는 빈 결과를 성공으로 간주하고 계속 진행해 버립니다. 실제로 모델의 추론이 나빴던 경우는 가장 적었고, 그마저도 보통은 복구가 가능한 수준이었습니다.
저를 가장 두렵게 만드는 건 세 번째 버킷입니다. 재시도 가능한 충돌은 괜찮습니다. 하지만 빈 결과에 대해 '조용한 성공'이 발생하면 모든 후속 작업이 오염되고, diff를 읽기 전까지는 실행이 잘 된 것처럼 보이니까요.
그래서 제가 요즘 저렴한 실행기(executor)에서 확인하는 건, 모델이 어떤 점수를 받느냐가 아니라 세션 깊숙한 곳까지 도구 호출이 잘 유지되는지 여부입니다. Ling-3.0-flash는 직접 관리해야 하는 정규식(regex) 대신 자체 도구 호출 형식을 위한 네이티브 파서를 제공하고, vLLM 포크는 자동 도구 선택 기능을 지원해서 호출이 꼬이는 단계를 하나 줄여줍니다. 아직 몇백 번 정도밖에 실행해보지 않았으니 검증된 결과라고 보기는 어렵습니다.
여러분은 어떤 비율로 실패가 발생하나요? 잘못된 호출 버킷이 모두에게 이렇게 큰 비중을 차지하는지, 아니면 제가 뭔가 너무 취약하게 만든 건지 궁금합니다.
