대규모 언어 모델 (LLM)은 그 자체만으로는 단 한 가지만 할 수 있습니다: 텍스트를 생성하는 것입니다. 모델은 당신의 캘린더를 확인하거나, 테스트 스위트 (test suite)를 실행하거나, 결제를 환불할 수 없습니다. 그렇다면 우리는 어떻게 "매우 뛰어난 자동 완성" 단계에서 여행을 예약하고 코드베이스를 수정하는 시스템까지 도달할 수 있었을까요?

그 답은 거의 당황스러울 정도로 간단합니다: 모델을 루프 (loop) 안에 넣고 도구 (tools)를 제공하는 것입니다. 그것이 바로 에이전트 (agent)입니다. 그 외의 모든 것은 세부 사항일 뿐입니다. 하지만 그 세부 사항이야말로 프로덕션 시스템이 성공하거나 실패하는 지점입니다.

무엇이 실제로 "에이전트"로 간주되는가

이 분야에는 과장된 모호함이 많으므로, 연구소들이 직접 사용하는 정의를 사용해 보겠습니다.

OpenAI의 작업 정의: 에이전트는 워크플로 (workflow) 실행을 제어하기 위해 LLM을 사용하는 시스템입니다. 에이전트는 다음 단계를 결정하고, 작업이 완료되었음을 인식하며, 스스로를 수정하고, 인간에게 제어권을 다시 넘겨줄 수 있습니다. 결정적으로, LLM을 포함하고 있지만 흐름을 제어하게 하지 않는 것들—단순한 챗봇 (chatbot), 단발성 호출 (single-turn call), 감성 분류기 (sentiment classifier)—은 명시적으로 에이전트가 아닙니다.

Anthropic은 동일한 경계선을 다르게 긋습니다: **워크플로 (workflow)**는 _사전에 정의된 코드 경로_를 통해 LLM과 도구를 실행하는 것이며, **에이전트 (agent)**는 모델이 자신의 프로세스와 도구 사용을 동적으로 직접 지시하게 하는 것입니다. 구분점은 다음에 무엇이 일어날지를 누가 결정하느냐입니다—당신의 코드인가, 아니면 모델인가.

모든 에이전트는 세 가지 구성 요소로 구축됩니다:

• 모델 (Model) — 추론을 수행하고 결정하는 LLM.
• 도구 (Tools) — 행동을 취하기 위해 호출할 수 있는 함수와 API.
• 지침 (Instructions) — 행동을 정의하는 가이드라인과 가드레일 (guardrails).

도구에는 세 가지 유형이 있습니다: 데이터 도구 (data tools) (데이터베이스 쿼리, PDF 읽기, 웹 검색), 액션 도구 (action tools) (이메일 전송, CRM 레코드 업데이트), 그리고 오케스트레이션 도구 (orchestration tools) (호출 가능한 도구로 노출된 다른 에이전트들).

에이전트 루프 (the "run")

핵심 메커니즘은 루프(loop)입니다. 이는 일반적으로 **실행(run)**이라고 불리며, 종료 조건이 충족될 때까지 모델을 반복적으로 호출합니다. 각 패스마다 상태가 컨텍스트에 누적되므로, 실행 후반부에 내린 결정이라도 모든 이전 단계의 흔적을 지니게 됩니다.

