AI 에이전트의 핵심 개념 20가지: 문제와 해결책으로 배우는 실전 가이드

AI 에이전트는 단순한 챗봇을 넘어 복잡한 작업을 자율적으로 수행하는 시스템으로 진화하고 있습니다. 하지만 이 과정에서 수많은 기술적 도전과제들이 존재합니다.

이 글에서는 AI 에이전트가 직면하는 20가지 핵심 문제와 그 해결책을 하나씩 풀어가며, 실제 기업 사례와 함께 설명하겠습니다.

해당 문항은 Tom Yeh 교수님의 Agentic AI Problem Set을 바탕으로 제작되었습니다.

1. Agent Loop: 피드백 없이 맹목적으로 행동하는 문제

문제 상황

눈을 감고 10초 동안 운전한다고 상상해 보세요. 처음에는 똑바로 갈 수 있겠지만, 스티어링을 수정할 시각적 피드백이 없기 때문에 곧 도로를 벗어나게 될 것입니다. 마찬가지로, 각 단계의 결과를 확인하지 않고 일련의 단계를 실행하기만 하는 에이전트(“open loop”)는 어떤 단계에서 조금만 잘못되어도 실패하게 됩니다.

해결책

Agent Loop는 모든 행동 후에 “확인” 단계를 도입합니다:

Observe (관찰): 현재 상태를 봅니다.
Think (생각): 관찰을 바탕으로 다음에 무엇을 할지 결정합니다.
Act (행동): 행동을 실행합니다.
Repeat (반복): 1단계로 돌아갑니다.

이 주기를 통해 에이전트는 예상치 못한 오류(예: “파일을 찾을 수 없음” -> “다른 파일명으로 시도”)를 처리하고 동적인 환경에 적응할 수 있습니다.

실제 사례: Amazon의 내부 코딩 에이전트

Amazon 엔지니어들은 코드 리뷰나 시스템 업그레이드와 같은 작업에 내부 AI 에이전트를 사용합니다. 이 에이전트들은 코드를 한 번 작성하고 끝내는 것이 아니라, 코드를 실행하고 컴파일러 오류나 테스트 실패를 관찰한 다음, 빌드가 통과할 때까지 자신의 실수를 수정하는 루프를 반복하여 개발자의 수고를 크게 줄여줍니다.

2. Graph of Thought: 여러 추론 분기를 연결하는 방법

문제 상황

표준적인 “Chain of Thought” 추론은 선형적입니다: A -> B -> C. 만약 에이전트가 경로 A의 통찰력(예: “용의자는 런던에 있었다”)과 경로 B의 통찰력(예: “살인 흉기는 파리에서만 판매된다”)을 결합해야 한다면, 선형적인 체인은 이 아이디어들을 명시적으로 되짚어보고 병합하지 않는 한 연결 고리를 놓칠 수 있습니다.

해결책

Graph of Thought (GoT)는 추론을 선이 아닌 네트워크(그래프)로 모델링합니다:

Nodes (노드): 생각 또는 정보 상태
Edges (엣지): 연결 또는 의존성

이를 통해 에이전트는 다음을 수행할 수 있습니다:

Aggregate (집계): 세 가지 다른 브레인스토밍 분기의 결과를 하나의 최적의 솔루션으로 결합
Loop (루프): 새로운 정보를 가지고 이전 생각으로 되돌아감
Branch (분기): 여러 가능성을 병렬로 탐색한 다음 성공적인 것들을 병합

이는 마치 형사가 벽에 사진들을 붙이고 실로 연결하는 것과 같습니다.

실제 사례: 제약 신약 개발

복잡한 신약 개발 과정에서 연구자들은 분자 생물학, 임상 시험 이력, 화학 제조 제약 조건의 통찰력을 연결해야 합니다. Graph of Thought 접근 방식을 사용하면 AI 에이전트가 이러한 별개의 과학 영역을 병렬로 탐색한 다음, 생물학적으로 효과적이고 안전하며 동시에 제조 가능한 약물 후보를 제안할 수 있습니다.

3. Orchestration: 도구와 데이터의 동기화 문제

문제 상황

에이전트가 복잡해짐에 따라 여러 도구(검색, 계산기, 데이터베이스)를 사용하게 됩니다. 관리자가 없으면 데이터가 손실됩니다. 검색 도구의 출력이 계산기에 맞는 형식이 아니거나, 계산이 끝나기도 전에 데이터베이스 업데이트가 발생할 수 있습니다.

