AX(AI 전환),Presentation,Resource,Whitepaper

• 챗봇과 에이전트를 가르는 기준은 무엇이고, 그 차이가 왜 통제 범위를 바꾸는가
• 위험 범주 열 개를 어떻게 제품 점검표로 쓸 수 있는 여덟 항목으로 바꾸는가
• Hermes Agent 는 그 여덟 항목 가운데 어디까지를 기능으로 갖추고 있는가
• 공식 문서가 수치까지 밝힌 것과 끝내 밝히지 않은 것은 각각 무엇인가
• 도입을 결정하기 전에 조직이 반드시 답해 두어야 할 조건은 무엇인가

아래 버튼에서 전체 29장 PDF를 받으실 수 있습니다. 사내 도입 검토 회의 자료나 보안 검토 요청서의 첨부로 그대로 쓰셔도 됩니다.

두 도구를 가르는 것은 대화창 모양도, 뒤에 붙은 모델의 크기도 아닙니다. 실행 방식입니다. 챗봇은 질문 하나를 받아 답 하나를 돌려주고 멈추며, 다음에 무엇을 할지 정하는 주체가 언제나 사람입니다. 남는 것도 대화창에 표시된 텍스트뿐입니다.

에이전트는 목표를 받으면 어떤 도구를 부를지, 어떤 파일을 열지, 언제 멈출지를 스스로 판단해 여러 단계를 이어 갑니다. 그래서 남는 것이 다릅니다. 파일 변경, 외부 호출, 메시지 발송처럼 시스템에 상태가 남습니다. 되돌리는 비용이 갈리는 지점이 여기입니다.

두 도구의 경계를 먼저 정리하고 싶으시다면 AI 에이전트란 무엇인가 와 AI 에이전트와 챗봇의 차이 를 함께 보시면 정의와 구조가 잡힙니다.

▲ 되돌리기 어려운 동작의 폭이 통제 범위를 결정 (발표자료 4쪽)

그러므로 AI 에이전트 도입 점검에서 가장 먼저 적을 것은 제품 이름이나 모델 사양이 아니라 그 에이전트에 실제로 위임한 동작의 목록입니다. 같은 모델을 얹더라도 사내 결재 시스템에 쓰기 권한을 받은 에이전트와 문서를 읽기만 하는 에이전트는 요구되는 통제가 서로 다릅니다.

OWASP Gen AI Security Project 는 2025년 12월 9일 에이전트형 애플리케이션만 따로 떼어 정리한 위험 목록을 공개했습니다. 특정 제품의 기능과 무관하게 관찰된 위험을 모은 결과이므로 어느 제품을 검토하든 그대로 댈 수 있습니다.

다만 범주는 위험의 이름이지 제품이 갖춰야 할 기능의 이름이 아닙니다. 그래서 열 개를 누가 실행을 시작하나 · 무엇을 반복해 실행하나 · 무엇을 만지나 · 어디로 나가나 · 누가 확인하나 다섯 단계로 다시 묶고, 단계마다 위험을 줄이는 장치를 뽑았습니다.

OWASP 가 함께 제시하는 완화 방향도 읽어 둘 만합니다. 생성된 코드의 사람 검토, 격리된 실행 환경, 설정 입력 검증, 오케스트레이션 호스트의 외부 연결 제한 네 가지인데, 넷 모두 무엇이 자동으로 실행되는지를 조직이 이미 알고 있어야 성립한다는 공통 전제를 갖습니다.

▲ 범주는 위험의 이름, 점검표에 필요한 것은 기능의 이름 (발표자료 7쪽)

열 개를 모두 외울 필요는 없습니다. 관통하는 질문이 둘로 줄어들기 때문입니다 — 이 실행을 누가 승인했나, 그리고 그 결과를 누가 확인하나. 앞의 질문에 답이 없을 때 목표 탈취와 메모리 오염이 커지고, 뒤의 질문에 답이 없을 때 도구 오남용과 연쇄 장애가 커집니다.

여기서 자주 나오는 반론을 미리 짚겠습니다. 이미 갖춰 둔 보안 투자로 충분하지 않으냐는 질문입니다. 네트워크 계층의 접근 통제나 코드 취약점 검사는 규격에 어긋난 요청과 알려진 결함 패턴을 걸러 내는 데 목적이 있습니다. 그런데 에이전트가 정상적인 형식으로 주고받는 요청 안에서 목표가 뒤바뀌거나 저장해 둔 맥락이 오염되는 변화는 애초에 그 검사 대상이 아닙니다. 그래서 오염된 문서 한 건이 기억에 섞여 다음 실행의 판단을 바꾸어도 네트워크 계층과 코드 계층에는 흔적이 남지 않습니다.

