AX LABS
← 블로그 에이전트 제품 설계

툴 조율이 에이전트 품질이다

순서보다 실패 경로를 먼저 설계한다

AX LABS 5분 읽기

현장에서 에이전트가 실패하는 장면은 대체로 비슷하다. 모델이 답을 몰라서가 아니다. 같은 API를 두 번 호출하고, 조회 전에 결재를 먼저 시도하고, 실패한 도구를 다시 부르며, 마지막에는 그럴듯한 요약으로 덮는다. 문제는 prompt가 아니라 tool orchestration이다.

에이전트 설계자는 “어떤 tool을 붙일까”보다 “어떤 순서로, 어떤 조건에서, 어디까지 재시도하고, 누가 합칠 것인가”를 먼저 정해야 한다. 이 설계가 없으면 MCP, Agent SDK, function calling은 모두 더 빠른 혼란이 된다.

순차 실행은 통제가 필요한 업무의 기본값이다

순차 패턴은 느리지만 안전하다. 앞 단계의 결과가 뒤 단계의 입력이 되는 업무에서는 병렬화가 품질을 깨뜨린다. 고객 조회 후 권한 확인, 권한 확인 후 주문 변경, 주문 변경 후 알림 발송이 그런 흐름이다.

OpenAI Agents SDK와 Anthropic Claude Agent SDK 모두 최근 문서에서 tool, handoff, tracing, 권한 제어를 실행 흐름의 핵심 구성요소로 다룬다. 이는 에이전트를 “대화형 모델”이 아니라 “도구를 쓰는 실행 시스템”으로 봐야 한다는 신호다.

순차 실행의 핵심은 단계 이름을 붙이는 것이다. 조회 → 판단 → 실행 → 검증 → 보고처럼 나누면 실패 지점이 보인다. 반대로 “처리해줘” 하나로 묶으면 에이전트의 판단과 실행이 한 덩어리가 된다. 운영에서는 이 덩어리가 사고가 된다.

에이전트의 자율성은 tool 호출 권한이 아니라 실행 경로의 명료함에서 나온다.

병렬 실행은 독립 작업에만 쓴다

병렬 패턴은 빠른 처리가 아니라 독립 검증을 위해 쓴다. 같은 질문에 대해 사내 문서, 계약서, 티켓 이력, 웹 검색을 동시에 조회하는 것은 병렬화할 수 있다. 하지만 결제 승인과 재고 차감은 병렬화하면 안 된다.

Google ADK 문서는 ParallelAgent로 여러 연구 에이전트를 동시에 실행하고, 이후 SequentialAgent에서 병합 에이전트가 결과를 합치는 구조를 제시한다. 이 구조가 중요한 이유는 병렬 실행 자체가 아니라 “merge 단계”를 별도 책임으로 둔다는 점이다.

패턴 쓰는 경우 설계 기준
순차 의존성이 강한 업무 다음 단계 입력을 명시한다
병렬 독립 조회·검증 병합 책임자를 둔다
재시도 일시 장애·형식 오류 오류 유형별 정책을 둔다
파이프라인 반복 운영 업무 고정 골격 안에 판단 지점을 둔다

병렬 실행의 위험은 결과 충돌이다. 한 tool은 “가능”이라고 하고, 다른 tool은 “불가”라고 말한다. 이때 모델에게 알아서 판단하라고 두면 안 된다. 우선순위, 최신성, 원천 시스템 권위를 규칙으로 박아야 한다.

재시도는 신뢰성이 아니라 책임 설계다

재시도는 가장 자주 오해되는 패턴이다. 실패하면 다시 부르면 된다는 생각은 위험하다. 읽기 tool은 재시도해도 된다. 쓰기 tool은 다르다. 주문 생성, 메일 발송, 티켓 종료, 파일 삭제는 재시도가 중복 실행으로 이어진다.

재시도 설계에는 네 가지가 필요하다.

  1. 오류 분류: 인증 오류, rate limit, timeout, schema mismatch를 구분한다.
  2. 멱등성 키: 같은 의도를 같은 실행으로 묶는다.
  3. 중단 기준: 최대 횟수보다 업무 위험도가 기준이다.
  4. 보상 동작: 잘못 실행된 결과를 되돌릴 절차를 둔다.

MCP 명세가 JSON Schema 검증과 프로토콜 구조를 강조하는 이유도 여기에 있다. tool 호출은 자연어가 아니라 계약이다. 계약이 없으면 재시도는 복구가 아니라 반복 사고가 된다.

Anthropic의 Agent SDK 권한 문서는 hook, permission rule, runtime callback을 통해 tool 사용을 제어하는 방식을 설명한다. 운영형 에이전트에서는 이 계층이 필요하다. 어떤 tool은 자동 실행하고, 어떤 tool은 사람 승인을 받고, 어떤 tool은 아예 차단해야 한다.

파이프라인은 에이전트를 업무 안에 묶는다

파이프라인 패턴은 순차·병렬·재시도를 하나의 운영 흐름으로 묶는다. 예를 들면 입력 정규화 → 병렬 조회 → 충돌 해소 → 실행 계획 → 사람 승인 → tool 실행 → 검증 → 기록이다.

여기서 모델은 모든 것을 결정하지 않는다. 모델은 애매한 판단, 문서 해석, 예외 분류를 맡는다. 상태 전이, 권한, 로그, 재시도, 승인선은 코드와 정책이 맡는다. 이것이 harness engineering의 핵심이다.

좋은 에이전트는 똑똑한 모델 하나가 아니다. 작은 tool, 명시적 상태, 좁은 권한, 관찰 가능한 trace, 실패 시 멈추는 규칙의 조합이다. OpenAI Agents SDK의 tracing 문서가 LLM generation, tool call, handoff, guardrail을 추적 대상으로 두는 것도 같은 방향이다.

AX Ops에서 tool orchestration은 구현 후반의 엔지니어링 이슈가 아니다. 업무를 재설계할 때 먼저 정해야 하는 운영 골격이다. 순차·병렬·재시도·파이프라인을 업무 책임과 함께 설계해야 에이전트가 PoC를 넘어선다.

참고

에이전트 제품은 tool 목록이 아니라 운영 경로로 설계해야 한다. 구현 전 실행 골격부터 정하려면 AX Ops 방법론 →