전체 시스템 청사진 업데이트 + 통합 모니터링 적용안

1. 어제 작업이 어디까지 진행됐는지

확인 결과, 어제 작업은 초안 2개 작성 단계까지 진행됨.

이미 만들어진 문서: - ~/knowledge-agent/800 운영/840 리포트/운영-청사진-2026-04-09.md - ~/knowledge-agent/800 운영/840 리포트/운영도-쉬운설명-2026-04-09.md

진행 상태 판단: - 역할 분담, 기본 흐름, 웹앱 위치, 공유용 설명 문구까지는 정리됨 - 두 문서 모두 frontmatter에 status: draft로 남아 있음 - 오늘 요청한 전체 시스템 관점 통합 모니터링(Claude Code + Codex + Hermes + cmux + 파이프라인) 내용은 아직 반영되지 않음 - 요청한 저장 위치 ~/knowledge-agent/400-reports/에도 아직 없음

즉, 어제는 운영 구조 설명 초안까지 완료, 오늘은 이를 최신 상태와 모니터링 설계까지 확장하는 단계로 보는 것이 맞음.

2. 2026-04-15 06:00 KST 기준 현재 시스템 상태

이 섹션은 blueprint_updater.py에 의해 자동 갱신됩니다.

2-1. 기본 운영 축

OpenClaw = 운영 본체
Claude = 기획·검토 축
Codex = 구현 축
Hermes = 병행 에이전트 스택
knowledge = 원본 볼트 (2,253개 노트)
knowledge-agent = 작업 볼트 (11,140개 노트)
virtual-insanity.net = OpenClaw 파이프라인 웹앱

2-2. 운영 데이터

항목	값
크론 잡	총 295개 (활성 0 / 비활성 295)
bus_commands	0건
ops_todos	0건
에러 장부	미해결 0건 (고위험 0건)
OTel 수집기	가동 중
OTel DB	존재
디스크	205.0GB / 460.4GB (44.5%)

2-3. 볼트 스테이지별 현황

스테이지	노트 수
000 선언	7
100 수신함	557
200 아토믹	4,671
200 정리	38
300 리소스	2
300 지식망	680
400 판단	31
500 시그널	311
600 데이터	10
700 실험실	98
800 운영	128
900 프롬프트	5

볼트 품질 점수: 캡처: 33, 정리: 56, 연결: 41, 판단: 81, 리소스: 0, 활동: 100, 운영: 87, 시스템: 100

2-4. 에이전트 큐 상태

데이터 없음

에이전트 등급: ron: C, codex: A, cowork: B, analyst-fundamental: F, analyst-macro: F, analyst-technical: F

2-5. 크론 에러 현황

없음

2-6. 파이프라인 상태

vault-architect: 2일 전
vault-flow-health: 2일 전

Knowledge Graph Live

이 섹션은 blueprint_updater.py에 의해 graph.json에서 자동 렌더링됩니다.

라이브 링크: https://virtual-insanity.net/graphify/index.html
퍼블릭 파일: ~/.openclaw/workspace/mission-control/public/graphify/index.html
데이터 파일: ~/.openclaw/workspace/mission-control/public/graphify/graph.json
마지막 갱신: 2026-04-12 20:22:45 KST

항목	값
노드 수	8,972
엣지 수	38,034
대상	`~/knowledge-agent/400-reports`
상태	live serving 중

Phase 4 Codex/Hermes/cmux 연결 진행 상황: - Codex 측 graphify 복구 작업 진행에 따라 graph.json의 노드/엣지 수가 갱신됨. - /graphify 퍼블릭 경로는 연결되어 있으며, 외부 링크로 즉시 열 수 있음. - Codex/Hermes/cmux 운영 신호는 OTel/dispatch 체계와 함께 묶여 가시화 기반이 갖춰졌고, Knowledge Graph Live는 그중 지식망 시각화 면을 담당함. - 이 섹션은 자동 갱신이므로 수동 편집하지 말 것. 변경이 필요하면 blueprint_updater.py의 render_kg_live() 수정.

3. 전체 시스템 청사진 v2

