AI 에이전트 완전정복 가이드

— 누구나 오늘 바로 자신만의 AI 에이전트를 만들 수 있다 —

원문 출처: @hooeem on X | 정리·재구성: 한국어 완전 해설판
참고 자료: Anthropic, OpenAI 공식 문서, 전문가 자료 종합
작성일: 2026년 3월 29일

---

들어가며: 이 가이드가 존재하는 이유

인터넷에는 AI 에이전트에 관한 수많은 단편적인 정보들이 흩어져 있다. Anthropic의 공식 문서, OpenAI의 SDK 가이드, 각종 전문가들의 블로그 포스트들. 하지만 “나 같은 일반인도 오늘 당장 에이전트를 만들 수 있다”는 전제 하에 처음부터 끝까지 안내해 주는 통합된 과정(full course)은 존재하지 않았다.

이 가이드는 바로 그 공백을 채우기 위해 만들어졌다. Anthropic, OpenAI, 그리고 수많은 전문가들의 자료를 한데 모아 재구성한 이 문서를 끝까지 읽고 나면, 당신은 오늘 안에 첫 번째 AI 에이전트를 실제로 작동시킬 수 있어야 한다.

에이전트를 만드는 것 자체가 목적이어서는 안 된다. 에이전트는 반드시 이유가 있어야 한다. 당신의 업무 흐름을 자동화하든, 리서치를 도와주든, 콘텐츠를 생성하든 — 그 이유가 명확할 때 비로소 에이전트는 진정한 가치를 발휘한다.

이 가이드는 총 8개의 섹션으로 구성되어 있다:

1. 에이전트의 작동 원리
2. 다섯 가지 핵심 워크플로 패턴
3. 에이전트 만들기 (본론)
4. 도구(Tools) 활용하기
5. 에이전트에게 메모리 부여하기
6. 에이전트를 실제로 작동하게 만들기
7. 멀티 에이전트
8. 마무리 및 핵심 정리

---

섹션 1: 에이전트의 작동 원리

1.1 핵심 루프 — 모든 에이전트의 공통 구조

아래 그림에 표현된 흐름은 현존하는 모든 AI 에이전트의 근본적인 작동 방식이다.

사용자 입력
    ↓
LLM이 생각한다 (추론)
    ↓
LLM이 결정한다: "바로 응답할까, 아니면 도구를 호출할까?"
    ↙              ↘
바로 응답         도구 실행 (검색, 계산, API 호출 등)
(최종 답변)           ↓
                 결과를 다시 LLM에게 피드백
                      ↓
                 LLM이 다시 생각한다
                      ↓
                    반복 (REPEAT)

이것이 전부다. 복잡해 보이지만 본질은 단순하다.

• LLM(대형 언어 모델) 은 “뇌(brain)”의 역할을 한다. 추론하고 판단한다.
• 도구(Tools) 는 “손(hands)”의 역할을 한다. 실제 행동을 수행한다 (계산기, 웹 검색, 파일 입출력 등).
• 메모리(Memory) 는 “메모장(notepad)”의 역할을 한다. 지금까지 일어난 일을 기록한다.

LangGraph, CrewAI, Anthropic SDK, OpenAI Agents SDK 등 어떤 프레임워크를 사용하든, 이 핵심 루프 자체는 바뀌지 않는다. 프레임워크는 이 루프를 편리하게 감싸주는 추상화(abstraction)일 뿐, 본질을 바꾸지는 않는다.

1.2 증강된 LLM (Augmented LLM)

일반적인 LLM은 텍스트를 받아서 텍스트를 출력한다. 그것이 전부다. 하지만 증강된 LLM은 세 가지 능력이 추가된다.

① 도구 (Tools)

모델이 직접 호출할 수 있는 함수들이다. 계산기, 데이터베이스, API, 파일 조작 등 거의 모든 것이 도구가 될 수 있다. Anthropic은 input_schema 형태로, OpenAI는 parameters가 포함된 function 객체 형태로 도구를 JSON 스키마를 통해 정의한다.

② 검색(Retrieval)

외부 소스에서 관련 정보를 끌어오는 능력이다. 검색 엔진, 문서, 벡터 데이터베이스 등을 활용한다. 모델이 학습 데이터에 없는 최신 정보나 개인화된 정보를 활용할 수 있게 해준다.

③ 메모리 (Memory)

대화 기록이나 다른 형태의 영속적 저장소를 통해 상호작용 간에 정보를 유지하는 능력이다. “이전에 무슨 이야기를 했는지” 기억하는 것이 메모리의 핵심이다.

1.3 워크플로 vs. 에이전트: 무엇을 선택해야 할까?

