AI가 '다 했습니다'라고 할 때 확인하는 법 — 업무를 맡기기 전에 정해둘 5가지

들어가며

고객 문의 30건을 배송·환불·계정으로 나누고 FAQ 초안까지 만들어달라고 맡겨 두었습니다. 다른 일을 보다가 돌아오니 "완료했습니다" 한 줄이 와 있습니다. 그런데 그 한 줄을 못 믿어서, 결국 30건을 처음부터 다시 열어봅니다.

AI 도구를 업무에 붙일 때 막히는 자리는 대개 여기입니다. 시키는 건 되는데, 맡긴 다음이 안 됩니다. 답이 뜰 때까지 화면만 보고 있고, 위험해 보이는 명령이 올라오면 승인하려고 자리를 못 뜨고, 시켜놓으면 뭘 하는지 안 보이고, 끝났다는데 결과가 어디에도 안 와 있습니다. 문제는 모델이 덜 똑똑해서가 아닙니다. 맡기고 확인하고 받는 과정이 비어 있어서입니다.

이 글에서는 AI 에이전트에 업무를 맡길 때 미리 정해둘 5가지를 정리했습니다. Hermes Agent의 최근 업데이트(v0.18~v0.19)를 예로 들지만, 다른 에이전트 도구를 쓰더라도 확인할 자리는 같습니다. "완료했습니다"를 증거로 바꾸는 완료 기준 쓰는 법과, 재시작 후에 다시 오는 결과와 오지 않는 결과의 차이도 함께 다룹니다.

맡긴 일은 늘 같은 다섯 자리에서 막힙니다

사람에게 일을 맡길 때를 떠올리면 순서가 분명합니다. 빨리 시작하고 → 위험한 건 결재를 받고 → 진행 상황을 보여주고 → 끝났으면 증거를 보여주고 → 결과를 전달합니다. AI에게 맡길 때도 같은 다섯 자리가 필요한데, 그동안은 이 자리가 곳곳이 비어 있었습니다.

아래 다섯 개 절이 이 표의 각 줄에 대응합니다. 순서대로 읽으시면 됩니다.

1. 시작 — 빨라진 것보다, 무슨 생각을 하는지 보이는 게 큽니다

Hermes v0.19 릴리즈 노트에는 첫 응답 지연이 줄었다는 수치가 적혀 있습니다. 콜드 스타트에서 첫 토큰이 뜨기까지 약 4.3초에서 약 0.9초로, 약 80% 단축입니다. CLI, 게이트웨이, TUI, 데스크톱, 예약 작업에 모두 적용됩니다.

이 수치는 범위를 정확히 알고 봐야 합니다.

📌 첫 응답 지연 80% 단축의 정확한 범위
이 값은 ① 콜드 스타트에서 첫 글자가 나오기까지의 지연만 가리킵니다. 작업 전체가 80% 빨라진다는 뜻이 아닙니다. ② 공식 릴리즈 노트에 적힌 공식 수치이며, 각자의 환경에서 잰 값이 아닙니다. 체감은 모델·네트워크·작업 종류에 따라 달라집니다.

숫자보다 체감이 큰 쪽은 따로 있습니다. 같은 업데이트에서 추론 과정이 기본값으로 실시간 스트리밍되도록 바뀌었습니다. 릴리즈 노트 표현대로 "30초 동안 스피너만 보고 있을 일이 없어진" 셈입니다. 커서만 깜빡이던 구간에 지금 무엇을 검토하고 있는지가 그대로 흐릅니다.

데스크톱 앱에서는 이 표시를 채팅 설정에서 켜고 끌 수 있습니다. 다만 메뉴 이름과 위치는 버전에 따라 달라질 수 있으니, 화면에서 찾을 때는 채팅 관련 설정부터 보시면 됩니다. 텔레그램이나 슬랙처럼 대화 기록이 그대로 쌓이는 채널에서는 켜두면 대화창이 지저분해지니, 이 표시는 앱이나 터미널에서 보는 쪽이 낫습니다.