flowchart LR
    H[해리]
    C1[Claude Code]
    C2[Codex]
    H1[Hermes]
    X[cmux]
    O[OpenClaw]
    Q[bus_commands / ops_todos]
    P[파이프라인 / cron / workers]
    K1[knowledge]
    K2[knowledge-agent]
    W[virtual-insanity.net]
    M[통합 모니터링 계층]

    H --> X
    X --> C1
    X --> C2
    X --> H1

    C1 --> O
    C2 --> O
    H1 --> O

    O --> Q --> P
    P --> K1
    P --> K2
    P --> W

    C1 --> K2
    C2 --> K2
    H1 --> K2

    C1 --> M
    C2 --> M
    H1 --> M
    X --> M
    O --> M
    P --> M
    W --> M

핵심 해석: - OpenClaw는 여전히 운영 중심축 - Claude/Codex/Hermes는 실행 주체가 다르지만 실제론 cmux 위에서 함께 움직임 - 파이프라인, 큐, 볼트, 웹앱은 OpenClaw 계층에 묶임 - 앞으로는 이 모든 층 위에 통합 모니터링 계층을 덮어야 함

4. Claude Code OpenTelemetry + Monitor 2.1.98를 전체 시스템에 적용하는 방식

4-1. 먼저 확인된 사실

확인된 사실: 1. 로컬 Claude Code는 2.1.98 2. 공식 Claude Code 문서는 OpenTelemetry 기반 monitoring을 지원함 3. 공식 문서상 metrics, logs/events, 그리고 beta traces까지 지원함 4. traces를 켜면 Claude가 실행한 subprocess에 TRACEPARENT가 전달될 수 있음 5. 별도 “Monitor”는 공식 문서보다 커뮤니티 구현체가 명확히 확인됨

정리: - 공식 사실 = Claude Code 2.1.98 + OTel monitoring 지원 - 추론/적용안 = 이 OTel 신호를 OpenClaw 전체 관측면으로 확장 - 커뮤니티 참고 구현 = zcquant/claude-code-monitor 류 대시보드형 수신기

4-2. 적용 원칙

이번 청사진의 핵심은 Claude만 보는 모니터링이 아니라 시스템 전체를 한 흐름으로 보는 것임.

따라서 기준은 아래 3개임: - 세션 단위: 누가 어떤 surface/workspace에서 일을 시작했는가 - 실행 단위: 어떤 프롬프트가 어떤 툴/스크립트/파이프라인을 유발했는가 - 운영 단위: 그 결과가 큐, DB, 볼트, 웹앱, 비용, 실패율에 어떤 흔적을 남겼는가

4-3. 권장 아키텍처

A. 수집층

로컬에 OTel Collector 단일 진입점을 둠.

권장 포트: - OTLP gRPC: 4317 - OTLP HTTP: 4318

역할: - Claude Code telemetry 수집 - Codex telemetry 또는 Codex 로그 수집 - Hermes 로그 수집 - OpenClaw 로그/메트릭 수집 - cmux 상태 스냅샷 수집 - 파이프라인/cron 실행 결과 수집

B. 저장층

신호 종류별 분리 권장: - Metrics: Prometheus 계열 - Logs/Events: Loki 또는 OpenSearch 계열 - Traces: Tempo 또는 Jaeger 계열

이 부분은 이 문서에서 특정 제품 강제보다 신호 분리 원칙이 더 중요함.

C. 시각화층

Grafana 또는 동등 대시보드에서 아래 4개 보드를 분리함: 1. Claude/Codex/Hermes 세션 보드 2. OpenClaw 운영 보드 3. 큐/크론/파이프라인 보드 4. 비용/토큰/실패 상관분석 보드

5. 컴포넌트별 적용안

5-1. Claude Code

현재 확인 상태

버전 2.1.98 확인
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 설정 흔적 있음
하지만 CLAUDE_CODE_ENABLE_TELEMETRY=1은 현재 확인 안 됨
현재 collector도 없음

적용안

telemetry enable 명시
metrics + logs 우선 연결
traces(beta)는 2단계에서 켬
OTEL_RESOURCE_ATTRIBUTES로 최소 아래 태그 추가
system=claude-code
host=mac-mini
role=planning-review
workspace=workspace:1 같은 cmux workspace 식별자
surface=surface:4 같은 surface 식별자

기대효과