이 둘의 구분은 매우 중요하다. 접근 방식을 선택하는 데 직접적인 영향을 미치기 때문이다.

구분	워크플로 (Workflow)	에이전트 (Agent)
실행 방식	결정론적 (Deterministic)	동적 (Dynamic)
제어 주체	코드가 실행을 제어	LLM이 다음 단계를 결정
재현성	동일 입력 → 동일 경로	동일 입력 → 다양한 경로 가능
적합한 작업	단계가 고정된 잘 정의된 작업	열린 결말의 복잡한 작업
비용	저렴 (LLM 호출 횟수 적음)	비쌈 (LLM 호출 반복)

핵심 조언: 먼저 단순한 워크플로로 시작하라. 그것이 부족하다고 느껴질 때 비로소 자율적인 에이전트로 ‘졸업’하는 것을 고려하라.

---

섹션 2: 다섯 가지 핵심 워크플로 패턴

믿기 어렵겠지만, 대부분의 문제는 완전한 자율성(full autonomy)이 없어도 해결할 수 있다. Anthropic이 문서화하고 업계가 광범위하게 채택한 다섯 가지 패턴이 일반적인 사례의 대부분을 커버한다. 각 패턴은 증강된 LLM을 기반으로 한다.

패턴 1: 프롬프트 체이닝 (Prompt Chaining)

개념: 작업을 순차적인 단계로 분해한다. 각 LLM 호출은 이전 호출의 출력을 처리한다. 단계 사이에 품질을 검증하는 프로그래매틱 “게이트(gate)”를 추가할 수 있다.

적합한 상황: 고정된 하위 작업으로 깔끔하게 분해되는 작업. 각 LLM 호출을 단순화함으로써 속도 대신 정확도를 얻는다.

활용 예시:

• 마케팅 카피를 생성한 후 번역하기
• 개요를 작성하고 → 핵심 주제 포함 여부를 검증하고 → 전체 문서를 작성하기

[입력] → [LLM: 초안 작성] → [검증 게이트] → [LLM: 번역] → [검증 게이트] → [출력]

패턴 2: 라우팅 (Routing)

개념: 들어오는 입력을 분류한 후 특화된 핸들러로 라우팅한다. 각 핸들러는 자체적으로 최적화된 프롬프트를 가진다.

적합한 상황: 입력의 카테고리에 따라 근본적으로 다른 처리가 필요한 경우. 고객 서비스 분류(triage)가 전형적인 예시다.

[입력] → [분류기 LLM] → 결제 문의? → [결제 전문 핸들러]
                      → 기술 문의? → [기술 전문 핸들러]
                      → 영업 문의? → [영업 전문 핸들러]

패턴 3: 병렬화 (Parallelisation)

개념: 여러 LLM 호출을 동시에 실행한다. 두 가지 하위 방식이 있다.

• 섹션닝 (Sectioning): 작업을 독립적인 하위 작업으로 나눠 병렬 처리
• 보팅 (Voting): 동일한 작업을 여러 번 실행하고 결과를 집계하여 더 높은 신뢰도 확보

적합한 상황: 하위 작업이 독립적일 때(섹션닝) 또는 중요한 결정에 합의가 필요할 때(보팅).

[입력] → [LLM 작업 1] ↘
        → [LLM 작업 2] → [집계/통합] → [출력]
        → [LLM 작업 3] ↗

패턴 4: 오케스트레이터-워커 (Orchestrator-Workers)

개념: 중앙 LLM(오케스트레이터)이 동적으로 작업을 분해하고 하위 작업을 워커 LLM들에게 위임한다. 병렬화와 달리, 하위 작업이 미리 정해져 있지 않고 오케스트레이터가 런타임에 결정한다.

적합한 상황: 사전에 구조를 예측할 수 없는 복잡한 작업. 여러 파일에 걸친 코드 생성, 리서치 작업, 보고서 작성 등.

[입력] → [오케스트레이터 LLM]
              ↓ (동적으로 작업 분해)
         [워커 1] [워커 2] [워커 3]
              ↓
         [결과 통합] → [출력]

패턴 5: 평가자-최적화자 (Evaluator-Optimiser)

개념: 하나의 LLM이 출력을 생성하고, 다른 LLM이 그것을 평가하고 피드백을 제공한다. 평가가 실패하면 피드백이 다시 루프를 돌린다. 품질 기준이 충족될 때까지 반복한다.

적합한 상황: 명확한 평가 기준이 존재하고 반복적 정제가 측정 가능한 가치를 더하는 경우. 번역, 코드 생성, 글쓰기 작업 등.

[입력] → [생성 LLM: 출력물 생성]
              ↓
         [평가 LLM: 품질 검사]
              ↓
         통과? → YES → [최종 출력]
                → NO  → [피드백] → (다시 생성 LLM으로)

