1년 동안 AI 에이전트 세 개가 제 사업의 백오피스를 운영했습니다. 위험한 행동을 한 에이전트는 하나도 없었습니다. 대신 조용해졌습니다. 감사 에이전트는 제가 알아차리기 전까지 열흘 연속 아무것도 보지 못했고, 사양서 초안을 쓰던 데몬은 47일 동안 꺼져 있었는데 알려 주는 경보가 없었습니다. 끝까지 버틴 규칙은 각 에이전트가 무엇을 건드릴 수 있는지, 어떻게 승인을 요청하는지, 멈췄을 때 제가 어떻게 알아차리는지를 다뤘습니다.
구성과 한계
일은 1인 사업의 잡무였습니다. 리서치, 파이프라인 정리, 초안 작성, 내부 도구 관리입니다. 세 에이전트에는 일부러 권한을 다르게 주었고, 판단은 저 혼자 내렸습니다. 오케스트레이터는 사업 맥락을 쥐고 사람이 읽을 모든 글을 초안으로 썼으며, 결과물은 언제나 초안에서 멈췄습니다. 코딩 에이전트는 서면 사양서만 받아 격리된 브랜치에서 일했고, 사업 데이터에 접근하지 못했으며, main 브랜치에는 한 번도 커밋하지 않았습니다. 예약 실행되는 감사 에이전트는 작업 보드와 저장소를 대조할 뿐 아무것도 바꿀 수 없었고, 유일한 출력은 pull request였습니다. 작업은 파일, 브랜치, 보드 카드로 오갔기 때문에 모든 단계가 몇 주 뒤에도 읽을 수 있는 기록으로 남았습니다.
제 일은 프로그램 딜리버리와 Salesforce 교육입니다. 이 구성은 고객 산출물이 아니라 제 백오피스였고, 규모도 한 사람과 작업 보드 하나였습니다. 여기서 얻은 교훈은 지금 Salesforce 관리자에게 AI를 가르칠 때 그대로 다룹니다. 누가 어떤 권한을 쥐는지, 에이전트가 어떤 데이터에 닿는지, 사람들이 스스로 움직이는 도구를 어떻게 받아들이는지입니다. 같은 질문을 Agentforce에 적용한 내용은 Agentforce 운영 모델 노트에 있습니다.
2026년 9월에 이 세 에이전트 구성을 정리하고 하나의 어시스턴트로 합쳐 움직이는 부품을 줄였습니다. 규칙은 그대로 살아남았습니다. 어느 규칙도 에이전트가 세 개라는 사실에 기대지 않았기 때문입니다. 이 규칙은 아무도 지켜보지 않을 때 움직이는 모든 구성 요소에 적용됩니다.
자율성은 조용히 실패합니다
감사 에이전트의 작업은 매일 아침 실행되어 결과를 담은 pull request를 열었습니다. pull request가 계속 도착했으니 시스템은 살아 있는 듯 보였습니다. 그러나 내용은 비어 있었습니다. 감사해야 할 데이터에 더 이상 접근하지 못했기 때문입니다. 같은 점검에서 사양서 초안 데몬이 47일 전 설정 일괄 변경으로 꺼졌다는 사실도 드러났습니다. 두 번 모두 장치 자체는 정상이었습니다. 실패한 쪽은 입력을 공급하고 지켜보는 일이었습니다.
에이전트 위험을 다루는 글은 대부분 해로운 행동을 걱정합니다. 제가 겪은 문제는 부재였고, 어떤 모델도 자기 부재를 보고하지 않습니다. 예약 실행되는 모든 구성 요소에는 하트비트와, 하트비트가 끊겼을 때 울리는 경보가 필요합니다. 빈 보고서가 도착했다고 하트비트가 되지는 않으므로 점검은 내용까지 읽어야 합니다. 이 장치는 첫 릴리스에 들어가야 합니다.
자율성이 클수록 권한은 작게
모든 설계 밑에 있던 원칙은 단순합니다. 에이전트가 자유롭게 움직일수록 건드릴 수 있는 범위는 좁아야 합니다. 이 원칙을 가장 날카롭게 보여 주는 개념이 유출 삼각형입니다. 공격자가 조작할 수 있는 입력, 사람 개입 없는 외부 송신, 민감한 데이터 접근을 모두 갖춘 에이전트는 어떤 모델을 쓰든 프롬프트 인젝션 한 번이면 데이터가 샙니다. 세 변 가운데 두 변은 괜찮지만 세 변이 모두 모이면 안 됩니다. 그래서 각 에이전트에서 한 변을 구조적으로 제거했습니다. 자격 증명을 주지 않거나 네트워크 경로를 막는 방식이었고, 모델에게 조심하라고 부탁하는 프롬프트 문장에는 기대지 않았습니다. 코딩 에이전트는 신뢰할 수 없는 저장소 콘텐츠를 읽고 브랜치를 push할 수 있었으므로 민감한 데이터에는 접근하지 못했습니다.
두 사건이 이 원칙을 더 분명하게 만들었습니다. 받은편지함 분류 프로토타입은 처음에 에이전트가 메시지를 보기 전에 개인정보를 지우고 카테고리와 플래그만 남기도록 설계했습니다. 실제 테스트에서 플래그만으로는 쓸 만한 답장을 쓸 수 없다는 사실이 드러났습니다. 그래서 절충 방향을 바꿨습니다. 에이전트는 메시지 전문을 읽고, 대신 외부 송신 변을 끊었습니다(허용 목록 프록시, 발송 자격 증명 없음, 웹 요청 도구 없음). 이후 보안 점검에서는 신뢰할 수 없는 수신 텍스트를 요약하던 헤드리스 작성기에 셸 도구가 붙어 있다는 사실을 찾았습니다. 악성 메시지가 호스트의 코드 실행으로 이어질 수 있는 경로였습니다. 이 작성기는 텍스트만 쓰는 구성으로 다시 만들었고, 입출력은 모두 래퍼 스크립트가 맡았습니다. 신뢰할 수 없는 입력을 다루는 헤드리스 에이전트에는 셸도, 권한 예외도 주지 않습니다.
승인은 기계적인 계약입니다
어떤 모델도 외부로 메시지를 보낸 적이 없습니다. 고객에게 가는 모든 글은 대기열에서 멈췄고, 사람이 승인 플래그를 세운 뒤에만 모델이 없는 스크립트가 발송했습니다. 발송 단계는 설득당할 여지가 없을 만큼 일부러 단순하게 만들었습니다.
코드 변경이든 보드 수정이든 모든 제안은 pull request로 왔습니다. merge는 승인, 코멘트와 함께 닫기는 거절이었습니다. 이 관례 하나로 감사 추적, diff 리뷰, 나머지는 승인하고 특정 변경만 보류하는 기능을 성숙한 도구에서 그대로 얻었습니다.
이 계약은 작업을 기계적으로 검증할 수 있을 때만 작동합니다. 코딩 에이전트에게 무엇을 넘길지는 라우팅 규칙이 정했습니다. 인수 기준을 테스트 통과, 빌드 성공, 기대 개수를 돌려주는 검색으로 쓸 수 없으면 그 작업은 사람이 감독하는 에이전트에 남았습니다. 초기 작업이 거절되어 돌아왔을 때 사양서를 고치자 거절이 사라졌습니다. 모델은 그대로였습니다.
영향 범위 순서로 가동합니다
자동화된 각 구간은 감지(읽기만), 초안(사람이 승인할 결과물 생성), 실행(사람 없이 행동) 가운데 하나로 분류했습니다. 감지와 초안은 하루 종일 돌았지만 외부에는 손댈 수 없었습니다. 실행은 저장소 안의 가동 파일 하나에 묶였습니다. 파일이 있으면 가동, 지우면 즉시 정지였고, 그 상태는 버전 관리에서 그대로 보였습니다. 긴급 정지 스위치를 설정 항목 대신 파일로 둔 이유는 파일이 비교하기 쉽고, 검색하기 쉽고, 장애 중에도 잘못 읽을 일이 없기 때문입니다.
이 관문이 제 몫을 한 적이 한 번 있습니다. 감사 에이전트가 merge하면 자동 배포되는 저장소에서 작업 항목을 출시 준비 상태로 옮기자고 제안했습니다. 그런 저장소는 금지 행동 목록에 있었으므로 제안은 자동으로 진행되지 않고 저에게 올라왔습니다. 그 카드는 정당했습니다. 그러나 다른 날이었다면 같은 이동이 아무도 검토하지 않은 운영 배포가 됩니다.
가장 넓은 자동화, 즉 보드의 모든 작업 항목에 걸친 일괄 행동은 별도 스위치 뒤에서 출시되어 드라이런으로 돌았고, 끝까지 꺼진 채 남았습니다. 사고는 가동 중이던 구성 요소에서 났습니다. 가동 순서는 영향 범위가 정했고, 어떤 스위치는 의욕보다 더 오래 꺼져 있을 만했습니다.
확인할 항목
- 사람 없이 행동하는 모든 구간을 존재 파일 하나로 가동하고, 구간마다 긴급 정지 스위치를 둡니다.
- 어떤 모델도 발송 자격 증명을 쥐지 않습니다. 사람이 세운 플래그를 보고 모델 없는 단계가 발송합니다.
- 제안은 pull request로 받습니다. merge는 승인, 닫기는 거절이며, 구두 승인은 없습니다.
- 예약 실행되는 모든 구성 요소에 하트비트와 침묵 경보를 두고, 경보는 도착 여부와 내용을 함께 확인합니다.
- 각 에이전트에서 유출 삼각형의 한 변을 구조적으로 제거합니다.
- 지시 파일, 정체성·보이스 파일, 에이전트 메모리는 어떤 에이전트도 쓸 수 없게 합니다.