맥미니로 24시간 도는 AI 에이전트 만들기 (3) — 활용기: 커스텀 스킬과 멀티에이전트

1편에서 토대를 세우고 2편에서 모델 라우팅을 잡았습니다. 이제 진짜 재미있는 부분 — 에이전트에게 내 워크플로우를 가르치는 단계입니다.

이번 편은 커스텀 스킬 제작, 여러 역할이 협업하는 멀티에이전트 구성, 과거를 기억하는 메모리 기능, 그리고 자동화(병렬 처리·cron·외부 연동)를 다룹니다. 사례는 멀티에이전트 주식 분석 리포트입니다.

이 편이 1편의 "항상 켜진 두뇌"라는 출발점과 다시 만나는 지점입니다. 단발성 챗봇과 상주형 에이전트의 결정적 차이가 바로 여기, "내 절차를 기억하고 자동으로 수행한다"에 있기 때문입니다.

스킬이란 무엇인가

Hermes의 **스킬(skill)**은 "이런 작업은 이렇게 처리하라"를 담은 절차서입니다. 실행 코드가 아니라 마크다운 문서(SKILL.md)이고, 에이전트가 그 절차를 자기 모델과 도구로 스스로 수행합니다. 즉 프로그램을 짜는 게 아니라, 잘 정리된 업무 매뉴얼을 써주는 일에 가깝습니다.

구조는 단순합니다.

~/.hermes/skills/custom/trading-report/
└── SKILL.md

파일 맨 위에 메타데이터(name, description)를 두고, description에 트리거가 될 표현들을 적습니다. 사용자가 그에 맞는 요청을 하면 에이전트가 알아서 스킬을 발동합니다.

---
name: trading-report
description: 단일 종목에 대해 10개 에이전트 투자 분석 리포트를 생성한다.
  "분석", "리포트", "매수/매도 의견" 등을 요청하면 이 스킬을 사용하라.
---

# Trading Report — 10-Agent 투자 분석
...

스킬이 등록됐는지는 다음으로 확인합니다.

hermes skills list

막혔던 지점: 스킬 발동은 모델 능력에 달렸습니다

스킬을 등록했는데도 에이전트가 안 부르는 일이 잦았습니다. "분석해줘"라고 해도 그냥 자기 식대로 짧게 답해버립니다. 이를 **과소발동(undertrigger)**이라 하는데, 경량 모델일수록 심합니다. 해결책은 두 가지였습니다 — description에 트리거 표현을 더 공격적으로 넣거나, 스킬 이름을 명시적으로 부르는 것입니다(예: trading-report 스킬로 분석해줘).

막혔던 지점: 긴 파일은 붙여넣지 말고 전송하세요

SKILL.md를 터미널에서 heredoc(cat > file << 'EOF') 방식으로 붙여넣다가 중간이 잘려 계속 실패했습니다. 긴 텍스트를 SSH 창에 한 번에 붙여넣으면 일부가 누락되거나, 종료 마커를 못 찾아 셸이 입력 대기 상태에 갇히기 쉽습니다. 긴 파일은 로컬에서 만들어 scp로 맥미니에 전송하는 게 훨씬 안전합니다.

scp ./SKILL.md 사용자명@100.x.x.x:~/.hermes/skills/custom/trading-report/SKILL.md

전송 후에는 앞뒤가 온전히 들어갔는지 head와 tail로 확인하는 습관을 들였습니다.

head -3 ~/.hermes/skills/custom/trading-report/SKILL.md
tail -3 ~/.hermes/skills/custom/trading-report/SKILL.md

멀티에이전트 — 10개 역할의 협업

이 스킬의 핵심은 10개의 전문 에이전트를 순차 실행하는 것입니다 (TauricResearch의 TradingAgents 아키텍처를 참고했습니다). 각 에이전트가 앞 단계의 출력을 입력받아 분석을 누적 심화합니다.