---

섹션 3: 에이전트 만들기 (본론)

드디어 핵심 파트다. “XYZ를 하는 에이전트를 원한다”는 생각을 실제로 구현하려면 어떻게 해야 할까?

3.1 가장 쉬운 사고 프레임

에이전트 설계를 다음 다섯 단계로 생각하라:

1. 할 일을 적는다
2. 어떤 도구가 필요한지 결정한다
3. 모델이 어떻게 행동해야 할지 알려준다
4. 실제 예시 5개로 테스트한다
5. 실패할 때만 복잡도를 추가한다

수많은 프레임워크를 마스터할 필요가 없다. 첫 번째 에이전트를 위한 최선의 출발점은 다음 두 가지 중 하나다.

• Anthropic: 도구, 파일, 셸 명령, 웹 액션, 강력한 코딩 워크플로를 갖춘 유능한 오퍼레이터처럼 작동하는 에이전트를 원할 때
• OpenAI: 깔끔한 개발자 SDK, 호스팅된 도구, 핸드오프, 가드레일, 프로덕션까지의 간단한 경로를 원할 때

3.2 에이전트 설계의 4가지 핵심 질문

에이전트를 만들기 전에 반드시 이 네 가지 질문에 먼저 답하라.

질문 1: 결과물이 무엇인가?

에이전트가 실제로 무엇을 생산해야 하는가?

• “주제를 리서치하고 요약본을 작성한다”
• “내 노트를 읽고 플래시카드로 변환한다”
• “지원 요청을 보고 올바르게 라우팅한다”
• “제품들을 비교하고 최선의 옵션을 알려준다”
• “내 콘텐츠를 검토하고 내 목소리로 다시 쓴다”

질문 2: 어떤 정보가 필요한가?

웹 검색이 필요한가? 파일이 필요한가? 데이터베이스가 필요한가? 스프레드시트? CRM? 아니면 사용자의 메시지만으로 충분한가?

질문 3: 어떤 행동이 허용되는가?

• 단순히 답변만 할 수 있는가?
• 검색할 수 있는가?
• 파일을 편집할 수 있는가?
• 이메일을 보낼 수 있는가?
• 코드를 작성할 수 있는가?
• 커스텀 함수를 호출할 수 있는가?

질문 4: 따라야 할 규칙은 무엇인가?

어조, 형식, 제약 조건, 안전 규칙, 불확실할 때의 행동 방침, “좋은 결과물”이란 무엇인지.

이 네 가지 질문에 명확하게 답할 수 있다면, 대부분 하루 안에 에이전트의 첫 번째 버전을 만들 수 있다.

3.3 AI를 활용해서 에이전트를 설계하는 방법

코딩에 들어가기 전에 Claude나 ChatGPT에게 다음 프롬프트를 제시하라. 이것이 가장 실용적인 첫 번째 단계다.

나는 AI 에이전트를 만들고 싶다.

내 목표:
[원하는 것을 설명]

사용자가 이런 것들을 물어볼 것이다:
[현실적인 예시 5개 추가]

에이전트가 접근할 수 있어야 하는 것:
[웹 검색 / 파일 / 계산기 / 커스텀 API / 그 외 없음]

반드시 해야 하는 것:
[협상 불가능한 규칙 목록]

절대 하지 말아야 하는 것:
[경계 목록]

다음으로 변환해 주세요:
1. 명확한 에이전트 스펙
2. 시스템 프롬프트
3. 도구 목록
4. 1차 버전 로드맵
5. 테스트 케이스 10개

이 단 하나의 프롬프트가 막연한 아이디어를 실제로 구축 가능한 계획으로 바꿔줄 수 있다.

3.4 에이전트 설계의 공식

매번 이 구조를 사용하라:

에이전트 = 역할 + 목표 + 도구 + 규칙 + 출력 형식

예시:

• 역할: 크립토 프로젝트를 위한 리서치 어시스턴트
• 목표: 정확한 정보를 찾아 명확하게 요약한다
• 도구: 웹 검색, 파일 검색, 계산기
• 규칙: 출처를 인용하고, 추측하지 않으며, 불확실성을 명시한다
• 출력 형식: 요약 + 리스크 + 기회 + 최종 판단

이것이 대부분의 유용한 에이전트의 토대다.

3.5 초보자를 위한 다섯 가지 에이전트 유형

처음이라면 멀티 에이전트 스웜(swarm)을 만들려 하지 마라. 다음 다섯 가지 중 하나로 시작하라.

---

유형 1: 리서치 에이전트 (Research Agent)

에이전트가 정보를 수집하고 요약해 주길 원할 때 사용한다.

활용 예시:

• “발목 염좌를 위한 최고의 재활 운동을 리서치해줘”
• “특정 크립토 프로토콜의 최신 업데이트를 찾아줘”
• “노트북 세 가지를 비교해줘”

필요한 것:

• 웹 검색
• 자신의 문서를 활용하고 싶다면 파일 검색
• 명확한 출력 형식

---

유형 2: 콘텐츠 에이전트 (Content Agent)

에이전트가 글을 쓰고, 다시 쓰고, 요약하거나 콘텐츠를 변환해 주길 원할 때 사용한다.

활용 예시:

• “내 노트를 뉴스레터로 바꿔줘”
• “이것을 내 브랜드 목소리로 다시 써줘”
• “이 미팅 전사(transcript)를 요약해줘”

필요한 것:

• 주로 강력한 시스템 프롬프트
• 선택적으로 파일 접근
• 선호하는 스타일의 예시

---

유형 3: 워크플로 에이전트 (Workflow Agent)

에이전트가 반복 가능한 비즈니스 프로세스를 따르길 원할 때 사용한다.

활용 예시:

• “지원 티켓을 분류해줘”
• “리드를 올바른 카테고리로 라우팅해줘”
• “양식 제출을 확인하고 응답 초안을 작성해줘”

필요한 것:

• 명확한 카테고리
• 규칙
• 때로는 커스텀 도구나 API 호출

---

유형 4: 개인 지식 에이전트 (Personal Knowledge Agent)

에이전트가 내 문서를 사용해서 질문에 답해 주길 원할 때 사용한다.

활용 예시:

• “내 PDF만 사용해서 답해줘”
• “내 노트를 검색하고 이 주제를 설명해줘”
• “이 고객에 대한 모든 언급을 찾아줘”

필요한 것:

• 파일 검색 또는 RAG(검색 증강 생성)
• 제공된 자료에 근거하도록 하는 명확한 지시

---

유형 5: 오퍼레이터 에이전트 (Operator Agent)

에이전트가 환경 내에서 실제 행동을 취하길 원할 때 사용한다.

활용 예시:

• “이 파일들을 읽고 편집해줘”
• “웹을 검색하고, 결과를 모아서 보고서를 저장해줘”
• “셸 명령을 실행하고 코드 디버깅을 도와줘”

필요한 것:

• 도구
• 권한
• 강력한 안전 경계

---

3.6 Anthropic으로 첫 에이전트 만들기

Anthropic의 에이전트 도구는 모델이 도구를 사용하고 환경 내에서 작동하길 원할 때 특히 유용하다. Claude Code는 2025년 2월에 출시되었으며, Claude Code SDK는 이후 Claude Agent SDK로 이름이 변경되었다. 2026년 3월 기준 최신 릴리즈는 v0.1.50이다.

Anthropic을 먼저 선택하면 좋은 경우:

• 파일을 읽고, 쓰고, 편집해야 할 때
• 셸 명령을 사용해야 할 때
• 웹을 검색해야 할 때
• MCP 도구를 사용해야 할 때
• 코딩 및 기술적인 작업에 잘 맞아야 할 때
• 단계적으로 작동하는 유능한 어시스턴트처럼 느껴져야 할 때

Anthropic으로 실제로 하는 것:

1. Claude에게 역할을 부여한다
2. Claude에게 도구를 준다
3. 작업이 완료될 때까지 Claude가 루프를 돌게 한다

예시: 리서치-요약 에이전트

목표: “주제를 리서치하고 깔끔한 보고서를 작성해 주는 에이전트”

에이전트 설계:

• 역할: 수석 리서치 어시스턴트
• 목표: 정확한 정보를 찾아 명확하게 요약
• 도구: 웹 검색, 선택적으로 파일 접근
• 규칙: 출처 인용, 불확실할 때는 명시, 간결하게 유지
• 출력: 글머리 요약 + 핵심 리스크 + 결론

SYSTEM_PROMPT = '''
당신은 신중한 리서치 어시스턴트입니다.

당신의 역할은 사용자가 주제를 정확하게 리서치하도록 돕는 것입니다.
필요할 때는 도구를 사용하세요.
추측하지 마세요.
정보가 불확실하거나 불완전하다면, 명확하게 그렇게 말하세요.
항상 다음을 생산하세요:
1. 요약
2. 핵심 발견
3. 리스크 또는 불확실성
4. 최종 결론
'''

사용자가 이렇게 물어볼 수 있다:

• “최신 AI 에이전트 SDK를 리서치해줘”
• “초보자 에이전트 구축에 Anthropic과 OpenAI를 비교해줘”
• “강력한 출처 세 개를 찾아 요약해줘”

이것이 이미 실제 에이전트다.

---

