AI 에이전트란?

---

개요

 

이 글은 AI 에이전트에서 사용되는 기본적인 용어들을 간단하게 정리하는 글입니다. 이미 에이전트를 개발하고 있거나 익숙한 사람보다는, AI 에이전트가 무엇인지 잘 모르고 관련 용어의 의미를 알고 싶은 사람에게 추천합니다.

 

---

에이전트의 정의

출처: https://builder.aws.com/content/30PvUImLL3LehFlOZpZ5SU6Bavn/agentic-ai-series-part-1-what-are-ai-agents-and-why-do-they-matter

 

에이전트라는 용어는 사용하는 사람과 맥락에 따라 의미가 조금씩 달라 혼란스럽다. 특히 AI 기능이 있다 하면 에이전트라는 단어를 갖다 붙이는 경우도 많이 보았다. 그래서 글을 시작하기 앞서 에이전트란 무엇인지 개념을 분명히 정리하고 넘어가겠다.

 

자율 에이전트는 데이터를 스스로 해석하고, 주변 환경을 이해하며, 그 상황(컨텍스트)에 맞는 결정을 내리도록 설계된 시스템이다. 단순히 주어진 규칙을 그대로 실행하는 것이 아니라, 현재 맥락을 바탕으로 스스로 판단하고 행동을 선택해야 한다. 따라서 결과가 이미 정해져 있는 스크립트나 강하게 제한된 워크플로는 자율 에이전트라고 부르기 어렵다.

 

워크플로 vs 에이전트

	코드	워크플로	자율 에이전트
입력 구조	완전히 예측 가능	단계별로 나눌 수 있고 대부분 예측 가능	매우 다양하고 예측 어려움
설명 가능성	완전히 투명	단계별 추적 가능	일부는 내부 동작이 보이지 않음
지연	매우 낮음	중간 수준	상대적으로 높음
적응, 학습	없음	제한적	높음 (피드백 기반 개선 가능)

 

여기서 워크플로와 자율 에이전트가 헷갈리는 이유는, 워크플로도 특정 단계에서 LLM을 호출할 수 있기 때문이다. 하지만 사용자가 지정한 단계에 따라 진행되는 과정 중 하나였을뿐, 스스로 의사결정하여 LLM을 호출하도록 만든 게 아니므로 LLM 호출 == 자율 에이전트라고 보기는 힘들다.

• 워크플로: 사람이 정의한 순서에 따라 실행됨
• 에이전트: 상황을 보고 스스로 다음 행동을 결정함

 

---

에이전틱 시스템

 

에이전트는 단독으로 동작하기보다 여러 구성 요소가 함께 동작하는 시스템으로 이해하는 것이 좋다. 에이전트가 효과적으로 동작하기 위해서는 다양한 구성 요소가 존재한다. 도구, 메모리, 오케스트레이션 등등. 이 전체 구조를 에이전틱 시스템(Agentic System)이라고 한다.

 

참고로 아래 구성 요소들은 모두 같은 레벨의 개념이 아니다. 임의로 분류해보자면 아래와 같다. 공식적인 분류가 아니고 구현에 따라 다르게 분류될 수 있는 부분도 존재하니, 참고만 하자.

에이전틱 시스템
├── 🔴 개발 기반
│   └── 에이전틱 프레임워크
├── 🟠 실행 제어
│   └── 오케스트레이션 (에이전트의 실행 흐름을 관리하는 제어 계층)
├── 🟡 에이전트의 내부 구성요소
│   ├── 메모리
│   └── 컨텍스트 엔지니어링
├── 🟢 외부 자원
│   ├── 지식 베이스 (Knowledge Base)
│   └── 도구 (Tool)
└── 🔵 도구 연결 방식
    ├── 플러그인
    └── MCP

 

 

🔴 에이전틱 프레임워크

• 자율 에이전트 개발을 위한 프레임워크
• ex: LangGraph, Autogen, CrewAI, OpenAI Agents SDK 등
• 각 프레임워크에는 고유의 장단점이 있어 목적에 따라 선택

 

 

🟠 오케스트레이션; Orchestration

• 에이전트가 어떤 작업을 어떤 순서로 수행할지 결정하고, 전체 실행 흐름을 관리하는 제어 로직
• 어떤 도구를 언제 호출할지 결정
• 각 모델 호출에 적합한 컨텍스트를 구성해 효과적이고 근거 있는 행동 유도

❓ 오케스트레이션은 에이전트의 일부 구성요소인가요?
- 에이전트: 의사결정 주체
- 오케스트레이션: 그 의사결정이 실행되도록 흐름을 구성하고 관리하는 메커니즘
즉, 오케스트레이션은 "무엇을 할지"가 아니라 "어떻게 실행할지"를 담당

 

도구 실행 방식

• 단일 실행
• 병렬 실행
• 체인 실행
• 그래프 기반 실행

