1강. LLM 에이전트란 무엇인가 | LLM 에이전트 설계와 구현 20강 · 고급 — 누구나패스

🎯 학습 목표

이 강을 마치면 다음을 할 수 있습니다.

LLM 에이전트와 일반 챗봇의 근본적인 차이를 명확히 설명할 수 있습니다.
인식→계획→행동→관찰(Perceive-Plan-Act-Observe) 루프가 어떻게 동작하는지 이해합니다.
대표적인 LLM 에이전트 사례를 알고, 각각의 특징을 비교할 수 있습니다.
LLM 에이전트의 현실적인 한계를 파악하고, 설계 시 무엇을 주의해야 하는지 이해합니다.

🤖 챗봇과 에이전트 — 무엇이 근본적으로 다른가

이 섹션에서는 우리가 이미 익숙한 챗봇과 LLM 에이전트의 차이를 살펴보겠습니다.

ChatGPT나 Claude에게 "파이썬에서 리스트를 정렬하는 방법을 알려줘"라고 물으면 즉각 답변이 돌아옵니다. 질문 하나에 답변 하나, 이것이 전통적인 챗봇(Chatbot)의 동작 방식입니다. 챗봇은 사용자의 입력을 받아 한 번의 추론으로 텍스트를 생성하고 멈춥니다. 외부 세계와 직접 상호작용하지 않으며, 결과가 맞는지 스스로 확인하지도 않습니다.

반면 LLM 에이전트(LLM Agent)는 다릅니다. 에이전트는 목표(Goal)를 받아 그것을 달성하기 위해 스스로 계획을 세우고, 도구(Tool)를 호출하고, 결과를 관찰한 뒤 다음 행동을 결정합니다. 이 과정을 목표가 달성될 때까지 반복합니다. 단순히 텍스트를 생성하는 것이 아니라 실제로 무언가를 실행하고, 그 결과에 따라 행동을 수정합니다.

핵심 차이를 한 문장으로 정리하면 이렇습니다. 챗봇은 질문에 답하고, 에이전트는 문제를 해결합니다. 챗봇이 "서울 날씨가 어떤가요?"라는 질문에 훈련 데이터 기반의 일반적인 서울 날씨를 설명한다면, 에이전트는 날씨 API를 호출해 지금 이 순간의 실제 날씨를 가져옵니다. 이 차이가 에이전트를 단순한 대화 도구를 넘어 실제 업무를 수행할 수 있는 자율 시스템으로 만드는 핵심 특성입니다.

챗봇과 에이전트를 나누는 경계선은 자율성(Autonomy)과 도구 사용(Tool Use), 그리고 피드백 루프(Feedback Loop)입니다. 이 세 가지가 모두 있어야 진정한 에이전트라고 할 수 있습니다.

구분	챗봇	LLM 에이전트
동작 방식	요청-응답(1회)	루프(목표 달성까지 반복)
자율성	없음 (정해진 답 생성)	있음 (스스로 계획·결정)
도구 사용	없음 또는 제한적	API·DB·코드 실행 등 다양
다단계 추론	단일 응답	여러 단계에 걸쳐 추론 연결
메모리	대화 내 맥락만	단기·장기 메모리 구성 가능
외부 작용	텍스트 생성에 한정	외부 시스템에 실제 행동

이 차이는 단순한 기능의 유무가 아닙니다. 에이전트는 LLM의 추론 능력을 실세계의 행동과 연결하는 아키텍처 패러다임의 전환입니다. 이 시리즈 전체가 바로 이 연결 방법을 깊이 있게 다룹니다.

🔄 인식→계획→행동→관찰 루프

이 섹션에서는 에이전트가 어떤 순서로 생각하고 행동하는지, 그 핵심 루프를 살펴보겠습니다.

LLM 에이전트의 동작을 이해하는 가장 좋은 출발점은 Perceive-Plan-Act-Observe 루프입니다. 이 패턴은 특정 논문 하나에서 정의된 것이 아니라, 자율 에이전트 시스템을 설계하는 과정에서 자연스럽게 수렴된 아키텍처 원칙입니다. 로봇공학과 강화학습 분야에서 오랫동안 사용해 온 감각-행동(Sense-Act) 루프의 LLM 버전이라고 이해하면 됩니다.