1. Technical Analyst   (시세·기술적 지표, 웹검색)
2. Fundamentals        (밸류에이션·PEG, 웹검색)
3. Sentiment           (수급·심리, 웹검색)
4. News                (뉴스·이벤트, 웹검색)
   ── 여기까지만 웹검색 ──
5. Bull Researcher      (강세 논리)
6. Bear Researcher      (Bull을 직접 반박)
7. Research Manager     (양측 종합 판단)
8. Trader               (진입·목표·손절가)
9. Risk Manager         (리스크 점검)
10. Portfolio Manager   (최종 결정 카드)

설계에서 신경 쓴 두 가지 장치가 있습니다.

가격 앵커. 첫 단계인 Technical Analyst가 현재가를 명시적으로 추출하고, 이후 모든 에이전트가 그 현재가만 기준으로 가격을 논하게 했습니다. 이게 없으면 뒤 단계에서 진입가·목표가를 환각으로 지어냅니다. 첫 단계에서 가격을 못 박아두는 것이 환각 방지의 핵심이었습니다.

웹검색 분리. 앞 4개 분석가만 실시간 데이터를 검색하고, 뒤 6개는 새로 검색하지 않고 앞 단계 결과로만 추론하게 했습니다. 속도·일관성·비용을 위한 선택입니다.

출력 품질은 결국 모델 체급

같은 스킬을 Flash-Lite로 돌리면 각 단계가 2~3줄로 압축됐고, 2.5 Flash로 돌리면 훨씬 충실했습니다. 프롬프트에 "각 단계 5~7문장, 압축 금지"를 명시해도 경량 모델은 잘 따르지 않았습니다. 결론은 2편과 같습니다 — 깊이가 필요하면 모델을 올려야 합니다. 그래서 이 리포트는 2.5 Flash로 돌리고, 일상 대화는 Flash-Lite로 두는 식으로 분리했습니다.

메모리 — 과거 분석을 기억하기

기본 스킬은 매번 백지에서 시작합니다. 같은 종목을 다음 주에 또 분석해도 지난번 판단을 모릅니다. 그래서 메모리 기능을 추가했습니다. 이것이야말로 "항상 켜진 두뇌"가 단발 챗봇과 갈리는 지점입니다 — 어제의 판단을 오늘 이어받으니까요.

• 분석을 마치면 종목별 파일(~/.hermes/trading-memory/<티커>.md)에 결정·가격·근거를 한 줄 추가합니다.
• 다음 분석을 시작하기 전에 그 파일을 읽고, "지난번 판단이 맞았는지" 회고한 뒤 새 판단에 반영합니다.

이러면 리포트에 "지난 분석에서 매수 추천했고 이후 +12% 상승 — 판단 유효" 같은 회고가 붙고, 신뢰도가 과거 적중 여부까지 반영해 조정됩니다.

막혔던 지점: 종목 간 오염

여기서 한 가지 우려가 있었습니다 — 다른 종목 분석이 섞이지 않을까? 두 가지 가드레일로 막았습니다.

1. 파일 분리. 종목별 파일을 따로 두고, "정확히 그 티커 파일만 읽어라"를 명시했습니다. 티커 표기도 표준화(회사명 → 표준 티커)해서, 같은 종목이 다른 파일로 흩어지는 것을 방지했습니다.
2. 세션 격리. 같은 대화에서 연달아 여러 종목을 물으면, 직전 종목 분석이 대화 맥락에 남아 다음 판단에 스며들 수 있습니다. "직전 종목 내용은 참고하지 말고 독립적으로 시작하라"를 명시하고, 종목별로 Discord 스레드를 분리해 쓰면 더 깨끗합니다.

자동화 — 병렬, 그리고 밤샘 배치

멀티에이전트 병렬 처리

여러 종목을 동시에 분석하고 싶을 때, Hermes의 delegate_task로 부모 에이전트가 자식 에이전트들을 병렬 생성할 수 있습니다. 봇을 여러 개 만들 필요가 없습니다 — 봇 하나가 내부에서 서브에이전트를 띄웠다 거둡니다. 디스코드에서 "삼성전자와 SK하이닉스를 병렬로 분석해줘"라고 하면 알아서 위임이 일어납니다.

