21장. 전문 에이전트 구현

왜 전문 에이전트가 필요한가 — 다 할 줄 아는 하나보다, 하나씩 맡은 셋

한 줄 요약

지금까지 만든 도구와 규칙을 하나의 에이전트에 모두 넣을 수도 있습니다. 하지만 도구와 규칙이 많아질수록 모델이 도구를 잘못 선택하거나 일부 규칙을 놓칠 가능성이 커집니다. 이번 장에서는 역할을 나누어 주문조회·정책안내·요청처리 에이전트를 만듭니다. 주문조회와 정책안내 에이전트는 정보를 조회하고 안내하며, 요청처리 에이전트는 고객이 요청한 작업을 실제로 처리합니다.

---

1. 지금 손에 있는 것

여기에 이번 장에서 처리 도구 4개를 더 만듭니다. 배송지를 바꾸고, 교환을 접수하고, 환불·주문 취소의 승인 요청을 올리고, 처리 내역을 조회하는 도구입니다. 합치면 도구가 11개입니다.

11장에서는 create_agent로 에이전트 하나를 만들고 도구 다섯 개를 줬습니다. 같은 방식으로 도구 열한 개와 모든 규칙을 한 에이전트에 넣으면 만능 상담원이 될 것 같습니다.

---

2. 하나에 다 넣으면 생기는 일

앞 장들에서 이미 본 것들입니다.

마지막 두 줄이 중요합니다. 주문을 조회할 때 필요한 규칙, 정책을 안내할 때 필요한 규칙, 요청을 처리할 때 필요한 규칙은 서로 다릅니다. 이것을 한 프롬프트에 다 적으면 수십 줄이 되고, 모델은 그 가운데 지금 필요한 줄을 놓칠 수 있습니다.

처리 도구가 생기면 한 가지가 더해집니다. 조회 도구는 잘못 골라도 엉뚱한 답이 나올 뿐이지만, 처리 도구는 잘못 고르면 엉뚱한 일이 실제로 일어납니다. 배송지가 바뀌고, 교환이 접수됩니다. 열한 개가 한 목록에 섞여 있으면 "재고 있어요?"라는 질문 하나에도 처리 도구가 선택지에 함께 올라옵니다.

사람의 조직도 같은 길을 갔습니다. 한 사람이 조회도 하고 규정도 찾고 처리도 하는 대신, 일을 나누고 일마다 필요한 권한과 지침만 줍니다.

---

3. 19장과 20장에서 이미 절반은 했다

19장의 갈래 노드와 20장의 Worker는 "자기 일에 필요한 도구만 가진다"는 원칙을 지켰습니다. 그런데 둘 다 그 파일 안에서만 쓰는 함수였습니다.

---

4. 이걸 모르면 무엇을 판단하지 못하는가

• 에이전트를 어디서 잘라야 하는지 기준 없이 감으로 나누게 됩니다. 너무 잘게 나누면 호출만 늘고, 너무 크게 두면 나눈 보람이 없습니다.
• 에이전트에게 어디까지 맡겨도 되는지 정하지 못합니다. 배송지 변경은 맡겨도 되는가, 환불은 어떤가. 기준이 없으면 전부 사람에게 넘기거나 전부 에이전트에게 맡기게 됩니다.
• "출고 전인가, 반품 기간 안인가" 같은 가능 여부를 누가 판정해야 하는지 알지 못합니다. 모델에게 맡길 일과 코드가 할 일이 섞입니다.
• 에이전트가 자기 일이 아닌 질문을 받았을 때 어떻게 해야 옳은지 판단하지 못합니다. 아는 대로 답하는 것이 친절해 보이지만, 그것이 가장 위험합니다.

---

5. 이번 장에서 만드는 셋

1장에서 소개한 그 셋입니다.

이번 장의 산출물은 파일 세 개입니다.

이번 장에서는 셋을 만들고 하나씩 따로 시험합니다. 고객 문의를 받아 셋 가운데 누구에게 맡길지 정하는 일은 이번 장에서 다루지 않습니다.

---

핵심 정리

• 도구와 규칙을 한 에이전트에 모두 넣으면 호출이 비싸지고, 도구를 잘못 고르고, 규칙을 빠뜨립니다.
• 일마다 필요한 규칙이 다릅니다. 나누면 프롬프트가 짧아지고 한 가지 일에 집중합니다.
• 조회 도구를 잘못 고르면 답이 틀리지만, 처리 도구를 잘못 고르면 일이 실제로 일어납니다.
• 19장의 갈래 노드와 20장의 Worker를 재사용할 수 있는 모듈로 끌어올린 것이 전문 에이전트입니다.
• 이번 장의 산출물은 처리 도구 haru_actions.py 와 전문 에이전트 셋 haru_agents.py 입니다.