Agent는 어떻게 도구를 호출하는가

결론부터 말하면 모델은 함수와 API를 직접 실행하지 않습니다. 모델의 역할은 현재 문맥을 읽고 다음 행동을 선택한 뒤, 그 의도를 구조화된 요청으로 표현하는 데까지입니다. 파일을 읽거나 네트워크 요청을 보내고 데이터베이스를 바꾸는 일은 모델 바깥의 runtime이 맡습니다.

이 구분이 흐려지면 tool calling, agent framework, server-side tool, MCP가 모두 비슷한 마법처럼 보입니다. Agent를 이해할 때 가장 먼저 분리해야 할 것은 결정과 실행입니다.

1. Runtime이 system instruction, 대화 이력, tool schema를 context로 구성합니다.
2. 모델이 일반 텍스트 또는 구조화된 tool request를 출력합니다.
3. Runtime이 schema와 permission을 검증한 뒤 실제 도구를 실행합니다.
4. Tool result를 다음 모델 호출의 context에 다시 넣습니다.
5. 더 이상 tool request가 없을 때까지 반복하고 최종 결과를 반환합니다.

while (step < maxSteps) {
  const response = await model(context, toolSchemas)
  if (!response.toolRequest) return response.text

  const request = validate(response.toolRequest)
  const result = await executeWithPolicy(request)
  context = appendToolResult(context, request.id, result)
}

네 번째 단계가 빠지면 모델은 실행 결과를 알 수 없습니다. 우리가 흔히 “agent가 기억했다”고 부르는 연속성도 대부분 context replay, state restoration, summary, checkpoint가 만든 결과입니다.

추상화가 높아질수록 개발자는 loop를 덜 보게 됩니다. 그러나 timeout, 중복 호출, 무한 반복, 승인, 비용 제한을 설계하려면 감춰진 상태 전이를 다시 펼쳐 볼 수 있어야 합니다.

Tool calling 예제를 볼 때 최종 문자열만 확인하면 중요한 과정이 사라집니다. 각 step에서 model input, tool request, validation result, tool latency, tool result 요약, 다음 model input을 함께 기록해야 실패가 선택 오류인지 실행 오류인지 구분할 수 있습니다.

• 모델이 tool 없이 답한 case와 tool을 선택한 case를 비교합니다.
• 필수 argument를 누락하거나 잘못된 type을 만들었을 때 복구 경로를 확인합니다.
• 같은 side effect가 재시도로 두 번 실행되지 않는지 검사합니다.
• maxSteps, timeout, cancellation이 실제 loop를 멈추는지 확인합니다.
• Tool result가 다음 context에서 어느 call id와 연결되는지 추적합니다.