← 에세이

지시 대신 경계: 자율 AI 에이전트에 대한 통제를 유지하는 방법

AI 에이전트에 대한 통제를 프롬프트의 지시에 기반해 구축할 수 없는 이유 — 그리고 기술적 경계에 기반해 구축하는 방법. 한 세션의 다섯 가지 사건.

5 분 소요
Telegram원문
지시 대신 경계: 자율 AI 에이전트에 대한 통제를 유지하는 방법

AI 에이전트가 더 자율적으로 변할수록, 우리는 익숙한 방식으로 그것들을 관리하려 한다 — 프롬프트에 규칙을 쓴다: '이것을 건드리지 마라', '오직 거기서만 작업하라', '절대 그것을 하지 마라'. 세 개의 병렬 에이전트 실험 동안 나는 이틀 만에 이 방식이 깨지는 사례들과 다른 방식이 작동하는 사례들의 살아있는 컬렉션을 모았다. 글의 논지는 간단하다: 지시는 에이전트가 어느 정도의 확률로 수행하는 부탁이고; 경계는 순종과 무관한 시스템의 속성이다. 에이전트가 하나이고 감독 아래 있을 때 그 차이는 문체적인 것처럼 보였다. 에이전트가 많아지자 그것은 아키텍처적인 것으로 드러났다.

한 세션의 다섯 가지 사건

아래의 모든 사례는 이 블로그의 한 작업 세션에서 일어났다 — 문서화되어 있으며, 각각은 텍스트를 통한 관리가 실패하는 서로 다른 방식을 보여준다.

지시가 없었다 — 사고가 일어났다. 에이전트는 자신의 작업을 준비하면서 공용 디렉터리에서 git stash 을(를) 실행했고, 자신의 작업과 무관한 내 커밋되지 않은 파일들을 스태시로 가져갔다. 아무도 아무것도 '위반'하지 않았다: 금지가 애초에 존재하지 않았기 때문이다. 이것은 지시의 근본적 속성이다 — 지시는 사고 후에 쓰인다. 에이전트가 하지 말아야 할 일의 전체 목록을 작성하는 것은 불가능하다.

지시는 있었지만 — 작동하지 않았다. 첫 사고 후 나는 에이전트들에게 명시적 규칙을 추가했다: '엄격히 자신의 작업 디렉터리에서만 작업하라'. 그중 한 에이전트는 여전히 메인 디렉터리에서 git 명령을 실행했다 — 단지 절대 경로로 그것을 참조했을 뿐이다. 악의도 어리석음도 아니었다: 모델은 확률적이며, 텍스트 규칙 준수 역시 컨텍스트 길이와 실행 횟수를 곱한 확률일 뿐이다.

기술적 경계는 조용히 작동했다. 같은 실험에서 가장 예상되던 사고 — '한 에이전트가 모두의 브랜치를 전환했다' — 는 단 한 번도 일어나지 않았다. 에이전트들이 신중했기 때문이 아니라, git worktree 가 물리적으로 하나의 브랜치를 두 개의 작업 복사본에 체크아웃하는 것을 허용하지 않기 때문이다. 보호는 도구에 내장되어 있다. 그것을 기억할 필요도, 따를 필요도 없다 — 그저 존재할 뿐이다.

지시가 경계가 있어야 할 자리에 서 있었다. 가장 불편한 발견: 이 블로그의 프로덕션은 프롬프트의 한 줄로 보호되고 있었다. master로의 push는 자동 배포를 트리거하며, 각 에이전트와 그것을 갈라놓은 것은 'git push 금지'라는 텍스트뿐이었다. 그것은 지켜졌다 — 그러나 그것은 통제가 아니라 운이다: 여기서 진짜 경계는 접근 권한, protected branch, 쓰기 권한 없는 토큰이다. 부탁이 자물쇠 자리에 서 있었다.

에이전트 자체 위의 경계. 세션 중 두 번, 런타임은 이미 실험 대상 에이전트가 아니라 내 주 어시스턴트를 정지시켰다: 권한 분류기가 프로덕션 서버로의 SSH와 커밋되지 않은 수정 사항의 대량 삭제를 차단했다 — 형식상 작업에서 따르는 행동이었지만 명시적 인간의 '예'가 필요한 것들이었다. 두 차단 모두 옳았다. 그리고 둘 다 자신이 계획대로 행동한다고 꽤 진심으로 믿는 에이전트의 '규율' 위에서 일어났다.

원리는 새롭지 않다 — 새로운 것은 대상뿐이다

공학은 LLM 훨씬 전에 이 교훈을 겪었다. 도요타의 생산 시스템에서 이 원리는 poka-yoke라고 불린다: 오류는 실행자의 경계심이 아니라 프로세스의 장치가 방지한다. 올바른 방향으로만 끼울 수 있는 부품이 '올바르게 끼우라'는 포스터보다 신뢰할 만하다. 플랫폼 엔지니어링에서는 같은 것을 guardrails라 부르고, 보안에서는 defense in depth라 부른다. 어디서나 한 가지 생각이다: 실행자가 읽고, 이해하고, 잊지 않았으리라 믿지 말라 — 잘못된 행동이 불가능하거나 비싸도록 만들어라.