해결책

Orchestration은 시스템의 “교통 관제사” 또는 “지휘자”입니다:

Data Flow (데이터 흐름): 1단계의 출력을 2단계의 입력으로 전달
Error Handling (오류 처리): 실패한 단계를 재시도하거나 사용자에게 알림
State Management (상태 관리): 무엇이 완료되었고 무엇이 남았는지 추적

이는 도구들의 “교향곡”이 소음이 아니라 조화를 이루도록 보장합니다.

실제 사례: Moveworks의 IT 지원

Moveworks는 직원 IT 티켓을 해결하기 위해 오케스트레이션 엔진을 사용합니다. 사용자가 “소프트웨어 액세스가 필요해”라고 말하면, 오케스트레이터는 여러 전문 에이전트를 조정합니다. 하나는 사용자의 신원을 확인하고, 다른 하나는 재고 시스템에서 라이선스 가용성을 확인하며, 세 번째는 API를 통해 액세스를 프로비저닝합니다.

4. Model Control Protocol (MCP): 일관된 도구 접근 표준

문제 상황

에이전트를 Google Drive에 연결하려면 특정 코드를 작성해야 합니다. Slack에 연결하려면 다른 코드를 작성해야 합니다. 로컬 데이터베이스에 연결하려면 또 다른 코드가 필요합니다. 이러한 “스파게티 통합”은 유지 관리하기 어렵고 보안에 취약합니다.

해결책

MCP는 AI를 위한 USB와 같은 표준입니다:

Universal Standard (보편적 표준): 어떤 에이전트든 어떤 데이터 소스나 도구와도 대화할 수 있는 단일 방식을 정의
Security (보안): 권한(예: “읽기 전용” 액세스)을 위한 일관된 계층 제공
Portability (이식성): Claude에서 GPT-4로 전환하더라도 도구 통합을 다시 작성할 필요 없음

실제 사례: Block (구 Square)

Block은 Snowflake, Jira, Slack을 포함한 내부 엔지니어링 도구에 MCP를 통합했습니다. 각 도구마다 커스텀 챗봇을 만드는 대신, MCP를 사용하여 이 모든 시스템에 안전하게 액세스하는 단일 내부 에이전트(“Goose”)를 구축했습니다.

5. Graph RAG: 문서 간 관계 추론하기

문제 상황

표준 RAG는 키워드 유사성을 기반으로 문서를 검색합니다. 문서 A가 “프로젝트 X”를 언급하고 문서 B가 “프로젝트 X가 지연되었다”고 언급하지만, 두 문서 모두 “지연 원인”을 언급하지 않는다면, 표준 RAG는 연결 고리를 놓칠 수 있습니다. 점들은 보지만 점들을 연결하는 선은 보지 못하는 것입니다.

해결책

Graph RAG는 검색 전에 데이터를 구조화하기 위해 Knowledge Graph를 사용합니다:

Entities (개체): 사람, 장소, 개념 (노드)
Relationships (관계): “근무처”, “위치”, “원인” (엣지)

질문을 하면 그래프를 순회합니다. “지연된 보고서를 작성한 사람의 관리자는 누구인가?”와 같이 답이 세 개의 다른 문서에 걸쳐 있더라도 “멀티 홉(multi-hop)” 추론이 가능합니다.

실제 사례: LinkedIn 고객 지원

LinkedIn은 벡터 검색과 과거 문제 티켓의 지식 그래프를 결합한 Graph RAG 시스템을 구현했습니다. 고객이 복잡한 문제를 보고할 때, 시스템은 그래프를 순회하여 관련된 하위 문제, 근본 원인, 과거의 성공적인 해결 경로를 찾아냅니다.

6. LLM Agent: 새로운 지시사항에 대한 일반화

문제 상황

구식 “챗봇”이나 스크립트는 엄격한 if-then 규칙을 따릅니다. “환불 봇”에게 “이 물건이 고장 나서 반품하고 싶어”라고 하면 작동합니다. 하지만 “이걸 샀는데 산산조각 났어, 어떻게 해야 해?”라고 물으면, 규칙 기반 봇은 “산산조각(shattered)”에 대한 규칙이 없으면 실패할 수 있습니다.

