AI 시리즈 3편: AI Agent란 무엇인가 (구조와 동작 원리 정리)

AI Agent란 무엇인가

AI Agent는 사용자의 요청을 받아서 단순히 답변만 하는 AI가 아닙니다.
목표를 이해하고, 필요한 작업을 계획하고, 외부 도구를 사용해서 실제 행동까지 수행하는 AI 시스템입니다.

예를 들어 사용자가 이렇게 요청했다고 가정해보겠습니다.

내 EKS 클러스터 상태를 점검하고 문제가 있으면 원인을 알려줘

 

일반 LLM은 이 요청에 대해 “이런 명령어를 실행해보세요”라고 설명할 수 있습니다.

하지만 AI Agent는 조금 다릅니다.

AI Agent는 다음과 같은 흐름으로 동작할 수 있습니다.

1. EKS 상태를 확인해야 한다고 판단
2. Kubernetes API 또는 kubectl 도구 선택
3. Pod 상태 조회
4. Event와 로그 확인
5. 문제 원인 정리
6. 사용자에게 결과 전달

즉, AI Agent는 설명에서 끝나는 것이 아니라 실제 작업 수행 흐름까지 이어지는 구조입니다.

 

LLM과 AI Agent의 차이

llm 과 ai agent 의 차이

LLM은 문장을 생성하는 모델입니다. 사용자가 질문하면 그에 맞는 답을 만들어냅니다.
반면 AI Agent는 LLM을 중심으로 여러 기능을 결합한 시스템입니다.

쉽게 비교하면 다음과 같습니다.

구분	LLM	AI Agent
역할	답변 생성	목표 달성
행동	텍스트 생성 중심	도구 사용 가능
외부 시스템 접근	기본적으로 불가	API, DB, 파일, 클라우드 접근 가능
흐름	질문 → 답변	목표 → 계획 → 실행 → 결과
예시	“명령어를 알려줌”	“명령어를 실행하고 결과 분석”

한 줄로 정리하면 다음과 같습니다.

LLM은 두뇌이고, AI Agent는 두뇌에 손과 발을 붙인 구조다.

 

---

 

왜 AI Agent가 필요한가

LLM은 강력하지만 한계가 있습니다.

LLM은 기본적으로 학습된 지식과 입력된 문맥을 바탕으로 답변을 생성합니다. 하지만 실제 시스템 상태를 직접 확인하거나, API를 호출하거나, 데이터베이스를 조회하거나, 파일을 수정하지는 못합니다.

예를 들어 LLM에게 “현재 서버 상태 알려줘”라고 하면, LLM은 실제 서버에 접근할 수 없기 때문에 일반적인 점검 방법만 알려줄 수 있습니다.

하지만 AI Agent는 외부 도구와 연결될 수 있습니다.

LLM + Tool + 실행 흐름 = AI Agent

이 구조가 되면 AI는 단순히 말하는 시스템이 아니라, 실제 업무를 수행하는 시스템에 가까워집니다.

 

---

 

AI Agent의 기본 구조

AI Agent는 보통 다음 요소로 구성됩니다.

ai agent 동작 흐름

1. 사용자 요청 이해

먼저 Agent는 사용자의 요청을 이해합니다.

예를 들어 사용자가 이렇게 말합니다.

최근 장애 원인을 분석해줘

Agent는 이 요청이 단순한 설명 요청이 아니라, 로그나 메트릭을 확인해야 하는 작업이라고 판단할 수 있습니다.

 

2. 계획 수립

다음으로 해야 할 일을 나눕니다.

1. 최근 에러 로그 조회
2. 메트릭 확인
3. 배포 이력 확인
4. 원인 후보 정리
5. 최종 분석 결과 작성

이 단계가 Agent와 일반 챗봇의 큰 차이입니다.
Agent는 목표를 달성하기 위해 작업 단계를 구성합니다.

 

3. Tool 선택

Agent는 작업에 필요한 도구를 선택합니다.

예를 들어 DevOps Agent라면 다음과 같은 Tool을 사용할 수 있습니다.

Kubernetes API
AWS CLI
Grafana API
Prometheus API
Log API
GitHub API
Slack API