인식(Perceive): 에이전트가 현재 상태를 파악합니다. 사용자의 최초 목표, 이전 도구 실행 결과, 메모리에서 꺼낸 관련 정보 등 모든 컨텍스트를 수집해 LLM에 전달할 프롬프트를 구성합니다.
계획(Plan): 목표를 달성하려면 무엇을 해야 하는지 추론합니다. 어떤 도구를 어떤 순서로 사용할지, 현재 상태에서 다음 단계가 무엇인지 결정합니다. LLM의 언어 추론 능력이 이 단계에서 핵심 역할을 합니다.
행동(Act): 결정한 도구나 API를 실제로 호출합니다. 웹 검색, 코드 실행, 데이터베이스 조회, 파일 읽기·쓰기, 외부 서비스 호출 등 다양한 외부 작업이 여기에 해당합니다.
관찰(Observe): 행동의 결과를 받아 컨텍스트에 추가합니다. 목표가 달성됐는지 판단하고, 달성되지 않았다면 다시 인식 단계로 돌아가 루프를 반복합니다.

2022년 10월 arXiv에 발표된 ReAct(Reasoning + Acting) 논문(Shunyu Yao 외, Princeton University·Google Research, ICLR 2023 채택)은 이 루프를 실용적으로 구현하는 방법을 제시했습니다. ReAct는 LLM이 Thought(생각) → Action(행동) → Observation(관찰)을 교대로 텍스트로 출력하도록 프롬프트를 설계해, ALFWorld 벤치마크에서 기존 모방 학습 방식 대비 34%, WebShop 벤치마크에서 10% 성능을 개선했습니다. 이 시리즈 2강에서 ReAct 패턴을 파이썬으로 직접 구현하게 됩니다.

루프의 종료 조건도 중요합니다. 에이전트는 (1) 목표가 달성됐다고 LLM이 판단하거나, (2) 최대 반복 횟수에 도달하거나, (3) 더 이상 취할 행동이 없을 때 루프를 종료합니다. 적절한 종료 조건 없이 루프를 설계하면 에이전트가 무한히 실행되거나 불필요한 API 비용을 소모하는 문제가 생깁니다. 이는 에이전트 설계의 중요한 실전 포인트 중 하나입니다.

💻 최소 에이전트 루프 — 파이썬 예제

이 섹션에서는 방금 배운 루프를 파이썬 코드로 표현해 보겠습니다. 아직 실제 LLM API를 연결하기 전 단계이지만, 에이전트의 핵심 구조를 눈으로 확인하는 것이 목적입니다.

# 에이전트 루프의 핵심 구조 (의사 코드)
import json
from typing import Callable

def run_agent(
    goal: str,
    tools: dict[str, Callable],
    llm: Callable[[str], str],
    max_steps: int = 10,
) -> str:
    """
    goal   : 달성할 목표 (사용자 입력)
    tools  : {tool_name: callable} 형태의 도구 딕셔너리
    llm    : LLM 호출 함수 (프롬프트 -> 텍스트 반환)
    """
    # 컨텍스트: 목표부터 시작해 Thought/Action/Observation이 축적됨
    context = [f"Goal: {goal}"]
    tool_descriptions = "\n".join(
        f"- {name}: {fn.__doc__}" for name, fn in tools.items()
    )

    for step in range(max_steps):         # ① 최대 반복 횟수 제한
        # --- 인식(Perceive): 현재 컨텍스트로 프롬프트 구성 ---
        prompt = build_prompt(context, tool_descriptions)

        # --- 계획(Plan) + 행동(Act) 결정: LLM 추론 ---
        response = llm(prompt)            # LLM이 Thought + Action을 출력
        thought, action = parse_response(response)
        context.append(f"Thought: {thought}")

        # ② LLM이 스스로 완료라고 판단하면 종료
        if action["type"] == "finish":
            return action["result"]

        # --- 행동(Act): 도구 실제 호출 ---
        tool_fn = tools.get(action["tool"])
        if tool_fn is None:
            observation = f"Error: 알 수 없는 도구 '{action['tool']}'"
        else:
            observation = tool_fn(**action["args"])

        # --- 관찰(Observe): 결과를 컨텍스트에 추가 ---
        context.append(f"Action: {json.dumps(action, ensure_ascii=False)}")
        context.append(f"Observation: {observation}")
        # 다음 이터레이션에서 이 관찰값을 포함한 새 프롬프트가 만들어짐

    return "최대 스텝에 도달했습니다. 목표를 달성하지 못했습니다."

코드의 핵심 부분을 하나씩 살펴보겠습니다.