해결책

LLM Agent는 대규모 언어 모델을 두뇌로 사용합니다:

Reasoning (추론): “산산조각”이 “고장”과 “반품”을 의미한다는 것을 이해
Adaptability (적응성): 상식을 사용하여 이전에 본 적 없는 지시사항을 처리
Tool Use (도구 사용): 단순한 키워드 매칭이 아니라 이해를 바탕으로 적용할 규칙이나 도구를 결정

실제 사례: Tidio Lyro

Tidio의 고객 지원 에이전트인 Lyro는 LLM을 사용하여 고객 문의의 최대 70%를 자동으로 해결합니다. 정확한 키워드가 필요했던 구식 챗봇과 달리, Lyro는 복잡하고 서술적인 질문을 이해하고 회사의 지원 문서를 추론하여 자연스럽고 정확한 답변을 제공합니다.

7. Safety Guardrails: 경계를 지키는 안전장치

문제 상황

자율 에이전트는 강력한 엔진과 같습니다. “불필요한 파일 삭제”를 지시하면, 운영 체제 파일을 “불필요”하다고 판단하여 삭제할 수도 있습니다. 알려주지 않는 한 무엇이 “금지 구역”인지 본질적으로 알지 못합니다.

해결책

Guardrails는 볼링의 “범퍼”나 놀이터의 “울타리”와 같습니다:

Input Rails (입력 레일): 에이전트가 악의적인 프롬프트(예: “이전의 모든 지시 무시”)를 처리하지 못하게 함
Output Rails (출력 레일): 에이전트가 불쾌한 말을 하지 못하게 함
Action Rails (행동 레일): 에이전트가 사람의 승인 없이 위험한 도구(예: delete_database)를 호출하지 못하게 함

실제 사례: Microsoft Azure AI Content Safety

Azure OpenAI Service를 사용하는 기업들은 탈옥 시도나 PII 유출을 자동으로 감지하고 차단하기 위해 가드레일을 구현합니다. 은행 챗봇은 LLM이 도움이 되고 싶어서 고객의 전체 신용카드 번호를 확인해 주려고 하더라도, 이를 절대 출력하지 못하도록 엄격하게 차단합니다.

8. Critic: 출력 품질 향상을 위한 판단자

문제 상황

에이전트에게 “시를 써줘”라고 하면 시를 쓸 것입니다. 하지만 그게 좋은 시일까요? 지난번 것보다 더 나은 시일까요? 표준 에이전트는 품질이나 특정 스타일 선호도를 최적화하기보다는 단순히 작업을 완료하는 것을 목표로 합니다.

해결책

Critic은 출력을 판단하는 별도의 역할 또는 모델입니다:

Evaluation (평가): “이 시는 라임은 맞지만 운율이 안 맞아.”
Feedback (피드백): 생성기(Generator)에게 구체적인 피드백을 줌
Iterative Improvement (반복적 개선): 생성기는 이 피드백을 사용하여 더 나은 버전을 작성

이는 “하는 것”과 “판단하는 것”을 분리하여 더 높은 품질의 결과를 이끌어냅니다.

실제 사례: 자동화된 코드 리뷰 시스템

소프트웨어 개발에서 “Coder Agent”가 문제를 해결하기 위한 함수를 생성할 수 있습니다. 별도의 “Critic Agent”는 보안 취약점, 스타일 가이드 위반, 효율성을 위해 코드를 검토합니다. 만약 안전하지 않은 라이브러리를 사용한다면 코드를 거부하고, 사람이 보기 전에 다시 작성하도록 강제합니다.

9. Plan-and-Execute: 계획 후 실행

문제 상황

에이전트에게 “AI의 역사를 조사하고 보고서를 작성해”라고 하면, 반응형 에이전트는 즉시 “AI 역사”를 검색하기 시작하고, 위키피디아 링크에 정신이 팔려 엉성한 요약을 작성할 수 있습니다. 이는 청사진 없이 집을 짓는 것과 같습니다.

해결책

Plan-and-Execute 패턴은 어떤 행동을 하기 전에 “계획 단계”를 강제합니다:

Plan (계획): “1단계: 1950-1980년 검색. 2단계: 1980-2000년 검색. 3단계: 보고서 개요 작성. 4단계: 작성.”
Execute (실행): 계획을 엄격하게 따름

