AI 에이전트의 작동 원리: 도구 선택에서 실행까지

“다음 주 화요일 오후에 김 연구원과 30분짜리 연구 회의를 잡아 줘.”

한 문장이지만 처리할 일은 여럿입니다. 사내 주소록에서 김 연구원을 찾고, 두 사람의 캘린더에서 함께 비어 있는 시간을 확인해야 합니다. 후보가 여러 개면 사용자에게 물어야 하고, 일정을 등록한 뒤에는 초대가 제대로 전송됐는지도 확인해야 합니다.

화면에는 AI가 이 모든 일을 처리한 것처럼 보입니다. 내부에서는 LLM과 에이전트 프로그램, 캘린더 API가 역할을 나눕니다. LLM은 요청을 해석해 다음 행동을 고르고, 필요한 도구의 이름과 인자를 구조화된 형태로 출력합니다. 이 출력이 Tool Call입니다. 에이전트 프로그램은 Tool Call을 검사해 실제 도구를 실행하고, 결과를 다시 LLM에 전달합니다.

한 문장이 일정으로 바뀌는 과정

회의 일정을 잡는 에이전트에는 주소록 검색, 빈 시간 조회와 일정 등록 도구가 연결돼 있습니다. 사용자가 요청하면 다음 순서로 일이 진행됩니다.

1. 애플리케이션이 사용자 요청과 현재 사용할 수 있는 도구의 설명을 LLM에 보냅니다.

2. LLM이 주소록 검색 Tool Call을 만들면 에이전트 프로그램이 사내 주소록에서 김 연구원을 찾습니다.

3. 검색 결과를 받은 LLM이 캘린더 조회 Tool Call을 만들고, 프로그램이 두 사람의 빈 시간을 확인합니다.

4. 후보가 하나면 정해진 정책에 따라 등록하거나 사용자에게 확인을 받습니다. 후보가 여러 개이거나 정보가 부족하면 LLM이 질문합니다.

5. 프로그램이 일정을 등록하고 결과를 돌려주면 LLM이 참석자와 시간을 확인해 완료 사실을 알립니다.

LLM이 내놓을 수 있는 다음 행동은 Tool Call만이 아닙니다. 동명이인이 나오거나 회의 시간이 빠졌다면 먼저 질문해야 합니다. 도구가 필요 없는 요청에는 바로 답할 수도 있습니다. 답변할지, 되물을지, 도구를 호출할지 알맞게 고르는 것이 에이전트용 LLM의 핵심 능력입니다.

LLM은 다음 답변이나 Tool Call을 생성합니다. AI 에이전트는 여기에 도구, 실행 프로그램, 작업 상태, 권한과 기록 체계를 더한 전체 시스템입니다.

일의 순서를 코드로 미리 정해 놓았다면 워크플로에 가깝습니다. 모델이 실행 결과를 보고 다음 도구와 순서를 그때그때 고르면 에이전트의 성격이 강해집니다. 실제 서비스에서는 두 방식을 섞습니다. 결제나 승인처럼 절차가 중요한 구간은 워크플로로 고정하고, 검색이나 문제 해결처럼 경로가 달라지는 구간은 LLM에 맡길 수 있습니다.

도구 이름과 인자는 어디에서 오는가

범용 LLM이 사내 캘린더 API를 미리 알고 있을 필요는 없습니다. 애플리케이션이 요청을 보낼 때 도구의 이름, 설명과 입력 형식을 함께 전달합니다. 다음은 참석자들이 모두 비어 있는 시간을 찾는 도구를 단순화한 예입니다.

{
  "type": "function",
  "name": "calendar_find_available_slots",
  "description": "로그인 사용자를 주최자로 포함해 참석자들의 공통 빈 시간을 찾는다.",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "attendee_ids": {
        "type": "array",
        "items": { "type": "string" },
        "description": "주최자를 제외한 참석자 계정 ID"
      },
      "date": {
        "type": "string",
        "description": "YYYY-MM-DD"
      },
      "time_range": {
        "type": "string",
        "enum": ["morning", "afternoon", "evening"]
      },
      "duration_minutes": { "type": "integer" }
    },
    "required": [
      "attendee_ids",
      "date",
      "time_range",
      "duration_minutes"
    ],
    "additionalProperties": false
  }
}

