docs(journey): add companyx grounding and orchestration research drafts

Made-with: Cursor
2026-03-23 17:14:01 +09:00 · 2026-03-23 17:14:01 +09:00 · 2f3bb6622c
commit 2f3bb6622c
parent 4b0a464b5b
7 changed files with 476 additions and 0 deletions
--- a/journey/plans/260323_companyx_grounding_라우팅_복구_계획.md
+++ b/journey/plans/260323_companyx_grounding_라우팅_복구_계획.md
@ -0,0 +1,61 @@
+---
+type: plans
+tags: [plans, companyx, grounding, routing, rb8001]
+status: open
+closing_criteria: should_handle_companyx_grounding 마커 복원, 검색 0건 fallback 복구, 문서 정렬, 통합 테스트 통과
+depends_on: 260323_companyx_grounding_라우팅_결정_리서치.md
+---
+
+# 260323 Company X grounding 라우팅 복구 계획
+
+## 정의
+
+- 이 계획은 Company X grounding 과잉 진입을 복구하고, 문서 계약과 현재 운영 기준을 다시 맞추는 실행 계획입니다.
+
+## 기준
+
+- 기능 복원이 문서 정렬보다 우선입니다.
+- 닫힌 문서는 수정하지 않습니다.
+- 코드와 문서는 같은 작업 단위에서 함께 맞춥니다.
+
+## 적용
+
+### 1. 코드 수정
+
+1. [`companyx_grounding_service.py`](../../../rb8001/app/services/companyx_grounding_service.py)
+   - `should_handle_companyx_grounding()`를 마커 기반으로 복원합니다.
+   - `_looks_like_companyx_grounding_question()`의 마커 범위를 확장합니다.
+2. 같은 파일
+   - `try_companyx_grounding()`에서 검색 결과 0건이면 `None`을 반환해 일반 경로로 fallback되게 합니다.
+
+실행 담당:
+- 코드 수정과 배포는 24 서버를 기준으로 진행합니다.
+
+### 2. 문서 정렬
+
+1. [`SKILL.md`](../../skills/companyx-rag/SKILL.md)
+   - Trigger를 마커 기반 기준으로 정렬합니다.
+2. [`companyx_grounding_pipeline.md`](../../workflow/03_rag/companyx_grounding_pipeline.md)
+   - 처리 순서 1번과 현재 기준을 마커 기반으로 정렬합니다.
+
+실행 담당:
+- 문서 정렬은 23 또는 24 서버 어느 쪽에서도 가능하되, git 기준 문서는 최종 한 번만 반영합니다.
+
+### 3. 검증
+
+아래 두 묶음을 함께 확인합니다.
+
+1. grounding 질문
+   - 계약서, 투자조합, 사업계획서, 고유번호증, 서면의결서, 공문 계열
+2. 일반 스킬 질문
+   - 캘린더
+   - 이메일
+   - 뉴스
+   - 일반 날짜/잡담
+
+## 닫는 기준
+
+- Company X 일반 질문이 더 이상 무조건 grounding으로 가지 않습니다.
+- 검색 0건일 때 일반 경로 fallback이 실제로 작동합니다.
+- `SKILL.md`와 workflow 문서가 현재 코드 기준과 일치합니다.
+- 대표 질문셋 통합 테스트가 통과합니다.
--- a/journey/research/260323_companyx_grounding_라우팅_결정_리서치.md
+++ b/journey/research/260323_companyx_grounding_라우팅_결정_리서치.md
@ -0,0 +1,50 @@
+---
+type: research
+tags: [research, companyx, grounding, routing, rb8001]
+status: closed
+research_target: Company X grounding 라우팅 기준을 team_id 상시 진입에서 마커 기반 진입으로 되돌릴지 판단
+closed_date: 2026-03-23
+closed_reason: 23/24 서버 Claude/Codex 의견과 실패 사례를 종합해 마커 기반 진입 + fallback 복구로 결정 완료
+---
+
+# 260323 Company X grounding 라우팅 결정 리서치
+
+## 정의
+
+- 이 문서는 Company X grounding 라우팅 기준을 어떤 방향으로 확정할지 비교·판단한 결과를 정리합니다.
+
+## 기준
+
+- 실제 사용자 실패 사례를 코드 상태보다 우선합니다.
+- 문서 정렬만으로 해결되는 문제와 코드 수정이 필요한 문제를 분리합니다.
+- 기능 복원과 장기 구조 개선을 구분합니다.
+
+## 비교안
+
+### A안: `team_id`면 항상 grounding
+
+- 장점: 문서 질문 미진입을 줄일 수 있습니다.
+- 단점: 이메일, 캘린더, 뉴스, 일반대화까지 grounding으로 과잉 진입합니다.
+
+### B안: 근거형/내부문서형 질문만 grounding
+
+- 장점: 문서 질문만 grounding에 들어가고, 나머지는 원래 스킬 경계를 유지합니다.
+- 단점: 마커 범위가 좁으면 일부 문서 질문을 놓칠 수 있어 마커 보강이 필요합니다.
+
+## 확인된 사실
+
+1. 현재 코드는 사실상 A안으로 동작합니다.
+2. 실제 Slack 실패 사례가 확인됐습니다.
+3. NAS 확정본 기준 23/24 서버 Claude/Codex 전원이 B안에 동의했습니다.
+4. 장기 방향으로는 2단계 gating(candidate → final)이 유효하지만, 지금 우선순위는 기능 복원입니다.
+
+## 결론
+
+- 이 결론은 NAS 확정본 기준 23/24 서버 Claude/Codex 전원 동의 상태입니다.
+- B안, 즉 `근거형/내부문서형 질문만 grounding`으로 되돌리는 것이 맞습니다.
+- 동시에 grounding 검색 결과 0건일 때 일반 경로 fallback이 되도록 복구해야 합니다.
+
+## 후속
+
+- 코드 수정은 별도 계획 문서로 실행합니다.
+- 문서 정렬은 코드 수정과 같은 작업 단위로 함께 처리합니다.
--- a/journey/research/orchestration_tools/260322_Browser_Use_CLI_2_0_CDP_direct_적용판단_리서치.md
+++ b/journey/research/orchestration_tools/260322_Browser_Use_CLI_2_0_CDP_direct_적용판단_리서치.md
@ -0,0 +1,102 @@
+---
+type: research
+tags: [research, orchestration, browser-automation, cdp, playwright, skill-publish]
+status: closed
+research_target: Browser Use CLI 2.0의 CDP direct 접근이 robeing 브라우저 자동화에 주는 의미와 적용 가능 범위 판단
+closed_date: 2026-03-22
+closed_reason: 현재 skill-publish 운영 이슈와 연결해 Playwright 유지, CDP direct는 별도 탐색 후보로 정리 완료
+---
+
+# Browser Use CLI 2.0 CDP direct 적용판단 리서치
+
+## 정의
+
+- 이 문서는 사용자 제공 이미지 요약을 출발점으로 삼아, `robeing/skill-publish`의 현재 Playwright 구조와 비교해 적용 가능성을 판단한다.
+- Browser Use CLI 2.0의 세부 성능 수치와 구현 방식은 이 문서에서 공식 문서로 재검증하지 않았다.
+- 따라서 아래의 "2배 빠름", "비용 절반"은 이미지 기반 참고 정보이며, 워크스페이스 적용 판단은 로컬 코드와 기존 트러블슈팅 기록을 기준으로 한다.
+
+## 기준
+
+### 현재 워크스페이스에서 확인된 사실
+
+- `skill-publish`는 Playwright Chromium 런타임으로 Squarespace 로그인과 편집을 수행한다.
+- [`skill-publish/app/services/publisher_service.py`](../../../../skill-publish/app/services/publisher_service.py)는 `async_playwright().start()` 후 `chromium.launch()`와 `browser.new_context()`를 사용한다.
+- [`skill-publish/app/services/squarespace_login.py`](../../../../skill-publish/app/services/squarespace_login.py)는 Squarespace 로그인 흐름을 페이지 선택자 중심으로 제어한다.
+- 기존 트러블슈팅 문서 [`../../troubleshooting/250918_claude_skill-publish_reCAPTCHA_login_failure.md`](../../troubleshooting/250918_claude_skill-publish_reCAPTCHA_login_failure.md)에는 Headless Playwright가 reCAPTCHA 탐지에 걸렸고, `Xvfb + HEADLESS_BROWSER=false`에서 성공했다고 기록돼 있다.
+
+### 이미지 기준 참고 정보
+
+- Browser Use CLI 2.0은 브라우저 자동화 CLI로 소개됐다.
+- 실행 중인 Chrome에 바로 연결한다는 메시지가 있다.
+- CDP(Chrome DevTools Protocol)를 직접 사용한다고 소개됐다.
+- Playwright/Puppeteer 같은 상위 레이어보다 더 가볍고 빠른 방향을 시사한다.
+
+## 적용
+
+### 구조 차이
+
+| 항목 | 현재 skill-publish | Browser Use류 CDP direct |
+|------|--------------------|--------------------------|
+| 제어 계층 | Playwright API | Chrome DevTools Protocol 직접 호출 |
+| 대상 브라우저 | Playwright가 띄운 Chromium 중심 | 이미 실행 중인 Chrome 또는 원격 CDP 엔드포인트 |
+| 추상화 수준 | 높음, selector/wait/context API 풍부 | 낮음, 세션/타깃/이벤트 직접 관리 필요 |
+| 유지보수성 | 현재 코드와 연속성 높음 | 재작성 비용 큼 |
+| anti-bot 대응 | headless 한계 있으나 headed/Xvfb 우회 경험 있음 | "실사용 Chrome 세션 재사용"이 가능하면 유리할 수 있음 |
+
+### 우리 워크스페이스에 도움이 되는 지점
+
+1. `실행 중인 Chrome 재사용`이라는 아이디어는 유효하다.
+   - 현재 Squarespace 로그인 실패의 핵심은 선택자 자체보다 봇 탐지였다.
+   - 실제 사용자 Chrome 세션이나 headed Chrome에 붙는 구조는 이 문제를 줄일 가능성이 있다.
+
+2. `Playwright 대체`보다 `부착형 보조 경로`로 보는 것이 맞다.
+   - 현재 퍼블리싱 로직은 로그인, 편집 진입, 섹션 복제, iframe 편집, 저장까지 Playwright API에 강하게 결합돼 있다.
+   - 전면 교체는 Minimal Change 원칙에 맞지 않는다.
+
+3. `CLI 기반 브라우저 조작`은 에이전트 운영 모델과 잘 맞는다.
+   - 터미널 에이전트가 브라우저 상태를 직접 확인하고 조작하는 패턴은 로빙의 운영 방식과 결이 맞다.
+   - 특히 디버깅, 로그인 세션 점검, 사람이 켜 둔 브라우저에 붙는 반자동 운영에서 가치가 있다.
+
+### 당장 도움이 안 되는 지점
+
+1. 현재 게시 자동화의 근본 문제를 자동으로 해결해 주지는 않는다.
+   - CDP direct라도 Squarespace의 bot detection, 인증 정책, DOM 변동 문제는 그대로 남는다.
+
+2. 현재 코드베이스에는 CDP direct 추상화가 없다.
+   - Playwright 기반 서비스 계층을 바로 재사용하기 어렵다.
+   - 도입 시 새 런타임, 세션 관리, 오류 처리 기준을 다시 잡아야 한다.
+
+3. "속도 2배, 비용 절반"은 현 시점에서 운영 의사결정 근거로 부족하다.
+   - 우리 병목은 대체로 로그인 성공률, anti-bot, 페이지 안정성이다.
+   - 순수 실행 속도는 1차 병목이 아니다.
+
+## 판단
+
+### 결론
+
+- 현재 `skill-publish`의 주 경로는 Playwright를 유지하는 것이 맞다.
+- Browser Use류 CDP direct 접근은 `운영 보조 경로` 또는 `반자동 디버그 경로`로는 검토 가치가 있다.
+- 즉, 지금 필요한 것은 "Playwright를 버리고 CDP로 갈아타기"가 아니라, "실사용 Chrome 세션에 붙는 대안 경로를 별도 탐색"하는 것이다.
+
+### 우선순위
+
+1. 주 경로 유지: Playwright + headed/Xvfb + 세션 안정화
+2. 탐색 후보: 기존 Chrome/CDP attach 방식으로 로그인 성공률과 디버그 편의성 비교
+3. 보류: skill-publish 전체를 CDP direct 런타임으로 재작성
+
+### 후속 액션
+
+- `skill-publish`에 "기존 Chrome/CDP attach 가능 여부"를 따로 조사하는 연구를 열면 의미가 있다.
+- 평가 기준은 속도보다 아래 세 가지가 먼저다.
+  - Squarespace 로그인 성공률
+  - 세션 재사용 안정성
+  - 편집 DOM 변경 대응 비용
+
+## 검증
+
+- 문서 위치가 research SSOT인 `journey/research/orchestration_tools/`인지 확인했다.
+- 로컬 코드 확인:
+  - `publisher_service.py`의 Playwright 브라우저 초기화
+  - `squarespace_login.py`의 로그인 흐름
+- 기존 실패 원인 확인:
+  - `250918_claude_skill-publish_reCAPTCHA_login_failure.md`
--- a/journey/research/orchestration_tools/260322_awesome_codex_subagents_적용판단_리서치.md
+++ b/journey/research/orchestration_tools/260322_awesome_codex_subagents_적용판단_리서치.md
@ -0,0 +1,106 @@
+---
+type: research
+tags: [research, orchestration, codex, subagents, agents, developer-tooling]
+status: closed
+research_target: VoltAgent awesome-codex-subagents 저장소의 진위 확인과 robeing 워크스페이스 적용 가치 판단
+closed_date: 2026-03-22
+closed_reason: GitHub 원문과 Codex 공식 문서를 확인했고, 로컬 .codex 상태 기준으로 템플릿 카탈로그 가치만 유효하다고 정리 완료
+---
+
+# awesome-codex-subagents 적용판단 리서치
+
+## 정의
+
+- 이 문서는 사용자 요청으로 `awesome-codex-subagents` 저장소의 실제 링크를 확인하고, robeing 워크스페이스에 도움이 되는 범위를 판단한다.
+- 목적은 "좋아 보이는 링크 저장"이 아니라, 현재 로컬 Codex 환경에 바로 쓸 수 있는지와 문서화 가치가 있는지를 구분하는 것이다.
+
+## 기준
+
+### 외부에서 확인한 사실
+
+- GitHub 저장소는 실제로 존재한다.
+  - 저장소: `https://github.com/VoltAgent/awesome-codex-subagents`
+- GitHub 페이지 기준 설명은 "136+ Codex subagents across 10 categories"이다.
+- 저장소 README는 Codex 공식 문서 링크로 `https://developers.openai.com/codex/subagents`를 가리킨다.
+- README 기준 설치 방식은 `.toml` 에이전트 파일을 아래 경로 중 하나에 복사하는 구조다.
+  - `~/.codex/agents/`
+  - `.codex/agents/`
+- README는 커스텀 서브에이전트가 자동 실행되지 않으며, 명시적으로 위임해야 한다고 적고 있다.
+
+### 로컬에서 확인한 사실
+
+- 현재 홈 디렉터리에 [`/home/admin/.codex`](/home/admin/.codex) 가 존재한다.
+- 현재 [`/home/admin/.codex/config.toml`](/home/admin/.codex/config.toml) 은 존재하지만, `agents` 관련 설정은 아직 없다.
+- 현재 [`/home/admin/.codex/agents`](/home/admin/.codex/agents) 디렉터리는 존재하지 않는다.
+
+## 적용
+
+### 이 저장소가 주는 실제 가치
+
+1. `서브에이전트 템플릿 카탈로그`로는 가치가 있다.
+   - 역할 정의를 `.toml`로 분리해 재사용하는 패턴은 에이전트 운영 표준화에 도움이 된다.
+   - 특히 reviewer, debugger, docs, infra, data, orchestration 계열 역할 분리가 잘 돼 있다.
+
+2. `멀티 에이전트 운영 사고방식` 참고용으로 유효하다.
+   - 한 메인 에이전트에 모든 지시를 몰아넣지 않고 역할별 책임을 분리하는 방식이다.
+   - 이는 robeing의 스킬 분리 방향과도 개념적으로 맞는다.
+
+3. `바로 설치해야 할 필수 의존성`은 아니다.
+   - 현재 워크스페이스는 이미 스킬 문서, 프로젝트 문서, 서비스 분리 구조를 갖고 있다.
+   - 이 저장소는 실행 런타임이 아니라 역할 프롬프트 모음에 가깝다.
+
+### 우리 워크스페이스에서 유용한 부분
+
+- 문서 리뷰 전용 에이전트
+- 인프라 점검 전용 에이전트
+- 디버그/리뷰/리서치 역할 분리 템플릿
+- `.codex/agents/` 경로를 쓰는 프로젝트별 에이전트 오버라이드 패턴
+
+### 우리 워크스페이스에서 바로 쓰기 어려운 부분
+
+1. 저장소를 그대로 가져온다고 운영 품질이 바로 올라가지는 않는다.
+   - 역할 수가 많아도 현재 프로젝트 구조와 맞지 않으면 오히려 선택 비용만 늘어난다.
+
+2. 136개 전체를 들여오는 방식은 SSOT 원칙과 맞지 않는다.
+   - 필요한 역할만 선별해야 한다.
+   - 중복 역할과 과한 추상화는 관리 비용을 만든다.
+
+3. 현재 로컬에는 `~/.codex/agents/` 자체가 없다.
+   - 즉, "이미 적용 중"이라고 말할 수 없다.
+   - 먼저 디렉터리 생성, 소수 파일 선별, 프로젝트별 우선순위 기준이 필요하다.
+
+## 판단
+
+### 결론
+
+- 이 저장소는 `참고 가치가 있는 진짜 GitHub 링크`가 맞다.
+- robeing에는 `전면 도입`보다 `선별 복사형 템플릿 소스`로 쓰는 것이 맞다.
+- 우선순위는 "에이전트 136개 도입"이 아니라, 현재 작업 흐름과 맞는 3~5개 역할만 추려 보는 것이다.
+
+### 추천 시작점
+
+아래 성격의 역할부터 선별 검토하면 된다.
+
+1. `reviewer` 또는 `code-reviewer`
+2. `debugger` 또는 `error-detective`
+3. `documentation-engineer` 또는 `technical-writer`
+4. `devops-engineer` 또는 `incident-responder`
+5. `mcp-developer` 또는 meta/orchestration 계열
+
+### 운영 원칙
+
+- 글로벌 공용은 `~/.codex/agents/`
+- 프로젝트 전용은 `.codex/agents/`
+- 같은 이름 충돌 시 프로젝트 전용이 우선
+- 전부 복사하지 말고 역할과 책임이 분명한 것만 선별
+
+## 검증
+
+- GitHub 저장소 존재 확인
+  - `https://github.com/VoltAgent/awesome-codex-subagents`
+- Codex 공식 문서 경로 존재 확인
+  - `https://developers.openai.com/codex/subagents`
+- 로컬 경로 확인
+  - [`/home/admin/.codex`](/home/admin/.codex)
+  - [`/home/admin/.codex/config.toml`](/home/admin/.codex/config.toml)
+  - [`/home/admin/.codex/agents`](/home/admin/.codex/agents) 미존재 확인
--- a/journey/research/orchestration_tools/260322_openclaw_로빙_적용_리서치_v1.md
+++ b/journey/research/orchestration_tools/260322_openclaw_로빙_적용_리서치_v1.md
@ -0,0 +1,36 @@
+---
+type: research
+tags: [research, orchestration, openclaw, rewrite, comparison]
+status: closed
+research_target: OpenClaw 로빙 적용 리서치의 일반 정리본 v1
+closed_date: 2026-03-22
+closed_reason: 일반 요약형 정리본 작성 완료
+---
+
+# OpenClaw 로빙 적용 리서치 v1
+
+## 개요
+
+OpenClaw는 다양한 메신저와 연결되는 오픈소스 AI 비서 플랫폼입니다. 이 문서는 OpenClaw 구조를 보고 로빙에 참고할 수 있는 부분을 간단히 정리합니다.
+
+## 핵심 내용
+
+- OpenClaw는 `gateway`, `agents`, `channels`, `extensions`, `skills` 구조를 가집니다.
+- 세션과 라우팅을 중앙에서 다루는 게 강점입니다.
+- 스킬을 문서와 메타데이터로 관리하는 점도 참고할 만합니다.
+- 보안적으로 allowlist, 세션 격리, 샌드박스 같은 기본값을 둡니다.
+
+## 로빙에 적용할 점
+
+- `robeing-gateway`를 중심으로 세션과 라우팅을 더 명확히 나눌 수 있습니다.
+- `skill-*` 문서를 SKILL.md 스타일로 더 표준화할 수 있습니다.
+- 메일, 캘린더, 리서치, 퍼블리싱 같은 역할을 분리하는 멀티 에이전트 구조도 참고 가능합니다.
+
+## 한계
+
+- OpenClaw는 Node.js/TypeScript이고 로빙은 Python/FastAPI라서 코드를 직접 가져오기는 어렵습니다.
+- 따라서 실제 적용은 코드 이식보다 설계 참고 수준이 적절합니다.
+
+## 결론
+
+OpenClaw는 로빙에 게이트웨이 구조, 스킬 문서화, 보안 기본값 측면에서 참고 가치가 있습니다. 다만 직접 통합보다는 아이디어를 선별 적용하는 편이 맞습니다.
--- a/journey/research/orchestration_tools/260322_openclaw_로빙_적용_리서치_v2.md
+++ b/journey/research/orchestration_tools/260322_openclaw_로빙_적용_리서치_v2.md
@ -0,0 +1,63 @@
+---
+type: research
+tags: [research, orchestration, openclaw, rewrite, comparison]
+status: closed
+research_target: OpenClaw 로빙 적용 리서치의 documentation-engineer 기준 정리본 v2
+closed_date: 2026-03-22
+closed_reason: documentation-engineer 기준으로 정의, 기준, 적용, 검증, 잔여 리스크를 강화한 정리본 작성 완료
+---
+
+# OpenClaw 로빙 적용 리서치 v2
+
+## 정의
+
+OpenClaw는 메신저 채널을 하나의 Gateway로 묶어 세션, 라우팅, 도구 실행, 스킬을 연결하는 개인 AI 비서 플랫폼입니다.
+로빙 관점에서는 직접 이식할 코드보다 게이트웨이, 스킬, 보안 구조의 참조 모델로 보는 것이 맞습니다.
+
+## 기준
+
+- 정합성 우선: OpenClaw는 Node.js/TypeScript, 로빙은 Python/FastAPI이므로 코드 병합보다 설계 참고가 우선입니다.
+- 책임 분리: 채널은 입력 전달에 집중하고, Gateway가 세션, 라우팅, 정책을 책임져야 합니다.
+- 스킬 계약화: 스킬은 프롬프트 묶음이 아니라 입력, 출력, 권한, 실패 기준이 있는 계약 단위여야 합니다.
+- 보안 기본값: 외부 입력은 기본 불신, allowlist와 격리 원칙을 먼저 둬야 합니다.
+- 운영 단순성: 현재 로빙 운영 경계 안에서 유지 가능한 항목만 채택합니다.
+
+## 확인된 사실
+
+- 원문 리서치 기준 OpenClaw는 `src/gateway`, `src/agents`, `src/channels`, `extensions/`, `skills/` 구조를 가집니다.
+- 채널은 코어 채널과 플러그인 확장 구조로 분리됩니다.
+- 스킬은 `SKILL.md`와 메타데이터 기반으로 관리됩니다.
+- 로빙과 OpenClaw는 런타임, 채널 구조, 스킬 구조가 다르므로 직접 코드 융합은 부적합하다고 원문에 명시돼 있습니다.
+
+## 적용
+
+| OpenClaw 기준 | 로빙 적용 |
+|---|---|
+| Gateway가 세션, 라우팅, 도구 호출의 중심 | `robeing-gateway`에 세션과 정책 책임을 더 집중 |
+| 채널은 이벤트 전달 역할 | Slack 등 입력 채널은 전달에 집중 |
+| `SKILL.md` 기반 스킬 계약 | `skill-*` 문서를 계약 문서로 표준화 |
+| allowlist, pairing, 샌드박스 | 외부 입력과 위험 작업에 기본 차단 원칙 적용 |
+| 멀티 에이전트 세션 분리 | 메일, 캘린더, 리서치, 퍼블리싱 분화 시 참고 |
+
+## 권장 해석
+
+- 우선 적용 후보는 Gateway 중심 설계, 스킬 포맷 표준화, 보안 기본값입니다.
+- 멀티 에이전트 라우팅은 필요성이 확인된 범위에서만 단계적으로 도입하는 편이 맞습니다.
+- 채널 확장 구조는 참고 가능하지만 현재 로빙 범위를 넘겨 과확장하지 않는 것이 안전합니다.
+
+## 검증
+
+- 원문 문서의 구조 설명과 결론을 기준으로 재정리했습니다.
+- 원문에 있는 기술 스택 차이, 적용 후보, 한계를 그대로 반영했습니다.
+- 다만 최신 OpenClaw 레포 상태를 다시 조회한 문서는 아니므로 세부 개수나 최신 버전은 확정값으로 보지 않습니다.
+
+## 잔여 리스크
+
+- 채널, 스킬, 게이트웨이 책임이 다시 섞이면 운영 복잡도가 커질 수 있습니다.
+- 스킬 계약이 약하면 문서만 늘고 실행 품질은 오히려 떨어질 수 있습니다.
+- 보안 기본값이 약하면 외부 메시지 입력이 공격면이 될 수 있습니다.
+
+## 결론
+
+OpenClaw는 로빙에 게이트웨이 중심 제어, 스킬 계약화, 보안 기본값을 정리하는 데 유효한 참고 모델입니다.
+다만 현재 로빙 기준에서는 직접 이식보다 설계 원칙만 선별 적용하는 편이 맞습니다.
--- a/journey/troubleshooting/260323_companyx_grounding_라우팅_과잉진입_및_fallback_차단.md
+++ b/journey/troubleshooting/260323_companyx_grounding_라우팅_과잉진입_및_fallback_차단.md
@ -0,0 +1,58 @@
+---
+type: troubleshooting
+tags: [companyx, grounding, routing, fallback, rb8001]
+status: open
+opened_date: 2026-03-23
+severity: high
+root_cause: Company X team_id 사용자 무조건 grounding 진입 + 검색 0건이어도 success=True 반환으로 일반 스킬 fallback 차단
+---
+
+# 260323 Company X grounding 라우팅 과잉진입 및 fallback 차단
+
+## 정의
+
+- Company X 사용자의 모든 질문이 grounding 경로로 먼저 들어가면서, 캘린더·이메일·뉴스·일반대화가 `문서 없음`으로 실패하는 문제입니다.
+- 이번 문서는 현재 운영 장애를 다룹니다. 닫힌 문서는 수정하지 않고, 현재 문제만 새 문서로 분리합니다.
+
+## 기준
+
+- 닫힌 문서는 닫힌 시점 사실만 유지합니다.
+- 현재 운영 문제는 현재 코드와 실제 실패 사례 기준으로 기록합니다.
+- 문서 정렬보다 기능 복원이 우선입니다.
+
+## 확인된 사실
+
+1. 현재 코드 [`companyx_grounding_service.py:135`](../../../rb8001/app/services/companyx_grounding_service.py#L135)는 Company X 팀이면 질문 마커와 무관하게 `True`를 반환합니다.
+2. 현재 코드 [`companyx_grounding_service.py:429`](../../../rb8001/app/services/companyx_grounding_service.py#L429)는 grounding 경로에 한 번 들어오면 검색 0건이어도 `success=True` 구조로 응답합니다.
+3. NAS 확정본 [`grounding_라우팅_최종결론_확정.md`](/mnt/nas/workspace/shared-editing/drafts/grounding_라우팅_최종결론_확정.md)에는 전원 동의 결론으로 "마커 체크 복원 + fallback 복구"가 기록돼 있습니다.
+4. 24 서버 Claude가 기록한 실제 실패 예시는 아래와 같습니다.
+   - 구글캘린더 일정 요청 → 문서 없음
+   - 이메일 확인 요청 → 문서 없음
+   - 날짜 질문 → 문서 없음
+   - AI 뉴스 검색 요청 → 문서 없음
+
+## 왜 문제인가
+
+- Company X 문서검색 기능 하나를 살리기 위해 다른 스킬 경계를 모두 무너뜨립니다.
+- 사용자는 이메일/캘린더/뉴스 요청을 했는데, 내부 문서검색 실패 응답만 받습니다.
+- 기존 계획의 롤백 기준(`grounding 진입률 80% 이상`)을 사실상 초과한 상태로 해석됩니다.
+
+## 적용
+
+### 현재 결론
+
+- NAS 확정본 기준 23/24 서버 Claude/Codex 전원이 같은 결론에 동의했습니다.
+- 운영 기준은 `team_id면 항상 grounding`이 아니라 `근거형/내부문서형 질문만 grounding`입니다.
+- grounding 검색 결과가 없으면 일반 경로로 돌아갈 수 있어야 합니다.
+
+### 관련 문서
+
+1. [260321_하이브리드검색_품질개선_계획.md](../plans/260321_하이브리드검색_품질개선_계획.md)
+2. [260322_companyx_rag_LLM판단보수_대화맥락미연결.md](./260322_companyx_rag_LLM판단보수_대화맥락미연결.md)
+3. [260323_companyx_grounding_라우팅_결정_리서치.md](../research/260323_companyx_grounding_라우팅_결정_리서치.md)
+4. [260323_companyx_grounding_라우팅_복구_계획.md](../plans/260323_companyx_grounding_라우팅_복구_계획.md)
+
+## 검증
+
+- 현재 코드 2곳을 직접 확인했습니다.
+- NAS 확정 드래프트의 전원 동의 결론을 직접 확인했습니다.