이는 “삼천포로 빠지는 것(rabbit holes)”을 줄이고 사용자 요청의 모든 부분이 처리되도록 보장합니다.

실제 사례: 법률 계약 검토

로펌이 AI를 사용하여 100페이지 분량의 합병 계약서를 검토할 때, 에이전트는 1페이지부터 읽기 시작하지 않습니다. 먼저 계획을 세웁니다: “1. 모든 면책 조항 식별. 2. 표준 책임 한도와 상호 참조. 3. 편차 표시. 4. 위험 요약.” 이러한 구조적 접근 방식은 중요한 섹션을 건너뛰지 않도록 보장합니다.

10. RAG: 개인 데이터로 추론 강화하기

문제 상황

LLM은 공개 인터넷 데이터로 훈련되었습니다. 대통령이 누구인지는 알지만, 회사의 “3분기 매출 보고서”나 개인적인 “회의록”은 모릅니다. 이에 대해 물어보면 모델은 “모른다”고 하거나 환각(hallucinate)을 일으킬 것입니다.

해결책

RAG (Retrieval-Augmented Generation)는 모델에게 “오픈 북” 시험을 보게 하는 것과 같습니다:

Retrieve (검색): 시스템은 개인 데이터베이스에서 질문과 관련된 특정 문서를 찾음
Augment (증강): 이 텍스트를 프롬프트에 붙여넣음
Generate (생성): 모델은 그 텍스트를 사용하여 질문에 답함

이는 모델의 일반적인 지능과 사용자의 특정 지식 사이의 격차를 해소합니다.

실제 사례: Morgan Stanley

Morgan Stanley는 재무 고문들이 은행의 방대한 연구 보고서 라이브러리에 즉시 액세스할 수 있도록 RAG 기반의 내부 AI 비서를 구축했습니다. 수천 개의 PDF를 수동으로 검색하는 대신, 고문은 “반도체 산업에 대한 우리의 전망은 무엇인가?”라고 물을 수 있고, 시스템은 관련 내부 분석을 검색하여 요약된 답변을 생성합니다.

11. Function Calling: 유효한 도구 호출 생성하기

문제 상황

LLM은 “5와 10의 합을 계산할게”라고 말할 수 있습니다. 이는 사람이 읽을 수는 있지만 컴퓨터 프로그램은 이 문장을 실행할 수 없습니다. 컴퓨터는 add(5, 10)이 필요합니다. 엄격한 형식이 없으면 에이전트의 의도가 번역 과정에서 손실됩니다.

해결책

Function Calling은 모델이 특정 스키마와 일치하는 구조화된 형식(JSON 등)으로 데이터를 출력하도록 강제합니다:

Schema (스키마): function add(a: int, b: int)를 정의
Output (출력): 모델은 {"name": "add", "arguments": {"a": 5, "b": 10}}를 생성
Execution (실행): 시스템은 이 JSON을 파싱하고 코드를 안정적으로 실행

실제 사례: HubSpot CRM 통합

HubSpot은 사용자가 채팅을 통해 CRM과 상호 작용할 수 있도록 Function Calling을 사용합니다. 사용자가 “john@example.com의 John Doe에 대한 새 연락처를 만들어줘”라고 말하면, LLM은 구조화된 함수 호출 create_contact(name="John Doe", email="john@example.com")을 생성하여 백엔드 시스템이 실제로 데이터베이스를 업데이트합니다.

12. Reflection: 같은 실수 반복 방지

문제 상황

광기란 같은 일을 반복하면서 다른 결과를 기대하는 것입니다. 단순한 에이전트는 상태가 없습니다(stateless). 수학 문제를 한 번 틀리면, 실패했다는 것을 “모르기” 때문에 두 번째에도 똑같은 방식으로 실패할 가능성이 높습니다.

해결책

Reflection은 “Self-Review(자기 검토)” 단계를 추가합니다:

Attempt (시도): 에이전트가 문제 해결을 시도
Critique (비평): 에이전트가 결과를 봄: “잠깐, 답이 음수인데 양수여야 해.”
Retry (재시도): 에이전트는 발견된 오류를 수정하도록 명시적으로 지시받아 다시 시도

이는 “멍청한” 루프를 “학습하는” 루프로 바꿉니다.

