에이전트 설계: 루프 · 워크플로 · 메모리 · 멀티에이전트 · MCP

에이전트 설계: 루프 · 워크플로 · 메모리 · 멀티에이전트 · MCP

에이전트(agent) 는 LLM이 도구를 부르고, 결과를 보고, 다음에 할 일을 스스로 정하는 일을 반복 하는 시스템입니다. 이 수업에서는 정해진 순서대로 흐르는 '워크플로'와 모델이 경로를 정하는 '에이전트'를 구분하고, 대표 설계 패턴 다섯 가지, 에이전트 루프의 구조, 메모리, 여러 에이전트를 나눠 쓰는 멀티에이전트, 도구 연결 표준 MCP, 그리고 단계가 길어질수록 오류가 쌓이는 문제를 숫자로 정리합니다.

들어가기 전에

• 도구 사용 · 함수 호출 · 구조화 출력 — 에이전트의 한 걸음은 도구 호출 한 번입니다.
• ReAct: 추론과 행동을 함께 — 생각 → 행동 → 관찰을 반복하는 원형.
• 프롬프트 설계와 인컨텍스트 학습 — 프롬프트 체이닝이 워크플로의 출발점입니다.

한눈에 보기

• '워크플로'와 '에이전트'를 구분하고, 언제 무엇을 쓸지 판단합니다.
• 프롬프트 체이닝 · 라우팅 · 병렬화 · 오케스트레이터-워커 · 평가자-최적화자 패턴을 압니다.
• 단계별 성공률이 0.95여도 20단계면 전체 성공률이 약 36%로 떨어지는 '오류 누적'을 계산합니다.
• 메모리를 최근성 · 중요도 · 관련성 점수로 꺼내는 방식을 직접 계산합니다.
• MCP가 무엇을 표준화하는지(호스트 · 클라이언트 · 서버, 도구 · 자원 · 프롬프트) 압니다.

1. 워크플로와 에이전트

직관(해설용 비유). 워크플로는 정해진 결재 라인, 에이전트는 재량권을 받은 담당자 입니다. 결재 라인은 예측 가능하고 싸지만 예외에 약하고, 담당자는 유연하지만 비용과 실수 가능성이 큽니다.

Anthropic의 글(2024)은 둘을 이렇게 나눕니다.

같은 글의 핵심 조언은 "가능한 가장 단순한 해법에서 시작해 필요할 때만 복잡도를 올려라" 입니다. 검색과 예시를 붙인 LLM 호출 한 번으로 충분한 경우가 많다고 합니다.

기본 부품: 확장된 LLM(augmented LLM). 검색 · 도구 · 메모리를 붙인 LLM입니다. 스스로 검색어를 만들고, 도구를 고르고, 무엇을 기억할지 정합니다. 아래 모든 패턴이 이 부품을 조합한 것입니다.

2. 워크플로 패턴 다섯 가지

체이닝은 지연을 늘리는 대신 정확도를 얻는 선택이라고 글은 설명합니다. 병렬화의 '투표'는 자기 일관성과 같은 아이디어입니다.

3. 에이전트 루프

구조. 에이전트는 보통 도구를 쓰는 LLM을 환경의 피드백을 받으며 반복 실행합니다(Anthropic 글). ReAct의 '생각 → 행동 → 관찰' 순환과 같습니다.

1234567891011flowchart TB
  G[목표 · 제약 받기] --> P[계획 · 다음 행동 결정]
  P --> T{도구가 필요?}
  T -->|예| C[도구 호출]
  C --> O[결과 관찰 · 메모리에 기록]
  O --> S{완료 조건 충족?<br/>최대 단계 · 예산 확인}
  S -->|아니오| P
  T -->|아니오| F[최종 답]
  S -->|예| F
  S -->|위험 행동| H[사람 확인 요청]
  H --> P

종료 조건이 꼭 필요합니다. ① 목표 달성 ② 최대 단계 수 ③ 토큰 · 비용 예산 ④ 같은 행동 반복 감지. 이 중 하나라도 없으면 루프가 끝없이 돌며 비용을 씁니다.

오류 누적. 단계마다 독립적으로 성공 확률 $p$ 라면 $n$ 단계 전체가 성공할 확률은

(해설용 단순 모형, 파이썬으로 계산.) 실제 에이전트는 실수를 관찰하고 고칠 수 있어 이보다 나을 수 있지만, 단계가 길수록 중간 점검 · 되돌리기 · 사람 확인이 중요한 이유 를 보여 줍니다. Anthropic 글도 자율성이 높을수록 비용과 오류 누적 위험이 커지므로 샌드박스에서 충분히 시험하고 안전장치를 두라고 권합니다.

