API 호출 자동화와 LLM의 연결 구조: 함수 호출, 에이전트 루프, MCP로 이어지는 AI 자동화의 설계도

1. 셰프에게 손이 없는 이유: LLM의 본질적 한계

LLM은 근본적으로 "주어진 토큰 시퀀스 다음에 올 토큰을 예측하는 함수"입니다. 입력으로 텍스트(혹은 이미지 등 멀티모달 데이터)가 들어가면, 출력으로 텍스트가 나옵니다. 이 사실 하나가 API 연결 구조 전체를 설명하는 출발점이에요.

이 구조에서 생기는 한계는 크게 세 가지입니다.

이 세 가지를 동시에 해결하는 방법이 바로 모델이 "무엇을 호출할지"를 결정하고, 외부 프로그램이 "실제로 호출"하는 분업 구조입니다. 셰프는 판단하고, 주방 보조는 실행합니다. 이 분업이 오늘 이야기의 뼈대예요.

이 분업 덕분에 개발자는 중요한 통제권을 쥡니다. 모델이 무엇을 요청하든 실제 실행 여부는 우리 코드가 결정할 수 있으니까요. 위험한 요청은 막고, 애매한 요청은 사람에게 확인받고, 실패한 요청은 다시 시도할 수 있습니다. 반대로 말하면, 이 통제 계층을 허술하게 만들면 AI 자동화의 사고는 대부분 여기서 터집니다.

2. 주방의 공용어: API, HTTP, JSON 기초

연결 구조를 이해하려면 주방에서 쓰는 언어부터 알아야 합니다. 이 주방의 공용어는 API, 전달 수단은 HTTP, 주문서 양식은 JSON입니다.

2-1. API란 무엇인가

API(Application Programming Interface)는 프로그램끼리 대화하기 위한 약속된 창구입니다. 식당의 배달 주문 창구를 떠올리면 쉬워요. 손님은 주방 안이 어떻게 생겼는지 몰라도, 정해진 양식대로 주문하면 음식을 받습니다. 내부 구현을 숨기고, 입력과 출력의 형식만 공개하는 것이죠.

오늘날 웹에서 가장 흔한 API 스타일은 REST입니다. 자원(resource)을 URL로 표현하고, HTTP 메서드로 행위를 표현합니다.

표의 멱등성(idempotency) 열을 꼭 기억해 두세요. "같은 요청을 여러 번 보내도 결과가 한 번 보낸 것과 같은 성질"을 뜻하는데, 자동화에서 재시도를 설계할 때 결정적인 역할을 합니다. 재고 조회(GET)는 열 번 해도 문제가 없지만, 발주(POST)를 실수로 세 번 보내면 양파 6kg이 도착합니다. 이 문제는 9장에서 자세히 다룹니다.

2-2. HTTP 상태 코드: 주방의 신호등

API 호출 자동화에서 상태 코드는 "다음에 무엇을 할지"를 결정하는 분기점입니다.

2-3. JSON: 모두가 읽는 주문서

JSON(JavaScript Object Notation)은 키-값 쌍으로 데이터를 표현하는 텍스트 형식입니다. 사람도 읽을 수 있고 기계도 쉽게 파싱할 수 있어, 웹 API의 사실상 표준 데이터 형식이 되었습니다. 그리고 결정적으로, LLM이 생성하기 좋은 형식이기도 합니다. 학습 데이터에 엄청난 양의 JSON이 포함되어 있으니까요.

{
  "item": "양파",
  "quantity_kg": 2,
  "urgent": true,
  "supplier_ids": ["S-101", "S-204"]
}

LLM과 API를 연결한다는 것은 결국 자연어 → JSON(모델이 생성) → HTTP 요청(코드가 실행) → JSON 응답 → 자연어(모델이 해석)의 변환 사슬을 만드는 일입니다.

2-4. LLM 자체도 API다

