Agent AI & Multi-Agent
77 slides 5시간 · Agent AI
SuanLab
Agent AI 단기 강좌

Agent AI & Multi-Agent

Claude API로 만드는 지능형 에이전트

도구를 쓰고 · 스스로 검증하고 · 협업하는 에이전트 3종 직접 제작
한국디지털컨버전스학회 · 5시간 집중 강좌 · 이론 + Colab 핸즈온
2026 · Course Materials
SESSION 1

Claude API & Agent 아키텍처

이론 + 실습
10:00–12:00
2

오늘 세션의 목표

can-do 목표
  • Agent가 일반 챗봇과 무엇이 다른지 설명
  • Claude에 외부 도구를 붙여 스스로 쓰게
  • Claude API 응답 구조를 읽고 다루기
  • 논문 검색 에이전트 직접 완성
기억할 한 줄
끝에서 이 네 가지를 체크합니다
3

따라오기 위해 필요한 것 (걱정 마세요)

입문자 환영
  • Python을 읽을 수 있는 정도면 충분
  • 코드는 한 줄씩 같이 — 막히면 손드세요
  • 어려운 용어는 그때그때 쉽게
  • 모든 실습은 Colab(브라우저), 설치 X
기억할 한 줄
"완벽 이해"보다 "직접 돌려보고 감 잡기"
4

용어 워밍업 ① — API / SDK

약속된 창구와 도구상자
  • API = 프로그램끼리 대화하는 약속된 창구
  • Claude API = 우리 코드가 Claude에 질문·답받는 창구
  • SDK = 그 창구를 쉽게 쓰는 도구상자 (anthropic)
기억할 한 줄
식당 비유: API = 주문 창구, SDK = 키오스크
5

용어 워밍업 ② — API Key / 환경변수

비밀 출입증
  • API Key = Claude 쓸 때 비밀 출입증 (sk-ant-...), 사용량 과금
  • 환경변수 = 프로그램이 읽는 메모지 → 키를 코드와 분리
  • Colab은 🔑 Secrets에 저장
기억할 한 줄
키를 코드/깃허브에 올리면 도용 위험!
6

용어 워밍업 ③ — JSON / dict / 토큰

오늘 코드의 90%
  • dict = {"role":"user","content":"안녕"}
  • JSON = 거의 같은 모양의 교환용 문자열
  • 토큰 = 단어 조각, 입력+출력만큼 과금
기억할 한 줄
오늘 코드의 90%는 dict 다루기 — 겁먹지 마세요
7

LLM이란? (출발점)

우리의 두뇌
  • LLM = 방대한 텍스트로 다음 말을 예측하는 모델
  • Claude, GPT 등 — 요약·번역·글쓰기·추론·코딩
  • 하지만 "두뇌" 하나로는 부족합니다 — 왜?
8

LLM만으로는 부족하다

두뇌는 똑똑한데 손발·기억·검색이 없음
물어보면
  • "오늘 환율?"
  • "이 논문 요약?"
  • "12345×6789?"
  • "모르는 사실"
LLM 혼자
  • 최신정보 없음
  • 접근 불가
  • 종종 틀림
  • 지어냄(환각)
9

그래서 등장: Agent

챗봇은 대답만, 에이전트는 일 처리

LLM(두뇌)에 손발·기억·도구를 붙여, 스스로 계획·행동하는 시스템

똑똑한 신입 조수에게 "검색권한 + 계산기 + 메모장"을 주고 "알아서 해줘"

10

Agent 동작의 큰 그림

관찰 → 추론 → 행동의 반복 루프
관찰 Observation도구 결과를 받는다 추론 Reason"다음에 뭘 할까?" 행동 Act도구를 호출한다 목표까지반복
핵심
사람이 리포트를 쓰는 과정과 동일 — 보고 · 생각하고 · 움직이고 · 다시 본다
11

Agent의 3대 구성 요소

세 요소가 루프로 맞물릴 때 에이전트
Planning
  • 다음 행동 결정
  • 오늘 실습: Claude 추론
Memory
  • 한 일 기억
  • 오늘 실습: messages
Tool
  • 실제 행동
  • 오늘 실습: search_papers
12

ReAct 프레임워크

Reason + Act를 번갈아 = 현대 에이전트 골격
Thought : "논문이 필요. 검색하자."
Action : search_papers("ReAct")
Observation : [논문 3편]
↑ 반복 ↓
Final Answer : "정리하면 ..."
참고
ReAct 논문(Yao 2022) 오늘의 run_agent가 그 구현체
13

