Windows 환경을 기준으로 작성했습니다.AI가 초안을 도운 부분도 사람이 다시 확인합니다.

작성일·최종 확인일: 2026-08-29

Hermes Agent와 일반 AI 채팅을 비교할 때 모델의 말솜씨부터 따지기 쉽습니다. 제가 업무 흐름을 설계할 때는 다른 부분을 먼저 봅니다. 답변만 돌려주는가, 아니면 내 PC의 허용된 도구를 호출해 파일을 읽고 명령을 실행하며 결과물을 남길 수 있는가입니다. 후자라면 편의가 커지는 만큼 검증과 권한 관리도 작업의 일부가 됩니다.

이 글은 일반 채팅으로 초안을 만들다가 로컬 에이전트 도입을 검토하는 Windows 사용자, 특히 혼자 문서와 콘텐츠 업무를 운영하는 사람을 위한 노트입니다. 특정 모델의 성능 순위를 매기거나 어느 제품이 항상 낫다고 주장하려는 글이 아닙니다. 기능과 명령은 바뀔 수 있으므로 Hermes 관련 내용은 2026-08-29에 공식 문서를 기준으로 다시 확인했습니다.

제가 구분하는 핵심: 조언과 실행

일반 AI 채팅에 “폴더의 파일명을 정리해 줘”라고 물으면 대개 방법, 코드, 명령 예시를 받을 수 있습니다. 사용자가 파일을 올리거나 내용을 붙여 넣은 범위 안에서 요약과 초안을 만들 수도 있습니다. 하지만 답변에 명령이 적혀 있다고 해서 내 PC에서 그 명령이 실행된 것은 아닙니다.

Hermes Agent 같은 로컬 도구형 에이전트는 설정된 도구를 통해 파일을 읽고, 코드를 수정하고, 테스트나 명령을 실행할 수 있습니다. messaging gateway를 연결하면 Telegram 같은 외부 입구에서 같은 에이전트에게 요청할 수도 있습니다. 여기서 “할 수 있다”와 “항상 허용해야 한다”를 분리해야 합니다. 파일 삭제와 외부 게시까지 열어 두는 것은 기능 확인이 아니라 권한 결정입니다.

문제 상황: 그럴듯한 완료 보고

채팅 답변은 문장 자체가 산출물일 때가 많습니다. 제목 후보나 설명문을 요청했다면 내용을 읽고 채택하면 됩니다. 실행형 작업은 다릅니다. “파일을 만들었습니다”라는 문장이 산출물이 아니라 실제 파일이 산출물입니다. 파일 위치, 내용, 대상 프로젝트가 맞는지 다시 읽지 않으면 완료 여부를 알 수 없습니다.

제가 에이전트 작업에서 가장 경계하는 표현은 근거 없이 단정적인 완료 보고입니다. 명령이 종료됐다는 로그만으로는 부족합니다. 생성된 파일을 열고, 테스트가 있다면 실제로 실행하고, 외부 상태를 바꿨다면 정확한 대상을 재조회해야 합니다. 도구 호출 결과와 업무 결과를 따로 확인하는 습관이 필요합니다.

기준 환경

  • Windows PC와 프로젝트별 작업 폴더
  • 일반 웹·앱 기반 AI 채팅
  • 로컬에 설치된 Hermes Agent와 필요한 도구
  • 상태 원본으로 쓰는 파일이나 저장소
  • 쓰기·삭제·외부 전송 전 사람 승인 절차

이 환경 목록은 제품 요구사항이 아니라 비교를 위한 기준입니다. Hermes는 여러 실행 환경과 인터페이스를 지원하므로 실제 지원 범위는 공식 문서에서 확인해야 합니다. Windows 설치 역시 기억에 의존해 명령을 옮기지 않고 공식 Installation 또는 Quickstart의 현재 안내를 따릅니다.

1단계: 같은 요청을 두 방식으로 적어 본다

예를 들어 문서 폴더에서 확장자별 파일 목록이 필요하다고 가정합니다. 일반 채팅에는 목록을 만드는 방법이나 스크립트를 요청할 수 있습니다.