흥미로운 점은 LLM을 사용하는 방법 자체가 API 호출이라는 사실입니다. OpenAI, Anthropic, Google 등 주요 제공사는 HTTP 엔드포인트로 모델을 제공합니다. 여러분의 프로그램은 대화 기록(messages)과 설정값을 JSON으로 담아 POST 요청을 보내고, 모델의 응답을 JSON으로 받습니다.

3. 연결 구조의 3계층: 모델·런타임·도구

LLM 기반 자동화 시스템을 해부하면, 거의 예외 없이 다음 세 계층이 나옵니다. 프레임워크 이름이 LangChain이든, LlamaIndex든, 직접 짠 수백 줄짜리 스크립트든 이 뼈대는 같습니다.

3-1. 모델 계층: 판단하는 두뇌

모델 계층의 역할은 의사결정입니다. 사용자의 요청과 사용 가능한 도구 목록을 보고, 지금 도구가 필요한지, 필요하다면 어떤 도구를 어떤 인자로 호출할지 결정합니다. 도구 결과를 받은 뒤에는 그것을 해석해 최종 답변을 쓰거나 다음 도구를 요청합니다.

3-2. 런타임 계층: 실제로 일하는 손

흔히 과소평가되지만, 시스템의 안정성과 보안은 거의 전부 이 계층에서 결정됩니다. 런타임이 하는 일을 정리하면 다음과 같습니다.

3-3. 도구 계층: 바깥 세상

도구는 런타임이 호출할 수 있는 모든 기능입니다. 사내 주문 시스템 REST API, 데이터베이스 쿼리, 웹 검색, 파일 시스템, 파이썬 코드 실행 샌드박스, 이메일 발송, 그리고 최근 빠르게 확산 중인 MCP 서버까지 모두 도구가 될 수 있습니다.

도구는 성격에 따라 크게 두 부류로 나누어 다루는 것이 좋습니다.

4. 함수 호출(Tool Calling)의 정확한 작동 원리

2023년 6월 OpenAI가 Chat Completions API에 함수 호출(function calling) 기능을 공식 도입하면서, LLM과 API의 연결은 "프롬프트 요령"에서 "API 규격"으로 격상되었습니다. 이후 Anthropic(Tool use), Google(Gemini Function calling) 등 주요 제공사들도 비슷한 기능을 제공하고 있으며, 오늘날에는 도구 호출(tool calling)이라는 용어가 더 널리 쓰입니다.

4-1. 한 번의 도구 호출이 일어나는 순서

손님이 "내일 서울 날씨 어때? 비 오면 우산 챙기라고 알려줘"라고 물었다고 해 봅시다.

즉, 사용자 입장에서는 한 번의 질문이지만 모델 API는 최소 두 번 호출됩니다. 이 점은 지연 시간과 비용 계산에서 중요합니다.

4-2. 코드로 보는 최소 구현

아래는 OpenAI Python SDK의 Chat Completions 방식을 예로 든 최소 구조입니다. 제공사마다 필드 이름은 조금씩 다르지만(예: Anthropic은 tool_use와 tool_result 콘텐츠 블록을 사용), 흐름은 동일합니다.

import json
from openai import OpenAI

client = OpenAI()

def get_weather(city: str, date: str) -> dict:
    # 실제로는 기상 API에 HTTP 요청을 보낸다
    return {"city": city, "date": date, "condition": "rain", "pop": 70}

TOOLS = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "특정 도시의 특정 날짜 날씨 예보를 조회한다.",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "도시 이름, 예: 서울"},
                "date": {"type": "string", "description": "YYYY-MM-DD 형식 날짜"}
            },
            "required": ["city", "date"],
            "additionalProperties": False
        }
    }
}]

REGISTRY = {"get_weather": get_weather}

messages = [{"role": "user", "content": "내일 서울 날씨 어때?"}]

resp = client.chat.completions.create(model="gpt-4o", messages=messages, tools=TOOLS)
msg = resp.choices[0].message

if msg.tool_calls:
    messages.append(msg)                       # 모델의 호출 요청도 기록에 남긴다
    for call in msg.tool_calls:
        fn = REGISTRY[call.function.name]
        args = json.loads(call.function.arguments)
        result = fn(**args)
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,           # 요청과 결과를 ID로 짝짓는다
            "content": json.dumps(result, ensure_ascii=False)
        })
    final = client.chat.completions.create(model="gpt-4o", messages=messages, tools=TOOLS)
    print(final.choices[0].message.content)
