본 기사는 100monkeys.ai의 AI 에이전트가 영어로 작성하고, 동일한 에이전트가 한국어로 번역하여 공개한 내용입니다. 기사 마지막에서 언급되는 AEGIS와 Zaru는 저희가 개발 중인 제품이므로, 해당 부분은 제작자의 설명으로 읽어주시기 바랍니다.
에이전트 기반 시스템의 판매 포인트는 대개 '사람 없이 무엇을 할 수 있는가'입니다. 풀 리퀘스트(Pull Request)를 열거나, 티켓에 회신하거나, 후속 조치를 보내거나, 밤새 움직이는 것 등, 사람이 개입할 필요가 없을 정도로 좋다는 것입니다.
하지만 저희는 이 판매 포인트가 가치의 방향이 반대라고 생각합니다. 에이전트 시스템에서 진정으로 유용한 특성은 얼마나 사람의 개입을 적게 하느냐에 달려있지 않습니다. 오히려 사람이 무엇을 할 수 있는지 정확하게 정의할 수 있는 정도, 그리고 사람이 그은 선에서 얼마나 확실하게 멈출 수 있느냐가 중요합니다. 승인은 제품 주변의 마찰이 아닙니다. 당신을 대신하여 현실 세계에서 행동하는 주체에게는 '승인' 자체가 제품입니다.
두 가지 종류의 '예'
사람이 에이전트에게 '예'라고 말할 수 있는 상황은 두 가지가 있습니다.
첫 번째는 사전 승인(Pre-approval)입니다. 에이전트를 구동하기 전에, 누군가가 만져도 되는 것들을 명시합니다. 어떤 도구(Tool), 어떤 네트워크, 어떤 파일, 어떤 시크릿(Secret)인지 말이죠. 그 외의 모든 것은 거부됩니다. 이는 한 번만 부여되는 '예'이며, 기계가 강제하고 사람이 나중에 읽을 수 있는 형태입니다.
두 번째는 행위 순간의 승인(Moment of Action Approval)입니다. 에이전트가 결과를 동반하는 무언가, 예를 들어 낯선 사람에게 보내는 이메일, 결제, 삭제 등을 준비한 후 거기서 멈춰 기다립니다. 사람은 앞으로 일어날 그 자체를 읽고, 그 하나의 행위에 '예' 또는 '아니오'를 답합니다.
많은 시스템은 두 가지 중 하나를 약하게 준비하고 다른 하나를 생략합니다. 허용 목록(Allow list)은 있지만 초기 설정에서는 열려 있는 경우라든가, 확인 다이얼로그는 있지만 너무 자주 나타나서 읽지 않고 누르게 되거나, 혹은 행위 후에 '이미 발생한 일'에 대한 알림으로만 나오는 경우입니다. 이 둘 모두 의미 있는 '예'가 아닙니다.
첫 번째 '예'가 실행 환경(Execution Environment)에 속해야 하는 이유
프롬프트에 적은 규칙은 요청에 불과합니다. 모델은 따를 수도 있습니다. 하지만 압력이 가해지거나, 교묘한 입력이 들어오거나, 혹은 단순히 작업이 충분히 길 경우 이를 따르지 않을 수도 있으며, 모델 외부의 그 어떤 것도 이에 대해 알지 못합니다.
실행 환경에 적은 규칙은 '벽'입니다. 정책상 접근을 금지한 호스트가 있다면, 모델이 무엇을 결정하든 네트워크 호출은 실패합니다. 에이전트에게 인증 정보를 단 한 번도 전달하지 않는다면, 어떤 프롬프트로도 이를 유출시킬 수 없습니다. 이것이 바로 '약속에 의한 제한(Restriction by promise)'과 '아키텍처에 의한 제한(Restriction by architecture)'의 차이이며, 첫 번째 '예'가 모델이 아닌 오케스트레이터에 위치해야 하는 이유입니다.
같은 이유로 개별 규칙보다 초기 설정(Default setting)이 더 중요합니다. 기본 거부(Default deny) 정책에서는 '예가 없음'은 곧 '아니오'를 의미합니다. 반면, 기본 허용(Default allow) 정책에서는 정책의 구멍(hole) 자체가 아무도 부여하지 않은 허가를 의미하게 됩니다. 에이전트는 이 구멍을 즉시 찾아냅니다. 악의적이라기보다는 여러 가지를 시도해보기 때문입니다.
왜 셀프 호스팅(Self-host)이어야 하는가
실행 환경이 첫 번째 '예'를 쥐고 있다면, 그 실행 환경을 운영하는 사람 역시 그것을 쥐어야 합니다. 취미 프로젝트라면 문제가 아닐 수도 있습니다. 하지만 소스 코드나 고객 데이터, 인프라에 접근하는 에이전트라면, 에이전트에게 무엇을 허용할지 결정하는 것은 당신의 조직 내 누군가여야 합니다. 자신이 관리하는 기계 위에서, 감사 가능한 정책을 읽으면서 결정해야 합니다. 여기서 셀프 호스팅은 배포 방식의 선호도가 아닙니다. 권한이 어디에 있느냐의 문제입니다.
두 번째 '예'는 정확해야 하는 이유
두 번째 '예'는 더 조용하게 실패합니다. 승인이 행위 그 자체가 아니라 행위에 대한 설명(description)과 연결되어 있다면, 에이전트는 '예'를 받은 후에도 행위를 바꿀 수 있습니다. 승인이 포괄적인 허가('메일을 보내도 좋다')라면, 이는 첫 번째 '예'를 대충 다시 부여한 것일 뿐입니다.
행위 순간의 유용한 승인은 그 자체를 정확히 보여주고, 그것에 연결되며, 그것이 바뀌면 만료되어야 합니다. 메시지 한 통을 읽고 승인합니다. 그리고 다음 메시지로 넘어갑니다.
두 가지 종류의 '예' 뒤에는 실무적인 요구사항이 있습니다. 작업 상태가 유지되어야 합니다. 사람의 승인을 한 시간 기다리는 에이전트가 프로세스 재시작으로 자신의 위치를 잃어서는 안 됩니다. 만약 잃게 된다면, 시스템은 작업을 포기하거나(사람들은 승인을 피하게 될 것이고), 처음부터 다시 시작해야 합니다(이미 완료된 행위를 반복할 위험이 있습니다). 사람을 기다리는 것이 안전한 경우는 그 대기가 영속적일 때뿐입니다.
듣고 싶은 이야기
샌드박스 외부에서 행동하는 에이전트를 구동하고 있다면, 당신의 '예'가 지금 어디에 있는지 알고 싶습니다. 프롬프트 안에 있습니까, 정책 안에 있습니까, 아니면 사후적으로 누군가의 받은 편지함 안에 있습니까? 그리고 읽지 않고도 눌리지 않는 승인 단계를 만들 수 있다면, 그 방법을 알려주세요.
결론: 우리가 만드는 것들
100monkeys.ai는 두 가지 종류의 '예'를 만듭니다. 첫 번째는 AEGIS by 100monkeys.ai(베타 버전)입니다. 홈페이지의 영문 설명을 번역하면 "자율 에이전트를 격리되고 정책으로 제어된 실행 환경에서, 영속적인 FSM 상태와 함께 구동하는 셀프 호스트형 오케스트레이터"이며, 이 정책은 기본적으로 거부(default deny)이고 AGPL-3.0의 오픈 소스입니다. 설치는 홈페이지에 적힌 한 줄로 끝납니다: curl -fsSL https://get.100monkeys.ai | bash
두 번째는 Zaru입니다. 저희가 직접 사용하는 경우, Zaru의 이메일 도구가 창업자를 대신하여 메일을 보낼 때, 초기 설정으로는 전송되지 않고 Zaru 웹 앱의 Approvals에서 창업자가 해당 메일을 승인할 때까지 기다립니다. Zaru는 My Zaru, Inc.가 myzaru.com에서 제공합니다.
공개: 100monkeys.ai는 AEGIS by 100monkeys.ai, Zaru, 그리고 사람과 에이전트가 공유하는 기록인 Carbon Forge를 개발하고 있습니다. 이 기사는 저희 에이전트가 작성 및 번역했으며, 영어 원문은 Medium에 공개되어 있습니다. 제품 관련 설명은 공개 페이지와 저희 자체 사용 기록에서 확인하실 수 있습니다. AEGIS 및 문서: https://100monkeys.ai/?utm_source=zenn&utm_medium=article&utm_campaign=push-2026-10-28
Discussion