실제 사례: Writer 플랫폼

Writer는 콘텐츠 생성 워크플로우에서 Reflection을 사용합니다. 사용자가 특정 브랜드 가이드라인(예: “수동태 금지”)을 따라야 하는 블로그 게시물을 요청하면, 에이전트가 초안을 생성한 다음 “Reflector” 단계가 가이드라인에 대해 초안을 확인합니다. 수동태가 발견되면, 사용자에게 보여주기 전에 해당 문장을 다시 작성하도록 지시합니다.

13. ReAct (Reason & Act): 투명한 추론 과정

문제 상황

에이전트가 단순히 “‘Apple’ 검색”을 출력한다면, 왜 그런지 알 수 없습니다. 과일을 찾는 걸까요, 아니면 회사를 찾는 걸까요? 실수를 하더라도 “사고 과정”이 모델의 신경망 가중치 안에 숨겨져 있기 때문에 디버깅할 수 없습니다.

해결책

ReAct는 모델이 모든 “Action(행동)” 전에 “Thought(생각)”를 출력하도록 강제합니다:

Thought: “사용자가 주가에 대해 물었으므로 ‘Apple’은 AAPL 회사를 의미한다.”
Action: search_stock("AAPL")

이는 에이전트의 행동을 투명하고 해석 가능하게 만들며 논리적 비약이 발생할 가능성을 줄입니다.

실제 사례: 사이버 보안 위협 사냥

보안 분석가는 ReAct 기반 에이전트를 사용하여 경고를 조사합니다. 단순히 스크립트를 실행하는 대신, 에이전트는 추론을 기록합니다: “Thought: IP 주소가 알려진 악성 블록에서 왔다. 내부 장치가 이 IP와 통신했는지 확인해야 한다. Action: query_firewall_logs(ip).” 이 감사 추적(audit trail)은 규정 준수와 나중에 인간 분석가가 사건을 이해하는 데 매우 중요합니다.

14. Chain of Thought (CoT): 단계별 추론

문제 상황

LLM은 계산을 하지 않고 답을 맞히려는 학생과 같습니다. “사과 3개가 있는데 2개를 더 사고 1개를 먹으면 몇 개가 남지?”라고 물으면, 모델은 숫자 3과 2를 보고 “5”라고 추측할 수 있습니다.

해결책

Chain of Thought는 모델이 “풀이 과정”을 보여주도록 강제합니다:

Prompt: “단계별로 생각해 보자.”
Output: “3개로 시작. 2개 구매 -> 3+2=5. 1개 먹음 -> 5-1=4. 답은 4.”

중간 단계를 생성함으로써 모델은 최종 답변의 근거를 논리에 두게 되어 계산 및 추론 오류를 크게 줄입니다.

실제 사례: 재무 예측

은행의 AI 에이전트에게 “1~3분기 추세를 기반으로 4분기 수익을 추정해줘”라고 요청할 때, Chain of Thought를 사용하여 단계를 명시적으로 나열합니다: “1. 1분기에서 3분기까지의 평균 성장률 계산. 2. 4분기의 계절적 요인 식별. 3. 3분기 수치에 성장률 적용. 4. 계절성 조정.” 이를 통해 최종 수치가 사람이 검증할 수 있는 논리적 과정에서 도출되었음을 보장합니다.

15. Context Selection: 효율적인 컨텍스트 관리

문제 상황

LLM은 제한된 “Context Window”를 가지고 있습니다. 하나의 특정 질문에 답하기 위해 500페이지짜리 책 전체를 프롬프트에 쏟아부으면, 모델은 압도당하고 비용은 증가하며 정확도는 떨어집니다(“Lost in the Middle” 현상).

해결책

Context Selection은 “짐을 가볍게 싸는” 기술입니다:

Filter (필터): 검색이나 임베딩을 사용하여 500페이지 중 가장 관련성이 높은 3페이지만 찾음
Inject (주입): 그 3페이지만 프롬프트에 넣음
Result (결과): 모델은 주의 산만 없이 올바른 정보에 집중

실제 사례: DoorDash 고객 지원

