AI Agent Architecture

AI Agent가 "reasoning-action-observation loop 안의 LLM 호출"이라는 개념이라면, AI Agent Architecture는 그 개념을 실행 가능한 system으로 만드는 구조다. Agent가 어떤 정보를 받고, 어떤 추론 프레임워크를 쓰고, 어떤 tool을 호출하고, observation을 어떻게 다음 reasoning에 반영할지를 정한다.

오케스트레이션 loop

Agent architecture의 중심은 orchestration loop다.

flowchart TD
    Start([사용자 요청]) --> Context["Context / memory 확인"]
    Context --> Thought["Reasoning
다음 행동 결정"]
    Thought --> Action["Action
tool 호출 또는 응답"]
    Action --> Observation["Observation
결과 수집"]
    Observation --> Check{목표 달성?}
    Check -->|No| Thought
    Check -->|Yes| Answer([Final answer])

Cognitive architecture는 agent가 정보를 인식하고, 추론하고, 행동을 결정하는 전체 구조다.^[1]
핵심 구성 요소는 세 가지다: 추론을 담당하는 model, 판단-행동 loop를 조율하는 orchestration layer, 외부 세계와 상호작용하는 tools.^[1:1]
Orchestration layer는 사용자 요청 수신 → 현재 상태 파악(메모리/컨텍스트 확인) → 다음 행동 결정(도구 호출 또는 최종 응답) → 행동 실행 및 결과 수집 → 목표 달성 여부 판단(미달 시 반복) 순으로 조율한다.^[1:2]
ReAct는 이 loop 안에서 Thought, Action, Observation을 반복하는 실행 패턴이다.^[1:3] CoT와 ToT를 포함한 세 프레임워크의 층위 차이는 Agent reasoning frameworks에서 비교한다.

이 orchestration loop 구조를, 백서는 주방의 요리사(Chef Analogy)에 비유해 설명한다: 정보 및 제약 요인 수집(주문서와 팬트리 식재료 확인) → 내부 추론(레시피와 향미 프로파일 구상) → 행동 수행(채소 썰기, 시어링 등) → 결과 관찰 및 계획 재조정(식재료 소진 또는 피드백에 맞춰 레시피 수정).^[2]

Model 성능을 강화하는 세 가지 학습 기법

에이전트 아키텍처 안에서 언어 모델이 상황에 맞는 도구를 선택하고 판단하도록 돕기 위해, 백서는 세 수준의 Targeted Learning을 제시한다.^[2:1]

기법	정의	요리사 비유	적용
In-Context Learning	추론 시점에 프롬프트와 few-shot 예시를 제공해 모델이 실시간으로 도구 사용법을 배움	고객으로부터 조리법(프롬프트), 핵심 재료(도구), 완성된 요리 샘플(few-shot)을 받아 현장에서 즉시 요리법을 구상	ReAct 프레임워크 등
Retrieval-Based In-Context Learning	외부 메모리(예: Example Store)와 DB에서 관련 정보·도구 세트·매칭 예시를 실시간 검색해 프롬프트를 동적으로 구성	팬트리(외부 데이터 저장소)에서 재료와 요리책을 동적으로 선택해 새 요리를 개발	RAG와 벡터 DB 검색을 통합한 agent 구조
Fine-Tuning Based Learning	추론 단계 이전에 도구 사용 예시와 태스크 지침 데이터셋으로 모델 자체를 사전 훈련	요리사를 전문 요리 학교에 보내 특정 요리법을 깊이 학습시켜 처음 마주하는 주문서도 정밀하게 처리하게 함	도구 사용 패턴이 고정적이고 대규모 특정 작업 훈련 데이터가 있을 때

(위 표는 백서의 요리사 비유를 Agent Architecture 문맥에 맞게 표로 재구성한 것이며, 원문의 세 항목·비유·적용 예는 그대로 보존했다.)^[2:2]

세 기법 중 추론 전에 모델 자체를 바꾸는 것은 Fine-Tuning Based Learning뿐이고, In-Context Learning과 Retrieval-Based In-Context Learning은 추론 시점에 프롬프트를 구성하는 방식이라고 볼 수 있다. 이는 표의 정의를 학습 시점과 추론 시점으로 다시 읽은 이 페이지의 해석이며, 모델을 바꾸는 학습과 입력만 바꾸는 프롬프트의 경계는 AI and Machine Learning Foundations에서 다룬다.

이 모든 것을 지탱하는 Harness

Harness Engineering 사례는 사람이 코드를 직접 작성하지 않는 제약 아래 Codex로 소프트웨어 제품의 내부 베타를 구축하고 출시한 실험을 기록한다. 5개월 뒤 리포지터리에는 약 백만 라인의 코드가 들어 있었고, Codex를 이끄는 세 명의 엔지니어 팀이 약 1,500개의 PR을 열고 병합해 엔지니어 1인당 하루 평균 3.5개의 PR 처리량을 냈다.^[3] 이는 architecture가 잘 설계되면 orchestration loop 하나가 대규모 실행량을 감당할 수 있다는 근거로 읽을 수 있다.

에이전트 런타임(orchestration loop)이 실행 결정을 내리는 통제 루프라면, Agent Harness는 이 architecture를 안전하게 떠받치는 개발·제약 도구 스택(custom linter, local observability)을 의미한다 — 이는 Runtime과 Harness Engineering 두 source의 용례를 architecture 문맥에서 대비한, 이 페이지의 해석이다.

Architecture가 결정하는 것과 결정하지 않는 것

Architecture는 agent의 능력 범위와 control boundary를 결정한다고 보인다. Model이 강해도 orchestration layer가 tool 선택, observation 반영, stopping condition을 잘못 설계하면 agent는 반복 실패하거나 부적절한 행동을 선택한다.
Workflow와 agent의 차이는 architecture에서 누가 control을 잡는지로 드러난다. 미리 정해진 code path가 주도하면 workflow에 가깝고, LLM이 process와 tool use를 동적으로 조정하면 agent에 가깝다 — AI workflow vs agent 참고.
ReAct는 architecture 전체가 아니라 architecture 안에서 reasoning과 action을 엮는 실행 패턴이다. CoT와 ToT는 주로 reasoning shape를 바꾸고, orchestration layer는 그 reasoning을 언제 실행하고 어떤 action으로 연결할지 결정한다.

Architecture는 prompt template과 다르다. Prompt는 model call의 입력 품질을 높이고, architecture는 여러 call/action/observation을 어떤 control flow로 묶을지 정한다. Predefined workflow도 LLM과 tool을 사용할 수 있지만, dynamic control을 LLM에 얼마나 맡기는지는 별도 architecture 결정이다. ReAct는 중요한 pattern이지만 agent architecture 전체와 동일하지 않다 — memory, tool interface, safety boundary, evaluation, stopping condition은 ReAct 표기만으로 해결되지 않는다.

이 구조가 무너지는 경우

ReAct transcript를 흉내내지만 실제 observation을 state에 반영하지 않는 경우.
Tool이 없는데 tool-use agent처럼 설계하는 경우.
Orchestration layer 없이 prompt만 길게 작성해 다단계 작업을 맡기는 경우.
Stop condition이 약해 반복 loop가 길어지거나 목표를 벗어나는 경우.
Tool 결과 검증 없이 observation을 그대로 신뢰하는 경우.
필요한 것은 workflow인데 agent autonomy를 과하게 열어두는 경우.

출처

테스트 질문

Agent architecture와 prompt template은 어떻게 다른가?
ReAct는 architecture 전체인가, architecture 안의 실행 pattern인가?
Orchestration layer가 약하면 어떤 실패가 생기는가?
Workflow와 agent의 차이는 architecture에서 어디에 나타나는가?

Agent Architecture.md — "에이전트가 정보를 인식하고, 추론하고, 행동을 결정하는 전체 구조", "모델 (Model): 추론을 담당하는 LLM", "오케스트레이션 레이어 (Orchestration Layer): 판단-행동 루프를 조율하는 시스템", "도구 (Tools): 에이전트가 외부 세계와 상호작용하는 수단", 실행 흐름: "사용자 요청 수신 → 현재 상태 파악(메모리/컨텍스트 확인) → 다음 행동 결정(도구 호출 or 최종 응답) → 행동 실행 및 결과 수집 → 목표 달성 여부 판단 → 미달 시 루프 반복", "추론(Reasoning)과 행동(Acting)을 교차하며 실행하는 프레임워크" ↩︎ ↩︎ ↩︎ ↩︎
22365_19_Agents_v8.pdf — 요리사 비유와 Targeted Learning 세 기법. 이 PDF는 이번 변환 세션에서 poppler 부재로 재추출하지 못했고, 2026-07-11 conformance 기록 시점에 검증된 기존 claim을 그대로 유지한다. ↩︎ ↩︎ ↩︎
Harness Engineering.md — (L20) "...Codex로 소프트웨어 제품의 내부 베타를 구축하고 출시하는 실험을 했다.", (L26) "...팀은 의도적으로 사람이 코드를 직접 작성하지 않는 제약을 선택했다.", (L28) "이 제약은 소프트웨어 엔지니어링 팀의 주된 업무가 코드 작성에서 벗어날 때 무엇이 달라지는지 드러냈다.", (L51) "5개월 뒤 리포지터리에는... 약 백만 라인의 코드가 들어 있었다. Codex를 이끄는 세 명의 엔지니어 팀은 약 1,500개의 pull request를 열고 병합했다. 이는 엔지니어 1인당 하루 평균 3.5개의 PR 처리량에 해당한다." ↩︎