AI Agent

AI Agent는 단일 LLM 호출을 reasoning-action-observation loop 안에 배치한 system concept이다. 이 페이지는 agent의 전체 경계를 설명하고, 세부 구조는 AI Agent Architecture, 추론 패턴 비교는 Agent reasoning frameworks, model call 품질 설계는 Prompt Engineering에서 다룬다.

목표를 향한 반복 구조

Agent는 정보 인식, 추론, 행동 결정, 관찰을 반복하는 구조로 정의된다.^[1]
단순 LLM 호출과 달리, agent는 목표 달성을 위해 판단-행동 loop를 가진다.^[1:1]

Input -> Reasoning -> Action -> Observation -> Reasoning -> ... -> Final Answer

단일 LLM 호출과의 차이는 반복성과 외부 행동이다. 단일 호출은 입력에서 출력을 생성하지만, agent는 중간 관찰을 다음 추론에 반영할 수 있다.

Model과 Agent의 차이

비교 항목	모델 (Models)	에이전트 (Agents)
지식 범위	훈련 데이터 내의 지식으로 제한됨	도구(Tools)를 활용해 외부 시스템과 실시간 정보 연동
맥락 및 세션 관리	단발성 추론(Single Inference) 수행. 세션 히스토리나 연속 맥락을 직접 관리하지 않음	오케스트레이션 레이어에서 세션 및 대화 히스토리를 관리하여 다회성 추론(Multi-turn) 지원
도구 연동성	네이티브한 도구 구현이 없음	아키텍처 상에 도구(Tools)가 네이티브하게 구현됨
로직 레이어	네이티브 로직 레이어가 없음. 복잡한 추론을 위해서는 단순 질문이나 프롬프트 구조에 의존	추론 프레임워크(CoT, ReAct 등)와 에이전트 프레임워크를 사용하는 네이티브 인지 아키텍처 탑재

이 비교표는 백서가 제시하는 model-agent 구분이다.^[2] Model, orchestration layer, tools를 agent의 핵심 구성 요소로 보는 것도 같은 계열의 주장이다.^[1:2]

Agent Patterns 노트는 workflow를 predefined code path에 따른 system으로, agent를 LLM이 process와 tool use를 동적으로 제어하는 system으로 구분한다.^[3]
백서는 agent가 주어진 목표를 위해 독립적으로 행동하고, 구체적인 지침이 없어도 스스로 판단해 추론할 수 있는 자율성(Autonomy)과 주도성(Proactivity)을 가진다고 기술한다.^[2:1]
Harness Engineering 사례는 사람이 코드를 직접 작성하지 않는 제약 아래 Codex가 약 백만 라인 규모의 내부 베타 제품을 구축하고 출시한 사례를 보여준다.^[4]

LLM 호출을 control loop에 넣는다는 것

AI Agent의 핵심은 "LLM을 쓴다"가 아니라 "LLM 호출을 control loop 안에 넣는다"는 데 있다고 보인다. Model은 추론을 담당하지만, agent system의 품질은 orchestration layer가 언제 추론하고, 어떤 tool을 호출하고, observation을 어떻게 다음 판단에 반영하는지에 달려 있다.

Agent와 workflow는 이분법보다 spectrum이다. 낮은 자율성에서는 code path가 control을 잡고, 높은 자율성에서는 LLM이 다음 과정과 tool 사용을 더 많이 결정한다. 실용적 agent 설계는 보통 둘 사이의 bounded autonomy를 정하는 일이다.

Model call, workflow, 완전 자율 시스템과의 경계

모든 LLM 사용이 agent는 아니다. Tool을 전혀 호출하지 않거나, observation을 다음 판단에 반영하지 않는 단순 질의응답은 agent보다 model call에 가깝다.

반대로 agent는 완전 자율 시스템만 뜻하지 않는다. 사전 정의된 workflow 안에서 제한적으로 자율성을 갖는 system도 agentic system으로 볼 수 있다. 중요한 기준은 tool 사용 여부 자체가 아니라 control boundary가 code path에 있는지, LLM의 동적 판단에 있는지다.

또한, 에이전트가 통제 및 실행 결정을 담당하는 런타임 영역이라면, Agent Harness는 에이전트가 아키텍처적 제약과 개발 품질 기준(custom linter, local observability) 안에서 신뢰성 있게 움직이도록 조율하는 환경·인프라 경계를 형성한다고 볼 수 있다.

이 경계가 흐려지는 경우

LLM 호출만 있으면 agent라고 부르는 경우.
Tool 호출은 있지만 observation을 다음 추론에 반영하지 않는 경우.
Orchestration layer의 책임을 prompt 하나로 대체하려는 경우.
정해진 workflow를 agent라고 부르며 불필요한 autonomy를 추가하는 경우.
목표 달성 여부를 판단하는 stopping condition이 없는 경우.

출처

테스트 질문

AI Agent와 단일 LLM 호출의 핵심 차이는 무엇인가?
Tool 호출만 있으면 항상 agent인가?
Orchestration layer가 agent 품질에 중요한 이유는 무엇인가?
AI workflow와 AI agent의 control boundary는 어떻게 다른가?

Agent Architecture.md — "에이전트가 정보를 인식하고, 추론하고, 행동을 결정하는 전체 구조", "단순 LLM 호출과 달리, 에이전트는 목표 달성을 위해 반복적인 판단-행동 루프를 가짐", "모델 (Model): 추론을 담당하는 LLM", "오케스트레이션 레이어 (Orchestration Layer): 판단-행동 루프를 조율하는 시스템", "도구 (Tools): 에이전트가 외부 세계와 상호작용하는 수단" ↩︎ ↩︎ ↩︎
22365_19_Agents_v8.pdf — Agents vs Models 비교표와 자율성/주도성 서술. 이 PDF는 이번 변환 세션에서 poppler 부재로 재추출하지 못했고, 2026-07-11 conformance 기록 시점에 검증된 기존 claim을 그대로 유지한다. ↩︎ ↩︎
Agent Patterns.md — "워크플로우란, LLM과 여러 도구들이 미리 정해진 코드 경로에 따라 작동할 수 있도록 하는 시스템이다.", "에이전트는 LLM들이 자신의 작업 과정과 도구 사용 방식을 동적으로 제어할 수 있는 시스템이다." ↩︎
Harness Engineering.md — (L20) "...Codex로 소프트웨어 제품의 내부 베타를 구축하고 출시하는 실험을 했다.", (L55) "개발 과정 전반에 걸쳐 사람은 코드에 직접 기여하지 않았다.", (L51) "5개월 뒤 리포지터리에는... 약 백만 라인의 코드가 들어 있었다." ↩︎