세션 시작 수
토큰 사용량
비용
tool execution 결과
prompt 단위 이벤트
terminal type / workspace / user 구분

중요한 확장 포인트

공식 문서상 traces를 켜면 subprocess에 TRACEPARENT 전달이 가능하므로, Claude가 OpenClaw 스크립트를 호출할 때 Claude prompt → Bash → Python script → queue/db 반영을 한 trace로 묶을 수 있음.

이게 이번 통합 청사진의 핵심 연결점임.

5-2. Codex

현재 확인 상태

~/.codex/config.toml에 OTel 블록 존재
analytics 활성
trace_exporter = "none"
OTLP HTTP endpoint가 http://localhost:4318/v1/logs로 잡혀 있음
하지만 실제 collector는 없음

적용안

1차는 native OTel보다 Codex 로그 + existing OTel output을 함께 수집
최소 수집 대상:
~/.codex/log/codex-tui.log
~/.codex/history.jsonl
~/.codex/session_index.jsonl
가능하면 Codex 쪽도 session/thread/turn 단위 필드를 공통 키로 정규화
Claude와 같은 dashboard에서 나란히 비교되도록 태그 통일
system=codex
role=implementation
workspace
surface

기대효과

구현 세션 길이
실패/재시도 패턴
플러그인/모델 경로 문제
작업 turn 수
로그 기반 오류 상관분석

판단: - Codex는 현재 collector만 생기면 바로 일부 신호를 받을 수 있는 절반 연결 상태임.

5-3. Hermes

현재 확인 상태

