만자 시스템 프롬프트의 해부학: Hermes Agent가 보여주는 AI 에이전트의 진짜 구조
🎧 Voice Briefing
📅 Generated: 2026. 4. 16. 오전 8:26
---

1만 토큰 시스템 프롬프트의 해부학: Hermes Agent가 보여주는 AI 에이전트의 진짜 구조
프롤로그: 당신이 대화하는 AI의 뒤편에는 만자가 숨어 있다
모든 사람이 프롬프트 엔지니어링을 이야기한다. "역할을 정해줘라", "맥락을 넣어라", "예시를 보여줘라."
하지만 실제 AI 에이전트가 사용하는 시스템 프롬프트를 한 글자도 빠짐없이 본 사람은 거의 없다.
최근 중국 개발자 岚叔(란수)가 오픈소스 AI 에이전트 Hermes의 시스템 프롬프트 전체를 덤프(dump)했다. 결과는 충격적이었다. 총 36,700자, 약 10,000 토큰.1 그리고 그 절반은 불필요했다.
이건 단순한 기술 분석이 아니다. AI 에이전트가 매 대화마다 얼마나 많은 자원을 낭비하고 있는지 — 그리고 그것을 어떻게 50% 줄일 수 있는지에 대한 이야기다.
I – 9개 레이어: AI 에이전트의 숨겨진 지층
Hermes Agent의 시스템 프롬프트는 9개의 레이어로 구성되어 있다. 마치 지질학적 지층처럼, 각 레이어는 고유한 역할을 담당한다.
graph TD
subgraph 정체성 ["정체성 레이어"]
A["1. SOUL.md — 에이전트 인격<br>~500자"]
end
subgraph 기억 ["기억 레이어"]
B["2. Memory 가이드 — 저장 규칙<br>~600자"]
C["3. MEMORY 스냅샷 — 장기 기억<br>~3,725자"]
D["4. USER PROFILE — 사용자 프로필<br>~682자"]
end
subgraph 능력 ["능력 레이어"]
E["5. Skills 인덱스 — 80+ 스킬 목록<br>~5,000자"]
F["6. AGENTS.md — 프로젝트 가이드<br>~20,300자"]
end
subgraph 환경 ["환경 레이어"]
G["7. 세션 메타데이터<br>~200자"]
H["8. 플랫폼 프롬프트<br>~200자"]
I["9. 대화 컨텍스트<br>~400자"]
end
A --> B --> C --> D --> E --> F --> G --> H --> I
style 정체성 fill:#e3f2fd,stroke:#1565c0
style 기억 fill:#f3e5f5,stroke:#7b1fa2
style 능력 fill:#fff3e0,stroke:#e65100
style 환경 fill:#e8f5e9,stroke:#2e7d32
내가 주목한 부분은 이것이다.
"AGENTS.md 파일 하나가 시스템 프롬프트의 거의 절반을 차지한다. 그런데 일반 사용자에게는 불필요한 내용이다."[^1]
여기서 핵심이 나온다. 에이전트를 개발하는 사람과 사용하는 사람의 프롬프트는 같을 필요가 없다. 그런데 Hermes는 기본 설정에서 둘을 구분하지 않았다.
II – 레이어별 해부: 무엇이 필수이고, 무엇이 낭비인가
9개 레이어를 기능과 토큰 비용 기준으로 분류해보면, 명확한 패턴이 보인다.
| 레이어 | 내용 | 크기 | 필수도 |
|---|---|---|---|
| 1. SOUL.md | 에이전트 인격 정의 | ~500자 | 필수 |
| 2. Memory 가이드 | 메모리 도구 사용법 | ~600자 | 필수 |
| 3. MEMORY 스냅샷 | 장기 기억 (93% 사용) | ~3,725자 | 필수 |
| 4. USER PROFILE | 사용자 선호도 | ~682자 | 필수 |
| 5. Skills 인덱스 | 80+ 스킬 목록 | ~5,000자 | 조건부 |
| 6. AGENTS.md | 프로젝트 개발 가이드 | ~20,300자 | 선택 |
| 7. 세션 메타데이터 | 시간/모델 정보 | ~200자 | 필수 |
| 8. 플랫폼 프롬프트 | Telegram/Discord 등 | ~200자 | 필수 |
| 9. 대화 컨텍스트 | 현재 세션 정보 | ~400자 | 필수 |
6번 AGENTS.md가 20,300자로 전체의 55%를 차지한다. 그리고 이 파일은 프로젝트 디렉터리 구조, 코어 API 문서, 도구 추가 가이드 등 개발자용 정보다.
일반 사용자가 Hermes와 대화할 때 이 정보가 필요할까? 전혀 아니다.
"매 대화마다 5,000 토큰을 절약할 수 있다. CWD(Current Working Directory) 경로만 바꾸면 된다."[^1]
III – 50% 토큰 절약: 한 줄의 설정 변경
란수가 제안한 해결책은 놀라울 정도로 간단하다.
Hermes는 프로젝트 파일을 다음 우선순위로 로드한다:
.hermes.md → AGENTS.md → CLAUDE.md → .cursorrules
기본 CWD가 ~/.hermes/hermes-agent/로 설정되어 있으면, 그 디렉터리의 거대한 AGENTS.md가 매번 로드된다.
해결법: CWD를 홈 디렉터리(~)로 변경하면, 해당 파일이 로드되지 않는다.
최적화 전: ~36,700자 (~10,000 토큰)
최적화 후: ~16,400자 (~5,000 토큰)
절감률: 약 50%
이것이 2026년 AI 에이전트 비용 최적화의 핵심 트렌드와 맞물린다. 최근 연구에 따르면, 최적화되지 않은 프로덕션 에이전트의 세션당 비용은 $10~$100 이상이며, RAG, 모델 라우팅, 프롬프트 캐싱 전략을 결합하면 80% 이상 비용을 절감할 수 있다.2
Anthropic도 최근 "효과적인 컨텍스트 엔지니어링" 가이드에서 이렇게 강조했다:
"토큰 최적화는 근본적으로 프롬프트 단축 문제가 아니라 컨텍스트 엔지니어링 문제다. 대부분의 팀이 토큰을 낭비하는 곳은 비대한 컨텍스트, 유휴 도구 스키마, 오래된 대화 히스토리다."[^3]
IV – Hermes의 진짜 혁신: 스스로 진화하는 스킬 시스템
토큰 낭비 문제와 별개로, Hermes의 아키텍처에는 주목할 만한 혁신이 있다.
GAPA(Generalized Action and Prompt Adaptation) 시스템이다. 15번의 도구 호출마다 에이전트가 자신의 행동을 평가하고 개선한다. 모델 자체를 수정하지 않고 프롬프트만 최적화하는 방식이다.3
복잡한 작업(5회 이상 도구 호출)을 완료하면, 에이전트가 자동으로 스킬 문서를 생성한다. 절차, 주의사항, 검증 단계가 구조화된 마크다운 문서다. 다음에 비슷한 작업이 오면? 처음부터 고민하는 대신 그 스킬을 로드한다.
Nous Research의 벤치마크에 따르면, 자체 생성 스킬을 사용하는 에이전트는 새 인스턴스 대비 연구 작업을 40% 더 빠르게 완료했다.3
하지만 여기서 역설이 등장한다.
스킬이 쌓이면? 5번 레이어의 Skills 인덱스가 계속 커진다. 현재도 80개 이상의 스킬이 5,000자를 차지하고 있다. 스킬의 자기 진화가 곧 프롬프트 비대화로 이어지는 것이다.
pie title Hermes 시스템 프롬프트 토큰 분포
"AGENTS.md (개발가이드)" : 55
"Skills 인덱스" : 14
"MEMORY 스냅샷" : 10
"나머지 6개 레이어" : 21
V – 당신의 AI 에이전트에 적용하는 3가지 원칙
Hermes의 분석에서 추출한 실전 원칙이다. Claude Code, Cursor, 또는 어떤 AI 에이전트를 사용하든 동일하게 적용된다.
| 원칙 | 설명 | 효과 |
|---|---|---|
| 모듈식 로딩 | 사용 맥락에 따라 프롬프트를 선택적으로 로드. 개발자용/사용자용 분리 | 토큰 40~55% 절감 |
| 선택적 도구 로딩 | 51개 중 30개만 로드하는 Hermes 방식. 필요한 도구만 활성화 | 도구 스키마 토큰 41% 절감 |
| 스킬 가지치기 | 자동 생성된 스킬 중 중복/구식 스킬 정기 정리 | 인덱스 비대화 방지 |
최근 한 개발자는 RAG와 프롬프트 최적화를 결합해 LLM 토큰 비용을 90% 줄인 사례를 공유했다.4 Redis의 분석에 따르면 프롬프트 캐싱만으로도 입력 토큰의 90% 할인, 지연 시간 85% 감소가 가능하다.5
핵심은 이것이다: 프롬프트를 짧게 쓰는 것이 아니라, 맥락을 현명하게 관리하는 것.
💭 이 글을 읽고 생각해볼 질문
-
모듈식 토큰 구성과 프롬프트 레이어 최적화가 AI 에이전트의 메모리-정체성 스냅샷 로딩 프로세스를 어떻게 개선할 수 있을까?
-
AI 에이전트의 자기 진화 스킬 시스템이 프롬프트 비대화를 초래할 때, 성능 유지와 토큰 효율성 사이의 최적 균형점은 어디인가?
-
서로 다른 플랫폼(Telegram, Discord, CLI)에서의 컨텍스트 엔지니어링 전략은 어떻게 달라져야 하는가?
댓글로 당신의 생각을 공유해주세요.
결론: 프롬프트 엔지니어링의 다음 단계는 '덜어내기'다
모든 사람이 프롬프트에 더 많은 것을 넣으려 한다. 더 정교한 역할 지정, 더 많은 예시, 더 상세한 지시.
하지만 Hermes의 해부가 보여주는 진실은 정반대다.
10,000 토큰의 시스템 프롬프트 중 절반은 필요 없었다. 한 줄의 설정 변경으로 50%를 줄일 수 있었다. 그리고 그 결과 에이전트의 성능은 오히려 개선되었다.
2026년 프롬프트 엔지니어링의 본질은 더 이상 "무엇을 넣을까"가 아니다. "무엇을 뺄까"다. Anthropic이 '컨텍스트 엔지니어링'이라는 새로운 이름을 붙인 이유가 바로 이것이다.6
"최고의 시스템 프롬프트는 가장 긴 프롬프트가 아니다. 그 순간에 정확히 필요한 것만 담은 프롬프트다."
Sources
이 글이 도움이 되셨다면, 한 명의 친구에게 공유해주세요.*