AI Agent

 

AI Agent란?

 

개념

사용자가 전달한 목표를 달성하기 위해 상황을 판단하고, 필요한 행동을 선택하며, 도구를 사용해 여러 단계의 작업을 수행하는 AI 시스템

 

일반적인 LLM 사용에서는 사용자가 질문을 입력하면 모델이 답변을 생성하는 것으로 작업이 끝나는 경우가 많음

사용자 입력 → LLM → 응답 생성

 

AI Agent는 단순히 답변을 생성하는 것에서 끝나지 않고,

주어진 목표를 확인한 뒤 필요한 작업을 판단하고 외부 도구를 사용하며, 그 결과를 다시 확인해 다음 행동을 결정할 수 있음.

 

이렇게 할 수 있는 이유 => LLM에 Tool(도구)과 실제 실행 환경을 연결해 놓았기 때문.

즉, LLM이 판단하고 → 연결된 Tool을 호출하고 → 실행 결과를 다시 받아 → 다음 행동을 판단하는 구조가 있기때문.

 

목표 전달 → 상황 파악 → 다음 행동 결정 → Tool 사용(선택 및 호출)  → 외부 환경에서 작업 수행 →  결과 확인 → 다음 행동 결정 ↺

 

요소	역할
LLM	목표와 현재 상황을 이해하고 다음 행동을 판단
Tools	검색, API 호출, 파일 처리, 데이터 조회 등 외부 작업 수행
Tool Calling	LLM이 필요한 Tool을 선택하고 호출
Agent Loop	판단 → 행동 → 결과 확인 → 재판단 과정을 반복
Context	현재 판단에 필요한 정보 제공
State / Memory	작업 과정에서 필요한 상태나 정보를 유지

 

 

Q ] AI Agent는 LLM 자체인가?

A]  아님

AI Agent는 일반적으로 LLM을 판단을 위한 Model로 사용하면서 Tool, Context, State 등을 연결하고 반복적으로 작업할 수 있도록 만든 애플리케이션 시스템

 

LLM = 입력을 바탕으로 출력을 생성하는 Model

AI Agent = LLM을 포함하여 외부 Tool과 실행 흐름 등을 연결한 시스템 

 

Q] 이 Agent 시스템은 누가 만드는가?

A] Agent를 사용하는 서비스의 개발자 또는 Agent 플랫폼 제공자

 

예를들어 개발자가 직접 Agent를 만든다면,

사용자 → 개발자가 만든 Agent Application → LLM API → Model의 Tool Call 출력 → Agent Application → 실제 Tool 실행 → 실행 결과를 다시 LLM에 전달

Q] AI Agent가 외부 작업을 수행할 수 있는 이유

A] 

LLM 자체가 파일 시스템, 데이터베이스, 검색 API 등을 직접 가지고 있는 것은 아님. 

Agent 시스템에서 LLM과 외부 Tool을 연결해 놓기 때문에 외부 작업을 수행할 수 있음. 

 

Model이 Tool Call 생성 → Agent Application이 Tool 실행 → 실행 결과를 Model에게 다시 전달

 

비교 : Workflow

구분	Workflow	AI Agent
작업 흐름	개발자가 주로 미리 정의	일부 작업 경로를 실행 중 Model이 선택
다음 행동 결정	규칙·조건문으로 결정	현재 Context와 실행 결과를 바탕으로 Model이 선택
Tool 사용 순서	미리 정의한 분기 필요	결과를 보고 다른 행동 선택 가능
예외 처리	미리 정의한 분기 중심	결과에 따라 다른 행동이나 Tool을 선택할 수 있음
유연성	상대적으로 낮음	상대적으로 높음
예측 가능성	높음	상대적으로 낮음
적합한 작업	반복적이고 규칙이 명확한 작업	상황 판단이 필요한 복잡한 작업

 

 

Q] Agent도 결국 Workflow로 만드는 것 아닌가?

A] 

Agent역시 개발자가 만든 실행 흐름 위에서 동작함. 