3.7 OpenAI로 첫 에이전트 만들기

OpenAI는 2025년 3월 11일 Responses API, 웹 검색·파일 검색·컴퓨터 사용을 위한 내장 도구와 함께 Agents SDK를 출시했다. Python 패키지 openai-agents는 2026년 3월 기준 v0.13.1이다.

OpenAI를 먼저 선택하면 좋은 경우:

• 매우 깔끔한 에이전트 API를 원할 때
• 쉬운 커스텀 함수 도구가 필요할 때
• 내장 호스팅 도구를 원할 때
• 전문화된 에이전트 간 핸드오프가 필요할 때
• 가드레일과 추적이 필요할 때
• 프로토타입에서 프로덕션까지 원활한 경로를 원할 때

예시: 지원 분류 에이전트

from agents import Agent, Runner

agent = Agent(
    name="Support Triage Agent",
    instructions="""
당신은 고객 요청을 분류합니다.
정확히 하나의 카테고리를 선택하세요:
- billing (결제)
- technical (기술)
- sales (영업)

다음을 응답하세요:
1. 카테고리
2. 이유를 한 문장으로 설명
""",
)

result = Runner.run_sync(agent, "이번 달 구독 비용이 두 번 청구되었어요.")
print(result.final_output)

예시: 커스텀 도구 추가하기

from agents import Agent, Runner, function_tool

def calculate(expression: str) -> str:
    import math
    allowed = {k: v for k, v in math.__dict__.items() if not k.startswith("__")}
    return str(eval(expression, {"__builtins__": {}}, allowed))

agent = Agent(
    name="Math Helper",
    instructions="수학 문제를 해결하도록 도와주세요. 필요할 때 계산기 도구를 사용하세요.",
    tools=[calculate],
)

result = Runner.run_sync(agent, "10000에 연 5% 성장률을 8년 적용하면 복리 성장은 얼마입니까?")
print(result.final_output)

이제 에이전트는 단순히 채팅하는 것이 아니라 도구를 통해 실제 행동을 취하고 있다.

---

3.8 에이전트를 실제로 원하는 대로 작동시키는 커스터마이징

초보자들이 주로 실수하는 지점이 바로 여기다. 특화된 에이전트 대신 범용 어시스턴트를 만드는 것이다.

체크리스트:

① 역할을 좁게 만들어라

나쁜 예: “비즈니스 관련 도움을 줘”
좋은 예: “영업 통화를 액션 포인트로 요약해줘”

② 출력 형식을 정의하라

나쁜 예: “답변을 줘”
좋은 예: “반환: 요약, 근거, 리스크, 다음 단계”

③ 예시를 제공하라

어조, 구조, 분류 품질을 원한다면 예시가 큰 도움이 된다. 모델에게 이렇게 말하라:

• “좋은 출력의 예시 3개가 있습니다”
• “요청을 분류하는 방법의 예시 5개가 있습니다”

④ 필요할 때만 도구를 추가하라

노트를 다시 쓰는 것이 작업이라면 웹 검색을 추가하지 마라. 프롬프트만으로 답이 와야 한다면 파일 접근을 추가하지 마라. 도구가 많을수록 복잡도가 높아진다.

⑤ 실제 프롬프트로 테스트하라, 이상적인 것으로 하지 말고

이것만 테스트하지 말 것:
“이 기술적 문제를 분류해주세요”

이것도 테스트하라:
“계정이 고장났고 계속 청구가 되는데 어떻게 하죠”

---

3.9 첫 에이전트 구축 경로

1단계: 에이전트를 한 문장으로 설명하라
예: “거친 메모를 깔끔한 주간 뉴스레터로 바꿔주는 에이전트를 원한다.”

2단계: Claude 또는 ChatGPT에게 다음을 생성하도록 요청하라

• 에이전트 스펙
• 시스템 프롬프트
• 도구 목록
• 테스트 프롬프트 10개

3단계: 가장 작은 작동 버전을 만들어라
멀티 에이전트 설정 없이. 복잡한 메모리 없이. 필요하지 않으면 RAG도 없이.

4단계: 10개의 실제 예시로 테스트하라

5단계: 한 번에 하나씩 개선하라

• 프롬프트 → 출력 구조 → 예시 → 도구 → 메모리 → 검색

이 순서가 중요하다. 모든 것에 한꺼번에 매몰되지 마라.

3.10 피해야 할 가장 큰 실수

“만능 슈퍼 에이전트”를 만들려 하지 마라.

시작할 때 포함하지 말 것:

• 웹 검색
• 파일 검색
• 데이터베이스 접근
• 메모리
• 멀티 에이전트 핸드오프
• 복잡한 가드레일
• 커스텀 대시보드
• 20가지 도구