Hermes config에서 OTel native 설정은 확인 안 됨
대신 아래 로그 자산 존재
~/.hermes/logs/gateway.log
~/.hermes/logs/gateway.error.log
~/.hermes/logs/errors.log
~/.hermes/sessions/*.jsonl

적용안

Hermes는 1차에 filelog receiver 기반 수집으로 붙임
sessions JSONL에서 아래 공통 필드 추출
session id
user/channel
provider/model
tool call 수
에러 여부
2차로 wrapper 스크립트를 둬 custom metrics 추가
session_started_total
tool_calls_total
session_errors_total
provider_latency_ms

기대효과

Hermes를 OpenClaw 바깥 별도 스택이 아니라 같은 observability 평면 위의 병행 스택으로 볼 수 있음

5-4. cmux

현재 확인 상태

다중 workspace/pane/surface 구조가 실제 운영의 실행면
현재는 상태줄과 tree 출력은 있으나 관측 데이터로 축적되지 않음

적용안

cmux는 native OTel 대상이 아니라 운영 컨텍스트 태거로 씀.

주기적 snapshot exporter 추가
cmux tree --all
cmux list-status
cmux list-workspaces
cmux list-surfaces
이 결과를 metrics/logs로 변환
active_workspaces
active_surfaces
claude_surfaces
codex_surfaces
surface_idle_seconds
Claude/Codex 시작 래퍼에서 환경변수 주입
CMUX_WORKSPACE_ID
CMUX_SURFACE_ID
이를 OTEL_RESOURCE_ATTRIBUTES로 변환

기대효과

“누가 어떤 세션에서 어떤 패널에서 돌고 있었는가”가 남음
이후 장애/비용/성능을 surface 단위까지 역추적 가능

5-5. OpenClaw

현재 확인 상태

운영 중심축
knowledge_os.py mcp-check 정상
queue/db/cron/system-digest/service-health 자산 존재
monitoring 폴더에 Prometheus/Grafana 룰 초안 존재
그러나 collector/dashboard 실가동은 아직 아님

이미 있는 관측 자산

system-baseline/latest.json
memory/system-digest/latest.json
/api/evolve/metrics
/api/cost
/api/services/health
SQLite: bus_commands, ops_todos
각종 cron/pipeline 로그

적용안

OpenClaw는 별도 계측보다 기존 자산을 exporter화하는 게 우선
1차 메트릭화 대상
queue depth
queued/done/failed per agent
cron enabled/disabled/error
stale pipeline age
service healthy count
webapp/dashboard response latency
2차 이벤트화 대상
command claim
command done/fail
orchestrator routing
pipeline failure ledger
3차 trace 연결 대상
Claude/Codex가 호출한 OpenClaw scripts
queue claim → worker start → result write → report publish

판단: - OpenClaw는 새 telemetry를 억지로 넣기보다 기존 DB/API/로그를 OTel 규격으로 끌어올리는 게 가장 효율적임.

5-6. 파이프라인 / cron / 웹앱

현재 확인 상태

파이프라인 계층은 이미 광범위한 cron 구조 보유
src/cron/isolated-agent/run.ts에 telemetry 필드 존재 흔적 확인
webapp 프로세스는 떠 있으나 현재 HTTP 즉시 응답 확인은 안 됨

적용안

모든 cron run에 공통 run_id 부여
run_id를 기준으로
시작 시각
종료 시각
성공/실패
출력 파일 수
결과 경로
관련 agent / model
upstream/downstream 대상 를 남김
webapp는 synthetic probe 추가
/
핵심 API
refresh script dry-run
stale detector 추가
마지막 성공 run 기준 N시간 초과 시 경고

기대효과

“파이프라인이 돈다” 수준이 아니라
어느 단계가 병목인지, 어느 브릿지가 끊겼는지, 어떤 보고가 stale인지 바로 보이게 됨

6. 권장 롤아웃 순서

Phase 1 — Collector 먼저

localhost OTel Collector 배치
신호 저장 백엔드 최소형 연결
현재 비어 있는 4317/4318 포트 활성화

Phase 2 — Claude 먼저 연결

Claude telemetry 정식 enable
metrics/logs 우선
traces는 beta로 별도 분리 테스트

Phase 3 — OpenClaw 연결

queue/db/api/system-digest exporter 추가
dashboard, webapp synthetic probe 추가

Phase 4 — Codex/Hermes/cmux 연결

Codex log ingestion + existing otel output 연결
Hermes filelog ingestion 연결
cmux snapshot exporter 연결

Phase 5 — End-to-End trace 실험

Claude → Bash → OpenClaw script → DB/API → webapp 까지 trace 이어보기
여기서 TRACEPARENT 전파를 핵심 가설로 사용

7. 통합 대시보드에 반드시 있어야 할 핵심 지표

A. 세션/사용량

Claude session count
Codex session/thread count
Hermes session count
active surfaces/workspaces

B. 비용/토큰

Claude cost usage
Claude token usage by type
Codex session volume proxy
agent별 모델 사용량

C. 운영/큐

bus queue depth
agent별 queued/done/failed
claim 지연 시간
stale queued command 수

D. 파이프라인/크론

cron success ratio
최근 24시간 실패 잡 수
stale pipeline 수
vault/webapp 브릿지 지연

E. 서비스 헬스

dashboard latency
webapp latency
gateway health
MCP health

F. 품질/리스크

동일 오류 반복 횟수
최근 24시간 error ledger open count
7일 기준 recurring 3+ 에러 수

8. 최종 판단

현재 시스템은 이미 - 운영 축(OpenClaw) - 실행 축(Claude/Codex/Hermes) - 작업면(cmux) - 결과층(볼트/웹앱) 을 갖고 있음.

부족한 것은 관측 축 하나임.

오늘 추가된 Claude Code OTel/Monitor 관점은 단순히 Claude만 보는 용도가 아니라, 이 시스템 전체에 대해 - 누가 시작했고 - 어떤 툴이 호출됐고 - 어떤 파이프라인을 건드렸고 - 어떤 비용과 실패를 만들었고 - 어느 보고/웹앱 결과로 이어졌는지 를 한 흐름으로 묶는 공통 관측 언어로 써야 함.

따라서 해리 시스템의 다음 청사진은 이렇게 정리됨:

OpenClaw가 운영을 조율하고, Claude/Codex/Hermes가 cmux 위에서 실행되며, knowledge/knowledge-agent/webapp으로 결과가 퍼지고, 그 전 과정을 OpenTelemetry 기반 관측 계층이 덮는 구조

이게 이번 버전의 최종 청사진임.

10. Karpathy 방법론 적용 현황

해리 시스템에는 이미 Karpathy식 “LLM이 지식을 읽고, 연결하고, 충돌을 드러내며, 파일 변경에 반응하는” 자동화가 일부 구현되어 있음.

이걸 한 줄로 요약하면:

노트가 들어오면 자동으로 관련 노트를 찾고, 링크를 붙이고, 모순을 따로 드러내고, watcher가 그 과정을 즉시 트리거하는 구조

10-1. 이미 적용된 방식

1) vault_ingest_linker — LLM 위키 패턴

vault_ingest_linker.py는 신규 노트 저장 뒤 아래 순서로 움직임.

frontmatter 파싱 + 검색 인덱스 패치
3-Tier 후보 검색
LLM 1회 호출로 관련성 확인 + 모순 감지
양방향 [[위키링크]] 삽입
필요 시 모순 노트 생성
처리 이력 기록

즉, 새 노트를 고립된 파일로 두지 않고 주변 지식망 안으로 자동 편입시키는 계층임.

2) 모순 감지

같은 스크립트 안에서 후보 노트와 새 노트 사이 충돌을 감지하면 별도 모순 노트를 생성함.

확인된 구현: - 후보별 contradiction 플래그 판정 - 700-lab 아래 모순 노트 생성 - 두 노트를 함께 가리키는 링크 구조 생성

이건 단순 연결을 넘어서 지식의 불일치 자체를 운영 대상으로 올리는 방식임.

3) vault_watcher 데몬

vault_watcher.py는 ~/knowledge/와 ~/knowledge-agent/를 감시하고, 파일 변경이 생기면:

vault_quick_sync.py 호출
이어서 vault_ingest_linker.py를 비동기로 트리거

구현상 특징: - 2초 디바운스 - 30초 쿨다운 - .md 중심 - _staging, 800 운영, .obsidian 등 일부 경로 제외

즉, 이 계층은 사람이 수동으로 “링크 돌려줘”를 누르는 구조가 아니라, 파일 변경 자체가 지식 연결 자동화의 시작 신호가 되게 만든 것임.

4) 3-Tier 후보 검색

vault_ingest_linker.py 기준 관련 노트 탐색은 아래 3단계임.

Tier A: vault_search 기반 후보 검색
Tier B: 태그/제목 키워드 Jaccard 유사도
Tier C: 2-hop 이웃 추적

사용자 설명의 “태그/키워드/의미 유사도” 관점으로 보면, 현재 시스템은 정확히 정적 메타 → 표면 키워드 → 주변 맥락/지식망 순으로 넓혀 가는 구조임.

즉, 하나의 검색 방식에 의존하지 않고 후보 회수율을 단계적으로 올리는 Karpathy식 다층 recall 패턴이 이미 들어와 있음.

10-2. 볼트 자동화 계층이 전체 시스템 청사진에 녹아드는 방식

이 계층은 청사진에서 knowledge/knowledge-agent 아래에 숨은 보조 기능이 아니라, 실제로는 입력 직후 자동 구조화 레이어로 보는 게 맞음.

흐름으로 쓰면:

노트 생성/수정
→ vault_watcher 감지
→ quick_sync
→ vault_ingest_linker
→ 관련 노트 후보 탐색
→ LLM 검증
→ 양방향 링크/모순 노트 생성
→ knowledge mesh 강화
→ 이후 Claude/Codex/Hermes/OpenClaw가 더 풍부한 맥락으로 읽음

즉, 앞서 문서에서 말한 운영 구조가

OpenClaw = 운영 본체
Claude/Codex/Hermes = 실행 주체
knowledge / knowledge-agent = 기억 저장층

이라면, Karpathy 방법론이 들어간 볼트 자동화 계층은

기억 저장층을 정적 보관소가 아니라, 스스로 연결을 자라게 만드는 능동형 메모리로 바꾸는 중간 엔진

역할을 함.

10-3. knowledge ↔ knowledge-agent 이중 구조에서 ingest linker의 역할

이중 구조에서 역할은 더 중요함.

knowledge

해리의 원본 볼트
더 신중해야 하는 기준 지식층

knowledge-agent

실험, 초안, 작업 결과, 보고서가 먼저 쌓이는 작업층

ingest linker의 실제 의미

ingest linker는 이 둘 사이에서 다음 역할을 함.

작업층에서 나온 새 노트를 기존 원본/기존 작업 지식과 빠르게 연결
새 초안이 과거 지식과 충돌하는지 조기 감지
원본 볼트와 작업 볼트가 완전히 분리된 섬으로 흩어지지 않게 연결망 유지

즉, 이 계층은 단순 링크 생성기가 아니라

knowledge는 기준축, knowledge-agent는 실험축으로 두되, 둘 사이 의미 연결은 계속 살아 있게 유지하는 브리지

라고 보는 게 맞음.

특히 해리 시스템에서는 - 원본 볼트는 읽기 중심 - 작업 산출물은 knowledge-agent 중심

이므로, ingest linker가 없으면 작업층에서 만들어진 노트가 빠르게 고립될 수 있음. 반대로 ingest linker가 있으면 새 산출물이 즉시 기존 지식망에 닿음.

10-4. 청사진상 위치 재정의

기존 청사진에 이 계층을 명시적으로 넣으면 아래처럼 이해하는 게 맞음.

해리/에이전트 출력
→ knowledge-agent 또는 knowledge에 노트 생성
→ vault_watcher
→ vault_ingest_linker
→ 링크/모순/후보 연결
→ 지식망 강화
→ 이후 분석/검색/리포트/웹앱에서 더 잘 활용

즉, 볼트 자동화 계층은 - 파이프라인의 일부이면서 - 기억 계층의 일부이고 - 이후 검색/분석/리포트 품질을 올리는 전처리 계층이기도 함.

청사진에선 이걸 “볼트 자동화 계층”으로 독립 표기하는 편이 더 정확함.

10-5. 향후 확장 방향

현재 구현은 “연결 + 모순 + watcher” 중심이고, 다음 확장 방향은 자연스럽게 이어짐.

1) 자동 요약

새 노트 유입 시 1~3줄 요약 자동 생성
기존 관련 노트 묶음에 대한 묶음 요약 생성
장기적으로는 MOC/브리프 자동 갱신까지 연결 가능

2) 자동 태깅

현재 frontmatter/키워드 기반을 더 강화해
LLM + 규칙 혼합 방식으로 태그 후보 제안
태그 정규화까지 포함하면 검색 품질이 더 안정됨

3) 지식 그래프 시각화

현재 양방향 링크와 2-hop 탐색은 이미 그래프적 구조를 가짐
이를 시각화하면
어떤 주제가 중심인지
어디가 고립 노트인지
어떤 영역에 모순이 많은지
어떤 작업 결과가 원본 지식과 약하게 연결되는지 를 한 번에 볼 수 있음

4) 자동 충돌 요약

모순 노트를 단순 생성으로 끝내지 않고
“무엇이 왜 충돌하는지”를 한 줄 요약으로 추가
해리 검토 우선순위까지 붙이면 운영성이 더 올라감

5) 분석 에이전트 연동

analyst / cowork / codex가 새 노트 작성 후
ingest linker 결과를 바로 다음 컨텍스트에 주입하면
에이전트가 더 일관된 판단을 내리게 됨

6) 관측 계층과 결합

이번 문서의 OTel 계층과 묶으면
“어떤 노트가 들어왔고”
“어떤 후보가 검색됐고”
“LLM이 어떤 링크/모순을 판정했고”
“그 후 어떤 리포트/웹앱 결과에 반영됐는지” 를 하나의 추적선으로 볼 수 있음

이 지점이 중요함.

Karpathy 방법론은 여기서 별도 실험이 아니라, 볼트 자동화 계층을 observability 계층과 연결할 때 비로소 시스템 수준 기능이 됨.

11. 근거 자료

로컬 근거

~/.openclaw/workspace/docs/system-baseline.md
~/.openclaw/workspace/memory/system-baseline/latest.json
~/knowledge-agent/800 운영/840 리포트/운영-청사진-2026-04-09.md
~/knowledge-agent/800 운영/840 리포트/운영도-쉬운설명-2026-04-09.md
~/.claude/settings.json
~/.codex/config.toml
~/.hermes/config.yaml
~/.openclaw/workspace/memory/system-digest/latest.json
~/.openclaw/workspace/monitoring/PR_DESCRIPTION.md
~/.openclaw/workspace/monitoring/prometheus/rules/timeout_spike_rules.yml

웹 근거

Claude Code Monitoring 공식 문서: https://code.claude.com/docs/en/monitoring-usage
Claude Code Monitor 커뮤니티 구현 예시: https://github.com/zcquant/claude-code-monitor