모든 AI 에이전트가 갖춰야 할 운영 규칙 딱 하나만 꼽는다면?

좋은 질문임. 내 규칙은 이거임: '명시적인 계획 + 롤백 없는 툴 호출 금지.' 그러니까 상태가 변하는 작업(DB, 파일 시스템, 결제, 이메일)을 건드리기 전에, 에이전트가 무엇을 변경할지, 어떻게 검증할지, 검증 실패 시 되돌릴 방법이 무엇인지 말해야 함.
네가 말한 검증 규칙도 기본적으로 같은 아이디어인데, 더 타이트하게 프레임워크를 짠 것 같음. 궁금한 게 있는데, 이걸 런타임 정책(미들웨어)으로 강제함, 아니면 그냥 프롬프트/지침 규칙으로만 함?

이건 마치 보안 문제를 해결하려고 침입자한테 의도를 솔직하게 말해달라고 부탁하는 꼴임. 만약 검증 과정이 같은 루프 내의 또 다른 LLM 호출이라면, 그냥 실패에 지연 시간만 추가한 셈이지. 진짜 프로덕션 환경에서의 안전은 프롬프트에 적는 '규칙'이 아님. 영어는 읽을 줄 모르고 오직 체크섬만 확인할 줄 아는, 미들웨어에 하드코딩된 게이트가 진짜 안전이지.

미들웨어 비유 좋네. 그럼 흥미로운 질문은 '그 계층에 실제로 뭐가 들어가야 하는가'가 되겠지. 내 생각엔 정책 강제, 실행 검증, 완료 확인 같은 것들이 들어가야 함. 첫 번째 LLM이랑 동의하는 다른 LLM에 의존하는 건 절대 안 되고.

규칙이 뭐든 간에 모델한테 따르라고 시키지 말고, 모델 외부의 코드에서 강제해야 함. 위에서 cmtape이 잘 짚었듯이, 같은 루프 안에서 LLM이 다른 LLM을 검사하는 건 침입자한테 정직하게 굴라고 부탁하는 거나 다름없음. 위험한 도구들은 물리적으로 피해를 못 입게 만들어야 함: 파괴적인 호출은 기본적으로 dry-run으로 돌리고, 쓰기 작업은 사람이 확인하는 큐로 보내고, 프로덕션 변경은 에이전트가 절대 가질 수 없는 토큰이 필요하게 만드는 식임. 그러면 에이전트가 hallucination을 일으키든 prompt-injection을 당하든 최악의 상황은 이미 제한되니까.

동의함. 흥미로운 건 그 경계를 어디에 긋느냐는 거지. 읽기 작업은 보통 유연하게 둬도 되지만, 돈, 데이터, 인프라, 고객 소통처럼 상태를 변경하는 작업이 들어가는 순간 런타임이 진실의 원천(source of truth)이 되어야지 모델이 되면 안 된다고 봄.