"I've never seen anything scarier than an LLM with tool calls." — Erik Meijer aka @HeadinTheBox

한 줄 핵심

도구 호출을 가진 LLM 에이전트는 즉시 실제 세계에 피해를 줄 수 있으므로, 실행을 분리하고 프로그램과 증명을 함께 만들어 검증 가능한 하네스로 감싸야만 안전하다는 주장이다.

시간별 요약

1. 0:01
   발표는 AI 에이전트가 단순한 질의응답을 넘어 실제 파일과 시스템을 망가뜨릴 수 있는 존재가 되었음을 문제의 출발점으로 삼는다. 그래서 막연한 신뢰가 아니라, 모델의 행동을 구조적으로 제한하고 증명 가능한 안전장치를 두어야 한다는 방향을 제시한다.
2. 4:01
   초기 LLM은 질문에 답하는 인터페이스에 머물렀지만, 프롬프트 인젝션과 유해 지식 노출, 그리고 안전성 판정의 불확실성 때문에 단순한 텍스트 모델만으로는 안전을 보장할 수 없다는 한계가 드러난다. 특히 안전은 수학적으로 직접 정의하기 어렵고, 기존의 정렬만으로는 탈옥을 막기 어렵다는 점을 강조한다.
3. 11:02
   tool calls가 추가되면서 LLM은 말만 하는 존재가 아니라 실제로 외부 세계에 side effect를 일으키는 존재가 되며, 이때부터 위험은 철학이 아니라 실행 사고의 문제가 된다. 에이전트가 계획을 수행하는 순간 은행 계좌, 파일, 데이터베이스에 돌이킬 수 없는 변경을 가할 수 있으므로, 실행 권한이 곧 안전의 핵심 쟁점이 된다.
4. 14:00
   해결책으로는 에이전트가 직접 실행하지 않고 먼저 계획을 생성하게 한 뒤, 별도의 실행 주체가 그 계획을 검증·실행하도록 분리하는 방식이 제시된다. 더 나아가 plan 자체를 검증 불가능한 블랙박스로 두지 않고, 프로그램 표현과 proof-carrying code로 바꿔 정적 분석과 타입 검사를 가능하게 만들어야 한다는 논리가 이어진다.
5. 18:01
   핵심 결론은 에이전트가 생성한 작업을 평문 자연어가 아니라 분석 가능한 프로그램으로 바꾸고, 그 프로그램이 안전하다는 증명을 함께 요구하면 기계적으로 검증할 수 있다는 것이다. 결국 안전한 에이전트는 '잘 부탁하는 프롬프트'가 아니라, 타입 시스템·정적 분석·증명 결합으로 만들어야 한다는 메시지로 마무리된다.

실무 인사이트

• 에이전트에 도구를 붙일 때는 먼저 실행 권한을 분리하고, 실제 실행 전 검증 단계를 강제하는 하네스 설계가 필요하다.
• 자연어 계획만으로는 안전성을 판단하기 어렵기 때문에, 중요한 작업은 프로그램 표현으로 변환해 정적 검사와 감사 가능성을 확보하는 편이 유리하다.
• LLM 안전성은 모델 성능만의 문제가 아니라 권한, 실행, 검증이 연결된 루프 전체의 문제이므로, 운영 설계에서 loop와 harness를 함께 다뤄야 한다.