OpenAI가 ChatGPT Work를 출시했다. 질문에 답하는 AI가 아니라, 몇 시간짜리 업무를 혼자 완수하는 AI다. Slack과 Jira, CRM을 연결하고, 예약 작업으로 매일 아침 피드백을 정리하고, 브라우저를 직접 열어 경쟁사를 분석하고, 스프레드시트를 수정한다. 버진 애틀랜틱은 수 주 걸리던 경쟁사 분석을 몇 시간으로 줄였고, 링센트럴의 한 매니저는 1명을 지원하던 역량으로 약 50명을 커버하게 됐다. 숫자만 보면 흥분할 만하다.
그런데 나는 이 발표를 보면서 다른 생각이 먼저 들었다. '이 에이전트가 CRM에 접근하고, 이메일을 보내고, 파일을 수정한다면—팀은 그 에이전트에게 어디까지 허락하고 있는가?' 에이전트가 실제 업무를 수행하는 시대가 열릴수록, 권한 설계의 공백이 그대로 리스크가 된다. 에이전트는 악의가 없어도 프로덕션을 망가뜨릴 수 있다. 잘못된 도구, 잘못된 고객 ID, 아무도 확인하지 않은 한 번의 자신감 있는 실행으로.
이 문제를 정면으로 다룬 아키텍처 가이드가 dev.to에 올라왔다. 핵심 주장은 단순하다. 프롬프트 가이드라인은 모델의 행동을 유도할 뿐, 강제하지 않는다. 에이전트가 툴을 호출하고, DB에 쓰고, 이메일을 발송하고, 워크플로우를 트리거할 수 있다면—모델과 실행 사이에 결정론적 레이어가 필요하다. 그게 런타임 정책 엔진이다.
구조는 간단하다. 에이전트 오케스트레이터가 툴 호출을 제안하면, 정책 엔진이 먼저 받는다. 정책 엔진은 네 가지 결정만 내린다: 허용(allow), 차단(deny), 보류(hold), 수정(modify). 에이전트는 프로덕션 툴을 직접 호출하지 않는다. 반드시 이 게이트를 통과해야 한다. 이걸 팀이 설계하지 않으면, 에이전트는 사용자 권한을 그대로 위임받아 실행한다. 사용자가 어드민이라면 에이전트도 어드민이 된다—의도와 무관하게.
실제 구현에서 가장 중요한 개념은 두 가지다. 첫째는 액션 엔벨로프(Action Envelope)다. 툴 호출을 날것으로 실행기에 넘기지 말고, 서버가 소유하는 래퍼 객체로 감싼다. 여기에는 테넌트 ID, 사용자 ID, 에이전트 ID, 오퍼레이션 종류(read/write/send/delete), 대상 리소스, 자율성 모드(draft/copilot/autopilot), 환경(dev/staging/production), 예상 비용이 모두 포함된다. 보안 컨텍스트는 모델이 결정하는 게 아니라 앱이 생성한다.
둘째는 위임 범위(Delegation Scope)다. 유저 권한과 에이전트 권한을 분리하는 것이다. OAuth 스코프처럼, 에이전트가 허용된 툴 목록, 허용된 오퍼레이션, 최대 비용, 만료 시간을 명시적으로 정의한다. 서브에이전트는 부모보다 좁은 권한만 받을 수 있고, 더 넓은 권한은 받을 수 없다. 위임은 빠르게 만료되고, 취소는 즉시 반영된다. 이 설계가 없으면 에이전트 체인이 깊어질수록 권한이 축적되는 게 아니라 의도치 않게 확장된다.
AMD ROCm 에이전트 스킬 구축 사례는 이 논의에 현장 증거를 더한다. 개발자 Yechua Silva는 Claude Code, Cursor, Codex 등 9개 코딩 에이전트에서 작동하는 AMD GPU 워크플로우 스킬 10개를 직접 만들었다. NVIDIA는 skills.sh에 428개 이상의 에이전트 스킬을 보유했지만 AMD는 0개였다. 그가 설계한 스킬은 단순한 코드 스니펫이 아니다. GPU 백엔드를 자동 감지하고, Docker 프로파일을 선택하고, 실제 인프라를 조작한다. 에이전트가 프로덕션 인프라에 실제로 손을 대는 구조다. 그리고 바로 그렇기 때문에, 이 스킬이 어느 환경에서 어떤 권한으로 실행되는지를 팀이 정의하지 않으면 위험하다.
세 가지 신호가 같은 방향을 가리킨다. ChatGPT Work는 에이전트가 실제 업무를 실행하는 시대를 선언했다. 런타임 정책 아키텍처는 그 에이전트를 어떻게 통제할 것인지를 설계 언어로 정리했다. AMD ROCm 스킬 사례는 코딩 에이전트가 실제 인프라 자동화에 쓰이고 있다는 현장 증거다. 이 세 가지가 겹치는 지점에서 팀 리드가 해야 할 일이 명확해진다.
팀에 에이전트를 도입하기 전에 물어야 할 질문은 '어떤 모델이 가장 성능이 좋은가'가 아니다. '이 에이전트에게 어떤 툴을, 어떤 조건에서, 어느 수준까지 허락할 것인가'를 먼저 설계해야 한다. 구체적으로는 다섯 가지다. 첫째, 리스크 티어를 정의한다—읽기/초안 작성/가역적 쓰기/외부 사이드이펙트/파괴적 오퍼레이션을 분리한다. 둘째, 각 에이전트에 위임 객체를 부여하고 만료 시간을 짧게 유지한다. 셋째, 외부 발송(이메일, 슬랙, 웹훅)과 삭제 오퍼레이션에는 human-in-the-loop 게이트를 기본값으로 설정한다. 넷째, 툴 인자를 스키마로 검증한다—모델이 생성한 인자가 그럴듯하다고 안전한 건 아니다. 다섯째, 비용 임계값을 설정하고 초과 시 자동으로 보류 상태로 전환한다.
전망은 냉정하게 봐야 한다. ChatGPT Work 같은 툴은 팀의 실행 속도를 실질적으로 높인다. 링센트럴 사례나 버진 애틀랜틱 사례는 과장이 아니다. 하지만 그 속도는 게이트 설계가 선행될 때만 안전하게 유지된다. 에이전트가 더 많은 권한을 가질수록, 프롬프트 수준의 안전장치는 더 빠르게 한계를 드러낸다. 런타임 정책은 선택 사항이 아니다. 에이전트에게 업무를 맡기는 순간부터 팀이 유지해야 할 인프라다. 좋은 소식은, 처음부터 완벽한 규칙 엔진이 필요하지 않다는 것이다. 결정론적이고 테스트 가능하고 인시던트 리뷰에서 설명 가능한 단순한 함수 하나로 시작할 수 있다. 핵심은 그 함수가 존재하는 것이다.