OpenClaw·Hermes 마이그레이션 (3/13) — 옮길 것과 버릴 것: 4 카테고리 분류

-

부제: 30 스크립트를 ✅ 🔧 💎 🗑 네 칸에 분류하는 기준

핵심 요약

  • 기존 자산을 새 플랫폼의 내장 기능과 1:1로 비교할 때 대체 / 부분 대체 / 보존 / 폐기 4 카테고리 분류법이 실용적이다.
  • Hermes의 핵심 설계 포인트는 agent/memory_provider.py의 Pluggable MemoryProvider — 외부 메모리가 1급 시민(first-class citizen)으로 취급된다.
  • 이 분류법을 OpenClaw → Hermes 케이스에 적용한 결과: 약 15개 대체, 12개 부분 대체, 10개 보존(이식), 8개 폐기. 보존 대상이 마이그레이션의 정당성을 결정한다.

분류 기준 — 왜 4 카테고리인가

에이전트 마이그레이션은 "전부 이식 vs 전부 재작성"의 이분법으로 처리되면 실패한다. 실제 자산은 연속적 스펙트럼 위에 분포한다. 4 카테고리는 대상 플랫폼의 인터페이스 존재 여부와 도메인 고유 로직 존재 여부의 2×2 매트릭스를 단순화한 것이다.

표시 의미 판정 조건
✅ 대체 대상 플랫폼 내장이 동일하거나 우월 내장 기능이 커버, 도메인 로직 불필요
🔧 부분 대체 인터페이스는 존재, 판단 로직만 이식 내장 hook/provider 있음, 판정 기준은 고유
💎 보존(이식) 대상 플랫폼에 없음, 고유 자산 내장 없음, 도메인 로직이 핵심 가치
🗑 폐기 원본 전용 + 전환 후 무의미 원본 프레임워크 종속, 이식 불가 또는 무가치

A. 메모리 계층 — 그릇과 내용물의 분리

메모리 관련 자산은 구조상 "저장/검색 메커니즘"과 "판단 로직"이 섞여 있는 경우가 많다. Pluggable MemoryProvider 아키텍처는 이 둘을 강제로 분리시킨다.

OpenClaw Hermes 대응 분류
bank/ 4-tier 구조 MemoryProvider 플러그인 wrapping 🔧
recall-tree / recall-match MemoryProvider.prefetch(query) 🔧
retain-extract / retain-merge on_session_end / on_pre_compress hook 🔧
memory-micro-cycle cron + sync_turn ✅
confidence-decay 없음 💎
topics-validate / topics-expand 없음 💎
user-pattern-stage (U-tag dialectic) 없음 💎
bank-lint / bank-size-watch 없음 💎
entity-audit 없음 💎
Topic-Cued Recall 전체 prefetch + system_prompt_block 🔧

원리: 검색·저장의 그릇은 플랫폼 내장이 제공한다. 판단 로직(무엇을 꺼낼지, 무엇을 폐기할지, 신뢰도를 어떻게 감쇠시킬지)은 도메인 고유 자산으로 남는다. 이 분리는 MemoryProvider 인터페이스 시그니처에서 강제된다 — prefetch(query) -> list[Memory]는 저장소가, 리스트에 들어갈 Memory의 선택/정렬/감쇠는 구현체가 담당한다.

B. 모델·라우팅·컨텍스트 — 거의 다 대체

OpenClaw Hermes 대응 분류
Router_Control 프록시 (포트 3939) smart_model_routing.py ✅
context compaction (safeguard) context_compressor.py ✅
프롬프트 캐시 수동 관리 prompt_caching.py ✅
auth-profiles.json credential_pool.py ✅
모델 fallback 네이티브 fallback ✅

이 영역은 공통 인프라에 해당한다. 모델 라우팅, 프롬프트 캐시, credential pooling, context compaction은 에이전트 도메인에 독립적이다. 커스텀 구현을 유지할 근거는 "내장이 특정 요구를 못 맞출 때"로 제한된다. 그 외 경우엔 ✅ 대체가 합리적이다.

C. Heartbeat / Self-Review — 절반은 보존

OpenClaw 분류 비고
heartbeat-router/tick/health ✅ cron + on_turn_start로 흡수
heartbeat 11 escalation reasons 💎 판정 기준은 도메인 자산
self-review-prescan/apply/fix ✅ hermes-agent-self-evolution(DSPy+GEPA)으로 업그레이드
daily-audit Phase A (docs-snapshot) 💎 Hermes에 없음
proactive-exception-alerts 💎 11 reason 판정은 보존

패턴: "언제 체크하는가"(heartbeat timing, self-review trigger)는 플랫폼이 제공할 수 있다. 반대로 "무엇을 문제로 판정하는가"(11 escalation reasons, docs-snapshot 기준)는 운영 이력에서 도출된 고유 기준이다. Self-Review의 DSPy+GEPA 기반 업그레이드는 ✅로 분류된 사례 — 내장 구현이 기능적으로 우월하므로 커스텀 로직을 고집할 이유가 없다.

D. 외부 통합

OpenClaw 분류
scrape.py (Scrapling + playwright + curl_cffi) 🔧
researcher Deep Mode (5-round AutoSearch) 💎
gws-wrapper / gws-check 🔧
Telegram Forum 6 토픽 라우팅 ✅
Discord 주채널 ✅
oMLX 통합 ✅

Deep Mode의 5-round AutoSearch는 💎에 속하는 대표 사례다. 검색 프로토콜 자체(쿼리 확장 → 결과 수집 → 크로스 레퍼런스 → 갭 식별 → 재검색)가 플랫폼에 존재하지 않는 도메인 로직이기 때문이다.

E. 워크스페이스 → Profile

11개의 워크스페이스 추상은 Hermes의 profiles 기능에 흡수된다. 구조적으로 워크스페이스의 약 절반이 모델 차이를 역할 차이로 표현하고 있었기 때문에, profile 5~6개로 기능 집합이 축약된다. 이는 "커스텀 추상이 플랫폼 네이티브에 자연스럽게 매핑되는" 케이스의 예시다.

F. Skills

일반 워크플로우 스킬(brainstorming, verification, code-review 등 9개)은 💎 → optional-skills/로 포팅한다. 이들은 OpenClaw 종속성이 없고 범용 재사용이 가능하다. 반면 oc-* 시리즈(8개)는 🗑 — 플랫폼 자체가 전환되면 호출 전제가 사라진다.

G. Hooks

PostToolUse(JSON 검증·Linter·DOC_SYNC), PreToolUse(git commit gate), SessionStart/End/PreCompact는 모두 🔧 부분 대체. Hermes의 profile/gateway hook 인터페이스로 이식하되 게이트 로직(무엇을 통과시키고 무엇을 차단하는가)은 그대로 가져간다. Hook은 "언제 실행할지"와 "무엇을 할지"가 분리 가능한 전형적 사례다.

분류 결과 집계

  • ✅ 대체: 약 15 항목 → 스크립트/설정 약 30% 감소 예상
  • 🔧 부분 대체: 약 12 항목
  • 💎 보존(이식): 약 10 항목 — 마이그레이션의 정당성은 사실상 이 칸에 달린다
  • 🗑 폐기: 약 8 항목

💎 항목이 0에 가까우면 마이그레이션 자체가 불필요하다(내장만으로 커버된다는 뜻). 반대로 💎 비중이 과반이면 플랫폼 교체보다 자체 유지가 더 합리적일 수 있다. 10/45 ≈ 22% 수준은 "플랫폼 교체 + 핵심 로직 이식"이 정당화되는 전형적 비율이다.

정리 — 적용 가능 범위

이 분류 프레임워크는 다음 조건에서 재사용 가능하다:

  • 소스와 대상 플랫폼이 명확히 구분될 때 (여기서는 OpenClaw → Hermes)
  • 양쪽 자산의 인터페이스 시그니처를 직접 비교할 수 있을 때
  • "도메인 고유 로직"과 "공통 인프라"의 경계가 코드 수준에서 식별 가능할 때

반면 다음 경우엔 이 방식이 잘 맞지 않는다: 두 플랫폼의 추상화 레벨이 크게 다를 때, 또는 자산의 가치가 개별 코드가 아닌 데이터(학습된 임베딩, 누적된 상호작용)에 있을 때.

열린 질문: 💎 10개의 이식 비용을 정량화하면 어떻게 되는가. LOC, 테스트 커버리지, 의존성 개수를 실측하면 "보존 가치"의 상한을 추정할 수 있다. 다음 글에서 이 실측을 다룬다.

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

댓글

댓글 쓰기

이 블로그의 인기 게시물

"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 »