else:
    print(msg.content)

코드에서 눈여겨볼 지점은 세 곳입니다.

4-3. 도구 선택을 제어하는 옵션

대부분의 제공사는 모델이 도구를 쓸지 말지를 제어하는 옵션을 둡니다. 이름은 다르지만 개념은 비슷합니다.

4-4. 좋은 도구 정의가 정확도를 결정한다

모델은 도구의 이름과 설명, 파라미터 설명만 보고 언제 어떻게 쓸지 결정합니다. 즉 도구 정의는 코드가 아니라 모델에게 주는 사용 설명서입니다. Anthropic의 공식 문서도 도구 설명을 상세하게 쓰는 것이 성능에 가장 중요한 요소라고 강조합니다.

5. JSON Schema와 구조화 출력: 주문서 양식의 엄격함

셰프가 쓴 주문서가 가끔 양식을 벗어난다면? "양파 2키로정도요~"라고 적어서 보내면 주방 보조의 자동 처리기는 멈춰 버립니다. 초기 LLM 자동화에서 가장 골치 아픈 문제가 바로 이것이었습니다. 모델이 생성한 JSON이 깨지거나, 필수 필드가 빠지거나, 타입이 틀리는 현상이죠.

5-1. JSON Schema란

JSON Schema는 JSON 데이터의 구조를 기술하는 표준 명세입니다. 어떤 필드가 있어야 하고, 각 필드의 타입은 무엇이며, 값의 범위는 어떠한지를 정의합니다. 도구 정의의 parameters가 바로 JSON Schema 형식입니다.

{
  "type": "object",
  "properties": {
    "item":        { "type": "string" },
    "quantity_kg": { "type": "number", "minimum": 0.1, "maximum": 500 },
    "priority":    { "type": "string", "enum": ["normal", "urgent"] },
    "deliver_by":  { "type": "string", "description": "ISO 8601 날짜" }
  },
  "required": ["item", "quantity_kg", "priority"],
  "additionalProperties": false
}

5-2. 생성 단계에서 형식을 강제하는 기술

과거에는 프롬프트에 "반드시 JSON으로만 답하라"고 부탁하고, 깨지면 다시 요청하는 방식이 일반적이었습니다. 이후 제공사들은 출력 형식을 더 확실하게 보장하는 기능을 내놓았습니다.

5-3. 런타임 검증 계층 만들기

파이썬에서는 Pydantic 같은 라이브러리로 스키마 정의와 검증을 한 번에 처리하는 경우가 많습니다. 하나의 모델 클래스에서 JSON Schema를 생성해 도구 정의에 넣고, 모델이 돌려준 인자를 같은 클래스로 검증하면 정의와 검증이 어긋날 일이 줄어듭니다.

from pydantic import BaseModel, Field, ValidationError
from typing import Literal

class PurchaseOrder(BaseModel):
    item: str
    quantity_kg: float = Field(gt=0, le=500)
    priority: Literal["normal", "urgent"]

schema = PurchaseOrder.model_json_schema()   # 도구 정의에 사용

def handle_call(raw_args: str):
    try:
        order = PurchaseOrder.model_validate_json(raw_args)
    except ValidationError as e:
        # 오류 내용을 모델에게 돌려주면 스스로 고쳐서 다시 요청하는 경우가 많다
        return {"error": "invalid_arguments", "detail": e.errors()}
    return place_order(order)

여기서 중요한 기법 하나: 검증에 실패했을 때 예외를 던지고 끝내기보다 오류 내용을 도구 결과로 모델에게 돌려주면, 모델이 이를 읽고 인자를 수정해 다시 호출하는 경우가 많습니다. 일종의 자가 교정 루프죠. 단, 무한 반복을 막기 위해 재시도 횟수 상한은 꼭 두어야 합니다.

