수년간 에이전트 데모를 믿었습니다 — 이제는 거부하는 관문을 만들었습니다

AI 요약

에이전트를 프로덕션에 배포할 때 데모를 한 번 지켜본 뒤 준비가 끝났다고 판단하는 관행은 흔합니다. HivePlane을 만든 작성자도 수년간 자신의 데모를 믿었습니다. 하지만 에이전트가 늘어나면 누가 에이전트를 소유하는지, 어떤 도구를 쓰고 얼마까지 지출하는지, 무엇보다 실제 성능을 입증했는지 확인할 기준이 필요합니다. 작성자는 이 문제를 해결하려고 에이전트가 재현 가능한 벤치마크를 통과하고 서명된 증명을 받아야 프로덕션에 접근하도록 하는 오픈소스 컨트롤 플레인을 만들었습니다.

인증 상태로 배포를 통제합니다

HivePlane은 등록, 인증, 접근 제한, 실행, 개입, 결과 전달, 관찰 순서로 에이전트를 관리합니다. 각 작업에는 인증 상태가 붙고, 상태에 따라 실행 가능한 환경이 달라집니다. 인증 전 상태인 uncertified는 샌드박스에서만 실행합니다. 스테이징 기준 0.80을 통과하면 provisional 상태가 되어 스테이징에 들어갑니다. 프로덕션 기준 0.90을 통과하면 certified 상태가 됩니다. 재인증에 실패하거나 환경 변화가 감지되면 quarantined 상태로 전환해 실행을 막습니다.

프로덕션 인증은 스테이징 기준을 더 높은 점수로 다시 확인하는 절차가 아닙니다. 별도의 벤치마크 실행이 필요합니다. 프롬프트, 모델, 도구 등 매니페스트 항목이 바뀌면 기존 인증은 무효가 되고, 프로덕션에 다시 접근하기 전에 재인증해야 합니다. 인증 결과에는 정확한 모델 식별자에 연결된 Ed25519 서명 증명이 발급됩니다. 시스템은 증명을 읽을 때마다 서명을 검증합니다.

실제 실행으로 벤치마크합니다

첫 현장 테스트는 실제 Docker 스택에서 시나리오 10개와 승인 기준 20개를 점검했고 모두 통과했습니다. 대상은 일반 Python 지원 에이전트와 LangGraph 판정 그래프였으며, 의도적으로 문제가 있는 테스트 구성도 포함했습니다. 인증은 시뮬레이션이 아닙니다. 각 벤치마크 작업을 런타임 어댑터와 정책 경계를 거쳐 실제로 실행하고, 사용한 경우에는 통제된 모델 연결부도 통과시킵니다.

지원 에이전트는 스테이징에서 6개 중 6개를 통과해 provisional 상태를 받았고 p95 지연 시간은 92ms였습니다. 프로덕션에서는 6개 모두 통과해 certified 상태가 됐으며 p95는 67ms였습니다. 판정 에이전트는 스테이징에서 4개 중 4개를 통과하고 p95 215ms를 기록했습니다. 프로덕션에서도 4개 모두 통과했으며 p95는 126ms였습니다.

테스트에서는 인증되지 않은 에이전트의 실행을 403으로 거부했고, 모델 교체도 403으로 차단했습니다. 겉보기에는 정상인 에이전트를 격리했으며 예산을 초과한 실행은 즉시 종료했습니다. 컨테이너 계층도 이미지 빌드, API 계약, 제어 루프, 재시작 후 지속성, UI를 포함해 25개 항목을 모두 통과했습니다.

프레임워크가 아니라 여러 에이전트를 운영합니다

작성자는 Kubernetes가 단일 컨테이너 런타임이 아니라 공통 계약 아래 여러 런타임을 운영한다고 설명합니다. HivePlane도 에이전트 프레임워크가 아니라 공통 매니페스트를 바탕으로 여러 에이전트를 운영하는 컨트롤 플레인입니다. 매니페스트에는 소유자와 팀, 런타임 어댑터, 허용 도구, 모델 식별자, 예산, 샌드박스와 외부 통신 규칙, 인증용 데이터셋과 기준, 결과 전달 대상이 들어갑니다. 이 항목 중 하나라도 바뀌면 프로덕션에 다시 접근하기 전에 에이전트를 재인증합니다.

작성자가 제품의 본질로 꼽는 부분은 실행이 아니라 거부입니다. ‘Forbidden’이라는 응답만 내놓으면 운영자가 다음에 무엇을 해야 할지 알 수 없습니다. 반면 인증 상태와 필요한 조치를 구체적으로 알려주는 거부는 운영 가능한 절차가 됩니다. 작성자는 인증을 단순한 품질 점수가 아니라 보안 통제로 봅니다. 서명된 증명을 프로덕션 진입 조건으로 두면 모델 교체, 매니페스트 수정, 에이전트 성능 저하를 추적하고 차단할 수 있습니다.

남은 과제와 범위

운영 도구는 현장에서 쓸 만큼 빨라야 합니다. 작성자가 측정한 점검과 중단 작업은 0.04초, 새 프로젝트 뼈대 생성은 0.24초였습니다. 느린 거버넌스 도구는 우회될 수 있고, 우회되는 컨트롤 플레인은 비싼 대시보드에 그친다고 설명합니다.

v0.1.0은 일반 Python 작업자와 LangGraph 어댑터를 지원합니다. 더 넓은 프레임워크 지원은 뒤로 미뤘습니다. 현재 재인증은 예약 실행 또는 변경 감지에 따라 진행하므로, 바뀌는 대상은 잡아내도 시간이 흐르며 성능이 약해지는 현상은 감지하지 못합니다. 드리프트 감지기는 다음 작업으로 제시했습니다. 이번 주기에는 모델 식별자 하나를 검증했으며, 실제 가격을 반영한 클라우드 프로필 테스트도 예정돼 있습니다. 작성자는 다음 글에서 현장 테스트 첫날 실패한 세 에이전트와 대신 인증한 대상을 다룰 계획입니다.

dev.to 반응

• @mickyarun — 매니페스트가 바뀌면 기존 인증이 무효가 된다는 문장이 가장 중요한 부분입니다. 제가 본 대부분의 관문은 승격을 한 번만 검사한 뒤, 그 밑에서 대상이 달라지는 것을 방치합니다. 그러면 증명은 더 이상 존재하지 않는 버전에 관한 진술이 됩니다. 모델 식별자에 증명을 연결하고 읽을 때마다 다시 검증하는 방식은 누군가 금요일에 모델을 바꿔도 버텨냅니다. 제가 더 파고들 부분은 매니페스트에 없는 항목입니다. 소유자, 어댑터, 도구, 모델은 들어 있지만 에이전트가 호출하는 외부 서비스는 빠져 있고, 외부 서비스는 알리지 않고 바뀝니다. 프롬프트와 모델, 도구 목록은 그대로인데 결제 API가 새 필드를 반환하기 시작하면, 매니페스트 안의 것은 바뀌지 않았으니 인증은 여전히 통과합니다. 검사가 실패한 게 아니라, 검사 대상이던 것과 더 이상 같은 대상을 검사하지 않는 상황입니다. 그래서 10/10이 오히려 가장 불편한 숫자입니다. 거부가 흥미로웠다고 쓴 점에서 이미 제 주장을 절반쯤 짚으셨습니다. 실제로 누군가 원했던 승격을 한 번도 막지 않은 관문은, 승격을 막을 수 없는 관문과 같은 증거입니다. 네 가지 잘못된 테스트 구성은 좋은 도구입니다. 여기에 실제 트래픽에서 거부율을 시간에 따라 추적하고, 0을 통과가 아닌 경보로 취급하는 방식을 더하겠습니다. 재인증에 실패해 작업이 격리되면 누가 예외를 승인할 수 있나요? 그 승인도 증명 기록에 남나요? 제가 지켜본 모든 관문에는 결국 승인할 수 있는 사람이 생겼고, 감사 기록은 대개 그 사람에게서 끊겼습니다.
  • @nomad-link-id — ‘누군가 데모를 지켜봤으니 에이전트가 프로덕션 준비를 마쳤다’는 문장이 저도 오랫동안 걱정했던 점을 정확히 짚습니다. 인증 단계와 매니페스트 변경 시 증명을 무효화하는 방식은 올바른 구조입니다. 다음으로 살펴볼 부분은 벤치마크 데이터셋에서 빠질 수 있는 상황입니다. 벤치마크가 평온한 날의 순조로운 경로만 평가한다면, 증명은 폭풍이 한 번도 오지 않은 환경을 설명할 뿐입니다. 필수 도구가 성공처럼 보이는 결과를 반환했지만 실제 사후 조건은 거짓인 경우, 정책상 컨텍스트가 비었거나 문서가 없는 경우, 에이전트가 임의로 답을 만들어내지 않고 거부하거나 사람에게 넘겨야 하는 경우를 넣고 싶습니다. 외부 서비스 변화도 같은 문제입니다. 프롬프트와 모델, 도구 목록은 같고 의존 서비스의 반환 형식만 바뀌면 매니페스트 안에서 바뀐 것은 없으니 인증은 계속 통과합니다. 실제 차단이 오랫동안 0건이면 통과가 아니라 경보로 취급해야 관문을 믿을 수 있습니다. ‘Forbidden’보다 이유가 분명하고 조치 가능한 거부가 제품입니다.