실시간으로 보이는 것은 진행 상황이지, 내용이 맞다는 보장이 아닙니다. 생각 과정이 그럴듯하게 흘러가도 결과는 틀릴 수 있습니다. 정확성은 네 번째 절에서 따로 확인합니다.

2. 승인 — 자동으로 넘길 것과 내가 직접 볼 것을 나눕니다

에이전트에 터미널을 쥐여주면 곧바로 부딪히는 문제가 있습니다. 위험해 보이는 명령마다 승인 요청이 올라오는데, 그걸 눌러주려고 자리를 못 뜹니다. 반대로 전부 자동으로 열어두면 지우면 안 될 걸 지웁니다.

Hermes는 v0.19부터 Smart 승인이 기본값입니다. 위험 패턴에 걸린 명령을 보조 LLM이 한 건씩 판단해서 세 갈래로 나눕니다.

공식 보안 문서의 표현을 그대로 옮기면 이렇습니다. 낮은 위험의 명령은 "그 명령에 한해서만(for that command only)" 자동 승인되고, 명백히 위험한 명령은 자동 거부되며, 애매한 경우는 수동 승인 요청으로 올라옵니다.

"그 명령 하나만"이 핵심입니다. 한 번 통과했다고 다음에도 통과하지 않습니다. 판정이 명령 단위로 새로 붙습니다. 승인 창에서 always를 고르면 이야기가 달라집니다. 그때는 패턴이 설정 파일의 영구 허용 목록에 저장됩니다. 편하지만, 무엇을 영구 허용했는지 기억나지 않는 상태가 제일 위험합니다. always는 매일 반복되는 읽기 전용 명령에만 쓰시길 권합니다.

자동 모드와 무관하게 막히는 것

승인 모드를 off로 두거나 yolo를 켜도 뚫리지 않는 층이 두 개 있습니다.

• 고정 차단 목록: 파일 시스템 전체 삭제(rm -rf /), 포크 밤, 디스크 포맷 같은 명령은 어떤 설정에서도 거부됩니다. 이 바닥은 사용자가 내릴 수 없습니다.
• 사용자 지정 거부 규칙: 설정에 직접 적어둔 금지 패턴은 yolo나 off보다 먼저 걸립니다. 우리 팀이 절대 건드리면 안 되는 폴더가 있다면, 모드에 기대지 말고 여기에 적어두는 편이 확실합니다.

거부할 때는 이유를 함께 적습니다

승인 요청을 그냥 거부하면 에이전트는 왜 막혔는지 모른 채 비슷한 시도를 반복합니다. v0.19에는 /deny <이유>가 들어왔습니다. 거부 사유를 함께 넘기면 에이전트가 그걸 읽고 다른 경로로 방향을 바꿉니다. "지우지 말고 백업 폴더로 옮겨" 같은 한 줄이 재시도 몇 번을 줄여줍니다.

⚠ Smart 승인은 위험한 일을 대신 결정해 주는 기능이 아닙니다. 낮은 위험의 승인 피로를 덜고, 애매한 판단을 사람에게 돌려주는 1차 분류입니다. 메일·메시지 발송, 파일이나 데이터 삭제, 결제, 권한 변경처럼 되돌리기 어려운 일은 사람이 확인하고 마지막 버튼을 누릅니다. 이 자리를 비우면 자동화가 아니라 사고가 됩니다.

데스크톱 앱을 쓰신다면 상태 표시줄의 Approval Mode에서 Manual / Smart / Off를 바로 바꿀 수 있습니다. 프로필 단위로 반영되니, 실험용 프로필과 실제 업무 프로필을 다르게 두는 것도 방법입니다.

그래서 뭘 맡기고 뭘 남기나

승인 모드를 정하기 전에, 일의 성격부터 나누는 편이 빠릅니다.

처음 붙일 업무는 되돌릴 수 있는 일 가운데 하나만 고르시면 됩니다.

3. 관찰 — 진행이 보인다고 결과가 맞는 건 아닙니다

30건을 한 번에 처리하는 대신, 카테고리별로 나눠 맡기는 쪽이 빠릅니다. Hermes에서는 이걸 서브에이전트 위임이라고 부릅니다. 기본값으로 동시 3개까지 돌고(설정으로 조절), v0.18부터는 백그라운드 병렬 실행이 지원됩니다. 세 개가 각자 돌다가 다 끝나면 결과가 한 번에 모여 올라옵니다.

