AI Agent Layered Architecture

배경

AI 시스템에서 말하는 Layer는 복잡한 시스템을 역할과 책임 단위로 나눈 층을 의미한다. 신경망 내부의 attention layer나 feed-forward layer를 말할 때도 있지만, AI 애플리케이션이나 에이전트 구조에서는 보통 시스템 아키텍처의 책임 분리를 뜻한다.

플랫폼 엔지니어 관점에서는 LLM 하나만 보는 것이 아니라, 모델을 둘러싼 인터페이스, 오케스트레이션, 메모리, 검색, 도구 실행, 저장소, 관측성까지 함께 봐야 한다.

AI Application = Model + Orchestrator + Memory + Retrieval + Tools + Storage + Serving + Observability

---

Layer의 일반적인 의미

Layer는 다음과 같은 목적을 가진다.

1. 복잡한 시스템을 역할별로 나눈다.
2. 각 층이 자기 책임만 담당하게 한다.
3. 아래쪽 구현 세부사항을 위쪽에 숨긴다.
4. 위쪽에는 단순한 인터페이스를 제공한다.
5. 장애가 났을 때 어느 층의 문제인지 분리해서 볼 수 있게 한다.

예를 들어 네트워크 OSI 7 Layer는 물리 계층, 데이터링크 계층, 네트워크 계층, 전송 계층 등으로 통신 책임을 나눈다. AI 시스템에서도 같은 방식으로 모델, 메모리, 검색, 실행, 저장소의 책임을 나눠 이해할 수 있다.

---

AI에서 Layer가 쓰이는 주요 문맥

1. 신경망 내부 Layer

모델 내부 계산 단계로서의 layer다.

Input embedding
↓
Transformer block
  - self-attention
  - feed-forward network
↓
Output head

이때 layer는 모델 내부의 계산 구조를 의미한다.

2. AI Application Architecture Layer

LLM 애플리케이션이나 에이전트 시스템을 구성하는 역할별 층이다.

User Interface Layer
Orchestration Layer
Memory Layer
Retrieval Layer
Tool Execution Layer
Model Serving Layer
Storage Layer
Observability Layer

Honcho, Obsidian, llm_wiki, bge-m3, pgvector 같은 구성 요소는 이 관점에서 각각 다른 layer 또는 component에 속한다.

---

현재 Hermes / Codex 구조에 대응하기

현재 로컬 AI 에이전트 구조를 layer로 보면 다음과 같이 볼 수 있다.

[Interface Layer]
Discord
 
[Orchestration Layer]
Codex / Hermes Agent
 
[Memory Layer]
Honcho, Hermes file-backed memory, session memory
 
[Knowledge Base Layer]
Obsidian / llm_wiki / mominWiki
 
[Retrieval & Embedding Layer]
bge-m3, pgvector
 
[Tool Execution Layer]
terminal, file, browser, Docker, Git, Kubernetes CLI 등
 
[Model Serving Layer]
OpenAI Codex backend, local Ollama, subagent model
 
[Storage Layer]
Markdown files, Postgres/pgvector, Docker volumes, local filesystem

이 구조에서 LLM은 전체 시스템 중 하나의 component일 뿐이다. 실제 에이전트 시스템은 여러 layer가 조합되어 동작한다.

---

Honcho와 llm_wiki의 관계

Honcho

Honcho는 Memory Layer에 가깝다.

역할은 다음과 같다.

- 사용자 선호 저장
- 대화 맥락 회상
- 중요한 conclusion 검색
- 에이전트가 답변 전 참고할 개인화 메모리 제공

예를 들면 다음과 같은 내용이 Honcho에 어울린다.

사용자는 플랫폼 엔지니어다.
사용자는 로컬 AI를 통해 AI stack flow를 직접 이해하려 한다.
Kubernetes 활용과 구조 분석 역량이 중요하다.
경력 표현에서는 아키텍처 설계 주도라고 과장하지 않는다.

Honcho는 사람이 읽는 문서 저장소라기보다는, 에이전트가 대화 중 빠르게 기억을 꺼내 쓰기 위한 검색 가능한 메모리다.

llm_wiki / Obsidian

llm_wiki와 Obsidian은 Knowledge Base Layer에 가깝다.

역할은 다음과 같다.

- 사람이 읽을 수 있는 기술 문서 작성
- 긴 분석 내용 보존
- 프로젝트/경력/실험 기록 정리
- wikilink, index, log를 통한 지식 연결
- source of truth 역할

예를 들면 다음과 같은 내용이 llm_wiki/Obsidian에 어울린다.

EKS DR 자동화 Lambda 구조 분석
Kubernetes RBAC / aws-auth 권한 분석
Honcho + pgvector + bge-m3 로컬 메모리 구조
LLM-on-Kubernetes 실험 기록
경력_프로젝트_종합정리.md

---

둘의 차이를 한 문장으로 정리

Obsidian / llm_wiki = 상세 원본 문서 저장소
Honcho = 에이전트가 빠르게 떠올리는 요약 기억과 검색 인덱스

또는 플랫폼 관점으로 보면 다음과 같다.

Obsidian / llm_wiki = PersistentVolume에 가까운 상세 데이터
Honcho = 검색 가능한 metadata/cache에 가까운 memory index

PV만 있으면 원본은 안전하지만 매번 전체를 찾아봐야 한다. 반대로 cache/index만 있으면 빠르게 찾을 수 있지만 상세 원본과 출처가 부족하다. 그래서 둘은 서로 대체 관계가 아니라 보완 관계다.

---

bge-m3와 pgvector의 위치

bge-m3는 Embedding Layer의 component다.

역할은 텍스트를 벡터로 바꾸는 것이다.

텍스트
→ bge-m3
→ 1024차원 embedding vector
→ pgvector 저장

pgvector는 Vector Storage / Index Layer에 가깝다.

역할은 다음과 같다.

- embedding vector 저장
- query vector와 기존 vector 사이의 거리 계산
- 관련 conclusion/document 검색

즉 bge-m3가 기억을 직접 판단하거나 대화를 스스로 낚아채는 것은 아니다. Hermes/Honcho가 저장하기로 한 텍스트를 bge-m3가 검색 가능한 벡터로 변환하는 구조다.

---

Layer와 Component의 차이

둘은 비슷하지만 다르다.

Layer

역할이나 책임 단위다.

Memory Layer
Embedding Layer
Storage Layer
Orchestration Layer
Knowledge Base Layer

Component

그 역할을 수행하는 구체적인 부품이다.

Honcho
bge-m3
pgvector
Obsidian
Codex
Ollama
Docker

예를 들면 다음과 같다.

Memory Layer = Honcho + Hermes memory + session memory
Embedding Layer = bge-m3
Knowledge Base Layer = Obsidian + llm_wiki
Orchestration Layer = Codex / Hermes Agent

---

장애 분석 관점

Layer를 나누면 문제를 분리해서 볼 수 있다.

검색 결과가 이상하다
→ embedding model 품질 문제인가?
→ pgvector dimension이 맞지 않는가?
→ Honcho conclusion이 저장되지 않았는가?
→ 원본 문서가 부정확한가?

답변 스타일이 이상하다
→ Codex prompt 문제인가?
→ Hermes memory 문제인가?
→ skill이 오래되었는가?
→ Honcho에서 잘못된 context를 recall했는가?

도구 실행이 실패한다
→ Tool Execution Layer 문제인가?
→ 권한 문제인가?
→ shell/runtime 차이인가?
→ Docker/Kubernetes 환경 문제인가?

이렇게 보면 AI 시스템도 일반적인 플랫폼 시스템처럼 layer별로 관찰하고 디버깅할 수 있다.

---

Kubernetes로 확장해서 보기

로컬에서 이해한 AI layer는 나중에 Kubernetes에 올릴 때 다음처럼 매핑할 수 있다.

Interface Layer
- Discord Gateway Deployment
 
Orchestration Layer
- Hermes/Codex Agent Deployment
 
Memory Layer
- Honcho API Deployment
- Honcho Deriver Worker
 
Embedding / Model Serving Layer
- Ollama, vLLM, KServe, Text Embeddings Inference
- GPU NodePool
 
Vector Storage Layer
- Postgres + pgvector StatefulSet 또는 managed database
 
Knowledge Base Layer
- Obsidian sync, Git repo, object storage, PVC
 
Observability Layer
- Datadog, Prometheus, Grafana, OpenTelemetry

이 관점에서 로컬 AI 실험은 단순히 모델을 돌려보는 것이 아니라, AI platform architecture를 layer별로 직접 구성하고 관찰하는 작업이다.

---

정리

AI에서 말하는 layer는 문맥에 따라 모델 내부 계산층을 뜻할 수도 있고, AI 애플리케이션의 시스템 책임층을 뜻할 수도 있다.

현재 Hermes/Codex/Honcho/Obsidian 구조에서 말하는 layer는 후자다.

Codex = Orchestration Layer
Honcho = Memory Layer
llm_wiki / Obsidian = Knowledge Base Layer
bge-m3 = Embedding Layer
pgvector = Vector Storage / Index Layer
Ollama = Local Model Serving Layer
terminal/file/browser tools = Tool Execution Layer
Discord = Interface Layer

핵심은 다음과 같다.

LLM 자체는 AI 시스템의 한 부분이고, 실제 AI agent system은 여러 layer가 조합되어 동작한다.

플랫폼 엔지니어 관점에서는 모델 성능만 보는 것이 아니라, 각 layer의 책임, 저장소, 검색 방식, 장애 지점, 교체 가능성, 운영 비용, Kubernetes 배포 구조까지 함께 봐야 한다.