왜 ReAct가 강력한가

상상해서 답 → 찾아보고 답
  • 생각을 글로 → 디버깅 쉬움
  • 행동(도구)으로 사실 확인 → 환각 교정
  • 한 번에 못 맞춰도 여러 번으로 개선
기억할 한 줄
"상상해서 답" → "찾아보고 답"
14

비교 — 단순 호출 vs 에이전트

오늘 만드는 건 오른쪽
단순 호출
  • 외부 접근 — 불가
  • 다단계 — 불가
  • 환각 — 높음
에이전트
  • 외부 접근 — 도구로 가능
  • 다단계 — 루프로 가능
  • 환각 — 낮춤
15

왜 Claude? ① 지시 이행력

이행력 = 신뢰성

복잡한 다단계 지시를 끝까지 정확히 따른다

약한 모델: "형식 지켜" → 흐트러짐

Claude: 까다로운 규칙도 일관 준수

에이전트는 지시(system)가 곧 운전대

16

왜 Claude? ② XML 구조화

태그 = "여기부터 결론" 표지판
<verdict>insufficient</verdict>
<missing>reinforcement learning</missing>
참고
사람이 읽기 좋고 + 코드로 추출 쉬움 — 뒤 세션 실습의 검증·리뷰가 이 방식
17

왜 Claude? ③ System Prompt

system 설계 = 에이전트 설계의 절반
system="너는 엄격한 검증자다. 근거 약하면 insufficient."
참고
같은 모델로 Researcher / Reviewer / Editor 페르소나(Session 3) system = 직무기술서
18

messages.create

대화 흐름 리스트
resp = client.messages.create(
model=MODEL, max_tokens=300, # max_tokens 필수!
messages=[{"role":"user","content":"..."}])
참고
messages = 대화 흐름 리스트 · max_tokens 없으면 에러
19

응답 뜯어보기

리스트인 이유 = 여러 블록
resp.content # 블록 '리스트'
resp.stop_reason # end_turn / tool_use / max_tokens
resp.usage # 토큰=비용
참고
content[0].text 로 첫 텍스트 · stop_reason=="tool_use" = 도구 신호
20

temperature — 다양성 조절

에이전트는 보통 낮게(재현성)
ask_once(q, temperature=0.0) # 일관
ask_once(q, temperature=1.0) # 창의
참고
실습 A-2에서 직접 비교
21

Tool Use란? — 왜 필요한가

요청 vs 실행 분리가 핵심

LLM은 혼자 검색·계산을 못 함

"도구 목록"을 주면 호출 요청, 실행은 우리 코드

비서에게 "필요하면 'OO 찾아줘'라고 말해 내가 찾아줄게"

22

Tool Use — 4단계 라운드트립

가장 중요 — 천천히
[1] tools와 함께호출 [2] Claude:"search_papers(ReAct)"tool_use [3] 우리 코드가실행 → 결과 [4] tool_result→ 최종 답변
핵심
[4]에서 같은 tool_use_id 로 결과를 돌려줘야 짝이 연결됩니다
23

Tool Use — 단계별

id를 맞춰야 짝 연결
  • [1] tools=[...] 첨부
  • [2] stop_reason=="tool_use", block.name / block.input
  • [3] search_papers(**block.input) ← 우리가 실행
  • [4] tool_result(같은 tool_use_id) → 재호출
기억할 한 줄
id를 맞춰야 요청-결과 짝이 연결됩니다 (실습 C-5)
24

도구 스키마

description = Claude의 선택 근거 → 정성껏!
{"name":"search_papers",
"description":"arXiv 논문 검색. 최신 근거 필요시.",
"input_schema":{"type":"object",
"properties":{"query":{"type":"string"}},
"required":["query"]}}
참고
description 한 줄로 Claude의 도구 선택이 바뀝니다 (실습 C-4)
25

도구가 2개면 Claude가 '고른다'

설명을 보고 상황에 맞는 도구 선택
"123*456 계산" → calculator
"ReAct 찾아줘" → search_papers
"기분 어때?" → 도구 없이 답
참고
실습 C-4에서 도구 선택을 직접 관찰
26

에이전트 루프 = ReAct 코드

이번 세션의 결승점
def run_agent(msg, tools, max_turns=6):
messages=[{"role":"user","content":msg}]
for _ in range(max_turns):
resp = call_with_retry(model=MODEL, max_tokens=1024,
tools=tools, messages=messages)
if resp.stop_reason != "tool_use": return 답변
# 도구 실행 → tool_result → 재호출
참고
for로 감싸면 멀티툴 에이전트, max_turns=안전장치
27