다만 제약이 있습니다. 동기적이라 부모 턴이 중단되면(새 메시지를 보내거나 중지하면) 자식들이 취소되고, 무엇보다 로컬 모델로는 병렬이 안 됩니다 — 모델 하나도 24GB에 빠듯한데 동시 여러 개는 메모리 초과입니다. 병렬은 클라우드 모델에서만 현실적이고, 로컬은 순차로 가야 합니다.

밤샘 cron 배치 — 24시간 두뇌의 진가

정기 작업이야말로 이 시스템의 진가가 나오는 영역입니다. 1편에서 "항상 켜진 두뇌"라고 했는데, 그게 가장 빛나는 순간이 바로 이것입니다. 밤새 도는 작업은 느려도 상관없고, 자는 동안 진행되며, 아침에 결과만 받으면 됩니다. 자는 동안 관심 종목들을 분석해서 출근 전에 브리핑을 받는 식이죠.

여기서 중요한 건 이건 delegate_task가 아니라 cron으로 해야 한다는 점입니다. delegate는 대화 턴에 묶여 중단되면 날아가지만, cron은 턴과 무관하게 독립 실행됩니다. 그래서 "낮엔 클라우드로 빠르게 묻고, 밤엔 정기 배치를 돌려 아침에 받는" 리듬이 만들어집니다. 이 정기 배치를 비용 걱정 없이 마음껏 돌리고 싶다면 로컬 모델이, 품질이 더 중요하면 클라우드가 적합합니다 — 2편의 라우팅 판단이 그대로 적용됩니다.

외부 연동

Hermes는 Google Workspace(Gmail·Calendar) 같은 외부 서비스도 OAuth로 붙일 수 있습니다. "메일에서 일정을 뽑아 캘린더에 넣기", "첨부파일을 읽어 요약하기" 같은 작업이 가능해집니다. 설정은 에이전트 주도로 진행되어, "구글 워크스페이스를 이메일과 캘린더로 연동해줘"라고 하면 Google Cloud 프로젝트 생성부터 OAuth 인증까지 단계별로 안내해줍니다. Obsidian 같은 노트 앱과 연동하면 에이전트가 무엇을 기억·학습하는지 마크다운으로 직접 검토할 수도 있습니다.

다만 여기서도 라우팅 원칙은 그대로입니다 — 외부 서비스의 내용이 처리 모델로 들어가므로, 민감한 메일이나 문서는 로컬 모델 채널에서만 다뤄야 합니다.

전체 정리 — 3편을 마치며

맨땅에서 시작해 다음을 갖췄습니다.

• 헤드리스 + 원격(Tailscale) + Discord로 24시간 가동되는 에이전트 (1편)
• 로컬/클라우드 하이브리드 모델 라우팅 (2편)
• 내 워크플로우를 담은 커스텀 멀티에이전트 스킬 + 메모리 + 자동화 (3편)

핵심 철학은 하이브리드와 분업입니다. 만능 모델 하나에 다 맡기는 게 아니라, 작업 성격에 따라 — 빠르게 원하면 클라우드, 깊게 원하면 상위 모델, 데이터를 가두거나 마음껏 돌리고 싶으면 로컬, 정기적이면 밤샘 cron — 적재적소에 나눠 쓰는 것입니다. 그리고 그 분업을 스킬이라는 절차서로 코드화해 에이전트에게 가르치는 것입니다.

처음에 "항상 켜져 있는, 나만의 두뇌"라고 했습니다. 클라우드 챗봇은 내가 물을 때만 깨어나지만, 이 시스템은 내가 자는 동안에도 어제의 판단을 기억한 채 오늘의 일을 합니다. 24GB 맥미니라는 제한된 하드웨어로도, 내 워크플로우를 아는 상주형 두뇌를 만들 수 있다는 것 — 이게 이 실험의 결론입니다.