다단계 추론용 도구 정의와 Agent Bricks

Design Applications 영역의 마지막 두 출제 목표는 「다단계 추론을 위한 도구를 정의하고 순서를 정한다」와 「Agent Bricks를 언제 쓸지 판단한다」입니다. 앞 노트에서 체인은 사람이 순서를 못 박은 것이고 에이전트는 모델이 정한다고 갈랐는데, 모델이 정하게 하려면 무엇을 고를 수 있는지 모델이 읽을 수 있는 형태로 적어 줘야 합니다. 그것이 도구 정의입니다. 문항은 「이 도구 설명의 문제는」·「이 요구에 맞는 Agent Bricks는」처럼 나옵니다.

도구 정의는 모델이 읽는 문서다

도구(tool)는 에이전트가 부를 수 있는 함수 하나입니다. 정의는 세 조각으로 되어 있고, 셋 다 모델이 실제로 읽습니다.

셋 중 설명이 정확도를 가장 크게 좌우합니다. 모델은 코드를 보는 것이 아니라 이 문장을 보고 고르기 때문입니다. 설명에는 하는 일뿐 아니라 언제 쓰고 언제 쓰지 않는지를 함께 적습니다. 「주문을 조회합니다」보다 「주문번호가 이미 있을 때 그 주문의 상태·금액·발송일을 조회합니다. 주문번호를 모를 때는 쓰지 마십시오」가 훨씬 잘 듣습니다.

Databricks에서 도구를 두는 가장 표준적인 자리는 Unity Catalog 함수입니다. SQL이나 Python 함수를 UC에 만들어 두면 3단 이름으로 관리되고 권한이 걸리며, 에이전트에 그대로 붙일 수 있습니다. 모델이 읽는 설명이 되는 것이 COMMENT입니다.

CREATE OR REPLACE FUNCTION main.agents.lookup_order(
  order_id STRING COMMENT '조회할 주문번호. 예: ORD-10293'
)
RETURNS TABLE (status STRING, amount DOUBLE, shipped_at DATE)
COMMENT '주문번호가 이미 있을 때 그 주문의 상태·금액·발송일을 조회합니다. 주문번호를 모르면 쓰지 마십시오.'
RETURN SELECT status, amount, shipped_at
       FROM main.ops.orders WHERE id = order_id;

파라미터 스키마는 후보가 정해진 값을 열어 두지 않는 것이 요령입니다. 상태 코드가 넷뿐이라면 자유 문자열로 받지 말고 후보를 설명에 못 박습니다. 값이 열려 있을수록 모델이 그럴듯한 값을 지어냅니다.

지식 수집 도구와 행동 도구

도구는 읽는 것과 바꾸는 것 둘로 갈립니다. 이 구분이 설계와 안전 양쪽에서 계속 쓰입니다.

지식 수집 도구(retrieval·조회)는 부작용이 없습니다. Vector Search 인덱스를 감싼 검색 도구, 테이블 조회 함수, 외부 API의 GET 호출이 여기입니다. 여러 번 불러도 상태가 달라지지 않으므로 모델이 자유롭게 시도해도 위험이 작습니다.

행동 도구(action)는 바깥 상태를 바꿉니다. 환불 처리, 메일 발송, 티켓 생성, 레코드 갱신이 여기입니다. 한 번 더 부르면 한 번 더 일어나므로 설계가 달라집니다.

• 권한을 좁힙니다. 행동 도구는 필요한 대상에만 걸린 권한으로 돌게 합니다.
• 되돌릴 수 없는 것은 사람의 확인을 답니다. 금액이 큰 환불처럼 되돌리기 어려운 일은 에이전트가 바로 실행하지 않고 확인 단계를 둡니다.
• 같은 요청을 두 번 받아도 한 번만 일어나게 합니다. 요청 식별자를 인자로 받아 중복 실행을 걸러 냅니다.