토큰 = 비용, 항상 관찰

루프 돌면 토큰 누적 → 비용↑
resp.usage.input_tokens # 입력
resp.usage.output_tokens # 출력
참고
실습의 run_agent가 누적 토큰을 출력 — 단체 실습 비용 의식
28

단체 실습 안전장치 ⚠️

흔한 장애에 미리 대비
  • 429(요청 폭주) → call_with_retry 지수 백오프
  • 네트워크/arXiv 장애 → mock 폴백
  • 모델명 오타MODEL 상수 한 곳
  • 키/크레딧 누락 → 친절한 안내
기억할 한 줄
429가 몰리면 줄 단위로 30초 텀을 둡니다
29

초보자가 자주 만나는 실수

왼쪽을 오른쪽으로
흔한 실수 ❌
  • resp.content 통째 출력
  • 키 하드코딩
  • max_tokens 누락
  • tool_result 안 돌려줌
  • 모델명 오타
이렇게 ✅
  • content[0].text
  • Colab Secrets
  • 항상 지정
  • 4단계 완주
  • MODEL 상수
30

정리 — 핵심

Session 1 요약
1
Agent = LLM + Planning·Memory·Tool
세 요소가 루프로 맞물린다
2
ReAct: 추론 ↔ 행동 반복
run_agent가 그 구현체
3
Claude 강점: 이행력·XML·System
에이전트 설계의 토대
4
Tool Use 4단계
description이 도구 선택을 좌우
5
단체 실습엔 retry + 폴백
429·네트워크 장애 대비
31

▶ 이제 노트북을 엽니다

01_custom_tool_use.ipynb
  • ① Colab에서 01_custom_tool_use.ipynb 열기
  • ② 🔑 Secrets에 ANTHROPIC_API_KEY 등록
  • ③ 맨 위 셀부터 차례로 ▶ 실행
  • 목표: search_papers 도구로 논문 검색 에이전트 완성
기억할 한 줄
전원 키 등록을 확인하고 시작합니다 — 휴식 후 60분
32
SESSION 2

LangGraph Stateful Workflow

이론 + 실습
13:30–15:00
33

오늘 세션의 목표

Session 1 run_agent와 연결
  • "그래프로 흐름"이 왜 좋은지
  • State · Node · Edge로 워크플로우
  • 조건에 따라 되돌아가는(순환) 에이전트
  • 검색→분석→검증→재검색 환각 거르는 에이전트
기억할 한 줄
Session 1 run_agent(for 루프)를 그래프로 구조화합니다
34

잠깐 복습

코드로 상상 → 그림으로 보기
  • Session 1: run_agent = for 루프로 도구 반복
  • 분기·조건이 많아지면 코드 복잡
  • 오늘: 흐름을 눈에 보이는 그래프
기억할 한 줄
Session 1 코드 재사용이 다음 단계와의 연결고리
35

용어 워밍업 — 그래프 / LangGraph

부품 3개: State, Node, Edge
[START] → 검색 → 분석 → 검증 → [END]
참고
그래프 = "상자(작업)+화살표(이동)" 흐름도 LangGraph = 그것을 코드로 만들고 실행
36

단순 루프의 한계

코드 다 읽어야 흐름 안다 = 위험
  • 분기·재시도가 뒤엉켜 읽기 어려움
  • 어디서 멈췄는지 추적 곤란
  • 시각화·재사용 힘듦
기억할 한 줄
if 중첩 지옥 — "코드 다 읽어야 흐름 안다"는 위험 신호
37

부품 ① State — 공용 메모장

팀 전원이 돌려보는 공용 클립보드
from typing import TypedDict, List, Annotated
import operator
class ResearchState(TypedDict):
query: str
documents: Annotated[List[dict], operator.add] # 누적
analysis: str
verdict: str
loop_count: int
참고
TypedDict = 키를 미리 적어둠 (실제 NB2의 ResearchState엔 재검색 키워드용 missing 키도 있음 — 여기선 핵심 5키만)
38

reducer — 덮어쓰기 vs 누적

누적 필요한 키만 reducer
documents: Annotated[List[dict], operator.add]
참고
보통 반환값은 그 키를 덮어씀 → reducer를 주면 합쳐짐(누적) documents는 검색마다 쌓여야 하므로 reducer
39