LangChain 문서에서도 Tool은 Agent가 실시간 데이터를 가져오고, 코드를 실행하고, 데이터베이스를 조회하고, 외부 시스템에서 행동할 수 있게 해주는 함수라고 설명합니다.

 

4. Tool 실행

Tool을 선택한 뒤 실제 실행은 애플리케이션 쪽에서 수행합니다.

중요한 점은 LLM이 직접 서버에 접속하는 것이 아니라는 점입니다.
LLM은 “이 도구를 이런 인자로 호출하라”고 요청하고, 실제 API 호출이나 코드 실행은 Agent를 감싸고 있는 애플리케이션이 수행합니다. OpenAI의 Tool Calling 흐름도 모델이 Tool Call을 생성하고, 애플리케이션이 코드를 실행한 뒤, 결과를 다시 모델에 전달하는 구조로 설명합니다.

 

5. 결과 해석

Tool 실행 결과는 보통 JSON이나 텍스트 형태로 돌아옵니다.

예를 들어 Pod 조회 결과가 다음과 같다고 가정합니다.

{
  "pod": "payment-api-7d9f",
  "status": "CrashLoopBackOff",
  "restartCount": 12
}

Agent는 이 결과를 해석해서 다음 단계로 넘어갑니다.

Pod가 반복 재시작 중이다.
로그를 확인해야 한다.

 

6. 최종 응답 생성

마지막으로 Agent는 수행한 작업 결과를 정리해서 사용자에게 전달합니다.

payment-api Pod가 CrashLoopBackOff 상태입니다.
최근 10분 동안 12회 재시작되었습니다.
로그상 DB 연결 실패가 원인으로 보입니다.
DB endpoint와 Secret 설정을 확인하는 것이 좋습니다.

이처럼 AI Agent는 “답변”이 아니라 “작업 결과”를 제공합니다.

 

---

 

AI Agent와 Tool Calling의 관계

tool calling

AI Agent를 이해하려면 Tool Calling을 반드시 알아야 합니다.

Tool Calling은 LLM이 외부 기능을 호출할 수 있도록 하는 방식입니다.

예를 들어 다음과 같은 Tool이 있다고 가정합니다.

def get_pod_status(namespace: str):
    ...

사용자가 “default namespace의 Pod 상태를 알려줘”라고 요청하면, 모델은 직접 답하지 않고 다음과 같이 판단할 수 있습니다.

get_pod_status(namespace="default")를 호출해야 한다

그 다음 애플리케이션이 실제 함수를 실행하고, 결과를 다시 LLM에게 전달합니다.

이 구조가 반복되면 Agent가 됩니다.

요청 → Tool 선택 → 실행 → 결과 확인 → 다음 Tool 선택 → 최종 답변

 

---

AI Agent의 핵심 구성 요소

AI Agent는 보통 다음 구성 요소를 가집니다.

ai agent 구성 요소

1. LLM

Agent의 판단 중심입니다.
사용자의 요청을 이해하고, 어떤 작업을 해야 할지 결정합니다.

 

2. Tool

외부 시스템과 연결되는 실행 기능입니다.

예를 들면 다음과 같습니다.

검색 API
데이터베이스 조회
Kubernetes API
AWS API
파일 읽기
Slack 메시지 전송

 

3. Memory

이전 대화나 작업 이력을 저장하는 요소입니다.

Memory가 있으면 Agent는 이전 상황을 참고해서 더 자연스럽게 작업할 수 있습니다.

예를 들어 사용자가 “아까 그 서비스 다시 확인해줘”라고 했을 때, Memory가 있으면 “아까 그 서비스”가 무엇인지 알 수 있습니다.

 

4. Planner

목표를 달성하기 위한 작업 단계를 나누는 역할입니다.

복잡한 작업일수록 Planner가 중요합니다.

 

5. Executor

실제 Tool을 실행하고 결과를 받아오는 역할입니다.

---

AI Agent가 어려운 이유

AI Agent는 좋아 보이지만 구현이 쉽지는 않습니다.

 

가장 큰 이유는 다음과 같습니다.

1. 잘못된 Tool을 선택할 수 있음

Agent가 상황을 잘못 이해하면 엉뚱한 API를 호출할 수 있습니다.

2. 결과 해석을 틀릴 수 있음