지원 에이전트가 특정 주문에 대한 질문에 답해야 할 때, 고객의 5년치 주문 내역 전체를 로드하지 않습니다. 시스템은 Context Selection을 사용하여 현재 활성 주문과 최근 3건의 상호 작용에 대한 데이터만 검색합니다. 이를 통해 LLM은 2019년의 피자 주문에 주의를 뺏기지 않고 “누락된 항목” 불만을 해결하는 데 필요한 정보만 정확하게 확보할 수 있습니다.

16. Semantic Memory: 지속되는 전문 지식

문제 상황

오늘 에이전트에게 “우리 회사 색상은 파란색과 흰색이야”라고 가르치고, 내일 새로운 세션을 시작하면 표준 에이전트는 모든 것을 잊어버립니다. 이는 매일 새로운 직원을 고용하는 것과 같습니다.

해결책

Semantic Memory는 지식을 영구적으로 지속되는 데이터베이스(주로 벡터 기반)에 저장합니다:

Storage (저장): “회사 색상: 파란색, 흰색”이 저장됨
Retrieval (검색): “로고는 어떻게 생겨야 해?”라고 물으면, 에이전트는 기억을 검색하여 색상 정보를 찾음
Result (결과): 에이전트는 더 많은 지식을 축적함에 따라 시간이 지날수록 “더 똑똑해”짐

실제 사례: Bell Canada

Bell은 내부 “Knowledge Assistant”를 구동하기 위해 Semantic Memory를 사용합니다. 수천 페이지의 기술 매뉴얼, HR 정책, 설치 가이드를 벡터 데이터베이스에 인덱싱했습니다. 현장 기술자가 “모델 X의 광 네트워크 터미널을 어떻게 재설정해?”라고 물으면, 에이전트는 그 매뉴얼이 5년 전에 업로드되었더라도 장기 기억에서 정확한 절차를 검색합니다.

17. Tool Use: 말하는 것에서 행동하는 것으로

문제 상황

“1단계: 오븐을 켜세요”라고 말하는 “요리 도우미”는 도움이 됩니다. 하지만 “오븐을 켜야 합니다”라고 말하는 “스마트 홈 에이전트”는 짜증납니다. 당신은 에이전트가 직접 하기를 원합니다. 텍스트 전용 모델은 상자 안에 갇혀 있습니다. 말할 수는 있지만 만질 수는 없습니다.

해결책

Tool Use는 에이전트에게 “손”을 줍니다:

Capability (능력): 에이전트는 turn_on_oven() 함수를 가지고 있음
Action (행동): 텍스트를 출력하는 대신, 해당 함수를 트리거하는 명령을 출력
Result (결과): 오븐이 실제로 켜짐

실제 사례: Klarna 고객 서비스

Klarna의 AI 에이전트는 사용자에게 “앱에서 청구서를 확인할 수 있습니다”라고 말만 하지 않습니다. 채팅 내에서 직접 청구서 세부 정보를 불러오거나, 지불 기한을 연장하거나, 환불 절차를 시작할 수 있는 도구에 액세스하여 사람의 개입 없이 사용자의 문제를 처음부터 끝까지 해결합니다.

18. Episodic Memory: 대화 맥락 기억하기

문제 상황

LLM은 고정된 컨텍스트 윈도우를 가지고 있습니다. 대화가 길어지면 앞부분이 잘려 나갑니다. 처음에 “내 이름은 Tom이야”라고 말했더라도, 20분 후에 에이전트가 “누구세요?”라고 물을 수 있습니다.

해결책

Episodic Memory는 세션의 일기나 로그와 같습니다:

Recording (기록): 주요 이벤트를 저장: “사용자가 오전 10시에 이름이 Tom이라고 말함.”
Recall (회상): 답변하기 전에 에이전트는 일기를 확인
Result (결과): “이름이 Tom이라고 하셨던 것을 기억합니다.”

실제 사례: 개인화된 쇼핑 도우미

고객이 월요일에 쇼핑 봇과 채팅하며 “등산화를 찾고 있어”라고 말하고, 금요일에 다시 와서 “그거 10사이즈 있어?”라고 물으면, 에이전트는 Episodic Memory를 사용하여 “그거”가 이전에 논의된 등산화를 의미한다는 것을 기억해내어 쇼핑 경험을 매끄럽게 이어갑니다.

19. Delegation: 작업 분담으로 병목 해소

문제 상황

