개인 AI 에이전트를 실제 업무 비서처럼 운영하려면: Hermes에서 배운 메신저, 지식창고, 스킬, 헬스체크 설계

1. 개요: 에이전트는 더 큰 채팅창이 아니다

대부분의 사람은 AI를 채팅창으로 처음 만납니다. 그래서 에이전트도 화면에 나온 답변만 보고 평가하기 쉽습니다. 하지만 업무 비서는 답변만 잘해서는 부족합니다. 요청을 받고, 회사 맥락을 알고, 도구를 쓰고, 고정 규칙을 지키고, 위험한 일은 승인받고, 증거를 남기고, 사람이 자리에 없어도 접근 가능해야 합니다.

그래서 Hermes는 좋은 사례입니다. 핵심은 비밀 프롬프트가 아닙니다. 모델 주변의 래퍼입니다. Telegram은 요청을 받는 문이고, 로컬 런타임은 실제 실행 환경이며, Codex 같은 provider는 추론과 실행을 담당합니다. Obsidian은 지식 표면, MCP는 도구와 데이터 연결, skills는 반복 절차, healthcheck는 시스템이 살아 있음을 증명하는 장치입니다.

공식 문서도 같은 방향을 가리킵니다. OpenAI는 에이전트 앱을 계획하고, 도구를 호출하고, 상태를 유지하고, 승인과 관측 가능성이 필요한 시스템으로 설명합니다. MCP 문서는 AI 애플리케이션을 외부 시스템과 연결하는 표준을 설명하면서도 민감한 도구 호출에는 인간 확인과 로그가 필요하다고 말합니다. X 인박스에서 잡힌 현장 신호도 같습니다. 빌더들은 "프롬프트를 더 잘 쓰는 법"에서 "AI를 운영 시스템 안에 박아두는 법"으로 이동하고 있습니다.

2. 쉬운 용어 정리: 게이트웨이, 런타임, MCP, 스킬, 메모리, 헬스체크

게이트웨이는 사람과 에이전트 사이의 문입니다. Hermes에서는 Telegram이 그 역할을 합니다. 쉽게 말하면 코딩 앱이나 대시보드를 열지 않아도 휴대폰에서 업무 요청을 넣을 수 있다는 뜻입니다.

런타임은 에이전트가 실제로 실행되는 장소와 프로세스입니다. provider는 추론과 실행을 맡는 모델 또는 백엔드입니다. MCP, 즉 Model Context Protocol은 AI가 데이터, 도구, 워크플로우와 연결되는 표준 소켓입니다. MCP는 뇌가 아니라 연결 단자입니다.

스킬은 재사용 가능한 업무 레시피입니다. 메모리는 세션이 바뀌어도 반복해서 설명하지 않아야 하는 안정적인 맥락입니다. 헬스체크는 중요한 부품들이 연결되어 있는지 반복해서 증명하는 테스트입니다. Failure Packet은 작은 사고 기록입니다. 무엇이 실패했는지, 어떤 신호가 있었는지, 왜 그랬는지, 다음에는 어떤 규칙으로 막을지를 적습니다.

• Gateway: 요청이 들어오는 문.
• Runtime: 에이전트가 실행되는 기계나 프로세스.
• Provider: 추론과 실행을 담당하는 모델 또는 백엔드.
• MCP: 도구, 파일, API, 워크플로우를 연결하는 표준 통로.
• Skill: 반복 업무를 처리하는 재사용 절차.
• Memory: 매번 다시 설명하지 않아야 하는 안정 맥락.
• Healthcheck: 시스템이 연결되어 있음을 증명하는 반복 테스트.
• Failure Packet: 실수를 다음 운영 규칙으로 바꾸는 짧은 회고 기록.

3. 왜 메신저 인터페이스가 중요한가