모델은 이 정의를 사용자 요청과 대화 기록, 앞서 실행한 도구의 결과와 함께 읽습니다. 도구 이름과 설명은 무엇을 할 수 있는지 알려주고, 스키마는 필요한 인자와 자료형을 정합니다. 도구 정의도 LLM의 입력에 포함되므로 도구가 많고 설명이 길수록 컨텍스트를 더 사용합니다.

auto 모드에서는 일반 답변과 Tool Call이 모두 출력 후보가 됩니다. 모델은 사용자 요청, 도구 설명과 이전 실행 결과를 바탕으로 다음 토큰의 확률을 계산합니다. Tool Call 형식을 택하면 도구 이름과 인자를 차례로 생성합니다. 도구 설명을 어떻게 쓰고 어떤 호출 사례를 학습했는지가 선택 결과에 영향을 주는 이유입니다.

예시 요청을 2026년 8월 5일에 받았고, 앞선 주소록 검색에서 김 연구원의 계정 ID를 u_1842로 확인했다고 해보겠습니다. LLM은 다음과 같은 Tool Call을 만들 수 있습니다.

{
  "name": "calendar_find_available_slots",
  "arguments": {
    "attendee_ids": ["u_1842"],
    "date": "2026-08-11",
    "time_range": "afternoon",
    "duration_minutes": 30
  }
}

도구 이름은 허용된 목록에서 골랐습니다. 참석자 ID는 주소록 검색 결과에서, 날짜와 시간대는 “다음 주 화요일 오후”에서 가져왔습니다. 회의 시간 30분도 사용자 요청에 들어 있습니다. 로그인한 사용자의 ID는 Tool Call 인자에서 빼고 실행 프로그램이 주최자로 넣습니다. 애플리케이션이 이미 아는 값까지 모델에 추측하게 만들면 인자가 길어지고 잘못된 계정을 넣을 여지도 생깁니다.

이름과 설명, 스키마가 분명하면 모델을 다시 학습하지 않고도 새 도구를 연결할 수 있습니다. 반대로 사내 용어가 낯설거나 비슷한 도구가 여럿이면 설명과 호출 예시를 보강하거나, 업무 데이터로 모델을 추가 학습할 수 있습니다.

도구 선택에는 모델의 학습 결과만 관여하지 않습니다. 시스템 지침과 허용 목록, 앞선 대화와 실행 결과, tool_choice 설정이 함께 영향을 줍니다. OpenAI와 Anthropic API는 모델이 답변과 도구 호출 사이에서 고르는 방식뿐 아니라, 특정 도구만 허용하거나 호출을 강제하는 방식도 제공합니다.

연결된 도구가 수백 개라면 모든 설명을 매번 넣기 어렵습니다. 이때는 검색이나 라우터로 후보를 먼저 좁힐 수 있습니다. 업무 절차에 따라 애플리케이션이 도구를 고정하고 LLM에는 인자만 채우게 하는 설계도 가능합니다.

오픈웨이트 모델을 직접 서빙할 때는 모델과 서빙 엔진 사이의 형식도 맞아야 합니다. Chat Template은 대화와 도구 정의를 모델이 학습한 형식으로 배치하고, Tool Call Parser는 모델의 출력을 API가 다룰 수 있는 구조로 바꿉니다. vLLM에서 모델에 맞는 Chat Template과 Parser를 지정하는 이유입니다.

JSON Schema의 strict 설정은 필드 누락과 자료형 오류를 줄입니다. 다만 구조가 맞는 호출과 업무에 맞는 호출은 별개의 문제입니다. 일정 조회가 필요한데 삭제 도구를 골랐거나 화요일을 수요일로 해석했다면 JSON이 완벽해도 작업은 실패합니다.

도구 사용은 학습하고, 이번 호출은 실행할 때 정한다

모델은 학습 과정에서 Tool Calling의 기본 능력을 익힙니다. 실제 요청에서 사용할 도구와 인자는 학습을 마친 모델이 실행 시점에 고릅니다. 공개된 모델 사례를 기준으로 보면 사전학습, SFT와 RL은 다음과 같이 기여합니다.

사전학습만 마친 모델도 익숙한 함수 호출을 흉내 낼 수 있습니다. 비슷한 도구를 구분하고 정해진 형식을 꾸준히 지키는 능력은 Tool Calling 사례를 담은 SFT로 다듬을 수 있습니다. 학습 데이터에는 도구 정의, 사용자 요청, 올바른 Tool Call, 실행 결과와 최종 답변이 한 흐름으로 들어갑니다.

