멀티 에이전트

지도 위치 : 1일차 · README 4장 여섯 층 전체 개관(①~⑥의 설계도) | 다음: 2차시 개발 환경 구성과 LLM API 호출 키워드 : 프로젝트 요구사항 분석과 자동화 범위 설정, 시스템 아키텍처 설계

이 차시를 다 읽으면

1. 에이전트를 유와 종차로 정의하고, 워크플로우 · 단일 호출과 무엇으로 갈리는지 말할 수 있다.
2. ⭐ 단일 호출 → 워크플로우 → 에이전트 → 멀티에이전트 사다리를 그리고, "충분하면 멈춘다"는 원칙을 설명할 수 있다.
3. 어떤 일에 에이전트를 써야 하는지 네 가지 기준(복잡도 · 가치 · 모델 능력 · 오류 비용) 으로 판단할 수 있다.
4. 오피스봇의 기능을 자동 / 사람 확인 / 사람만 세 칸으로 나누고, 완료 기준을 측정 가능하게 쓸 수 있다.
5. 여섯 층 아키텍처 초안을 그리고, 왜 평가셋을 첫날부터 만드는지 말할 수 있다.

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 하나입니다. "무엇을, 어디까지, 어떤 구조로 자동화할 것인가?" 아직 코드는 한 줄도 쓰지 않습니다. 이 과정은 첫 차시라 앞 차시가 없습니다. 대신 이 차시에서 정한 설계도(요구사항 · 자동화 범위 · 여섯 층 · 평가셋)가 24차시까지 계속 다시 불려 나옵니다.

---

1. 에이전트란 무엇인가

1.1 정의 — 같은 범주 안의 네 형제

LLM 응용 시스템 — [소프트웨어]인데, [ 대규모 언어 모델(LLM)을 부품으로 써서 글을 이해하거나 만들어 내는 일을 한다 ]는 점에서 규칙만으로 동작하는 일반 프로그램과 구별된다.

LLM (대규모 언어 모델) — [생성형 AI]인데, [ 대량의 글로 학습해 "지금까지의 글 다음에 올 조각"을 예측하는 방식으로 글을 만든다 ]는 점에서 이미지 생성 모델과 구별된다.

이 범주 안에 네 형제가 있습니다. 모두 LLM을 쓰지만 누가 다음 할 일을 정하는가 가 다릅니다.

도구 — [LLM 응용 시스템의 부품]인데, [ 모델이 "불러 달라"고 요청하면 코드가 실행해 주는 함수 ]라는 점에서 모델이 직접 만드는 글과 구별된다(5차시).

1.2 반례 — 이건 에이전트가 아닙니다

⚠️ "에이전트"라는 말은 마케팅에서 넓게 쓰입니다. 이 노트에서는 "반복하며 모델이 다음 행동을 정하는가" 로만 판정합니다.

1.3 비유 — 기억 보조용으로만

워크플로우는 정해진 조립 라인 , 에이전트는 재량을 가진 직원 , 멀티에이전트는 역할이 나뉜 팀 입니다. 조립 라인은 예측 가능하지만 예상 밖 부품이 오면 멈추고, 재량 있는 직원은 유연하지만 매번 같은 결과를 보장하지 않습니다.

---

2. ⭐ 누가 흐름을 정하는가 — 네 칸 사다리

2.1 사다리

        유연함 ↑  비용 ↑  예측 어려움 ↑
  ┌─────────────────────────────────────────────┐
4 │ 멀티에이전트   여러 모델이 서로 넘겨주며 흐름을 정함 │ 20~22차시
  ├─────────────────────────────────────────────┤
3 │ 에이전트       모델 하나가 반복하며 흐름을 정함     │ 9~11차시
  ├─────────────────────────────────────────────┤
2 │ 워크플로우     코드가 흐름을 정하고, 칸마다 모델 호출 │ 4, 7, 18~19차시
  ├─────────────────────────────────────────────┤
1 │ 단일 호출      모델 한 번                         │ 2~3차시
  └─────────────────────────────────────────────┘
        단순함 ↓  싸다 ↓  시험하기 쉬움 ↓

2.2 세 문장 중 문장 1 — 가장 단순한 것부터, 충분하면 멈춘다

한 번의 호출로 되면 워크플로우를 만들지 않고, 워크플로우로 되면 에이전트를 만들지 않고, 에이전트 하나로 되면 멀티에이전트를 만들지 않는다.

⭐ 사다리는 올라갈수록 좋아지는 등급표가 아닙니다. 위 칸은 유연함을 얻는 대신 비용 · 지연 · 예측 불가능성을 치릅니다. 그래서 설계의 첫 질문은 "얼마나 똑똑하게 만들까"가 아니라 "어느 칸이면 충분한가" 입니다.

앞으로 다시 만납니다 — 9차시에서 2칸에서 3칸으로 올라가는 순간(에이전트 루프)을 직접 만들고, 21차시에서 3칸에서 4칸으로 올라갈지를 이 문장으로 다시 판정합니다.

2.3 에이전트를 써야 하는가 — 네 가지 기준

⚠️ 네 기준은 동시에 봐야 합니다. 복잡도가 높아도 오류 비용이 크면 에이전트에게 맡기지 않고, 사람 승인을 끼운 워크플로우로 만듭니다(23차시).

💡 판단이 서지 않으면 한 칸 아래에서 시작 하세요. 워크플로우로 만들고 평가셋에서 "미리 정한 분기로는 안 되는 질문"이 모일 때 에이전트로 올라가면 됩니다.

2.4 반례 — 흔한 오해

---

3. 요구사항 분석과 자동화 범위

3.1 요구사항 — 두 종류

요구사항 — [설계 문서의 항목]인데, [ 시스템이 무엇을 해야 하고 어떤 조건을 지켜야 하는지 확인 가능한 문장으로 적는다 ]는 점에서 막연한 바람("편리했으면")과 구별된다.

⭐ 에이전트 서비스에서는 비기능 요구사항이 더 자주 사고를 냅니다. "연차를 알려 준다"는 금방 되지만, " 다른 사람의 연차는 알려 주지 않는다"는 처음부터 설계에 넣지 않으면 나중에 고치기 어렵습니다(8차시).

3.2 자동화 범위 — 세 칸

⚠️ "사람만" 칸은 비워 두기 쉬운데 가장 중요합니다. 오피스봇이 괴롭힘 신고에 그럴듯한 조언을 하는 순간 회사의 공식 입장처럼 읽힙니다. 이 칸의 요청은 의도 분류(4차시)에서 걸러 사람에게 넘깁니다.

앞으로 다시 만납니다 — "사람 확인" 칸은 8차시에서 쓰기 도구를 분리할 때, 23차시에서 승인 게이트(HITL)로 직접 구현할 때 다시 나옵니다.

3.3 ⭐ 완료 기준은 측정 가능하게

빈칸의 숫자는 팀이 정합니다. 이 노트는 숫자를 대신 정하지 않습니다. 중요한 것은 누가 재도 같은 결과가 나오는 문장 이어야 한다는 점입니다. 이것이 세 문장 중 문장 3 "근거와 측정이 없으면 믿지 않는다"의 첫 적용입니다.

---

4. 시스템 아키텍처 초안

4.1 여섯 층으로 본 오피스봇

 직원 ─ 사내 메신저 ─▶ ┌──────────────────────────────────────────────┐
                      │ ⑥ 서비스   API 서버 · 스트리밍 · 승인 화면        │ 23~24차시
                      │ ⑤ 협업     그래프 · 인사/IT/규정 에이전트 · 관리자  │ 18~22차시
                      │ ④ 기억     대화 세션 · 사용자 프로필               │ 16~17차시
                      │ ③ 지식     규정 PDF → 청크 → 벡터 DB → 출처 답변   │ 12~15차시
                      │ ② 행동     조회 도구 · 라우팅 · 루프 · 가드레일     │ 5~11차시
                      │ ① 호출     LLM API · 프롬프트 · 의도 분류          │ 1~4차시
                      └──────────┬───────────────────┬───────────────┘
                                 │ (내 서버 안)        │ (인터넷 너머)
                       사내 DB · 규정 문서        외부 LLM API (Claude)

4.2 아키텍처에 미리 그어 둘 선 두 개

4.3 ⭐ 평가셋을 첫날부터

평가셋 — [시험 데이터]인데, [ 실제로 들어올 질문과 그에 대한 기대 결과를 짝지어 고정해 둔 목록 ]이라는 점에서 개발자가 그때그때 떠올려 보는 예시 질문과 구별된다.

번호 | 질문                                   | 기대 의도  | 기대 도구            | 자동화 칸 | 비고
001  | 연차 며칠 남았어?                        | 휴가조회   | get_leave_balance   | 자동     |
002  | 노트북이 안 켜져요                        | IT장애    | (티켓 안내)          | 자동     |
003  | 김과장 연차 몇 개 남았는지 알려줘           | 휴가조회   | (차단)               | 자동     | 남의 데이터
004  | 모니터 하나 더 신청할게요                  | 장비신청   | (초안 → 확정)        | 사람 확인 |
005  | 팀장님한테 폭언을 들었어요                  | 기타      | (담당자 연결)         | 사람만   |

(예시 형식입니다. 실제 질문은 현업에서 모읍니다.)

왜 첫날인가 — 평가셋이 없으면 2~8차시 내내 "좋아진 것 같다" 는 느낌으로만 프롬프트와 도구를 고치게 됩니다. AI에게 구현을 맡기는 이 과정에서는 더욱 그렇습니다. AI의 "잘 동작합니다"를 내가 채점할 수단 이 평가셋뿐이기 때문입니다.

앞으로 다시 만납니다 — 이 평가셋은 3차시(프롬프트 개선 판정), 4차시(분류 정확도와 혼동표), 7차시(도구 선택 정확도), 15차시(검색 품질)에서 열이 하나씩 늘어나며 계속 쓰입니다.

---

5. 실습 — 맡기고 검수하기

이 차시는 설계 판단 의 차시입니다. AI는 초안 작성 보조로만 씁니다. 판단(자동화 칸, 완료 기준 숫자)은 내가 정합니다.

지시

사내 도우미 "오피스봇"의 요구사항 문서 초안과 평가셋 초안을 만들어줘.

목표:
- 기능 요구사항 / 비기능 요구사항을 나눠서 표로
- 기능마다 자동화 칸을 [자동 | 사람 확인 | 사람만] 중 하나로 제안하고, 근거를 한 줄씩
- 기능마다 사다리 칸 [단일 호출 | 워크플로우 | 에이전트 | 멀티에이전트] 중 가장 낮은 칸을 제안하고, 왜 한 칸 아래로는 안 되는지 한 줄
- 평가셋 초안 30문항: [번호 | 질문 | 기대 의도 | 기대 도구 | 자동화 칸 | 비고]
  의도는 휴가조회 / 규정질문 / 장비신청 / IT장애 / 기타 중 하나
  "남의 데이터 묻기" 3문항, "사람만" 칸 3문항, 의도가 애매한 질문 3문항 반드시 포함

제약:
- 완료 기준의 숫자는 채우지 말고 빈칸(___)으로 둘 것 — 숫자는 내가 정한다
- 실제 회사 규정 내용을 지어내지 말 것
- 파일로 저장: docs/requirements.md, eval/eval_set_v0.csv

보고 형식: 만든 파일 경로, 각 파일의 줄 수, 평가셋의 의도별 문항 수 표

받을 증거

• 두 파일의 경로와 내용 원문 (요약이 아니라 파일 그대로)
• 평가셋의 의도별 문항 수 표 — 한 의도에 몰려 있지 않은지

내가 직접 확인할 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 1차시 노트만 근거로 5문제를 내줘. 비전공자 기준으로.
"단일 호출·워크플로우·에이전트·멀티에이전트 사다리", "에이전트를 쓸지 판단하는 네 기준", "자동화 범위 세 칸", "측정 가능한 완료 기준"은 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.