이 대응을 일대일로 읽지 않는 편이 좋습니다. 한 범주가 여러 항목으로 흩어지기도 하고, 한 항목이 여러 범주를 함께 받기도 합니다.

그렇게 남은 것이 절차 기억 · 채널 통합 · 무인 실행 · 실행 격리 · 데이터 처리 위치 공개 · 권한 분리 · 위험 명령 승인 · 실행 결과 검증 여덟 가지입니다. 반복 업무를 굴리는 데 필요한 부품과 위험을 줄이는 데 쓰이는 장치를 하나의 목록으로 합친 결과입니다.

여덟 항목은 특정 제품의 기능 목록을 옮겨 온 것이 아니라 열 개 범주에서 역으로 추출한 요구입니다. 시작 지점에 걸리는 목표 탈취·신뢰 착취·불량 에이전트는 누가 어떤 조건에서 실행을 시작하는가로 묶이고, 그 묶음이 곧 채널 통합과 권한 분리라는 기능의 이름이 됩니다.

▲ 8가지 이름을 끝까지 고정 (발표자료 8쪽)

이 여덟 개 이름은 검토가 끝날 때까지 바꾸지 않고 그대로 씁니다. 장마다 다른 말로 바꿔 부르면 같은 요구를 두 번 검토하거나 반대로 통째로 빠뜨리기 쉽기 때문입니다.

Hermes Agent 는 Nous Research 가 공개한 오픈소스 에이전트 런타임입니다. 설치 전제는 Python 3.11 · Node.js · ripgrep 셋뿐이고, 공식 저장소는 5달러짜리 가상 사설 서버부터 GPU 클러스터와 서버리스 인프라까지 실행 범위로 밝히고 있습니다.

대조 결과 일곱 항목은 공식 문서가 기능으로 명시합니다. 여덟 번째인 실행 결과 검증만 보안 문서가 나열한 여덟 계층 어디에도, 기능 개요 문서 어디에도 나오지 않습니다. 근거로 삼을 공식 기술이 없습니다.

항목별 근거는 이렇게 갈립니다. 절차 기억은 실행을 마친 뒤 도는 자기개선 검토가 스킬 문서를 스스로 남기는 데서 나오고, 채널 통합과 무인 실행과 실행 격리는 공식 보안 문서가 기능으로 기술하는 기본 동작이며, 권한 분리와 위험 명령 승인은 여덟 계층 안에 각각 자리를 갖습니다.

▲ 8번째 실행 결과 검증만 공식 문서 어디에도 없음 (발표자료 12쪽)

이 표가 말하는 것은 공식 문서에 기능으로 나와 있다는 사실까지입니다. 그 기능이 실제 운영에서 얼마나 견고하게 도는지는 조직의 환경과 작업량에 따라 달라집니다. 다른 제품을 함께 검토 중이라면 항목명을 그대로 둔 채 제공 여부만 바꿔 적는 방식으로 같은 표를 다시 쓰실 수 있습니다.

채널 통합의 짝짓기 코드는 혼동하기 쉬운 글자를 뺀 32자 알파벳에서 뽑은 8글자이고, 유효 시간 1시간, 요청 간격 10분, 대기 코드 3개, 인증 5회 실패 시 1시간 잠금입니다. 값 하나하나보다 중요한 것은 세 가지가 함께 걸려 있다는 점입니다. 코드 공간이 아무리 넓어도 그것만으로는 코드를 계속 새로 받아 가며 시도하는 방식을 막지 못하고, 요청 간격과 실패 잠금이 함께 있을 때 비로소 무차별 대입을 막는 구성이 완성됩니다.

▲ 3가지 제한이 함께 걸릴 때 무차별 대입 차단 (발표자료 16쪽)

사내 규정이 일회용 인증 코드의 유효 시간을 30분 이내로 묶어 두었다면 1시간이라는 값은 규정과 어긋나므로, 예외 승인을 받을지 설정을 조정할지 먼저 결정해야 합니다. 반면 최소 CPU 코어 수와 메모리 용량 같은 정량 사양은 명시가 없습니다. 서버 사양을 근거로 예산을 세우려는 담당자라면 시험 설치를 거쳐 조직이 직접 측정해야 합니다.

채널이 요청을 받는 입구라면, 그 요청이 사람의 추가 승인 없이 끝까지 도는 것은 별개의 조건입니다. 무인 실행을 업무에 쓰려면 프로세스 관리자와 재시작 정책과 로그 보존 기간을 조직이 먼저 정해야 합니다.

공식 FAQ 는 WSL 의 systemd 지원이 불안정하다고 명시합니다. 표준 업무 환경이 Windows 이고 개발용으로 WSL 을 쓰는 조직이라면 밤새 돌 예정이던 작업이 아침에 멈춰 있는 상황을 만나게 되는데, 그때 원인이 에이전트인지 WSL 인지 전원 설정인지 가려내는 데 적지 않은 시간이 듭니다. 상시 구동만 별도 리눅스 호스트로 옮기는 구성을 점검해야 합니다.

