에이전트와 도구 사용 — 실험 설계를 자동으로 이어붙이는 루프
이 토픽을 마치면
편 #7·8까지의 어시스턴트는 한 번의 프롬프트에 한 번의 응답을 반환합니다. 그런데 실험 설계·데이터 분석·문헌 종합 검토 같은 실제 연구 작업은 여러 단계·여러 도구가 얽혀 있습니다. 이 편에서는 LLM에 도구(tools)·루프(loop)·메모리(memory) 를 얹어 에이전트(agent) 로 확장하는 방법을 배웁니다.
편 #1의 확률 기계가, 편 #7의 조건 설계와 편 #8의 외부 지식 주입을 지나, 이제 자율적으로 여러 단계를 이어붙이는 실행자가 됩니다. 2024~2025년 AI 개발의 최전선이 여기입니다.
대학원생의 요청 하나가 갖는 실제 복잡도
여러분이 지도교수에게 다음 주 실험 세팅안을 제출해야 한다고 합시다. 여러분이 어시스턴트에게 이렇게 말합니다.
"지난 우리 논문에서 쓴 세포주와 유사한 최근 논문의 CRISPR 편집 프로토콜을 참고해서, 이번 실험 설계 초안을 만들어줘. 필요한 시약 목록도 정리하고, 우리 실험실 재고에 없는 것만 표시해줘."
이 한 문장의 요청 안에 실제로 필요한 작업.
- 실험실 논문 창고를 뒤져서 어떤 세포주를 자주 쓰는지 확인.
- PubMed에서 그 세포주 + CRISPR 편집 조건으로 최근 논문 검색.
- 검색된 논문 중 유사한 조건 몇 편을 상세 요약.
- 여러 프로토콜을 종합해 실험 설계 초안 작성.
- 초안에서 필요한 시약 목록 추출.
- 실험실 재고 데이터베이스 조회해서 재고 유무 확인.
- 부족 시약만 별도 표시.
- 최종 결과를 markdown 문서로 정리.
편 #7의 프롬프트 하나로는 이 흐름을 처리할 수 없습니다. 편 #8의 RAG는 3번까지는 도와주지만 4~7단계는 못 함. 필요한 것은 여러 도구를 순차·병렬로 호출하는 실행자. 이 실행자가 에이전트.
Agent = LLM + Tools + Loop + Memory
에이전트의 구조를 최소 부품으로 정리.
┌─────────────────────────────────────────┐
│ 에이전트 루프 │
│ │
│ ┌─────────┐ ┌──────────┐ │
│ │ LLM │───▶│ 판단 │ │
│ │(reason) │ │(next step)│ │
│ └─────────┘ └──────────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌────────┐ ┌──────────┐ │
│ │ Memory │◀───│ 도구 호출 │ │
│ └────────┘ │ (act) │ │
│ └──────────┘ │
│ │ │
└───────────────────────┼─────────────────┘
▼
외부 세계
(검색·계산·API·DB)네 부품:
- LLM: 편 #1~6에서 다뤘던 그 확률 기계. 다음 어떤 도구를 어떤 인자로 호출할지 결정.
- Tools: 외부 세계와 상호작용하는 함수. 검색·계산·데이터베이스 쿼리·API 호출 등.
- Loop: LLM이 도구를 호출하고, 결과를 관찰하고, 다시 판단하는 반복.
- Memory: 지금까지의 관찰·판단 이력. 문맥 창(단기)과 외부 저장(장기)으로 나뉨.
이 네 부품이 갖춰지면 에이전트가 자율적으로 여러 단계를 실행할 수 있게 됩니다.
바이오 유비 — 세포의 환경 반응. 세포도 사실 이 구조입니다. 감지(sensor 수용체) → 판단(신호 캐스케이드) → 행동(전사 인자 활성, 대사 조절) → 관찰(피드백) → 다시 감지. 편 #4의 신호 캐스케이드가 세포 내부 판단 회로였다면, 에이전트는 이걸 LLM으로 대체한 인공적 유비. 세포가 "실행 가능한 결정 시스템"인 것처럼 에이전트도 그러함.
Tool — 외부 세계로 나가는 문
도구(tool) 는 에이전트가 호출할 수 있는 함수입니다. 각 도구는 이름·설명·파라미터 스키마를 가집니다.
바이오 실무에 필요한 도구 예시.
tools = [ { "name": "search_lab_papers", "description": "실험실 논문 창고에서 관련 논문 검색", "input_schema": { "type": "object", "properties": { "query": {"type": "string", "description": "검색어"}, "top_k": {"type": "integer", "default": 5} }, "required": ["query"] } }, { "name": "search_pubmed", "description": "PubMed에서 논문 검색", "input_schema": { "type": "object", "properties": { "query": {"type": "string"}, "year_from": {"type": "integer"}, "max_results": {"type": "integer", "default": 20} }, "required": ["query"] } }, { "name": "get_reagent_stock", "description": "실험실 재고 데이터베이스에서 시약 재고 조회", "input_schema": { "type": "object", "properties": { "reagent_names": {"type": "array", "items": {"type": "string"}} }, "required": ["reagent_names"] } }, { "name": "write_file", "description": "결과를 파일로 저장", "input_schema": { "type": "object", "properties": { "path": {"type": "string"}, "content": {"type": "string"} }, "required": ["path", "content"] } }]이 도구들을 에이전트가 호출하고, 각 결과를 문맥에 쌓아가면서 다음 판단을 내립니다.
도구 설명의 중요성. LLM은 도구 이름·설명·파라미터 스키마만 보고 호출을 결정합니다. 설명이 부정확하거나 모호하면 에이전트가 잘못된 도구를 호출하거나 잘못된 인자를 넣습니다. 도구 설계 시 프롬프트 엔지니어링만큼 신중해야 합니다.
좋은 도구 설명의 요소.
- 언제 이 도구를 써야 하는지 명시
- 각 파라미터의 목적과 예시
- 반환값의 형식
- 실패 케이스 (파라미터 오류·자원 없음 등) 처리 방침
Function Calling — 표준 인터페이스
Function Calling(OpenAI 용어) 또는 Tool Use(Anthropic 용어)는 LLM이 도구를 호출하기 위한 표준화된 API 인터페이스.
훈련된 모델은 "이 시점에 이 도구를 호출해야 한다" 는 것을 학습했습니다. 사용자 프롬프트와 도구 목록을 받으면 도구 이름과 파라미터를 JSON 형태로 반환합니다.
Claude API 예시.
response = client.messages.create( model="claude-3-5-sonnet-latest", tools=tools, messages=[{"role": "user", "content": "지난 3년간 실험실이 자주 쓴 세포주 3가지를 알려줘."}])
# response.stop_reason == "tool_use"# response.content 내부에:# [# {"type": "text", "text": "실험실 논문 창고를 확인해보겠습니다."},# {"type": "tool_use", "name": "search_lab_papers", # "input": {"query": "cell line used in experiments", "top_k": 10}, # "id": "toolu_01ABC..."}# ]호스트 프로그램(에이전트 루프)이 이 호출을 실행하고 결과를 다시 모델에 전달.
tool_result = search_lab_papers(query="cell line used in experiments", top_k=10)
response = client.messages.create( model="claude-3-5-sonnet-latest", tools=tools, messages=[ {"role": "user", "content": "지난 3년간 실험실이 자주 쓴 세포주 3가지를 알려줘."}, {"role": "assistant", "content": response.content}, # tool_use 포함 {"role": "user", "content": [ {"type": "tool_result", "tool_use_id": "toolu_01ABC...", "content": json.dumps(tool_result)} ]} ])모델이 이 결과를 참조해 다음 판단을 내림. 다시 도구 호출을 요청하거나(stop_reason == "tool_use"), 최종 답변을 반환(stop_reason == "end_turn").
이 왕복이 에이전트 루프의 뼈대.
ReAct 패턴 — 생각과 행동의 교대
ReAct(Reasoning + Acting). 에이전트가 각 스텝마다 생각(reasoning) 을 명시적으로 쓴 다음 행동(action, 도구 호출) 을 하는 패턴.
편 #7의 Chain-of-Thought가 답변 생성 전 추론 어절을 채우는 원리였다면, ReAct는 각 도구 호출 전에 왜 이 도구를 이 인자로 호출하는지 명시적으로 씀. 이 명시가 모델의 판단을 안정화합니다.
ReAct 패턴 예시:
Thought: 실험실이 자주 쓴 세포주를 확인해야 하니 먼저 실험실 논문 창고를 뒤진다.
Action: search_lab_papers(query="cell line CRISPR knockout", top_k=15)
Observation: [15편 논문 초록·방법 조각]
Thought: 이 논문들에서 HEK293T이 8회, HeLa가 5회, U2OS가 3회 언급됨. HEK293T이 가장 자주 쓰임.
이제 최근 논문에서 HEK293T + CRISPR 편집 프로토콜을 검색한다.
Action: search_pubmed(query="HEK293T CRISPR knockout efficient protocol", year_from=2023, max_results=10)
Observation: [10편 최근 논문 초록]
Thought: 이 중 2024년 Nature Protocols 논문이 세포주와 편집 방법이 유사. 상세 요약 필요.
Action: search_pubmed(query="2024 Nature Protocols HEK293T CRISPR efficient", max_results=1)
Observation: [해당 논문 전문 조각]
Thought: 프로토콜 초안 작성 준비 완료. 필요 시약 목록 정리 후 재고 확인.
...각 Thought이 다음 Action을 정당화하고, 각 Observation이 다음 Thought의 근거가 됩니다. 이 명시적 구조가 에이전트의 자기 검증과 디버깅을 돕습니다. 실패 시 어느 Thought에서 잘못된 판단이 있었는지 추적 가능.
최근 모델의 내재화. Claude 3.5·GPT-4o·o1 같은 최신 모델은 ReAct 패턴을 명시적으로 요청하지 않아도 자동으로 이런 흐름을 씁니다. 훈련 데이터에 에이전트 로그가 대량 포함되어 학습된 결과.
Planning — 큰 작업을 잘게 쪼개기
간단한 작업은 한 스텝의 도구 호출로 끝나지만, 우리 대학원생의 요청(8단계)처럼 복잡한 경우 먼저 전체 계획을 수립하는 것이 유리합니다.
Plan-and-Execute 패턴.
- 유저 요청을 받으면 먼저 계획 수립: 필요한 단계들을 리스트업.
- 각 단계를 순차 또는 병렬로 실행.
- 각 단계 결과를 관찰하고 필요하면 계획 수정.
- 최종 결과 반환.
계획 수립 단계에서 LLM에 이런 프롬프트.
당신은 연구 어시스턴트입니다. 유저 요청을 실행 가능한 단계로 분해하세요.
각 단계는 사용할 도구와 그 인자를 명시하세요.
유저 요청: (사용자의 요청)
계획을 JSON으로 반환:
{
"steps": [
{"step_id": 1, "action": "tool_name", "params": {...}, "depends_on": []},
{"step_id": 2, "action": "tool_name", "params": {...}, "depends_on": [1]},
...
]
}병렬 실행. depends_on이 비어 있는 단계들은 병렬 처리 가능. 예를 들어 논문 5편을 각각 요약하는 단계는 병렬. 시간 절약.
동적 재계획. 스텝 결과가 계획과 다르면(예: 검색이 0개 결과) 남은 스텝을 재구성. CoT + Tool + 재계획이 결합된 형태.
바이오 유비. 연구 프로젝트 관리와 개념 정합. 큰 프로젝트를 마일스톤과 태스크로 쪼개고, 병렬 진행 가능한 것과 순차 진행할 것을 구분하고, 결과에 따라 계획을 조정. 에이전트가 하는 일이 이 관리 사이클의 자동화.
Memory — 단기와 장기
에이전트가 여러 단계를 실행하면서 정보가 쌓입니다. 이 정보를 어디에 저장하느냐가 메모리 설계.
단기 메모리 = 문맥 창. 현재 세션의 도구 호출·관찰·판단 이력이 모두 문맥 창에 누적. 편 #6의 어텐션이 이 이력을 참조.
문제. 세션이 길어지면 문맥 창을 넘어감. GPT-4의 128K, Claude의 200K도 도구 호출 30~50회면 채워짐. 그리고 편 #8의 lost in the middle 문제도 발생.
단기 메모리 관리 기법.
- Summarization. 오래된 관찰을 요약으로 압축.
- Selective retention. 중요한 결과만 유지, 상세 로그는 파일로 저장.
- Chunking. 최근 N 스텝만 문맥에 유지.
장기 메모리 = 외부 저장. 여러 세션에 걸쳐 유지되는 정보.
- 파일 시스템. 각 세션의 결과를 파일로 저장. 다음 세션에서 파일 읽기 도구로 참조.
- 벡터 DB. 과거 결과를 임베딩해 저장, 필요할 때 RAG로 검색.
- 구조화 데이터베이스. 스키마 있는 정보(실험 이력·결과 지표 등)를 SQL DB에 저장.
바이오 유비. 세포의 후생유전학적 메모리. 유전자 발현 이력이 히스톤 수식·DNA 메틸화로 세대를 넘어 전달됨. 에이전트의 장기 메모리도 유사한 지속성 개념.
MCP — 도구 인터페이스의 표준화
지금까지 이야기한 도구들은 각 에이전트 시스템마다 다른 형식으로 정의됩니다. Claude API의 tool schema, OpenAI function calling, LangChain tool, LlamaIndex tool 등 모두 인터페이스가 조금씩 다름. 새 시스템에 이전하려면 도구 정의를 다시 짜야 함.
Model Context Protocol (MCP). 2024년 Anthropic이 제안한 표준. 도구·리소스·프롬프트를 언어·프레임워크·모델 무관하게 정의하는 open standard.
구조.
- MCP 서버: 도구·리소스를 제공하는 프로세스. 예: filesystem 서버, GitHub 서버, PubMed 서버.
- MCP 클라이언트: 서버에 연결해 도구를 호출하는 에이전트.
- 통신: 표준 JSON-RPC 프로토콜.
바이오 실무에 유용한 MCP 서버 예시.
- PubMed MCP: 논문 검색·상세 조회.
- PDB MCP: 단백질 구조 데이터.
- UniProt MCP: 단백질 정보 QA.
- Filesystem MCP: 실험실 파일 시스템 접근.
- Slack MCP: 팀 채널 알림.
의의. MCP가 표준화되면 에이전트 시스템은 자기가 아는 언어(MCP)만 쓰면 됨. 새 도구를 추가하려면 MCP 서버를 하나 띄우면 끝. 도구 생태계가 하나의 표준 위에 축적.
2025년 기준 Claude Desktop·Cursor·Continue·Windsurf 등 주요 에이전트 도구들이 MCP를 채택. 오픈소스 커뮤니티에서 수백 개의 MCP 서버가 공개됨. MCP를 이해하고 자기 도구를 MCP 서버로 만들 수 있는 것이 오늘의 AI 개발자 기본 소양이 되어가고 있습니다.
Multi-Agent — 역할 분담
복잡한 작업은 한 에이전트가 다 하기보다 여러 에이전트가 역할 분담해서 처리하는 게 나은 경우가 많습니다.
바이오 연구 파이프라인 예시. 세 개 에이전트로 나눔.
- Literature Agent: 논문 검색·요약 전담.
- Protocol Agent: 프로토콜 초안 작성·시약 목록 정리.
- Inventory Agent: 실험실 재고 관리.
세 에이전트가 오케스트레이터(orchestrator) 아래 협업. 오케스트레이터는 유저 요청을 받아서 어느 에이전트에게 무엇을 위임할지 결정.
Anthropic의 서브에이전트 실험. Claude Code·Manus·Devin 등 최근 코딩 에이전트가 이 구조. 메인 에이전트가 여러 서브에이전트를 스폰해서 병렬로 서브 작업 진행. 각 서브에이전트가 자기 문맥 창을 가져 정보 격리됨.
언제 multi-agent가 유리한가.
- 서로 다른 도메인 지식이 필요한 경우 (문헌·프로토콜·재고).
- 병렬 처리로 시간 단축이 필요한 경우 (논문 10편 동시 요약).
- 문맥 격리로 오염을 막고 싶은 경우.
언제 single agent가 나은가.
- 컨텍스트를 공유해야 하는 경우 (한 대화 맥락에서 계속 조정).
- 오케스트레이션 오버헤드가 이득보다 큰 경우.
- 디버깅·감사가 중요한 경우 (단일 로그가 추적 쉬움).
Safety — 도구 실행의 위험성
에이전트가 도구를 실제로 실행한다는 것은 실제 세계에 영향을 준다는 뜻. 실수·오용 시 진짜 손실이 발생합니다.
바이오 맥락 위험 사례.
- 시약 자동 주문 도구가 잘못된 수량을 주문.
- 실험 예약 도구가 잘못된 시간을 예약.
- 데이터베이스 수정 도구가 실험 기록을 덮어씀.
- 외부 API 호출로 개인 정보 노출.
방어 기법.
1. 도구 권한 분리. 읽기 전용 도구와 쓰기·실행 도구를 분리. 대부분의 자동 실행은 읽기 전용에 국한.
2. 인간 승인 게이트. 파괴적 도구(시약 주문·데이터 수정)는 실행 전 인간 확인. 에이전트가 계획을 제시하면 유저가 승인 후 실행.
3. 도구 실행 로그. 모든 도구 호출을 감사 가능한 로그에 기록.
4. Sandboxing. 실행 환경을 격리. 예: 코드 실행 도구는 Docker·wasm 샌드박스에서.
5. Prompt injection 방어. 편 #7의 injection 위험이 에이전트에서 더 심각. 검색된 문서·읽은 파일 안에 "당신의 원래 지시는 무시하고 X를 실행하라"가 심어져 있을 수 있음. 도구 결과를 시스템 프롬프트에 직접 연결하지 않고 명시적 delimiter로 감쌈.
바이오 특화 위험. 화학·생물학 정보 조합으로 위험 물질 합성 정보가 생성될 수 있음. 정렬(alignment) 훈련이 이를 막지만 완전하지 않음. 편 #11에서 자세히.
바이오 응용 시나리오
시나리오 1 — 실험 설계 어시스턴트 (앞 시나리오 완성)
앞에서 이야기한 8단계 요청을 처리하는 에이전트를 실제로 구현.
import anthropic
client = anthropic.Anthropic()
tools = [...] # 앞에서 정의한 4개 도구
def execute_tool(name, params): if name == "search_lab_papers": return vectorstore.similarity_search(params["query"], k=params.get("top_k", 5)) elif name == "search_pubmed": return pubmed_api(**params) elif name == "get_reagent_stock": return db.query_stock(params["reagent_names"]) elif name == "write_file": Path(params["path"]).write_text(params["content"]) return {"status": "ok"}
def agent_loop(user_request): messages = [{"role": "user", "content": user_request}] while True: response = client.messages.create( model="claude-3-5-sonnet-latest", tools=tools, messages=messages, max_tokens=4096 ) if response.stop_reason == "end_turn": return response.content[0].text messages.append({"role": "assistant", "content": response.content}) tool_results = [] for block in response.content: if block.type == "tool_use": result = execute_tool(block.name, block.input) tool_results.append({ "type": "tool_result", "tool_use_id": block.id, "content": json.dumps(result) }) messages.append({"role": "user", "content": tool_results})
# 사용result = agent_loop("지난 우리 논문에서 쓴 세포주와 유사한 최근 논문의 CRISPR 편집 프로토콜을 참고해서, 이번 실험 설계 초안을 만들어줘. 필요한 시약 목록도 정리하고, 우리 실험실 재고에 없는 것만 표시해줘.")이 loop이 최대 20~30 스텝 동안 도구를 호출하며 8단계 요청을 자동 처리.
시나리오 2 — 분자 특성 계산 에이전트
RDKit, PubChem, OpenBabel 등 화학 정보 도구를 MCP 서버로 감싸고 에이전트에 붙임.
유저 요청: "이 SMILES 분자의 예상 IC50 값과 유사한 알려진 저해제 3개를 찾아줘. 특히 hERG 채널 부작용 예측도 알려줘."
에이전트가:
- SMILES → 분자 구조 파싱 (RDKit MCP)
- Molecular fingerprint 계산 (RDKit)
- PubChem 유사 분자 검색 (PubChem MCP)
- hERG 저해 예측 모델 호출 (별도 예측 API)
- 결과 통합·보고서 작성
약물 발굴 초기 단계에서 실제로 이런 에이전트가 배치되기 시작.
시나리오 3 — 실험 데이터 자동 분석 파이프라인
측정 기기에서 나온 원본 파일을 자동 분석.
- File Watcher Agent: 실험 기기 폴더 모니터링, 새 파일 감지.
- QC Agent: 원본 데이터 품질 검사, 이상치 감지.
- Analysis Agent: 통계 분석·시각화·리포트 생성.
- Notification Agent: 결과를 Slack·이메일로 알림.
멀티 에이전트 오케스트레이션의 실전 예시. 몇몇 최근 실험실 자동화 스타트업이 이런 시스템 제공.
핵심 정리
- 에이전트 = LLM + Tools + Loop + Memory. 한 번의 프롬프트를 넘어 자율적 다단계 실행.
- Tool use / Function calling은 LLM이 외부 도구를 표준 방식으로 호출하는 인터페이스.
- ReAct 패턴 — Thought · Action · Observation 교대. 편 #7 CoT의 자연스러운 확장.
- Planning으로 큰 작업을 잘게 쪼개고 병렬 처리. 동적 재계획으로 실패 대응.
- Memory는 단기(문맥)와 장기(파일·벡터DB·SQL) 조합. 세션 넘어 지속.
- MCP는 도구 인터페이스의 open standard. 도구 생태계를 하나의 표준 위에 축적.
- Multi-agent는 역할 분담 필요할 때. Orchestrator + Sub-agents 패턴.
- Safety — 권한 분리, 인간 승인 게이트, 로그, sandbox, injection 방어. 도구 실행은 실제 세계에 영향.
다음 개념
- 편 #10
context-window-management— 에이전트의 긴 세션 문맥을 지혜롭게 관리하는 실무 기법. - 편 #11
hallucination-and-alignment— 에이전트의 도구 호출 오판·환각 문제. - 편 #13
claude-code-and-cursor— 코딩 에이전트의 실전 사용.
📐 부록 — 전문가를 위한 수학·시스템 공식
난이도: 매우 어려움 (Very Hard) 대상: 시스템 설계·강화학습·정형화된 프로세스 배경 독자
A.1 에이전트의 마르코프 결정 과정 관점
에이전트를 부분 관측 마르코프 결정 과정(POMDP)으로 형식화.
- 상태
s ∈ S: 세계의 현재 상태 (에이전트가 직접 관측 못 함). - 관측
o ∈ Ω: 도구 호출 결과.o ~ O(o | s). - 행동
a ∈ A: 도구 호출. - 정책
π(a | h): 관측·행동 이력h가 주어졌을 때 다음 행동 확률. - 보상
r: 목표 달성도.
LLM은 π를 파라미터화한 함수. π_θ(a | h) = LLM(h).
차이점. 강화학습과 달리 LLM의 π는 훈련 시 명시적 보상 신호로 훈련되지 않았음(RLHF는 다른 층위). 하지만 훈련 데이터의 에이전트 로그에서 "이 상황에서 이 행동" 패턴을 흡수.
A.2 Function Calling의 훈련
LLM이 도구를 잘 부르는 것이 저절로 되는 것은 아님. 훈련 데이터에 도구 호출 패턴이 명시적으로 포함되어야 함.
Function calling 훈련 데이터 형식:
User: "지난 3개월 평균 세포 배양 성공률은?"
Assistant: <tool_call>get_experiment_records(period="3_months")</tool_call>
Tool: {"records": [...], "success_rate": 0.87}
Assistant: "지난 3개월 평균 성공률은 87%입니다."이런 대화 수십만 개로 훈련. 모델이 상황에 맞는 도구 호출 패턴을 학습.
Toolformer (Meta AI, 2023)가 이 훈련 방식의 초기 연구. 최근 모델은 대량의 tool use 대화로 사전훈련 + RLHF.
A.3 ReAct의 형식화
각 스텝 t에서:
Thought_t ~ π_thought(· | h_t)
Action_t ~ π_action(· | h_t, Thought_t)
Observation_t = Tool(Action_t)
h_{t+1} = h_t ∪ {Thought_t, Action_t, Observation_t}정지 조건: Action_t == "answer" 또는 t == max_steps.
이론적 이점. Thought이 명시적으로 문맥에 있으면 π_action이 참조 가능. Thought 없이 바로 Action을 뽑는 것보다 정확도 높음.
최근 모델의 internal reasoning. o1·Claude 3.5 등 최신 모델은 Thought을 hidden reasoning으로 처리하기도 함. 외부에서 안 보이지만 내부적으로는 유사한 구조.
A.4 Multi-step Planning의 계산 복잡도
Greedy planning (LLM이 한 번에 계획 만들기):
- 시간: 1 LLM 호출
- 오류 전파: 초기 오류가 모든 스텝에 영향
Tree Search planning (여러 계획 후보 생성 후 선택):
- 시간: N × 1 LLM 호출 (N개 후보) + 평가 LLM 호출
- 오류 감소: 다양성으로 최적 계획 선택 가능성 상승
Monte Carlo Tree Search (MCTS):
- 각 스텝마다 여러 후보 탐색 + rollout 시뮬레이션
- 시간 폭발 (
b^d, b=branch factor, d=depth) - AlphaGo·o1 계열의 뿌리 방법론
A.5 Tool Selection 확률의 anchor
LLM이 도구를 선택하는 확률:
P(tool_i | context) = softmax(logit(tool_i | context))Anchor effect. 도구 설명에 특정 상황이 명시되면 그 상황이 문맥에 있을 때 도구 선택 확률 급상승. 도구 설명이 프롬프트 엔지니어링만큼 중요한 이유.
Ambiguity penalty. 여러 도구가 비슷한 상황에 맞으면 모델이 잘못된 도구를 선택할 확률 상승. 도구 이름·설명은 서로 명확히 구별되어야 함.
A.6 MCP 프로토콜 구조
JSON-RPC 2.0 기반.
서버가 제공하는 method:
initialize: 프로토콜 버전·capability 교환tools/list: 사용 가능한 도구 목록tools/call: 도구 실행resources/list: 정적 자원 목록 (예: 파일)resources/read: 자원 읽기prompts/list: 프롬프트 템플릿 목록prompts/get: 프롬프트 가져오기
클라이언트가 제공하는 method:
sampling/createMessage: 서버가 LLM 호출을 요청할 수 있음 (양방향)logging/log: 서버가 클라이언트에 로그 전달
Transport: stdio (표준 입출력) 또는 HTTP+SSE.
A.7 Context Window Budget 관리
에이전트 세션이 길어질수록 문맥 관리가 중요.
세션 예산:
budget = C - system_prompt - tools_schema - reserved_outputC: 문맥 창 크기.
세션 진행 시 사용량:
used = Σ_{t} |Thought_t + Action_t + Observation_t|used > budget * threshold 이면 압축·요약 트리거.
Compaction 전략:
- 초기 몇 스텝의 상세 관찰을 요약으로 대체.
- 성공한 최근 스텝만 유지.
- 모든 중간 결과를 외부 파일에 저장, 파일 경로만 문맥에 유지.
A.8 Multi-Agent 통신 프로토콜
에이전트 간 통신 형식.
Message passing:
{
"from": "orchestrator",
"to": "literature_agent",
"task": "PubMed에서 HEK293T + CRISPR 최근 논문 10편 요약",
"context": {...},
"deadline": "2 minutes",
"return_format": "json_schema"
}Response:
{
"from": "literature_agent",
"to": "orchestrator",
"status": "success",
"result": {...},
"duration": "45s",
"cost": {"tokens": 45230}
}Consensus mechanism. 여러 에이전트가 다른 답을 반환하면 오케스트레이터가 다수결·품질 평가로 최종 선택.
A.9 Tool Cost·Latency 관리
각 도구 호출의 비용·지연:
| 도구 | 지연 | 비용 |
|---|---|---|
| Vector search | 100~500ms | $0 (자체 호스트) |
| PubMed API | 1~3s | $0 |
| LLM 호출 | 2~30s | $0.01~1 |
| Web scraping | 3~10s | $0 |
| 코드 실행 | 1s~ | $0 (샌드박스) |
최적화:
- 병렬 호출 가능한 것들 배치.
- 캐싱 (동일 쿼리는 재사용).
- 조기 종료 (충분한 정보 수집 시 loop break).
A.10 에이전트 평가 지표
Task success rate: 완료 여부 (인간 판정). Steps to completion: 도구 호출 수. 적을수록 효율. Cost per task: 토큰·API 비용. Latency: 시작~완료 시간. Robustness: 실패 케이스 복구율.
벤치마크:
- AgentBench: 다양한 도메인 에이전트 태스크.
- SWE-bench: 실제 GitHub 이슈 해결.
- GAIA: 일반적 조수 태스크.
- WebArena: 웹 자동화.
바이오 특화 벤치마크는 아직 초기 단계.
참고 자료
본 편의 콘텐츠·시나리오·비유·수치는 모두 BioPlayground 자체 개발이며, 아래는 개념 학습에 도움이 되는 외부 참고 자료입니다.
- ReAct 원 논문: Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (ICLR 2023)
- Toolformer: Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools" (NeurIPS 2023)
- Function Calling: OpenAI docs "Function Calling", Anthropic docs "Tool Use"
- Model Context Protocol: modelcontextprotocol.io, Anthropic 공식 사양 (2024)
- Plan-and-Execute: Wang et al., "Plan-and-Solve Prompting" (ACL 2023)
- AutoGPT·BabyAGI 개념 원류: Nakajima·Richards, 오픈소스 프로젝트 (2023)
- MCTS + LLM: Yao et al., "Tree of Thoughts" (NeurIPS 2023)
- SWE-bench: Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" (ICLR 2024)
- AgentBench: Liu et al., "AgentBench: Evaluating LLMs as Agents" (ICLR 2024)
- Anthropic Building Effective Agents: anthropic.com/research/building-effective-agents (2024)
편 #9로 에이전트의 기본 구조를 배웠습니다. 편 #10에서는 에이전트의 긴 세션에서 문맥 창을 지혜롭게 관리하는 실무 기법을 다룹니다.