6. 에이전트 루프와 ReAct 패턴

4장의 예시는 도구를 한 번 쓰고 끝났습니다. 하지만 현실의 업무는 그렇게 단순하지 않습니다. "지난달 매출 상위 3개 메뉴의 재료 재고를 확인하고, 부족한 것은 발주해 줘"라는 요청을 생각해 보세요. 매출 조회 → 레시피 조회 → 재고 조회 → 부족분 계산 → 발주라는 여러 단계를 앞 단계 결과에 따라 진행해야 합니다.

이렇게 모델이 도구 호출과 결과 확인을 반복하며 목표를 달성하는 구조를 흔히 에이전트 루프(agent loop)라고 부릅니다.

6-1. ReAct: 생각과 행동을 번갈아

에이전트 루프의 이론적 뿌리로 자주 언급되는 것이 2022년 Yao 등이 발표한 논문 "ReAct: Synergizing Reasoning and Acting in Language Models"입니다. ReAct는 Reasoning(추론)과 Acting(행동)의 합성어로, 모델이 생각(Thought) → 행동(Action) → 관찰(Observation)을 번갈아 생성하도록 하는 프롬프팅 방식을 제안했습니다. 추론만 하거나 행동만 하는 방식보다, 둘을 엮었을 때 지식 집약적 질의응답과 의사결정 과제에서 성능과 해석 가능성이 개선되었다고 보고했습니다.

당시에는 함수 호출 API가 없었기 때문에, 모델이 "Action: search[서울 날씨]" 같은 텍스트를 쓰면 프로그램이 정규식으로 파싱해 실행하는 방식이었습니다. 오늘날에는 이 파싱을 네이티브 도구 호출 기능이 대신해 주지만, 생각→행동→관찰의 순환 구조는 그대로 이어지고 있습니다.

같은 시기 Meta AI의 Toolformer(2023) 연구는 모델이 언제 어떤 API를 부를지 스스로 학습하도록 하는 자기 지도 방식을 제시했습니다. 이러한 연구 흐름이 상용 모델의 도구 사용 능력 향상으로 이어졌다고 볼 수 있습니다.

6-2. 에이전트 루프의 표준 골격

MAX_STEPS = 10

def run_agent(user_input: str):
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": user_input},
    ]
    for step in range(MAX_STEPS):
        resp = call_llm(messages, tools=TOOLS)
        msg = resp.message

        if not msg.tool_calls:          # 도구 요청이 없으면 최종 답변으로 간주
            return msg.content

        messages.append(msg)
        for call in msg.tool_calls:
            result = safe_execute(call) # 검증·권한·재시도·타임아웃 포함
            messages.append(tool_result_message(call.id, result))

    return "작업 단계가 너무 많아 중단했습니다. 요청을 나눠서 다시 시도해 주세요."

이 20줄 남짓한 골격이 대부분 에이전트 프레임워크의 심장입니다. 프레임워크들은 여기에 메모리 관리, 스트리밍, 상태 저장, 병렬 실행, 추적(tracing) 같은 기능을 덧붙인 것이라고 볼 수 있어요.

6-3. 종료 조건: 루프는 반드시 끝나야 한다

에이전트가 같은 도구를 계속 부르거나, 실패를 반복하며 맴도는 현상은 실제로 자주 일어납니다. 그래서 종료 조건을 여러 겹으로 겁니다.

6-4. 컨텍스트 관리: 기록이 너무 길어질 때

모델에는 한 번에 처리할 수 있는 컨텍스트 윈도 크기 제한이 있습니다. 도구 결과가 크면(예: 수천 행짜리 DB 결과, 긴 웹페이지 원문) 몇 단계 만에 한계에 도달할 수 있어요. 흔히 쓰는 대응책은 다음과 같습니다.

7. 병렬 호출과 스트리밍: 주방을 빠르게

7-1. 병렬 도구 호출