부품 ② Node — 작업 한 단계

노드는 "한 가지 일"만
def search_node(state):
docs = search_papers(state["query"]) # Session 1 재사용!
return {"documents": docs} # 바뀐 키만
참고
입력은 State 전체 / 출력은 갱신할 키만
40

부품 ③ Edge — 이동 규칙

조건부 엣지가 "되돌아가기"를 만든다
# 일반 add_edge("A","B") → 무조건 이동
# 조건부 add_conditional_edges(...) → 갈림길
search → analyze → verify ─(충분)→ END
└──(부족)→ search ← 순환
참고
순환은 조건부 엣지로만 만들어집니다
41

우리가 만들 흐름

되돌아가는 화살표 하나가 순환의 전부
START search_node검색 analyze_node분석 verify_node검증 충분 END 부족: 재검색 (순환)
핵심
노드 3개 함수명을 노트북과 그대로 맞췄습니다: search_nodeanalyze_nodeverify_node
42

search 노드 — 재검색은 좁혀서

중복 제거 + 누적
def search_node(state):
term = state["query"]
if state.get("missing"):
term += " " + state["missing"] # 부족분으로 좁힘
docs = search_papers(term, 3)
fresh = [중복 제거]
return {"documents": fresh} # reducer로 누적
참고
재검색은 verify가 알려준 missing 키워드로 범위를 좁힙니다
43

analyze 노드 — 모은 자료 정리

갱신 키만 반환
def analyze_node(state):
docs = state["documents"]
analysis = ask_claude(
"다음 논문들을 종합 분석:\n" + 자료요약)
return {"analysis": analysis} # 갱신 키만
참고
search가 모은 documents를 한 편의 분석으로 → 다음 verify가 채점 ask_claude는 Session 1 호출 패턴 재정의
44

verify 노드 — 환각 거르기

Claude가 자기 결과를 비판
judge = ask_claude(
"충분한가? 환각 없나?\n"
"<verdict>sufficient/insufficient</verdict>\n"
"<missing>키워드 or none</missing>")
verdict = extract(judge, "verdict")
참고
Claude가 자기 결과를 비판 → 부족하면 재검색 자기 점검 = 자율성
45

조건부 라우팅 — 갈림길 함수

반환 문자열 → 매핑 → 다음 노드
def route_after_verify(state):
if state["verdict"]=="sufficient": return "end"
if state["loop_count"]>=MAX_LOOPS: return "end"
return "search" # 순환!
g.add_conditional_edges("verify", route_after_verify,
{"search":"search","end":END})
참고
라우터가 반환한 문자열이 매핑을 통해 다음 노드로 연결됩니다
46

그래프 조립

레고처럼 노드와 엣지를 붙인다
g = StateGraph(ResearchState)
g.add_node("search", search_node)
g.add_node("analyze", analyze_node)
g.add_node("verify", verify_node)
g.add_edge(START, "search")
g.add_edge("search","analyze"); g.add_edge("analyze","verify")
g.add_conditional_edges("verify", route, {...})
app = g.compile()
참고
노드를 등록하고 엣지로 연결한 뒤 compile()로 실행 가능한 앱 생성
47

실행 & 결과

노드 print 로그를 순서대로 읽기
app.invoke({"query":"...","documents":[],"loop_count":0,...},
config={"recursion_limit":15})
참고
노드의 print 로그가 순서대로 출력 → 부족하면 search로 되돌아가는 순환을 관찰
48

stream — 노드별 진행 (심화)

invoke=한 번에, stream=노드마다
for step in app.stream(initial, config={...}):
for node, delta in step.items():
print("노드 완료:", node, list(delta))
참고
invoke는 결과를 한 번에, stream은 노드마다 중간 상태를 흘려줍니다 (실습 E-3)
49

⚠️ 무한루프 방지 (가장 중요!)

끝나지 않는 루프 → 비용 폭발
  • 루프 카운터loop_count >= MAX_LOOPS
  • recursion_limit — 시스템 상한
  • 둘 다 — 의미상 종료 + 시스템 상한
기억할 한 줄
비용 사고 1순위 — 카운터와 recursion_limit을 함께 거세요
50

실행 추적 & 디버깅

키 없으면 print로 충분
# 가장 쉬움: 노드 print
# 한 단계 위: LangSmith (선택)
os.environ["LANGCHAIN_TRACING_V2"]="true"
참고
LangSmith 키가 없어도 print 로그로 충분히 추적됩니다
51

초보자가 자주 만나는 실수

