당신의 AI 에이전트는 먼저 메시지를 보내야 합니다

이 글은 Hermes Agent Challenge의 제출물입니다: Hermes Agent에 대해 작성하기.

대부분의 AI 어시스턴트(AI assistants)는 Slack 초대장을 잃어버린 인턴처럼 가만히 기다리기만 합니다.

당신은 탭을 엽니다. 프롬프트(prompt)를 입력합니다. 똑같은 프로젝트를 다시 설명합니다. 똑같은 링크를 다시 붙여넣습니다. 그러고 나서 답변이 진짜인지 확인하느라 오후 시간의 절반을 보냅니다.

AI가 화려한 자동 완성(autocomplete) 상자였을 때는 괜찮았습니다.

하지만 에이전트(agents)에게는 괜찮지 않습니다.

가장 흥미로운 Hermes Agent 활용 사례는 "도구를 갖춘 챗봇(chatbot)"이 아닙니다. 그것은 당신의 서버에 상주하며, 당신 삶의 지루한 부분들을 지켜보고, 당신이 일을 처리하는 방식을 기억하며, 볼 가치가 있는 일이 생겼을 때 당신에게 먼저 메시지를 보내는, 항상 켜져 있는 작은 비서실장(chief of staff)입니다.

Jarvis(자비스)도 아니고, 공상 과학 영화 속 집사도 아닙니다. 그보다는 잠도 자지 않고 가끔 당신의 할 일 목록(TODO list)을 판단하기도 하는, 카페인을 과다 섭취한 운영 담당자(operations person)에 가깝습니다.

승리하는 활용 사례: 먼저 메시지를 보내는 에이전트

2026년의 트렌드는 명확합니다. 에이전트들은 짧은 채팅 세션에서 장기 실행 워크플로(workflows)로 이동하고 있습니다.

개발자들은 코딩 에이전트(coding agents)를 사용하여 리포지토리(repos)를 검사하고, 테스트를 실행하며, PR(Pull Requests)을 생성하고, 몇 분 또는 몇 시간 동안 반복 작업을 수행합니다. 팀들은 모든 모델에 대해 일회성 통합(integrations)을 작성하는 대신 MCP를 통해 도구들을 연결하고 있습니다. 개인용 에이전트 사용자들은 단순한 프롬프트의 영리함보다 메모리(memory)에 더 신경을 씁니다. 왜냐하면 사각형 모양의 화면에 자신의 삶을 다시 설명하는 것에 지쳤기 때문입니다.

Hermes는 바로 그 교차점에 위치합니다:

사용자의 개인 기기, VPS, 컨테이너 또는 클라우드 백엔드 (cloud backend)에서 실행할 수 있습니다.
메시징 게이트웨이 (messaging gateway)를 갖추고 있어, 에이전트가 사용자가 이미 대화하고 있는 곳인 Telegram, Discord, Slack, WhatsApp, 이메일 등에서 활동할 수 있습니다.
지속성 메모리 (persistent memory), 세션 검색 (session search), 그리고 스킬 (skills)을 갖추고 있어, 매일 아침 처음부터 다시 시작하는 대신 점진적으로 개선될 수 있습니다.
크론 잡 (cron jobs)과 웹훅 (webhooks)을 지원하여, 사용자가 무언가를 잊었다는 사실을 기억해낼 때까지 기다리지 않고도 스스로 행동할 수 있습니다.
도구 (tools), MCP 서버, 터미널 명령 (terminal commands), 파일, 브라우저, 이미지 생성, TTS (Text-to-Speech), 그리고 서브 에이전트 (subagents)를 사용할 수 있습니다.

이러한 조합은 제품의 형태를 변화시킵니다.

일반적인 어시스턴트는 다음과 같이 답합니다:

"이 뉴스 기사를 요약해줘."

선제적인 Hermes 워크플로우 (workflow)는 다음과 같이 말합니다:

"매일 아침 에이전트 생태계를 확인하고, 유용한 이야기를 검증하며, 중복된 내용은 무시해줘. 내 스타일로 짧은 브리핑을 작성하고, 커버 카드를 생성한 뒤, Telegram에 게시하고, 어제와 비교해서 무엇이 바뀌었는지 나에게 알려줘. 만약 워크플로우가 중단되면 정확히 어느 부분에서 문제가 생겼는지 설명해줘."

이것은 완전히 차원이 다른 존재입니다.

5단계 루프 (5-step loop)

이번 챌린지를 위해 제가 구축할 가장 이상적인 Hermes 워크플로우는 간단합니다:

감시 (Watch): 뉴스 피드, GitHub 리포지토리 (repos), 이슈 (issues), 편지함, 캘린더, RSS, 대시보드, 또는 현재 당신이 "나중에 확인해야지"라고 말하게 만드는 그 어떤 시스템이든 감시합니다.
검증 (Verify): 소스를 가져오고, 여러 참조 자료를 비교하며, 환각 (hallucination)이 섞인 요약을 방지하고, 근거 (receipts)를 남깁니다.
생성 (Produce): 브리핑을 작성하고, 다이어그램을 생성하며, PR (Pull Request) 초안을 작성하고, 이슈를 생성하거나, 노트를 업데이트하거나, 메시지를 준비합니다.
보고 (Report): 최종 결과를 실제 사람이 있는 플랫폼을 통해 다시 보냅니다.
학습 (Learn): 워크플로우가 성공적으로 작동하면 이를 하나의 스킬 (skill)로 저장하고, 다음번에 해당 절차를 재사용합니다.

마지막 단계는 사람들이 과소평가하는 부분입니다.

도구를 사용하는 에이전트 (tool-using agent)는 유용합니다. 하지만 무엇이 효과적이었는지 기록하는 도구 사용 에이전트는 가장 좋은 의미에서 '위험'합니다. 첫 번째 실행은 엉망일 수 있습니다. 하지만 다섯 번째 실행부터는 마치 누군가를 고용한 것 같은 기분이 들기 시작합니다.

왜 Hermes가 이에 적합한가

많은 에이전트 프레임워크 (agent frameworks)가 도구를 호출할 수 있습니다. 그것은 이제 기본 사양 (table stakes)입니다.

Hermes가 흥미로워지는 이유는 에이전트를 브라우저 탭처럼 다루는 것이 아니라, 상주 프로세스 (resident process)에 가깝게 다루기 때문입니다.

1. 게이트웨이 (gateway)를 통해 접근 가능하게 만듭니다

에이전트가 당신의 터미널 (terminal) 안에 갇혀 있을 필요는 없습니다. 산책 중에는 Telegram으로, 배송 업무 중에는 Discord로, 혹은 리포지토리 (repo)에 깊이 몰입해 있을 때는 CLI를 통해 에이전트와 대화할 수 있습니다.

직접 해보기 전까지는 이것이 단순히 외관상의 문제처럼 들릴 수도 있습니다.

최고의 자동화는 당신이 그것을 떠올린 바로 그 순간에 실행할 수 있는 것입니다. 커피를 만드는 동안 블로그 아이디어가 떠올랐을 때, 노트북을 열고, 적절한 리포지토리를 찾고, 가상 환경 (virtualenv)을 활성화하고, 번거로운 절차를 수행하고 싶지는 않을 것입니다. 저는 그냥 음성 메시지를 보내고 제 할 일을 계속하고 싶습니다.

2. Cron을 통해 선제적으로 작동하게 만듭니다

Cron은 지루하지만, 그렇기 때문에 승리합니다.

프롬프트 (prompt)를 기다리는 에이전트는 관리해야 할 또 다른 탭이 될 뿐입니다. 하지만 예약된 작업 (scheduled jobs)을 가진 에이전트는 인프라 (infrastructure)가 됩니다.

예시:

