Tool Calling은 에이전트가 외부 세계와 만나는 지점입니다. 따라서 가장 먼저 망가지는 곳도, 가장 먼저 복구 전략을 넣어야 하는 곳도 여기입니다.
이 글은 호출 실패를 어떻게 감지하고, 어떤 순서로 다시 시도하며, 언제 다른 도구로 우회할지 정리합니다.
개요 #
Tool Calling 실패는 대부분 입력이 나쁘거나, 도구가 느리거나, 결과 형식이 기대와 다를 때 발생합니다. 문제는 호출 자체가 성공했다고 끝이 아니라는 점입니다. 응답이 왔더라도 그 응답이 안전하고 유효한지 확인해야 합니다.
관련 개념은 Tool Calling 실무 가이드, OpenAI Structured Outputs 실무 가이드, OpenAI Remote MCP 실무 가이드, MCP 서버 실무 가이드를 보면 연결이 잘 보입니다.
왜 중요한가 #
도구 호출은 종종 외부 API, DB, 파일 시스템, 승인 플로우까지 연결합니다. 여기서 한 번만 잘못돼도 결과가 틀릴 수 있고, 위험한 경우에는 실제 작업이 잘못 실행될 수도 있습니다.
그래서 복구 설계는 단순한 에러 처리보다 넓어야 합니다.
- 잘못된 파라미터를 빨리 잡아야 합니다.
- timeout과 rate limit은 재시도 정책으로 처리해야 합니다.
- 응답 형식 실패는 스키마 검증으로 차단해야 합니다.
- 위험한 결과는 사람 검토로 보내야 합니다.
실패 사례 #
대표적인 실패는 다음과 같습니다.
- timeout: 도구는 정상인데 응답이 늦음
- invalid arguments: 모델이 잘못된 파라미터를 전달함
- schema mismatch: 결과가 스키마와 다름
- partial success: 일부 데이터만 갱신되고 멈춤
- stale action: 오래된 상태로 잘못된 작업을 실행함
이런 실패는 표면적으로 비슷해 보여도 복구 방법은 다릅니다.
복구 패턴 #
- 먼저 입력을 검증합니다.
- 호출 전에 스키마를 강제합니다.
- timeout은 짧은 재시도와 장기 fallback으로 나눕니다.
- 결과 검증에 실패하면 재질의를 한 번만 허용합니다.
- 위험도가 높으면 사람 검토 지점으로 넘깁니다.
실무에서는 Structured Outputs와 tool schema를 같이 쓰는 편이 좋습니다. 하나는 모델이 틀린 구조를 내보내는 걸 줄이고, 다른 하나는 도구 쪽에서 잘못된 입력을 바로 끊어줍니다. Agent Debugging과 OpenAI Agent Evals를 붙이면 같은 실패가 다시 발생하는지도 확인할 수 있습니다.
아키텍처 도식 #
복구가 잘 되는 tool calling은 보통 4개 계층으로 나뉩니다.
- policy layer: 무엇을 호출할 수 있는지 결정
- validation layer: 입력과 출력의 형식 검사
- execution layer: 실제 호출과 timeout 처리
- recovery layer: retry, fallback, human review
이렇게 나누면 실패가 생겨도 호출 전, 호출 중, 호출 후 중 어디서 끊어야 할지 명확해집니다.
체크리스트 #
- 호출 전 입력 검증이 있는가
- timeout과 rate limit을 구분하고 있는가
- schema mismatch를 자동으로 차단하는가
- 재시도 횟수와 간격이 명확한가
- 실패 시 fallback tool이 준비되어 있는가
- 위험한 작업은
Human in the Loop로 전환되는가
결론 #
Tool Calling의 안정성은 성공률만이 아니라 복구 품질로 판단해야 합니다. 실패를 숨기지 말고, 실패별로 복구 경로를 분리하면 운영 난도가 크게 내려갑니다.