여기서 알아둘 성질이 하나 있습니다. 서브에이전트는 격리된 새 컨텍스트에서 시작합니다. 부모 대화에서 무슨 이야기를 했는지 모릅니다. 넘겨준 목표와 맥락만 알고 일합니다. 그래서 "아까 말한 그 기준대로"라고 쓰면 안 되고, 각 서브에이전트에게 필요한 기준을 그때그때 다 적어줘야 합니다. 이걸 모르고 맡기면 셋이 각각 다른 기준으로 분류해 옵니다.

v0.19에서 달라진 부분은 진행이 보인다는 점입니다. 위임이 시작되는 순간 작업별 실시간 로그 파일이 떨어집니다. 작업 하나당 로그 하나가 ~/.hermes/cache/delegation/live/ 에 append-only로 쌓이고, 터미널에서 tail -f 로 그대로 따라 볼 수 있습니다. 도구 호출, 결과, 스트리밍된 답변이 순서대로 들어옵니다.

/agents(또는 /tasks)를 치면 지금 돌고 있는 작업과 최근 끝난 작업이 부모 기준 트리로 보입니다. 비용도 함께 집계되고, 개별 에이전트를 멈추거나 잠시 세울 수 있습니다. 하나가 엉뚱한 방향으로 가고 있으면 그것만 멈추고 나머지는 그대로 두면 됩니다.

관찰이 바꿔주는 건 되돌리는 시점입니다. 예전에는 방향이 틀어져도 끝나봐야 알았고, 그때는 이미 30건이 다 잘못 분류돼 있었습니다. 지금은 두 번째 문의를 처리하는 중에 눈치챌 수 있습니다.

그렇다고 관찰이 검증을 대신하지는 않습니다. 로그가 깔끔하게 흘러도 분류 결과는 틀릴 수 있습니다. 진행을 보는 것과 결과가 맞는지 확인하는 것은 별개입니다. 그래서 다음 절이 필요합니다.

4. 완료 — "다 했습니다"를 증거로 바꾸는 다섯 줄

이 글에서 실무에 가장 오래 남을 부분입니다. 완료 기준을 시작 전에 적어두는 것입니다.

Hermes에는 /goal에 붙는 완료 계약(completion contract) 이 있습니다. v0.18에 들어온 기능입니다. 목표를 걸 때 "무엇이 참이어야 끝난 것인지"를 같이 적어두면, 판정 방식 자체가 바뀝니다. 공식 문서는 이렇게 적고 있습니다. 판정자는 검증 기준이 구체적인 증거로 충족될 때만 done을 내립니다. 명령 실행 결과, 파일 발췌, 테스트 출력 같은 것들입니다. "다 한 것 같다"는 통하지 않습니다.

계약에 들어가는 항목은 다섯 개이고, 모두 선택 사항입니다.

실제로 어떻게 적나

두 가지 방법이 있습니다. 문서가 권하는 쪽은 초안을 자동으로 잡게 하는 것입니다.

/goal draft 고객문의 30건을 배송·환불·계정으로 분류하고 카테고리별 FAQ 초안 만들기

직접 적을 때는 첫 줄에 목표를 쓰고, 아래에 접두사를 붙여 항목을 채웁니다.

/goal 고객문의 30건 분류 + 카테고리별 FAQ 초안 작성

verify: 분류 결과 합계 30건, 중복 0건, 누락 0건,
        FAQ 파일에 배송·환불·계정 세 섹션이 모두 존재
constraints: 원본 CSV 파일은 수정하지 않는다
boundaries: 입력 폴더와 출력 폴더 안에서만 작업한다
stop when: 분류 기준이 애매한 문의가 3건을 넘으면 멈추고 물어본다

첫 줄이 목표 문장이 되고, verify: · constraints: · boundaries: · stop when: 이 각 항목으로 들어갑니다. 본문 중간에 우연히 들어간 콜론은 무시됩니다. 표기는 버전에 따라 조금씩 달라질 수 있으니, 처음 쓸 때는 짧은 목표로 한 번 걸어보고 화면에 잡힌 항목을 확인하시면 됩니다.