사람 없이 끝난 작업은 결과를 나중에 확인할 수 있어야 업무에 쓸 수 있습니다. 토큰 회계와 추정 비용과 세션 길이와 사용 요약 네 가지는 이미 제공되므로 밤사이 무슨 일이 있었는지 전혀 모른 채 아침을 맞는 상황은 아닙니다. 다만 이를 하나로 묶는 통합 텔레메트리 계층이 없어 하나의 실행을 처음부터 끝까지 이어서 되짚는 화면이 없습니다.

에이전트를 드나드는 데이터는 한 갈래로만 흐르지 않습니다. 코어를 가운데 두고 보면 서로 독립된 네 경로가 각자 다른 곳으로 데이터를 보내거나 받습니다. 검색·추출 백엔드, 모델 제공자, 사용 정보 계측, 메시징 게이트웨이입니다.

▲ 코어를 사내 서버에 올려도 4개 경로의 목적지는 경로별 설정으로 별도 결정 (발표자료 22쪽)

특히 주의할 것은 설정을 비워 두면 API 키가 백엔드를 결정한다는 점입니다. 백엔드 값을 지정하지 않으면 사용할 수 있는 키를 기준으로 자동 선택되므로, 다른 업무에 쓰려고 넣어 둔 키 때문에 웹 검색 트래픽이 예상하지 못한 대상으로 나갈 수 있습니다.

모델 제공자는 네이티브 Anthropic 연동, OpenRouter, Nous Portal 세 경로를 공식 문서가 함께 소개합니다. 세 경로를 가르는 기준은 성능 순위보다 계약 형태에 가깝습니다. 한 가지 덧붙이면, 캐시 키에 모델 식별자가 들어 있어 다른 모델로 넘어가는 순간 그전까지 쌓아 둔 캐시가 맞지 않게 되고 전환 직후 첫 요청은 대화 전체를 다시 읽는 비용을 치릅니다. 모델 전환을 무료 옵션 변경으로 잡으면 안 됩니다.

보안 문서는 제품의 안전장치를 여덟 계층으로 나눠 설명합니다. 컨테이너 격리와 파일 쓰기 안전장치는 별도 구성 없이 제품에 들어 있어 조직이 아무것도 하지 않았을 때 확보하는 기준선이 되고, 권한 분리와 위험 명령 승인은 실행 주체를 통제합니다.

▲ 8개 계층은 권한과 범위만 통제 (발표자료 24쪽)

여덟 계층에는 공통점이 하나 있습니다. 모두 누가, 무엇을, 어디까지 할 수 있는가를 통제하고, 작동 시점도 실행 이전이거나 실행 도중입니다. 실행이 끝난 뒤 그 결과가 맞았는지 확인하는 계층은 하나도 없습니다. 위험 명령 승인 게이트가 걸러 내는 대상은 삭제나 전송처럼 정해진 형태에 들어맞는 명령인 반면, 보고서를 잘못 요약하거나 숫자를 잘못 집계한 산출물은 명령 자체가 안전하므로 이 게이트에 아예 걸리지 않습니다.

이 공백을 제품의 결함으로 읽을 이유는 없습니다. 여덟 계층은 처음부터 권한과 범위를 설계 범위로 삼았고 그 안에서 각 계층이 맡은 역할을 합니다. 다만 경계를 모르는 조직은 제품이 결과까지 책임진다고 가정한 채 검토를 끝내고, 검증 절차를 아무도 맡지 않은 상태로 운영을 시작하게 됩니다.

승인 게이트에도 같은 성격의 빈틈이 있습니다. 승인 화면에 어떤 항목을 요약하고 어떤 근거를 붙일지를 대개 에이전트가 정하기 때문입니다. 승인자는 그 요약만 보고 판단하므로, 요약에서 빠진 정보는 승인 절차에 아예 없는 것과 같습니다.

첫째, 사람 확인 없이 맡겨도 되는 범위를 정하고 그 범위를 설정으로 실제 좁힐 수 있는지 시험 환경에서 확인해야 합니다. 정형화된 조회나 요약 업무라면 범위를 넓게 두어도 위험이 작지만, 외부로 나가는 메시지 발송이나 시스템 설정 변경이 섞인 업무라면 범위를 좁히고 승인 단계를 촘촘히 거치게 하는 편이 안전합니다.

둘째, 승인 요청을 검토할 담당자와 부재 시 대리자와 판단 기준을 지정해야 합니다. 승인 절차가 시스템에 있다는 사실과 그 절차를 맡을 사람을 조직이 정해 두었다는 사실은 서로 다른 이야기이며, 앞의 것은 제품이 갖추고 있고 뒤의 것은 도입하는 쪽의 몫입니다.