문항이 「어떤 도구에 사람 확인을 붙여야 하는가」라고 물으면 답은 늘 되돌릴 수 없는 행동 도구 쪽입니다. 조회 도구에 확인을 붙이는 보기는 비용만 늘리는 오답입니다.

호출 순서 정하기

에이전트가 순서를 정하지만, 정할 수 있게 재료를 깔아 주는 것은 설계자의 일입니다.

1. 의존 관계를 설명에 적습니다. 「이 도구는 customer_id가 필요합니다. 고객 조회 도구로 먼저 얻으십시오」처럼 앞 도구를 지목합니다.
2. 범위를 좁히는 도구를 먼저 부르게 합니다. 검색·필터가 앞에 서야 뒤 도구의 호출 수와 비용이 줄어듭니다.
3. 행동은 마지막에 둡니다. 조회로 사실을 다 모으고 나서 바꾸게 해야 잘못된 행동을 되돌릴 일이 줄어듭니다.
4. 도구 수를 줄입니다. 후보가 많아질수록 잘못 고를 확률이 오릅니다. 하는 일이 비슷한 도구 둘은 하나로 합치는 편이 낫습니다.

그리고 순서가 늘 같다면 애초에 에이전트가 아닙니다. 매번 조회 → 요약 → 저장이라면 체인으로 못 박는 쪽이 싸고 빠르고 디버깅도 쉽습니다. 「모델이 순서를 정할 필요가 있는가」가 에이전트를 고르는 기준입니다.

Agent Bricks 셋

Agent Bricks는 흔한 에이전트 패턴을 설정만으로 만들어 주는 빌더입니다. 직접 코드를 짜는 Agent Framework보다 한 층 위이고, 시험은 요구를 읽고 셋 중 하나를 고르게 합니다.

셋 다 공통으로 얹어 주는 것이 있습니다. 만들어진 에이전트는 그대로 엔드포인트로 배포되고, 품질 평가와 모니터링이 처음부터 붙어 나옵니다. 그래서 「빨리 세워 보고 품질을 재 보자」는 요구에 특히 맞습니다.

가르는 기준은 출력의 모양과 대상의 수입니다. 출력이 답변이면 Knowledge Assistant, 출력이 정해진 필드 묶음이면 Information Extraction, 다룰 대상이 문서가 아니라 이미 있는 에이전트들이면 Multiagent Supervisor입니다.

Agent Bricks를 쓰지 않을 자리

빌더가 좋은 만큼 안 맞는 자리도 분명합니다.

• 순서가 고정된 단순 파이프라인 — 에이전트가 아니라 체인의 일입니다.
• 오케스트레이션 자체를 세밀하게 제어해야 할 때 — 조건 분기, 재시도 정책, 중간 상태 저장을 직접 다뤄야 하면 Agent Framework로 짭니다.
• 부작용이 큰 행동을 여러 개 다뤄야 할 때 — 확인 절차와 권한을 손으로 설계해야 합니다.
• 모델이 필요 없는 일 — 테이블 조회와 집계는 SQL이 훨씬 싸고 정확합니다.
• 도구를 새로 만들어 붙여야 할 때 — 사내 시스템을 호출하는 도구는 결국 손으로 정의해야 합니다.

한 줄로 줄이면 패턴이 흔하고 설정으로 충분하면 Agent Bricks, 흐름을 직접 쥐어야 하면 Agent Framework, 순서가 고정이면 체인입니다. 이 세 갈래를 고르는 문항이 설계 영역에서 반복해 나옵니다.

연습 문제

1. 다음 도구 설명 중 에이전트의 선택 정확도가 가장 높을 것은?
   ① 「주문 도구」
   ② 「주문을 처리합니다」
   ③ 「주문번호가 있을 때 상태·금액·발송일을 조회합니다. 주문번호를 모르면 쓰지 마십시오」
   ④ 「SELECT status, amount FROM orders WHERE id = ?를 실행합니다」

   ③. 하는 일과 함께 언제 쓰지 않는지까지 적혀 있습니다. ④는 무엇을 위한 도구인지 판단할 재료가 없습니다.