큰 틀 자체는 개발자가 설계 

Model 호출 → Tool Call이 있는지 확인 → Tool 실행 → 결과를 Model에 전달 → Model 다시 호출 → 완료될 때까지 반복

 

다만, 일반적인 Workflow와 다른 점은 그 안에서

어떤 Tool을 사용할지 → 어떤 값을 Tool에 전달할지 → 결과를 보고 다시 검색할지 → 다른 Tool을 사용할지 → 작업을 종료할지 

등을 코드에 모두 고정하지 않고 Model이 현재 입력을 바탕으로 선택할 수 있음. 

 

차이는 Workflow 내부의 세부 경로까지 개발자가 모두 정해놓느냐.

 

실제 서비스에서는 둘 중 하나만 선택할 필요 없고, 

오히려 중요한 부분은 Wokflow로 고정하고, 판단이 필요한 부분만 Agent에게 맡기는 방식이 많이 사용될 수 있다. 

 

장점과 한계

장점

• 여러 단계의 작업 수행 : 단순한 질무에 답하는 것뿐 아니라 하나의 목표를 여러 단계로 나누어 처리할 수 있음.
• 외부 Tool 활용 : AI Agent는 Tool을 통해 모델이 직접 처리할 수 없는 작업까지 수행할 수 있음. 
• 상황에 따른 유연한 대응 : Workflow처럼 모든 실행 경로를 미리 정의하지 않아도 중간 결과에 따라 다음 행동을 변경할 수 있음. 
• 반복 작업 자동화 : 여러 Tool과 단계가 필요한 작업도 하나의 목표로 전달할 수 있다. 

한계

• 잘못된 판단 가능성 : AI Agent판단을 담당하는 Model 역시 항상 정확한 것은 아님
• Tool 실행 실패 : Agent가 올바른 Tool을 선택했다고 하더라도 Tool 자체의 실행이 항상 성공하는 것은 아님. 
  => API 오류, 네트워크 오류, 권한 부족, 파일 접근 실패, 잘못된 입력값 등이 발생할 수 있음. 
  따라서, Agent는 실행 결과가 실패했는지 확인하고 적절하게 대응할 수 있어야 함
• Context의 한계 : Agent가 올바른 판단을 하려면 필요한 정보가 충분히 제공되어야 함 중요한 정보가 빠져 있거나 오래된 정보가 포함되어 있다면 판단 역시 잘못될 수 있음. 
• 긴 작업에서의 상태 관리 : 작업 단계가 많아질수록 상태(어떤 작업을 완료했는지, 현재 무엇을 하고 있는지, 어떤 결과가 나왔는지, 다음에 무엇을 해야 하는지) 등을 계속 유지해야 함
  => 이러한 상태가 제대로 관리되지 않으면 이미 완료된 작업을 반복하거나 중요한 단계를 놓칠 수 있음. 
• 비용과 실행 시간 증가 : Agent는 한 번의 모델 호출로 끝나는 것이 아니라 여러 번의 판단과 Tool 호출을 반복할 수 있음. 
  => 따라서 일반적인 단일 요청보다 토큰 사용량, API 호출수, 실행 시간이 증가할 수 있음
• 권한과 안정성 문제 : 어떤 작업까지 허용할 것인지도 중요, 지나치게 많은 권한을 주면 잘못된 판단이 시스템 변경으로 이어질 수 있음

---

 

AI Agent의 기본 구조

 

하나의 요소만으로 동작하기보다는, 

모델이 필요한 정보를 바탕으로 판단하고 외부 도구를 사용하며 작업 상태를 이어갈 수 있도록 여러 요소가 함께 구성됨

        사용자 목표
             ↓
           Model
      판단 / 다음 행동 결정
        ↙           ↘
   Context          Tools
 필요한 정보       실제 행동
        ↖           ↙
        Memory / State
          상태 유지

AI Agent
├─ Model
├─ Context
├─ Tools
└─ Memory / State

 

