60%의 팀이 실행 중인 AI 에이전트를 강제 종료하지 못함. 다들 킬 스위치 어떻게 관리함?

타임아웃은 킬 스위치가 아니지. 나는 모든 툴 호출 사이에 취소 토큰(cancellation token)을 확인하고, 이미 시작된 작업에 대해서는 멱등성(idempotent) 보장이나 보상 작업(compensating action)이 이루어지길 원함.

진짜 문제지. 대부분 팀은 해피 패스만 가정하고 넘어가더라. 내가 실제로 효과 본 패턴 몇 개 알려줌. 툴 레벨 게이트가 저평가되어 있음. 예를 들어, 사용자가 '판매 실적 상위 5개 보여줘'라고 했는데 LLM이 갑자기 CREATE TABLE을 실행하려 한다고 치자. SQL 생성 툴에 DDL/DML 작업을 감지해서 거부하거나 사람 승인 단계로 넘기는 게이트를 잘 설치해두면 데이터베이스에 닿기 전에 막을 수 있음. 에이전트가 사고 칠 기회조차 안 주는 거지. 툴이 그냥 거부해버리니까.

내 생각엔 '킬 스위치'라는 접근 방식 자체가 좀 거꾸로 된 것 같음. 이미 실행 중인 에이전트를 강제 종료한다는 건, 이미 뭔가를 잃었다는 뜻이잖아(이미 작성했거나, 보냈거나, 커밋한 것들). 실무에서 진짜 효과적인 건 위험한 작업 전에 체크포인트를 두는 거임. 파괴적인 툴 호출은 실행 전에 무조건 사람 승인을 거치게 하는 거지. 런타임 킬 스위치보다 구현도 쉽고, 실패해도 '작업 대기' 상태가 되지 '데이터 삭제'가 되진 않으니까. 이거 안 하는 팀들은 거의 항상 똑같은 소리 하더라: 우리...

킬 스위치보다는 체크포인트 방식으로 접근해야 한다는 말에 전적으로 동의함. 근데 문제가 하나 있음. 실행 중에 멈춰야 할 때, 이미 실행된 작업의 영향 범위를 알아야 한다는 거임. 툴 3개 호출하고 외부 시스템 2곳에 기록한 에이전트를 멈추는 건, 0단계에서 멈추는 거랑은 차원이 다른 문제임. 툴을 멱등성 있게 구현하고 작업별로 실행 로그를 남겨야 킬 스위치가 진짜 안전하게 작동함.

스위치 끄는 건 쉬움. 어려운 건 스위치를 당겼을 때 어떤 상태가 되느냐임. 작업 도중에 에이전트를 죽이는 건 그 작업이 중단해도 안전할 때나 가능한 건데, 중요한 작업들은 대부분 그렇지 않음. 전송, 쓰기, 삭제 중에 멈추면 그냥 끝까지 두는 것보다 상황이 더 꼬일 수 있음. 작업이 반쯤 완료된 상태에서 어디까지 진행됐는지 알 방법이 없으니까. 나한테 진짜 도움 된 건 킬 스위치보다는 안전한 중단 지점을 설계하는 거였음.