시작할 때 포함할 것:

• 하나의 역할
• 하나의 에이전트
• 하나의 명확한 프롬프트
• 최대 하나 또는 두 개의 도구
• 5~10개의 실제 테스트 케이스

이것이 성공하는 방법이다. 복잡하게 만들지 않는 것이 핵심이다.

---

섹션 4: 도구(Tools) 활용하기

4.1 가장 흔한 오해

대부분의 사람들이 이렇게 생각한다:
“도구가 많을수록 = 더 똑똑한 에이전트”

틀렸다.

더 좋은 도구 = 더 똑똑한 에이전트
더 적은 도구 = 더 신뢰할 수 있는 에이전트

4.2 도구에 대한 가장 단순한 사고방식

도구란 그냥 이것이다:
“AI가 혼자서는 할 수 없는 것”

예시:

• 숫자 계산
• 웹 검색
• 파일 읽기
• 이메일 보내기
• 데이터베이스 조회

4.3 도구가 필요한가? 판단하는 법

도구를 추가하기 전에 먼저 물어라:

• “모델이 추론만으로 이것에 답할 수 있는가?”
• “아니면 실제 세계 데이터나 행동이 필요한가?”

도구가 필요 없는 경우:

• “이 이메일을 다시 써줘” → 추론만으로 가능
• “이 텍스트를 요약해줘” → 추론만으로 가능
• “이 개념을 설명해줘” → 추론만으로 가능

도구가 필요한 경우:

• “지금 날씨가 어때?” → 실시간 데이터 필요
• “최신 뉴스를 검색해줘” → 웹 검색 필요
• “복리 이자를 계산해줘” → 계산기 필요
• “내 스프레드시트에서 데이터를 가져와줘” → 파일 접근 필요

핵심 규칙:

• 외부 데이터나 행동이 필요하면 → 도구 사용
• 그렇지 않으면 → 도구 추가하지 않기

4.4 AI를 활용해서 도구를 설계하는 법

나는 AI 에이전트를 만들고 있다.

내 목표:
[목표 설명]

에이전트가 해야 할 것들:
[행동 목록]

이 중 어떤 것이 도구를 필요로 하는가?
어떤 도구를 만들어야 하는가?
단순하고 최소한으로 유지하라.

반환:
1. 도구 목록
2. 도구 설명
3. 각 도구에 필요한 입력

4.5 도구를 단순하게 유지하는 법

나쁜 도구 설계:

manage_files(action, file, destination, overwrite, format, permissions)

좋은 도구 설계:

read_file(path)
write_file(path, content)
delete_file(path)

핵심 규칙: 하나의 도구 = 하나의 명확한 역할

4.6 에이전트에게 도구 사용 시점을 알려주는 법

이것이 대부분의 사람들이 실패하는 지점이다.

나쁜 예: “계산기 도구”

좋은 예: “수학이 필요할 때마다 이 도구를 사용하라. 절대 계산을 추측하지 마라.”

4.7 에이전트 실패로부터 배우기

실제 테스트를 실행하라:

• “2의 16승이 뭐야”
• “10년간 7% 성장을 계산해줘”

에이전트가:

• 도구를 사용하지 않으면 → 설명을 수정하라
• 잘못 사용하면 → 입력을 수정하라
• 환각(hallucination)을 일으키면 → 규칙을 더 엄격하게 만들어라

---

섹션 5: 에이전트에게 메모리 부여하기

5.1 두 가지 메모리 유형

사람들은 이것을 엄청나게 복잡하게 생각한다. 실은 이것만 이해하면 된다.

① 단기 메모리 (Short-term Memory): 대화

이것은 그냥: “지금까지 무슨 말이 오갔는가”

이것은 기본적으로 제공된다. 별도로 설정할 필요가 없다.

② 장기 메모리 (Long-term Memory): 외부 지식

이것은: “에이전트가 나중에 찾아볼 수 있는 것들”

예시:

• 내 노트
• PDF
• 문서
• 데이터베이스

5.2 실제로 메모리가 필요한가?

이렇게 물어라:

• 에이전트가 메시지 간에 것들을 기억해야 하는가? → YES → 단기 메모리
• 외부 문서를 사용해야 하는가? → YES → 장기 메모리
• 그 외의 경우 → 아마 메모리가 필요 없다

AI에게 결정을 도와달라고 할 수 있다:

나는 AI 에이전트를 만들고 있다.

내 목표:
[목표]

이 에이전트에게 다음이 필요한가:
1. 대화 메모리?
2. 외부 지식 (RAG)?

필요하다면 이유를 설명하라.
필요하지 않다면 이유를 설명하라.

단순하게 유지하라.

5.3 세 가지 옵션