개념	설명
Model	Agent의 판단을 담당하는 핵심 요소.  => 사용자의 목표와 현재 상황을 이해하고,  - 무엇을 해야 하는지 - 어떤 정보가 필요한지 - 어떤 Tool을 사용할지 - Tool 실행 결과를 보고 다음에 무엇을 할지 등을 판단함.
Context	Model이 현재 판단을 내릴 때 참고하는 정보 (Model은 모든 정보를 항상 알고 있는 것이 아니기 때문에, 현재 작업에 필요한 정보를 Context로 전달받아 판단) ex) 사용자의 요청, 현재 대화 내용, 검색된 문서, Tool 실행 결과, 작업에 필요한 데이터
Tools	Agent가 외부 환경에서 실제 행동을 수행할 수 있도록 하는 기능 (행동담등)
Memory / State	Agent가 작업을 수행하면서 필요한 정보나 현재 작업 상태를 유지하기 위한 요소 - Memory : 이전 작업이나 상호작용에서 유지할 정보 - State : 현재 작업이 어디까지 진행되었는지에 대한 상태

 

---

 

AI Agent는 어떻게 동작할까?

 

앞에서 본 Model, Context, Tools, Memory/State는 각각 따로 동작하는 것이 아니라 서로 연결되어 하나의 작업 흐름을 만든다. 

이 과정에서 중요한 개념이 Tool Calling과 Agent Loop

목표
 ↓
Model 판단
 ↓
Tool Calling
 ↓
Tool 실행
 ↓
결과 반환
 ↓
Model 재판단
 ↓
필요하면 반복

 

Tool Calling

Model이 현재 작업에 필요한 외부 기능을 선택하고 호출하는 방식 

=> 필요한 작업을 판단 → 적절한 Tool 호출 → 실행 결과를 다시 받아 활용 

 

Tool

일반적으로 LLM 내부에 존재하는 기능은 아님. 

개발자 입장에서는 Tool은 LLM이 사용할 수 있도록 등록한 함수나 API 

 

Tool의 종류

Agent가 수행하는 작업에 따라 달라질 수 있음

ex) Web Search (웹에서 정보 검색), API (외부 서비스와 데이터 송수신), File (파일 읽기/수정) 

 

Q] Model은 Tool이 있다는 것을 어떻게 아는가?

A]

Agent Application이 LLM이 호출할 때 사용 가능한 Tool의 정의를 함께 전달하기 때문. 

 

ex) 사용자 요청 : 서울 현재 날씨 알려줘. 

사용 가능한 Tool : 

get_wether

- 특정 도시의 현재 날씨 조회

- city : string

 

Model은 이 정보를 현재 Context의 일부로 받아들임. 

즉 Model이 인터넷에서 Tool을 찾아오는 게 아니라, 

개발자 → 사용 가능한 Tool 정의 제공 → Model 

 

 

 

Q] Model은 어떻게 Tool을 선택할 수 있는가?

A] 

모든 LLM이 기본적으로 Tool Calling을 지원하는 것은 아님. 

 

Tool Calling을 지원하는 Model은 사용자의 요청과 제공된 Tool 정의를 바탕으로 적절한 Tool Call 형식의 출력을 생성할 수 있도록 학습+설계된 Model

 

ex)

사용자 : 현재 날씨 알려줘. 

사용 가능한 Tool : get_weather(city)

라는 입력이 있다면 Model이 일반적인 문장 대신 개념적으로 다음과 같은 출력을 생성할 수 있음. 

{
  "tool": "get_weather",
  "arguments": {
    "city": "서울"
  }
}

=> 현재 Context와 Tool 정의를 바탕으로 Model이 get_weather Tool Call을 출력함. 

 

이런 Model인지 알 수 있는 방법 => LLM 제공사의 모델 공식 문서와 기능 명세 확인

모델마다 Tool Calling, Function Calling, Structured Output 등의 지원 여부가 다를 수 있음. 

 

 

Tool Calling 전체 흐름

① 개발자
   사용할 Tool 구현 / 연결
        ↓