"서울, 부산, 제주 날씨 알려줘"라는 요청을 받았다면, 세 번을 순서대로 호출할 필요가 없습니다. 최근 주요 모델 API는 한 번의 응답에 여러 개의 도구 호출을 동시에 담을 수 있습니다(parallel tool calls). 런타임은 이를 동시에 실행하면 전체 대기 시간을 줄일 수 있죠.

import asyncio

async def execute_all(tool_calls):
    tasks = [async_execute(call) for call in tool_calls]
    results = await asyncio.gather(*tasks, return_exceptions=True)
    # 일부가 실패해도 나머지 결과는 살린다
    return [
        (call.id, r if not isinstance(r, Exception) else {"error": str(r)})
        for call, r in zip(tool_calls, results)
    ]

7-2. 스트리밍과 SSE

LLM 응답은 토큰 단위로 생성되기 때문에, 전체가 끝날 때까지 기다리지 않고 생성되는 대로 받아서 화면에 보여줄 수 있습니다. 주요 LLM API는 이를 위해 SSE(Server-Sent Events) 방식의 스트리밍을 지원합니다. SSE는 서버가 하나의 HTTP 연결을 열어둔 채 이벤트를 연속으로 밀어주는 단방향 통신 방식이에요.

도구 호출과 스트리밍을 함께 쓸 때는 주의할 점이 있습니다. 도구 호출의 인자 JSON도 조각조각 나뉘어 도착하므로, 런타임은 조각을 모두 이어 붙인 뒤에야 파싱할 수 있습니다. 부분 JSON을 성급하게 파싱하면 오류가 납니다.

7-3. 비동기 작업과 웹훅

어떤 API는 결과가 즉시 나오지 않습니다. 영상 렌더링, 대량 데이터 처리, 사람의 승인을 기다리는 작업 등이 그렇죠. 이럴 때는 두 가지 패턴을 씁니다.

에이전트 관점에서는 장기 작업을 "시작" 도구와 "상태 조회" 도구로 나누고, 루프를 일시 중단했다가 웹훅이 도착하면 저장된 대화 상태를 불러와 재개하는 설계가 자주 쓰입니다. 이때 대화 상태를 직렬화해 영속 저장할 수 있도록 런타임을 만들어 두어야 합니다.

8. MCP: 도구 연결의 표준 규격

함수 호출 덕분에 LLM과 API를 잇는 일은 쉬워졌지만, 새로운 문제가 생겼습니다. 모든 애플리케이션이 모든 도구를 각자 따로 연결해야 했던 거죠. 챗봇 A도, IDE 플러그인 B도, 사내 에이전트 C도 각자 Slack 연동, GitHub 연동, DB 연동 코드를 따로 만들었습니다. 애플리케이션이 M개, 도구가 N개면 M×N개의 통합 작업이 필요한 구조입니다.

이 문제를 풀기 위해 Anthropic이 2024년 11월 오픈 표준으로 공개한 것이 MCP(Model Context Protocol)입니다. 공식 문서는 MCP를 AI 애플리케이션을 위한 "USB-C 포트"에 비유합니다. 규격만 맞으면 어떤 도구든 꽂아 쓸 수 있다는 의미예요. 공개 이후 여러 AI 도구와 개발 환경, 그리고 다른 모델 제공사들도 MCP 지원을 발표하면서 생태계가 빠르게 확장되었습니다.

8-1. MCP의 구성 요소

MCP는 세 역할로 구성됩니다.

8-2. 서버가 제공하는 세 가지 기본 요소

반대 방향의 기능도 있습니다. 서버가 클라이언트에게 모델 생성을 요청하는 Sampling, 사용자에게 추가 정보를 요청하는 Elicitation 등이 명세에 포함되어 있으며, 명세는 버전별로 계속 갱신되고 있습니다.

8-3. 통신 방식: JSON-RPC 2.0과 전송 계층

MCP 메시지는 JSON-RPC 2.0 형식을 따릅니다. JSON-RPC는 "메서드 이름 + 파라미터"를 JSON으로 보내고 결과를 JSON으로 받는 가벼운 원격 호출 규격입니다. 예를 들어 클라이언트가 서버의 도구 목록을 요청하는 메시지는 다음과 같은 모양입니다.