옵션 A: 메모리 없음 (여기서 시작하라)

• 대부분의 초보자에게 최선
• 사용 사례의 70%에서 작동

옵션 B: 대화 메모리

• 대부분의 SDK에서 이미 처리됨
• 메시지를 초기화하지 않으면 됨

옵션 C: 파일 기반 메모리 (쉬운 RAG)

• 문서를 업로드
• 파일 검색 도구 사용

5.4 과잉 복잡화를 피하는 법

가장 큰 실수:

• 벡터 DB 추가
• 임베딩
• 복잡한 파이프라인

…을 필요한지도 모르는 상태에서 추가하는 것.

핵심 규칙: 에이전트가 메모리 없이 작동하면 → 추가하지 마라

---

섹션 6: 에이전트를 실제로 작동하게 만들기

6.1 왜 에이전트들이 망하는가

많은 에이전트들이 실패하는 이유는 다음 세 가지다:

• 나쁜 프롬프트
• 테스트 없음
• 비현실적인 기대

6.2 AI를 활용해서 테스트 케이스 만들기

나는 이런 목표로 AI 에이전트를 만들었다:
[목표]

현실적인 사용자 입력 15개를 만들어줘:
- 지저분한 것
- 모호한 것
- 실제 세계 스타일

다음도 포함해줘:
- 엣지 케이스
- 혼란스러운 입력
- 잘못된 입력

6.3 실제 사용자처럼 테스트하라

테스트하지 말 것: “이 결제 요청을 분류해주세요”
테스트할 것: “왜 또 청구가 된 거임 진짜”

6.4 한 번에 하나씩 수정하라

실패하면 물어라:

• 프롬프트가 불명확한가?
• 출력 형식이 모호한가?
• 도구가 빠진 게 있는가?
• 규칙이 빠진 게 있는가?

6.5 AI를 활용해서 에이전트를 디버깅하라

내 에이전트는 이렇다:

내가 물어본 것:
[입력]

나온 결과물:
[출력]

무엇이 잘못되었는가?
어떻게 고치는가?
구체적으로 말해줘.

6.6 너무 빨리 복잡하게 만들지 마라

다음을 추가하지 말 것:

• 멀티 에이전트
• 복잡한 워크플로
• 자동화 파이프라인

단순한 버전이 일관되게 작동하기 전까지는.

---

섹션 7: 멀티 에이전트

7.1 핵심 원칙: 하나로 시작하라

사람들은 이렇게 생각한다:
“에이전트가 많을수록 = 더 강력하다”

틀렸다.

항상 하나의 에이전트로 시작하라.

더 많이 추가하는 것은 다음 경우에만 고려하라:

• 작업이 명확하게 분리될 때
• 하나의 에이전트가 어려움을 겪을 때
• 역할이 매우 다를 때

7.2 멀티 에이전트가 필요한 단 세 가지 상황

① 다른 기술이 필요할 때
예: 리서치 에이전트 + 글쓰기 에이전트

② 명확한 파이프라인이 있을 때
예: 입력 → 분석 → 작성 → 출력

③ 다른 권한이 필요할 때
예: 하나의 에이전트는 데이터를 읽을 수 있고, 다른 에이전트는 행동을 실행할 수 있음

7.3 멀티 에이전트가 필요한지 AI에게 물어보는 법

나는 AI 에이전트를 만들었다.

역할은 다음과 같다:
[설명]

이것이 다음 중 무엇이어야 하는가:
1. 단일 에이전트
2. 멀티 에이전트

멀티라면:
- 어떤 역할들인가?
- 왜인가?

단순하게 유지하라.

7.4 가장 안전한 패턴

슈퍼바이저 모델:

사용자 → 메인 에이전트 → (필요하면 다른 에이전트 호출)

시작하지 말 것:

• 스웜(swarm)
• 완전 자율적인 멀티 에이전트 시스템

이것들은 쉽게 망가진다.

7.5 역할을 단순하게 유지하라

나쁜 예:
“동적 인지 레이어링을 가진 AI 전략가 에이전트”

좋은 예:
“리서치 에이전트”, “글쓰기 에이전트”

7.6 에이전트를 천천히 추가하라

시작: 1개 에이전트
그 다음: 최대 2개 에이전트
실제 이점이 보일 때만 확장하라.

---

섹션 8: 마무리 및 핵심 정리

8.1 가장 중요한 인사이트

에이전트는 개념적으로 단순하지만 운영적으로 까다롭다.

핵심 루프 — LLM이 생각하고, 도구를 호출하고, 반복한다 — 는 Python 50줄에 담길 수 있다. 실제 작업은 도구 설계, 오류 처리, 평가, 그리고 더 단순한 패턴(프롬프트 체이닝, 라우팅)이 자율적인 에이전트보다 더 나은 성능을 발휘할 때를 아는 것에 있다.

