메시지는 권한이 아니다 — 봇이 봇에게 일을 맡기는 시대의 AI 직원 설계
발행일: 2026년 10월 14일
소개
Hermes처럼 늘 깨어 있고, Claude Code처럼 손이 강한 AI 직원. 그런데 그 둘을 합치는 순간 생기는 문제가 있습니다. 반야가 "권한 위임"을 양념이 아니라 그릇으로 보는 이유를 정리했습니다.
1. AI 직원은 말이 아니라 손으로 일을 끝낸다
답만 하는 챗봇은 상담원입니다. 직원이라면 일을 끝내야 하고, 회사의 일은 결국 파일·스크립트·API·장비로 끝납니다. 보고서를 만들고, 데이터를 정리하고, 빌드를 돌리고, 서버 상태를 확인하는 일입니다. 그래서 AI 직원의 엔진은 코드에이전트 입니다. 개발자 전용 도구가 아니라 모든 AI 직원이 공유하는 "손"입니다.
손이 생기면 질문이 바뀝니다. "AI가 무엇을 말했나"가 아니라 "AI가 무엇을 했고, 누가 그걸 시켰나" 가 됩니다.
2. 지금의 봇 협업은 대부분 "메시지 교환"이다
봇이 봇에게 일을 맡기는 구조는 이미 흔합니다. 하지만 들여다보면 두 갈래입니다.
업무 에이전트 플랫폼 에서 봇끼리 주고받는 것은 "이 일을 해 줘"라는 요청과 결과물입니다. 받은 봇은 자기 권한·자기 환경에서 스스로 실행하고, 실행 수단은 대개 미리 연결된 API 커넥터나 업체 클라우드 안의 격리된 실행기입니다. 고객 PC의 셸이나 파일을 다른 봇의 메시지로 직접 움직이는 경우는 드뭅니다. 위험은 작지만, 할 수 있는 일도 그만큼 좁습니다.
코딩 에이전트 의 멀티에이전트는 부모가 자식을 띄우는 위계형입니다. 같은 주인, 같은 프로그램, 같은 권한 안에서 돌아가므로 "다른 봇이 보낸 메시지를 믿어도 되나"라는 질문 자체가 없습니다.
3. 손을 가진 봇이 메시지를 받으면
실제 컴퓨터에서 셸과 파일을 다루면서 메신저로 일을 받는 오픈소스 개인 비서(OpenClaw, Hermes Agent 등)는 설치형 CLI와 상시 게이트웨이로 돌아갑니다. 겉모습은 "늘 깨어 있는 Claude Code"에 가깝고, 그래서 강력합니다.
이들의 출발점은 "내 AI, 내 컴퓨터, 내 책임"입니다. 메시지를 보낸 사람이 곧 주인이므로 받은 메시지를 지시로 처리 합니다. 개인 비서로서는 자연스러운 설계입니다. 통제는 설정·허용 목록·샌드박스로 합니다.
그런데 회사는 다릅니다. 여러 사람, 여러 회사의 AI, 여러 컴퓨터가 섞입니다.
다른 AI의 메시지가 명령이 된다. 한 AI가 프롬프트 인젝션에 속으면 그 지시가 다른 AI의 손으로 전달됩니다.
비밀값이 대화를 타고 퍼진다. 한 AI가 읽은 키가 답장·요약·기록에 섞여 다른 AI와 서버로 흘러갑니다.
사람이 없는 시간에 돈다. 매번 물으면 멈추고, 안 물으면 위험합니다.
누가 시켰는지 남지 않는다. 사고가 나도 원인을 설명할 수 없습니다.
4. 반야의 원칙: 메시지는 참고 자료, 권한은 사람이 발급한다
반야의 AI 직원은 출발점이 다릅니다.
메시지는 누가 보냈든 참고 자료입니다. 다른 봇의 요청은 "할 일 목록"이지 "권한"이 아닙니다.
손을 움직이는 권한은 사람이 보낸 쪽에 발급한 실행 허가에서만 나옵니다. 범위(경로·도구), 횟수, 유효 시간이 정해진 출입증입니다.
판정은 도구가 실행되기 직전에 코드가 합니다. 프롬프트나 설정 파일이 아니라, 이 턴이 사람에게서 왔는지 다른 봇의 메시지에서 왔는지를 보고 그 출처에 맞는 허가로 판정합니다.
누가 누구에게 무엇을 맡겼고 누가 승인했는지 원장에 남습니다.
이 원칙은 기존 에이전트에 설정을 덧붙여서는 만들기 어렵습니다. 판정이 들어갈 자리 — 턴의 출처, 도구 실행 직전, 비밀값의 흐름 — 부터 구조가 달라야 하기 때문입니다. 그래서 우리는 권한 위임을 "양념"이 아니라 "그릇"이라고 부릅니다.
5. 남의 에이전트도 같은 규칙 아래로
반야는 Claude Code나 Codex 같은 코딩 에이전트를 흉내 내지 않습니다. 대신 그들을 좌석 으로 팀에 앉힙니다. 외부 에이전트의 자기 도구 호출도 실행 직전에 같은 출입증으로 판정합니다. 사내에서는 실제로 Claude Code 세션이 좌석으로 들어와 다른 AI 직원과 일을 주고받고 있고, 다른 봇의 메시지로 시작된 턴에서 허가 밖의 일을 하려 하면 사람에게 확인을 받습니다.
6. 승인창과 자율 사이의 균형
원칙이 엄격하면 승인창이 쏟아집니다. 자율 모드의 숙제는 "무엇을 사람에게 남기고, 무엇을 AI가 판단하게 할 것인가"입니다. 최근 개선에서 세운 기준은 이렇습니다.
방향으로 나눕니다. 들어오는 것(다운로드, 패키지 설치, 읽기 조회)은 AI가 판단하고, 나가는 것(업로드, 게시, 원격 변경)은 사람에게 남깁니다.
위험 목록만 사람에게. 예를 들어 Git은 push, 강제 리셋, 브랜치 삭제처럼 작업이나 이력을 잃는 동작만 묻고, 나머지는 AI가 판단합니다.
모르는 문법은 사람에게. 클라우드·배포·DB CLI는 읽기 전용 형태(조회·목록·계획)만 AI가 판단하고, 처음 보는 하위 명령은 기본적으로 사람에게 넘깁니다.
단어 목록이 아니라 구조로. "delete"라는 단어를 찾는 방식은 gcloud ... delete 나 terraform destroy 를 놓칩니다. 도구별로 들어오는 방향의 문법을 인정하고, 나머지는 보수적으로 다룹니다.
7. 다음 단계: 문지기와 기록
방향 판정만으로는 부족합니다. 내려받은 스크립트 자체가 위험할 수 있기 때문입니다. 그래서 실행 직전의 게이트키퍼 를 준비하고 있습니다.
셸 파싱과 정규화: quoting이나 래퍼로 위험 명령을 숨기는 우회를 막기 위해 문자열이 아니라 구문 트리로 판단합니다.
시스템 변경 규칙: 자동 실행 등록, 셸 설정, 방화벽, 키체인처럼 시스템을 바꾸는 동작을 규칙으로 잡습니다. 공개된 연구(정적 규칙 우선, 애매한 경우만 모델 판정)의 결과를 출발점으로 삼습니다.
위협 정보 대조: 접속 대상 IP·도메인을 Spamhaus DROP / ASN-DROP 같은 공개 차단 목록과 대조합니다. 국내 위협 정보와의 연계도 추진하고 있습니다. 대조는 모두 로컬 캐시로 하고, 명령 원문은 외부로 보내지 않습니다.
작은 판사 모델: 규칙으로 애매한 경우만 로컬의 작은 안전 분류 모델이 판정합니다. GPU가 없는 장비에서도 돌 수 있는 크기를 고릅니다.
그리고 이 모든 판단을 개선하려면 데이터가 필요합니다. 승인창이 뜬 명령과 사람의 승인·거부를 명령의 형태만 남기는 방식으로 모아, 어떤 규칙이 불필요하게 사람을 부르는지, 릴리스마다 승인창이 늘었는지를 숫자로 확인합니다.
8. 클라우드 하나가 아니라 모든 장비에서
AI 직원이 일하는 곳은 클라우드 컨테이너만이 아닙니다. 사무실 PC, 사내 서버, 현장의 엣지 장치와 거기 연결된 보드까지입니다. 같은 명령이 맥·윈도우·리눅스에서 다르게 동작하고, 보드 쓰기처럼 되돌릴 수 없는 동작도 있습니다. 메시지는 권한이 아니라는 원칙은 장비가 바뀌어도 그대로이고, 장비마다 다른 규칙이 그 위에 얹힙니다.
맺으며
Hermes처럼 늘 깨어 있고, Claude Code처럼 손이 강한 AI 직원은 이미 만들 수 있습니다. 어려운 것은 그 손을 여러 사람과 여러 AI가 섞인 회사 안에서 안전하게 쓰는 일입니다. 반야는 그 답을 "메시지는 권한이 아니다"라는 한 문장에서 시작합니다.
© 2026. All rights reserved.