4. 메모리

짧은 기억과 긴 기억.

• 짧은 기억(작업 기억): 지금 대화 · 작업의 문맥 창 안 내용. 길어지면 오래된 부분을 요약하거나 잘라 냅니다.
• 긴 기억: 파일 · DB · 벡터 저장소에 적어 두고 필요할 때 검색해 꺼냅니다. MemGPT는 운영체제의 메모리 계층처럼 문맥 창 안팎으로 정보를 옮기는 방식을 제안했습니다.

무엇을 꺼낼까: 생성형 에이전트의 점수. Park 외(2023)의 생성형 에이전트는 기억마다 세 점수를 매기고, 각각 0~1로 정규화해 더한 값이 높은 순으로 꺼냅니다(논문 구현에서는 가중치를 모두 1로 둠).

숫자로 해 보기(해설용, 정규화된 값). 질문: "다음 주 발표 준비 어떻게 하지?"

가장 최근인 커피 기억보다, 관련성 · 중요도가 높은 두 기억이 먼저 꺼내집니다.

5. 멀티에이전트

아이디어. 리드 에이전트가 일을 나눠 여러 하위 에이전트에게 각자의 깨끗한 문맥 으로 맡기고 결과를 종합합니다(오케스트레이터-워커의 에이전트 버전).

보고된 결과(Anthropic, 2025). 리드 Claude Opus 4 + 하위 Claude Sonnet 4 구성이 단일 Claude Opus 4 에이전트보다 사내 리서치 평가에서 90.2% 더 좋았다고 합니다. 같은 글은 BrowseComp 평가에서 토큰 사용량 하나만으로 성능 차이의 80%가 설명 되었고, 에이전트는 일반 채팅보다 약 4배, 멀티에이전트는 약 15배 많은 토큰을 쓴다고 밝혔습니다.

맞지 않는 경우(같은 글). 모든 에이전트가 같은 문맥을 공유해야 하거나 에이전트끼리 의존이 많은 일, 병렬로 나눌 부분이 적은 대부분의 코딩 작업은 아직 잘 맞지 않는다고 했습니다. 즉 멀티에이전트는 넓게 병렬 탐색하는 일에, 그 비용을 감당할 가치가 있을 때 씁니다.

숫자로 해 보기(해설용). 채팅 한 번에 2,000토큰이 든다면, 같은 질문을 멀티에이전트로 풀면 위 배수로 약 30,000토큰입니다. 토큰 단가가 같다면 비용도 약 15배입니다.

6. MCP: 도구 연결의 표준

문제. 데이터 소스나 도구가 하나 늘 때마다 앱마다 별도 연동 코드를 짜야 했습니다. Anthropic은 2024년 11월 25일, 이런 조각난 연동을 하나의 프로토콜로 바꾸자며 오픈 표준 MCP(Model Context Protocol) 를 공개했습니다.

구조(MCP 명세). JSON-RPC 2.0 메시지로 세 역할이 통신합니다.

서버가 제공하는 것은 자원(resources: 데이터 · 맥락), 프롬프트(prompts: 템플릿), 도구(tools: 모델이 실행할 함수) 입니다. 명세는 언어 서버 프로토콜(LSP)에서 영감을 받았다고 밝힙니다. 도구를 한 번 MCP 서버로 만들면 MCP를 지원하는 여러 앱에서 다시 쓸 수 있습니다.

보안 원칙(명세). 사용자가 모든 데이터 접근 · 작업에 명시적으로 동의하고 통제해야 하며, 호스트는 도구를 실행하기 전에 사용자 동의를 받아야 합니다. 도구 설명 같은 정보도 신뢰할 수 있는 서버에서 온 것이 아니면 신뢰하지 않는 데이터 로 다루라고 명시합니다.

7. 도구 설계(ACI)와 안전장치

Anthropic 글은 사람-컴퓨터 인터페이스(HCI)에 공을 들이듯 에이전트-컴퓨터 인터페이스(ACI) 에 공을 들이라고 합니다.

• 모델 입장에서 설명 · 인자만 보고 쓰는 법이 분명한지 확인합니다(신입 개발자에게 주는 문서처럼).
• 여러 입력으로 시험해 모델이 자주 하는 실수를 찾고 고칩니다.
• 실수하기 어렵게 인자를 바꿉니다. 글의 예: 디렉터리를 옮긴 뒤 상대 경로를 틀리던 문제를 절대 경로만 받도록 바꿔 없앴습니다.

정리한 세 원칙(같은 글). ① 설계를 단순하게 ② 계획 단계를 드러내 투명하게 ③ 도구 문서화와 시험을 꼼꼼하게.

운영 안전장치(해설용 체크리스트). 최소 권한, 되돌릴 수 없는 행동 전 사람 확인, 샌드박스 실행, 단계 · 비용 상한, 모든 도구 호출 로그, 외부 데이터 속 지시 무시.

연습 문제

1. 문의 메일을 '배송 · 환불 · 기타'로 나눠 각각 다른 프롬프트로 처리하려 합니다. 어떤 패턴인가요?
   • 풀이: 라우팅입니다. 분류 후 전문 경로로 보냅니다.
2. 단계 성공률 0.98인 에이전트가 30단계를 거쳐야 합니다. 단순 모형에서 전체 성공률은?
   • 풀이: $0.98^{30}\approx0.545$, 약 55%입니다.
3. 4절 표에서 질문이 "오늘 아침에 뭐 마셨지?"로 바뀌어 관련성이 (1.0, 0.0, 0.0)이 되면 1순위는?
   • 풀이: 커피 기억 $1.0+0.0+1.0=2.0$, 형식 지정 $0.4+0.8+0=1.2$, 시간 초과 $0+1.0+0=1.0$ 이므로 커피 기억입니다.
4. MCP에서 '사내 위키 검색 기능'을 제공하는 쪽은 호스트 · 클라이언트 · 서버 중 무엇인가요?
   • 풀이: 서버입니다. 호스트(LLM 앱) 안의 클라이언트가 그 서버에 연결합니다.

스스로 점검

1. 에이전트보다 워크플로를 먼저 고려해야 하는 이유는?
   • 답: 정해진 경로는 예측 가능하고 싸며 디버깅이 쉽습니다. 단계가 분명한 일에 자율성을 주면 비용과 오류 누적 위험만 커집니다.
2. 멀티에이전트가 단일 에이전트보다 좋은 결과를 낸 이유로 글이 든 핵심 요인은?
   • 답: 더 많은 토큰(탐색 · 추론량)을 병렬로 쓸 수 있다는 점입니다. 토큰 사용량이 성능 차이의 80%를 설명했습니다. 대신 비용이 크게 늡니다.
3. MCP 서버가 준 도구 설명을 그대로 믿으면 안 되는 이유는?
   • 답: 명세가 밝히듯 신뢰할 수 없는 서버의 설명은 조작될 수 있고, 도구는 임의 코드 실행이 될 수 있기 때문입니다. 사용자 동의와 권한 통제가 필요합니다.

용어 정리

더 깊이 보려면

• ReAct: 추론과 행동을 함께
• Reflexion: 말로 하는 강화학습 에이전트 — 실패를 글로 돌아보며 고치는 에이전트
• 생성형 에이전트 · MemGPT — 메모리 설계
• SWE-bench — 코딩 에이전트 평가
• Anthropic, Building effective agents: https://www.anthropic.com/research/building-effective-agents

다음에 볼 것

• 직접 해 보기: 도구를 부르는 에이전트 루프 만들기 — 오늘 배운 루프를 파이썬으로 직접 구현
• Reflexion: 말로 하는 강화학습 에이전트 — 루프에 '돌아보기'를 더한 연구
• AX란 무엇인가 — 에이전트를 회사 업무에 들이는 전환 관점(AX 트랙)
• 프로세스 재설계와 사람 검토 루프(HITL) — 에이전트 도입 단계와 사람 검토 위치

라이선스

본문은 KAITABASE 자체 해설입니다. 패턴 · 수치는 Anthropic 공식 글과 MCP 명세, 논문 원문에서 확인한 것만 옮겼습니다(2026-10 확인). 확률 · 점수 · 토큰 계산은 해설용 단순 모형이며 파이썬으로 검산했습니다.

출처

• Anthropic, Building effective agents (2024-12-19): https://www.anthropic.com/research/building-effective-agents
• Anthropic, How we built our multi-agent research system (2025-06-13): https://www.anthropic.com/engineering/multi-agent-research-system
• Anthropic, Introducing the Model Context Protocol (2024-11-25): https://www.anthropic.com/news/model-context-protocol
• Model Context Protocol Specification: https://modelcontextprotocol.io/specification/latest
• Yao 외, ReAct (2022): https://arxiv.org/abs/2210.03629
• Park 외, Generative Agents (2023): https://arxiv.org/abs/2304.03442
• Packer 외, MemGPT (2023): https://arxiv.org/abs/2310.08560