에이전트에게 도구를 제공한다고 해서 그 도구가 수행할 수 있는 모든 행동을 승인하는 것은 아닙니다. 호출 전에 대상의 행동과 클래스를 확인하고, 과도하게 토큰을 소모하는 것을 모니터링하여 해당 에이전트를 격리할 수 있어야 합니다. 프롬프트를 저렴하거나 더 비싼 모델로 라우팅하기 전에 자체적인 작업으로 평가(evals)를 구축해야 하는데, 공용 벤치마크 점수가 모델이 귀하의 환경에서 어떻게 작동하는지 알려주지는 못하기 때문입니다.
Jeetu Patel, Cisco의 사장 겸 최고 제품 책임자(Chief Product Officer)는 2026년 8월 'Chain of Thought'에서 이러한 사례를 제시했습니다.
도구 권한 부여와 허용된 행동을 어떻게 구분할까요?
도구 권한 부여(tool grant)는 에이전트가 해당 통합을 사용할 수 있는지 여부를 답변합니다. 반면, 행동 검사(action check)는 에이전트가 무엇을 할 수 있고 누구에게 할 수 있는지를 답변합니다. Patel은 자신의 받은 편지함 예시를 통해 이 둘을 구분했습니다: 저녁 식사 예약을 하는 것은 범위 내에 있을 수 있지만, 이사회 구성원에게 연락하는 것은 동일한 연결에서 다른 행동입니다.
에이전트에 대해 단순히 접근 제어(access control)만 할 수는 없습니다. 행동 제어(action control)를 해야 합니다. 즉, Conor가 만약 에이전트에게 이메일 권한을 부여하고 싶다면, 자신의 전체 이메일 받은 편지함에 대한 전적인 재량권(carte blanche rights)을 부여하고 싶은 것이 아닙니다. 그저 '있잖아? 나를 위해 식당 저녁 예약을 할 수 있어'라고 말하며 권한을 부여하는 것입니다. 하지만 나의 이사회 구성원에게 연락해서 무작위로 문자 메시지를 보내는 것은 할 수 없습니다.
Jeetu Patel, Cisco 사장 겸 최고 제품 책임자(Chief Product Officer), Chain of Thought ep 67에서
Podcast 에피소드 · Chain of Thought | AI Agents, Infrastructure & Engineering · 8월 12일 · 46분
favicon podcasts.apple.com
결정은 도구(tool), 행동(action), 대상 클래스(target class)의 키로 저장합니다. ("inbox", "reserve", "restaurant")와 ("inbox", "message", "board")는 서로 다른 답변이 필요합니다. 이미 승인하지 않은 모든 트리플을 가로채야 합니다. 모델 외부에서 허용 목록(allow list)을 강제하고, 이를 런타임 의도 확인(runtime intent checks)과 결합해야 합니다. 에이전트는 너무 똑똑해서 정적 규칙을 우회하기 쉽기 때문에, 패텔(Patel)의 설명에 따르면 그렇습니다. 경계 조건(Boundary conditions)은 현재 행동이 원래 의도에서 벗어나고 있는지 여부에 따라 런타임에 생성되어야 하며, 벗어날 때 가로채는 것이 필요합니다.
어떻게 행동과 토큰 사용을 감독하나요?
에이전트가 설정한 경계를 넘거나(crosses a boundary), 토큰 소비가 통제 불능 상태가 될 때는 호출을 가로챕니다. 그리고 격리(quarantine)시킵니다. 패텔은 이를 인프라 모니터링과 나란히 놓습니다: 시스템의 복원력, 가드레일 위반, 그리고 토큰 사용입니다.
세 번째는 토큰 경제학(tokenomics)을 모니터링하고 있는지 확인해야 한다는 것입니다. 즉, 이 에이전트들이 토큰 사용 패턴에서 과도하게 소비하지 않도록 해야 합니다.
Jeetu Patel, Cisco 사장 겸 최고 제품 책임자(President and Chief Product Officer), Chain of Thought ep 67에서 발췌
격리(Quarantine)는 과도하게 소비하는 에이전트를 일시적으로 멈추게 하는 방법입니다. Cisco는 사람들에게 토큰에 대한 광범위한 접근 권한을 주어 익숙해지게 한 후, 인원수(headcount)를 배분하듯이 토큰을 할당하기 시작했습니다. 팀은 특정 수의 토큰과 그들로부터 제공해야 할 결과물을 받습니다. 그가 제기한 다음 질문은 동일한 비용으로 어떻게 아키텍처를 구축하여 생성되는 토큰 양을 20%, 30%, 40%, 50%, 60% 더 높일 수 있느냐는 것입니다.
적응할 최소한의 스케치이며, 드롭인 라이브러리는 아닙니다.
def check_action(agent, tool, action, target_class, tokens_needed):
if (
isinstance(tokens_needed, bool)
...
allowed_actions는 승인한 트리플(triples)을 담고 있습니다. token_budget를 초과하면 격리 플래그가 설정되어 나중에 호출할 때 사람이 해제하기 전까지 중단됩니다. 에이전트가 작동하는 동안 실제 행동과 작업 의도를 비교하고, 이들이 벗어날 때 가로채야 합니다. 설정 시 고정된 규칙은 Patel이 에이전트들이 우회한다고 말한 것입니다.
라우팅 모델 전에 자체 평가(evals)를 구축해야 하는 이유?
공개 평가에서 높은 점수를 받았다고 해서 해당 모델이 사용 사례에서도 잘 작동한다는 의미는 아닙니다. 이는 모델이 벤치마크가 측정한 행동에 대해 잘했다는 것을 의미할 뿐입니다. 먼저 작업 중심으로 평가를 구축하고, 그 결과를 사용하여 더 저렴하거나 더 비싼 모델로 프롬프트를 보내세요.
그리고 참고로, 사용자의 벤치마크와 평가는 전체 이야기를 알려주지 못합니다. 이것은 대부분의 사람들이 깨닫지 못하는 또 다른 점입니다. 마치, 만약 모델이 한 평가에서 잘 작동한다고 해서 그 환경에서도 잘 작동할 것이라는 의미는 아닙니다. 단지 해당 벤치마크가 모델의 매우 특정한 행동 세트를 평가했을 때, 그 모델이 잘 수행했다는 것을 의미할 뿐입니다.
Jeetu Patel, Cisco 사장 겸 최고 제품 책임자(Chief Product Officer)가 Chain of Thought ep 67에서 말한 내용입니다.
그의 설명에 따르면, 비용에는 토큰의 달러 가격과 소비하는 와트(wattage)가 포함됩니다. 왜냐하면 돈은 있어도 전력이 부족할 수 있기 때문입니다. 그는 또한 사용 가능한 전체 컴퓨팅 용량의 60%가 추론(inferencing)에 할당되고 있다고 말했습니다. 작업별로 고려해야 할 상충 관계는 지능, 비용, 그리고 통제력입니다. 민감한 데이터와 같이 통제력이 더 중요한 작업에서는, 지능의 마지막 5%가 그다지 중요하지 않을 수도 있습니다.
승인 경로에 사람이 남아 있는 상황을 유지하여 해당 사용 사례가 신뢰할 수 있는 기록(track record)을 가질 때까지 기다리세요. Patel의 의견은 다음과 같습니다: 모델이 귀하의 환경에 충분히 미세 조정(fine-tuned)되고, 그 결정들을 통계적으로 충분히 많이 확인하여 편안함을 느낄 때까지 모든 것을 승인하고, 그때서야 사람을 루프에서 제외하는 것을 고려하세요. 이 지점이 어디에 위치할지는 사용 사례와 조직마다, 그리고 간단한 작업과 더 복잡한 작업 사이에서도 다릅니다.
FAQ
사서함 연결(inbox connection)이 에이전트가 모든 메시지를 보내도록 허용하나요?
해당 연결은 도구 권한 부여(tool grant)입니다. Patel은 저녁 식사 예약과 이사회 연락을 분리하며, 이 두 가지는 동일한 사서함에 대해 별도의 행동 검사가 필요하다고 말합니다.
공개 벤치마크가 어떤 모델로 라우팅해야 할지 알려주나요?
이는 해당 평가(eval)의 동작에 대해 모델이 어떻게 수행했는지 보고할 뿐입니다. Patel은 그 결과가 귀하의 환경에서의 성능을 확립하지 못한다고 말합니다. 사용 사례별로 자체 평가를 구축한 다음, 라우팅하세요.
만약 에이전트가 토큰을 소진하거나 경계를 벗어나면 어떻게 해야 하나요?
경계를 넘는 행동을 가로채세요(Intercept). 토큰 사용량이 과도하게 많다면, 에이전트를 격리(quarantine)하여 보류할 수 있도록 하세요.
핵심 요약 (Takeaway)
- 민감한 모든 호출은 도구(tool), 행동(action), 대상 클래스(target class)별로 키를 지정하고, 승인하지 않은 키는 가로채세요(intercept).
- 에이전트당 토큰 예산(token budget)을 설정하고, 이 예산을 초과하면 에이전트를 격리하세요.
- 모델 외부에서 강제되는 권한 부여와 함께 원래 의도(original intent)를 기준으로 런타임 시 경계 검사(boundary checks)를 재계산하세요.
- 더 저렴한 모델과 더 비싼 모델 사이에 프롬프트를 라우팅하기 전에 자체 사용 사례로 평가를 구축하세요.
- 해당 사용 사례가 신뢰할 수 있는 기록을 가질 때까지 승인에 사람(human)을 남겨두세요.
전체 대화 내용은 Chain of Thought에서 트랜스크립트와 함께 확인할 수 있습니다.
에피소드 스크립트를 기반으로 AI의 도움을 받아 작성됨.