context 리스트: 에이전트의 단기 메모리 역할을 합니다. 목표, 생각, 행동, 관찰이 순서대로 쌓이고, 이것이 다음 LLM 호출의 프롬프트 입력이 됩니다. 루프가 반복될수록 이 리스트가 길어지고, 결국 컨텍스트 창 한계와 충돌하게 됩니다. 6강에서 이 문제를 해결하는 메모리 설계를 다룹니다.
max_steps: 무한 루프를 방지하는 안전 장치입니다. 프로덕션 에이전트에서는 비용과 응답 시간을 고려해 반드시 설정해야 합니다. 일반적으로 단순 작업은 5~10 스텝, 복잡한 멀티스텝 작업은 20~50 스텝을 기준으로 잡습니다.
action["type"] == "finish": LLM이 스스로 목표를 달성했다고 판단하면 "finish" 타입 액션을 반환하고 루프를 종료합니다. 이 종료 신호를 LLM이 어떻게 생성하도록 프롬프트를 설계하느냐가 에이전트 품질에 큰 영향을 줍니다.
tool_fn(**action["args"]): 도구를 실제로 호출하는 부분입니다. LLM이 생성한 액션 파라미터가 도구 함수의 인수로 그대로 전달됩니다. 3강에서 도구 정의와 스키마를 체계적으로 다룰 예정입니다.

이 구조에서 build_prompt()와 parse_response()가 에이전트 품질을 좌우하는 숨은 핵심입니다. 프롬프트를 어떻게 구성하느냐, LLM 출력을 어떻게 파싱하느냐에 따라 같은 LLM을 사용해도 에이전트 성능이 크게 달라집니다. 이 두 함수의 구현 전략을 2강부터 단계적으로 배우게 됩니다.

🌐 대표적인 LLM 에이전트 사례

이 섹션에서는 실제로 세상에 등장한 LLM 에이전트의 대표 사례를 살펴보겠습니다. 사례를 통해 에이전트가 어떤 방식으로 동작하는지, 어떤 한계를 보이는지 직관적으로 이해할 수 있습니다.

AutoGPT는 2023년 3월 Toran Bruce Richards가 공개한 오픈소스 프로젝트입니다. GPT-4를 사용해 사용자가 제시한 장기 목표를 달성하기 위해 스스로 하위 작업을 생성하고 실행합니다. 인터넷 검색, 파일 읽기·쓰기, 코드 실행 기능을 갖추고 있으며, 당시 에이전트 가능성을 대중에게 처음으로 강렬하게 보여준 프로젝트입니다. 다만 실제 사용에서는 루프를 무한 반복하거나 목표와 무관한 작업을 생성하는 등 안정성 문제가 자주 보고됐습니다. 이는 종료 조건과 에이전트 안전 설계가 얼마나 중요한지 보여주는 사례입니다.

BabyAGI(Yohei Nakajima)는 태스크 생성 에이전트, 태스크 우선순위 지정 에이전트, 태스크 실행 에이전트라는 세 가지 특화 에이전트가 협력하는 구조를 보여줬습니다. 한 에이전트가 모든 것을 처리하는 대신 역할을 분리해 각자 최적화한다는 아이디어는 이후 멀티에이전트 시스템 설계의 원형이 됐습니다. 이 시리즈 8강에서 멀티에이전트 시스템을 깊이 있게 다룹니다.

대형 AI 기업들도 에이전트 제품을 본격적으로 출시하고 있습니다. Anthropic Claude는 도구 사용(Tool Use) API를 통해 에이전트 구현을 지원하며, 명확하게 정의된 도구 스키마를 기반으로 안정적인 도구 호출을 제공합니다. 이 시리즈 17강에서 Claude API로 에이전트를 직접 구현해 봅니다. 이 외에도 Microsoft Copilot, Google Gemini의 에이전트 기능, OpenAI의 Assistants API 등 주요 플랫폼 모두 에이전트 기능을 지원합니다.

기업 현장에서의 에이전트 활용도 빠르게 확산되고 있습니다. 코드 리뷰 자동화, 고객 서비스 에스컬레이션, 데이터 분석 파이프라인 자동화, 문서 요약과 분류 등이 대표적입니다. 그러나 현재 실전 배포 에이전트의 대부분은 좁은 범위의 특정 도메인에 집중하는 형태입니다. 범용 에이전트보다 도메인 특화 에이전트가 현재로서는 훨씬 더 안정적으로 동작하고, 예측 가능한 성능을 보입니다.

