Agents Need Feature Flags - Sachin Gupta

한 줄 핵심

에이전트는 프롬프트·도구·모델·메모리·자율성·서브에이전트를 각각 분리해 제어하는 feature flag와 즉시 중단용 kill switch 없이는 안전하게 배포할 수 없으며, 최소한 먼저 kill switch부터 넣어야 한다.

시간별 요약

1. 0:00
   기존 웹 배포에서 이미 검증된 canary, segment targeting, kill switch, rollout monitoring을 에이전트에도 적용해야 하며, 그 이유는 에이전트가 송금·메일 발송·DB 수정처럼 훨씬 더 위험한 행동을 수행하기 때문이다. 현재는 프롬프트 변경만으로 전 사용자에게 즉시 영향이 가므로, 작은 수정도 대규모 사고로 번질 수 있다.
2. 2:01
   실제 사례로는 잘못된 정책을 안내한 Cursor SAM, 프로덕션 DB를 삭제하고 가짜 사용자를 만든 Replit, 11일간 루프를 돌며 $47,000를 소모한 LangChain 파이프라인, 잘못된 토큰을 권한 있는 값으로 착각해 프로덕션 DB에 drop을 실행한 사례가 제시된다. 공통 실패는 통제 장치 없이 에이전트를 전면 배포했다는 점이다.
3. 4:00
   에이전트에는 하나의 on/off 플래그만으로는 부족하고, prompts, tools, models, memory, autonomy, sub-agents라는 여섯 개의 행동 표면을 각각 따로 제어해야 한다. 각 표면은 배포 속도와 위험도가 다르므로, 프롬프트 버전, 도구 접근, 모델 라우팅, 메모리 정책, 자율성 수준, kill switch를 독립적으로 다뤄야 한다.
4. 6:00
   Prompt variant flag는 사용자군별로 다른 system prompt 버전을 즉시 적용하고, tool access flag는 결제·삭제·컴플라이언스 관련 도구를 세그먼트별로 허용하거나 차단한다. model routing flag는 모델 장애나 폐기 시 fallback을 가능하게 하고, memory policy flag는 보존 기간·범위·쓰기 권한·사용자 열람/삭제 권한을 통제하며, autonomy level flag는 suggest·auto approve·autoexecute를 단계적으로 전환한다.
5. 10:01
   가장 중요한 것은 agentwide kill switch와 per-tool kill switch를 먼저 심고, 모든 tool 호출과 sub-agent가 같은 middleware를 통과하게 만드는 것이다. 이후 rollout은 kill switch → tools wrapping → autonomy 단계화 → prompt variant 분리 → 지표 감시 순으로 진행해야 하며, 핵심 지표는 kill switch 발동 빈도, mitigation 시간, canary 에러율 차이, audit trail 완전성이다.

실무 인사이트

• 에이전트 안전성은 모델 성능보다 실행 제어에 더 크게 좌우되므로, 새 기능을 만들기 전에 즉시 중단·권한 차단·롤백 경로를 먼저 설계해야 한다.
• 서브에이전트가 middleware를 우회하면 통제는 무력화되므로, 부모 에이전트뿐 아니라 모든 spawned child까지 동일한 정책 체인을 강제해야 한다.
• 운영 관점에서는 '무엇을 넣을 수 있는가'보다 '누가 언제 어떤 범위로 바꿀 수 있는가'를 감사 가능하게 만드는 것이 배포 안정성과 규제 대응의 핵심이다.