"매 평일 오전 9시에 AI 에이전트 뉴스를 요약해 줘."
"매주 금요일마다 내 오픈 소스 이슈 (open-source issues)를 확인하고 실현 가능한 기여 방안을 하나 제안해 줘."
"매일 밤 내 노트를 스캔해서 내일의 우선순위 목록을 생성해 줘."
"매일 아침 내 블로그 파이프라인 (pipeline)이 실행되었는지 확인하고, 실행되지 않았다면 알려줘."

네, 마지막 예시는 개인적인 것입니다. 질문은 받지 않겠습니다.

3. 메모리 (memory)는 '그라운드호그 데이 (Groundhog Day)'를 방지합니다

메모리가 없다면 에이전트는 값비싼 금붕어가 됩니다.

당신은 이렇게 말합니다:

"짧은 문구를 사용해 줘. IST 시간을 선호해. 내 DEV.to 핸들은 이거야. 내 이미지들은 저 GitHub 리포지토리에 있어. 다른 에이전트가 작업 중일 때는 게이트웨이를 재시작하지 마."

그러면 다음 주에 에이전트가 똑같은 것을 다시 묻습니다.

그 시점에서 AI는 시간을 절약한 것이 아닙니다. 그저 당신의 짜증을 GPU로 외주 준 것뿐입니다.

Hermes는 지속적인 사용자 메모리 (User memory), 정기적인 세션 기록 (Session history), 그리고 절차적 기술 (Procedural skills)을 갖추고 있습니다. 이것들은 서로 다른 종류의 컨텍스트 (Context)입니다:

사용자 메모리 (User memory): 지속적인 선호도와 사실.
세션 검색 (Session search): 과거 대화에서 일어난 일.
기술 (Skills): 특정 범주의 업무를 수행하기 위한 재사용 가능한 절차.

이러한 분리는 매우 중요합니다. "Nimesh는 IST 시간을 선호한다"는 메모리입니다. "호스팅된 이미지를 사용하여 DEV.to 기사를 게시하는 방법"은 기술입니다. "우리는 어제의 커버 이미지를 수정했다"는 세션 기록입니다.

이것들이 서로 뒤섞이면 에이전트는 엉망이 됩니다. 반면, 이것들이 분리되어 있으면 에이전트는 숙련된 전문가 (Senior)처럼 느껴지기 시작합니다.

4. 기술은 훌륭한 업무를 반복 가능하게 만듭니다

기술 (Skills)은 숨겨진 핵심 기능입니다.

대부분의 사람들은 에이전트가 단 하나의 작업을 완료하게 만드는 것이 어려운 부분이라고 생각합니다. 하지만 그것은 문제의 절반일 뿐입니다. 진정한 승리는 에이전트가 다음번에 똑같이 고통스러운 유도 (Steering)를 필요로 하지 않도록 만드는 것입니다.

좋은 기술은 메모리에 쑤셔 넣은 동기 부여 문구가 아닙니다. 그것은 플레이북 (Playbook)입니다:

언제 그것을 사용할지
어떤 도구 (Tools)를 호출할지
어떤 파일이나 API가 중요한지
무엇이 잘못될 수 있는지
결과를 어떻게 검증할지

이것은 기본적으로 숙련된 전문가들이 일하는 방식이기도 합니다. 그들은 모든 세부 사항을 기억하지 않습니다. 그들은 문제의 형태, 함정, 그리고 어설픈 행동 (Clown behavior)을 방지하는 체크리스트를 기억합니다.

구체적인 빌드: 개인용 시그널 데스크 (Personal signal desk)

만약 제가 심사위원들에게 깊은 인상을 남기기 위해 하나의 Hermes 프로젝트를 만든다면, 저는 이것을 만들 것입니다:

개인용 시그널 데스크 (The Personal Signal Desk): 당신이 선택한 도메인을 감시하고, 높은 신호 (High-signal)를 가진 업데이트를 찾아내며, 짧은 일일 브리핑을 작성하고, 간단한 시각 자료를 생성하며, 선호하는 채팅창에 게시하고, 시간이 지남에 따라 스스로의 소싱 규칙 (Sourcing rules)을 개선하는 상시 가동되는 Hermes 워크플로 (Workflow).