② LLM 호출 시
   Tool 이름 + 설명 + 입력 형식 전달
        ↓

③ Model
   사용자 요청과 Tool 정의를 바탕으로
   일반 응답 또는 Tool Call 출력
        ↓

④ Tool Call 발생
        ↓

⑤ Agent Application
   실제 함수 / API 실행
        ↓

⑥ Tool 실행 결과 반환
        ↓

⑦ Agent Application
   결과를 다시 Model에게 전달
        ↓

⑧ Model
   결과를 바탕으로 다음 출력 생성

 

 

Agent Loop

Tool을 한 번 호출하는 것만으로 모든 작업이 끝나는 것이 아니고,

복잡한 목표를 처리하려면 Tool의 실행 결과를 확인하고, 그 결과에 따라 다음 행동을 다시 결정하는 과정이 필요함. 

이러한 반복적인 흐름을 Agent Loop 

현재 상황 확인
       ↓
다음 행동 선택
       ↓
행동 실행
       ↓
결과 확인
       ↓
목표 달성?
  ↙             ↘
NO               YES
↓                 ↓
다시 Model 호출    종료

 

---

 

AI Agent를 만드는 방법

 

순서	설명
1. Agent의 목표를 정함	역할과 행동 범위를 결정 ex) 날씨 Agent → 사용자가 요청한 지역의 날씨를 조회하고 안내  ex) 고객지원 Agent → 고객 질문을 분석하고 주문 정보를 조회해 답변
2. Model을 연결함	Agent의 판단에 사용할 LLM API를 연결 Agent Application → LLM Client → Open API / Anthropic /... ex) class LlmClient {     public function generate(array $messages, array $tools)     {         // LLM API 요청     } }
3. Agent가 사용할 Tool을 만듦	Tool은 실제로 개발자가 만든 Application 기능 ex) 날씨 Agent class WeatherTool {     public function execute(string $city): array     {         // Weather API 호출     } }
4. Tool Registry를 만듦	Agent가 사용할 수 있는 Tool들을 한곳에서 관리하는 구조 필요 Model에 전달할 Tool명세도 여기서 만들 수 있음.  => 이 부분이 있어야, Model이 tool을 출력 할 때 실제로 어떤 코드를 실행할지 알 수 있다.  ex) $tools = [     'get_weather' => new WeatherTool(),     'search_web'  => new SearchTool(), ];
5. Context를 관리하는 부분을 만듦	매번 LLM에게 사용자 요청만 보내는 것은 아님,  System Instrunction, 사용자 요청, 이전 대화, Tool 실행 결과, 현재 Task State 등을 조합해서 Model에 전달해야 함.
6. Tool Executor을 만듦	Model의 반환값에서 실제 Tool을 찾아 실행하는 부분이 필요함. ex) class ToolExecutor {     public function execute(string $name, array $arguments)     {         $tool = $this->tools[$name];         return $tool->execute(...$arguments);     } }
7. Agent Controller / Loop를 만듦	구성요소들을 하나로 묶어주는 실행 코드 필요 ex) class Agent {     public function run(string $request)     {         while (true) {             $context = $this->context->build();             $response = $this->llm->generate(                 $context,                 $this->tools->definitions()             );             if ($response->isToolCall()) {                 $result = $this->toolExecutor->execute(                     $response->tool,                     $response->arguments                 );                 $this->context->addToolResult($result);                 continue;             }             return $response->text;         }     } }

 

 

---

 

예시

 

• 코드 리뷰 에이전트 : PR 확인 → 변경 파일 분석 → 위험 코드 탐지 → 테스트 필요 영역 정리 → 리뷰 코멘트 작성
• 장애 분석 에이전트 : 에러 로그 조회 → 최근 배포 내역 확인 → DB 쿼리 지연 확인 → 원인 후보 정리
• WordPress 운영 에이전트 : 플러그인 충돌 확인 → 느린 쿼리 분석 → 관리자 페이지 오류 확인 → 수정안 제시