AI 에이전트 도구 표면 통제 설계와 운영 원칙

도구 등록이 쉬워질수록 통제가 필요한 이유

하네스 엔지니어링에서는 실행 샌드박스와 검증 루프뿐 아니라 도구 표면도 핵심 설계 대상으로 다뤄진다. MCP로 도구 계층의 표준화가 진행되면서 연결 자체는 쉬워졌지만, 그만큼 도구 목록이 통제 없이 불어나기 쉬워졌다.

도구가 많으면 에이전트가 처리할 수 있는 요청 범위는 넓어진다. 반대로 비슷한 기능 사이에서 잘못된 도구를 고를 가능성도 커지고, 각 도구의 설명이 컨텍스트 예산을 차지해 본래 과업에 쓸 여유가 줄어든다. 잘못 선택된 도구가 되돌릴 수 없는 조치를 수행할 수 있다는 점도 문제다. 외부 입력이 도구 실행 권한까지 이어지는 신뢰 경계의 결함도 실제로 보고됐다.

따라서 통제 대상은 단순한 등록 여부가 아니다. 목록 분할, 흐름별 노출, 설명 규격, 스키마 제약, 위험 등급, 승인 분리, 오호출 감지, 사용 빈도 기반 회수를 하나의 운영 체계로 묶어야 한다.

노출 범위를 설계하는 통제 계층

도구 목록은 조회, 변경, 외부 통신, 시스템 조작처럼 성격에 따라 분리한다. 모든 도구를 하나의 평면 목록에 두면 위험과 노출 범위를 함께 관리하기 어렵다.

활성 도구는 업무 흐름의 단계에 맞춰 전환한다. 현재 단계에 필요하지 않은 도구는 목록에서 제외하며, 전 도구를 상시 노출하지 않는다. 이때 노출은 기능 제공이 아니라 위험 예산을 배분하는 행위로 본다.

도구 설명은 목적, 사용 조건, 사용하면 안 되는 상황, 인자 의미, 반환 형태, 부수효과를 같은 순서로 작성한다. 함수 시그니처만 보여 주는 방식으로는 충분하지 않다. 특히 사용하지 말아야 할 상황을 분명히 하는 일이 선택 정확도에 큰 영향을 준다.

인자에는 필수 여부, 허용 값 범위, 형식 제약을 스키마로 적용하고 위반은 호출 전에 차단한다. 자유 문자열 인자를 남겨 두면 오류가 실행 시점에야 드러난다. 또한 각 도구에 되돌림 가능성, 외부 노출 여부, 비용 발생 여부를 구조화된 위험 등급으로 부여한다. 설명에만 위험을 적어서는 정책으로 강제할 수 없다.

고위험 도구는 사람 승인이나 별도 자격 확인을 거쳐 실행하도록 분리한다. 모든 도구를 자동 실행으로 두면 되돌릴 수 없는 조치에 필요한 게이트가 사라진다. 운영 중에는 인자 검증 실패, 즉시 재호출, 결과 미사용, 연속 도구 전환을 오선택 신호로 수집한다. 실행 자체는 성공했지만 선택이 잘못된 호출도 자주 발생하기 때문이다.

마지막으로 일정 기간 호출되지 않은 도구를 후보로 뽑아 폐기하거나 비활성화한다. 회수 절차 없는 등록은 도구 목록을 한 방향으로만 키운다.

⤢✕

운영 체계에 포함할 작업

먼저 등록된 도구 전체를 인벤토리로 정리하고, 호출 빈도·오호출률·마지막 사용 시점을 함께 붙인다. 등록 문서만으로는 실제로 살아 있는 도구를 판단할 수 없으므로 호출 로그가 필요하다.

대표 업무 흐름을 따라가며 각 단계에서 실제 호출된 도구만 모아 활성 집합을 만든다. 담당자의 추정만으로 집합을 구성하면 안전을 이유로 범위가 넓어지기 쉽다.

도구 설명은 규격 서식에 따라 다시 작성하고, 금지 상황 항목을 빠짐없이 채운다. 초기 설명은 구현자 관점에 머무르는 경우가 많다. 위험 등급은 되돌림 가능성, 외부 영향, 비용 발생을 기준으로 매기고 검토자를 둔다. 등급은 정책 강제의 근거이므로 개발자 개인의 판단에만 맡길 수 없다.

오선택 신호가 잡힌 호출은 모아서 설명 결함과 유사 도구의 중복 여부를 분석한다. 이를 곧바로 모델 성능 문제로 단정할 수는 없다. 오호출의 다수는 설명과 목록 구조에서 비롯된다.

미사용·저빈도 도구는 주기적으로 검토해 목록에서 걷어낸다. 삭제가 예외적인 작업이 아니라 정기 절차가 되어야 목록이 관리 가능한 크기를 유지한다. 목록 분할 기준, 설명 규격, 스키마 요건, 위험 등급 정의, 승인 대상은 조직 표준으로 등록하고, 활성 도구 수·도구별 오호출률·승인 게이트 통과 건수·폐기 처리율을 정기 보고 항목으로 편성한다.

노출 방식과 실행 통제의 선택

구분	상황별 부분 노출	전체 도구 상시 노출
선택 정확도	높음	낮음
컨텍스트 소모	작음	큼
구현 복잡도	높음	낮음
기능 범위	집합에 제한	전 범위
실패 원인 추적	단순	복잡
예외 요청 대응	지연 발생	즉시

상황별 부분 노출은 선택지를 줄여 오선택을 낮추고, 도구 설명이 차지하는 예산을 줄여 본 과업에 쓸 컨텍스트를 확보한다. 실패했을 때 후보가 적어 원인 추적도 단순해진다. 다만 집합 정의와 전환 로직이 필요하며, 필요한 도구가 활성 집합에 빠지면 과업이 막힌다. 예외 요청에도 집합 갱신이 선행돼 지연이 생긴다.

전체 도구를 상시 노출하면 어떤 요청에도 대응할 수 있고 구현이 단순하며 예외 처리도 즉시 가능하다. 그러나 유사 기능 도구가 늘수록 선택 정확도는 떨어지고, 설명만으로 컨텍스트가 소모된다. 잘못된 호출이 만드는 부수효과 위험도 목록 크기에 비례해 커진다. 핵심 흐름은 부분 노출로 선택 정확도를 지키고 저위험 조회 도구만 상시 노출하는 혼합 구성이다.

엄격한 스키마 강제는 잘못된 인자를 호출 전에 막아 실행 실패율을 낮추고, 실패 지점을 분명히 해 교정 지시를 정확하게 만든다. 도구 계약도 별도 문서 없이 드러난다. 반면 스키마 정의와 유지에는 공수가 들고, 예상하지 못한 정당한 사용이 차단되면 우회 구성이 생길 수 있다. 스키마가 실제 구현과 어긋나면 정상 호출까지 막힌다.

자유 인자 허용은 복잡한 요청을 그대로 전달하고 새로운 사용 방식을 수용하기 쉽다. 하지만 인자 오류가 실행 시점에 드러나 실패율이 높아지고, 오류 메시지가 원인을 가리지 못하면 재시도가 무작위로 흐를 수 있다. 잘못된 인자가 예상치 못한 부수효과를 낼 위험도 있다. 필수 구조는 스키마로 강제하고 세부 조건은 자유 필드로 남기되, 실행 전 검증으로 걸러내는 이원 구성이 표현력과 실패율 사이의 절충안이 된다.

승인 게이트를 분리하면 되돌릴 수 없는 조치가 사람 확인을 거치므로 사고 위험이 크게 낮아진다. 승인 이력은 감사 근거로 남고, 외부 입력이 실행 권한에 직접 도달하는 경로도 끊어진다. 대신 승인 대기가 누적되고, 맥락 없는 형식적 승인이 생길 수 있으며 야간이나 대량 처리에서는 병목이 된다.

전 도구 자동 실행은 처리 속도가 빠르고 사람 개입 없이 과업을 완주할 수 있어 자동화 효과가 온전히 나온다. 구현도 단순하다. 그 대가로 오호출 하나가 되돌릴 수 없는 결과를 만들 수 있고, 외부에서 들어온 지시가 그대로 실행될 수 있으며 사고 뒤 책임 소재가 불분명해진다. 위험 등급이 높은 소수 도구만 게이트로 분리하고 나머지는 자동 실행으로 두면 게이트 통과량을 낮게 유지하면서 속도와 안전을 함께 확보할 수 있다.

정보관리기술사 관점에서의 연결

도구 설명 규격과 인자 스키마는 인터페이스 명세를 표준화하는 활동에 대응한다. MCP 기반 도구 계층의 표준화는 이기종 연계를 위한 공통 프로토콜 채택으로 볼 수 있다.

위험 등급 표기와 승인 대상 분리는 최소 권한 원칙 및 직무 분리를 구현하는 방법이다. 업무 상황에 따라 노출 집합을 전환하는 방식은 필요한 시점에만 권한을 부여하는 접근 통제와 맞닿아 있다.

인자 스키마의 사전 검증은 결함을 이른 단계에서 차단하는 품질 보증 활동이다. 오호출 신호를 수집하고 정기 축소 검토를 수행하는 과정은 결함 데이터를 바탕으로 개선을 반복하는 순환 구조가 된다.

2026년에 예상되는 운영 변화

도구 설명 규격은 조직 사이의 공통 서식으로 수렴하고 등록 심사 항목에 편입되는 방향으로 갈 수 있다. 업무 흐름에 따른 노출 집합 전환은 오케스트레이션 프레임워크의 기본 기능으로 내장되는 흐름이다.

위험 등급과 승인 게이트는 에이전트 보안 요건의 표준 항목으로 요구되는 방향이며, 미사용 도구 회수 절차 역시 도구 등록과 짝을 이루는 운영 규칙으로 정착되는 흐름이다.

도구를 추가하면 기능 범위는 넓어지지만, 오선택 가능성과 컨텍스트 소모도 함께 커진다. 도구 표면을 설계 대상으로 보면 무엇을 제공할지보다 무엇을 감출지를 먼저 정하게 된다. 성격별 목록 분할, 업무 흐름별 노출 집합, 금지 상황을 포함한 설명 규격, 엄격한 인자 스키마, 고위험 도구의 승인 분리가 기본 구성이 된다. 등록만 하고 회수하지 않으면 목록은 계속 팽창하므로, 정기 축소 검토가 이 통제 체계를 유지한다.