예시 요청: Windows의 지정 폴더에서 파일을 확장자별로 집계하는
읽기 전용 Python 예제를 작성해 줘. 실제 경로 대신 sample/input을 사용해 줘.

이 결과는 코드 초안입니다. 실행 여부, 접근 권한, 실제 파일 구조는 사용자가 확인합니다. Hermes Agent에는 허용된 테스트 폴더를 직접 조회하도록 요청할 수 있습니다.

예시 요청: 승인된 sample/input 폴더를 읽기 전용으로 조회해
확장자별 개수를 보여 줘. 파일을 변경하지 말고, 사용한 대상과
검증 방법을 함께 보고해 줘.

두 문장은 모두 가상 예시이며 실행 사실이나 측정값을 담지 않습니다. 차이는 두 번째 요청이 실제 도구 사용과 검증을 포함할 수 있다는 점입니다. 그러므로 대상 경로와 금지 동작을 더 명확히 써야 합니다.

2단계: 원본을 누가 가지고 있는지 확인한다

채팅 창에 붙여 넣은 표를 요약한다면 그 표가 대화의 원본입니다. 로컬 에이전트가 현재 프로젝트 상태를 묻는 요청을 받는다면 CSV, 데이터베이스, Git 상태 등 다시 읽을 수 있는 원본이 필요합니다. 에이전트의 기억은 편리한 배경정보지만 자주 바뀌는 현재 상태를 대신하면 안 됩니다.

예를 들어 “이번 달 초안이 끝났는가”는 변하는 상태입니다. 장기 기억에 완료라고 남기는 대신 상태표를 업데이트하고 다음 요청에서 다시 조회합니다. 반면 “이 프로젝트는 외부 게시 전 승인을 받는다”는 비교적 안정적인 운영 원칙입니다. 원칙과 현재값을 한곳에 쌓지 않아야 수정할 위치가 분명합니다.

3단계: 권한을 작업 단위로 연다

일반 채팅의 위험은 주로 입력한 정보와 잘못된 조언을 사용자가 실행하는 데 있습니다. 로컬 에이전트에는 실제 파일과 프로그램에 접근하는 위험이 추가됩니다. 처음에는 읽기만 허용하고, 새 파일 생성, 기존 파일 수정, 삭제, 외부 전송을 차례로 분리합니다. “프로젝트를 도와줘”처럼 넓은 허용 대신 이번 요청에 필요한 동작만 엽니다.

프로필을 업무별로 나누면 설정, 메모리, 세션, 기술을 분리하는 데 유용합니다. 다만 공식 Hermes Profiles 문서가 설명하듯 프로필은 파일시스템 샌드박스가 아닙니다. 같은 운영체제 사용자 권한으로 실행되는 로컬 백엔드라면 다른 폴더에 접근할 가능성을 별도로 통제해야 합니다. SOUL에 “이 폴더만 사용”이라고 적는 것은 행동 지침이지 운영체제 수준의 접근 차단이 아닙니다.

4단계: 실행 전 계획과 실행 후 증거를 분리한다

제가 실행형 요청을 적을 때는 먼저 무엇을 읽고 무엇을 바꿀지 요약하게 합니다. 위험한 동작이 있으면 그 지점에서 승인을 받습니다. 실행 후에는 같은 계획 문장을 반복하는 대신 실제 확인 결과를 요구합니다. 예를 들면 파일 존재 여부, 변경된 줄, 테스트 명령의 실제 종료 상태, 재조회한 설정값입니다.

계획이 길고 멋진 것은 성공 기준이 아닙니다. 반대로 답변이 짧아도 대상과 검증이 분명하면 운영에 쓸 수 있습니다. “완료”라는 단어보다 어떤 원본을 다시 읽었는지가 중요합니다.

5단계: 반복할 절차는 기술이나 스크립트로 고정한다

