왜 하나에 도구를 다 몰아넣지 않는가 — 역할 분리
한 줄 요약
도구를 나누는 것은 성능이 아니라 판단의 문제입니다. 도구가 하나뿐인 담당자는 고를 것이 없고, 틀렸을 때 어디를 고쳐야 하는지 분명해집니다.
1. 사람으로 생각해 보기
회사에 이런 사람이 있다고 합시다.
"우리 회사의 모든 데이터를 다루고, 모든 규정을 알고, 시장 조사도 하는 사람"
가능은 합니다. 그런데 일이 많아지면 어떻게 될까요?
- 어느 자료를 봐야 할지 매번 고민한다
- 실수하면 어느 단계에서 틀렸는지 본인도 모른다
- 새 사람을 뽑아 인수인계하기 어렵다
그래서 실제 회사는 역할을 나눕니다. 데이터 담당, 법무 담당, 마케팅 담당.
에이전트도 같은 이유로 나눕니다.
2. 도구가 늘면 무슨 일이
4장 4절에서 짚은 것을 다시 봅시다.
도구 2개 → 대체로 잘 고른다
도구 5개 → 가끔 헷갈린다
도구 10개 → 자주 헷갈린다
도구 20개 → 명세만으로 토큰을 크게 먹는다
이유는 셋이었습니다.
- 설명이 비슷하면 도구를 혼동한다
- 명세 자체도 토큰을 사용한다
- 판단할 것이 많아진다
3. 실제로 난 사고
이 과정의 8장 코드를 만들 때 실제로 겪은 일입니다. 6장 9절에서 예고했던 그것입니다.
처음 담당 설명
아래는 개념 설명용 코드입니다 — 실습 파일에 넣지 않습니다. (사고가 났던 옛 버전이라 실습 파일에는 들어가지 않습니다. 주문담당은 뒤에 추가되므로 여기에는 아직 없습니다.)
ROLE_DESC = {
"데이터분석가": "주문·재고·리뷰 CSV 를 계산한다 (매출, 재고, 판매 추이, 평점)",
"규정담당": "사내 규정과 제품 매뉴얼을 검색한다 (환불 기간, 제품 사양)",
"시장조사원": "인터넷을 검색한다 (경쟁 제품, 시장 반응)",
}
그럴듯해 보입니다. 그런데 이 질문에서 사고가 났습니다.
답이 아주 그럴듯합니다. 오류도 안 났습니다. 그런데 완전히 틀렸습니다.
원인
reorder_level 은 inventory.csv 의 열입니다. 규정 문서에 있을 리가 없죠.
그런데 "재주문 기준"이라는 말이 규정처럼 들립니다. 팀장(플래너)이 그래서 규정담당에게 보낸 것입니다.
고친 방법
아래는 3절에서 만들 code/ch08_multi_agent.py 의 일부를 미리 보는 것입니다 — 지금 붙여 넣지 않아도 됩니다.
ROLE_DESC = {
"주문담당": "주문번호 하나의 상태를 조회한다 — 고객·상품·금액·주문일·배송상태. "
"'O001203' 같은 주문번호가 질문에 있을 때만 부른다. 집계나 통계는 못 한다.",
"데이터분석가": "사내 CSV 를 계산한다 — 매출·판매 추이, 재고 수량과 재주문 기준(reorder_level), "
"리뷰 평점과 부정 리뷰 내용. 사내 '숫자'는 전부 여기 있다.",
"규정담당": "사내 문서를 검색한다 — 환불·교환 기간, 멤버십 등급, 제품 사양(배터리·방수 등). "
"재고나 매출 같은 수치는 여기 없다.",
"시장조사원": "인터넷을 검색한다 — 경쟁 제품, 시장 동향, 바깥 사용자 반응.",
}
최종 담당은 넷입니다. 주문담당은 3장 에이전트를 그대로 데려온 것으로, 위 사고와는 별개로 처음부터 팀에 들어 있습니다.
문제를 해결하려고 바꾼 것은 두 가지입니다.
재주문 기준(reorder_level)— 헷갈리는 항목의 이름을 정확히 명시재고나 매출 같은 수치는 여기 없다— 안 하는 일을 적음
결과:
[계획]
→ 데이터분석가: 승승 스마트워치 Fit 5(P0003)의 재주문 기준을 채우기 위해
필요한 발주 수량을 계산해 주세요.
[데이터분석가 보고]
재주문 기준을 채우기 위해 필요한 발주 수량은 27개입니다.
[최종 답변]
승승 스마트워치 Fit 5(P0003)를 27개 발주하십시오.
모델을 바꾼 게 아닙니다. 설명 두 줄을 고쳤습니다.
4장 4절에서 "언제 안 쓰는지도 적어라"고 한 것이 정확히 이 이야기입니다. "~는 여기 없다" 한 문장이 사고를 막았습니다.
4. 나누면 좋아지는 것 셋
① 각자의 판단이 쉬워진다
[데이터분석가가 받는 것]
도구: run_pandas 하나
질문: "재주문 기준을 채우려면 몇 개 발주해야 하나요?"
→ 고를 것이 없다. 그냥 계산하면 된다.
도구 선택이라는 문제 자체가 사라집니다.
② 어디서 틀렸는지 보인다
[데이터분석가 보고] 재고 3개 / 평균 3.8점 ← 맞음
[규정담당 보고] 문서에 없음 ← 여기가 이상하다
[시장조사원 보고] 시장은 성장세 ← 맞음
보고가 담당별로 나오므로 어디가 문제인지 바로 보입니다. 한 에이전트라면 최종 답 하나만 나와서 추적이 어렵죠.
③ 담당별로 개선할 수 있다
규정담당이 자꾸 틀린다면 — 규정담당의 시스템 지시와 k 값만 손보면 됩니다. 다른 담당은 안 건드려도 됩니다.
실제로 그렇게 고쳤습니다. 6장 8절에서 k 를 4에서 6으로 올린 그 수정이 규정담당만을 위한 것이었죠.
5. 나눠서 나빠지는 것
한계도 짚고 넘어갑니다.
① 호출이 늘어난다
[한 명] 도구 2번 쓰면 LLM 호출 3번
[나누면] 플래너 1 + 작업마다 2번 이상 + 종합 1
작업 3개 → 8번 · 작업 8개 → 18번
2~6배입니다. 비용도 시간도 그만큼 듭니다.
② 계획이 틀리면 전부 틀린다
플래너가 잘못 나누면 워커들이 아무리 잘해도 답이 틀립니다. 위의 사고가 정확히 그 경우였죠.
한 에이전트라면 도구를 잘못 골라도 결과를 보고 다시 시도할 기회가 있습니다(ReAct 루프). 플래너-워커 구조에서는 계획이 한 번에 정해집니다.
이 약점을 줄이는 방법이 있습니다 — 종합 단계에서 "정보가 부족하다"고 판단하면 다시 계획을 세우게 만드는 것이죠. 그러면 그래프에 되돌아가는 화살표가 생깁니다. 이 과정에서는 안 합니다. 구조가 복잡해지고, 실습에서는 한 바퀴로 충분하기 때문입니다.
③ 담당끼리 정보를 못 나눈다
데이터분석가: "리뷰에 배터리 불만이 많다"
규정담당: (그 사실을 모른 채) "사양은 7일/18시간이다"
각자 따로 조사하므로, 서로의 발견을 활용하지 못합니다. 합치는 것은 종합 단계의 몫입니다.
이 과정의 구조에서는 그걸로 충분합니다. 더 정교하게 하려면 담당끼리 대화하게 만드는 방법도 있지만, 훨씬 복잡해집니다.
6. 언제 나누고 언제 안 나누나
| 상황 | 권장 |
|---|---|
| 도구 1~3개, 한 영역 | 한 에이전트 |
| 도구가 5개 이상 | 나눈다 |
| 성격이 다른 자료원(CSV·문서·웹) | 나눈다 |
| 담당별로 다른 규칙이 필요 | 나눈다 |
| 답이 빨라야 함 | 한 에이전트 |
| 어디서 틀렸는지 추적해야 함 | 나눈다 |
이 과정의 8장은 두 번째와 세 번째 조건에 해당합니다.
7. 정리 — AI가 한 것과 사람이 한 것
| 누가 | 무엇 |
|---|---|
| AI(플래너) | 질문을 읽고 누구에게 무엇을 물을지 결정 |
| AI(워커) | 각자 도구를 써서 조사 |
| AI(종합) | 보고를 하나의 판단으로 |
| 사람 | 담당을 몇 명으로 나눌지 |
| 사람 | 각 담당에게 어떤 도구를 줄지 |
| 사람 | 각 담당의 역할 설명 — 특히 "안 하는 일" |
| 사람 | 나누는 것이 맞는지 판단 |
위 문제를 해결한 것은 AI가 아니라 사람이었습니다. 역할 설명 두 줄을 고친 것이죠.
핵심 정리
- 도구를 나누는 것은 성능이 아니라 판단의 문제입니다.
- 도구가 늘면 — 설명이 비슷한 것끼리 헷갈리고, 명세가 토큰을 쓰고, 판단할 것이 많아집니다.
- 실제 사고 — "재주문 기준"을 규정담당에게 보내 "문서에 없음"이라는 그럴듯한 오답이 나왔습니다.
- 고친 방법은 역할 설명 두 줄이었습니다 — 헷갈리는 항목의 이름을 정확히 명시하고, "~는 여기 없다" 를 추가.
- 나눠서 좋아지는 것 — 각자의 판단이 쉬워지고, 어디서 틀렸는지 보이고, 담당별로 개선할 수 있습니다.
- 나눠서 나빠지는 것 — 호출이 2~6배, 계획이 틀리면 전부 틀리고, 담당끼리 정보를 못 나눕니다.
- 자료원의 성격이 다를 때(CSV·문서·웹) 나누는 것이 특히 효과적입니다.
- 역할 설명을 쓰는 것은 사람의 일입니다. 문제도 거기서 생기고, 해결책도 거기서 찾습니다.