Google의 FunctionGemma 학습 지침은 도구 사용 능력을 호출 형식과 의도 판단으로 나눠 설명합니다. JSON을 정확하게 써도 사용자의 목적과 맞지 않는 도구를 골랐다면 요청을 제대로 처리하지 못합니다. 학습과 평가에서는 호출 형식과 도구 선택을 각각 확인해야 합니다.

RL의 사용 범위는 모델마다 다릅니다. OpenAI는 gpt-oss의 사후학습에 SFT와 많은 연산을 투입한 RL을 사용해 추론과 도구 사용을 가르쳤다고 밝혔습니다. Qwen3-Coder는 코드를 실행해 받은 피드백과 여러 단계의 도구 사용 결과를 RL에 활용했습니다. 긴 작업에서는 한 번의 호출이 맞았는지보다 여러 선택을 거쳐 최종 목표를 달성했는지가 중요하기 때문입니다.

모델 개발사가 학습 데이터와 보상 설계를 모두 공개하는 경우는 드뭅니다. 같은 ‘Tool Calling 지원’ 모델도 도구 선택, 인자 작성과 여러 단계의 작업 능력은 다를 수 있습니다. 사용하려는 도구와 실제 요청으로 성공률을 확인해야 합니다.

호출 뒤의 일은 에이전트 프로그램이 맡는다

Tool Call에는 실행할 도구의 이름과 인자가 담깁니다. 에이전트 프로그램은 도구가 허용돼 있는지, 인자와 업무 규칙이 맞는지, 현재 사용자에게 실행 권한이 있는지 확인합니다. 검사를 통과한 호출만 실제 함수나 API로 보냅니다.

핵심 동작은 다음과 같은 반복문으로 단순화할 수 있습니다.

while True:
    response = llm(history, allowed_tools)
    history.append(response)

    if not response.tool_calls:
        return response.text

    for call in response.tool_calls:
        checked_call = validate(call, user_permissions)
        result = execute(checked_call)
        history.append(tool_result(call.id, result))

execute() 안에는 캘린더 API, 데이터베이스, 파일 검색이나 코드 실행기가 연결됩니다. 인증 정보는 이 실행 계층에서 관리합니다. LLM에는 비밀키를 보여줄 필요가 없습니다. 프로그램이 성공·실패와 조회 결과만 대화 기록에 넣어 다음 판단을 요청합니다.

일정 등록이나 메일 발송처럼 외부 상태를 바꾸는 도구에는 승인 단계를 둘 수 있습니다. 에이전트 프로그램이 실행 내용을 사용자에게 보여 주고 승인을 받은 뒤 호출하는 방식입니다. 삭제, 결제와 외부 전송처럼 되돌리기 어려운 작업일수록 승인과 권한 경계를 세밀하게 정해야 합니다.

MCP(Model Context Protocol)는 에이전트 애플리케이션과 외부 도구·데이터를 연결하는 공통 규약입니다. MCP 서버는 사용할 수 있는 도구와 입력 형식을 알리고 실행 결과를 돌려줍니다. 모델은 다음 Tool Call을 만들고, 에이전트 애플리케이션은 허용할 도구와 실행 권한을 통제합니다. MCP를 연결했다고 작업 계획이나 보안 정책까지 자동으로 완성되지는 않습니다.

코딩 에이전트가 먼저 성과를 낸 이유

C와 Python도 일정한 문법으로 표현되는 언어입니다. LLM은 공개 저장소의 코드와 주석, 문서와 수정 이력에서 문제 설명과 구현 사이의 관계를 배웁니다. 여기에 파일 검색, 편집, 명령 실행과 테스트 도구를 연결하면 모델이 만든 코드를 실제 환경에서 확인할 수 있습니다.

코딩 에이전트의 강점은 실행 결과가 빠르고 구체적으로 돌아온다는 점에 있습니다. 컴파일러는 문법 오류의 위치를 알려주고, 테스트는 기대한 결과와 실제 결과의 차이를 보여 줍니다. 에이전트는 이 피드백을 읽어 코드를 다시 고치고 테스트할 수 있습니다. 비교적 적은 종류의 도구만으로도 긴 작업을 이어갈 수 있다는 점도 유리합니다.

같은 원리는 일반 업무에도 적용됩니다. 송장을 만들었다면 금액과 수신자를 다시 읽고, 회의를 등록했다면 캘린더에서 일정과 참석자를 다시 조회해야 합니다. 완료 문장을 그럴듯하게 쓰는 능력보다 실제 결과를 확인할 도구와 절차가 업무의 신뢰도를 높입니다.