개발자라면 다음과 같은 것들을 감시할 수 있습니다:

AI 에이전트 관련 GitHub 트렌딩 저장소 (trending repos)
MCP 서버 출시
관련 DEV 포스트
Hacker News 토론
사용하는 도구들의 문서 (docs) 변경 사항
본인의 저장소 및 이슈 (issues)

창업자(Founder)의 경우, 다음과 같은 것들을 감시할 수 있습니다:

경쟁사의 출시
가격 페이지 변경 사항
채용 공고
투자 유치 발표
Reddit의 고객 불만 사항
소셜 채널에서의 제품 언급

학생의 경우, 다음과 같은 것들을 감시할 수 있습니다:

인턴십 채용
연구 논문
해커톤 (Hackathons)
장학금 마감일
대학교 공지 사항
본인의 학습 계획

동일한 아키텍처 (Architecture). 다른 소스 (Sources). 다른 기술 (Skills).

에이전트는 50개의 링크를 한꺼번에 쏟아내서는 안 됩니다. 그것은 지능이 아닙니다. 그것은 링크 쓰레기 매립지일 뿐입니다.

에이전트는 다음 다섯 가지를 가지고 돌아와야 합니다:

무엇이 변했는가
그것이 왜 중요한가
출처 링크
어떤 조치를 취해야 하는가
내일을 위해 무엇을 배웠는가

마지막 항목이 바로 Hermes가 제값을 하는 지점입니다.

워크플로 (Workflow)의 실제 모습

지루하지만 현실적인 버전은 다음과 같습니다:

08:55 Cron이 Hermes를 깨움
08:56 Hermes가 설정된 소스들을 검색함
08:58 검색 스니펫 (snippets)뿐만 아니라 원본 페이지를 가져옴
...

유용한 에이전트의 재미있는 점은 최종 데모가 거의 너무 단순해 보인다는 것입니다.

메시지 하나가 도착합니다.

그게 전부입니다.

하지만 그 메시지 아래에는 검색, 검증 (validation), 메모리 (memory), 도구 사용 (tool use), 예약된 실행 (scheduled execution), 파일 처리 (file handling), 어쩌면 이미지 생성, 어쩌면 TTS (Text-to-Speech), 그리고 아무도 수동으로 하고 싶어 하지 않는 수많은 미세한 검증 단계들이 존재합니다.

이것이 제가 "비서실장 (chief of staff)"라는 프레임워크를 좋아하는 이유입니다. 비서실장은 마법처럼 보이기 위해 존재하는 것이 아닙니다. 그들은 혼란을 줄이기 위해 존재합니다.

밈 (Meme) 버전

모든 에이전트 블로그에는 아주 작은 장난스러운 다이어그램 하나가 필요하기 때문입니다. 그렇지 않으면 개발의 신들이 노하실 테니까요:

이 농담이 먹히는 이유는 이것이 절반의 농담이기 때문입니다.

선제적인 에이전트 (Proactive agent)는 알림을 사방에 뿌리도록 방치한다면 분명 짜증스러운 존재가 될 수 있습니다. 핵심은 에이전트가 사용자의 방해를 받을 권리를 스스로 증명하게 만드는 것입니다.

저의 규칙은 다음과 같습니다:

만약 Hermes가 나에게 먼저 메시지를 보낸다면, 그 메시지는 시간을 절약해주거나, 실수를 방지하거나, 혹은 완료된 작업을 보여주어야 한다.

단순히 분위기만 맞추는 핑 (Vibes-only pings)은 안 됩니다. "그냥 확인차 연락드렸어요" 같은 스팸도 안 됩니다. 가짜 생산성을 과시하는 축하 세리머니 (Productivity confetti)도 안 됩니다.