▲ 3가지 조건 모두 기능 유무가 아닌 조직의 값 지정 (발표자료 27쪽)

셋째, 검색·추출 백엔드가 어느 서버로 요청을 보내는지 우리 환경에서 직접 확인하고, 개발 정책 한 줄과 배포판 현황 한 줄을 나누어 기재해야 합니다. 둘을 뭉쳐 수집 없음이라고 단정하면 나중에 감사나 실사에서 그 단정을 뒷받침할 근거를 대기 어렵습니다.

통제가 실제로 걸리는지는 운영 중에 확인하기 어렵습니다. 격리된 복제 환경에 과거 실행 기록을 다시 흘려 보내면 차단이 실제로 작동하는지와 복구 절차가 수행 가능한지를 함께 확인하실 수 있습니다.

• 여덟 항목 가운데 일곱은 공식 문서가 기능으로 명시하고, 실행 결과 검증 하나만 근거가 없습니다.
• 설치 전제는 Python 3.11 · Node.js · ripgrep 셋뿐이지만, 정량 사양은 명시가 없어 시험 설치로 측정해야 합니다.
• 짝짓기 코드는 8글자 · 유효 1시간 · 요청 간격 10분 · 대기 3개 · 실패 5회 잠금으로 수치까지 공개돼 있습니다.
• 여덟 계층은 전부 실행 이전이거나 도중에만 작동하므로 산출물 정확성은 설계 범위 밖입니다.
• AI 에이전트 도입 점검의 실제 작업 범위는 무인 실행 범위, 승인 담당자 지정, 데이터 경로 확인, 검증 절차 설계 네 줄입니다.

AI 에이전트 도입 점검 항목은 몇 가지입니까

여덟 가지입니다. OWASP 위험 10개 범주를 실행 단계 다섯으로 묶어 뽑았습니다. 절차 기억, 채널 통합, 무인 실행, 실행 격리, 데이터 처리 위치 공개, 권한 분리, 위험 명령 승인, 실행 결과 검증입니다. 특정 제품과 무관한 잣대이므로 다른 후보 제품에도 그대로 대볼 수 있습니다.

Hermes Agent 는 여덟 항목 가운데 몇 개를 제공합니까

일곱은 공식 문서가 기능으로 명시하고, 실행 결과 검증 하나는 근거가 없습니다. 보안 문서가 나열한 여덟 계층과 기능 개요 문서 어디에도 실행이 끝난 뒤 결과가 맞았는지 확인하는 계층이 없습니다. 검증의 기준과 담당은 도입하는 조직이 처음부터 설계해야 합니다.

여덟 계층이 있는데 왜 실행 결과 검증이 따로 필요합니까

여덟 계층은 실행 이전과 도중의 권한·범위만 통제하고 결과의 정확성은 다루지 않기 때문입니다. 보고서를 잘못 요약하거나 숫자를 잘못 집계한 산출물은 명령 자체가 안전하므로 위험 명령 승인 게이트에 걸리지 않습니다. 명령이 규칙을 지켜 돌았는지와 그 결과가 옳은지는 서로 다른 질문입니다.

무인 실행은 설치만으로 바로 쓸 수 있습니까

아닙니다. 프로세스 관리자와 재시작 정책과 로그 보존 기간을 조직이 먼저 정해야 합니다. 공식 FAQ 는 WSL 의 systemd 지원이 불안정하다고 명시하므로, 표준 환경이 Windows 인 조직은 상시 구동을 별도 리눅스 호스트로 옮기고 도입 판단 전에 하룻밤 구동 시험으로 확인하는 절차를 권합니다.

Hermes Agent 를 설치하려면 무엇이 필요합니까

공식 문서가 밝힌 전제는 Python 3.11, Node.js, ripgrep 셋뿐입니다. 대부분의 사내 리눅스 서버나 개발 장비는 추가 구매 없이 이 조건을 채웁니다. 반면 최소 CPU 코어 수와 메모리 용량 같은 정량 사양은 명시가 없어 실제 작업량에 맞는 사양은 시험 설치로 직접 가늠해야 합니다.

• AI 에이전트 필수 기능 여덟 가지, 도입 전 점검 기준
• Agentic AI(에이전틱 AI)란 무엇인가
• 멀티 에이전트 시스템이란
• LLM 기반 AIOPS 도입 기준
• 생성형 AI 진화 4단계
• 레거시 시스템과 MCP 연결 로드맵
• MSAP.ai 제품문의
• AI Discovery Workshop 신청
• OWASP Gen AI Security Project
• Hermes Agent 공식 저장소
• Agent Skills 공개 표준