대화만으로 같은 설명을 매번 반복하면 조건이 조금씩 달라집니다. 안정된 절차는 검증 가능한 스크립트, 프로젝트 문서, Hermes skill 같은 형태로 옮길 수 있습니다. 그 안에는 언제 쓰는지, 정확한 단계, 중단 조건, 검증 방법을 넣습니다. 특정 세션에서 우연히 통과한 명령을 일반 절차로 바로 승격하지 않고 다른 입력과 실패 사례를 확인합니다.

Hermes의 기술과 메모리는 역할이 다릅니다. 기술은 재사용 절차에 가깝고, 메모리는 장기적으로 다시 쓸 사실이나 사용자 선호를 담습니다. 오늘의 임시 작업 목록과 진행률은 둘 중 어디에도 억지로 넣지 않고 작업 관리 원본에 둡니다.

나쁜 접근과 흔한 실패

첫 번째는 일반 채팅이 써 준 명령을 검토 없이 관리자 권한으로 붙여 넣는 것입니다. 설명용 명령에는 내 환경의 경로, 버전, 권한이 반영되지 않았을 수 있습니다. 도움말을 확인하고 테스트 폴더에서 실행합니다. 두 번째는 에이전트가 도구를 가졌다는 이유로 넓은 권한을 영구 허용하는 것입니다. 편의상 열린 삭제와 전송 권한은 잘못된 대상 해석 때 바로 영향을 냅니다.

세 번째는 프로필이나 SOUL을 보안 장벽으로 오해하는 것입니다. 지침을 잘 나눠도 OS 권한이 그대로면 기술적 격리가 된 것이 아닙니다. 네 번째는 테스트를 작성했다는 답변을 테스트 통과로 읽는 것입니다. 테스트 파일의 존재, 실제 실행 명령, 결과를 각각 확인해야 합니다.

실용적인 비교 점검

  1. 같은 읽기 전용 과제를 일반 채팅에는 코드 작성으로, Hermes에는 테스트 폴더 조회로 요청합니다.
  2. 일반 채팅의 코드는 도움말과 코드 검토를 거쳐 별도 환경에서 실행합니다.
  3. Hermes 응답에서는 호출한 도구와 실제 대상을 확인합니다.
  4. 존재하지 않는 파일을 요청해 두 방식 모두 추측하지 않는지 봅니다.
  5. 쓰기 요청을 추가해 Hermes가 승인 경계에서 멈추는지 확인합니다.
  6. 결과 파일을 사람이 열어 원본과 대조합니다.

이 절차 역시 제 점검 기준이며 특정 제품 간 벤치마크 결과가 아닙니다. 모델, 도구, 설정이 달라지면 행동도 달라질 수 있습니다.

검증 체크리스트

  • 요청 결과가 답변인지 실제 외부 산출물인지 구분했는가
  • 실행형 요청에 대상, 허용 동작, 중단 조건을 적었는가
  • 에이전트가 현재 상태를 원본에서 다시 읽는가
  • 설명용 명령을 실행 사실로 오해하지 않았는가
  • 프로필과 파일시스템 격리를 구분했는가
  • 파일 생성 뒤 내용과 식별자를 다시 확인했는가
  • 테스트를 실제로 실행하고 결과를 확인했는가
  • 외부 공개, 삭제, 결제에는 사람 승인이 남아 있는가

보안·개인정보 주의

일반 채팅과 에이전트 어느 쪽에도 실제 비밀번호, API 키, 고객 식별정보를 예시로 넣지 않습니다. 에이전트 로그와 세션 기록도 민감정보가 남을 수 있는 저장물로 취급합니다. 도구 실행 화면을 공유할 때는 사용자명과 전체 경로, 저장소 주소, 환경변수 출력까지 확인합니다. 비밀값은 설정과 분리된 승인된 저장소에 두고 출력은 존재 여부만 보고하게 합니다.

공식 참고 링크와 다음 글

실행 권한을 열기 전에 AI 자동화 전에 정리할 항목을 먼저 적고, 기억과 현재 상태를 나누려면 SOUL·USER·MEMORY 구분 작업 노트를 이어서 확인합니다. 제가 내리는 결론은 단순합니다. 채팅은 조언을 검토하고, 에이전트는 조언과 함께 실제 변경도 검증해야 합니다.