⚠️ 에이전트의 한계와 설계 시 주의점

이 섹션에서는 에이전트가 왜 항상 기대대로 동작하지 않는지, 그 근본 원인을 살펴보겠습니다. 한계를 이해하는 것은 에이전트를 제대로 설계하기 위한 출발점입니다.

첫 번째 한계는 환각(Hallucination)입니다. LLM은 확률 기반으로 텍스트를 생성하기 때문에 사실이 아닌 내용을 자신 있게 출력할 수 있습니다. 에이전트 맥락에서는 특히 "기능적 환각"이 위험합니다. 도구를 잘못된 인수로 호출하거나, 존재하지 않는 API를 호출하거나, 실제로 동작하지 않는 코드를 작성하는 경우가 여기에 해당합니다. 도구 정의를 모호하게 작성하면 에이전트가 추측에 의존하게 되어 환각이 더 자주 발생합니다. 3강에서 도구 스키마를 명확하게 설계하는 방법을 자세히 다룹니다.

두 번째는 컨텍스트 창(Context Window) 제한입니다. 에이전트 루프가 반복될수록 컨텍스트에는 점점 더 많은 Thought·Action·Observation이 쌓입니다. 모델의 컨텍스트 창 한계를 넘으면 초기에 주어진 중요한 지시사항이 잘리거나 무시될 수 있습니다. 최근 모델들이 대용량 컨텍스트를 지원하더라도, 장기 루프에서는 체계적인 메모리 관리 전략이 필수입니다. 6강과 7강에서 단기·장기 메모리 설계를 다룹니다.

세 번째는 컨텍스트 오염(Context Poisoning)입니다. 루프 초반에 잘못된 관찰값이 컨텍스트에 들어오면, 이후의 모든 추론이 그 잘못된 정보를 기반으로 이루어집니다. 오류가 오류를 낳는 연쇄 실패가 발생하고, 에이전트는 점점 더 엉뚱한 방향으로 나아갑니다. 이를 방지하기 위해 도구 결과를 검증하는 단계를 루프에 포함하거나, 특정 임계값 이상의 오류가 발생하면 루프를 중단하는 안전 장치가 필요합니다.

네 번째는 비결정성(Non-determinism)입니다. 동일한 입력에도 LLM은 매번 조금씩 다른 출력을 생성할 수 있습니다. 에이전트 루프에서는 이 변동성이 증폭됩니다. 한 단계의 출력이 다음 단계의 입력이 되기 때문에, 초기의 작은 차이가 완전히 다른 결과로 이어지기도 합니다. temperature 설정, 명확한 프롬프트, 구조화된 출력 스키마를 통해 이 변동성을 최소화하는 것이 중요합니다. 14강 에이전트 디버깅 기법에서 이 문제를 체계적으로 다룹니다.

이 한계들은 에이전트가 "쓸모없다"는 뜻이 아닙니다. 오히려 이 한계를 알고 설계하면 훨씬 더 견고한 에이전트를 만들 수 있습니다. 이 시리즈 전체가 각각의 한계를 극복하는 구체적인 기법을 단계적으로 소개합니다.

📝 핵심 요약 + 다음 강 예고

이 강에서 배운 내용을 정리하겠습니다.

개념	핵심 내용
에이전트 정의	목표를 받아 도구를 사용하고 루프를 통해 스스로 달성하는 시스템
챗봇과의 차이	챗봇 = 1회 응답, 에이전트 = 목표 달성까지 반복 루프
핵심 루프	인식(Perceive) → 계획(Plan) → 행동(Act) → 관찰(Observe)
ReAct 논문	Thought/Action/Observation 교대 구조, ICLR 2023 채택 (Yao et al., 2022)
대표 사례	AutoGPT(2023.03), BabyAGI, Claude Tool Use, OpenAI Assistants API
주요 한계	환각, 컨텍스트 창 제한, 컨텍스트 오염, 비결정성

에이전트의 개념과 동작 원리를 이해했다면 이제 실전으로 넘어갈 준비가 된 것입니다. 다음 강인 2강 「ReAct 에이전트 패턴」에서는 오늘 개념으로만 소개한 ReAct를 파이썬 코드로 직접 구현합니다. Thought→Action→Observation 루프를 실제 LLM API와 연결해, 간단한 도구 사용 에이전트를 처음부터 만들어 보겠습니다.

LLM 에이전트란 무엇인가