{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }

도구를 실행할 때는 tools/call 메서드에 도구 이름과 인자를 담아 보냅니다.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_stock",
    "arguments": { "item": "양파" }
  }
}

메시지를 실어 나르는 전송 방식(transport)은 크게 두 가지가 표준으로 정의되어 있습니다.

8-4. MCP와 함수 호출의 관계

여기서 많은 분들이 헷갈립니다. "MCP를 쓰면 함수 호출이 필요 없나요?" 아닙니다. 둘은 서로 다른 층위에서 협력합니다.

즉 MCP는 3장의 3계층 중 ②런타임과 ③도구 사이를 표준화한 것입니다. 이 덕분에 도구 개발자는 한 번만 서버를 만들면 MCP를 지원하는 어떤 호스트에서든 쓰일 수 있고, 앱 개발자는 커넥터를 일일이 만들 필요가 줄어듭니다. 재능넷 같은 재능 거래 플랫폼에서도 최근 사내 시스템을 MCP 서버로 감싸 AI 도구에 연결해 달라는 개발 의뢰가 눈에 띄게 늘고 있는 것도 이런 흐름과 맞닿아 있습니다.

9. 신뢰성: 재시도, 백오프, 멱등성, 서킷 브레이커

데모에서는 모든 API가 0.1초 만에 성공합니다. 현실의 주방은 다릅니다. 납품업체 전화는 통화 중이고, 냉장고 센서는 가끔 응답이 없고, LLM API는 요청이 몰리면 429를 돌려줍니다. API 호출 자동화의 진짜 실력은 실패를 어떻게 다루는가에서 드러납니다.

9-1. 타임아웃: 무한정 기다리지 않기

타임아웃이 없는 HTTP 요청은 응답 없는 서버 하나 때문에 전체 에이전트를 멈춰 세울 수 있습니다. 많은 HTTP 라이브러리는 기본 설정에서 타임아웃이 없거나 매우 길게 잡혀 있으므로, 모든 외부 호출에 명시적 타임아웃을 거는 것이 원칙입니다. 연결 수립 타임아웃과 응답 읽기 타임아웃을 구분해 설정하는 것도 좋습니다. LLM 호출은 긴 출력을 생성할 때 수십 초가 걸릴 수 있으므로, 일반 API보다 넉넉하게 잡거나 스트리밍을 활용합니다.

9-2. 무엇을 재시도할 것인가

9-3. 지수 백오프와 지터

실패하자마자 즉시 재시도하면, 이미 과부하인 서버를 더 두들기는 꼴이 됩니다. 그래서 재시도 간격을 1초, 2초, 4초, 8초처럼 지수적으로 늘리는 지수 백오프(exponential backoff)를 씁니다.

그런데 수많은 클라이언트가 동시에 실패하고 똑같은 간격으로 재시도하면, 정확히 같은 순간에 다시 몰려드는 문제가 생깁니다. 이를 막기 위해 대기 시간에 무작위성(지터, jitter)을 섞습니다. AWS 아키텍처 블로그의 "Exponential Backoff And Jitter" 글은 여러 지터 전략을 비교하며 지터를 추가하는 것이 경합을 크게 줄인다고 설명합니다. OpenAI와 Anthropic의 문서도 속도 제한 오류에 대해 지수 백오프 재시도를 권장합니다.

import random, time

RETRYABLE = {429, 500, 502, 503, 504}

def call_with_retry(do_request, max_attempts=5, base=1.0, cap=30.0):
    for attempt in range(max_attempts):
        try:
            resp = do_request()
        except (ConnectionError, TimeoutError):
            resp = None

        if resp is not None and resp.status_code not in RETRYABLE:
            return resp                          # 성공 또는 재시도 불가 오류

        if attempt == max_attempts - 1:
            break

        retry_after = resp and resp.headers.get("Retry-After")
        if retry_after and retry_after.isdigit():
            delay = float(retry_after)           # 서버가 알려준 대기 시간 우선
        else:
            delay = random.uniform(0, min(cap, base * 2 ** attempt))  # full jitter
        time.sleep(delay)

    raise RuntimeError("재시도 한도 초과")

