채팅에 상주하며 '읽기만' 하는 AI 에이전트는 설계가 간단합니다. 까다로운 것은 캘린더 등록, 티켓 생성, Slack 게시, 외부 API 호출 등 부작용을 수반하는 도구를 실행할 수 있는 에이전트를 만들 때입니다. 본 기사에서는 상주 에이전트에게 도구 실행 권한을 부여할 때 정리해야 할 논점들을 구현 패턴과 함께 정리합니다.

왜 '읽기'와 '쓰기'로 설계가 달라지는가

읽기 전용 도구(검색, 요약, 정보 획득)는 LLM이 다소 잘못된 판단을 하더라도 실질적인 피해가 작고, 틀리면 다시 물어보면 되기 때문에 괜찮습니다. 하지만 쓰기 계열 도구(전송, 등록, 삭제, 결제)는 실행하는 순간 취소할 수 없는 부작용을 외부에 일으킵니다.

즉, 쓰기 계열 도구를 다루는 에이전트의 설계 과제는 모델의 정확도를 어떻게 높일지가 아니라, 모델이 틀려도 피해가 한정되도록 권한과 플로우를 어떻게 설계할지로 바뀝니다. 이 부분을 모호하게

이는 LLM의 로그(프롬프트-응답)와 별개로, 툴 실행 계층에서 독립적으로 기록되어야 합니다. LLM이 '실행했다'고 발언하더라도, 실제로 권한 검사를 거쳐 실행되었다는 보장이 없기 때문입니다.

요약

• 부작용을 동반하는 툴을 가진 에이전트는 모델의 정확도보다는 권한과 플로우 설계로 사고를 예방해야 합니다.
• LLM의 출력은 '의도'에 불과합니다. 인자(argument)의 유효성 검사 및 권한 강제는 툴 실행 계층(시스템 측)에서 수행해야 합니다.
• 위험도가 높은 작업은 '취소 가능 여부', '영향 범위가 본인을 초과하는지'로 분류하고, 필요한 작업에만 휴먼 인 더 루프(Human-in-the-Loop)를 거칩니다.
• 툴 실행 로그는 LLM 로그와 별개로, 실행 계층에서 독립적으로 기록해야 합니다.

Slack/Teams/Chatwork에 상주하며 정보 수집이나 연락을 대행하는 HACH 같은 에이전트도, 툴 실행 권한의 설계는 동일한 생각으로 구성하고 있습니다. 동종 에이전트를 설계하시는 분들께 참고가 되기를 바랍니다.

토론