왼쪽을 오른쪽으로
흔한 실수 ❌
  • State 전체 반환
  • 종료조건 없는 순환
  • add_edge로 갈림길
  • State 초기값 누락
이렇게 ✅
  • 바뀐 키만 반환
  • MAX_LOOPS + recursion_limit
  • add_conditional_edges
  • invoke에 다 채워
52

정리 — 핵심

Session 2 요약
1
LangGraph = State + Node + Edge
reducer로 누적 제어
2
add_conditional_edges로 순환
되돌아가는 화살표가 자율성
3
검증 노드로 환각 거르고 재검색
verify_node가 자기 점검
4
무한루프 이중 방어
카운터 + recursion_limit
53

▶ 이제 노트북을 엽니다

02_langgraph_cyclic_agent.ipynb
  • 검색 → 분석 → 검증 → 재검색 순환 에이전트 조립
  • search_node · analyze_node · verify_node 직접 작성
  • add_conditional_edges로 되돌아가는 순환 구현
  • 앞 세션에서 등록한 키 그대로 사용
기억할 한 줄
노드 3개 함수명은 노트북과 1:1 일치 — 60분
54
SESSION 3

Multi-Agent 협업

이론 + 실습
15:30–17:00
55

오늘 세션의 목표

결과물 = 다듬은 연구 초안
  • "왜 한 명이 아니라 여러 에이전트"
  • Supervisor-Worker / Actor-Critic 구분
  • Researcher ↔ Reviewer 피드백으로 글 완성
기억할 한 줄
지금까지 한 명 → 이제 여러 명의 팀
56

잠깐 복습

공통: 스스로 점검하면 품질↑
  • Session 1: 도구 쓰는 에이전트
  • Session 2: 그래프로 순환·검증
  • 공통: 스스로 점검하면 품질↑
기억할 한 줄
오늘: 그 점검을 다른 역할 에이전트에게 (verify → Reviewer)
57

용어 워밍업 — 페르소나 / 멀티에이전트

같은 모델 + 다른 system = 다른 직원
RESEARCHER_SYSTEM = "너는 Researcher다 ..."
REVIEWER_SYSTEM = "너는 까다로운 Reviewer다 ..."
참고
페르소나 = 역할·성격 → system prompt로 구현 모델을 여러 개 띄울 필요 없음
58

왜 한 명이 아니라 여러 명?

글쓴이 자기 교정 → 오타 못 봄
  • 한 모델에 쓰기+검토+수정을 한꺼번에?
  • 자기 글에 관대(self-bias)
  • 역할 섞여 품질 저하
  • 초점 흐림
기억할 한 줄
저자-편집자-교정자 분업이 필요한 이유
59

단일 vs 분업

견제와 전문화
혼자
  • 다 함
  • 셀프 봐주기
  • (자기 글에 관대)
  • Researcher: 작성
  • Reviewer: 비판
  • Editor: 윤문
  • → 견제 → 품질↑
60

페르소나 설계 = System Prompt

구체적일수록 또렷
RESEARCHER_SYSTEM = "근거 중심으로 초안을 쓴다..."
REVIEWER_SYSTEM = "허점·근거부족을 냉정히 지적한다..."
참고
Session 1의 이행력·System 제어가 여기서 결실 — Reviewer는 까다롭게 설계
61

패턴 ① Supervisor-Worker

감독자가 쪼개 나눠주고 모음
Supervisor Worker A검색 Worker B요약 Worker C번역 취합 → Supervisor
핵심
Supervisor가 큰 작업을 쪼개 분배하고 결과를 모읍니다 (실습 E 맛보기)
62

패턴 ② Actor-Critic (오늘 핵심)

작성자 ↔ 검토자 피드백 루프
ResearcherActor · 작성 ReviewerCritic · 비판 작성 → ← 고쳐서 다시 ... approve 또는 최대 횟수까지
핵심
Actor(배우)가 쓰고 Critic(평론가)이 비판 → 고쳐 다시 쓰는 피드백 루프
63

Researcher (작성자)

같은 함수가 작성·개선 두 모드
def researcher_write(topic, feedback=None, previous=None):
if previous and feedback: # 개선
prompt = "이전 초안을 피드백대로 고쳐줘 ..."
else: # 작성
prompt = "이 주제로 초안을 써줘 ..."
return ask_claude(prompt, system=RESEARCHER_SYSTEM)
참고
개선 모드에선 이전 초안과 피드백을 함께 전달
64