Tool 결과는 맞는데, Agent가 그 의미를 잘못 해석할 수 있습니다.

3. 보안 문제가 생길 수 있음

Agent가 외부 시스템에 접근할 수 있다는 것은 강력하지만 위험합니다.

예를 들어 Agent가 AWS API를 호출할 수 있다면 권한 제어가 매우 중요합니다.

4. 무한 루프 가능성

Agent가 작업을 끝내지 못하고 계속 Tool을 호출할 수 있습니다.

그래서 실제 구현에서는 다음과 같은 제한이 필요합니다.

최대 반복 횟수
허용 Tool 목록
권한 제한
승인 단계
로그 기록

 

---

 

AI Agent를 안전하게 운영하려면

AI Agent는 반드시 안전장치가 필요합니다.

1. 최소 권한 원칙

Agent에게 모든 권한을 주면 안 됩니다.

예를 들어 EKS 상태 조회 Agent라면 조회 권한만 주는 것이 좋습니다.

읽기 전용 권한
특정 namespace 제한
특정 API만 허용

 

2. 실행 전 승인

위험한 작업은 바로 실행하지 않고 사용자 승인을 받아야 합니다.

예를 들어 다음 작업은 승인 단계를 두는 것이 좋습니다.

Pod 삭제
배포 롤백
보안그룹 변경
IAM 권한 수정

 

3. 감사 로그

Agent가 어떤 Tool을 호출했고, 어떤 결과를 받았는지 기록해야 합니다.

운영 환경에서는 Agent도 하나의 사용자처럼 추적되어야 합니다.

4. 실패 처리

Tool 호출이 실패했을 때 어떻게 처리할지도 중요합니다.

재시도
대체 Tool 사용
사용자에게 실패 원인 전달

 

 

---

 

AI Agent와 기존 자동화 도구의 차이

ai agent vs 기존 자동화 도구

n8n, Airflow, Jenkins 같은 도구는 정해진 흐름을 실행하는 자동화 도구입니다.

AI Agent는 고정된 흐름이 아니라 상황에 따라 다음 행동을 선택합니다.

정확히 말하면 n8n은 AI Agent가 아니라, AI Agent를 실행하거나 연결할 수 있는 워크플로우 자동화 도구에 가깝습니다.

 

대표적인 AI Agent 프레임워크

LangChain

LLM 애플리케이션과 Agent를 만들기 위한 대표적인 프레임워크입니다. LangChain 문서에서는 Agent가 언어 모델과 Tool을 결합해, 작업을 추론하고 Tool을 선택하며 반복적으로 해결해나가는 시스템이라고 설명합니다.

LangGraph

복잡한 Agent 흐름을 상태 기반 그래프로 구성할 때 사용합니다.
단순한 질의응답보다 여러 단계의 작업 흐름이 있을 때 유용합니다.

AutoGen

멀티 Agent 구조를 만들 때 많이 언급되는 프레임워크입니다.

CrewAI

역할 기반 Agent 협업 구조를 만들 때 자주 사용됩니다.

 

---

 

AI Agent와 MCP의 관계

AI Agent가 외부 Tool을 사용하려면 Tool 연결 방식이 필요합니다.

기존에는 각 서비스마다 API 연결 방식을 따로 구현해야 했습니다.

Agent → AWS API 직접 연결
Agent → DB API 직접 연결
Agent → GitHub API 직접 연결

이 방식은 복잡합니다.

그래서 등장한 개념이 MCP입니다.

MCP는 Model Context Protocol의 약자로, AI 애플리케이션과 외부 도구를 연결하기 위한 표준 인터페이스에 가깝습니다.

다음 글에서 MCP를 자세히 다루면 좋습니다.

 

 

---

정리

AI Agent는 LLM을 기반으로 하지만, 단순한 챗봇과는 다릅니다.

LLM이 답변을 생성하는 역할이라면, AI Agent는 목표를 달성하기 위해 판단하고, 도구를 선택하고, 실행 결과를 해석하는 시스템입니다.

핵심은 다음과 같습니다.

LLM = 답변 생성
Tool = 외부 기능 실행
Agent = LLM + Tool + 계획 + 실행

 

 

※ 해당글의 이미지는 이해를 돕기 위해 제작된 예시 다이어그램입니다.