8.2 세 가지 실행 가능한 시작점

① 처음부터 에이전트를 직접 만들어보라

원시 루프를 이해하면 모든 프레임워크가 마법이 아닌 투명한 도구로 보인다. 문제를 더 빨리 디버깅하고 도구를 더 현명하게 선택할 수 있다.

② 작동하는 가장 단순한 패턴으로 시작하라

프롬프트 체인은 대부분의 멀티스텝 작업을 처리한다. 라우팅 패턴은 대부분의 분류-후-행동 워크플로를 처리한다. LLM이 실행 경로를 동적으로 결정해야 할 때만 자율적인 에이전트로 넘어가라.

③ 도구 설계와 평가에 일찍 투자하라

명확한 이름, 정밀한 설명, 구조화된 오류 메시지를 가진 잘 설계된 도구들은 모델이나 프레임워크를 바꾸는 것보다 에이전트 성능을 더 많이 향상시킨다. 그리고 20개의 좋은 테스트 케이스는 어떤 양의 수동 테스트보다 더 많은 버그를 잡을 것이다.

8.3 현재 AI 에이전트 생태계의 흐름

분야는 빠르게 움직이고 있다. MCP(Model Context Protocol)가 1년도 안 되어 보편적인 표준이 되었고, 두 주요 제공업체가 Agent SDK를 출시했으며, 매달 새로운 프레임워크들이 등장하고 있다.

하지만 이 가이드의 기본 원칙들은 안정적이다:

• 에이전틱 루프: LLM이 생각하고 → 도구를 호출하고 → 반복한다
• 다섯 가지 워크플로 패턴: 프롬프트 체이닝, 라우팅, 병렬화, 오케스트레이터-워커, 평가자-최적화자
• 좋은 도구 설계의 원칙: 단순하고, 명확하고, 목적이 하나여야 한다
• 단순하게 시작하는 훈련: 복잡도는 필요할 때만 추가한다

이것들을 마스터하면, 다음에 무엇이 오든 적응할 수 있다.

---

빠른 참조: 핵심 공식 요약

에이전트 설계 공식

에이전트 = 역할 + 목표 + 도구 + 규칙 + 출력 형식

핵심 루프

사용자 입력 → LLM 추론 → 응답 또는 도구 호출 → 결과 피드백 → 반복

도구 결정 기준

외부 데이터 또는 행동 필요? → 도구 사용
그렇지 않으면 → 도구 추가 안 함

메모리 결정 기준

메시지 간 기억 필요? → 단기 메모리
외부 문서 필요? → 장기 메모리 (RAG)
그 외 → 메모리 필요 없음

멀티 에이전트 결정 기준

항상 하나로 시작
↓
실패하거나 명확히 분리가 필요할 때만
↓
슈퍼바이저 모델 사용 (메인 에이전트 → 서브 에이전트 호출)

---

부록: AI 에이전트 관련 핵심 개념 용어 정리

용어	설명
LLM	대형 언어 모델 (Large Language Model). 에이전트의 “뇌”
Tool (도구)	LLM이 호출할 수 있는 함수. 계산기, 웹 검색, 파일 조작 등
Memory (메모리)	대화 기록 또는 외부 저장소. 단기/장기로 구분
RAG	검색 증강 생성 (Retrieval-Augmented Generation). 외부 문서 검색 후 생성
System Prompt	에이전트의 역할, 목표, 규칙을 정의하는 초기 지시문
Workflow	결정론적 실행 흐름. LLM이 경로를 결정하지 않음
Agent	LLM이 동적으로 다음 단계를 결정하는 자율적 시스템
Orchestrator	다른 LLM/에이전트를 지휘하는 중앙 LLM
Worker	오케스트레이터의 지시를 받아 하위 작업을 수행하는 LLM
MCP	Model Context Protocol. 도구 통합을 위한 표준 프로토콜
Guardrails	에이전트의 행동을 제한하는 안전 장치
Handoff	한 에이전트에서 다른 에이전트로 작업을 전달하는 것
Prompt Chaining	여러 LLM 호출을 순차적으로 연결하는 워크플로 패턴
Routing	입력을 분류하여 적절한 핸들러로 보내는 패턴
Parallelisation	여러 LLM 호출을 동시에 실행하는 패턴
Evaluator-Optimiser	생성-평가-피드백-반복 루프 패턴

---

이 문서는 @hooeem의 X(Twitter) 스레드를 바탕으로 Anthropic, OpenAI 공식 문서 및 업계 전문가 자료를 종합하여 한국어로 재구성한 것입니다.