메신저 인터페이스는 너무 단순해 보여서 과소평가되기 쉽습니다. 하지만 도입 문제를 크게 줄입니다. 좋은 자동화도 특정 컴퓨터, 특정 repo, 특정 터미널을 열어야만 쓸 수 있다면 실제 업무 속도에는 잘 붙지 않습니다. Telegram은 에이전트를 항상 가까운 입력면으로 만듭니다.

비즈니스 가치는 "어디서나 채팅"이라는 신기함이 아닙니다. 포착 속도입니다. 창업자는 고객 이슈를 바로 넘길 수 있고, 팀 리드는 출처 기반 요약을 요청할 수 있고, 운영자는 매일 점검을 전체 작업 환경을 다시 열지 않고 지시할 수 있습니다.

다만 이 문은 좁아야 합니다. 메신저는 읽기, 초안 작성, 요약, 분류, 큐잉에 강해야 합니다. 파일 삭제, 고객 메시지 발송, 결제, 프로덕션 변경 같은 일은 몰래 실행되면 안 됩니다. 게이트웨이가 실제 부작용을 만들 수 있는 순간, 승인과 로그는 선택 기능이 아니라 제품의 일부가 됩니다.

4. 지식창고: 에이전트에는 노트 더미가 아니라 진짜 출처가 필요하다

가장 흔한 실패는 낡거나 부분적인 맥락에서 나온 자신감 있는 답변입니다. Obsidian이 강한 이유는 회사 지식을 평문 노트로 오래 보관할 수 있기 때문입니다. 의사결정, SOP, 출처 링크, 프로젝트 규칙, 조사 로그, 매일의 맥락이 모두 쌓일 수 있습니다. Obsidian Local REST API는 vault를 인증된 REST API와 MCP 서버로 노출해 AI가 읽고, 검색하고, 허용된 경우 수정할 수 있는 구현 예시입니다.

핵심은 "허용된 경우"입니다. 지식창고를 에이전트에 연결했다고 자동으로 안전해지는 것은 아닙니다. 첫 운영 규칙은 read, search, list 우선이어야 합니다. 쓰기, 추가, 패치, 이동, 삭제는 명확한 대상과 이유가 있을 때만 허용해야 합니다. MCP는 유용하지만 위험할 수도 있습니다. 도구 접근을 쉽게 만들기 때문에 권한 경계도 같이 보여야 합니다.

Anthropic이 말하는 context engineering은 이 문제를 더 큰 이름으로 부르는 것입니다. 모델 앞에 어떤 맥락을 언제 놓을지 설계하는 일입니다. 작은 회사가 첫날부터 거대한 지식 그래프를 만들 필요는 없습니다. 대신 하나의 workflow card부터 만들면 됩니다. 담당자, 최근 업데이트일, 출처 링크, 예시, 예외, 승인 규칙, 금지 행동이 들어간 카드입니다.

5. 스킬과 메모리: 같은 설명을 매번 반복하지 않기

X 인박스에서 반복해서 보인 고통은 하나였습니다. 사람들은 AI 세션을 열 때마다 같은 말을 다시 하는 데 지쳐 있습니다. 말투, 프로젝트 제약, 선호 워크플로우, 금지 행동, 출처 우선순위는 오늘 채팅창에만 있으면 안 됩니다. 프로젝트 규칙, 메모리 파일, 스킬로 바뀌어야 합니다.

스킬은 마법이 아닙니다. 반복 업무를 위한 재사용 플레이북입니다. 블로그 글을 조사하는 법, route check를 하는 법, 위험한 git 명령을 검토하는 법, 고객 답변을 준비하는 법, 런칭 이슈를 분류하는 법입니다. 절차가 적혀 있으면 에이전트는 모든 세부사항을 항상 프롬프트에 들고 다니지 않아도 필요할 때 불러올 수 있습니다.

메모리도 절제해야 합니다. 영구 메모리는 오래가는 사실과 선호를 담아야지, 모든 임시 생각을 저장하면 안 됩니다. 더 좋은 패턴은 층을 나누는 것입니다. 항상 읽는 작은 briefing, 필요할 때 불러오는 상세 skill, 증거가 필요할 때 검색하는 source note입니다.