2. 다음 중 행동 도구로 분류되는 것을 둘 고르시오.
   ① Vector Search 인덱스에서 유사 문서 검색
   ② 고객에게 환불 처리
   ③ 주문 테이블 조회
   ④ 담당자에게 알림 메일 발송
   ⑤ 사내 위키 문서 읽기

   ②와 ④. 바깥 상태를 바꾸고 두 번 부르면 두 번 일어납니다. 나머지는 부작용이 없는 지식 수집 도구입니다.
3. 계약서 PDF 3천 건에서 계약 금액·시작일·만료일·당사자를 뽑아 테이블로 만들어야 합니다. 알맞은 것은?
   ① Knowledge Assistant
   ② Information Extraction
   ③ Multiagent Supervisor
   ④ Vector Search 엔드포인트만 만든다

   ②. 출력이 정해진 필드 묶음이면 Information Extraction입니다. ①은 출력이 답변인 QA 자리입니다.
4. 에이전트 도구 호출 순서를 설계할 때의 원칙을 순서대로 배열하시오.
   (가) 상태를 바꾸는 도구를 부른다
   (나) 범위를 좁히는 검색·필터 도구를 부른다
   (다) 필요한 식별자와 사실을 조회로 모은다

   (나) → (다) → (가). 좁히고, 사실을 모으고, 마지막에 바꿉니다. 행동을 앞에 두면 잘못된 실행을 되돌려야 합니다.
5. 사내에 인사팀·재무팀·법무팀 에이전트가 이미 배포되어 있고, 직원의 질문을 알맞은 에이전트로 보내 답을 받아 오는 창구가 필요합니다. 알맞은 것은?
   ① Knowledge Assistant
   ② Information Extraction
   ③ Multiagent Supervisor
   ④ 세 에이전트를 하나로 합쳐 다시 만든다

   ③. 다룰 대상이 문서가 아니라 이미 있는 에이전트들이면 감독자 구조입니다.
6. 「매일 밤 어제 접수된 문의를 조회해 요약하고 결과를 테이블에 쓴다. 단계는 늘 같다」는 요구에 가장 알맞은 구성은?
   ① 도구 다섯 개를 붙인 에이전트
   ② Multiagent Supervisor
   ③ 순서를 못 박은 체인
   ④ Knowledge Assistant

   ③. 순서가 고정이면 모델이 순서를 정할 이유가 없습니다. 체인이 더 싸고 빠르며 실패 지점도 분명합니다.
7. 도구 정의에서 파라미터를 자유 문자열로 열어 두었을 때 생기기 쉬운 문제는?
   ① 도구 호출 자체가 차단된다
   ② 모델이 후보에 없는 값을 지어내 호출이 실패한다
   ③ 설명이 무시된다
   ④ 권한 오류가 난다

   ②. 값의 후보가 정해져 있다면 스키마와 설명에 못 박아야 합니다.
8. 금액이 큰 환불을 처리하는 도구에 붙이는 장치로 알맞은 것을 둘 고르시오.
   ① 같은 요청 식별자로 두 번 불려도 한 번만 실행되게 한다
   ② 사람의 확인 단계를 둔다
   ③ 도구 설명을 짧게 줄인다
   ④ 조회 도구에도 같은 확인을 붙인다
   ⑤ temperature를 올린다

   ①과 ②. 되돌릴 수 없는 행동에는 중복 방지와 사람 확인이 붙습니다. ④는 비용만 늘리고, ⑤는 선택을 더 흔듭니다.

여기까지가 설계 영역입니다. 이 영역의 문항은 결국 모델에게 무엇을 얼마나 정해 주는가를 묻습니다. 형식을 정해 주면 프롬프트, 단계까지 정해 주면 체인, 도구만 주고 순서를 맡기면 에이전트, 그 패턴이 흔하면 Agent Bricks입니다. 요구를 읽고 이 네 칸 중 어디인지 먼저 정하면 보기가 대개 하나로 좁혀집니다.