LLM에 질문하고 답을 받는 코드만으로는 AI 에이전트가 아닙니다. 에이전트가 되려면 환경을 관찰하고, 목표에 맞는 행동을 고르고, 실제 도구를 실행한 뒤 그 결과를 다시 관찰하는 loop와 권한 통제가 필요합니다.
AI 에이전트는 LLM 호출에 도구 몇 개를 붙인 이름이 아니라 관찰한 결과를 다음 행동에 반영하는 폐루프 시스템입니다. 행동 권한, 중단 조건, 상태와 결과 검증이 없으면 자율성보다 오류의 반복이 먼저 커질 수 있습니다.
AI 에이전트와 챗봇은 무엇이 다른가: 도구 실행, 메모리, 권한까지 만드는 순서
챗봇과 에이전트를 가르는 것은 행동의 폐루프다
에이전트의 기본 구조는 perception, reasoning, action의 반복입니다.
1
2
3
4
5
6
사용자 목표
→ 환경, 상태 관찰
→ 다음 행동 계획
→ 도구 실행
→ 실행 결과 확인
→ 완료 또는 재계획
챗봇은 답변을 생성한 뒤 작업이 끝날 수 있습니다. 에이전트는 API 응답, database 변경, browser 화면, robot sensor처럼 행동 뒤에 바뀐 상태를 다시 읽어야 합니다. 성공 여부를 확인하지 않고 다음 단계로 넘어가면 여러 번의 작은 오류가 누적됩니다.
전통적인 분류도 이 loop에서 무엇을 유지하고 최적화하는지에 따라 이해할 수 있습니다.
| 유형 | 판단 근거 | 필요한 상태 |
|---|---|---|
| 단순 반사 | 현재 입력과 if-then 규칙 | 거의 없음 |
| 모델 기반 | 환경이 어떻게 변하는지 예측 | 내부 상태 |
| 목표 기반 | 목표까지의 행동 순서 | 목표와 계획 |
| utility 기반 | 여러 결과의 효용 비교 | 점수, trade-off |
| 학습 | 경험으로 정책 개선 | 기록과 feedback |
LLM agent는 이 중 하나의 고정 유형이라기보다 자연어 reasoning과 tool selection을 기존 규칙, 계획, 학습 구조에 결합한 형태가 될 수 있습니다.
LLM, 도구, 메모리는 서로 다른 책임이다
LLM은 사용자의 지시를 해석하고 후보 행동을 만들 수 있지만, 실제 권한과 상태를 스스로 갖고 있지는 않습니다.
- LLM: 목표 해석, 계획, 도구 인자 생성, 결과 요약
- Tool layer: browser, code, API, database 같은 실제 행동
- Memory: 대화, 작업 단계, 실행 결과와 장기 지식 저장
- Controller: 반복 횟수, 완료 조건, 오류, 승인 처리
- Guardrail: 허용된 도구와 데이터, 비용, 권한 제한
행동 선택을 추상화하면 원문처럼 상태와 가능한 사고 경로에 따른 확률로 표현할 수 있습니다.
\[P(action|state) = \\sum_i P(thought_i|state) \\times P(action|thought_i,state)\]하지만 확률이 높은 행동이 안전하거나 허용된 행동이라는 뜻은 아닙니다. “가장 그럴듯한 API 호출”과 “실제로 실행해도 되는 호출” 사이에 schema 검증과 권한 정책이 필요합니다.
memory도 대화 전체를 무조건 저장하는 기능이 아닙니다. 현재 작업에 필요한 short-term state와 이후에도 보관할 long-term information을 나누고, 오래된 상태가 새 실행을 오염시키지 않도록 갱신 기준을 정해야 합니다.
기존 Python 조각이 빠뜨린 것
원문에는 다음 LLM 호출 예제가 있습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
from openai import OpenAI
client = OpenAI()
def agent_response(user_input):
response = client.chat.completions.create(
model="gpt-4",
messages=[
{"role": "system", "content": "당신은 친절한 비서입니다."},
{"role": "user", "content": user_input}
]
)
return response.choices[0].message.content
이 코드는 한 번의 응답을 받는 핵심 조각이지 완전한 agent가 아닙니다. tool 정의와 실행, 결과 재입력, memory, 종료 조건, 오류 처리, 사용자 승인 흐름이 없습니다. model="gpt-4"와 client interface도 설치한 library와 사용 가능한 모델 환경에 맞는지 별도로 확인해야 합니다.
날씨 예제도 구조를 보여주는 pseudocode입니다.
1
2
3
4
5
6
7
8
9
def weather_agent(query):
intent = analyze_intent(query)
if intent == "weather":
location = extract_location(query)
weather_data = call_weather_api(location)
return format_weather_response(weather_data)
else:
return llm_response(query)
analyze_intent, extract_location, call_weather_api, format_weather_response가 정의돼 있지 않으므로 그대로 실행할 수 없습니다. 이 조각의 가치는 “의도 판단 → 입력 추출 → 도구 호출 → 결과 변환”의 경계를 보여주는 데 있습니다.
실제 구현에서는 location이 비었을 때 질문을 되돌려야 하고, API 실패와 timeout을 처리하며, 도구 결과가 사용자의 질문과 맞는지 확인해야 합니다.
작은 에이전트는 이 순서로 만든다
“무엇이든 하는 비서”보다 결과를 검증할 수 있는 한 가지 작업으로 시작하는 편이 좋습니다.
- 목표와 완료 조건을 한 문장으로 정합니다.
- 사용할 도구와 금지할 행동을 목록으로 만듭니다.
- 각 도구의 입력, 출력 schema를 고정합니다.
- 현재 상태와 다음 행동을 기록할 memory를 설계합니다.
- 실행 전 validation과 위험 행동의 사용자 승인을 둡니다.
- 실행 결과를 다시 관찰하고 성공 여부를 검사합니다.
- 최대 반복 횟수와 중단 조건을 정합니다.
예를 들어 보고서 agent라면 “자료를 찾는다”보다 “허용된 database에서 지정 기간의 데이터를 읽고, 합계가 원본과 일치하는 표를 만든다”가 테스트하기 쉽습니다. 메시지 전송, 결제, 파일 삭제, robot motor 제어처럼 되돌리기 어려운 행동은 자동 실행 범위를 좁히고 승인 지점을 둬야 합니다.
평가도 최종 문장 품질만 보면 안 됩니다.
| 평가 항목 | 확인 질문 |
|---|---|
| 목표 달성 | 요청한 결과가 만들어졌나 |
| 도구 정확도 | 올바른 도구와 인자를 선택했나 |
| 상태 관리 | 이미 끝난 단계를 반복하지 않았나 |
| 오류 복구 | 실패를 감지하고 안전하게 멈췄나 |
| 비용 | 불필요한 호출과 loop가 없었나 |
| 권한 | 허용되지 않은 행동을 시도하지 않았나 |
multi-agent가 항상 더 좋은 것은 아니다
여러 agent를 planner, researcher, executor, reviewer처럼 나누면 역할별 prompt와 도구 권한을 분리할 수 있습니다. 복잡한 작업을 병렬화하거나 서로 결과를 검토하는 데 유용합니다.
반면 agent 사이의 메시지가 늘고, 서로 다른 상태를 믿거나, 같은 일을 중복 수행할 수 있습니다. 한 agent로 충분한 작업에 multi-agent를 붙이면 비용과 실패 지점만 늘어납니다. 역할 사이에 전달할 산출물과 최종 책임자를 정할 수 있을 때 분리해야 합니다.
원문이 연결한 추가 자료는 LangChain 문서, AutoGPT 저장소, Stanford CS224U입니다. 설치 예시는 다음과 같지만, 각 package의 현재 version과 환경 호환성을 확인하지 않은 완전한 setup script는 아닙니다.
1
2
3
pip install langchain
git clone https://github.com/Significant-Gravitas/AutoGPT.git
pip install semantic-kernel
AI agent의 자율성은 많이 맡길수록 커지는 기능이 아니라, 관찰과 검증 사이에서 허용된 행동을 얼마나 안정적으로 반복하느냐의 문제입니다. 첫 구현의 목표는 사람을 없애는 것이 아니라, 좁고 검증 가능한 loop를 끝까지 정확히 닫는 것이어야 합니다.
첫 Agent 과제는 네 문장으로 정의한다
“어떤 입력을 받는가”, “어떤 도구를 읽거나 실행하는가”, “완료를 무엇으로 판정하는가”, “어느 행동 전에 사람이 승인하는가”를 적습니다. “메일을 처리한다”보다 “새 메일을 주제별로 분류해 draft 목록을 만들고 발송은 하지 않는다”처럼 경계가 보여야 합니다.
도구 schema에는 허용된 argument와 실패 응답을 명시하고, model이 존재하지 않는 parameter를 만들거나 timeout을 만났을 때 재시도 횟수를 제한합니다. 읽기와 쓰기 권한을 분리하고 삭제, 결제, 외부 전송은 초기 과제에서 제외합니다.
완료 설명보다 상태를 검사한다
파일 정리 Agent라면 실제 대상 directory와 변경 목록, 코딩 Agent라면 diff와 test, 일정 Agent라면 생성된 event와 중복 여부를 확인합니다. 모델의 최종 문장은 참고일 뿐 외부 상태가 원하는 조건과 일치해야 완료입니다.
각 step에는 입력, 선택한 tool, arguments, result, 다음 판단을 기록합니다. 오류가 나면 perception, planning, tool execution, verification 중 어느 단계인지 분류합니다. 성공률 하나만 남기면 prompt를 고쳐야 하는지 tool을 고쳐야 하는지 알 수 없습니다.
Memory와 Multi-Agent를 늦게 추가한다
한 session 안의 작업이 안정된 뒤에만 장기 memory를 넣습니다. 잘못된 사실이나 민감 정보가 memory에 저장되면 이후 요청에 반복될 수 있으므로 저장 조건, 수정, 삭제와 사용자별 격리가 필요합니다. 모든 대화를 무기한 저장하는 것은 기억이 아니라 새 위험입니다.
여러 Agent도 역할마다 독립 검증이 있을 때 사용합니다. 같은 model이 만든 결과를 같은 기준으로 서로 확인하면 오류를 합의할 수 있습니다. 단일 loop보다 완료율이 실제로 오르고 호출, 지연이 감당되는지 비교한 뒤 분업을 늘리는 편이 안전합니다.
함께 읽으면 이해가 이어지는 글
- Nvidia Nemotron 3.5 Lightning과 NeMo Switchyard: 에이전트 모델 라우팅 판단법 — Nvidia가 자율 에이전트 시스템을 위해 개발된 30B 규모의 오픈 모델 Nemotron 3.5 Lightning과 오픈소스 라우터 라이브러리 NeMo Switchyard를 2026년 8월 11일 공개했습니다. NeMo…
- Anthropic Skills는 MCP와 무엇이 다를까: SKILL.md 구조부터 검증까지 — anthropics/skills를 도구 자체가 아닌 재사용 가능한 작업 지침으로 읽고, 점진적 로딩 구조, 저장소 예시, 안전한 시험 순서를 정리합니다.
- Google ADK Python 예제가 실행되지 않는 이유: 상태, 도구, 재시도 경계 — ADK가 프롬프트 밖의 상태, 도구, 순환 제어를 구조화하는 이유를 설명하고, 프레임워크 개념이 섞인 예제를 실제 Google ADK 코드로 오해하지 않도록 전제와 누락을 짚습니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.