Hermes Agent는 CLI뿐 아니라 여러 메시징 채널, 원격 실행 환경, 스케줄링, MCP 도구를 연결할 수 있는 자율형 에이전트입니다. 이런 구조는 “매일 운영 현황을 정리해 전달한다”, “새 요청을 분류해 검토 대기열을 만든다” 같은 장기 업무에 적합해 보입니다.
그러나 장기 실행은 단순히 에이전트를 계속 켜 두는 문제가 아닙니다. 업무 시간 밖에도 실행되는 작업, 다른 시스템의 자격 증명, 외부에서 들어오는 메시지, 승인 없이 실행될 수 있는 명령이 한데 모이면 운영 책임의 경계가 쉽게 흐려집니다.
장기 실행 과제는 세 종류로 나눕니다
처음부터 모든 기능을 묶기보다, 위험도와 책임 방식이 다른 과제를 구분합니다.
| 유형 | 예시 | 기본 원칙 |
|---|---|---|
| 정기 정보 제공 | 일일 이슈 요약, 마감 예정 목록 | 읽기 전용 데이터, 발송 대상 확인 |
| 검토 준비 | 요청 분류, 자료 누락 알림, 초안 생성 | 사람이 최종 확인, 업무 건에 결과 기록 |
| 실행 연계 | 티켓 등록, 배포 요청, 권한 변경 신청 | 좁은 허용 범위, 명시적 승인, 되돌릴 수 있는 작업 우선 |
첫 검증은 정기 정보 제공 또는 검토 준비에서 시작하는 것이 좋습니다. 실행 연계는 업무 흐름과 통제 기준이 충분히 정리된 뒤에 별도로 검토해야 합니다.
승인 방식은 대화 편의가 아니라 위험도에 맞춥니다
Hermes Agent 공식 문서는 위험한 명령에 대한 승인 모드와 컨테이너 격리, 메시지 사용자 인증, 파일 쓰기 보호, MCP 자격 증명 필터링 등을 보안 계층으로 설명합니다. 기본 승인 모드가 있다고 해서 모든 작업이 자동으로 안전해지는 것은 아닙니다.
운영자는 다음을 명확히 정의해야 합니다.
- 어떤 명령·도구·MCP 연결이 승인을 요구하는가
- 예약 작업이 승인 대기 상태에 빠지면 중단할지, 담당자에게 통지할지
- 승인자가 부재한 시간에는 어떤 작업까지 허용할지
- 비가역 변경, 외부 발송, 권한 변경을 어떤 별도 절차로 다룰지
“위험한 명령만 승인한다”는 규칙은 출발점일 뿐입니다. 실제 업무 위험도는 명령 자체보다 대상 시스템, 데이터, 실행 시점, 결과의 되돌림 가능성에 의해 결정됩니다.
도구와 자격 증명은 업무별로 분리합니다
하나의 에이전트가 모든 시스템에 접속할 필요는 없습니다. 예를 들어 운영 현황 요약용 에이전트에는 로그 조회 권한만, 배포 검토용 에이전트에는 읽기 전용 배포 정보만 부여할 수 있습니다.
분리 기준은 다음과 같습니다.
- 업무별 계정: 개인 계정이나 광범위한 관리자 권한을 재사용하지 않습니다.
- 최소 권한: 조회, 초안, 등록, 실행 권한을 분리합니다.
- 실행 환경 격리: 신뢰하기 어려운 입력을 다루는 에이전트는 별도 컨테이너·작업 공간에서 실행합니다.
- 자격 증명 필터링: 연결하지 않은 시스템의 환경 변수나 토큰이 도구에 전달되지 않게 합니다.
- 만료와 회수: 프로젝트 종료·역할 변경 때 권한을 회수할 수 있어야 합니다.
이 구조는 보안을 위한 추가 절차이면서, 문제가 생겼을 때 영향 범위를 좁히고 원인을 추적하기 위한 운영 기반이기도 합니다.
스케줄 작업에는 성공·실패 외의 상태가 필요합니다
매일 아침 보고를 보내는 자동화는 성공 또는 실패만 기록하면 충분해 보입니다. 하지만 AX 운영에서는 다음 상태가 추가로 필요합니다.
- 데이터가 늦어 보고가 불완전한 상태
- 승인 대기로 실행이 중단된 상태
- 기준 문서가 변경돼 재검토가 필요한 상태
- 전달은 됐지만 담당자 확인이 아직 없는 상태
이 상태들은 메신저 대화 로그가 아니라 업무 대시보드, 티켓, DX 플랫폼의 이력으로 남겨야 합니다. 그래야 담당자가 바뀌어도 자동화의 현재 상태와 다음 조치를 알 수 있습니다.
보안 점검은 배포 전·변경 후에 반복합니다
에이전트에 새 채널, 새 도구, 새 스킬을 붙이는 일은 권한 모델을 바꾸는 일입니다. 그래서 다음 시점에는 같은 점검표를 다시 적용해야 합니다.
- 새로운 메시징 채널을 연결할 때
- MCP 서버 또는 외부 API를 추가할 때
- 스케줄 작업의 실행 범위를 넓힐 때
- 모델·자격 증명·실행 환경을 바꿀 때
- 기존 업무에서 다른 부서로 확장할 때
점검 결과는 “안전함”이라는 선언보다, 허용된 도구·승인 규칙·데이터 범위·복구 방법을 명확히 남기는 형태가 좋습니다.
가상의 업무 예시: 월요일 운영 보고 준비
월요일 운영 보고를 준비하는 가상 일정 작업을 예로 들겠습니다. 에이전트가 승인된 운영 지표를 읽어 미확인 장애와 마감 임박 건의 초안을 만듭니다. 데이터 수집이 늦으면 “성공”으로 발송하지 않고 불완전 상태로 담당자에게 알립니다. 담당자는 숫자와 대상 범위를 확인한 뒤에만 보고를 배포합니다. 일정 작업에 성공·실패만 두지 않고, 입력 지연·승인 대기·재검토 필요 상태를 두면 조용히 틀린 보고가 전달되는 위험을 줄일 수 있습니다.
| 상태 | 자동으로 할 일 | 사람의 결정 |
|---|---|---|
| 준비 완료 | 초안과 근거 링크 생성 | 배포 승인 |
| 입력 지연 | 발송 중지·담당자 알림 | 대체 자료 사용 여부 |
| 승인 대기 | 실행 보류 | 허용 범위 조정 |
| 실패 | 오류 이력 보존 | 재실행·복구 판단 |
처음에는 읽기 전용 정기 요약 하나만 골라 입력 출처, 실행 시간, 실패 시 중단 기준, 검토자를 정의하세요. 신뢰도는 실행 횟수보다 누락 입력·만료 권한·승인 대기·전달 실패를 성공과 구분해 드러내는 방식에서 확인됩니다.
장기 실행의 핵심은 재시작 가능성입니다
정기 작업은 언젠가 중간에 멈춥니다. 네트워크가 끊기거나, 입력 시스템이 늦거나, 자격 증명이 만료될 수 있습니다. 따라서 한 번에 끝나는 명령처럼 설계하지 말고 실행마다 입력 기준 시각, 처리한 업무 식별자, 결과 위치, 다음 재시도 시점을 남겨야 합니다. 재시작한 에이전트가 앞선 결과를 모른 채 같은 알림을 다시 보내거나 이미 처리한 작업을 수정하지 않도록, 각 행동은 식별자와 상태를 확인한 뒤 수행합니다.
가상의 일일 운영 요약에서 오전 데이터 수집이 지연됐다고 가정해 보겠습니다. 에이전트는 전날 수치를 새 보고처럼 보내지 않고 ‘입력 지연’ 상태로 초안을 보류합니다. 운영 담당자는 누락된 출처와 영향 범위를 확인해 대체 자료를 쓸지, 발송을 미룰지 결정합니다. 복구 뒤에는 새 입력 기준 시각을 기록한 한 건만 발송하고, 지연과 수동 판단을 이력에 남깁니다. 자동 작업이 할 일은 실패를 숨기는 것이 아니라, 사람이 판단할 수 있게 멈추고 근거를 모으는 것입니다.
Hermes Agent의 실행·격리·승인 기능은 공식 문서의 현재 설명을 확인해 검토할 수 있습니다. 실제 환경에서는 최소 권한, 비밀정보 분리, 만료·철회 절차, 작업별 승인 기준을 별도로 시험한 뒤에만 범위를 넓혀야 합니다.
장기 작업의 장애 대응은 재실행 버튼 하나로 정의되지 않습니다. 운영자는 마지막으로 성공한 입력 시각과 이미 전달된 결과를 확인하고, 같은 보고가 중복 전달되지 않게 처리 식별자를 대조합니다. 보안 책임자는 작업 중 바뀐 권한이나 만료된 자격 증명을 확인하며, 업무 책임자는 누락된 데이터로 발송할지 기다릴지 결정합니다. 이 판단을 남기지 않으면 자율 실행은 편리한 자동화가 아니라 설명할 수 없는 반복 작업이 됩니다.
작업 시작 시점의 조건을 실행 내내 신뢰하지 않습니다
몇 분 안에 끝나는 작업과 달리 장기 작업은 실행 중에 권한, 기준 문서, 입력 데이터가 바뀔 수 있습니다. 오전에 유효했던 토큰이 오후에 회수되거나, 보고서 초안을 만드는 사이 대상 기간이 마감될 수 있습니다. 따라서 시작 때 한 번 인증하고 끝까지 실행하는 방식보다, 중요한 도구 호출과 외부 발송 직전에 권한과 업무 상태를 다시 확인해야 합니다. 기준이 달라졌다면 실패로 밀어붙이지 않고 ‘재검토 필요’ 상태로 멈춥니다.
작업 정의에는 입력 기준 시각과 최대 실행 시간도 포함해야 합니다. 종료 시점 없이 계속 자료를 모으는 에이전트는 최신 정보를 더 얻는 대신 보고의 범위를 계속 바꿀 수 있습니다. 운영 책임자는 어느 시점의 데이터를 한 묶음으로 볼지, 늦게 도착한 입력을 다음 실행으로 넘길지, 시간이 초과되면 부분 결과를 폐기할지 결정합니다. 에이전트는 이 규칙에 따라 체크포인트를 남기고, 재시작 때 승인되지 않은 중간 산출물을 최종 결과로 승격하지 않습니다.
승인 대기는 자격 증명을 붙잡은 채 멈추는 상태가 아닙니다
실행 도중 사람의 승인이 필요해졌다면 에이전트가 열린 연결과 민감한 임시 파일을 유지한 채 무기한 기다려서는 안 됩니다. 승인 요청에는 실행하려는 행동, 대상, 예상 영향, 되돌림 방법, 만료 시각을 포함하고, 대기 상태로 전환할 때 불필요한 세션과 자격 증명을 정리합니다. 승인자가 늦게 응답하면 현재 데이터와 권한을 다시 확인한 뒤 새 실행으로 이어가야 합니다.
승인 요청의 문구도 결과를 과장하지 않아야 합니다. ‘안전한 변경을 승인해 달라’가 아니라 어떤 파일을 어디에 보내거나 어떤 티켓 상태를 바꾸려는지 구체적으로 보여줘야 합니다. 승인자는 업무 필요성과 대상 범위를, 보안 담당자는 권한과 외부 전송을, 운영자는 실패 시 복구 가능성을 각자 확인합니다. 세 역할이 항상 별도 사람일 필요는 없지만 어떤 책임으로 판단했는지는 기록에 남아야 합니다.
중단·격리·복구를 실제 일정 작업으로 연습합니다
장애 훈련은 에이전트 프로세스를 강제로 종료하는 데서 그치지 않습니다. 입력 수집 뒤 초안 생성 전에 멈춘 경우, 외부 전송은 성공했지만 결과 기록 전에 멈춘 경우, 승인 직후 자격 증명이 회수된 경우를 구분해 재실행합니다. 각 상황에서 처리 식별자와 외부 시스템의 실제 상태를 대조해 중복 행동을 막고, 자동 판단이 불가능하면 사람의 조정 대기열로 보냅니다.
복구 후에는 빠진 보고 한 건만 채우고 끝내지 않습니다. 운영자는 지연 시간과 수동 조정 내용을 기록하고, 개발 책임자는 체크포인트와 멱등 처리의 결함을 수정하며, 보안 책임자는 격리 범위가 다른 작업의 비밀정보까지 노출하지 않았는지 확인합니다. Hermes Agent가 제공한다고 설명하는 실행·승인·격리 기능은 이 운영 설계의 참고 수단이며, 실제 환경에서의 적합성과 안전성은 공식 문서, 현재 버전, 조직의 정책에 따라 별도로 검증해야 합니다.
얼마나 오래 실행할지가 아니라 어디서 멈춰야 하는가
운영 책임자는 정기 작업의 누락을 줄이고 싶고, 보안 담당자는 장기 자격 증명의 노출을 걱정합니다. 이 갈등은 에이전트에 더 넓은 권한을 주는 방식으로 풀지 않습니다. 읽기 전용 수집, 초안 생성, 승인 대기, 제한된 실행을 분리하고 각 단계에 만료와 철회 기준을 둡니다. 실행 시간이 길어질수록 작업 시작 당시의 권한과 현재 권한이 다른 경우도 점검해야 합니다. 권한이 바뀌면 안전하게 중지하고 사람이 재승인하는 편이 잘못된 자동 실행보다 낫습니다.