AI 에이전트가 자체 자격 증명을 지니고 외부 서비스에 직접 연결될 때, 이는 사내 소프트웨어라기보다 법인카드를 들고 다니지만 관리자는 없는 계약직 직원처럼 행동합니다. 에이전트가 무엇을 건드렸는지, 누가 액세스를 승인했는지, 왜 어떤 대화는 다른 대화보다 비용이 10배나 더 들었는지 알 수 없습니다. 로그는 수십 개의 서비스로 파편화됩니다. 질문은 걷잡을 수 없이 늘어납니다.
에이전트가 실제로 호출한 도구는 무엇인가요? 누가 해당 데이터베이스에 접근할 권한을 부여했나요? 월요일에는 5개의 토큰을 사용했는데, 왜 화요일 실행에서는 4만 개의 토큰이 소모되었을까요? 실제로 우리가 지출한 금액은 얼마인가요?
사용자, 모델, 서비스 사이에 중앙 제어 계층이 없다면 이러한 질문들은 해결되지 않은 채로 남습니다. 모든 연결을 한 번에 등록하고, 에이전트가 진정으로 필요로 하는 좁은 범위의 기능만을 노출하며, 모든 실행 과정을 상세히 기록하는 단일 플레인이 필요합니다. 이 글에서는 deco Studio를 로컬 제어 플레인으로 사용하는 심화 실습 과정을 살펴봅니다. deco Studio를 설정하고, 안전한 Model Context Protocol 서버를 연결하며, 단 하나의 허용된 기능만 노출한 뒤, 에이전트가 자신의 경계를 넘어서려 할 때 어떤 일이 발생하는지 확인해 보겠습니다.
파편화된 자격 증명의 문제점
일반적인 팀 환경을 가정해 봅시다. 한 개발자는 개인 키를 사용하여 에이전트를 검색 API에 연결합니다. 다른 개발자는 데모가 무해해 보인다는 이유로 동일한 에이전트를 운영 데이터베이스에 연결합니다. 세 번째 개발자는 에이전트가 "송장 처리를 도울 수 있도록" 결제 조회 도구를 추가합니다. 각 연결은 서로에게 보이지 않습니다. 이제 에이전트는 검색, 운영 데이터, 재무 기록에 직접 접근할 수 있게 되었지만, 팀에는 무엇이 활성화되어 있는지에 대한 통합된 목록이 없습니다.
자격 증명이 에이전트 내부에 존재하면 거버넌스가 무너집니다. 키가 에이전트의 메모리나 로컬 환경 파일에 저장되어 있기 때문에 중앙에서 액세스 권한을 취소할 수 없습니다. 외부 서비스는 익명의 자동화된 클라이언트로부터의 API 호출만 인식하므로 사용량을 감사할 수도 없습니다. 예상치 못한 비용은 며칠 뒤 클라우드 청구서에 나타나며, 그때가 되면 어떤 프롬프트가 비용 급증을 유발했는지 아무도 기억하지 못합니다.
deco Studio에서 제어 플레인 구축하기
deco Studio는 로컬 허브 역할을 하여 이 문제를 해결합니다. 자신의 머신에서 실행하면 모든 설정이 관리되는 단일 지점이 됩니다. API 키와 도구 정의를 여러 에이전트에 흩뿌리는 대신, Studio 내부에서 연결을 한 번만 등록하면 됩니다. 그런 다음 각 에이전트가 볼 수 있는 기능을 정확히 결정할 수 있습니다.
이를 교환기를 설치하는 것으로 생각하면 쉽습니다. 모든 전선이 하나의 방으로 모입니다. 당신은 어떤 회선이 어느 부서와 연결될지 선택하고, 모든 통화 기록을 보관합니다.
먼저 deco Studio를 로컬에서 실행하는 것부터 시작하세요. 실행이 완료되면 설정을 중앙 집중화합니다. 도구를 사용하려는 모든 에이전트는 이제 외부 서비스에 직접 요청하는 대신 제어 플레인에 요청해야 합니다. 이를 통해 관찰, 필터링 및 로깅이 가능한 병목 지점(chokepoint)이 즉시 생성됩니다.
안전한 MCP 서버 연결하기
이번 실습에서는 Model Context Protocol 서버를 연결합니다. MCP는 모델이 외부 도구와 상호 작용할 수 있도록 하는 개방형 표준이지만, 표준이 안전을 보장하지는 않습니다. 여기서 핵심 단계는 '선택성'입니다. 서버가 제공하는 모든 엔드포인트를 맹목적으로 노출하지 마십시오. deco Studio에 서버를 등록한 다음, 테스트 에이전트에는 허용된 단 하나의 기능만 노출합니다.
예를 들어, MCP 서버가 파일 읽기, 파일 쓰기, 데이터베이스 쿼리, 네트워크 가져오기 등 10개의 기능을 제공할 수 있다고 가정해 봅시다. 이 중 샌드박스형 계산기나 합성 데이터에 대한 읽기 전용 조회와 같이 무해한 작업 하나를 선택하여 그것만 노출합니다. 나머지 9개 기능은 에이전트에게 보이지 않게 됩니다. 에이전트가 해당 기능들을 요청하면 제어 플레인은 단호하게 거절합니다.
이는 '최소 권한 원칙'을 기계적으로 구현한 것입니다. 에이전트는 정중한 지시가 아니라 소프트웨어 경계를 통해 권한을 부여받습니다.
경계 테스트하기
테스트 에이전트를 생성하고 deco Studio 제어 플레인을 가리키도록 설정합니다. 허용된 단 하나의 기능이 필요한 작업을 부여합니다. 작업이 성공하는 과정을 지켜보세요. Studio 내부의 로그에는 모델 요청, 제어 플레인을 통한 도구 호출 라우팅, 함수 실행, 그리고 모델로 되돌아가는 결과가 모두 표시됩니다. 전체 경로를 하나의 연속적인 트레이스로 읽을 수 있습니다.
이제 에이전트에게 의도적으로 제외한 함수가 필요한 두 번째 작업을 부여하십시오. 에이전트는 한계를 우회하기 위해 추론을 시도하거나, 해당 도구가 존재한다고 환각(hallucination)을 일으킬 수도 있습니다. 어떤 경우든 호출은 컨트롤 플레인(control plane)에 도달하고, allowlist가 이를 거부하며, 실행은 실패합니다. 이 실패야말로 경계가 이론적인 것이 아니라 소프트웨어로 강제되고 있다는 증거입니다.
먼저 합성 작업(synthetic tasks)으로 이를 수행하십시오. 생성된 사용자 프로필로 가득 찬 가짜 데이터베이스를 구축하십시오. 에이전트가 이를 쿼리하게 하고, allowlist와 거부 사례를 검증하십시오. 경계가 확실하다고 신뢰할 수 있을 때 비로소 프로덕션 시스템을 에이전트에 연결하는 것을 고려해야 합니다. 벽을 검증하기도 전에 실제 데이터로 서두르는 것이 바로 비밀 정보가 유출되는 방식입니다.
실행의 전체 경로 읽기
deco Studio를 사용하면 실행의 모든 계층을 검사할 수 있습니다. 프롬프트, 컨텍스트 윈도우, 포맷팅 등 모델의 원시 요청(raw model request)을 볼 수 있습니다. 모델이 호출하기로 결정한 도구 호출(tool call)도 확인할 수 있습니다. 컨트롤 플레인이 해당 호출을 라우팅하고, 함수를 실행하며, 페이로드를 반환하는 과정도 볼 수 있습니다. 마지막으로, 모델이 그 결과를 어떻게 소비하여 답변을 형성하는지도 확인할 수 있습니다.
이러한 가시성은 기본적인 감사(audit) 질문에 답을 줍니다. 컨트롤 플레인이 로그를 남기기 때문에 어떤 도구가 실행되었는지 알 수 있습니다. 설정 기록이 하나의 로컬 레지스트리에 저장되어 있으므로 누가 액세스 권한을 부여했는지 알 수 있습니다. 토큰 수를 셀 수 있으므로 왜 실행 비용이 많이 들었는지 알 수 있습니다.
중요한 지표 측정하기
모든 실행에 대해 네 가지 특정 지표를 추적하십시오. 첫째, 입력 및 출력 토큰입니다. 이는 모델 비용의 대부분을 차지하며, 대략적인 추정치가 아닌 정확한 수치가 필요합니다. 둘째, 모델 지연 시간(latency)과 도구 지연 시간을 분리하십시오. 프롬프트와 모델 응답 사이의 시간은 외부 서비스가 도구 호출에 응답하는 데 걸리는 시간과 다릅니다. 이 둘을 혼동하면 지연 원인을 잘못 진단하게 됩니다. 셋째, 검증된 제공업체 요율을 기반으로 비용을 계산하십시오. 추측하지 마십시오. 제공업체의 가격표를 확인하고 측정된 토큰과 대조하십시오. 넷째, 성공한 호출과 거부된 권한 없는 호출을 비교하십시오. 거부 횟수가 높다는 것은 에이전트가 경계를 탐색하고 있거나, allowlist가 정당한 요구 사항과 일치하지 않음을 의미합니다.
이러한 수치들은 에이전트 운영을 블랙박스 구독 모델에서 관측 가능한 시스템으로 전환해 줍니다. 이를 통해 예산을 세우고, 최적화하며, 설명할 수 있습니다.
로컬 제어와 로컬 실행의 차이
이는 신중한 개발자들조차 실수하는 부분입니다. 자신의 기기에서 deco Studio를 실행하면 설정에 대한 로컬 제어권은 갖게 되지만, 모델 자체의 로컬 실행을 보장하지는 않습니다. 에이전트가 OpenAI, Anthropic 또는 기타 호스팅된 API와 같은 외부 제공업체를 호출하도록 설정하면, 프롬프트는 사용자의 기기를 떠납니다. Studio는 게이트를 관리하지만, 데이터는 여전히 네트워크를 통과합니다.
항상 이러한 경계를 추적하십시오. 파이프라인의 어느 부분이 localhost에 머물고, 어느 부분이 타인의 서버로 이동하는지 파악해야 합니다. 데이터가 민감하다면 도구 계층의 로컬 제어만으로는 부족합니다. 모델 추론이 어디에서 발생하는지도 알아야 합니다. 로컬 대시보드가 주는 편안함을 원격 모델의 현실과 혼동하지 마십시오.
지침은 권한 부여가 아닙니다
위험한 지름길 중 하나는 프롬프팅을 통해 에이전트를 보안하려는 시도입니다. 모델에게 "절대 삭제 함수를 호출하지 마"라고 말하는 것은 보안 제어가 아닙니다. 그것은 단지 제안일 뿐입니다. 모델은 지침을 오해하거나, 프롬프트 탈옥(jailbreak)을 당하거나, 단순히 추론 오류를 범할 수 있습니다. 진정한 보안은 소프트웨어 경계에 존재합니다.
deco Studio 내부의 allowlist를 사용하여 정확히 어떤 함수를 호출할 수 있는지 정의하십시오. 컨트롤 플레인 내부의 서버 측 검사를 통해 이러한 제한을 강제하십시오. 에이전트는 사용자가 파일 권한을 확인하는 방식과 동일하게, 친절한 메모를 읽는 것이 아니라 단단한 한계에 부딪힘으로써 자신의 능력을 파악해야 합니다. 보안은 자연어가 아닌 아키텍처에 속해야 합니다.
작게 시작하고, 회의적인 태도를 유지하세요
컨트롤 플레인을 한 단계씩 구축하십시오. 하나의 MCP 서버, 하나의 노출된 함수, 하나의 합성 작업부터 시작하십시오. 에이전트가 성공해야 할 곳에서 성공하고, 실패해야 할 곳에서 실패하는지 검증하십시오. 트레이스를 읽고, 토큰 수를 확인하십시오. 그런 다음 다음 도구를 추가하십시오.
제어는 단순히 켜고 끄는 스위치가 아닙니다. 그것은 경계를 신뢰하기 전에 그 경계를 증명하는 습관입니다. deco Studio는 그 습관을 연습할 수 있는 로컬 플레인을 제공합니다. 이를 사용하여 자율 에이전트 군집을 관리 가능하고, 관측 가능하며, 경계가 설정된 시스템으로 전환하십시오.
Source: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
선택 사항 학습 커뮤니티: Telegram의 GyaanSetu AI