증거를 제시하거나, 아니면 침묵하십시오.

시니어급 체크리스트

이 워크플로 (Workflow)가 데모 단계를 넘어 실제로 생존하기를 원한다면, 프로덕션 소프트웨어 (Production software)처럼 설계하십시오.

하나의 좁은 작업부터 시작하기

자신의 야망을 디버깅 (Debugging)하는 것을 즐기는 게 아니라면, 첫날부터 "내 인생 전체를 위한 OS"를 구축하려 하지 마십시오.

한 가지 작업만 선택하십시오:

일일 AI 브리핑 (Daily AI brief)
주간 오픈소스 기여 탐색 (Weekly open-source contribution scout)
블로그 발행 보조 (Blog publishing assistant)
편지함 분류 (Inbox triage)
릴리스 모니터링 (Release monitor)
회의 후속 조치 초안 작성 (Meeting follow-up drafter)

그 작업을 지루할 정도로 신뢰할 수 있게 만드십시오. 그다음 단계로 넘어가면 됩니다.

메모리 (Memory)와 로그 (Logs)를 분리하기

모든 무작위 이벤트를 영구적인 메모리 (Durable memory)로 저장하지 마십시오. 그렇게 하면 에이전트가 유령이 나오는 다락방처럼 변하게 됩니다.

영구적인 사실 (Durable facts)은 저장하십시오. 작업 이력은 세션 (Sessions)에 유지하십시오. 절차 (Procedures)는 기술 (Skills)로 만드십시오.

발행 전 검증하기

워크플로가 공개적으로 게시되는 구조라면, 검증 (Verification)을 워크플로의 일부로 만드십시오.

블로그 파이프라인 (Blog pipeline)의 경우, 다음을 의미합니다:

원본 이미지 URL이 200 상태 코드를 반환하는지
기사 API가 성공을 반환하는지
공개 페이지가 정상적으로 로드되는지
태그가 정확한지
시각적 규칙에 따라 커버 이미지에 의도치 않은 텍스트가 없는지

네, 이것은 지루한 작업입니다. 바로 그렇기 때문에 에이전트가 이 일을 해야 하는 것입니다.

위험한 작업에는 인간을 루프에 포함시키기 (Human-in-the-loop)

자율성 (Autonomy)이 무모함 (Recklessness)과 같지는 않습니다.

Hermes가 초안을 작성하고, 확인하고, 요약하고, PR (Pull Request)을 열고, 게시물을 준비하게 하십시오. 파괴적인 명령, 자금 이동, 프로덕션 배포 (Production deploys), 외부 이메일, 그리고 대규모로 당신을 당황스럽게 만들 수 있는 모든 것에는 더 주의를 기울여야 합니다.

최고의 에이전트 설정은 "모든 것을 YOLO(You Only Live Once) 식으로" 하는 것이 아닙니다. 그것은 범위가 지정된 신뢰 (Scoped trust)입니다.

결과물을 판단하기 쉽게 만들기

모든 선제적 워크플로는 다음 질문에 답할 수 있어야 합니다:

무엇을 했는가?
무엇이 변했는가?
어떤 소스 (Sources)를 사용했는가?
무엇이 실패했는가?
내가 다음에 무엇을 해야 하는가?

에이전트가 스스로를 설명할 수 없다면, 그것은 완료된 것이 아닙니다. 그저 확신에 차 있을 뿐입니다.

이것이 챌린지에서 승리할 수 있는 이유

Hermes Agent Challenge의 write 트랙은 명확성 (Clarity), 깊이 (Depth), 독창성 (Originality), 실용적 가치 (Practical value), 그리고 글쓰기 품질 (Writing quality)을 기준으로 심사됩니다.

선제적인 비서 (Chief-of-staff) 워크플로우는 추상적이지 않기 때문에 이 다섯 가지 요소를 모두 충족합니다. 이는 Hermes가 일반적인 어시스턴트와 무엇이 다른지를 보여줍니다: