실무 Multi-Agent 오케스트레이션 1장 · 에이전트 요구사항과 아키텍처 설계 7 / 8 ← 이전목차다음 → TechLead Cro

1장. 에이전트 요구사항과 아키텍처 설계

정리와 체크리스트

1장에서 배운 것

이번 장에서는 코드 없이 "무엇을, 왜 만드는가" 를 정했습니다.

  • LLM의 한계 — 일반 지식은 잘 답하지만, 실시간 정보와 사내 정보는 답하지 못하거나 환각으로 지어냅니다.
  • 에이전트 — LLM에 도구·지식·기억·루프를 붙여 실제로 일을 끝내게 만든 시스템입니다.
  • AI 애플리케이션과 에이전트의 차이 — "다음에 무엇을 할지 누가 결정하는가"입니다. 개발자가 정해 두면 애플리케이션, 모델이 정하면 에이전트입니다.
  • 멀티에이전트 — 일을 역할별 전문 에이전트에게 나누고 Supervisor가 지휘하는 구조입니다. 에이전트 하나로 부족해질 때 나눕니다.
  • 전문 에이전트 셋 — 주문조회(읽기), 정책안내(읽기), 요청처리(쓰기). 읽기와 쓰기를 나눠 위험한 도구를 쥔 쪽을 하나로 좁힙니다.
  • 로그 분석 — 만들기 전에 문의 로그를 센다. 유형별 건수가 자동화 순서를, 처리 결과가 목표를 정합니다.
  • 요구사항 — 표준 질문 12개. 처리하면 안 되는 일을 가려내고, 답하지 않아야 할 질문에 답하지 않는 것이 품질을 가릅니다.
  • 처리의 세 갈래 — 되돌릴 수 있는 일은 직접 처리, 돈이 나가는 되돌릴 수 없는 일은 승인 후 처리, 처리할 수 없는 일은 상담원에게.
  • 아키텍처 — 도구·지식·기억·오케스트레이션 네 구성요소.

한눈에 보는 핵심

에이전트 = LLM(두뇌) + 도구 + 지식 + 기억 + 루프

멀티에이전트 = 전문 에이전트 여럿 + 지휘하는 Supervisor + 사람의 승인과 사람에게 넘기는 길

처리 요청 = 직접 처리 / 승인 후 처리 / 상담원에게 (기준은 "되돌릴 수 있는가")


체크리스트

옆 사람에게 말로 설명할 수 있으면 통과입니다.

  • [ ] LLM이 "제 주문 어디까지 왔어요?"에 답하지 못하는 이유를 설명할 수 있다.
  • [ ] 환각이 무엇이고 왜 생기는지 설명할 수 있다.
  • [ ] 에이전트가 LLM에 붙이는 네 가지(도구·지식·기억·루프)를 각각 한 줄로 말할 수 있다.
  • [ ] AI 애플리케이션과 에이전트의 차이를 "누가 결정하는가"로 설명할 수 있다.
  • [ ] 에이전트 하나에 모든 일을 넣으면 생기는 문제를 두 가지 이상 말할 수 있다.
  • [ ] Supervisor가 하는 일과 하지 않는 일을 구분할 수 있다.
  • [ ] 전문 에이전트 셋의 이름과 맡는 일을 말하고, 읽기와 쓰기를 나눈 이유를 설명할 수 있다.
  • [ ] 문의 로그를 유형별·처리 결과별로 세면 각각 무엇이 정해지는지 말할 수 있다.
  • [ ] 표준 질문 12개 중 "답하지 않는 것이 정답"인 질문을 고를 수 있다.
  • [ ] 처리 요청 하나를 보고 직접 처리, 승인 후 처리, 상담원에게 중 어디에 해당하는지 가를 수 있다.
  • [ ] 처리해도 되는지를 모델이 아니라 코드가 판정하게 하는 이유를 말할 수 있다.
  • [ ] 아키텍처의 네 구성요소가 각각 어떤 질문 때문에 필요한지 말할 수 있다.

한 줄 핵심

LLM은 똑똑하지만 갇힌 두뇌입니다. 도구·지식·기억·루프를 붙이면 일하는 에이전트가 되고, 역할을 나눠 지휘하면 멀티에이전트가 됩니다. 처리는 되돌릴 수 있는 만큼만 맡깁니다.

← 이전 절전체 24장 지도 — 일곱 단계로 쌓아 올린다다음 절 →확인문제와 해답
오명운 · macro@prag-ai.com