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

도구 호출은 IR로 다뤄야 한다

실행 전 정책 검사가 하네스의 본체다

AX LABS 6분 읽기

에이전트 PoC는 대개 잘 움직인다. 사용자가 요청하고, 모델이 tool을 고르고, JSON 인자를 만들고, 함수가 실행된다. 문제는 운영 전환 회의에서 시작된다. 보안팀은 “이 호출이 허용된 근거가 어디 있느냐”고 묻고, 현업은 “실행 전 승인 조건을 다르게 걸 수 있느냐”고 묻고, 개발팀은 “모델 출력이라 재현이 어렵다”고 답한다.

이때 하네스 설계가 드러난다. 도구 호출을 곧바로 코드 실행으로 보내는 구조는 데모 구조다. 운영 구조는 모델이 만든 호출을 먼저 action IR로 컴파일하고, 그 IR을 정책 엔진이 검사한 뒤, 마지막에 어댑터가 실제 tool로 변환한다.

모델 출력은 실행 명령이 아니다

MCP 2025-11-25 specification은 tool calling, authorization, tool naming, tasks 같은 실행 표면을 계속 넓히고 있다. 최신 MCP changelog도 sampling request의 tools와 toolChoice, authorization 개선, task 추적을 주요 변경으로 적고 있다. 이는 tool 연결이 표준화되고 있다는 뜻이지, 각 기업의 실행 정책까지 자동으로 해결된다는 뜻이 아니다. (modelcontextprotocol.io)

Microsoft가 2026년 공개한 Agent Governance Toolkit 설명도 같은 지점을 짚는다. MCP는 discovery와 invocation 표면을 제공하지만, “이 agent가 이 tool을 이 인자로 지금 호출해도 되는가”를 판단하는 내장 checkpoint가 부족하다. 그래서 AGT는 tool call 앞단에서 policy enforcement를 수행하는 control plane으로 제안됐다. (developer.microsoft.com)

모델은 의도를 만든다. 실행 권한은 하네스가 판정한다.

이 구분이 없으면 prompt가 곧 권한이 된다. 현장에서 반복되는 실패는 모델 품질 문제가 아니라 경계 설계 문제다.

action IR은 감사 가능한 계약이다

Programmatic Tool Calling IR은 모델 출력과 실제 tool 실행 사이의 중간 표현이다. 이름은 거창하지만 구조는 단순해야 한다. 사람이 읽고, 정책 엔진이 검사하고, trace로 남길 수 있어야 한다.

구분 직접 tool call action IR 경유
모델 역할 tool과 인자 생성 실행 의도 생성
하네스 역할 호출 전달 컴파일·정책 검사·승인
정책 위치 tool 내부 또는 사후 로그 실행 전 중앙 판단
감사 단위 함수 로그 actor, resource, action, reason
실패 처리 예외 처리 deny, require_approval, rewrite, dry_run

IR에는 최소한 다음 필드가 들어간다.

  • actor: 사용자, agent, subagent, 위임 주체
  • action: 업무 의미의 동사. 예: invoice.approve, repo.write_file
  • resource: 대상 시스템, 데이터 등급, 범위
  • args: schema 검증이 끝난 정규화 인자
  • policy_context: 시간, 채널, 세션, 승인 상태, risk label
  • execution_plan: dry-run, idempotency key, rollback hint, timeout

핵심은 tool 이름을 정책의 중심에 두지 않는 것이다. mcp__server__action 같은 이름은 어댑터 레벨의 식별자다. 정책은 업무 행위와 자원 단위로 써야 오래 간다. Claude Agent SDK의 hooks도 PreToolUse, PostToolUse 같은 실행 이벤트에서 개입할 수 있고, MCP tool naming 패턴을 노출한다. 이 훅은 좋은 삽입점이지만, 훅 안에서 판단할 객체는 raw tool input이 아니라 정규화된 IR이어야 한다. (code.claude.com)

정책 검사는 실행 직전에 고정돼야 한다

정책 검사는 prompt에 쓰는 문장이 아니다. deterministic check로 고정해야 한다. OpenAI Agents SDK 문서는 guardrails가 agent 실행과 병렬 또는 blocking 방식으로 돌며 입력과 출력 검사를 수행할 수 있다고 설명한다. 2026년 Agents SDK 업데이트도 controlled workspace, tool, sandbox execution, durable execution을 하네스의 핵심 인프라로 다룬다. (openai.github.io)

AX Ops 관점에서 IR 하네스는 네 단계로 잡는다.

  1. Compile: 모델의 tool intent를 action IR로 변환한다.
  2. Normalize: schema, enum, resource ID, 금액·날짜·권한 범위를 정규화한다.
  3. Decide: policy engine이 allow, deny, require_approval, dry_run을 결정한다.
  4. Adapt: 승인된 IR만 MCP, API function, internal service call로 변환한다.

이 설계가 들어가면 보안팀의 질문이 바뀐다. “모델이 안전한가”가 아니라 “어떤 IR 상태에서 어떤 정책이 어떤 결정을 내렸는가”가 된다. 운영 회의에서 다룰 수 있는 단위가 생긴다.

참고

IR은 에이전트를 느리게 만드는 장치가 아니다. 운영에서 승인, 감사, 복구, 책임 배분을 가능하게 만드는 실행 언어다. AX LABS는 agent UX보다 먼저 agent harness를 설계한다. 이 순서를 지켜야 PoC가 운영으로 넘어간다. AX Ops 방법론 →