“기본 라인은 다재다능하지만, 너무 다재다능해서 역효과가 날 수 있죠.”
OpenClaw “Context Engine Plugin”이란 무엇인가
컨텍스트 엔진은 OpenClaw에서 세션의 기억(컨텍스트)을 정리하는 시스템 전체를 교체할 수 있는 플러그인입니다.
왜 기본 파이프라인만으로는 부족할까
컨텍스트 누수 현상
기본 파이프라인(legacy)은 모든 워크로드에 똑같은 방식으로 컨텍스트를 정리합니다. 교육용 대화, 코딩 작업, 긴 협업 채팅 — 각각 다르게 정리해도 되는데 말이죠.
워크로드별 최적화가 어려운 이유
“하나의 라인으로 모든 것을 처리한다”는 것은 공장에서 조립 라인 하나로 모든 제품을 조립하는 것과 비슷합니다. 자동차와 휴대폰을 같은 라인에서 조립할 수는 있지만, 효율적이지는 않죠.
Context Engine Plugin의 핵심 개념
”세션 컨텍스트 오케스트레이션” 전체를 교체한다
컨텍스트 엔진은 “일부만 바꾸는 게” 아닙니다. 컨텍스트를 수집하는 단계(ingest) → 조립하는 단계(assemble) → 압축하는 단계(compact)까지, 전체를 새로 설계합니다.
ingest → assemble → compact, 세 단계 한 번에 설계
세 단계 각각을 이해하면 왜 “전체 교체”가 필요한지 알 수 있습니다:
- ingest: 새로운 메시지가 올 때마다 세션 기억에 무엇을 추가할지 결정
- assemble: 최종 프롬프트를 만들기 위해 어떤 순서로 배치할지 결정
- compact: 토큰 한도를 넘지 않도록 어떤 정보를 우선 보존할지 결정
등록부터 활성화까지, 3단계로 끝
1단계: 엔진 등록 (api.registerContextEngine)
먼저 플러그인에서 엔진을 등록합니다. 이때 factory 함수를 제공하는데, 이는 엔진 객체를 만드는 함수입니다.
api.registerContextEngine('lossless-claw', () => ({
info() { return { id: 'lossless-claw', name: 'Lossless Claw' }; },
ingest() { /* 컨텍스트 수집 */ },
assemble() { /* 조립 */ },
compact() { /* 압축 */ }
}));2단계: 슬롯에 지정 (plugins.slots.contextEngine)
다음으로 config에서 활성 엔진을 지정합니다.
{
"plugins": {
"slots": {
"contextEngine": "lossless-claw"
}
}
}3단계: 예시 보기 (lossless-claw 구조)
위 코드가 실제로 어떻게 동작하는지 확인하려면, 네 가지 메서드를 구현하면 됩니다.
info(): 엔진 정보 반환ingest(): 새로운 메시지 처리assemble(): 프롬프트 조립compact(): 컨텍스트 압축
Exclusive Slot: “동시 다중 엔진”이 아닌 이유
결정성 보장
동시에 여러 엔진이 같은 세션에서 작동하면, 어느 엔진이 결과를 냈는지 알기 어렵습니다. exclusive slot은 한 번에 하나만 작동하도록 보장합니다.
디버깅 용이성
문제가 발생했을 때 “어느 엔진인지” 바로 알 수 있어야 합니다. exclusive slot은 이를 단순화합니다.
운영 단순화
설정 파일에서 plugins.slots.contextEngine에 하나만 지정하면 됩니다. 여러 엔진을 관리할 필요가 없습니다.
Legacy vs Custom: 무엇이 다른지
기본(legacy) 동작 방식
OpenClaw가 기본으로 제공하는 파이프라인입니다. 대부분의 워크로드에 적당하게 동작합니다.
커스텀 엔진 적용 시 장점
워크로드별로 컨텍스트 전략을 최적화할 수 있습니다. 비용 절감, 품질 개선이 가능할 수 있습니다.
비교표
| 항목 | legacy | custom engine | 비고 |
|---|---|---|---|
| 토큰 사용량 | 기본 알고리즘 | 워크로드별 최적화 가능 | 10~30% 절감 가능성 |
| 품질 손실률 | 고정 정책 | 정책 커스터마이즈 | 중요 정보 보존율 향상 가능성 |
| 운영 복잡도 | 관리 불필요 | 엔진 유지관리 필요 | trade-off 존재 |
언제 교체하는 게 좋은가
실제로 교체를 고려해볼 만한 신호 3가지
- 특정 워크로드에서 비용이 계속 높을 때 - 기본 파이프라인이 그 워크로드에 최적화되어 있지 않을 수 있습니다.
- 압축 결과에서 중요 정보가 자주 누락될 때 - 도메인별 우선순위 정책이 필요할 수 있습니다.
- 새로운 정책을 실험해보고 싶을 때 - 예를 들어 교육용 대화에서 키워드 보존 정책을 테스트하고 싶을 때.
교체 기준 체크리스트
- 기본 파이프라인이 내 워크로드에 안 맞을 때
- 도메인별 컨텍스트 조립 규칙이 필요할 때
- 압축 정책을 비용/정확도 기준으로 튜닝하고 싶을 때
실무 적용 예시 3가지
- 교육 콘텐츠 맞춤: 긴 대화에서 교육 키워드 보존 (예: 코딩 용어 정의)
- 코딩 작업 효율: 코드 히스토리 우선 압축 (최근 코드 상태 보존)
- 긴 대화 압축 최적화: 비용 절감 우선 (중복 내용 제거)
운영 체크포인트 (롤백·로그·테스트)
엔진 간 전환 시 점검 포인트
엔진을 바꿀 때마다 세션 동작을 확인하세요. 특히 압축 결과가 예상대로 나오는지 확인이 중요합니다.
롤백 절차
문제가 발생하면 plugins.slots.contextEngine를 다시 legacy로 설정하면 됩니다. gateway를 재시작하세요.
슬롯 독립 테스트 방법
새 엔진을 배포하기 전에, 테스트 환경에서 먼저 확인하세요.
결론
”교체”가 아닌 “적절한 선택”의 문제
기본 파이프라인도 훌륭합니다. 하지만 워크로드에 따라 다른 파이프라인이 더 효율적일 수 있습니다. “교체”가 아니라 “적절한 선택”의 문제입니다.
적용 가이드 요약
- 먼저 기본으로 시작
- 워크로드 관찰
- 필요 시 커스텀 엔진 도입