verification을 쓸 때 세어볼 수 있게 씁니다

다섯 항목 중 결과를 실제로 바꾸는 건 verification입니다. "무엇으로 증명할 것인가"를 적는 자리인데, 여기에 기분을 적으면 기분으로 통과합니다.

요령은 하나입니다. 숫자를 세거나, 파일이 있는지 보거나, 문자열이 들어 있는지 확인할 수 있는 문장으로 적습니다. 마지막 줄처럼 "발송 0건"을 조건에 넣어두면, 초안까지만 만들고 멈추게 하는 장치가 됩니다.

stop_when도 같이 챙기시면 좋습니다. 애매한 게 몇 건을 넘으면 멈추고 물어보라고 적어두면, 어중간한 판단을 혼자 밀어붙이지 않습니다. 위 예시의 "3건"이 그 역할입니다.

⚠ 완료 계약은 AI가 스스로 완벽하게 자기 검증을 한다는 뜻이 아닙니다. 사람이 미리 적어둔 기준을 대조하는 것이라, 기준을 허술하게 쓰면 허술하게 통과합니다. 무엇으로 증명할지 정하는 일은 계속 사람 몫으로 남습니다.

이름이 비슷해서 헷갈리는 기능이 하나 더 있습니다. v0.18에는 코딩 검증 증거 원장도 함께 들어왔는데, 이건 코드 프로젝트의 테스트·린트·빌드 결과를 기록하는 별도 장치입니다. 위에서 다룬 /goal 완료 계약과는 다른 기능입니다.

5. 결과 전달 — 다시 오는 것과 오지 않는 것

마지막 자리는 결과 전달입니다. 평소에는 신경 쓸 일이 없다가, 한 번 겪으면 오래 기억에 남는 구간입니다. 결과는 다 만들어졌는데 슬랙이나 텔레그램으로 넘어가는 사이에 연결이 끊기거나 프로세스가 죽는 경우입니다. 예전에는 이럴 때 처음부터 다시 시켜야 했습니다.

v0.19에는 전달 원장(delivery-obligation ledger) 이 들어왔습니다. 최종 응답을 내부 데이터베이스에 기록해 두고, 전송 도중 게이트웨이가 죽으면 다음 부팅 때 그 응답을 다시 전달합니다. 결과가 조용히 사라지는 상황을 막아줍니다.

여기서 오해하기 쉬운 지점이 하나 있습니다.

공식 문서도 이 둘을 분명히 구분합니다. Hermes 프로세스가 재시작되면 실행 중이던 자식 작업은 재개되지 않고 unknown 상태가 됩니다. 반대로 재시작 전에 완료됐지만 전달되지 않은 결과는 복구되어 원래 세션의 확인 절차를 거쳐 다시 올라옵니다.

💡 끊기면 안 되는 일은 이 방식에 얹지 마세요.
복구되는 건 '완료됐는데 전달만 안 된 결과'뿐입니다. 30분짜리 배치 작업을 돌려놓고 중간에 재시작되면, 그 작업은 이어지지 않습니다. 이런 일은 예약 작업(cron) 이나 추적되는 백그라운드 프로세스로 돌리는 쪽이 맞습니다.

예약 작업 쪽은 실행 이력이 남습니다. Hermes는 각 실행 시도를 프로필별 데이터베이스에 기록하고 claimed → running → completed / failed / unknown 으로 추적합니다. 터미널에서 최근 실행 목록을 조회할 수 있고, 실패한 작업은 조용히 넘어가지 않고 알림이 옵니다.

다만 여기에도 선이 있습니다. 공식 문서에 자동 재실행 정책은 나와 있지 않습니다. 실패는 기록되고 알려주지만, 다시 돌릴지 판단하는 건 사람입니다. "실패하면 알아서 재시도하겠지"라고 가정하고 중요한 업무를 걸어두면 안 됩니다.

이 기능들은 언제 들어왔나