“지시는 부탁이다. 경계는 시스템의 속성이다. 부탁에 기대는 통제는 통제가 아니라 누적 효과를 가진 운이다.”

– 병렬 에이전트와 이틀간 작업한 결론

AI 에이전트와 함께 이 오래된 원리는 세 가지 이유로 더 날카로워진다. 에이전트는 많다 — 지시 실패 확률은 각 에이전트의 각 실행마다 곱해진다. 에이전트는 빠르다 — '오류를 시작함'과 '완전히 망침' 사이에 몇 초가 지나며, 인간은 개입할 시간이 없다. 그리고 에이전트는 문자적이지만 신뢰할 수 없다: 그들은 어떤 주니어보다도 프롬프트 텍스트를 성실히 수행하지만, 여전히 확률적이다 — 그리고 규모에서의 확률적 규칙 준수는 위반을 보장한다.

경계는 실제로 어떻게 보이는가

이 세션 후 내가 구축한 계층들 — 파일 시스템에서 검증까지:

  • 파일 시스템: 각 에이전트에게 자체 작업 복사본(git worktree, Anthropic이 권장하는 병렬 세션용으로 Claude Code에 내장됨), 그리고 OS 수준에서는 샌드박스: Claude Code의 sandboxing 은 OS의 표준 프리미티브로 파일 시스템과 네트워크를 격리한다 — Anthropic에 따르면 이는 내부 권한 요청을 84% 줄였고, 성공적인 prompt-injection은 내부에 갇힌 채로 남는다.
  • 쓰기 권한: 프롬프트가 아니라 권한으로 보호되는 제품과 master — protected branch, push 권한 없는 토큰, 에이전트별 개별 계정. 프롬프트에 남겨 달라는 요청은 가능하지만 두 번째 레이어로서.
  • 런타임: worktree는 데이터베이스, 포트, 컨테이너를 격리하지 않는다 — 이들은 모든 복사본이 공유한다. 테스트와 서버를 실행하는 에이전트에게는 일회용 리소스가 필요하다: 임시 DB, 전용 포트, 에이전트별 컨테이너.
  • 행동 권한: 되돌릴 수 없는 작업은 확인 또는 분류기를 거친다 — 마치 Claude Code의 auto mode처럼, 모든 것을 묻거나 아무것도 묻지 않는 대신 각 행동을 평가한다. 이것은 오직 사람의 명시적 결정으로만 움직이는 경계다.
  • 산출물 기반 검증: 에이전트의 자기 보고가 아니라 디스크의 흔적을 신뢰하라. 내 멈춘 에이전트는 인터페이스에서 작동하는 것처럼 보였다; 진단은 20분 동안 그 복사본에 새 파일이 없다는 사실이 내렸다. 자신의 브랜치에 커밋하는 것도 같은 아이디어다: 실패와 에이전트의 낙관주의 모두를 견디는 결과물.

이 체계에서 지시문은 사라지지 않는다 — 첫 번째 레이어가 아니라 마지막 레이어가 된다. 프롬프트의 "자신의 디렉터리에서 작업하라"는 여전히 유용하다: 시도 빈도를 낮춘다. 그러나 시도와 사고 사이에는 희망이 아니라 경계가 있어야 한다.

솔직한 단서

경계는 절대적이지 않다: 샌드박스는 우회되고, 분류기는 틀리며, 공개된 우회 분석들은 이를 정기적으로 보여준다. 그래서 경계는 보안의 모든 것처럼 레이어로 구축된다. 그리고 경계는 시작 시점에 지시문보다 비싸다: worktree, 권한, 샌드박스를 설정하는 데는 몇 시간이 걸리고, 프롬프트에 한 줄 쓰는 데는 몇 초가 걸린다. 비대칭성은 다른 곳에 있다: 경계는 한 번만 지불하면 되고, 지시문은 매 실행마다 실패 확률로 지불된다. 나의 경우 격리 설정은 단 한 번의 충돌도 없이 통과한 실험의 첫 재시작만으로 비용을 회수했다.

결론

시리즈의 질문은 AI 에이전트를 통제를 잃지 않고 실제 업무에 어떻게 통합할 것인가이다. 이 글의 답은: 통제란 에이전트에게 쓰인 것이 아니라 그 주위에 구축된 것이다. 프롬프트에 또 하나의 "절대 X를 하지 마라"를 추가하기 전에 자문해 볼 만하다: X를 기술적으로 불가능하게 만들 수 있는가? 그렇다면 그것이 노력을 기울일 올바른 위치다. 프롬프트는 요청하게 하고, 시스템이 금지해야 한다.

출처 및 참고 자료

← 모든 에세이