Reviewer — XML 피드백

verdict로 종료, issues로 개선 지시
prompt = ("초안 비평. 형식:\n"
"<verdict>approve/revise</verdict>\n"
"<issues>- 문제점</issues>\n"
"<suggestions>- 제안</suggestions>")
참고
사람이 읽고 + 코드로 파싱(extract) verdict로 루프 제어
65

협업 루프

초안이 라운드마다 좋아지는 과정
def collaborate(topic, max_rounds=3):
draft = researcher_write(topic)
for r in range(max_rounds):
review = reviewer_review(topic, draft)
if extract(review,"verdict")=="approve": break
fb = issues + suggestions
draft = researcher_write(topic, fb, draft)
return draft
참고
라운드별로 초안이 개선되는 과정을 출력으로 관찰
66

⚠️ 종료 조건 (필수)

자율성과 안전장치는 한 세트
  • 품질: Reviewer approve
  • 상한: 최대 라운드 max_rounds
  • 둘 다 없으면 무한 루프
기억할 한 줄
종료 조건은 세 세션을 관통하는 핵심 가드레일
67

Editor 추가 — 3-에이전트

Researcher → Reviewer → Editor
EDITOR_SYSTEM = "내용은 두고 가독성·흐름만..."
def editor_polish(text):
return ask_claude("의미 바꾸지 말고 다듬어줘.\n"+text,
system=EDITOR_SYSTEM)
참고
Editor는 의미를 바꾸지 않고 가독성·흐름만 다듬습니다 (실습 D)
68

Supervisor-Worker 맛보기 (심화)

Supervisor가 분해, Worker가 수행
subs = supervisor_split(task) # 큰 작업 → 하위
results = [worker(s) for s in subs] # 각각 수행
참고
실습 TODO: 4번째 페르소나 fact_check로 사실 검증 추가 (노트북 F의 정답 함수명)
69

두 패턴 비교

실무에선 섞어 쓰기도
Supervisor-Worker
  • 구조 — 분배·취합
  • 목적 — 작업 분할
  • 예 — 검색+요약
Actor-Critic
  • 구조 — 피드백 루프
  • 목적 — 품질 개선
  • 예 — 작성↔검토
70

실무 적용 팁

처음부터 복잡하게 X — 단순함이 미덕
  • 작게 시작: 도구 → 그래프 → 멀티에이전트
  • 에이전트 수는 필요한 만큼만
  • 출력 형식 고정(XML/JSON)
  • 로그로 관찰
기억할 한 줄
과설계 경계 — 단순함이 미덕
71

초보자가 자주 만나는 실수

왼쪽을 오른쪽으로
흔한 실수 ❌
  • 한 에이전트에 역할 다
  • Reviewer 너무 착하게
  • 종료조건 없음
  • 자유 형식 피드백
이렇게 ✅
  • 페르소나 분리
  • 까다롭게
  • approve + max_rounds
  • XML 고정
72

정리 — 핵심

Session 3 요약
1
페르소나 = system prompt
같은 모델, 다른 직무기술서
2
Supervisor-Worker / Actor-Critic
분배·취합 vs 피드백 루프
3
XML 피드백으로 협업 제어
verdict로 종료, issues로 개선
4
종료 조건 필수
approve + max_rounds
73

▶ 이제 노트북을 엽니다

03_multi_agent_researcher_reviewer.ipynb
  • Researcher ↔ Reviewer 협업으로 연구 초안 완성
  • researcher_write · reviewer_review · collaborate 작성
  • XML <verdict>로 루프 종료, <issues>로 개선
  • 앞 세션 키 그대로 — 실습 45분
기억할 한 줄
라운드마다 초안이 좋아지는 과정을 직접 관찰합니다
74

🎓 Q&A & Wrap-up

관통 주제: 스스로 점검 + 가드레일
[S1] Tool Use → 행동
[S2] LangGraph → 상태·순환
[S3] Multi-Agent → 협업
참고
세 세션을 관통하는 주제: 스스로 점검 + 가드레일
75

더 나아가기 (부록 노트북 04)

빨리 끝낸 분 / 복습용
Prompt Caching
  • 반복 컨텍스트 비용↓
Streaming
  • 실시간 출력
구조화 출력
  • Tool Use로 JSON 강제
Eval
  • 품질을 수치로
76
"
관통 주제는 하나 — 스스로 점검하고, 가드레일을 건다
— Agent AI 단기 강좌 · 감사합니다 🙏
77
1 / 77

목차 · Slides