다섯 자리가 전부 같은 업데이트에서 채워진 게 아닙니다. 네 번째 완료 검증만 v0.18이고, 나머지는 v0.19입니다.

v0.19.0은 2026년 7월 20일, v0.18.0은 7월 1일 릴리즈입니다. 쓰고 계신 버전이 그보다 낮다면 위 기능들이 보이지 않습니다. 업데이트 방법과 최신 릴리즈는 공식 리포지토리에서 확인하시면 됩니다.

오늘 바로 해볼 것

한 번에 다 바꾸실 필요는 없습니다. 순서대로 세 가지만 해보시면 차이가 보입니다.

1. 되돌릴 수 있는 업무 하나를 고릅니다. 분류, 요약, 초안 작성 중에서 고르시면 됩니다. 발송·삭제·결제가 끼는 업무는 처음에 넣지 않습니다.
2. 완료 기준을 다섯 줄로 적습니다. 아래 틀을 그대로 쓰시면 됩니다. Hermes가 아니어도, 프롬프트 맨 앞에 붙여두는 것만으로 결과가 달라집니다.

목표:      (끝났을 때 참이어야 하는 상태 한 문장)
증명 방법:  (숫자를 세거나 파일 존재를 확인할 수 있는 조건)
바꾸지 말 것: (원본 파일, 기존 데이터 등)
작업 범위:   (손대도 되는 폴더·도구)
멈출 조건:   (애매한 게 N건을 넘으면 멈추고 물어본다)

1. 결과를 받으면 증명 조건부터 확인합니다. 결과물 전체를 다시 읽는 대신, 적어둔 조건이 실제로 충족됐는지만 봅니다. 조건이 부실했다면 다음 실행에서 조건을 고칩니다. 이 반복이 실력이 됩니다.

마무리

핵심을 정리합니다.

• 모델이 아니라 맡기는 과정이 문제였습니다. 시작·승인·관찰·완료·전달, 이 다섯 자리가 채워지면 같은 모델로도 맡길 수 있는 일이 늘어납니다.
• 자동 승인은 낮은 위험만 통과시킵니다. 판정은 명령 단위로 새로 붙고, 되돌리기 어려운 일은 사람이 확인합니다. 거부할 때는 이유를 함께 적어야 다른 경로를 찾습니다.
• 완료는 선언이 아니라 증거입니다. 시작 전에 "무엇으로 증명할지"를 세어볼 수 있는 문장으로 적어두면, 결과를 다시 다 읽지 않아도 됩니다.
• 재시작이 모든 걸 살려주지는 않습니다. 완료됐는데 전달만 안 된 결과는 다시 오고, 실행 중이던 작업은 오지 않습니다. 끊기면 안 되는 일은 예약 작업으로 돌립니다.

AI에게 일을 맡기는 실력은 프롬프트를 길게 쓰는 데서 늘지 않습니다. 무엇을 맡기고, 어디서 멈추게 하고, 무엇으로 완료를 확인할지 스스로 정하는 데서 늘어납니다. 그 자리를 사람이 지키고 있으면, 맡길 수 있는 일의 범위는 계속 넓어집니다.

함께 읽으면 좋은 글

• AI한테 '이거 해줘' 그만 시키세요: 출근하고 보고하는 AI 직원 만드는 법 — 맡길 대상을 처음 세팅하는 단계
• 노트북은 조종석, 일은 서버가 합니다 — Hermes Desktop 앱을 24시간 VPS에 원격 연결하는 법 — 24시간 돌려두는 실행 환경
• 비개발자를 위한 AI 프롬프트 엔지니어링 — 3사 공식 가이드에서 뽑은 5가지 핵심 원칙 — 지시를 구체적으로 적는 기본기

참고 자료 및 출처

Hermes의 화면·메뉴 이름·명령은 업데이트로 바뀝니다. 정확한 값은 위 공식 문서에서 확인하시는 것을 권합니다.

이 글의 다섯 가지 변화를 실제 화면으로 확인하고 싶으시다면, 더미 고객문의 30건으로 같은 흐름을 시연한 영상도 참고하실 수 있습니다: Hermes 에이전트, 모델보다 중요한 업데이트가 나왔습니다