2026년 Anthropic이 약 40만 건의 Claude Code 대화 세션을 분석한 연구에서는 사용자가 주로 무엇을 만들지 정했고, 에이전트는 구현 방법을 더 많이 선택했습니다. 업무 지식이 풍부한 사용자의 세션일수록 성공률도 높았습니다. 다만 성공 여부는 대화 기록과 일부 시스템 신호로 측정했으므로 모든 결과물을 직접 검수한 평가는 아닙니다.

Claude Code, Codex, Pi와 OpenCode는 모두 모델에 파일·터미널 도구를 연결하지만 문맥 수집, 편집 방식, 권한 확인과 작업 상태 관리가 다릅니다. Claude Code와 Codex는 각각 Claude와 OpenAI 모델을 중심으로 도구와 실행 환경을 통합합니다. Pi는 작고 확장 가능한 실행 틀을 지향하며 여러 모델 제공업체를 연결할 수 있습니다. OpenCode도 여러 제공업체와 권한 설정을 지원합니다.

제품 간 차이는 모델만 바꿔서는 알기 어렵습니다. 같은 모델에 다른 실행 틀을 연결하는 비교와 각 제품이 권장하는 전체 구성의 비교가 모두 필요합니다. 구체적인 기능과 과제 비교는 후속 글에서 다루겠습니다.

정상적인 Tool Call도 잘못된 일을 시킬 수 있다

스키마 검사는 잘못 닫힌 괄호와 빠진 필드를 잡습니다. 모델이 알맞은 도구를 골랐는지, 인자의 내용이 업무에 맞는지는 따로 확인해야 합니다. 기능이 겹치는 도구가 많거나 설명이 모호하면 형식에 맞는 오답이 나올 수 있습니다.

모델이 역할을 구분할 수 있도록 이름과 설명을 구체적으로 쓰고, 기능이 겹치는 도구는 경계를 분명히 나눠야 합니다. 반환값에는 다음 판단에 필요한 정보만 담는 편이 좋습니다. Anthropic의 도구 설계 사례도 명확한 기능 경계와 토큰을 아끼는 결과 형식을 강조합니다.

긴 작업에서는 마지막 답변만 보아서는 실패 원인을 찾기 어렵습니다. Tool Call과 실행 결과, 재시도, 승인과 오류를 시간순으로 남겨야 처음 잘못된 지점을 찾고 같은 요청을 다시 시험할 수 있습니다. Anthropic의 에이전트 평가 지침처럼 실행 기록과 최종 결과를 나눠 보는 방법이 유용합니다. 일정 에이전트라면 답변 문장뿐 아니라 캘린더에 올바른 일정이 등록됐는지도 확인해야 합니다.

Microsoft Research의 AgentRx는 API 업무, 장애 대응, 웹·파일 작업에서 실패한 115개 실행 기록을 분석했습니다. 오류는 잘못된 호출, 도구 결과의 오독, 계획 이탈과 실행 환경 문제 등 여러 단계에서 발견됐습니다. ITBench-AA가 공개한 59개 Kubernetes 장애 진단 과제에서도 당시 가장 높은 성공률은 47%였습니다. 더 많은 단계를 거쳤다고 성공률이 높아지지는 않았습니다.

권한과 비밀키는 실행 계층에 남긴다

에이전트가 읽는 메일, 문서와 웹페이지에는 지시처럼 보이는 문장이 섞일 수 있습니다. 외부 콘텐츠에 숨긴 명령으로 모델의 행동을 바꾸는 공격을 Prompt Injection이라고 합니다. 모델이 공격 문구를 거부하도록 학습해도 위험을 모두 없애기는 어렵습니다.

읽기와 쓰기 권한을 나누고, 실행할 디렉터리와 접속할 네트워크를 제한해야 합니다. 결제, 삭제와 외부 발송에는 사람의 승인을 둘 수 있습니다. OpenAI의 Prompt Injection 대응 지침도 모델의 판단에만 의존하지 않고 권한, 데이터 흐름과 실행 범위를 함께 제한해야 한다고 설명합니다.

비용은 답변 한 번보다 작업 한 건으로 본다

도구를 여러 번 쓰는 요청은 LLM 호출 한 번으로 끝나지 않습니다. 주소록 검색, 일정 조회, 후보 선택과 등록을 거칠 때마다 도구 결과를 포함해 모델을 다시 호출합니다. 도구 설명과 중간 기록도 입력 토큰에 포함됩니다. 검색 결과와 로그가 길어지면 컨텍스트가 늘고, 이미 읽은 문맥의 연산 결과를 GPU 메모리에 보관하는 KV cache도 커집니다. 외부 API를 기다리는 시간 역시 사용자가 느끼는 작업 시간에 포함됩니다.

따라서 에이전트의 성능과 비용은 초당 토큰 수만으로 판단하기 어렵습니다. 작업 한 건을 끝내는 데 필요한 LLM 호출 횟수, 호출마다 사용한 입력·출력 토큰, 도구 대기 시간, 재시도와 최종 성공률을 함께 봐야 합니다.

온프레미스에서는 에이전트 전체를 운영한다

온프레미스 AI 에이전트에는 LLM 서빙과 함께 도구를 실행하고 권한과 상태를 관리할 환경이 필요합니다. 다음 구성 요소가 함께 움직여야 에이전트가 실제 작업을 끝낼 수 있습니다.

오픈웨이트 모델을 직접 운영할 때는 실제로 사용할 Tool Calling 형식까지 시험해야 합니다. 모델과 맞지 않는 Chat Template이나 Parser를 사용하면 호출 정보가 일반 텍스트로 남거나 인자가 잘못 해석될 수 있습니다. 스키마 준수율, 도구 선택률, 인자 정확도와 업무 완료율을 나누어 측정하면 실패한 구간을 찾기 쉽습니다.

인프라 용량도 에이전트의 작업 단위로 계산해야 합니다. GPU 처리량과 함께 도구를 실행할 CPU, 내부 시스템에 연결할 네트워크, 문서와 실행 기록을 보관할 스토리지가 필요합니다. 시간당 완료한 작업 수, 작업 하나를 마치는 데 걸린 시간, LLM 호출 횟수와 재시도율을 실제 요청으로 측정하면 필요한 GPU 수와 주변 자원을 정할 근거가 생깁니다.

첫 에이전트의 역할을 정하면 필요한 인프라가 보인다

회의 일정은 AI 에이전트의 작동 방식을 보여 주는 한 가지 예입니다. 같은 구조로 연구 자료를 탐색하거나 데이터를 분석하고, 코드를 작성하거나 콘텐츠를 만들 수도 있습니다. 에이전트가 맡을 역할과 사용할 데이터, 연결할 도구, 기대하는 결과를 정하면 필요한 모델과 인프라, 권한과 평가 기준이 구체적으로 드러납니다.

매니코어소프트와 모티프테크놀러지스가 함께 만든 Motif AI BOX는 액체냉각 GPU 서버 deep gadget을 기반으로 AI 모델과 에이전트 플랫폼을 구성한 AI 에이전트 어플라이언스입니다. 두 회사는 연구·개발, 데이터 분석, 코딩, 교육·콘텐츠 제작과 사내 업무 지원 등 다양한 용도에 맞춰 모델과 에이전트 기능, 데이터·도구 연동, 사용자 환경을 커스터마이징합니다. 사용자 수와 필요한 모델의 크기에 따라 서버 한 대부터 GPU 클러스터까지 시스템 규모도 달라집니다.

도입을 검토하고 있다면 Motif AI BOX 문의 페이지에 만들고 싶은 에이전트의 용도와 예상 사용자 수, 연결할 데이터·도구를 남겨 주세요. 아직 구체적인 제품 사양을 정하지 않았더라도 목적에 맞는 모델과 에이전트 구성, GPU 인프라와 운영 환경부터 함께 설계할 수 있습니다.

주요 참고 자료

• OpenAI, Function Calling Guide

• OpenAI, Introducing gpt-oss

• OpenAI, Designing AI Agents to Resist Prompt Injection

• Google AI for Developers, Fine-tuning with FunctionGemma

• Qwen Team, Qwen3-Coder: Agentic Coding in the World

• Anthropic, Tool Use with Claude

• Anthropic, Writing Effective Tools for AI Agents

• Anthropic, Agentic Coding and Persistent Returns to Expertise

• Anthropic, Building Effective Agents

• Anthropic, Demystifying Evals for AI Agents

• Anthropic, Claude Code Overview

• OpenAI, Codex CLI

• Pi Agent Harness, Coding Agent

• OpenCode, Introduction

• Microsoft Research, AgentRx: Diagnosing AI Agent Failures from Execution Trajectories

• Artificial Analysis·IBM, ITBench-AA: Frontier Models Score Below 50%

• vLLM, Tool Calling

• Model Context Protocol, Architecture Overview