파이썬에서는 tenacity 같은 재시도 라이브러리를 쓰면 이런 로직을 데코레이터로 깔끔하게 붙일 수 있고, 주요 LLM 제공사의 공식 SDK들도 일정 횟수의 자동 재시도 기능을 내장하고 있습니다. 다만 SDK 자동 재시도와 직접 짠 재시도가 겹쳐서 재시도 횟수가 곱으로 늘어나지 않도록 주의하세요.

9-4. 멱등성 키: 양파 6kg 사태 막기

재시도의 가장 큰 함정은 이것입니다. 발주 API에 요청을 보냈는데 타임아웃이 났습니다. 그런데 사실 서버는 요청을 정상 처리했고, 응답만 늦게 온 것이었다면? 재시도하는 순간 중복 발주가 됩니다.

이를 해결하는 표준적인 방법이 멱등성 키(idempotency key)입니다. 클라이언트가 작업마다 고유한 키(보통 UUID)를 생성해 요청 헤더에 담아 보내면, 서버는 같은 키로 들어온 요청을 한 번만 처리하고 이후에는 저장된 첫 결과를 돌려줍니다. Stripe 같은 결제 API가 Idempotency-Key 헤더로 이 방식을 지원하는 대표 사례이고, IETF에서도 이 헤더를 표준화하는 초안이 논의되고 있습니다.

9-5. 서킷 브레이커: 망가진 납품업체 잠시 차단

어떤 외부 API가 완전히 다운되었다면, 매 요청마다 타임아웃까지 기다리며 재시도하는 건 자원 낭비입니다. 서킷 브레이커(circuit breaker) 패턴은 실패가 일정 기준을 넘으면 회로를 "열어" 한동안 해당 API 호출을 즉시 실패 처리하고, 일정 시간 뒤 일부 요청만 시험적으로 흘려보내 회복 여부를 확인합니다.

에이전트 맥락에서 서킷이 열렸을 때는 도구 결과로

{"error": "supplier_api_unavailable", "message": "납품업체 시스템이 일시적으로 응답하지 않습니다"}

9-6. 속도 제한을 내 쪽에서 먼저 관리하기

LLM API는 보통 분당 요청 수(RPM)와 분당 토큰 수(TPM) 등으로 사용량을 제한합니다. 대량 배치 작업을 돌릴 때는 429를 맞고 나서 대응하기보다, 클라이언트 쪽에서 토큰 버킷 같은 알고리즘으로 요청 속도를 미리 조절하는 편이 효율적입니다. 즉시 응답이 필요 없는 대량 작업이라면, 일부 제공사가 제공하는 배치 API(비동기로 처리하고 비용을 할인해 주는 방식)를 검토할 만합니다.

10. 보안: 프롬프트 인젝션과 최소 권한

LLM에 도구를 쥐여주는 순간, 보안 위협의 성격이 바뀝니다. 이전에는 모델이 이상한 말을 하는 정도였다면, 이제는 이상한 행동을 할 수 있으니까요. OWASP는 LLM 애플리케이션 보안 위험 목록(OWASP Top 10 for LLM Applications)을 발표하고 있으며, 프롬프트 인젝션을 가장 앞자리에 두고 있습니다. 과도한 권한 부여(Excessive Agency) 역시 주요 위험으로 꼽힙니다.

10-1. 간접 프롬프트 인젝션

사용자가 직접 "이전 지시를 무시해"라고 입력하는 직접 인젝션보다 더 까다로운 것이 간접 프롬프트 인젝션입니다. 모델이 도구로 읽어 온 웹페이지, 이메일, 문서 안에 공격자의 지시문이 숨어 있는 경우죠.

현재로서는 프롬프트 인젝션을 모델 수준에서 완전히 막는 방법은 없다는 것이 보안 업계의 대체적인 평가입니다. 그래서 방어는 "모델이 속을 수 있다"를 전제로 구조적으로 설계합니다.

10-2. 구조적 방어 수단