개요
Ai agent 설계를 해보았고, 엔지니어링을 위한 개념을 들어가 볼 것입니다.
: 기존의 단순 LLM 호출과 AI Agent의 가장 큰 차이는 ‘ 스스로 판단하고 외부 세계와 상호작용할 수있는가’입니다.
AI Agent는 크게 4가지 레이어로 구성할 수 있습니다
- Tool / Capability ( 도구/능력 ) : 에이전트가 손발처럼 사용하는 외부 기능을 말합니다.
- Agent가 실제로 할 수 있는 능력
- EX) 인터넷 검색 , 계산기 API 호출 )
- Execution Pattern ( 실행 패턴 ) : 전달받은 작업을 어떤 순서와 논리 구조로 진행할지 정하는 ‘행동/사고 알고리즘’입니다.
- 능력을 사용하는 실행 흐름
- Agent Archetype (에이전트 원형/역할) : 특정한 목적을 달성하기 위해 Tool과 Execution Pattern을 결합하여 만든 ‘전문 직무( 스페셜리스트 )’입니다.
- 능력과 흐름을 결합한 역할
- Multi-Agent ( 다중 에이전트 ) : 서로 다른 역할을 가진 여러 Agent Archetype들이 팀을 이루어대화하고 작업물을 주고받으며 복잡한 문제를 해결하는 조직 구조입니다.
- 여러 역할을 연결한 협업 구조
AI Agent의 구성 요소
Tool / Capability (도구 및 능력)
일반적인 LLM 호출은 입력을 받아 텍스트를 생성하는 데 중심이 있습니다. 반면 Agent는 외부 세계에 영향을 주는 행동을 수행할 수 있습니다. 최신 정보를 검색하거나, 파일을 읽거나, 데이터베이스를 조회하거나, 코드를 실행하는 일은 모델의 언어 생성만으로 완결되지 않습니다. 이때 실제 실행을 담당하는 것이 Tool입니다.
단순 LLM vs AI Agent (Tool Calling)
- 기존 LLM: "텍스트를 받아 다음 텍스트를 예측해 출력"하는 뇌 역할만 수행합니다.
- Tool을 가진 Agent: LLM이 스스로 "지금은 계산기가 필요하군", "지금은 사내 DB를 조회해야겠어"라고 판단하여 원하는 Tool 이름과 전달 인자(Arguments)를 JSON 형태로 생성합니다.
- 실행 방식: 모델이 직접 파이썬 코드를 실행하거나 웹을 검색하는 것이 아니라, 모델은 "A 함수를 X 인자값으로 실행해 줘"라는 요청만 남기고, 실제 실행은 이를 감싸고 있는 서버/런타임(Runtime)이 수행한 뒤 그 결과(Observation)를 다시 모델에게 돌려줍니다.
Tool Calling의 기본 흐름
사용자 요청
↓
LLM이 필요한 도구 판단
↓
도구 이름과 인자 생성
↓
런타임이 권한·입력 검증 후 도구 실행
↓
실행 결과(observation)를 LLM에 반환
↓
LLM이 다음 행동을 결정하거나 최종 답변 작성주요 Capability의 의미
| Capability | 핵심 역할 | 실무 비유 |
|---|---|---|
| Web Search | 최신 인터넷 데이터 수집 | 실시간 구글링하는 리서처 |
| File Search / Retrieval | 특정 문서, 사내 위키, 백서 등 검색 (RAG) | 사내 도서관/문서고 전담 관리자 |
| Code Interpreter | 격리된 공간(Sandbox)에서 파이썬 코드 실행 | 검증용 가상 PC를 가진 데이터 분석가 |
| Computer Use / Browser | 클릭, 스크롤, 키보드 입력 등 GUI 직접 조작 | RPA(업무 자동화) 로봇 |
| Function Calling | REST API, 데이터베이스 조회, 결제 처리 | 백엔드 서버 엔드포인트 연결 |
| MCP (Model Context Protocol) | 다양한 데이터/도구를 표준화된 인터페이스로 통일 | 모든 기기를 연결하는 USB-C 포트 |
| Agents as Tools | 다른 에이전트 자체를 하나의 도구처럼 호출 | “김 대리한테 물어봐” 하고 팀원에게 외주 주기 |
워크플로우와 Agent의 핵심 차이
- Workflow (정적 프로세스) :
A 실행 -> B 실행 -> C 실행처럼 결과와 관계없이 항상 정해진 순서대로 작동하는 자동화 파이프라인. - Agent (동적 판단):
A 실행 -> 결과 관찰 -> (결과가 이상하네?) -> B 대신 D 실행 -> 최종 답안 작성처럼 결과에 따라 다음 행동을 LLM이 자율적으로 판단하여 반복하는 시스템.
Execution Pattern (실행 패턴)
: 에이전트가 문제를 해결할 때 채택하는 사고 및 작업 흐름의 설계 방식입니다.
[Prompt Chaining] : A ──> B ──> C (직렬)
[Parallelization] : A ┬─> B ─┬─> 합침 (병렬)
└─> C ─┘
[ReAct] : 생각 ──> 행동(Tool) ──> 관찰 ──> (반복) ──> 완료| 패턴 | 핵심 개념 | 적합한 상황 | 이해하기 쉬운 예 |
|---|---|---|---|
| Prompt Chaining | LLM 호출을 단계별로 연결 | 단계가 명확한 처리 | 초안 작성 → 요약 → 교정 |
| Routing | 입력을 분류해 경로 선택 | 요청 유형이 다양함 | 환불 문의와 기술 문의 분리 |
| Parallelization | 독립 작업을 동시에 수행 후 통합 | 여러 출처·독립 검토 | 세 사이트를 동시에 조사 |
| ReAct | 판단 → 행동 → 관찰 반복 | 결과에 따라 다음 행동 변경 | 검색 결과가 부족하면 재검색 |
| Plan-and-Execute | 먼저 계획을 만들고 순서대로 실행 | 긴 리서치·보고서·코드 작업 | 목차 작성 후 장별 조사 |
| Reflection / Evaluator | 결과를 평가하고 개선 | 품질이 중요한 생성 작업 | 코드 생성 → 테스트·리뷰 → 수정 |
| Orchestrator-Workers | 중앙 조정자가 하위 작업 분배 | 작업을 전문 단위로 나눌 때 | 파일별 수정 담당 배정 |
| Graph / State Machine | 상태와 전이를 명시적으로 관리 | 복구·승인·장기 실행 | 결제 승인 대기 후 재개 |
1) Prompt Chaining (프롬프트 체이닝)
: Prompt Chaining은 여러 LLM 호출을 직렬로 연결하는 방식입니다. 첫 번째 호출의 결과가 두 번째 호출의 입력이 됩니다. 예컨대 고객 리뷰를 먼저 분류하고, 그 결과를 바탕으로 요약한 뒤, 마지막으로 답변 문안을 만드는 구조입니다.
장점은 흐름이 명확하고 테스트가 쉽다는 점입니다. 반면 중간 단계의 오류가 다음 단계로 전파될 수 있습니다. 따라서 단계 사이에 형식 검증과 품질 검사를 두는 것이 좋습니다.
- 개념: 하나의 큰 작업을 여러 단계의 프롬프트로 쪼개어 순차적으로 연결하는 방식입니다.
- 비유: 공장의 컨베이어 벨트.
2) Routing (루팅)
Routing은 사용자의 입력을 분류한 뒤 적절한 처리 경로로 보내는 패턴입니다. “배송이 늦어요”는 배송 Agent로, “비밀번호를 바꾸고 싶어요”는 계정 Agent로 보내는 식입니다. Routing의 핵심은 분류 기준과 분류 실패 시의 기본 경로를 명확히 하는 것입니다.
- 개념: 입력을 분석하여 가장 잘 처리할 수 있는 특정 경로(프롬프트 or 도구 or 하위 에이전트)로 분기시키는 방식입니다.
- 비유: 고객센터의 ARS 안내 ("배송 문의는 1번, 환불 문의는 2번").
3) Parallelization (병렬화)
Parallelization은 서로 의존하지 않는 작업을 동시에 실행합니다. 여러 웹 출처를 동시에 검색하면 전체 대기 시간을 줄일 수 있지만, 결과를 합칠 때 중복·충돌·출처 신뢰도 문제를 처리해야 합니다.
- 개념: 여러 개의 LLM 호출을 동시에 실행한 후, 그 결과들을 하나로 종합하는 패턴입니다.
- 비유: 교과서 여러 권을 여러 명이 동시에 나눠 읽은 뒤 모여서 요약본 만들기.
4) ReAct (Reason + Act)
ReAct는 Reasoning과 Acting을 번갈아 수행하는 구조로 이해할 수 있습니다. 모델이 문제를 보고 행동을 선택하고, 도구 결과를 관찰한 뒤 다시 다음 행동을 선택합니다.
이 패턴은 정답을 한 번에 알 수 없는 문제에 유용합니다. 그러나 반복 횟수가 제한되지 않으면 비용과 실행 시간이 커지고, 도구를 끝없이 호출할 수 있습니다. 따라서 최대 반복 횟수, 시간 제한, 예산 제한, 중단 조건을 반드시 둬야 합니다.
질문 → 판단 → 도구 호출 → 결과 관찰 → 재판단 → 추가 호출 또는 답변- 개념: '생각(Thought)→ 행동(Action/Tool 호출) → 관찰(Observation/결과 확인)'의 루프를 반복하며 문제를 해결하는 가장 대표적인 에이전트 패턴입니다.
- 비유: 여행 계획표를 미리 다 짜놓고 하나씩 방문지를 찍는 여행가.
5) Plan-and-Execute (계획 후 실행)
Plan-and-Execute는 실행 전에 전체 계획을 세우는 방식입니다. 긴 보고서를 작성할 때 먼저 질문을 하위 주제로 쪼개고, 각 주제에 필요한 자료와 순서를 결정한 뒤 실행합니다.
계획이 있으면 전체 목표와 진행 상황을 관리하기 쉽습니다. 다만 초기 계획이 틀렸을 때 고집스럽게 유지하면 비효율적일 수 있으므로, 실행 결과에 따라 계획을 수정하는 재계획 단계를 포함해야 합니다.
- 개념: 먼저 전체적인 실행 계획(Sub-tasks)을 수립한 뒤, 각 단계를 차례대로 실행하며 필요 시 계획을 수정하는 패턴입니다.
- 비유: 여행 계획표를 미리 다 짜놓고 하나씩 방문지를 찍는 여행가.
6) Reflection / Evaluator (반성 및 평가)
Reflection은 Agent가 만든 결과를 스스로 검토하고 개선하는 패턴입니다. 별도의 Evaluator가 기준에 따라 평가하도록 만들 수도 있습니다. 글이라면 사실성·논리성·문체를, 코드라면 테스트 통과·보안·변경 범위를 평가할 수 있습니다.
평가 기준이 모호하면 “더 좋게 고쳐라” 수준에 머물 수 있습니다. 따라서 평가 항목을 측정 가능한 형태로 정의하고, 개선 시도 횟수와 종료 조건을 정해야 합니다.
- 개념: 생성자(Generator)가 결과물을 만들면, 평가자(Evaluator)가 피드백을 주고, 이를 바탕으로 다시 수정하는 루프입니다.
- 비유: 글을 쓰는 작가와 이를 검수하고 빨간 펜으로 고쳐주는 편집장.
7) Orchestrator-Workers (지휘자-작업자)
Orchestrator-Workers에서는 중앙 조정자가 업무를 나누고 여러 Worker에게 실행을 맡긴 뒤 결과를 합칩니다.
예를 들어 문서 승인 시스템은 작성 중 → 검토 중 → 수정 요청 → 승인 완료라는 상태를 가질 수 있습니다. 사람의 승인을 기다리거나 오류 이후 재개해야 하는 업무에서는 단순한 직렬 호출보다 상태 기반 설계가 안정적입니다.
- 개념: 중앙의 Orchestrator가 큰 문제를 작게 쪼개어 여러 Worker에게 나눠주고, Worker들이 가져온 결과를 지휘자가 다시 하나로 합칩니다.
- 비유: 프로젝트 매니저(PM)가 개발자, 디자이너, 기획자에게 업무를 배분하고 진행 상황을 관리하는 형태.
8) Graph / State Machine (상태 기반 제어)
Graph 또는 State Machine은 시스템의 상태와 전이를 명시적으로 표현합니다.
- 개념: 작업의 '상태(State)'와 조건부 이행(Edge)을 명시적 그래프로 정의합니다.
- 비유: 게임의 퀘스트 진행 트리 (A조건 만족 시 B엔딩, 중간에 사용자가 개입(Human-in-the-loop) 가능).
Agent Archetype (에이전트 페르소나/유형)
: 자주 쓰이는 Tool과 Execution Pattern을 결합하여 특정한 전문 직무 형태로 세팅해 둔 에이전트 유형들입니다.
┌─────────────────────────────────────────────────────────────┐
│ Agent Archetype │
│ ┌───────────────────────┐ ┌─────────────────────────┐ │
│ │ Tool / Capability │ + │ Execution Pattern │ │
│ │ (Web, Code, DB, ...) │ │ (ReAct, Reflection,...) │ │
│ └───────────────────────┘ └─────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘1) Researcher Agent (조사/리서치 에이전트)
Researcher Agent는 여러 출처를 조사하고, 내용을 비교·요약하며, 근거를 남기는 역할입니다. 단순히 검색 결과를 나열하는 것이 아니라 질문을 하위 문제로 나누고, 신뢰할 수 있는 자료를 선별하며, 상충되는 내용을 표시해야 합니다.
- 단순 RAG와의 차이점:
- 단순 RAG: "데이터베이스에서 관련 문서 3개 찾아서 요약해 줘." (단발성)
- Researcher Agent: "A와 B 기술을 비교해 줘." → A 검색 → 정보 부족 → 추가 키워드 검색 → B 검색 → A와 B의 정보 상충 확인 → 추가 검증 검색 → 최종 보고서 작성 (자율적 심층 탐색)
- 핵심 패턴: ReAct, Plan-and-Execute
- 주요 리스크: 인터넷의 거짓 정보를 사실로 믿는 문제(Hallucination), 최신성 부족.
2) Code Interpreter / Data Analyst Agent (데이터 분석 에이전트)
Code Interpreter는 Agent에게 계산과 실행 능력을 부여하는 Capability입니다. Data Analyst Agent는 이 능력을 데이터 분석 업무에 맞게 구성한 Archetype이라고 볼 수 있습니다.
- 작동 방식: 직접 계산을 머리로 하지 않고, Python 코드를 작성해 Sandbox 환경에서 실행한 뒤 출력된 통계값이나 차트를 읽어서 설명합니다.
- 텍스트-투-SQL(Text-To-SQL)에서의 유용성: 대용량 데이터베이스 전체를 LLM 문맥(Context)에 다 넣을 수 없으므로, 에이전트에게 DB 테이블의 구조(Schema)만 보여준 뒤 "쿼리를 만들어서 실행해 보고, 그 결과 집계표만 나에게 해석해 줘"라고 처리합니다.
3) Coding Agent (코딩 에이전트)
Coding Agent는 Code Interpreter와 비슷해 보이지만 작업 대상이 다릅니다. Code Interpreter가 격리된 환경에서 계산이나 파일 처리를 수행한다면, Coding Agent는 실제 저장소의 코드를 읽고 수정하며 테스트합니다.
Code Interpreter와의 차이점
| 구분 | Code Interpreter Agent | Coding Agent |
|---|---|---|
| 목적 | 데이터 분석, 일회성 계산, 차트 생성 | 실제 소프트웨어 제품의 코드 수정 및 빌드 |
| 작업 공간 | 격리된 파이썬 가상 공간 (Sandbox) | 실제 프로젝트 코드베이스 (GitHub Repo) |
| 주요 도구 | python_exec, file_upload | file_read, file_edit, run_tests, git |
| 위험성 | 가상 공간의 메모리/시간 초과 정도 | 기존 소스코드 파손, 버그 유발, 종속성 꼬임 |
- 필수 루프:
Explore(탐색) -> Plan(계획) -> Implement(구현) -> Test/Verify(검증)- 성공적인 Coding Agent는 코드를 고친 후 단위 테스트(Unit Test)를 실행하여 실패하면 스스로 코드를 다시 고치는 능력을 갖추고 있습니다.
- 성공적인 Coding Agent는 코드를 고친 후 단위 테스트(Unit Test)를 실행하여 실패하면 스스로 코드를 다시 고치는 능력을 갖추고 있습니다.
4) Orchestrator Agent (오케스트레이터 에이전트)
Orchestrator Agent는 직접 모든 일을 처리하기보다 요청을 분해하고, 적절한 Tool·Workflow·Agent에 작업을 배분한 뒤 결과를 합성합니다. 회사의 프로젝트 관리자나 관제센터에 비유할 수 있습니다.
- 핵심 역할: 복잡한 요청을 처리하기 위한 ‘총괄 매니저’.
- Single Agent vs Multi-Agent Orchestration:
- Single Agent Orchestrator: 매니저 에이전트 하나가 자기가 가진 여러 도구(검색 도구, 계산 도구, 요약 도구)를 순서대로 꺼내 쓰는 방식.
- Multi-Agent Orchestrator: 매니저 에이전트가 하위의 'Researcher Agent', 'Data Analyst Agent' 등 독립된 다른 에이전트들에게 일을 할당하고 그 보고를 받아서 통합하는 방식.
Single Agent와 Multi-Agent의 관계
Single Agent와 Multi-Agent는 완전히 다른 원리라기보다 규모와 역할 분리의 차이입니다. 두 구조 모두 Tool, 실행 패턴, 상태 관리, 오류 처리가 필요합니다.
| 기준 | Single Agent | Multi-Agent |
|---|---|---|
| 구성 | 하나의 모델이 여러 도구 사용 | 여러 전문 Agent가 역할 분담 |
| 장점 | 단순한 구조, 낮은 통신 비용 | 전문화, 병렬 처리, 역할별 검증 |
| 단점 | 프롬프트와 책임이 복잡해짐 | 조정 비용, 통신 오류, 비용 증가 |
| 적합한 경우 | 도구가 적고 흐름이 짧은 업무 | 분야별 전문성이 필요하고 작업이 큰 업무 |
요약 및 마무리
- 단순한 작업 → 단일 LLM 프롬프트 또는 Prompt Chaining / Routing (Workflow)
- 도구가 필요한 작업 → Single Agent + Tool Calling (ReAct)
- 전문 분야가 명확히 나뉘고 긴 호흡이 필요한 작업 → Orchestrator + Multi-Agent
