OpenClaw·Hermes 마이그레이션 (6/13) — 5주 마이그레이션 계획: 기능 카테고리화와 profile 압축

-

누적된 에이전트 플랫폼을 단계적으로 이식할 때의 일정 설계, 기능 카테고리화, profile 압축 기법 정리

이 글이 전달하는 것

  • 다수의 파일로 누적된 에이전트 시스템을 기능 카테고리(A~K)로 정규화하는 분류 기준
  • 5주 일정 설계: 스키마 → 데이터 변환 → 어댑터 → 자산 이식 → 듀얼 실행 + 컷오버
  • Profile 압축 기법: 다수의 워크스페이스를 줄일 때의 선정 원칙
  • 데몬 → 라이브러리 전환의 판단 근거와 1인 시스템에서의 trade-off

접근법: 코드 이식이 아니라 부채 정리

누적된 에이전트 시스템을 다른 런타임으로 옮길 때 단순 복사 이식은 5주가 아니라 1~2일이면 끝난다. 그러나 데이터 변환·검증·듀얼 실행까지 포함하면 일정은 달라진다. 마이그레이션의 진짜 비용은 코드가 아니라 데이터 정합성과 검증 구간에 쌓인다.

이 글은 그 구간을 어떻게 쪼개고 측정하는지를 정리한다.

살려야 할 기능의 카테고리화 (A~K)

마이그레이션 대상을 파일 단위로 보면 다수지만, 기능 단위로 묶으면 한 자릿수 카테고리로 압축된다. 일정을 설계하기 전에 이식 대상을 먼저 정규화하는 이유는 하나다. 일정은 카테고리 단위로 움직이고, 카테고리 단위가 검증의 단위가 된다.

카테고리 핵심
A 메모리 시스템 4-tier, Retain 태그, U-tag dialectic, Reflect, micro-cycle, Topic-Cued Recall, 의미 검색
B Heartbeat 다단계 tier + 다수의 escalation 사유 + Quota 체크
C Self-Review 다단계 stage + Skill Evolution Loop
D Daily Audit Phase A~E (가이드/업데이트 감지, 진단, 집계, 최종 리뷰)
E Researcher Deep Mode 다라운드 AutoSearch + 다단계 웹접근
F Channel Routing Discord 주채널 + Telegram Forum Topic 분기
G Profile 매핑 워크스페이스 → profile 압축
H Hooks PostToolUse, PreToolUse, SessionStart/End/Compact
I 보안 모델 loopback, token, dmPolicy, 단일 사용자 수용
J 자동 업데이트 com.hermes.update-check 신규
K 폐기 대상 heartbeat-tick.py 등

비용 분포

A(메모리 시스템)가 전체 마이그레이션의 절반 이상을 차지한다. SQLite로 저장소를 교체하면서 4-tier 구조와 U-tag dialectic을 무손실로 옮겨야 한다는 제약이 붙기 때문이다. 4-tier 구조는 단순 key-value 덤프로는 복원되지 않고, dialectic 태그는 시간 순서와 참조 관계를 보존해야 의미가 유지된다.

K(폐기 대상)는 일정에 들어가지 않는다. 명시적으로 버리는 자산을 목록화해 두면 이식 대상 범위가 자동으로 축소된다.

5주 일정의 구조

Week 작업 산출물
1 memcore SQLite 스키마 + 라이브러리 골격 스키마 DDL, 빈 라이브러리 shell
2 bank/ → memcore 변환 (rsync + 마이그레이션 스크립트) 변환된 SQLite DB, 검증 리포트
3 Hermes 설치 + 최소 profile + MemoryProvider 어댑터 읽기 가능한 최소 런타임
4 보존 자산 이식 + Hermes profile 구성 동작하는 전체 런타임
5 듀얼 실행 + 검증 + 컷오버 동등성 검증 로그, 컷오버 결정

설계 원칙: 읽기 쪽부터 만든다

Week 1~3은 데이터를 옮기고 읽을 수 있게 만드는 단계이고, Week 4는 동작 코드 이식, Week 5는 동등성 비교와 컷오버다. 쓰기보다 읽기가 먼저 완성되면 변환 오류를 빨리 발견할 수 있다. 역순으로 가면 변환 실패가 실행 시점에 누적되어 롤백 비용이 커진다.

듀얼 실행이 핵심 안전장치

Week 5의 듀얼 실행은 양쪽 시스템을 동시에 돌려서 출력이 일치하는지를 비교하는 단계다. 동일한 메모리 micro-cycle을 양쪽에서 실행 → 출력 비교 → 일치하면 컷오버, 불일치면 차이 분석. 한 번에 갈아엎지 않는다는 점이 요지다.

