Resource,Whitepaper

챗봇과 에이전트를 가르는 선은 화면이 아니라 실행 방식에 있습니다. 챗봇은 답 하나를 내놓고 멈추지만, 에이전트는 목표를 받으면 사람 개입 없이 다음 행동을 스스로 골라 이어갑니다. 이 자율 실행이 파일 쓰기·외부 메시지 발송처럼 되돌리기 어려운 동작을 만들어내면서, OWASP Gen AI Security Project 는 에이전트형 애플리케이션의 위험을 열 개 범주로 정리했습니다. 이 범주를 실행 단계로 다시 묶으면 절차 기억·채널 통합·무인 실행·실행 격리·데이터 처리 위치 공개·권한 분리·위험 명령 승인·실행 결과 검증이라는 여덟 개 기능 요구로 좁혀집니다. 반복 업무 하나를 에이전트에 맡기려면 절차 기억·채널·무인 실행·검증이라는 네 부품이 동시에 갖춰져야 하고, 이 네 부품이 여덟 항목의 뼈대이기도 합니다.

Hermes Agent 공식 문서를 AI 에이전트 필수 기능 여덟 항목에 대조하면 일곱 개는 기능으로 명시되어 있습니다. 절차 기억은 스킬 체계가 맡습니다. 에이전트가 작업 도중에도, 턴이 끝난 뒤 백그라운드 자기개선 리뷰에서도 스스로 절차를 문서로 남기는 구조입니다. 보안 문서는 안전장치를 여덟 개 층으로 설명하는데, 컨테이너 격리는 실행 격리의 근거이고 세션 간 격리와 사용자 인가는 권한 분리로, 위험 명령 승인은 그대로 같은 이름의 항목으로 이어집니다. 데이터 처리 위치 공개는 검색·추출 백엔드가 기본값 Firecrawl 외에 일곱 종 대안으로 교체 가능하다는 사실과, 모델 제공자가 네이티브 앤트로픽·오픈라우터·누스 포털 세 경로로 나뉜다는 사실에서 근거를 찾을 수 있습니다.

여덟 번째인 실행 결과 검증만 다릅니다. 사용자 인가부터 입력 정제까지 여덟 개 안전장치 층 어디에도, 실행이 끝난 뒤 그 결과가 실제로 맞는지 확인하는 절차는 없습니다. 승인 게이트는 삭제·전송처럼 되돌리기 어려운 명령이 실행되기 직전에 개입할 뿐, 명령 자체는 안전해도 내용이 틀린 산출물까지는 다루지 않습니다. 이 공백은 결함이 아니라 설계 범위의 경계입니다. 일곱 계층이 누가 시작하고 무엇을 만질 수 있는지를 통제하도록 설계된 반면, 결과가 옳은지 확인하는 일은 애초에 이 통제 체계가 맡기로 한 문제가 아니었습니다.

공개된 사례를 살펴보면 규모의 쏠림도 함께 보입니다. 확인되는 활동은 저장소 이슈 논의 같은 개인 개발자·소규모 단위에 그치고, 조직명이 붙은 전사 규모 도입 사례는 조사 범위 안에서 확인되지 않았습니다. “5달러짜리 VPS부터 GPU 클러스터까지 돌아간다”는 문장은 제품이 감당하도록 설계된 지원 범위 선언이지, 그 규모에서 실제로 운영 중인 고객이 있다는 사례 보고가 아닙니다. 두 문장을 하나로 이어 읽으면 도입 판단의 근거가 실제보다 부풀려집니다.

이 구도가 도입을 검토하는 조직에 남기는 몫은 분명합니다. 일곱 항목은 설치와 함께 따라오지만, 실행 결과 검증만은 누가·언제·무엇을 기준으로 확인할지를 조직이 직접 설계해야 합니다. 엔터프라이즈 AI 도입을 준비하는 조직이라면, 백서가 정리한 확인 물음 가운데 지금 바로 대입해 볼 수 있는 항목부터 짚어보는 편이 안전합니다.

• 지금 검토 중인 반복 업무 하나를 절차 기억·채널·무인 실행·검증 네 칸에 대입해 빈 칸이 남는지 점검해야 합니다.
• 무인 실행을 맡겨도 되는 범위를 조직 기준으로 좁힐 수 있는지 확인하고, 그 범위를 설정에 반영할지 결정해야 합니다.
• 위험 명령 승인 알림이 왔을 때 누가 판단하고, 그 사람이 부재중이면 누가 대신할지 담당자를 준비해야 합니다.
• 검색·추출 백엔드가 어떤 서버로 요청을 보내는지, 계측 조각이 조직의 데이터 처리 정책과 맞는지 함께 점검해야 합니다.

이 물음에 답한 뒤에도 남는 질문은 규모입니다. 우리와 비슷한 규모의 공개 운영 사례가 없다면, 그 첫 사례가 되어도 괜찮은지를 스스로 판단해야 합니다. 지원 범위 선언과 실제 운영 사례를 구분해서 읽는 습관이 AI 에이전트 필수 기능 점검의 마지막 단계입니다. 여덟 항목을 근거와 함께 정리한 MSAP.ai 백서 전문에서 이 대응표와 확인 질문을 자세히 다룹니다.