그래프 기반 실행은 조건에 따라 실행 경로가 달라지는 구조이다. 노드는 도구 실행, 엣지는 다음 단계로 이동하는 조건을 의미한다. 이 방식은 유연하지만, 그래프가 복잡해질수록 유지보수가 어렵고, 새로운 도구를 추가하기 까다롭다.

 

 

🟡 메모리; Memory

• 에이전트가 정보를 저장하고 다시 활용할 수 있게 함
• 단기 메모리; short-term memory
  • 현재 작업과 관련된 정보 저장
  • 컨텍스트 유지
  • 보통 FIFO 방식인 롤링 컨텍스트 윈도(rolling context window) 방식으로 구현되기도 함
• 장기 메모리; long-term memory
  • 장기간 유지되는 지식 저장
  • DB, 지식그래프, 파인튜닝된 모델 등을 통해 구현

 

 

🟡 컨텍스트 엔지니어링; Context Engineering

• LLM에 전달되는 입력을 어떻게 구성할지 설계하는 작업
• 작업 성능을 최대화하기 위해, 구조적이고 토큰 효율적인 컨텍스트 윈도*를 구성하는 작업
• 아래와 같은 작업 포함
  • 어떤 정보를 포함할지
  • 어떤 순서로 배치할지
  • 불필요한 정보를 어떻게 제거할지
  • 제한된 토큰 내에 어떻게 효율적으로 구성할지

* 컨텍스트 윈도; Context Window
: 한 번의 호출에서 LLM에 입력으로 전달되는 정보

 

 

🟢 지식 베이스; knowledge base

• 에이전트가 참고할 수 있는 정보 저장소
• 에이전트는 이 정보를 검색해서 답변이나 의사결정에 활용
• ex: Notion이나 Wiki 등 문서, Database, Vector DB 등

 

 

🟢 도구; tool

• 에이전트가 실제로 작업을 수행하기 위해 사용하는 기능
• 단순한 답변 생성을 넘어, 외부와 상호작용하거나 실제 행동을 하기 위해 필요
• ex
  • 로컬 도구: 로컬 환경에서 계산이나 파일 처리 등의 로직 직접 수행
  • API 기반 도구: 외부 서비스에서 제공하는 API 호출

 

 

🔵 플러그인; Plugin

• 도구를 특정 프레임워크에서 쉽게 사용할 수 있도록 정리한 형태
• 정해진 형식에 맞춰 도구를 정의하면, 별도 구현 없이 바로 연결해서 사용 가능

 

🔵 MCP(Model Context Protocol)

• LLM과 외부 시스템을 연결하기 위한 표준 인터페이스
• 특정 모델에 종속되지 않음
• 다양한 도구를 재사용 가능하게 함
• 도구 사용 방식 자체를 표준화 -> 여러 에이전트가 동일한 방식으로 도구를 사용할 수 있음
• 아직 보안 표준이 완전히 정립되지 않아, 실제 서비스에서는 별도 검토 필요

❓ 도구 vs 플러그인 vs MCP
- 도구: 에이전트가 호출해서 작업을 수행하는 실제 기능
- 플러그인: 특정 프레임워크에서 도구를 쉽게 등록하고 사용할 수 있도록 만든 연결 방식
- MCP: 어느 프레임워크에서든 무관하게 도구를 동일한 방식으로 연결하고 사용할 수 있도록 정의한 표준 프로토콜

 

 

---

마치며

 

AI 에이전트는 새로운 개념처럼 보이지만, 본질을 살펴보면 기존의 API 서버와 크게 다르지 않다고 생각했다.

• 상황에 따라 속도와 정확성에 대한 트레이드오프 고민
• 최대한 심플하게 운영하다가 정말 필요한 순간에 다중화 고려
• 제공해야 하는 서비스에 비해 너무 높은 비용의 스펙을 사용하지는 않는지 체크
• 한 번에 많은 기능을 넣기보다는 단계적으로 확장

등등 서버를 유지보수하는 서버 개발자라면 누구나 인지하고 있는 부분이라고 생각한다.

 

조금 다른 점은 정말 철저한 테스트가 필요하다고 생각하는 점이다. API 서버도 물론 테스트가 필요하지만, 어쨌든 코드 베이스니 어느 정도 예측 가능하다. 하지만 에이전트는 스스로 판단하고 계획을 세우니, 입력값이 조금만 달라져도 전혀 다른 행동을 보일 수 있다.

 

인터넷에 자주 돌아다니는 AI 공포 썰도 위험모드나 자동모드로 수행했더니 내 파일을 이상한 사이트에 업로드하거나 중요한 파일을 삭제해 버리는 등이 많지 않은가? 특히나 개인정보를 다룰 가능성이 있는 에이전트라면, 혹은 개인정보를 다룰 의도는 없었는데 사용자가 개인정보를 입력해 버린다면?

 

입력에 대한 통제가 어렵기 때문에, 더 철저한 테스트 전략이 필요해 보인다. 이 부분에 대해서는 가드레일, 테스트 자동화 이런 키워드를 통해서 더 자세히 알아볼 수 있을 것 같다.

 

---

참고

• AI 에이전트 엔지니어링 책