이 구조는 Strangler Fig 패턴의 변형이다. 기존 시스템을 죽이지 않고 옆에서 동일 기능을 돌리다가, 검증이 끝나면 스위치만 돌린다. 검증 근거가 누적되기 전에는 어느 쪽도 제거하지 않는다.

Profile 압축 기법

워크스페이스가 다수로 쪼개진 상태는 누적의 결과일 뿐 최적 구조가 아니다. 압축의 기준은 "활성 스킬 카테고리가 겹치는가"다. 겹치면 합치고, 독립적이면 남긴다.

Profile 흡수 대상 활성 스킬 카테고리
mir-coordinator mir + planner 라우팅, 대화, PRD
research researcher 웹리서치, AutoSearch Deep
writer communicator 글쓰기, 편집
coder orchestrator 코딩, CLI, 서브에이전트 팩토리
google-workspace google Gmail, Calendar, Drive
memory-ops memory-runner + memory-manager + reviewer bank I/O, Reflect, 월간 리뷰

Profile에서 제외되는 것들

monitor와 telegram-ops는 profile 레벨이 아니라 cron/hook 레벨로 내려간다. 단순 라우팅 작업은 독립 profile로 분리할 가치가 없다. 판단 기준: 상태(state)를 들고 있는가? 상태가 없는 단순 라우팅은 hook으로 충분하다.

압축의 측정값

profile 수가 줄면 전환 의사결정 수가 선형이 아니라 페어 단위로 감소한다. 선택지가 많을 때와 적을 때는 체감 이상으로 차이가 난다. 정량 측정은 어렵지만, 인지 부하 감소는 profile 수가 절반 가까이 줄어드는 순간이 아니라 각 profile의 역할이 상호 배타적으로 정의되는 순간에 발생한다.

데몬 → 라이브러리 전환

이번 마이그레이션에서 구조적 변화가 가장 큰 결정은 메모리 계층을 데몬이 아니라 라이브러리로 구현한다는 것이다. 기존 시스템은 oMLX 서버, gateway 데몬 등 백그라운드 프로세스가 다수 떠 있었다. 새 시스템은 메모리를 SQLite + Python 라이브러리(memcore) 로만 다룬다.

데몬의 숨은 비용

1인 시스템에서 데몬은 다음을 요구한다. - 프로세스 사망 감지 — 죽었는지 알아차리는 메커니즘 - 재시작 정책 — launchd / systemd / supervisor 중 선택 - 헬스체크 — endpoint 설계 + 주기적 호출 - 로그 회전 — 디스크 점유 방지 - 동시성 제어 — 다중 클라이언트 가정 시 필요

라이브러리는 import만 하면 된다. 단일 사용자 환경에서는 동시성 문제 자체가 발생하지 않는다. SQLite의 WAL 모드로 단일 writer + 다중 reader 조건도 충족된다.

전환 범위

oMLX는 유지한다(임베딩 서빙은 라이브러리로 대체하기 어렵다). gateway와 메모리 데몬은 전부 라이브러리로 흡수된다. 결과적으로 다수의 LaunchAgent 중 상당수가 제거될 예정이다.

한계와 열린 질문

이 계획의 적용 범위는 단일 사용자 시스템이다. 다중 사용자 환경에서는 데몬 → 라이브러리 전환이 성립하지 않는다(동시성과 리소스 격리가 필요해진다). Profile 압축도 마찬가지로 역할이 상호 배타적으로 정의 가능할 때만 유효하다.

열린 질문: - 듀얼 실행 구간에서 어느 정도의 출력 차이를 "동등"으로 볼 것인가? 비결정성(LLM 샘플링)이 섞이면 바이트 단위 비교는 불가능하다. 의미 동등성 판정 기준이 필요하다. - 메모리 카테고리 A의 dialectic 태그는 참조 그래프를 보존해야 한다. SQLite에서 이걸 테이블 구조로 풀 것인가, JSON 컬럼으로 갈 것인가의 선택이 남아 있다. - Profile 수가 더 줄어들 수 있는가? 사용 패턴에 따라 mir-coordinator + writer 통합 가능성이 있다.

적용 가능 범위

이 글의 일정 설계와 카테고리화 기법은 다음 경우에 재사용 가능하다. - 누적된 에이전트 시스템을 다른 런타임으로 옮길 때 - 데이터 스키마 교체를 동반하는 마이그레이션 - 워크스페이스/프로필 수가 실제 필요보다 많이 쪼개져 있다고 판단되는 경우 - 데몬 기반 구조를 라이브러리로 흡수할 때의 판단 기준이 필요한 경우

핵심은 검증 구간을 일정에 명시적으로 포함시키는 것이다. 코드 이식만 일정으로 잡으면 검증은 "끝나면 하는 것"이 되고, 끝이 나지 않는다.

시리즈 전체 안내: 시리즈 목차

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »