Open Envelope, 에이전트 팀 정의의 표준화 실험
멀티에이전트 시스템이 늘수록 문제는 개별 프롬프트가 아니라 역할, 권한, 비밀, 실행 결과를 이식 가능한 계약으로 남기는 것이다. Open Envelope는 에이전트 팀을 OpenAPI나 Kubernetes 매니페스트처럼 다루려는 초기 신호다.
AI 뉴스를 놓치지 마세요
매주 핵심 AI 소식을 이메일로 받아보세요.
에이전트 팀도 매니페스트가 필요하다
Open Envelope 문서는 AI 에이전트 팀을 정의하는 열린 스키마를 제안한다. 핵심은 에이전트의 역할, 계층, 필요한 비밀값, 변수, 접근 정책, 실행 결과를 JSON Schema 형태로 표현하는 것이다. 별도 런타임에 묶인 코드가 아니라, 어느 플랫폼이든 해석할 수 있는 선언형 계약을 만들겠다는 접근이다.
함께 공개된 스키마 런칭 글은 이 스키마가 SchemaStore에 등록됐고 npm 패키지로도 배포된다고 설명한다. VS Code가 package.json이나 GitHub Actions 파일에 자동완성을 제공하듯, 에이전트 팀 정의 파일도 IDE와 CI에서 검증할 수 있게 하려는 방향이다. SchemaStore와 JSON Schema의 생태계를 빌리는 판단은 실용적이다.
KanBots, 칸반을 병렬 에이전트 런처로 바꾸다와 Runtime, 팀 단위 코딩 에이전트 운영체제를 겨냥하다가 보여준 것처럼 에이전트는 이제 단일 챗봇이 아니라 팀 단위 실행 단위가 되고 있다.
코드 우선에서 계약 우선으로
LangGraph, CrewAI, Vertex AI ADK 같은 프레임워크는 개발자가 코드로 에이전트 그래프를 만든다. 이 방식은 유연하지만 조직이 커지면 이식성과 검토성이 떨어진다. Open Envelope는 Dockerfile이나 OpenAPI가 했던 것처럼 런타임과 정의를 분리하려 한다. 에이전트가 어떤 역할을 맡고, 누구에게 보고하며, 어떤 호스트에 접근하고, 어떤 비밀값이 필요한지 파일만 보고 알 수 있어야 한다는 주장이다.
OpenAPI Specification은 API 계약을 코드 밖으로 끌어내 도구 생태계를 만들었다. 같은 일이 에이전트에서도 필요하다. 프롬프트가 코드 안에 묻히고 접근 권한이 런타임 설정에 흩어지면 감사와 재사용이 어렵다.
| 항목 | 코드 우선 에이전트 | 스키마 우선 에이전트 |
|---|---|---|
| 정의 위치 | 프레임워크 코드 | 독립 매니페스트 |
| 검토 방식 | 코드 리뷰 중심 | 계약, 권한, 비밀 검토 |
| 이식성 | 런타임 종속 | 구현 런타임 교체 가능 |
| 위험 | 암묵적 권한 | 스키마와 실제 런타임 불일치 |
접근 정책과 비밀 관리가 핵심이다
Open Envelope 문서에서 눈에 띄는 부분은 accessPolicy, requiredSecrets, requiredVariables다. 에이전트가 어떤 호스트에 어떤 방식으로 접근할 수 있는지 선언하고, 비밀값은 스키마에 직접 넣지 않고 배포 시점에 주입한다는 모델이다. 이는 에이전트 보안에서 반드시 필요한 최소선이다.
도메인 위장 프롬프트 공격, 에이전트 방어의 맹점을 찌르다에서 본 것처럼 에이전트는 외부 콘텐츠와 도구 호출 사이에서 공격면을 만든다. 프롬프트에 "조심하라"고 쓰는 것보다 네트워크 정책과 비밀 주입 경계를 계약으로 남기는 편이 더 강하다.
다만 표준은 문서만으로 완성되지 않는다. 런타임이 실제로 접근 정책을 강제하는지, 로그에 비밀이 남지 않는지, 스키마 버전이 깨질 때 어떻게 마이그레이션하는지가 중요하다. Open Agent Specification 연구도 에이전트 정의의 이식성과 호환성을 별도 문제로 다룬다.
한국 개발팀의 활용 가능성
국내 기업은 여러 부서가 각자 에이전트를 실험하면서 비슷한 자동화를 중복 개발하기 쉽다. 스키마 기반 정의가 정착하면 영업 리드 분류, 고객지원 티켓 처리, 보안 알림 조사 같은 팀을 파일로 배포하고 검토할 수 있다. 승인자는 코드 전체가 아니라 입력, 출력, 권한, 비밀, 비용 모델을 볼 수 있다.
AI 에이전트 테스트, 분산시스템의 주장부터 검증한다의 관점에서도 선언형 계약은 테스트 대상을 명확히 한다. 입력 스키마, 출력 스키마, 런 이벤트가 있으면 에이전트 품질을 재현 가능하게 측정할 수 있다.
자주 묻는 질문
Q1: Open Envelope는 프레임워크인가요?
A: 문서상 핵심은 에이전트 팀 정의를 위한 오픈 스키마다. 자체 런타임도 있지만 표준 계약을 강조한다.
Q2: 왜 SchemaStore 등록이 중요한가요?
A: 별도 확장 없이 IDE 자동완성, 유효성 검사, CI 검증을 활용할 수 있다. 도입 장벽을 낮춘다.
Q3: 코드 기반 LangGraph 같은 도구와 경쟁하나요?
A: 일부는 경쟁하지만 더 큰 방향은 상호 보완이다. 스키마가 계약을 제공하고 런타임은 이를 실행할 수 있다.
Q4: 가장 큰 위험은 무엇인가요?
A: 스키마에 선언된 권한과 실제 런타임 강제가 다르면 보안 착시가 생긴다. conformance 테스트가 필요하다.
Q5: 기업에서 먼저 쓸 부분은 무엇인가요?
A: 역할, 접근 정책, 비밀 요구사항, 출력 스키마를 명시하는 내부 템플릿부터 도입하면 에이전트 감사가 쉬워진다.
관련 토픽 더 보기
📰 원본 출처
openenvelope.org이 기사는 AI 기술을 활용하여 작성되었으며, 원본 뉴스 소스를 기반으로 분석 및 해설을 추가한 콘텐츠입니다. 정확한 정보 전달을 위해 노력하고 있으나, 원본 기사를 함께 확인하시기를 권장합니다.