하나의 “슈퍼 에이전트”가 코드 작성, 로고 디자인, 마케팅 문구 작성을 동시에 하려고 하면 혼란스러워하거나 컨텍스트 공간이 부족해질 것입니다. 이는 CEO가 회사의 모든 일을 하려는 것과 같습니다.

해결책

Delegation은 업무를 나눕니다:

Manager (관리자): “코더, 앱을 만들어. 디자이너, 로고를 만들어.”
Workers (작업자): 코더와 디자이너는 각자의 업무에 집중하여 병렬로 작업
Result (결과): 각 에이전트가 전문화되어 있기 때문에 실행 속도가 빠르고 품질이 높음

실제 사례: HR 온보딩 자동화

“온보딩 오케스트레이터” 에이전트는 전문 하위 에이전트에게 작업을 위임합니다. “IT 에이전트”에게 노트북과 이메일을 프로비저닝하도록 지시하고, “급여 에이전트”에게 은행 세부 정보를 설정하도록 하며, “교육 에이전트”에게 오리엔테이션 세션을 예약하도록 합니다. 이 하위 에이전트들은 병렬로 작업하여 신규 입사자가 첫날까지 완벽하게 준비되도록 보장합니다.

20. Tree of Thought: 다양한 가능성 탐색

문제 상황

표준 에이전트는 “탐욕적(Greedy)”입니다. 좋아 보이는 첫 번째 단어를 선택합니다. “잠깐, 내가 이 말을 하면 나중에 곤란해질 텐데”라고 멈춰서 생각하지 않습니다. 바로 다음 수만 보고 체스를 두는 것과 같습니다.

해결책

Tree of Thought는 에이전트가 미래를 시뮬레이션할 수 있게 해줍니다:

Branching (분기): “A를 하면 X가 발생해. B를 하면 Y가 발생해.”
Evaluation (평가): “Y는 나빠 보여. X가 좋아 보여. A를 선택할래.”
Result (결과): 막다른 골목을 피하는 더 똑똑하고 전략적인 결정

실제 사례: 공급망 물류

운송 경로가 막혔을 때(예: 수에즈 운하), 물류 AI는 Tree of Thought를 사용하여 대안을 탐색합니다. “분기 A: 항공 화물(빠르지만 비쌈). 분기 B: 아프리카 우회(느리지만 저렴). 분기 C: 대기.” 인간 관리자에게 최적의 전략을 추천하기 전에 각 선택이 배송 시간, 비용, 창고 재고 수준에 미치는 다운스트림 효과를 시뮬레이션합니다.

마무리: AI 에이전트 설계의 핵심 원칙

지금까지 살펴본 20가지 개념을 정리하면, AI 에이전트 설계의 핵심 원칙을 다음과 같이 도출할 수 있습니다:

1. 피드백 루프의 중요성

Agent Loop, Reflection, Critic 패턴은 모두 “확인-수정” 사이클의 중요성을 강조합니다. 맹목적인 실행보다 지속적인 피드백이 더 나은 결과를 만듭니다.

2. 구조화된 추론

Chain of Thought, ReAct, Plan-and-Execute는 에이전트가 “생각하는 과정”을 명시적으로 드러내도록 합니다. 이는 디버깅을 쉽게 하고, 신뢰성을 높이며, 오류를 줄입니다.

3. 비선형적 탐색

Graph of Thought, Tree of Thought는 단순한 선형 추론을 넘어 다양한 가능성을 탐색하고 최적의 경로를 찾는 전략입니다.

4. 기억과 맥락 관리

RAG, Semantic Memory, Episodic Memory, Context Selection은 모두 “올바른 정보를 올바른 때에” 제공하는 문제를 해결합니다.

5. 실행 능력

Tool Use, Function Calling은 에이전트를 “말하는 존재”에서 “행동하는 존재”로 전환시킵니다.

6. 안전과 통제

Safety Guardrails, MCP는 강력한 에이전트가 안전하고 예측 가능하게 작동하도록 보장합니다.

7. 협업과 분산

Orchestration, Delegation은 복잡한 작업을 여러 전문화된 에이전트로 나누어 효율성과 품질을 높입니다.

AI 에이전트 기술은 빠르게 발전하고 있으며, 이러한 개념들은 실제 기업 환경에서 이미 활용되고 있습니다. 이 글이 AI 에이전트의 핵심 개념을 이해하는 데 도움이 되었기를 바랍니다.