서론 - 들어가기 앞서...
아이러니하게도 사람은 자기가 대체될 수 있다는 불안을 은연중에 느끼면서도, 끊임없이 자동화를 꿈꾼다.
과연 AI 에이전트가 AI 기술의 종착역이 될 것인가라는 의문을 품으면서도, 이 생태계에서 살아남으려면 확실히 알고 넘어가야겠다는 생각이 든다.
AI 에이전트를 단순히 유행하는 기술로 바라볼 것이 아니라, 그 원리와 구조를 제대로 이해해야 하는 것이다.
자 그렇다면 단순히 '에이전트를 흉내 내봤다'가 아니라, '제대로 된 시스템을 구축해 봤다'고 자신 있게 말하려면 어떻게 공부해야 할까?
이 전 스터디 주제인 RAG는 오히려 심플했다.
이번 주제는 생각보다 훨씬 더 어렵게 다가왔다.
성희가 내가 너무 겁을 먹은 것 같다고 했는데, 맞는 말이다.
겁난다. 제대로 알지도 못하면서 아는 척하는 것? 나는 그게 질색이다. 그게 나 자신이라면 더더욱.
그래서 AI들에게 직접 물어봤다. 하나씩, 전부.
그리고 난감했다.
출발점이 되어야 할 개념들이 오히려 나를 더 혼란스럽게 했으므로.
본론 - AI Agent의 본질: '표준적 정의'는 어디서 왔을까?
ChatGPT에 따르면
AI Agent는 생각보다 "공식적으로 딱 한 줄로 불변의 정의가 있는 개념"은 "아니다"라고 말한다.
왜냐하면 AI Agent는 학문(인공지능), 산업(OpenAI, Anthropic 등), 연구자마다 조금씩 다르게 정의하기 때문.
하지만 여러 정의의 출발점이 되는 가장 권위 있는 정의는 존재한다.
실제로 ChatGPT, Gemini, Claude 등 여러 AI에게 동일한 질문을 했을 때 공통적으로 언급한 정의는 다음과 같았다.
가장 권위있고 원론적인 정의는
에이전트란 센서(Sensors)를 통해 환경(Environment)을 인식(Perceive)하고, 액추에이터(Actuators)를 통해 그 환경에 행동(Act)하는 모든 것.
이어서 Gemini의 말에 따르면
AI Agent(인공지능 에이전트)에 대한 정의를 찾을 때, "처음 정의되었고 지금까지 변하지 않는 딱 표준적인 정의"를 원한다면 학계와 컴퓨터 과학에서 바이블로 통하는, 바로 저 정의가 저술되어 있는, 한 권의 교과서로 가야한다고 했다.
바로 스튜어트 러셀(Stuart Russell)과 피터 노빅(Peter Norvig)이 저술한 <<인공지능 : 현대적 접근방식 (Artificial Intelligence : A Modern Approach, AIMA) 이다.
자 이제 그 내용을 상세하게 들여다 보자.
1. 가장 확실하고 원론적인 정의
An agent is anything that perceives its environment through sensors and acts upon that environment through actuators.
이 정의는 수십 년간 변하지 않았으며, 최근 유행하는 LLM(대형 언어 모델) 기반의 고도화된 AI 에이전트 역시 이 구조를 그대로 따른다고 한다.
여기에 덧붙여서 Claude는 Rational Agent(합리적 에이전트)에 대해 언급하였는데
A rational agent is one that does the right thing.
이는 더 정확하게는
주어진 percept sequence(인식 이력)를 바탕으로 기대 성능을 최대화하는 행동을 선택하는 agent라고 했다.
왜 이게 "불변의 원조"냐면
Russell & Norvig의 Artificial Intelligence : A Modern Approach(1995)는 AI 연구 분야를 "합리적 에이전트의 연구와 설계"로 정의헸고, 이후 나온 모든 AI agent 정의(AWS, Google, IBM, LLM 기반 agent 등)는 전부 이 틀 위해서 확장된 것이고,
AI 교과서들은 인공지능을 "지능형 에이전트의 연구와 설계"로 정의하며, 목표 지향적 행동이 지능의 핵심임을 강조하기 때문이다.
즉, AIMA 정의 기준으로 보면
Russell & Norvig의 정의에서 agent 핵심은 단순히 도구를 쓰는 게 아니라
| 조건 | 설명 |
| Perceive | 환경을 인식 |
| Act | 환경에 행동 |
| Rational | 성능을 최대화하는 방향으로 스스로 판단 |
위 표와 같은 조건을 만족해야 하는 것이다.
그저 API 도구 호출만 하면
[사람이 시킴] → [LLM이 API 호출] → [결과 반환] → 끝
이건 그냥 함수 실행기(function caller)이기 때문이다.
1.1. 수식으로 보는 에이전트(불변의 개념)
수학적으로 에이전트는 에이전트 함수(Agent Function)로 표현된다.
에이전트의 본질은 내부 구조가 무엇이든 간에, 결국 '입력(인식)을 받아서 행동으로 연결하는 매핑(수학적 함수(f)'이라는 뜻이다.
■ P* : 에이전트가 지금까지 센서를 통해 받아들인 모든 인식들의 누적 이력(=시퀀스(Percept Sequence))
■ A : 에이전트가 취할 수 있는 최선의 행동(Action)
즉, "지금까지 보고 듣고 경험한 것을 바탕으로, 현재 어떤 최선의 행동을 할지 결정하는 주체"가 바로 에이전트인 것이다.
1.2. 구조적 구성 요소
가장 정석적인 AI 에이전트는 항상 다음 3가지 요소의 상호작용으로 정의된다.
■ 환경(Environment) : 에이전트가 처한 세계(웹페이지, 게임 화면, 팩토리 라인 등)
■ 센서(Sensors) : 환경으로부터 데이터를 받아들이는 통로(카메라, 마이크, API 데이터 입력, 텍스트 프롬프트 등)
■ 액추에이터(Actuators) : 환경에 물리적/디지털적 변화를 주는 도구(로봇 팔, 스피커, 키보드 입력, API 호출을 통한 툴 실행 등)
1.3. 왜 지금 이 정의가 다시 중요할까?
최근 챗GPT나 LLM 기반의 AI를 넘어 'AI Agent'가 대세가 된 이유도 이 고전적 정의와 맞닿아 있다.
단순히 질문에 답만 하는 챗봇은 '인식(Perceive)'하고 '답변(Text Generation)'하는 데서 끝나지만, 현재의 AI 에이전트는 스스로 브라우저를 켜고, 코드를 실행하고, API를 호출하여 외부 환경에 행동(Act)'을 취하기 때문이다.
기술은 발전했어도 30년전 러셀과 노빅이 정의한 프레임워크안에 그대로 머물러 있는 셈이다.
학술적, 기술적 논문이나 공식적인 자리에서 '가장 확실한 근거'를 두고 에이전트를 정의해야 한다면, "러셀과 노빅의 AIMA(Artificial Intelligence: A Modern Approach)에 따른 개념"이라고 명시하시면 된다.
2. 그럼 API로 도구만 호출하면 agent라고 할수 있나?
결론부터 말하면 '아니다...'
단순히 API로 도구를 호출하는 '기능'이 있다는 것만으로는 진정한 의미의 AI 에이전트라 부르기 어렵다.
그 차이는 "개발자가 짜놓은 하드코딩된 규칙대로 움직이느냐(단순 자동화 프로그램)", 아니면 "AI가 스스로 판단해서 도구를 쓸지 말지, 쓴다면 어떻게 쓸지 결정하느냐(에이전트)"의 차이에서 온다고 한다...
더불어 제미나이는
러셀과 노빅의 고전적 정의와 현대 LLM 기반 에이전트의 관점을 융합해서 분석해보면, 왜 단순 API 호출만으로 에이전트가 될수 없는지 명확하게 알 수 있다고 한다.
2.1. 결정적 차이 : 자율성(Autonomy)과 루프(Loop)
단순히 API를 호출하는 프로그램과 AI 에이전트는 구조적으로 다르다.
❌ 단순 API 호출 프로그램(If-Else 기반 자동화)
사용자가 "내일 서울 날씨 어때"라고 물었을 때, 프로그램이 if(question.contains("날씨")) 같은 규칙에 의해 날씨 API를 호출하고 결과를 보여준다면 이것은 단순 자동화 툴이다.
■ 결정의 주체가 AI가 아니라 개발자가 고정해 둔 소스코드이기 때문이다.
⭕진정한 AI 에이전트(인식 - 판단 - 행동의 루프)
동일한 질문을 했을 때, AI가 스스로 질문의 맥락을 '인식'하고 자신의 지식만으로는 부족하다는 것을 '판단'한 뒤, "내가 가진 도구 목록 중에 get_weather_api를 쓰는게 최선이겠군 하고 판단하여 주도적으로 aPI를 선택하고 실행하는 구조여야 한다,
더 중요한 것은 행동 이후의 피드백이다. 만약 APi를 호출했는데 에러가 나거나 원하는 데이터가 안 오면, 에이전트는 그 실패를 다시 인식하여 아 날씨 api 안되네? 그럼 웹 검색 도구를 대신 써야겠다.라고 스스로 다음 행동을 수정할 수 있어야 한다.
다음은 챗GPT가 준 예시이다.
@app.get("/weather")
def get_weather():
weather = weather_api()
return weather
이건 그냥 API 호출이다.
[사용자] → [프로그램] → [날씨 API] → [결과반환]
여기에는 목표 설정, 계획, 판단, 재시도가 없다.
그래서 보통 Agent라고 부르지 않는다.
실제로 최근 AI 업계에서는
Level 0 : LLM
질문 → 답변
LLM(ChatGPT 기본)
Level1 : Tool Calling
질문 → LLM → 도구 호출 → 답변
Tool Calling(많은 사람들이 여기서 Agetn라고 부르지만 사실 애매함)
Level2 : Agent
목표 → LLM → 계획 → 도구선택 → 실행 결과 검증 → 재실행 → 완료
Level3 : 멀티에이전트
목표 → 장기 메모리 → 계획 → 여러 Agent 협업 → 작업 완료
한 문장으로 정리하면,
"API를 호출해서 답을 주는 것은 Tool Calling이고, AI가 목표 달성을 위해 어떤 도구를 사용할지 스스로 결정하면 Agent다."
도구 호출은 agent의 수단이지, agent의 정의가 아니다.
요즘 agent라는 말이 남발되는 이유가 바로 이 구분을 흐리게 하기 때문이다.
2.3.그렇다면 Agent의 철학적 정의와 현대 AI 에이전트의 핵심 4 요소는 무엇인가?
여기서 나는 AI 질문들에서 흥미로운 점을 발견했다.
먼저 GPT부터 살펴보겠다.
GPT는 AIMA 정의로 역으로 따지면, 이게 없으면 agent가 아닌 것들을 다음과 같이 정의하였다.
1. Autonomy(자율성)
사람이 매 단계마다 지시해야 움직인다면 agent 아님 그냥 도구
근거 : AIMA에서 agent는 percept sequence를 바탕으로 스스로 action을 선택함. 외부 지시가 매번 필요하면 agent function이 agent 안에 있는 게 아니라 사람 안에 있는 것.
Gemini에 따르면
최근 AI 학계(예 OpenAI, ReAct 프레임워크 등)에서 정의하는 '도구를 사용하는 AI 에이전트'는 단순히 API를 실행하는 수준을 넘어 다음과 같은 유기적 구조를 가진다고 했다.
■ Core(두뇌) : 거대 언어 모델(LLM). 맥락을 이해하고 계획을 세우는 핵심 주체이다.
■ Memory(기억) : 이전 대화 내용이나 API 호출 결과를 기억하고 다음 행동에 반영하는 공간이다.
■ Tools(도구 - API) : 계산기, 웹 검색, DB 조회, 외부 서비스 연동 등 에이전트가 쓸수 있는 무기들이다.
■ Planning(기획/판단) : 목표를 달성하기 위해 문제를 잘게 쪼개고 어떤 도구를, 어떤 순서로, 어떤 인자(Parameter)를 넣어서 호출할지 스스로 설계하는 능력이다.
비유하자면
■ 단순 API 호출 : 장비를 쥐어주면 로봇 공장의 기계 팔처럼 정해진 궤적으로만 움직이는 상태.
■ AI 에이전트 : 장비(API)를 쥐어줬더니, 공사 현장 상황을 보고 "지금은 망치가 아니라 드라이버를 써야겠네"라고 스스로 판단해서 작업하는 목수 상태.
둘이 다르게 말해서 물어봤다
ChatGPT는 '철학적 기능적 정의' 즉, 에이전트의 조건을 말했고
Gemini는 '기술적 구조적 아키텍처를 말했다. (에이전트의 부품)를 말했다.
3. 그럼 이 개념에 부합하는 코드가 git에 있나?
그렇다.
Gemini에 따르면 깃허브(GitHub)에는 정확히 이 개념에 부합하는 코드들이 아주 많단다.
앞서 말한 "인식(Perceive), 판단(Reasoning), 행동(Action), 관찰(Observation)"의 루프를 외부 프레임워크(LangChain 등) 없이, 파이썬 기본 코드로만 구현한 'From Scratch(바닥부터 구현하기)' 스타일의 코드들이 그 본질을 가장 잘 보여준다.
그중에서 기술적으로 가장 유명하고 직관적인 오픈소스 패턴인 ReAct(Reason + Act) 에이전트의 핵심 루프 코드 구조를 아래에 붙여놓았다.
깃허브에서 llm-agent-from-scratch 같은 저장소들을 보면 아래와 같은 방식으로 구현됨을 볼 수 있다.
💡 깃허브에서 찾는 에이전트의 핵심 '루프' 코드(Python)
에이전트가 완벽하게 자율적인 '루프'를 돌며 스스로 도구를 선택하고 결과를 판단하는 프롬프트 기반의 핵심 로직이라 한다.
보라, 아래 2번에서도 설명하겠지만 당신은 알 수 있을것이다.
소스코드 어디에도 특정 API를 호출하는 하드코딩(If-Else)은 없다.
LLM이 판단한 결과가 다시 루프를 타고 Observation으로 들어가는 이 구조가 바로 에이전트의 실체다.
import re
class Agent:
def __init__(self, llm, tools):
self.llm = llm
self.tools = {t.name: t for t in tools}
self.system_prompt = """
너는 주도적으로 문제를 해결하는 AI 에이전트다.
질문이 들어오면 다음 단계를 엄격히 반복하며 답을 찾아내라:
1. Thought: 문제를 해결하기 위해 지금 무엇을 해야 하는지 생각하라.
2. Action: 사용할 도구 이름과 인자를 'Action: 도구이름(인자)' 형식으로 출력하라.
3. Observation: 도구가 실행된 결과(외부 환경)를 보고 다시 판단하라.
사용 가능한 도구 목록:
{tool_descriptions}
최종 답을 얻었다면 'Final Answer: [답변]' 형식으로 끝내라.
"""
def run(self, user_query):
# 1. 인식(Perceive): 처음 유저의 질문과 환경을 메모리에 기록
context = self.system_prompt + f"\nUser Question: {user_query}"
# 에이전트 불변의 Loop (최대 10번 자율 반복)
for i in range(10):
# 2. 판단(Reasoning): LLM이 현재 맥락을 보고 'Thought'와 'Action'을 스스로 결정
response = self.llm.generate(context)
context += f"\n{response}"
print(f"\n--- [Step {i+1}] AI의 생각과 판단 ---\n{response}")
if "Final Answer:" in response:
return response.split("Final Answer:")[-1].strip()
# 3. 행동(Action) 추출: "Action: 계산기(3+5)" 같은 문구가 있는지 파싱
action_match = re.search(r"Action:\s*(\w+)\((.*)\)", response)
if action_match:
tool_name, tool_input = action_match.groups()
# 스스로 선택한 도구를 가져와서 실행 (API 혹은 내부 함수 호출)
if tool_name in self.tools:
print(f"👉 [행동] AI가 스스로 '{tool_name}' 도구를 호출합니다. 인자: {tool_input}")
observation = self.tools[tool_name].execute(tool_input)
else:
observation = f"에러: '{tool_name}'이라는 도구는 없습니다."
# 4. 관찰(Observation): 외부 환경에서 얻은 피드백을 다시 컨텍스트에 주입
print(f"🔍 [관찰 결과] 도구가 리턴한 데이터: {observation}")
context += f"\nObservation: {observation}"
else:
# 만약 도구 호출 포맷을 안 지켰다면 스스로 교정하도록 유도
context += f"\nObservation: 올바른 Action 포맷을 사용하세요."
💡 이 코드가 앞선 정의와 일치하는 이유
1. while/for 루프 구조 : if-else로 한 번 실행하고 끝나는 게 아니라, 목적을 달성(Final Answer)할 때까지 AI가 스스로 판단하며 루프를 유지한다.
2. 자율적 도구 선택(action_match 부분) : 소스코드 레벨에서 특정 API를 호출하라고 지정하지 않았다.
LLM이 텍스트로 "Action: 내일_날씨_API(서울)"이라고 출력하면, 코드는 그걸 파싱해서 동적으로 호출해 줄 쁀이다. 어떤 무기를 쓸지는 AI가 100% 자율적으로 결정한다.
3. 피드백 수용(context += f"\nObservation: {observation}"): 도구를 실행해 나온 원본 데이터(Observation)를 AI 기억(Context)에 다시 넣어준다. AI는 다음 턴에 이 결과를 보고 "아, 데이터가 이렇게 왔으니 다음엔 이 행동을 해야겠구나"하고 생각을 업데이트 한다.
📚 깃허브에서 찾는 에이전트의 핵심 '루프' 코드(Python)
이러한 정석적인 에이전트 구조가 어떻게 구현되는지 오픈소스로 직접 보고싶다면, GitHub 검색창에 아래 키워드들을 검색해 보면 좋은 레퍼런스 코드를 찾을 수 있다고 했다. 확인해보지 못해서 거짓말 했을 수 있으니 안나와도 너무 화내지 않길 바란다.
■ llm-agent-from-scratch(외부 라이브러리 없이 바닥부터 구현한 에이전트)
■ langchain-ai/react-agent(LangChain 팀에서 공식 제공하는 ReAct 템플릿 코드)
■ pguso/ai-agents-from-scratch(최근 깃허브에서 에이전트 도구 호출 및 ReAct 패턴을 가볍게 학습하기 좋은 저장소)
4. 그렇다면 반대로 "이게 빠지면 A 에이전트가 아니다" 하는 요소와 그 근거는 무엇일까?
Gemini :
이 글을 읽다보면 같은 내용이 반복되기 때문에 정말 지루할 것이다.
하지만 필요하다 크로스체크 그래서 지겹게 반복한다.
위 질문에 Gemini는 이 질문에 다음과 같이 답했다.
AI 에이전트의 정의에서 '이것이 빠지면 절대로 AI 에이전트라고 부를 수 없다'고 할 수 있는 가장 결정적인 요소는 바로 자율적인 피드백 루프(Autonomous Feedback Loop)입니다.
조금 더 직관적으로 표현하자면 '관찰(Observation)을 통한 자율적 판단'으로, 이 요소가 빠진 시스템은 아무리 인공지능(LLM)을 쓰고 API를 호출하더라도 에이젠트가 아니라, 단순한 '파이프라인 프로그램'이나 '고급 챗봇'에 불과하다고 했다.
이어서 그 명확한 판단 기준과 학술적/현대적 근거는 다음과 같다고 말해주었다.
❌ 4.1.이것이 빠지면 에이전트가 아니다 : '자율적 피드백 루프'
시스템이 단선적으로 작동하는가, 아니면 순환하며 스스로 궤도를 수정하는가가 핵심이다.
4.1.1. 결과(Observation)를 보고 다음 행동을 스스로 결정하는 단계가 없다면?
사용자가 입력한 값을 받아 LLM이 "API A를 호출해줘"라고 해서 코드가 API A를 호출하고 그대로 실행을 끝마친다면, 그 사이에 루프(Loop)는 없다.
진정한 에이전트는 API A를 실행한 결과물(환경의 변화)을 다시 확인(인식)하고 그에 따라 "다음엔 B를 해야겠군" 혹은 "실패했으니 다시 해야겠군"을 스스로 판단해야 한다(그럼 실패의 기준은 어떻게 정하지?개발자가? AI가? 목표에 기준을 둬야하는걸 말하나?). 이 순환 구조가 빠지면 에이전트 자격 상실이다.
* 내 글에서 잘못 정리된 부분을 찾으라 하니 실패의 기준은 이미 본문에 나왔다고 클로드가 짚어줬다.
상위 목표(실패 기준 포함) 개발자가 정함
하위 목표 LLM이 판단
4.1.2. 실행 흐름 제어권(Control Flow)이 소스코드에 있다면?
"1단계로 번역하고, 2단계로 날씨 API를 호출하고, 3단계로 이메일 발송해"처럼 개발자가 소스코드로 순서를 딱 고정해 두었다면, 중간에 LLM이 들어가서 멋진 텍스트를 생성해 내더라도 에이전트가 아니다. 그것은 그냥 'AI 기능이 포함된 워크플로우 자동화 프로그램'이다. 실행의 제어권과 계획 수립 권한이 AI에게 통째로 넘어가 있어야 에이전트이다.
📚 그렇게 말할 수 있는 근거는 무엇인가?
가장 공신력 있는 두 가지 진영(고전 교과서와 현대 AI 빅테크)의 정의가 모두 이를 뒷바침한다.
근거1. 고전적 근거(Russell & Norvig의 AIMA)
앞서 언급한 인공지능 교과서에서는 에이전트와 단순 프로그램을 구별하는 기준으로 자율성을 꼽으며 다음과 같이 명시한다.
"시스템의 행동이 자기가 직접 인식한 바에 의존하기보다, 개발자의 사전 지식(Built-in Knowledge)에만 의존한다면 그 시스템은 자율성을 결여한 것이다. 자율적인 에이전트는 환경에 적응하고 스스로 학습하여 자신의 사전 지식을 보완할 수 있어야 한다.
(근데 이거는 인간이 완벽하지 못하다는 전제하에 이렇게 설계한걸까? 이전에 멘토님이 하신 말씀이 떠오른다 자신이 가지고 있는 지식에 갇혀있으면 안된다고)
즉, 개발자가 짜놓은 IF-Else나 정해진 순서대로만 움직이고 외부 환경의 피드백을 받아 스스로 궤도를 수정하지 못한다면, 그것은 교과서 정의상 에이전트가 될 수 없다.
근거2. 현대적 근거(학계의 ReAct 프레임워크 및 OpenAI의 정의)
현재 깃허브와 업계에서 에이전트를 만들 때 표준으로 쓰는 ReAct(Reasoning + Acting) 방법론의 핵심 논문(Yao et al., 2022)을 보면 에이전트의 단계를 이렇게 정의한다.
여기서 가장 중요한 근거는 Observation(관찰)이 다음 Thought(생각)에 영향을 준다는 점이다.
■ 내가 행동을 취했을 때 외부 환경이 어떻게 변했는지(에러가 났는지, 올바른 데이터가 왔는지)를 시스템이 다시 입력값으로 받아들이지 않는다면, ReAct 논문 구조 자체가 성립하지 않는다.
위와 같이 언급하며 마지막으로 Gemini는 이 부분에 대해 다음과 같이 한줄로 요약해주었다.
"결과를 보고 스스로 생각을 고쳐먹는 '피드백 루프'가 없다면, AI 에이전트가 아니라 그냥 똑똑한 자동화 스크립트다."
같은 얘기의 반복이지만 어떻게 말하는지 비교를 위해 정리한 내용이다.
개념에 대해 다르게 표현하는 단어와 그 뉘앙스과 생각의 확장에 많은 도움을 준다고 생각하기 때문에
같은 의미의 문장도 표현의 차이를 비교하는 걸 좋아한다.
Gemini가 위와 같이 말했다면 ChatGPT는 같은 내용이지만 구체적으로 얘기를 했다.
GPT :
4.2. 목표(Goal) 기반의 자율적 행동
만약 시스템이 1) 목표를 받지 않고 2) 스스로 행동을 결정하지 못하면 Agent라고 부르기 어렵다.
예를 들어
[사용자] → [날씨 알려줘] → [날씨 API 호출] → [결과 반환]
이건
목표 달성 과정 없음
행동 선택 없음
판단 없음
그래서 Agent가 아니라 그냥 프로그램이라 했다.
목표 기반의 자율적 행동이라 해서 초반에 헷갈렸는데 뒤에 이렇게 덧붙였다.
가장 최소가 되는 조건은 자율적으로 행동을 결정하는 능력이라 했다.
5. 가장 최소 조건
만약 시험 문제처럼
AI Agent가 되기 위한 필수 요소 하나만 고르시오.
라고 하면 GPT는
자율적으로 행동을 결정하는 능력(Autonomy)
을 고르겠다고 했다.
그 이유로는
■ 목표는 있을 수 있고
(목표가 없을수가 있나? 음.. 달리기 선수는 달린다 이걸 목표라고 보지 않는다는거지? 이번 대회에서 '달려서' '1등을 한다'가 목표)
■ 도구는 없어도 되고
■ 메모리는 없어도 되고
(고전 학문에서는 기억이 없는 '단순 반사 에이전트'도 에이전트에 포함되지만, "현대 LLM 생태계에서 우리가 구축하려는 주도적 에이전트는 '기억(Percept Sequence)'과 '목표(Goal)'가 빠지면 성립할 수 없다.
■ 계획도 단순할 수 있지만
자율성이 없으면
[입력] → [정해진 로직] → [출력]
인 일반 프로그램과 구별이 안되기 때문이다.
그래서 현재 OpenAI, Anthropic, 학계 정의를 최대한 압축하면
AI Agent = 목표를 달성하기 위해 환경을 인식하고 자율적으로 행동을 결정하는 AI 시스템 이고, 자율적 행동 결정이 없다면 Agent라고 부르기 어려우며 이게 가장 강한 기준이라고 했다.
하지만 간과해서는 안되는게 저 능력이 꼭 있어야 한다는걸 강조하는 것이지 목표, 도구, 메모리, 계획이 없어도 된다가 아니다.
이것들은 필수에 속한다는점 잊지 말자.
Claude는 AIMA 정의를 역으로 따져서 이게 없으면 agent가 아닌 것들이라고 표현했다.
필수 요소 3가지(없으면 agent 아님)
1. Autonomy(자율성)
사람이 매 단계마다 지시해야 움직이면 → agent 아님, 그냥 도구(tool)
근거 : AIMA에서 agent는 percept sequence를 바탕으로 스스로 action을 선택한다. 외부 지시가 매번 필요하면 agent function이 agent 안에 있는 게 아니라 사람 안에 있는 것이기 때문이다.
2. Feedback Loop(인식 → 행동 → 재인식 루프)
근거 : AIMA의 정의 자체가 "percept sequence"임. 단발성 입출력이 아니라 시간에 걸친 연속적 인식과 행동이 전제.
3. Goal-directedness(목표 지향성)
목표 없이 입력에 반응만 하면 → agent 아님, 그냥 함수(function)
근거 : Rational agent 정의의 핵심이 "performance measure를 최대화"하는 것. 최대화할 기준(목표)이 없으면 rational의 개념 자체가 성립되지 않으므로(새삼스럽게 목표라는 것이 능력의 최대화를 의미한다는 걸 깨달았다;;)
표로 정리하자면
| 빠지면 | 뭐가 되냐 | 왜 agent 아닌가 |
| Autonomy | 도구(Tool) | 판단 주체가 agent 밖에 있음 |
| Feedback Loop | 스크립트(Script) | percept sequence가 없음 |
| Goal-directedness | 함수(Function) | rational의 기준이 없음 |
현실 적용 시 체크해야 할 사항
"이 시스템이 agent인가?"를 판단할 때
1. 사람 개입 없이 다음 행동을 스스로 결정하는가? → Autonomy
2. 이전 결과를 보고 다음 행동이 달라지는가? → Feedback Loop
3. 달성하려는 목표가 시스템 내부에 있는가? → Goal-directedness
셋 다 YES → Agent
하나라도 No → Agent 아님
이러면서 요즘 "AI Agent"라고 불리는 것들 중 상당수가 이 기준으로 보면 그냥 고급 API 호출기라고 했다.
5. AI 에이전트에는 목표가 없어도 에이전트라고 할수 있어?
Gemini가 목표에 대한 업급이 없어서 다음과 같이 추가 질문을 했다.
결론부터 말하면 이자식이 목표가 없으면 절대로 AI 에이전트가 될 수 없다고 했다.
목표가 빠진 시스템은 에이전트가 아니라, 단순한 '반사 작용 프로그램(Reflex Program)'아니 입력에 리액션만 하는 '챗봇'에 불과하다고
그러면서 추가적으로 왜 목표가 에이전트의 필수 조건인지, 그리고 "목표가 없어도 에이전트처럼 보이던데?"라는 착각이 왜 일어나는지 명확한 근거와 함께 짚어준다 했다.
5.1.
러셀과 노빅의 교과서에는 에이전트를 발전 단계에 따라 분류하는데 우리가 지금 말하는 주도적인 AI 에이전트는 정확히 목표 기반 에이전트와 효용 기반 에이전트를 의미한다.
단순 반사 에이전트 : 목표가 없다.
목표 기반 에이전트 자신이 달성해야 할 '최종 상태'를 알고 있다.
현재 상태와 목표 상태를 비교하며, 그 목표에 도달하기 위해 필요한 행동을 스스로 계획하고 도구를 선택한다.
6. 그래서 그 목표는 누가 정함?
1. 상위 목표(Meta-Goal)는 '개발자'가 정한다.
에이전트가 태어날 때 가지는 근본적인 정체성과 세계관, 제약 조건은 개발자가 시스템 프롬프트(System Prompt)나 코드로 고정해 두어야 한다.
■ 예시 : 너는 사용자의 일정을 관리하고 개인 비서 역할을 수행하는 AI 에이전트다. 타인의 정보를 조회할 때는 반드시 보안 규정을 준수해야 한다.
■ 의미 : 에이전트가 존재해야 하는 이유와 절대 넘지 말아야 할 선(가이드라인)을 개발자가 법처럼 정해두는 것.
2. 당면 목표(Task-Goal)는 '사용자'가 정한다.
에이전트가 실제로 움직이게 만드는 실시간 트리거(명령)와 최종 목적지는 사용자가 던진다.
■ 예시 : "나 내일 오후 3시에 강남역 근처에서 친구 만나는데, 조용하고 주차 가능한 카페 3곳만 찾아서 내 캘린더에 등록해 줘."
■ 의미 : 개발자가 만든 비서(에이전트)에게 사용자가 구체적인 임무를 하달하는 것.
3. 하위 목표(Sub-Goal)와 계획은 'LLM(Core)'이 정한다.
개발자의 세계관 안에서 사용자의 명령을 받은 LLM은 이 목표를 달성하기 위해 문제를 쪼개고 스스로 하위 목표들을 수립한다.
이 부분이 단순 프로그램과 에이전트를 가르는 지점이다.
■ LLM의 내부 판단(Planning) :
- 하위 목표 1 : 강남역 주변의 조용하고 주차 가능한 카페를 웹 검색 툴로 찾자.
- 하위 목표 2 : 찾아낸 카페들의 상세 정보를 비교해서 가장 좋은 3곳을 추려내자.
- 하위 목표 3 : 구글 캘린더 API를 호출해서 내일 오후 3사에 등록하자.
■ 의미 : 큰 목표를 달성하기 위해 "지금 이 순간 무엇을 해야 하는가"에 대한 세부 목표는 LLM이 자율적으로 결정하도록 한다.
이거를 구현하기 위해 코드는 어떻게 적용되어야 하나...?
💡 한눈에 보는 역할 분담 (비유)
공사 현장으로 비유해보면
■ 개발자(설계자/건축주) : "이 땅에 '카페 건물(상위 목표)'을 지어라" 하고 에이전트의 존재 이유를 정의한다.
■ 사용자(현장 소장) : "오늘 퇴근 전까지 '2층 콘크리트 타설(당면 목표)' 끝내세요" 하고 구체적인 업무를 시킨다.
■ LLM(숙련된 목수/반장) : 그 명령을 듣고 "그럼 자재부터 나르고, 거푸집 짜고, 시멘트 비벼야겠네(하위 목표 수립)"라며 스스로 계획을 세우고 도구를 쥐어 잡는다.
따라서 "목표는 사용자가 던지고, 개발자가 틀을 잡고, LLM이 쪼갠다"가 정답이다.
우리가 개발자로서 에이전트에게 상위 목표(System)를 잘 심어줘야, 사용자가 던지는 임무(User Query)를 받았을 때 LLM이 길을 잃지 않고 스스로 하위 계획(Planning)을 세워서 도구를 쓸 수 있는 것이다.
에이전트 서비스의 성패는 코딩 실력이 아니라 예외 처리(Error Handling)와 상태 관리(State Management)에서 갈린다.
LLM은 언제든 헛소리를 하거나 툴 호출에 실패할 수 있다.
"에이전트가 삼천포로 빠졌을 때 어떻게 메인 루프로 복귀시킬 것인가?를 늘 염두에 두고 아키텍처를 설계해야 프로젝션 환경에서 버틸 수 있다.
왜 내가 여기에 집착하는가
사람은 실수를 한다.
그러나 고칠수 있다.
하지만 고치려면 뭐가 잘못되었는지를 알아야 한다.
그러려면 그 개념에 대해 인지하고 있어야 한다.
개발은 결국 유지보수의 반복이다.
처음에 잘못짜도 고치면 된다. 하지만 내가 뭘 고쳐야하는지 모른다면 그것은 큰 문제가 된다.
그렇기에 이 정의에 대해 명확하게 이해하고자 이 글을 남긴다.
'스터디 > AI-Agent' 카테고리의 다른 글
| [작성중/AI-Agent] Claude.md 분석 (0) | 2026.06.15 |
|---|---|
| [작성중/AI-Agent] 끔직한 결말, 그리고 방향성을 잡기위한 재설계의 필요성 (0) | 2026.06.14 |
| [작성중/AI-Agent] Claude가 작성한 프로젝트, 어떤 순서로 만들어졌을까? (0) | 2026.06.14 |
| [YouTube/작성중] 파이썬으로 ai Agent 만들기(프레임워크 X) (0) | 2026.06.03 |
| [작성중]AI 기술의 발달 과정과 n8n (0) | 2026.05.15 |