6. 승인과 도구 경계: 덜 연결하고 더 많이 증명하기

에이전트를 만드는 나쁜 방식은 모든 도구를 연결하고 생산성이라고 부르는 것입니다. 도구가 많아지면 할 수 있는 일은 늘지만, 우발적인 데이터 노출, 잘못된 쓰기, 책임 경계 혼란도 같이 늘어납니다. MCP 도구 명세도 민감한 작업에는 인간 확인, 명확한 표시, 입력 검증, 타임아웃, 감사 로그가 필요하다고 설명합니다.

OpenAI Codex의 승인과 sandbox 문서도 같은 운영 모양을 보여줍니다. 통제된 workspace 안에서는 읽고 수정하되, 경계를 넘거나 부작용이 큰 작업은 승인을 받아야 합니다. 이것은 관료주의가 아닙니다. 에이전트를 더 유용하게 만들면서도 사람이 책임을 유지하는 방식입니다.

따라서 좋은 Hermes식 래퍼는 whitelist에서 시작합니다. 메신저가 무엇을 실행할 수 있는지, 에이전트가 무엇을 읽을 수 있는지, 어떤 도구는 읽기 전용인지, 어떤 행동은 승인이 필요한지, 어떤 행동은 금지인지, 실행 후 증거는 어디에 남기는지를 먼저 정해야 합니다.

7. 헬스체크, 로그, Failure Packet

에이전트가 운영의 일부라면 "어제는 됐다"로는 부족합니다. 게이트웨이가 끊길 수 있습니다. OAuth가 만료될 수 있습니다. Obsidian이 닫혀 있을 수 있습니다. 로컬 MCP endpoint가 실패할 수 있습니다. 시작 프로그램이 깨질 수 있습니다. 모델이나 provider 설정이 바뀔 수 있습니다. 헬스체크가 없으면 첫 발견자는 일을 기다리던 사람이 됩니다.

헬스체크는 지루하고 반복 가능해야 합니다. 게이트웨이 프로세스가 살아 있는지, provider에 닿는지, 지식창고에 닿는지, 도구 목록을 볼 수 있는지, 해롭지 않은 테스트 요청을 끝낼 수 있는지, 로그가 남는지 확인해야 합니다. 이 차이가 데모와 실제 비서의 차이입니다.

두 번째 루프는 Failure Packet입니다. 같은 실패가 반복되면 수동으로 고치고 끝내면 안 됩니다. incident, signal, root cause, prevention rule, closeout proof를 남겨야 합니다. 이렇게 해야 개인 스크립트가 매주 좋아지는 운영 시스템이 됩니다.

8. 회사에서는 어떻게 과하게 만들지 않고 도입할까

작은 팀의 첫 Hermes식 에이전트는 회사를 통째로 관리하면 안 됩니다. 리스크가 낮고 출처가 명확한 반복 업무 하나를 고르세요. 매일 지식 요약, 고객 질문 triage, lead research, 런칭 체크리스트 리뷰, 블로그 조사 brief, 내부 SOP 검색 같은 일입니다.

그 다음 가장 작은 운영 래퍼를 만듭니다. 하나의 메신저 입구, 하나의 source-of-truth 폴더, 하나의 작업 티켓 형식, 한두 개의 읽기 우선 도구, 하나의 승인 규칙, 하나의 헬스체크, 결과를 남기는 하나의 로그 위치입니다. 2주 동안 잘 돌아가면 그때 도구 하나나 workflow 하나를 더합니다.

이 지점에서 사람도 AI와 함께 발전해야 합니다. 모델이 강해질수록 인간의 장점은 모든 답을 직접 쓰는 능력에서 업무 시스템을 설계하는 능력으로 이동합니다. 출처 우선순위, 권한 경계, escalation rule, 품질 기준, feedback loop를 설계하는 사람은 AI 때문에 덜 중요해지는 것이 아니라 더 중요해집니다.