1. 컨텍스트 구성(Assemble context) — 시스템 프롬프트 + 도구 정의 + 대화 기록 + 검색된 데이터 등.
2. 모델 호출(Call the model) — 모델은 최종 답변 또는 도구 호출 요청 중 하나를 반환합니다.
3. 도구 호출 시, 실행(If it's a tool call, execute it) — 사용자의 하네스(harness)(모델이 아님)가 실제 함수를 실행하고 결과를 포착합니다.
4. 결과 피드백(Feed the result back) — 이 결과를 컨텍스트에 추가하고 루프를 반복합니다.
5. 종료(Exit) — 최종 답변, 도구 호출 없음, 오류 발생, 또는 최대 턴 수 제한 시 종료됩니다.

Anthropic은 동일한 사이클을 컨텍스트 수집 → 행동 취하기 → 작업 검증 → 반복으로 설명합니다. 여기서 '검증(verify)'이라는 단어가 중요합니다. 에이전트는 각 단계에서 도구 결과와 코드 실행을 통해

3. 코드가 실행됩니다. 도구 호출(tool call, 함수 이름 + JSON 인자)을 파싱하고, 실제 함수를 실행하여 결과를 얻습니다. 모델은 스스로 아무것도 실행하지 않습니다. 모델은 오직 *의도(intentions)*만을 내뱉을 뿐이며, 여러분의 하네스(harness)가 실제 작업을 수행합니다. 이러한 분리는 보안 경계(security boundary) 역할도 합니다.

4. 결과를 다시 입력합니다. tool 역할(role), 일치하는 tool_call_id, 그리고 결과 내용을 포함한 메시지를 추가한 뒤, 모델을 다시 호출하여 모델이 해당 출력을 다음 단계에 통합할 수 있도록 합니다.

구조화된 출력 (Structured outputs)

유효한 JSON을 단순히 기대하는 것이 아니라 *보장(guarantee)*하려면, **엄격 모드 (strict mode)**를 통해 생성을 스키마에 맞게 제한해야 합니다 (additionalProperties: false, 모든 필드 필수). 엄격 모드가 없다면 JSON 출력은 최선(best-effort)을 다할 뿐입니다. 즉, 생성 이후에 검증하고 실패 시 다시 프롬프트를 입력해야 하는데, 이는 보장이 아니라 피드백 루프(feedback loop)에 불과합니다. 다운스트림(downstream) 단계에서 중요한 작업이라면 반드시 제약 조건이 있는 버전을 사용하세요.

인터페이스를 제품처럼 설계하세요

Anthropic은 우리가 본받을 만한 점을 강조합니다. 바로 **에이전트-컴퓨터 인터페이스 (Agent–Computer Interface, ACI)**도 인간을 위한 UI만큼이나 세심한 설계가 필요하다는 것입니다. 여기에는 모델이 쉽게 실수하지 못하도록 도구 시그니처(tool signatures)를 설계하는 **오류 방지 (error-proofing, poka-yoke)**가 포함됩니다. 명확한 이름, 엄격한 스키마, 그리고 도움이 되는 에러 메시지는 그 어떤 영리한 프롬프팅보다 신뢰성 향상에 더 큰 도움이 됩니다.

모델의 입장에서 생각해 보세요. 모델은 텍스트라는 작은 구멍을 통해 여러분의 시스템을 보지 못한 채 운영하고 있습니다. 좋은 도구는 자기 기술적(self-describing)이며, 오용하기 어렵고, 실패했을 때 실행 가능한 메시지와 함께 명확하게 오류를 알립니다.

우선 단일 에이전트부터

화려한 기술로 넘어가기 전, 마지막으로 매우 중요한 조언을 하나 드리겠습니다. 단일 에이전트(single agent)부터 시작하십시오. 잘 설계된 도구(tools)와 함께 루프(loop) 내에서 작동하는 단일 모델만으로도 놀라울 정도로 많은 실제 문제들을 해결할 수 있습니다. 여러 에이전트를 사용하는 것은 전문화(specialization)가 진정으로 병목 현상(bottleneck)을 제거할 때만 고려하십시오. 왜냐하면 이 시리즈의 뒷부분에서 살펴보겠지만, 에이전트의 수가 늘어난다는 것은 성숙도가 높아지는 것이 아니라 분산 시스템(distributed-systems)의 복잡성이 증가함을 의미하기 때문입니다.

핵심 요약 (Key takeaways)

• 에이전트(Agent) = LLM + 도구(tools) + 지침(instructions)이며, 모델이 제어하는 루프(loop) 내에서 실행됩니다.
• 모델은 오직 *의도(intentions)*만을 출력하며, 여러분의 하네스(harness)가 이를 실행하고 결과를 다시 피드백합니다.
• 도구는 JSON 스키마(JSON Schema)로 선언되며, 엄격 모드(strict mode)를 통해 출력의 신뢰성을 확보할 수 있습니다.
• 도구 인터페이스를 제품의 표면(product surface)처럼 다루십시오. 명확함(clarity)이 영리함(cleverness)보다 중요합니다.