연재 「프롬프트로 읽는 AI 에이전트」 제12회 (제10장).

전 12회 완결·최종회입니다.

실재하는 3가지 AI 에이전트 OSS를 실제 코드와 실제 프롬프트를 원전에서 인용하며 분석하고,

최종적으로 「스스로 AI 에이전트를 만들 수 있는」 상태를 목표로 해온 연재의 총괄 장입니다.

지금까지 읽은 것 ―― 연재의 회고

12회에 걸쳐 3가지 AI 에이전트 OSS를 원전의 코드와 프롬프트로 해부해 왔습니다. 제0장에서 제시한 지도에는 이렇게 적었습니다 ―― 「AI 에이전트에는 **실행형 (Execution-type)**과 **학습형 (Learning-type)**이라는 근본적으로 다른 두 가지 세계관이 있으며, 본 연재는 3가지 교재(실행형 2 + 학습형 1)로 그 양쪽을 풀어낸다」(제0장 참조). 제1부(제16.5장)가 실행형 2종의 횡단적 해부, 제2부(제79장)가 학습형 1종의 독립적 해부, 그리고 본 장(제10장)이 3자를 하나의 축으로 다시 세우는 총괄입니다.

제1부에서는 agent-zero와 Hermes를 **루프(Loop)·인격(Persona)·도구(Tool)·기억(Memory)·분업(Division of Labor)·자기 개선(Self-improvement) + 안전(Safety)·외부 연결(External Connection)**이라는 7가지 기둥으로 나란히 펼쳐, 각각의 설계 차이를 하나씩 추출했습니다. 제1장에서 Reason–Act–Observe의 최소 루프를 쓰고, 제2장에서 prompts/*.md와 SOUL.md의 인격 외재화를 읽고, 제3장에서 {{tools}} 주입과 function-calling 스키마를 나란히 배치하며, 제4장에서 동결 스냅샷인 MEMORY.md와 벡터 자동 recall을 대조하고, 제5장에서 call_subordinate의 재귀적 위임과 kanban의 비동기 분업을 비교하며, 제6장에서 behaviour_adjustment와 포크형 백그라운드 리뷰, 그리고 <untrusted_tool_result>의 아키텍처적 방어를 읽고, 제6.5장에서 MCP를 통한 외부 연결의 동형화 전략을 살펴보았습니다.

제2부에서는 세계관을 일단 전환하여 Agent0를 독립적으로 다루었습니다. 제7장에서 「행동을 쓰는 것」이 아니라 「가중치를 학습시키는 것」을 선택하는 동기(Zero Data / Co-Evolution / Tool Integration)와 적용 조건을 정리하고, 제8장에서 출제자(Curriculum Agent)와 해답자(Executor Agent)의 공진화와 「프롬프트로 보상을 만드는」 min(p, 1-p)의 볼록 함수를 읽고, 제9장에서 자기 라벨링(다수결에 의한 유사 정답)과 GRPO/ADPO를 통한 가중치 업데이트 루프를 열었습니다. 제6장의 「실행형의 자기 개선 = 텍스트 쓰기 변경」과 제9장의 「학습형의 자기 개선 = 경사(Gradient)에 의한 파라미터 텐서 업데이트」가 동일한 "self-improvement"라는 단어로 완전히 다른 메커니즘을 가리키고 있다는 점 ―― 이것이 제2부의 가장 날카로운 단면이었습니다.

본 장은 그 전체를 하나의 보조선으로 관통합니다. 연재 제목에 내건 「프롬프트로 읽는다」의 진의 ―― 「프롬프트가 무엇을 담당하는가」라는 하나의 질문을 축으로 3자를 대조하면 설계의 급소를 놀라울 정도로 꿰뚫어 볼 수 있다 ―― 를 여기서 회수합니다.

하나의 보조선 ―― 「프롬프트가 무엇을 담당하는가」

제0장에서 연재 제목의 이유를 다음과 같이 적었습니다(제0장 참조).

에이전트의 소스 코드를 열면 방대한 파일에 압도됩니다. 하지만 「이 프레임워크에서는 프롬프트가 무엇을 담당하고 있는가?」라는 하나의 질문을 축으로 읽으면 설계의 급소를 놀라울 정도로 꿰뚫어 볼 수 있습니다.

제1~9장까지 통독한 지금, 이 보조선이 3자에서 완전히 다른 그림을 그려낸다는 것을 알 수 있을 것입니다.

agent-zero: 프롬프트는 「모든 거동의 정의서」. 인격·행동 규범·응답 계약·도구 목록·자기 개선 대상(behaviour.md)까지, prompts/*.md라는 텍스트 파일군이 에이전트의 모든 거동을 외재화한다. 코드를 수정하지 않고 텍스트를 편집하는 것만으로 에이전트의 성격이 변하며, 그 순도가 높다는 점이 agent-zero를 교재로서 흥미롭게 만든다(제2장·제3장·제6장 참조).

Hermes: 프롬프트는 「동적으로 합성되는 행동 규범 + 도구 제시」. 변화 빈도에 따라 stable/context/volatile의 3층으로 분류하며, SOUL.md(인격)와 MEMORY.md/USER.md(기억), 그리고 조건부 가이던스(MEMORY_GUIDANCE・TASK_COMPLETION_GUIDANCE...

등)을 **코드 내에서 동적 합성(Dynamic Synthesis)**한다. 툴은 function-calling의 tools= 인수로 별도 채널을 제시한다. 프리픽스 캐시(Prefix Cache)를 보호하기 위해 **바이트 안정성(Byte Stability)**까지 설계에 반영된, 장기 운용을 위한 프롬프트 기반(제2장·제3장·제4장 참조).

Agent0: 프롬프트는 "보상을 생성하는 출력 계약(Output Contract)"이다. <question>...</question>과 \boxed{final_answer}라는 출력 태그가 후속 정규 표현식(re.findall(r"<question>(.*?)</question>", ...) 및 extract_boxed_content(...))과 1대 1로 맞물려, 보상 함수의 자동 채점을 성립시키는 **훈련 장치(Training Device)**가 된다. 동일한 "응답 계약"이라는 용어가 실행형에서는 루프의 디스패치(Dispatch)에, 학습형에서는 보상의 자동 채점에 사용된다 (제7장·제8장·제9장 참조).

본 장의 주인공은 이 세 가지 그림을 하나의 대조표에 나열하는 것입니다. 표의 셀은 구체적인 기구(Mechanism)의 이름과 장 번호로 채우고, 본문은 "그것을 구분하여 사용하는 독자의 설계 판단 축"을 작성합니다. 새로운 사실은 도입하지 않습니다. 제1~9장에서 확정된 사실만으로 세 가지를 다시 나열합니다.

3자 대조표 ―― 프롬프트의 역할을 축으로 한 10가지 관점

연재 전체의 관찰을 10가지 관점으로 나열합니다. 각 셀에는 구체적인 기구의 이름과 근거가 되는 장 번호를 붙였습니다. 출처의 원전 파일명이나 커밋 해시(Commit Hash)는 전 장에서 다루었으므로, 본 장에서는 재인용하지 않습니다 ―― 장 번호를 참고하여 필요에 따라 거슬러 올라가 읽어주시기 바랍니다.

표 1: 프롬프트의 소재와 역할

여기서 첫 번째 판단 축이 보입니다 ―― **프롬프트를 "텍스트 1차원"으로 외재화할 것인가, "코드 내에서 동적 합성할 것인가"**입니다. agent-zero는 텍스트 순도를 우선하여 {{ include }}만으로 합성을 완결하는 방식입니다. Hermes는 동일한 외재화 방식을 따르면서도, 운용상의 제약(프리픽스 캐시·툴 구분 제시)을 위해 코드 측에서 동적 합성하는 방식입니다. Agent0는 애초에 목적이 다르므로 "인간이 읽고 쓰는 하나의 시스템 프롬프트"를 정비하는 문제가 아니라, 훈련할 때마다 동일한 문면이 재사용되는 형태 (dataset.py와 question_generate.py에서 바이트 일치)가 됩니다 (제8장 참조).

표 2: 기억·다중 에이전트·자기 개선

두 번째 판단 기준 ―― "다음 회차를 위한 학습"을 텍스트로 다시 쓰는가, 아니면 가중치로 다시 쓰는가. 실행형 2종 (agent-zero / Hermes)이 "세션 중/후에 텍스트를 교체하는" 두 방향으로 나뉘어 있는 반면, Agent0는 차원 자체를 바꾸어 파라미터 텐서 (Parameter Tensor)의 값을 교체하는 세계로 나아갑니다. 제6장 끝에서 예고하고 제9장에서 회수했던 이 단면이 본 표의 "자기 개선" 행에 응축되어 있습니다. 중요한 것은, 학습형은 실행형의 상위 호환이 아니라는 점입니다 (제7장 참조). 텍스트 교체와 가중치 업데이트는 교체 대상도, 필요한 인프라도, 실패 시의 복구 방식도, "개선이 적용되는" 시점도 모두 다른 두 가지 메커니즘입니다 (제9장 E절의 대비표 참조).

표 3: 도구 · 도메인 · 적용 조건

```. ... 마지막 부분은 \boxed{...}와 같습니다.

마찬가지입니다. 프롬프트는 **훈련 롤아웃(rollout)에서 어떤 일이 일어날지를 결정하는 포맷 계약(format contract)**이지, 사용자에게 보여줄 "인격"을 결정하기 위한 것이 아닙니다.

그리고 동일한 문구가 dataset.py (훈련 시의 롤아웃)와 question_generate.py (훈련 후의 데이터 생성 배치)에서 **바이트 단위로 일치(byte-identical)**하게 재사용됩니다 (제8장 참조). "훈련을 통해 습득시킨 행동"을 그대로 "데이터 생성 시 발휘하게 만들기" 위해, 프롬프트는 계약으로서 고정되어 있습니다. 프롬프트가 "제품의 설정"도 "운용의 호적"도 아닌, "강화학습 (RL)의 입출력 포맷과 보상(reward)의 자동 채점을 성립시키는 틀"이 되어 있다는 것 ―― 이것이 Agent0의 프롬프트를 읽는 법입니다.

3가지 세계관을 한 줄로

세 가지를 각각 한 줄로 압축하면 다음과 같습니다.

• agent-zero: 프롬프트는 "모든 거동의 정의서" (prompts/*.md를 통해 거동을 외재화하는 설정 파일).
• Hermes: 프롬프트는 "동적으로 합성되는 행동 규범 + 도구 제시" (stable/context/volatile의 3층 구조와 API의 tools= 인수의 이중 구조).
• Agent0: 프롬프트는 "보상을 만들어내는 출력 계약" (<question>과 \boxed{}를 통해 보상 함수와 맞물리는 훈련 장치).

동일한 "프롬프트"라는 단어가 세 대상 사이에서 이토록 다른 역할을 수행하고 있습니다. 제0장에서 제시했던 보조선이, 여기까지 읽어온 덕분에 비로소 구체적인 형상을 갖추게 되었습니다.

자작을 위한 설계 판단 축 ―― 당신이 선택할 4가지 분기

지금까지의 대조를 바탕으로, 본 장의 또 다른 목표인 ―― 독자가 직접 만들 때의 설계 판단 축을 4가지 분기 형태로 정리합니다. 연재를 통해 독자가 가질 수 있었던 선택지들을 이 장에서 다시 정렬합니다.

분기 ①: 당신이 만들고 싶은 것은 "실행형"인가 "학습형"인가

첫 번째 분기입니다. 제7장에서 보았듯이, 학습형은 실행형의 상위 호환이 아니라, 목적과 전제가 다른 병존하는 별개의 해법입니다 (제7장 참조). 당신이 해결하고자 하는 문제가 다음 중 어디에 속하느냐에 따라 이후의 모든 판단이 달라집니다.

• 실행형을 선택하는 조건: API를 통한 독점 모델 (Claude / GPT 등)에서도 구동하고 싶다, 대화·운용 작업·자유 문장을 다루고 싶다, 노트북 + API 키만으로 시작하고 싶다 ―― 이 중 하나라도 해당한다면 실행형입니다. 제1~6.5장에서 구축한 최소 구현의 연장선상에서 만들 수 있습니다.
• 학습형을 선택하는 조건: 자동 채점이 가능한 좁고 깊은 추론 도메인 (수학·코드·일반 추론)으로 한정할 수 있다, GPU 클러스터 (8GPU 이상)와 훈련 인프라를 준비할 수 있다, 가중치에 접근 가능한 오픈 웨이트 모델 (Qwen3-4B-Base / Qwen3-8B-Base ...)

등)을 기점으로 할 수 있습니다 ―― 이 세 가지 조건을 모두 만족한다면 학습형 (Learning-based)을 검토할 가치가 있습니다. 제7장, 제8장, 제9장을 참조하십시오.

망설여질 때는 "나의 태스크는 자동 채점이 가능한가?"를 가장 먼저 묻는 것이 지름길입니다. "고객에게 메일 쓰기", "논문 요약 쓰기", "상사에게 상담하기"와 같이 출력의 좋고 나쁨을 수치로 자동 채점하기 어려운 태스크는, 현시점에서는 실행형 (Execution-based)이 무난합니다 (제7장 「적용 조건」 참조).

분기 ②: 프롬프트를 "외재화"할 것인가 "코드 내에서 동적 합성"할 것인가

실행형을 선택했을 경우, 다음에 오는 것이 이 분기입니다.

• agent-zero 방식 (텍스트 외재화)을 선택하는 조건: 프롬프트 편집만으로 거동을 바꾸고 싶다 (코드 변경을 거치지 않고, 파일을 수정하는 것만으로 재시작도 불필요), 관심사 (인격·규범·통신 규약·문제 해결 절차)별로 파일을 분할하고 싶다, 새로운 툴은 파일을 배치하는 것만으로 등록하고 싶다 ―― 이 중 하나라도 해당한다면 agent-zero 방식입니다. {{ include }}의 재귀적 전개와 {{tools}} 플레이스홀더(Placeholder)로 합성이 완결됩니다 (제2장·제3장 참조).

• Hermes 방식 (코드 내 동적 합성)을 선택하는 조건: 프리픽스 캐시 (Prefix Cache)를 활용하기 위해 바이트 안정성 (Byte Stability)을 엄격하게 관리하고 싶다, 툴에 따라 조건부로 가이던스 (Guidance)를 주입하고 싶다, 프로필 (profile)마다 별도의 HERMES_HOME (config·메모리·스킬)으로 동적으로 전환하고 싶다 ―― 이 중 하나라도 해당한다면 Hermes 방식입니다. build_system_prompt_parts를 통해 stable/context/volatile을 구성하는 스타일이 됩니다 (제2장 참조).

어느 쪽이 정답이라는 이야기가 아니라, 무엇을 최적화하고 싶은가에 따라 결정됩니다. 인간의 편집 용이성을 최우선으로 한다면 agent-zero, LLM API의 운용 비용과 장기 세션을 최우선으로 한다면 Hermes입니다. 양쪽의 장점을 모두 취할 수도 있습니다 ―― 예를 들어 인격은 SOUL.md에 외재화하면서, 3층 구조로 재배열하는 하이브리드 방식입니다.

분기 ③: 자기 개선은 "텍스트 쓰기"인가 "가중치 업데이트"인가

제6장에서 보았듯이, 실행형의 자기 개선은 텍스트 쓰기에 국한됩니다. 가중치는 단 1비트도 움직이지 않습니다 ―― 이것이 제1부의 마침표였습니다. 학습형을 선택한 경우에는 자기 개선 = 가중치 업데이트가 됩니다.

• agent-zero 방식 (대화 중에 즉시 쓰기): 사용자의 지적을 behaviour_adjustment를 통해 즉시 behaviour.md에 머지(Merge)하고, 다음 턴의 BehaviourPrompt.execute가 시스템 프롬프트 선두에 주입하는 폐쇄 루프 (Closed-loop). 즉각적인 반영이 필요하거나, 학습의 기준을 "대화의 흐름 속에서 판단하게 하고 싶다"면 이 방식입니다 (제6장 참조).

• Hermes 방식 (턴 이후의 포크형 백그라운드 리뷰): _spawn_background_review로 데몬 스레드 (Daemon Thread)를 일으켜, _MEMORY_REVIEW_PROMPT / _SKILL_REVIEW_PROMPT를 자기 자신에게 묻게 합니다. 툴 화이트리스트 (Whitelist)로 개입을 물리적으로 제한하고, 큐레이터 (Curator) 패스로 엄브렐러화 (Umbrella-ization) 합니다. 학습의 기준을 명시적으로 프롬프트에 규정하고 싶거나, 메인 세션에 영향을 주고 싶지 않다면 이 방식입니다 (제6장 참조).

• Agent0 방식 (가중치 업데이트): GRPO로 출제역을, ADPO로 해답역을 업데이트합니다. 자동 채점이 가능한 도메인에서, GPU 클러스터를 투입할 수 있다면 이것이 제3의 선택지가 됩니다 (제9장 참조).

세 가지 선택지를 나열했을 때 중요한 것은, 모두 "자신의 거동을 개선한다"는 동일한 목적을 가지고 있지만, 바꾸는 대상이 다르다는 점입니다 (제9장 E절의 대비표를 참조하십시오). 텍스트 쓰기와 가중치 업데이트는 충돌하지 않으며, 서로 다른 계층에서 서로 다른 효과를 발휘합니다.

분기 ④: 툴은 "프롬프트 임베딩"인가 "API 인자"인가

제3장에서 보았듯이, 툴을 제시하는 데에는 두 가지 경로가 있습니다.

• agent-zero 방식 (프롬프트 임베딩): .md 설명서를 {{tools}} 플레이스홀더에 모아서 흘려 넣습니다. 모델의 펑션 콜링 (Function-calling) 대응 여부에 의존하지 않고, .md 문구 하나만으로 제시를 완전히 제어할 수 있습니다. 인자의 타입 체크는 LLM의 해석에 맡깁니다 (json_parse_dirty...

느슨하게 파싱(Parsing) (제3장 참조). -
Hermes 스타일 (API 인자): JSON function-calling 스키마로 정의하고, tools= 인자에 register()로 중앙 레지스트리에 모은 뒤, check_fn으로 필터링하여 API의 tools= 인자에 전달합니다. 타입, 필수 여부, 범위를 기계적으로 선언할 수 있으며, check_fn을 통해 "환경적으로 사용할 수 있는 도구만", toolset을 통해 "이 상황에 필요한 도구만" 제시할 수 있습니다. 대신, function-calling 지원 모델과 레지스트리 메커니즘이 전제되어야 합니다 (제3장 참조).

제1장에서 살펴본 응답 형식 및 종료 조건의 설계 차이는 사실 이 제시 형식의 선택에서 비롯되었습니다 (제3장 「두 존재의 대조」 참조). 도구의 제시 방법은 에이전트 전체 설계를 관통하는 하나의 축이며, 이곳을 결정하면 루프의 종료 판정(도구 호출 여부로 판정 / 전용 도구로 break_loop)까지 연동됩니다.

4가지 분기를 조합하기

4가지 분기는 독립적으로 결정할 수 있습니다. 예를 들어 "실행형 · 텍스트 외재화 · 대화 중 즉시 재작성 · 프롬프트 임베딩"을 선택하면 agent-zero에 가장 가까운 구성이 되고, "실행형 · 코드 내 동적 합성 · 턴 이후의 포크 리뷰 · API 인자"를 선택하면 Hermes에 가까운 구성이 됩니다. 하지만 4가지를 다른 조합으로 선택할 수도 있습니다. 예를 들어 "실행형 · 텍스트 외재화 · 턴 이후의 리뷰 · API 인자"와 같이 말이죠. 연재를 통해 독자가 세울 수 있었던 선택지의 총정리가 바로 이 4가지 분기입니다.

연재 통독 후의 최소 에이전트 전체상 ―― 제0장의 도표를 업데이트하다

제0장의 마지막에 두었던 "최소 자작 AI 에이전트의 전체상" 도표를 여기서 업데이트합니다. 연재 12회를 모두 읽은 독자가 지금 바로 조립할 수 있는 모습입니다. 새로운 부품은 하나도 추가하지 않습니다. 제0~9장에서 준비한 7가지 부품의 연결 맵만을 보여줍니다.

연재 통독 후의 최소 에이전트 전체상
(실행형을 선택할 경우 ―― 제1부의 연장선으로서 조립)
┌──────────────────────────────────────────────────────────────┐
...

연재 통독 후의 최소 에이전트 전체상
(학습형을 선택할 경우 ―― 제2부의 독립된 세계로서 조립)
함수 self_evolving_loop(num_iterations):
...

실행형 도표는 제0장의 "목표상" 의사 코드(제0장 말미 참조)에 제6장의 리뷰와 미신뢰 관측의 포장, 제6.5장의 MCP를 더한 것입니다. 학습형 도표는 제7장에서 예고한 의사 코드(제7장 말미 참조)를 제8장·제9장의 구체화(프롬프트와 보상 함수의 대응, 자기 라벨링, GRPO/ADPO)로 채운 것입니다.

실행형을 선택하는 독자는 위의 도표를, 학습형을 선택하는 독자는 아래의 도표를 각각 다시 조립하여 자신의 환경에서 구동할 수 있습니다. 연재 12회의 목표는 바로 이것이었습니다. 연재 통독 시 자작 경로의 일관성(수용 조건 D-1)이 이 두 장의 도표에 집약됩니다.

연재를 마치며

12회의 연재를 통해 AI 에이전트를 만드는 3가지 세계관을 살펴보았습니다.

agent-zero는 prompts/*.md라는 텍스트 파일군을 통해 에이전트 본인의 모든 거동을 외재화하는 세계. Hermes는 stable/context/volatile의 3층 프롬프트와 영속 메모리, kanban, profile로 장기 운용을 지원하는 세계. Agent0는 출제자와 정답자의 공진화와 GRPO/ADPO를 통해 가중치 그 자체를 써 내려가는 세계. 이 세 가지 세계는 목적도, 전제도, 인프라도 다릅니다. 공통점은 모두 "프롬프트란 무엇을 담당하는 것인가"를 설계 판단의 중심에 두고 있다는 점입니다.

제0장에서 제시했던 보조선 ―― "프롬프트가 무엇을 담당하는가"라는 하나의 질문 ―― 은 여기까지 읽어 내려온 후에야 비로소 구체적인 형상을 맺었습니다. 프롬프트는 agent-zero에서는 설정 파일, Hermes에서는 동적으로 합성되는 행동 규범 + 도구 제시, Agent0에서는 보상을 생성하는 출력 계약입니다. 같은 "프롬프트"라는 단어가 세 존재 사이에서 완전히 다른 역할을 수행하고 있습니다. 이 사실을 자신의 손으로 구동할 수 있는 의사 코드까지 포함하여 받아들인 당신은, 이제 "AI 에이전트란 무엇인가"라는 첫 번째 질문에 답할 수 있을 것입니다.

지금의 독자라면 당신이 만들고 싶은 에이전트를 디자인할 수 있습니다. 실행형(Execution-based)인가 학습형(Learning-based)인가, 텍스트 외재화(Text Externalization)인가 동적 합성(Dynamic Synthesis)인가, 텍스트 재작성(Text Rewriting)인가 가중치 업데이트(Weight Update)인가, 프롬프트 임베딩(Prompt Embedding)인가 API 인자(API Argument)인가 ―― 4가지 분기점은 연재를 통해 독자의 머릿속에 나열되어 있을 것입니다. 이것들은 '최선의 선택'이 아니라 '당신의 문제에 따른 선택 축'입니다. 3가지 요소는 교재일 뿐, 정답이 아닙니다.

연재 제목으로 내건 "프롬프트로 읽는 AI 에이전트"는 세 가지 구현 방식을 해설하기 위한 보조선이었습니다. 하지만 다 읽고 난 지금, 이것이 자작을 위한 설계의 언어이기도 했다는 점이 보일 것입니다. 당신이 새로운 에이전트를 설계할 때, 가장 먼저 물어야 할 것은 ―― "이 에이전트에서 프롬프트는 무엇을 담당하는가"입니다. 이 질문에서 시작된다면 루프(Loop)도, 기억(Memory)도, 자기 개선(Self-improvement)도, 도구 제시(Tool Provision)도, 모든 설계 판단이 연동되어 결정됩니다.

12회 동안 함께해 주셔서 감사합니다. 연재는 여기서 완결되지만, 당신의 에이전트는 이제부터 시작입니다. 원본 코드는 모두 GitHub에 있으며, 제1~9장에서 확인한 사실들은 당신의 손끝에서 재현될 수 있습니다. 다음에 읽어야 할 것은 바로 당신 자신의 에이전트 코드일 것입니다.

―― 연재 「프롬프트로 읽는 AI 에이전트」 전 12회 완

Discussion