• @dougame — 에이전트 데모는 정말 오해를 부릅니다. 데모에서는 늘 완벽하게 작동하지만 실제 환경에서는 망가집니다. 이를 잡는 관문을 만든 점이 좋습니다. AI 에이전트를 테스트하는 분들을 위해 저는 API 키에 jzstoken을 쓰고 있습니다. 서비스마다 가입하지 않고도 여러 모델을 테스트하기 쉽습니다. 처음 시작할 때 5달러를 무료로 제공해서 선불 비용 없이 실제 환경 테스트를 할 수 있습니다.
• @quietlabops — 거부할 수 있는 관문이 전부입니다. 저희는 이를 Mode A라고 부릅니다. 봇은 초안을 쓰고 사람은 여전히 직접 붙여넣습니다. 공개 발언을 사람답게 유지하려고 의도적으로 단순하게 만들었습니다. 현장 테스트 한 페이지 요약은 grokbotplaybook.grok.me/에 있습니다.
• @tobazmojik_30ba9ad — 에이전트 데모는 흔히 순조로운 경로에 맞춰 최적화하지만, 프로덕션 시스템에는 낮은 신뢰도나 위험한 작업을 거부하는 안정적인 방법이 필요합니다. ‘거부하는 관문’은 인상적인 데모를 사람들이 실제로 믿을 수 있는 시스템으로 바꾸는 요소입니다. 특히 결정이 현실에 영향을 줄 때 그렇습니다. 자동화와 감독의 더 넓은 흐름에 관한 가이드를 썼습니다: gumreads.gumroad.com/l/bgykuc. 관문이 개입할 때 가장 효과적이라고 확인한 신호나 기준은 무엇인지 궁금합니다.
• @mir_arshadalitalpur_1b3 — 매우 관련 있는 문제이고 글도 잘 썼습니다. 저희도 모든 것을 감사 가능하게 만드는 zizkadb로 이 문제를 해결하려 합니다. 오픈소스입니다: github.com/ZIZKA-AI-SL/ZizkaDB.
• @mudassirworks — ‘데모를 통과했나’에서 ‘현재 산출물이 현재 매니페스트를 기준으로 인증됐나’로 옮겨간 점은 대부분의 팀이 명확히 설정하지 않는 경계입니다. 403을 오류 처리가 아니라 제품 출력으로 삼은 부분이 기억에 남습니다. 사후 정책 문서가 아니라 프로토콜 자체에 신뢰 경계를 넣고 있습니다. HivePlane의 증명 계층은 매니페스트가 바뀌면 인증도 무효로 만들어 ‘지난주에는 작동했다’는 변명을 없앱니다. 인증 정책 자체를 매니페스트와 별도로 버전 관리해야 했던 사례가 있나요? 아니면 둘을 묶어두는 편이 원하는 속성을 보장하나요?

원문: dev.to / 번역·요약: Trawling