Add OpenClaw-based robeing improvement ideas

journey/README.md

@@ -37,6 +37,10 @@
 
 - CI 빌드 시간 단축 계획 – `troubleshooting/250723_happybell80_CI빌드시간단축.md`
 
+### 에이전트 구조 / Gateway 정리
+
+- OpenClaw 기반 로빙 개선 아이디어 – `ideas/260309_openclaw_기반_로빙_개선_아이디어.md`
+
 ### Intent 리뷰 / 의도 학습
 
 - Intent 리뷰 큐 설계 및 API 계획 – `../300_architecture/390_human_in_the_loop_intent_learning.md`

journey/ideas/260309_openclaw_기반_로빙_개선_아이디어.md

@@ -0,0 +1,67 @@
+tags: [openclaw, robeing, gateway, skills, multi-agent]
+
+# OpenClaw 기반 로빙 개선 아이디어
+
+## 배경
+- `openclaw` 저장소를 2026-03-09 기준 최신으로 확인했습니다.
+- 최신 반영 자체는 모델 툴 스키마 호환성 수정 성격이 강했고, 로빙에 바로 가져올 기능 추가는 아니었습니다.
+- 다만 `OpenClaw`가 이미 강하게 정리한 `Gateway`, `세션`, `멀티채널`, `스킬`, `보안 기본값` 구조는 로빙 개선 아이디어로 여전히 유효합니다.
+
+## 핵심 판단
+- 로빙에 필요한 것은 OpenClaw 코드 이식보다 설계 패턴 차용입니다.
+- 특히 `rb8001 + skill-* + robeing-gateway` 구조를 더 명확히 분리하고, 운영 기준을 문서화하는 데 참고 가치가 큽니다.
+- 이 아이디어 문서는 기존 리서치 문서를 실행 후보 관점으로 다시 압축한 것입니다.
+
+## 먼저 가져올 개선 아이디어
+
+### 1. Gateway 책임 집중
+- 채널과 스킬은 이벤트 전달에 집중하고, 세션·라우팅·보안 판단은 `robeing-gateway`에 모읍니다.
+- 목표는 "어디서 들어온 요청인지"보다 "어떤 세션과 존재가 처리해야 하는지"를 게이트웨이에서 일관되게 결정하는 구조입니다.
+- 적용 후보:
+  - Slack 등 외부 입력은 Gateway 진입 후 의도 분류
+  - `rb8001` 직접 분기보다 Gateway가 라우팅 우선 담당
+  - 세션 수명, 헬스, 실패 기록도 Gateway 기준으로 통일
+
+### 2. 존재 분화형 멀티 에이전트 라우팅
+- 지금의 단일 `rb8001` 중심 처리에서, 메일·캘린더·리서치·퍼블리싱 같은 역할별 존재 분화를 더 명확히 합니다.
+- 목표는 "스킬 호출"을 넘어 "존재별 세션과 책임 분리"를 만드는 것입니다.
+- 적용 후보:
+  - 존재별 기본 시스템 프롬프트 분리
+  - 존재별 접근 가능한 스킬 세트 분리
+  - 존재 간 위임/협업 로그 구조 설계
+
+### 3. `skill-*` 계약 문서 표준화
+- 각 `skill-*` 서비스에 `SKILL.md` 스타일 계약 문서를 붙여 입력, 출력, 권한, 필요한 환경을 고정합니다.
+- 목표는 스킬을 "코드 묶음"이 아니라 "설치/권한/입출력 계약이 있는 실행 단위"로 보는 것입니다.
+- 적용 후보:
+  - `skill-email`, `skill-news`, `skill-calendar`, `skill-rag-file`부터 시작
+  - 필수 환경변수, 인증 방식, 실패 조건, 출력 형식 명시
+  - 장기적으로는 로빙 스킬 카탈로그/배포 기준으로 연결
+
+### 4. 메신저 입력 보안 기본값 강화
+- 외부 메신저 입력은 기본적으로 불신하고, 명시적 허용 규칙 아래에서만 처리합니다.
+- 목표는 편의보다 운영 안전성을 먼저 확보하는 것입니다.
+- 적용 후보:
+  - allowlist 또는 대응 가능한 승인 절차
+  - 그룹 채널 mention gating
+  - 설정/토큰/노출점 점검용 진단 스크립트
+
+## 왜 지금 의미가 있는가
+- 로빙은 이미 컨테이너/마이크로서비스 구조를 가지고 있지만, 세션·라우팅·스킬 계약은 아직 더 선명해질 여지가 있습니다.
+- OpenClaw는 사용자 접점과 운영 안전장치를 제품 수준으로 정리해 둔 사례라서, 로빙의 다음 정리 기준으로 참고 가치가 높습니다.
+- 특히 로빙이 장기적으로 에이전트 생태계와 스카웃 가능한 에이전트 구조를 지향한다면, 존재 분화와 스킬 계약화는 먼저 정리해야 할 축입니다.
+
+## 보류 판단
+- Node/TypeScript 기반 OpenClaw 코드를 Python/FastAPI 기반 로빙에 직접 병합하는 방향은 우선순위가 낮습니다.
+- 현재는 코드 도입보다 구조와 운영 규칙을 로빙 문서와 서비스 경계에 반영하는 편이 더 적절합니다.
+
+## 다음 후보 작업
+1. `robeing-gateway` 기준 세션·라우팅 책임 범위를 문서로 먼저 고정합니다.
+2. `skill-email` 하나를 샘플로 `SKILL.md` 스타일 계약 문서로 바꿉니다.
+3. 메신저 입력 보안 기본값과 점검 항목을 운영 체크리스트로 분리합니다.
+
+## 참고 문서
+- `../research/orchestration_tools/260205_openclaw_로빙_적용_리서치.md`
+- `../research/orchestration_tools/260205_openclaw_official_docs_summary.md`
+- `../../book/300_architecture/310_전체_시스템_구조_컨테이너와_마이크로서비스.md`
+- `../../book/400_growth/440_스카웃_가능한_에이전트란.md`