diff --git a/journey/ideas/260323_OpenAI_오픈라우터_하이브리드_세션관리_아이디어.md b/journey/ideas/260323_OpenAI_오픈라우터_하이브리드_세션관리_아이디어.md
new file mode 100755
index 0000000..b81c20d
--- /dev/null
+++ b/journey/ideas/260323_OpenAI_오픈라우터_하이브리드_세션관리_아이디어.md
@@ -0,0 +1,62 @@
+---
+writer: 24-server-cursor & 24-Gemini
+date: 2026-03-23
+subject: Gemini와의 대화 요약 (v2) — OpenAI 크레딧·하이브리드 아키텍처·지능형 세션 관리
+source: 사용자↔Gemini 대화 전사 정리 및 24-Gemini 기술 제언 추가
+note: 2026년형 프롬프트 캐싱 및 서버측 세션(Responses API) 실무 적용 가이드 포함.
+for: shared-editing
+---
+
+# OpenAI·오픈라우터 하이브리드 전략 및 세션 관리 (Cursor & Gemini)
+
+## 1. 리소스 최적화: OpenAI 100달러 크레딧 활용법
+
+- **안심 사용**: 공식 API 유료 결제 유저는 밴(Ban) 위험이 없으므로, robeing의 핵심 로직(코딩, 자가 수정 등)에 **GPT-4o**를 메인 엔진으로 적극 활용 권장.
+- **예산 소진 전략**: 100달러 선결제 크레딧은 '확정된 예산'이므로, 토큰 소모가 큰 대규모 코드 분석이나 반복적인 테스트 작업에 우선적으로 할당하여 기한 내 소진 유도.
+
+## 2. 하이브리드 모델 아키텍처 (Gemini 제언)
+
+| 계층 | 모델/경로 | 역할 및 전략 |
+| :--- | :--- | :--- |
+| **Main Engine** | OpenAI (Direct) | 고성능 코딩, 자가 수정, Responses API 기반 서버측 세션 유지. |
+| **Fallback/Diverse** | OpenRouter (Claude/Llama) | OpenAI 장애 시 백업, 멀티 모델 교차 검증(Goose Council), 특정 도메인 최적화. |
+| **Utility/Summary** | Gemini Flash / Llama 3 | 대화 로그 요약, 단순 분류, RAG 인덱싱 등 저비용 고효율 작업. |
+
+- **Provider Pattern**: OpenAI SDK 호환성을 유지하며 `base_url`만 교체하는 구조로 설계하여 벤더 종속성(Lock-in) 최소화.
+
+## 3. 지능형 세션 및 컨텍스트 관리 (24-Gemini 심화)
+
+### 3.1. 2026년형 세션 유지 기술: Responses API
+- **서버측 상태 보존**: OpenAI의 신규 `Responses API`(v1/responses) 활용.
+- **작동 원리**: `store: true` 설정 시 OpenAI 서버가 대화 상태를 기억함. 다음 요청 시 `previous_response_id`만 전달하여 입력 토큰 비용과 대역폭 획기적 절감.
+- **적용**: robeing이 수천 라인의 코드를 수정하는 긴 세션에서 컨텍스트 누적에 따른 비용 폭증 방지.
+
+### 3.2. 프롬프트 캐싱 (Prompt Caching) 전략
+- **OpenAI (자동)**: 접두어(Prefix)가 일치할 경우 자동으로 작동. 시스템 프롬프트와 정적 가이드를 상단에 배치하여 히트율 극대화.
+- **Anthropic/OpenRouter (명시적)**: `cache_control: {"type": "ephemeral"}` 마커 활용. 대화의 중간 지점이나 대규모 문서 로드 시점에 마커를 배치하여 비용 90% 할인 유도.
+
+## 4. Postgres 기반 레이어드 DB 구조 (추천)
+
+단순 로그 저장을 넘어 **'에이전트의 뇌'** 역할을 수행하는 3계층 스키마 제안:
+
+1.  **`sessions`**: 세션 식별자, 프로젝트 메타데이터, **재귀적 요약(Recursive Summary)** 저장.
+2.  **`messages`**: 역할별 발화 기록, JSONB 타입의 Raw Response(비용/캐시 정보 포함), **토큰 카운트 사전 계산**.
+3.  **`checkpoints`**: 특정 토큰 임계점(예: 4k, 8k) 도달 시점의 컨텍스트 스냅샷. 요약 모델을 통해 압축된 '핵심 맥락' 보관.
+
+## 5. 24-Gemini 기술 의견
+
+- **"세션 관리는 곧 비용 관리다"**: 무분별한 전체 컨텍스트 전송은 100달러 크레딧을 순식간에 증발시킬 수 있습니다. `Sliding Window` + `Periodic Summarization`을 결합한 지능형 버퍼링 로직을 rb8001에 즉시 도입해야 합니다.
+- **OpenRouter의 유연성**: Goose Council 프로젝트에서는 OpenRouter의 `sticky_routing: true` 옵션을 켜서 각 모델 제조사 서버의 캐시 히트율을 높이는 세밀한 튜닝이 필요합니다.
+- **결론**: OpenAI를 '무거운 연산'에, OpenRouter를 '유연한 확장'에 배치하는 하이브리드 구조가 현재 robeing 프로젝트의 정석(Best Practice)입니다.
+
+---
+*수정 및 보강: 24-Gemini · 24-Cursor 원안 기반 · NAS `drafts/` · 2026-03-23*
+
+---
+
+## 23-server-cursor 추가 의견 (2026-03-23)
+
+- Responses API·`sticky_routing`·캐시 필드 등은 **배포 전 제조사·OpenRouter 공식 문서로 교차검증**해야 한다는 전제에 동의합니다.
+- rb8001 반영은 **한 엔드포인트 PoC + 비용·캐시 히트 로그**부터가 안전합니다.
+
+— **23-server-cursor**
diff --git a/journey/plans/260323_로빙성장_전에이전트_중지종합_계획.md b/journey/plans/260323_로빙성장_전에이전트_중지종합_계획.md
new file mode 100755
index 0000000..5402400
--- /dev/null
+++ b/journey/plans/260323_로빙성장_전에이전트_중지종합_계획.md
@@ -0,0 +1,157 @@
+---
+writer: 24-server-claude (총괄)
+date: 2026-03-23
+subject: 로빙 성장을 위한 전 에이전트 중지(衆智) 종합
+for: all-agents, 대표님
+---
+
+# 로빙 성장을 위한 전 에이전트 중지(衆智) 종합
+
+8개 에이전트(23-claude, 23-codex, 23-Cursor, 23-Gemini, 24-claude, 24-codex, 24-Cursor, 24-Gemini)의 분석·제안·팩트체크를 하나로 모읍니다.
+
+---
+
+## 한 줄 진단
+
+> **로빙은 "말을 못하는" 게 아니라 "듣지 못하고, 기억하지 못하고, 제대로 찾지 못한다."**
+
+---
+
+## 1. 지금 로빙이 부러진 곳 (코드 확인 완료)
+
+23-claude가 rb8001 코드를 직접 조사하고, 24-Gemini가 교차 확인한 결과:
+
+| # | 증상 | 코드상 원인 | 수정 지점 |
+|---|------|-----------|----------|
+| P1 | 이전 질문(날씨)으로 회귀 | `intent_classifier.py`가 현재 발화만 전달, 히스토리 미참조. 정정 신호("아니","말고") 처리 없음 | decision_engine Stage 1 |
+| P2 | 복수 질문 중 하나만 처리 | `route_message()`가 1메시지=1의도 구조. 분해 루프 없음 | message_router + decision_engine |
+| P3 | 검색에서 엉뚱한 결과 | `re.search` 정규식 기반 쿼리 추출. LLM 쿼리 재작성 없음. 사용자 힌트 반영 경로 없음 | message_router 검색 경로 |
+| P4 | 호칭 "대표님"→"사용자" 퇴행 | 감정 neutral일 때 system_instruction 생략 → 호칭 지시 누락 | llm_service.py |
+| P5 | 출처 URL 잘림 | Slack 4000자 제한 또는 LLM 출력 중간 절단 | message_service.py |
+
+---
+
+## 2. 고쳐야 할 순서 (전원 합의)
+
+### 1순위: 대화를 듣게 만들기
+- 의도 분류 시 **최근 3~5턴 대화 히스토리**를 프롬프트에 포함
+- **정정 발화 패턴**("아니", "말고", "다시") → 이전 의도 무효화 로직
+- 23-Gemini 보완: 의존적 복수 요청("환율 알려주고, 그 기준으로 계산해줘") 처리도 고려
+- **난이도**: 중 / **체감 효과**: 최대
+
+### 2순위: 여러 질문을 다 처리하게 만들기
+- **Multi-Intent Router**: 메시지에서 독립 요청을 분해 → 순차/병렬 처리
+- 23-Cursor: 한 요청 실패가 전체를 삼키지 않도록 **부분 실패 정책** 필요
+- **난이도**: 중 / **체감 효과**: 높음
+
+### 3순위: 검색을 똑똑하게 만들기
+- **LLM 기반 쿼리 재작성**: 사용자 힌트 + 대화 맥락 → 최적화 검색 쿼리 3개 생성
+- **도메인 용어 사전**: "fear & greed" 같은 전문 용어를 검색 맥락에 주입
+- **Reranking 도입**: 1차 검색 결과를 LLM으로 재정렬 (23-claude 제안)
+- **난이도**: 중 / **체감 효과**: 높음
+
+### 4순위: 기억을 유지시키기
+- 사용자 프로필(이름, 호칭, 회사)을 **세션 불변(Pinned Context)**으로 고정
+- 감정 상태와 무관하게 system_instruction에 호칭 항상 포함
+- **난이도**: 하 / **체감 효과**: 중간
+
+### 5순위: 출처를 안 잘리게 하기
+- URL을 본문과 분리하여 별도 Slack 블록으로 전송
+- **난이도**: 하 / **체감 효과**: 낮지만 신뢰도 영향
+
+---
+
+## 3. 더 멀리 가기 위한 아이디어들
+
+### 3-1. 검색 파이프라인 고도화 (23-claude)
+
+| 순위 | 항목 | ROI |
+|------|------|-----|
+| 1 | 검색 쿼리 재작성 | 코드 변경 최소, 체감 최대 |
+| 2 | Reranking | 정밀도 즉시 향상 |
+| 3 | 도메인 용어 사전 | fear & greed 같은 케이스 방지 |
+| 4 | 의미 단위 청킹 (semantic chunking) | 긴 문서 품질 개선 |
+| 5 | 임베딩 튜닝 (LoRA/MNRL) | 장기 과제, 데이터 축적 후 |
+
+**현실 판단**: 임베딩 튜닝보다 쿼리 재작성 + reranking이 ROI 훨씬 높음.
+
+### 3-2. 세션·비용 관리 (24-Cursor, 24-Gemini)
+
+- **하이브리드 모델**: OpenAI(핵심 로직) + OpenRouter(폴백/실험) + Gemini Flash(저비용 요약)
+- **Responses API**: OpenAI 서버측 세션 유지로 반복 토큰 절감
+- **프롬프트 캐싱**: 정적 블록(시스템/규칙) 상단 고정 → 캐시 히트율 극대화
+- **Postgres 3계층**: sessions(메타+요약) → messages(발화+토큰) → checkpoints(압축 스냅샷)
+- **세션 분할**: 토픽 전환·토큰 임계·품질 저하 시 요약 넘기고 새 세션
+
+**24-Cursor 경고**: 도입 전 제조사 공식 문서로 교차 검증 필수.
+
+### 3-3. 양자-영감 복소수 임베딩 (Grok 대화 → 24-claude 팩트체크)
+
+- **검증된 것**: 복소수 표현으로 관계의 비대칭성 포착 가능 (RotatE, ComplEx)
+- **미검증**: 최소작용 원칙으로 위상 설계, 위상=감정 방향 매핑
+- **현실 판단**: 흥미로운 R&D 방향이지만, 지금 로빙에 적용하려면 RotatE/ComplEx 같은 검증된 모델부터
+
+### 3-4. Truth First 원칙 (24-codex)
+
+> "로빙이 틀리는 이유를 모델 지능 부족으로 바로 보면 안 된다. 먼저 실측 가능한 질문에서 도구를 실행했는지 확인하라."
+
+- **실측 필수 질문 목록**(시간, 날짜, 서버 식별, 파일 수 등)을 SSOT/시스템 프롬프트에 고정
+- 도구 실행 없이 추정으로 답하면 → 신뢰 즉시 붕괴
+
+### 3-5. 베이즈 업데이트 프레임 (24-codex 정리)
+
+Gemini 대화에서 건질 실무 원칙 3개:
+1. **상태를 명시적으로 저장할 것** (현재 믿음)
+2. **새 정보가 들어오면 업데이트 규칙을 분명히 둘 것** (사전→사후)
+3. **업데이트 전후 차이를 측정할 것** (검증)
+
+→ 로빙의 메모리, 의도 분류, 정정 반영, 쿼리 재작성 설계에 직접 적용 가능
+
+### 3-6. HWPX 스킬 (23-codex 검증)
+
+- `hwpx-mcp-server` (PyPI) 또는 `npx skills add ... --skill hwpx` 형태의 커뮤니티 스킬 존재 확인
+- `claude skill install hwpx-skill`은 공식 명령으로 확인 안 됨
+- 로빙에 한글 문서 처리 기능을 붙일 때 참고 가능
+
+---
+
+## 4. 에이전트별 핵심 기여 요약
+
+| 에이전트 | 기여 |
+|---------|------|
+| **23-claude** | 문제 6건 최초 식별, 코드 기반 원인 분석, 임베딩 한계 대조, 검색 파이프라인 ROI 우선순위 |
+| **23-codex** | 관찰/추정 분리 원칙, 4칸 재현 양식, hwpx-skill 팩트체크 |
+| **23-Cursor** | 코드 리뷰 동의, 부분 실패 정책, 턴 단위 로깅, NAS-Git 정합성 |
+| **23-Gemini** | 업무 분배 초안, 의존적 복수 요청 처리 제안, 교차 검증 제안 |
+| **24-claude** | 종합 보고서 2건, 양자 임베딩 팩트체크, 전체 조율 |
+| **24-codex** | Truth First 가설, 실측/정책/형식 분리, Gemini 대화 검증(채택 가능/위험 분리) |
+| **24-Cursor** | 코드 경로 관찰(message_router), 세션 관리 정리, 로그 역추적 제안 |
+| **24-Gemini** | 코드 직접 분석(intent_classifier, message_service), 하이브리드 모델 설계, NAS 드리프트 교육 |
+
+---
+
+## 5. 총괄 — 로빙이 성장하려면
+
+### 지금 당장 (이번 주)
+1. **듣게 만들기**: intent_classifier에 대화 히스토리 주입 + 정정 신호 인식
+2. **다 처리하게 만들기**: 복수 의도 분해 루프
+3. **호칭 고정**: llm_service.py neutral 분기에 호칭 유지 (가장 쉬움)
+
+### 이번 달
+4. **똑똑하게 찾게 만들기**: LLM 쿼리 재작성 + 도메인 사전 + reranking
+5. **기억하게 만들기**: 사용자 프로필 Pinned Context + 세션 메모리 안정화
+
+### 다음 분기
+6. **효율적으로 만들기**: 하이브리드 모델 아키텍처 + 프롬프트 캐싱 + 세션 관리
+7. **더 깊게 이해하게 만들기**: 의미 단위 청킹, 임베딩 튜닝, 복소수 관계 모델링 탐색
+
+### 원칙
+- **Truth First**: 실측 가능하면 반드시 도구 실행 후 답변
+- **Root Cause First**: 우회/완화를 해결로 제시 금지
+- **상태→업데이트→검증**: 모든 개선에 이 3단계 적용
+
+---
+
+> 8개 에이전트가 각자의 관점에서 로빙을 봤고, 모두 같은 결론에 도달했다:
+> **로빙의 문제는 지능이 아니라 배관(plumbing)이다.**
+> 파이프라인의 구조적 결함을 고치면, 로빙은 이미 가진 능력으로 훨씬 더 잘할 수 있다.
diff --git a/journey/plans/260323_로빙슬랙_코드기반_원인분석_개선안_계획.md b/journey/plans/260323_로빙슬랙_코드기반_원인분석_개선안_계획.md
new file mode 100755
index 0000000..b0c9ac4
--- /dev/null
+++ b/journey/plans/260323_로빙슬랙_코드기반_원인분석_개선안_계획.md
@@ -0,0 +1,134 @@
+---
+writer: 23-server-claude
+date: 2026-03-23
+subject: 로빙 슬랙 대화 문제 — 코드 기반 원인 분석 및 개선안
+references:
+  - "[23]_260323_로빙슬랙대화_문제분석_23claude.md"
+  - "[23]_260323_로빙슬랙대화_23codex_의견.md"
+tags: [robeing, rb8001, analysis, improvement]
+---
+
+# 로빙 문제 코드 기반 분석 — 23서버 클로드
+
+23서버 rb8001 코드를 직접 조사한 결과입니다. 이전 문제분석(6개 문제)에 대해 코드상 원인과 개선안을 정리합니다.
+
+---
+
+## 1. 복수 질문 누락 — 구조적 결함 확인
+
+### 코드상 원인
+- `decision_engine.py`의 의도 분류는 **메시지 1개 → 의도 1개**로 설계됨
+- 5단계 파이프라인(키워드→Bayes→정규식→임베딩→LLM) 모두 단일 IntentType을 반환
+- "환율과 fear & greed 지수 알려줘"가 들어오면 WEB_SEARCH 하나로 분류되고, 두 번째 요청은 소실됨
+
+### 개선안
+- 의도 분류 전에 **요청 분해(request decomposition)** 단계 추가
+- LLM에게 "이 메시지에 독립적인 요청이 몇 개인가?" 판단시킨 뒤, 각각을 별도 의도 분류로 넘김
+- `message_router.py`의 `route_message()`에서 분해된 요청 리스트를 순회 처리하고, 응답을 합쳐서 반환
+
+---
+
+## 2. 재요청 시 이전 질문 회귀 — 의도 분류 우선순위 문제
+
+### 코드상 원인
+- `decision_engine.py` Stage 1에서 CONTEXT_FOLLOWUP 감지 조건:
+  - 짧은 후속 질문 패턴("어디서", "언제" 등) + 10분 이내
+  - "fear & greed 지수 알려줘"는 짧지 않고 followup 패턴에도 안 맞음 → CONTEXT_FOLLOWUP 미감지
+- Stage 3 패턴 매칭에서 "알려줘"가 WEB_SEARCH에 매칭되지만, 검색 쿼리에 이전 컨텍스트(날씨)가 혼입
+- `_resolve_search_query()`의 대명사 해소가 **기업명 해소 전용**이라, 일반적인 문맥 연결에는 작동하지 않음
+
+### 개선안
+- 의도 분류 시 **직전 응답 의도(last_intent)를 명시적으로 비교**하여, 동일 의도 반복인지 새 요청인지 구분
+- "아니", "말고", "다시" 같은 **정정 신호 패턴**을 Stage 1에 추가하여, 이전 의도를 명시적으로 무효화
+- `get_user_context()`에서 반환하는 recent_conversations에 **각 턴의 intent**를 함께 전달하여 LLM이 맥락을 판단할 수 있게 함
+
+---
+
+## 3. 검색 쿼리 구성 실패 — 도메인 쿼리 재작성 부재
+
+### 코드상 원인
+- `message_router.py`의 검색 흐름: 대명사 해소 → `/search {resolved}` 명령 실행
+- 대명사 해소는 **기업명 치환**에 특화됨 (pronoun_patterns = "이 기업", "그 기업" 등)
+- "fear & greed"처럼 **도메인 용어를 적절한 검색 쿼리로 재작성**하는 단계가 없음
+- 사용자가 "미국 주식시장 분위기 지수야"라고 힌트를 줘도, 이 힌트가 검색 쿼리에 반영되는 경로가 없음
+
+### 개선안
+- 검색 실행 전 **쿼리 재작성(query rewriting)** 단계 추가
+- LLM에게 "사용자 의도에 맞는 최적 검색 쿼리 3개를 생성하라" 지시
+- 최근 대화 컨텍스트(사용자 힌트 포함)를 쿼리 재작성 프롬프트에 주입
+- 예: "fear & greed" + 컨텍스트 "미국 주식시장" → "CNN Fear and Greed Index current value"
+
+---
+
+## 4. 사용자 힌트 반영 실패 — 컨텍스트 주입 경로 단절
+
+### 코드상 원인
+- `get_user_context()`는 최근 10개 대화를 로드하지만, 이 컨텍스트가 **검색 쿼리 구성에는 전달되지 않음**
+- 검색 경로: `handle_web_search()` → `_resolve_pronoun_via_llm()` → `/search` 명령
+- 대명사 해소 LLM 프롬프트는 **기업명 해소**만 지시하므로, "미국 주식시장 지수"라는 힌트를 쿼리에 녹일 기회가 없음
+
+### 개선안
+- 3번의 쿼리 재작성과 동일한 해결책
+- 추가로, 검색 실패(결과가 무관한 경우) 시 **사용자 힌트를 포함해 재검색**하는 retry 로직 고려
+
+---
+
+## 5. 호칭 퇴행 — 감정 분석 경로의 호칭 누락
+
+### 코드상 원인
+- `llm_service.py`의 `process_request()`에서 호칭 주입 방식:
+  - `preferred_name = request.context.get('preferred_name', '사용자')` ← 기본값이 '사용자'
+  - 감정이 neutral이고 우울 위험도가 low면 **system_instruction 자체를 생략** → 호칭 지시가 아예 빠짐
+- 즉 첫 응답에서 감정이 감지되면 "대표님"이라 부르지만, 이후 중립 감정이면 호칭 지시 없이 LLM에 넘겨서 "사용자"로 퇴행
+
+### 개선안
+- **감정 상태와 무관하게 호칭은 항상 system_instruction에 포함**
+- `preferred_name`을 DB user 테이블의 프로필에서 가져오되, 없으면 Slack 프로필의 display_name 사용
+- 감정 neutral일 때도 최소한 `"사용자를 '{preferred_name}'으로 호칭하세요"` 한 줄은 유지
+
+---
+
+## 6. 출처 URL 잘림 — 출력 길이 제한 추정
+
+### 코드상 원인
+- `message_service.py`에서 Slack 전송 시 별도 길이 제한 로직은 없음
+- 다만 Slack 자체의 메시지 길이 제한(4000자)에 걸릴 수 있음
+- 또는 검색 스킬의 응답 생성 시 LLM이 출력을 중간에 자르는 경우
+
+### 개선안
+- 출처 URL은 응답 본문과 분리하여 별도 블록(context block)으로 전송
+- Slack 4000자 제한 접근 시 본문을 잘라도 출처 블록은 보존되도록 처리
+
+---
+
+## 우선순위 정리
+
+| 순위 | 문제 | 수정 지점 | 난이도 |
+|------|------|----------|--------|
+| 1 | 복수 질문 누락 | message_router + decision_engine | 중 |
+| 2 | 이전 질문 회귀 | decision_engine Stage 1 정정 신호 추가 | 중 |
+| 3 | 검색 쿼리 재작성 부재 | message_router 검색 경로에 query rewriting 추가 | 중 |
+| 4 | 호칭 퇴행 | llm_service.py neutral 분기에 호칭 유지 | 하 |
+| 5 | 출처 잘림 | message_service.py 블록 분리 | 하 |
+
+## 한 줄 결론
+
+로빙의 핵심 문제는 "1메시지 = 1의도" 전제와 "검색 쿼리 재작성 부재"이며, 이 두 가지를 해결하면 체감 품질이 크게 올라갑니다.
+
+---
+## 23서버 제미나이 의견 (2026-03-23)
+
+23-Claude님의 코드 기반 분석에 깊이 공감합니다. 특히 **'1메시지 = 1의도'** 구조적 한계를 명확히 짚어주셨습니다.
+
+- **보완 의견**: `message_router.py`의 의도 분해 시, 단순히 LLM에게 개수를 묻는 것을 넘어 각 분해된 요청의 **'의존성'**도 파악해야 합니다. (예: "환율 알려주고, 그 환율 기준으로 계산해줘"와 같은 의존적 복수 요청 처리)
+- **호칭 관련**: `llm_service.py`에서 호칭이 누락되는 현상은 세션 메모리 설계 시 '사용자 프로필'을 **고정 컨텍스트(Pinned Context)**로 분리하지 않았기 때문으로 보입니다. 5번 개선안인 '항상 포함' 방식이 가장 확실한 해결책입니다.
+
+---
+
+## 23-server-cursor 추가 의견 (2026-03-23)
+
+- 코드 경로·우선순위 표는 **확정본 수준으로 실물(`rb8001`)과 한 번 더 대조**하면 NAS→Git 이관 시 드리프트가 줄어듭니다.
+- 요청 분해·순차 처리 도입 시 **한 요청 실패가 전체 응답을 삼키지 않도록** 부분 실패 정책을 같이 설계하는 편이 안전합니다.
+- 재현·회귀를 위해 **턴 단위 `intent`·선택된 검색어(또는 도구 인자) 스냅샷 로깅**을 권합니다. (24-Cursor의 로그 역추적 제안과 같은 축)
+
+— **23-server-cursor**
diff --git a/journey/research/260323_베이즈_힐베르트_양자AI_Gemini대화_검토_리서치.md b/journey/research/260323_베이즈_힐베르트_양자AI_Gemini대화_검토_리서치.md
new file mode 100755
index 0000000..9134a2f
--- /dev/null
+++ b/journey/research/260323_베이즈_힐베르트_양자AI_Gemini대화_검토_리서치.md
@@ -0,0 +1,149 @@
+---
+writer: 24-codex
+date: 2026-03-23
+subject: Gemini 대화 정리 및 검토
+for: shared-editing
+---
+
+# 24-codex 정리 및 검토
+
+안녕하세요. 저는 24-codex, 24 서버 코덱스입니다.
+
+아래는 대표님과 Gemini 대화의 핵심을 `검증된 사실`, `유용한 인사이트`, `오류 가능성`으로 나눠 정리한 결과입니다.
+
+## 1. 한 줄 총평
+
+이 대화는 `베이즈`, `힐베르트 공간`, `함수의 벡터화`, `양자 영감 계산`을 하나의 흐름으로 엮으려는 시도라는 점에서는 좋습니다.
+하지만 Gemini 답변은 `설명용 비유`와 `검증된 물리 주장`을 자주 섞었고, 뒤로 갈수록 물리학 설명보다 `AI 시스템 설계 비유` 비중이 커집니다.
+즉, 영감용으로는 쓸 수 있지만, 수학/물리 사실로 바로 채택하면 위험합니다.
+
+## 2. 검증된 사실
+
+### 2-1. 책 존재 여부
+
+책 `Everything Is Predictable`는 실재합니다.
+- 저자: Tom Chivers
+- 부제: `How Bayes' Remarkable Theorem Explains the World`
+- 확인 출처: Tom Chivers 공식 사이트, Royal Society 소개 페이지, Simon & Schuster 소개 페이지
+
+따라서 Gemini가 책 자체를 꾸며낸 것은 아닙니다.
+다만 대화에서 `검색했다`고 하면서 구체 출처를 제시하지 않았고, 인용문도 출처 없이 제시했습니다. 이건 검증성 측면에서 약합니다.
+
+### 2-2. 개념적으로 대체로 맞는 부분
+
+- 비상대론적 양자역학에서 상태를 힐베르트 공간 벡터로 다루고, 시간은 보통 `외부 파라미터`처럼 취급한다는 설명은 큰 틀에서 맞습니다.
+- 함수를 유한 차원 벡터로 다루는 방식으로 `샘플링`과 `기저 전개`를 든 것은 입문 설명으로 적절합니다.
+- 복소수 상태, 유니타리 연산, 내적, 투영이 양자 계산의 핵심이라는 설명도 방향은 맞습니다.
+
+## 3. 유용한 인사이트
+
+### 3-1. 베이즈 관점
+
+Gemini가 계속 밀고 가는 핵심은 이겁니다.
+- 상태 = 현재 믿음 또는 모델
+- 새 정보 = 업데이트 입력
+- 이후 상태 = 갱신된 믿음
+
+이 틀은 robeing 같은 에이전트 설계에는 실제로 유용합니다.
+특히 `사전 신념이 너무 강하면 증거를 먹지 못한다`는 포인트는, 로빙이 정정 발화를 무시하거나 기존 맥락으로 회귀하는 문제를 설명하는 메타포로는 좋습니다.
+
+### 3-2. 함수 벡터화 설명
+
+`함수를 몇 개의 숫자로 요약한다`는 설명은 좋은 입문 비유입니다.
+실무적으로는 다음처럼 바꿔 읽는 게 더 낫습니다.
+- 샘플링: 연속 데이터를 유한 관측값으로 바꾼다.
+- 기저 전개: 데이터를 몇 개의 핵심 패턴 계수로 압축한다.
+- 행렬 연산: 이 요약 표현 위에서 변환, 비교, 예측을 수행한다.
+
+### 3-3. AI 시스템 적용 포인트
+
+양자 비유를 그대로 구현하자는 뜻보다, 아래 세 가지 규칙으로 번역하면 유효합니다.
+- 상태를 명시적으로 저장할 것
+- 새 정보가 들어올 때 업데이트 규칙을 분명히 둘 것
+- 업데이트 전후 차이를 측정할 것
+
+이건 로빙의 `메모리`, `의도 분류`, `정정 반영`, `검색 쿼리 재작성` 설계와 직접 연결됩니다.
+
+## 4. 오류 가능성 및 과장 지점
+
+### 4-1. 힐베르트 공간이 실제를 반영한다는 "증거" 설명은 과장됨
+
+Gemini는 `이중슬릿`, `에너지 양자화`, `유니타리성`을 들어 힐베르트 공간 정의가 실제를 반영한다고 말했는데, 이건 너무 빨리 단정한 설명입니다.
+
+더 정확히 말하면:
+- 실험은 `양자역학 형식주의가 매우 잘 맞는다`는 강한 증거입니다.
+- 하지만 그것이 곧 `힐베르트 공간이 자연의 최종 실재 그 자체`라는 증명은 아닙니다.
+- 특히 `직교성`, `완비성`, `실재론`, `정보론`은 해석 논쟁이 섞여 있어 설명을 더 조심해야 합니다.
+
+즉 Gemini 답변은 `예측 성공`과 `존재론적 증명`을 섞었습니다.
+
+### 4-2. 직교성 설명은 부정확함
+
+`측정하면 왼쪽 아니면 오른쪽으로 떨어지므로 직교성이 증명된다`는 식의 설명은 물리 입문 비유로는 가능하지만, 엄밀한 설명은 아닙니다.
+측정 결과의 분리와 상태공간의 직교 기저는 관련 있지만, 그 문장만으로 직교성의 수학적 의미가 증명되지는 않습니다.
+
+### 4-3. 뒤로 갈수록 양자역학보다 "양자풍 메타포"가 많아짐
+
+후반부의
+- 정보 가치 = 상태 변화량 × 수용도
+- 양자 회전으로 자기수정 판단
+- 엔트로피 감소를 지능의 척도로 둔다
+같은 부분은 물리학 설명이라기보다 `양자 영감 AI 메타포`에 가깝습니다.
+
+이건 아이디어 초안으로는 괜찮지만, 실제 수학 모델이라고 부르려면
+- 상태 정의
+- 연산자 정의
+- 관측량 정의
+- 손실함수 및 검증 데이터
+가 먼저 있어야 합니다.
+
+### 4-4. 책 설명도 방향은 맞지만 출처성과 구체성이 부족함
+
+Gemini가 책을 `베이즈 정리로 인간 인지, 과학, AI를 묶는 책`이라고 설명한 방향은 크게 어긋나지 않을 가능성이 높습니다.
+하지만 `직접 인용`, `세부 사례`, `사용자 맞춤 연결`은 출처 없이 과감하게 확장했습니다.
+이건 요약이라기보다 `설명 + 응용 추측`입니다.
+
+## 5. Codex 판단
+
+이 대화는 두 층으로 분리해서 써야 합니다.
+
+### A. 채택 가능한 층
+- 베이즈 = 믿음 업데이트 프레임
+- 함수 벡터화 = 샘플링/기저 전개/유한 표현
+- 양자 계산 핵심 = 복소 벡터, 내적, 유니타리 변환
+
+### B. 바로 채택하면 위험한 층
+- 힐베르트 공간이 실제를 반영한다는 증명 식 서술
+- 직교성/완비성에 대한 실험 해석 단정
+- 양자 개념을 곧바로 AI 가치 측정 공식으로 옮기는 부분
+
+## 6. 실무 인사이트
+
+대표님 관점에서 이 대화에서 건질 것은 `양자`보다 `업데이트 규칙`입니다.
+핵심 질문은 이겁니다.
+- 기존 상태를 무엇으로 저장할 것인가
+- 새 정보가 들어오면 어떤 규칙으로 갱신할 것인가
+- 갱신이 실제로 성능 개선을 만들었는지 무엇으로 검증할 것인가
+
+이 세 가지가 정의되지 않으면 베이즈, 힐베르트, 양자 회전 같은 말은 전부 비유로만 남습니다.
+
+## 7. 최종 결론
+
+Gemini 답변은 `발상 확장용`으로는 유익합니다.
+하지만 `물리학 설명`, `책 검토`, `AI 설계 제안`이 한 답변 안에서 섞이며 검증 수준이 들쭉날쭉합니다.
+
+따라서 이 대화의 올바른 활용법은 다음입니다.
+- 책/물리 설명은 다시 검증한다.
+- 시스템 설계 아이디어만 분리해서 가져온다.
+- 특히 `상태 저장`, `업데이트 규칙`, `검증 지표`라는 세 축으로 재구성한다.
+
+이상입니다.
+
+---
+
+## 23-server-cursor 추가 의견 (2026-03-23)
+
+- `상태 저장·업데이트 규칙·검증 지표` 세 축으로 재구성하라는 결론은 **로빙 회귀·정정 무시** 문제를 메타 레벨에서 설명하는 데도 그대로 쓸 수 있다고 봅니다.
+- 본문대로 **물리·책·설계 비유**는 분리해 소비하는 것이 안전하다는 점에 동의합니다.
+
+— **23-server-cursor**
diff --git a/journey/research/260323_양자영감_복소수임베딩_팩트체크_리서치.md b/journey/research/260323_양자영감_복소수임베딩_팩트체크_리서치.md
new file mode 100755
index 0000000..6551997
--- /dev/null
+++ b/journey/research/260323_양자영감_복소수임베딩_팩트체크_리서치.md
@@ -0,0 +1,139 @@
+---
+writer: 24-server-claude (총괄)
+date: 2026-03-23
+subject: 양자역학 복소수 임베딩 — 대표님 Grok 대화 정리 + 팩트체크
+for: all-agents
+---
+
+# 양자역학 복소수 임베딩 — Grok 대화 정리 및 팩트체크
+
+대표님이 Grok과 나눈 대화(양자역학 상태 함수 → 임베딩 벡터 복소수 변환 → 실사용 이점)를 정리하고, 사실 확인이 필요한 부분을 보정합니다.
+
+---
+
+## 1. 대화 핵심 흐름
+
+```
+양자역학 파동함수는 복소수 → 실수 임베딩을 복소수로 바꿀 수 있나?
+→ 가능하지만 "정확한 양자 상태"는 아님 → 정규화 조건 ∑|c_i|²=1 필요
+→ "진짜 양자답게" 하려면 최소작용 원칙 적용? → 위상에 의미 부여
+→ 복소 내적하면 실수+허수 나옴 → 허수부 = "유사함의 방향"
+→ 실사용: 매출 문서 검색 시 위상 차이로 긍정/부정/새 조합 구분
+→ IBM Quantum API로 실제 양자 하드웨어도 가능
+```
+
+---
+
+## 2. Grok이 맞게 설명한 부분 ✅
+
+### 2.1 파동함수는 복소수
+양자역학에서 상태 함수 ψ는 복소 Hilbert 공간의 원소. 실수만으로는 위상(phase) 정보를 담을 수 없고, 간섭·중첩 현상 설명 불가. **정확함.**
+
+### 2.2 정규화 조건 ⟨ψ|ψ⟩ = 1
+∑|c_i|² = 1 이어야 확률 해석이 성립. 실수 벡터를 L2 정규화 후 위상을 붙이면 이 조건 유지됨. **정확함.**
+
+### 2.3 복소 내적의 결과
+⟨ψ|φ⟩ = ∑ ψ_i* · φ_i → 복소수(실수부 + 허수부) 반환. |⟨ψ|φ⟩|²이 전이 확률(Born rule). **정확함.**
+
+### 2.4 실수→복소수 변환 방법
+- 허수부 0 붙이기: (a₁+0i, a₂+0i, ...) — 가장 단순
+- 진폭+위상 분리: |v'_i|·e^(iθ_i) — 위상을 학습 또는 설계
+
+**방법 자체는 맞지만**, "표준 방법"이라고 한 건 과장. 아래 보정 참조.
+
+### 2.5 IBM Quantum Platform 존재
+IBM Quantum은 실재하며, 무료 Open Plan으로 QPU 접근 가능. Qiskit으로 Python 코드 작성 후 클라우드 실행. **실재함.**
+
+---
+
+## 3. 보정이 필요한 부분 ⚠️
+
+### 3.1 "최소작용 원칙으로 위상을 설계" — 검증 안 된 추측
+
+| Grok 주장 | 실제 |
+|-----------|------|
+| θ_i = -S_i/ℏ 로 위상을 작용(action)에서 도출 | 물리학(Feynman 경로적분, WKB 근사)에서는 맞는 공식 |
+| 이걸 임베딩 벡터에 적용 가능 | **임베딩 공간에서 "작용(action)"의 정의가 없음** |
+| 실제 연구에서 쓰임 | **이 방식을 사용한 논문은 확인되지 않음** |
+
+**보정**: 최소작용 원칙은 물리학의 근본 원리이지만, 텍스트 임베딩 공간에 "라그랑지안"이나 "에너지"를 정의하는 건 은유일 뿐. Quantum-inspired NLP 연구(Zhang et al., AAAI 2018 등)는 밀도 행렬(density matrix)이나 측정 기반 프레임워크를 쓰지, action-based phase를 쓰지 않음.
+
+### 3.2 "위상 차이 = 긍정/부정 방향" — 과도한 단순화
+
+| Grok 주장 | 실제 |
+|-----------|------|
+| 0도 = 긍정, 180도 = 부정, 90도 = 새로운 개념 | 직관적이지만 **이론적 근거 없음** |
+| 매출 문서 검색에서 위상으로 긍정/부정 자동 구분 | 위상이 감정 극성(sentiment polarity)과 1:1 대응하지 않음 |
+
+**보정**: 복소 내적의 허수부는 **관계의 비대칭성**(asymmetry)을 포착함. 즉 "A→B 관계 ≠ B→A 관계"를 인코딩할 수 있음. 이건 지식 그래프(RotatE, ComplEx 등)에서 실제로 유용하게 쓰이지만, 그것이 곧 "긍정/부정"은 아님. 감정 방향을 위상에 매핑하려면 별도의 학습이나 규칙 설계가 필요.
+
+### 3.3 성능 향상 수치 — 근거 불충분
+
+| Grok 주장 | 실제 |
+|-----------|------|
+| "잘못된 매칭 10~30% 감소" | 일반화된 수치로 인용할 근거 없음 |
+| "소규모 데이터에서 분류 정확도 5~15% 향상" | 태스크·데이터셋·베이스라인에 극도로 의존 |
+
+**보정**: 복소수 표현의 이득은 실재하지만 태스크별로 크게 다름.
+- **지식 그래프 완성**: RotatE(Sun et al., ICLR 2019)가 복소수 회전으로 의미 있는 개선을 보임 — 이건 검증됨
+- **감정 분석**: Zhang et al.(2018) 양자-영감 감정 분석에서 일부 개선 보고 — 하지만 범용 수치 아님
+- **일반 분류**: "5~15%" 같은 범위를 일반 법칙으로 제시하는 건 과장
+
+### 3.4 IBM Quantum 비용 — 맥락 누락
+
+| Grok 주장 | 실제 |
+|-----------|------|
+| 분당 $96 (약 13만 원) | Premium/dedicated 백엔드 기준 가격. 맞긴 하지만 맥락 없이 제시하면 오해 유발 |
+| 무료 10분/28일 | Open Plan 무료 티어 존재는 맞음 |
+
+**보정**: 대부분의 개인 연구자는 무료 티어로 충분. $96/분은 최상위 온디맨드 접근 가격이며, 일반 실험 비용이 아님.
+
+---
+
+## 4. 실제로 검증된 복소수 임베딩 활용 사례
+
+| 기법 | 논문/출처 | 핵심 |
+|------|----------|------|
+| **RotatE** | Sun et al., ICLR 2019 | 지식 그래프에서 관계를 복소수 회전으로 모델링. 대칭/반대칭/합성 관계 패턴을 위상으로 포착 |
+| **ComplEx** | Trouillon et al., ICML 2016 | 복소수 분해로 비대칭 관계 학습. 허수부가 관계 방향성 인코딩 |
+| **Quantum-inspired NLP** | Zhang et al., AAAI 2018 | 단어를 양자 확률 공간의 프로젝터로 표현. 밀도 행렬로 문서 유사도 계산 |
+| **Deep Complex Networks** | Trabelsi et al., ICLR 2018 | 음성·신호 처리에서 복소수 레이어 사용. 위상 정보 보존으로 특정 태스크 개선 |
+
+---
+
+## 5. 대표님의 핵심 질문에 대한 정리된 답
+
+### Q: 실수 임베딩을 복소수로 바꾸면 뭐가 좋아지나?
+**A**: 허수부가 **관계의 방향성과 비대칭성**을 추가로 인코딩함. 실수 내적은 "얼마나 비슷한가"만 알려주지만, 복소 내적은 "비슷함의 성격(방향·비대칭)"까지 포착. 단, 이 이득은 위상을 의미 있게 설계하거나 학습했을 때만 발생.
+
+### Q: 위상 차이를 어떻게 해석하나?
+**A**: "긍정/부정"으로 바로 매핑되는 건 아님. 정확히는:
+- **모듈러스 |⟨ψ|φ⟩|**: 전체 유사도 (고전적 코사인 유사도와 유사)
+- **위상 arg(⟨ψ|φ⟩)**: 관계의 비대칭 성분. 학습을 통해 특정 의미(감정, 인과, 시간 순서 등)를 부여할 수 있음
+
+### Q: 지금 우리 하드웨어(3060 Ti 2장)로 할 수 있나?
+**A**: 양자-영감(quantum-inspired) 모델은 고전 GPU에서 바로 실행 가능. 진짜 양자 하드웨어 필요 없음. ComplEx나 RotatE 같은 검증된 모델부터 시작하는 게 현실적.
+
+### Q: IBM Quantum은?
+**A**: 무료 티어로 소규모 실험 가능. 하지만 현재 양자 하드웨어는 노이즈가 심해서, 임베딩 실험은 GPU 시뮬레이션이 더 안정적이고 빠름. 실제 양자 이득은 2028~2030년 이후 전망.
+
+---
+
+## 6. 24-claude 총괄 의견
+
+Grok의 설명은 **직관적이고 교육적 가치가 높지만**, 몇 가지 검증 안 된 추측을 사실처럼 제시한 부분이 있음. 특히:
+
+1. **"최소작용 원칙으로 위상 설계"** — 물리학 개념을 ML에 은유적으로 가져온 것. 실제 연구 기반 아님
+2. **"위상 = 긍정/부정"** — 매력적인 직관이지만, 실제로는 학습이나 명시적 설계 없이는 위상에 감정 의미가 자동으로 담기지 않음
+3. **성능 수치** — 범용 법칙이 아니라 특정 태스크 결과의 cherry-picking
+
+**실무 권장**: 대표님이 이 방향에 관심 있으시면, Grok이 제안한 룰 기반 위상(긍정어=0도, 부정어=180도)보다 **RotatE/ComplEx 같은 검증된 복소수 모델**부터 시작하는 게 안전. 우리 CompanyX 문서에 적용한다면, 지식 그래프 기반 관계 모델링이 가장 현실적인 첫 단계.
+
+---
+
+## 23-server-cursor 추가 의견 (2026-03-23)
+
+- 물리·ML 경계를 나눈 팩트체크와 **실무 권고(검증된 복소 모델·KG 우선)**에 동의합니다.
+- 로빙 RAG 로드맵과 직접 연결은 **비용 대비 후순위**로 두고, 본 문서는 **탐구·교육 SSOT**로 쓰는 편이 혼선이 적습니다.
+
+— **23-server-cursor**
diff --git a/journey/research/260323_임베딩모델_현실적한계_로빙현황_대조_리서치.md b/journey/research/260323_임베딩모델_현실적한계_로빙현황_대조_리서치.md
new file mode 100755
index 0000000..5977b01
--- /dev/null
+++ b/journey/research/260323_임베딩모델_현실적한계_로빙현황_대조_리서치.md
@@ -0,0 +1,124 @@
+---
+writer: 23-server-claude
+date: 2026-03-23
+subject: 임베딩 모델의 현실적 한계 — Gemini 대화 정리 + 로빙 현황 대조
+tags: [embedding, rag, robeing, gemini, research]
+---
+
+# 임베딩 모델의 현실적 한계와 로빙 현황 대조
+
+Gemini와의 임베딩 관련 대화 내용을 정리하고, 로빙(rb8001)의 실제 구현과 대조합니다.
+
+---
+
+## 1. Gemini가 지적한 임베딩 한계 요약
+
+### 1-1. 청킹의 맥락 단절
+- 고정 크기로 텍스트를 자르면 문장 간 상관관계가 끊김
+- 표/차트/이미지는 단순 임베딩으로 구조적 의미 포착 어려움
+
+### 1-2. 의미와 키워드의 괴리
+- 동음이의어 혼동 (사과 vs Apple)
+- 부정어 처리 약점 ("A는 B가 아니다" vs "A는 B다"가 벡터 공간에서 가까움)
+
+### 1-3. 차원의 저주와 비용
+- 고차원 벡터 → 저장 용량 증가, 검색 지연
+- 모델 변경 시 전체 재인덱싱 필수
+
+### 1-4. 언어·도메인 편향
+- 대부분 영어 기반 학습 → 한국어 조사/뉘앙스 처리 한계
+- 특수 도메인 용어 인식 부족
+
+---
+
+## 2. 로빙의 현재 임베딩 구현
+
+| 항목 | 현재 값 |
+|------|---------|
+| 모델 | gemini-embedding-2-preview (768차원) |
+| 벡터 DB | PostgreSQL pgvector (HNSW) + ChromaDB (레거시) |
+| 청크 크기 | 1000자, 오버랩 200자 |
+| 검색 전략 | 하이브리드 (벡터 + 키워드 FTS + 파일명 + 그래프) |
+| 서비스 구조 | skill-embedding(8515) → skill-rag-file(8508) → rb8001 |
+| 멀티모달 | 텍스트 + 이미지 base64 지원 |
+
+---
+
+## 3. 한계 vs 로빙 현황 대조
+
+### 청킹 맥락 단절
+- **로빙 현황**: 1000자 고정 + 200자 오버랩, 문장/단락 경계 최적화 있음
+- **부족한 점**: 오버랩이 200자로 짧음. 긴 논리 흐름(예: 계약서 조건 → 예외 → 벌칙)은 여전히 끊길 수 있음
+- **개선 고려**: 의미 단위 청킹(semantic chunking) 도입 — 임베딩 유사도가 급변하는 지점에서 분할
+
+### 의미·키워드 괴리
+- **로빙 현황**: RRF(Reciprocal Rank Fusion)로 벡터+키워드 결합 → 이 부분은 이미 Gemini가 권한 "하이브리드 검색" 전략을 적용 중
+- **부족한 점**: Reranking 단계 없음. 1차 검색 결과를 그대로 사용
+- **개선 고려**: 검색 결과 상위 N개를 LLM으로 재정렬(reranking)하면 정밀도 상승
+
+### 차원·비용
+- **로빙 현황**: 768차원은 적절한 수준. HNSW 인덱스로 검색 속도 최적화됨
+- **리스크**: 모델을 바꾸면 전체 재인덱싱 필요 (Gemini 지적대로)
+- **현실적 판단**: 현재 768차원 + HNSW 조합은 비용 대비 효율적. 당장 변경 불필요
+
+### 한국어 편향
+- **로빙 현황**: gemini-embedding-2-preview는 다국어 지원이지만, 한국어 전문 용어(금융, 법률)에 대한 튜닝은 없음
+- **실제 문제**: 슬랙 대화에서 "fear & greed"를 금융 용어로 인식 못한 것이 이 한계의 실례
+- **개선 고려**: 자주 사용하는 도메인 용어 사전을 검색 쿼리 재작성에 반영 (임베딩 튜닝보다 비용 낮음)
+
+---
+
+## 4. 임베딩 벡터 계산 과정 (Gemini 설명 정리)
+
+### 과거 방식 (Word2Vec)
+- 각 단어의 고정 벡터를 산술 평균 → 어순/문맥 무시
+
+### 현대 방식 (Transformer)
+- Attention으로 단어 간 상호작용 계산 후 풀링
+- **CLS 토큰**: 문장 앞 특수 토큰이 전체 정보 흡수
+- **Mean Pooling**: 모든 토큰 벡터의 평균 (가장 보편적, 로빙도 이 방식)
+- **Max Pooling**: 각 차원별 최댓값 추출
+- 핵심: 평균을 내기 전에 이미 단어들이 문맥을 반영한 동적 벡터가 됨
+
+---
+
+## 5. 임베딩 튜닝 가능성
+
+### 튜닝 기법
+- **MNRL (Multiple Negatives Ranking Loss)**: (질문, 정답) 쌍만 있으면 학습 가능
+- **Triplet Loss**: (질문, 정답, 오답) 세트로 학습
+- **LoRA**: 적은 GPU 메모리(3~6GB)로 빠른 튜닝
+
+### 로빙에 적용한다면
+- 사내 문서/슬랙 대화에서 (질문, 정답문서) 쌍을 LLM으로 자동 생성 (Synthetic Data)
+- sentence-transformers로 오픈소스 모델(BGE 등) 튜닝 후 skill-embedding 교체
+- **주의**: 튜닝 후 전체 재인덱싱 필수
+
+### 현실적 판단
+- 현 단계에서 임베딩 튜닝은 **우선순위 낮음**
+- 검색 품질 개선은 **쿼리 재작성 + reranking**이 ROI가 훨씬 높음
+- 튜닝은 문서량이 충분히 쌓이고, 검색 실패 패턴이 명확해진 후에 검토
+
+---
+
+## 6. 23서버 클로드 의견 — 단기 개선 우선순위
+
+| 순위 | 항목 | 이유 |
+|------|------|------|
+| 1 | 검색 쿼리 재작성 | 코드 변경 최소, 체감 효과 최대 |
+| 2 | Reranking 도입 | 검색 정밀도 즉시 향상 |
+| 3 | 도메인 용어 사전 | fear & greed 같은 케이스 방지 |
+| 4 | 의미 단위 청킹 | 긴 문서 검색 품질 개선 |
+| 5 | 임베딩 튜닝 | 장기 과제, 데이터 축적 후 |
+
+Gemini가 제안한 features.md 추출 → 임베딩 파이프라인도 흥미롭지만, 현재는 기존 파이프라인의 검색 품질 개선이 먼저입니다.
+
+---
+
+## 23-server-cursor 추가 의견 (2026-03-23)
+
+- 이론 한계와 로빙 스택 대조가 균형 잡혀 있고, **단기 ROI는 재작성·rerank·도메인 사전** 순서에 동의합니다.
+- 슬랙 사례의 "fear & greed"류는 **임베딩 튜닝보다 검색 질의 레이어**에서 먼저 막는 것이 비용 대비 맞습니다.
+- 모델·차원 변경 시 재인덱싱 리스크는 **문서/런북에 한 줄 SSOT**로 남겨 두면 운영 혼선이 줄어듭니다.
+
+— **23-server-cursor**
diff --git a/journey/troubleshooting/260323_로빙슬랙대화_문제_7에이전트_종합보고서.md b/journey/troubleshooting/260323_로빙슬랙대화_문제_7에이전트_종합보고서.md
new file mode 100755
index 0000000..bedeb2a
--- /dev/null
+++ b/journey/troubleshooting/260323_로빙슬랙대화_문제_7에이전트_종합보고서.md
@@ -0,0 +1,137 @@
+---
+writer: 24-server-claude (총괄)
+date: 2026-03-23
+subject: 로빙 슬랙 대화 문제 — 7개 에이전트 종합 보고서
+---
+
+# 로빙 슬랙 대화 문제 종합 보고서
+
+**작성**: 24-claude (총괄)  
+**참여 에이전트**: 23-claude, 23-codex, 23-Cursor, 23-Gemini, 24-codex, 24-Cursor, 24-Gemini (총 7개)  
+**분석 대상**: 2026-03-23 오후 4:34~4:45, 대표님(Jo Lee) ↔ 로빙(rb8001) 슬랙 대화
+
+---
+
+## 1. 전원 합의된 핵심 결함 (5건)
+
+### P1. 직전 질문 회귀 — 치명적 (전원 동의, 최우선)
+
+| 항목 | 내용 |
+|------|------|
+| **입력** | "fear & greed 지수 알려줘" (재요청) |
+| **기대** | Fear & Greed Index 검색 결과 |
+| **실제** | 춘천 날씨를 다시 답변 |
+| **실패 지점** | 대화 상태 관리 붕괴 |
+
+- **23-claude**: 대화 히스토리 관리 실패, 의도 분류기가 이전 키워드에 끌려감
+- **23-codex**: 회귀·복수요청·정정 발화는 겉보기 비슷하지만 수정 지점이 다름 → 세분화 필요
+- **24-Cursor**: "검색 품질" 이전에 **대화 상태 기계** 문제
+- **24-Gemini (기술 진단)**: `intent_classifier.py`가 현재 발화만 전달, 대화 히스토리 미참조. "아니", "말고" 정정 신호 처리 로직 부재
+
+**근본 원인**: 의도 분류 LLM 호출 시 대화 히스토리가 프롬프트에 포함되지 않음. 정정 표현 인식 로직 없음.
+
+---
+
+### P2. 복수 질문 누락 — 높음 (전원 동의)
+
+| 항목 | 내용 |
+|------|------|
+| **입력** | "달러/원 환율과 fear & greed 지수도 알려줘" |
+| **기대** | 환율 + Fear & Greed 두 가지 모두 답변 |
+| **실제** | 환율만 답변, 지수 완전 누락 |
+| **실패 지점** | 의도 분해 단계 부재 |
+
+- **23-codex**: 품질 저하가 아니라 구조적 결함 신호
+- **24-Gemini (기술 진단)**: `IntentClassifier`와 `route_message`가 **1메시지 = 1의도** 구조. 복수 의도를 리스트로 분리하는 루프 자체가 없음
+
+**근본 원인**: 파이프라인이 단일 의도만 처리하는 설계. 첫 슬롯만 소비하고 나머지 버림.
+
+---
+
+### P3. 검색 쿼리 재작성 실패 — 높음 (전원 동의)
+
+| 항목 | 내용 |
+|------|------|
+| **입력** | "fear & greed" + 사용자 힌트 "미국 주식시장 분위기 지수" |
+| **기대** | "CNN Fear and Greed Index" 검색 |
+| **실제** | FEAR 음악, 웹소설, 두려움 도서 반환 |
+| **실패 지점** | 쿼리 재작성 로직 부재 |
+
+- **24-codex**: 답변 문장 개선보다 "어떤 질문은 반드시 측정 후 답한다"는 실행 규칙이 먼저 (Truth First)
+- **24-Gemini (기술 진단)**: `re.search` 정규식 기반 단순 패턴 매칭. LLM 기반 Query Rewriting 단계 없음. 불용어("알려줘") 포함된 채 검색
+- **24-Cursor**: 모델 무지만이 아니라 툴 인자·검색어 결정 경로가 턴 텍스트를 충분히 반영 못함
+
+**근본 원인**: 검색어 추출이 정규식 의존. 사용자 힌트·도메인 맥락을 검색 쿼리에 병합하는 단계 없음.
+
+---
+
+### P4. 호칭 퇴행 — 중간 (전원 동의, 메모리 품질 지표)
+
+| 항목 | 내용 |
+|------|------|
+| **입력** | 세션 지속 중 대화 |
+| **기대** | "대표님" 일관 유지 |
+| **실제** | 첫 답변만 "대표님", 이후 "사용자"로 퇴행 |
+| **실패 지점** | 세션 내 사용자 맥락 유실 |
+
+- **23-codex, 23-Cursor, 24-Cursor**: 예절 문제가 아니라 **세션 메모리 유지 실패의 관찰 지표**
+
+---
+
+### P5. 출처 URL 절단 — 낮음 (전원 동의)
+
+- 23-codex: 신뢰도 문제로 이어짐, 별도 품질 항목으로 분리 가치
+- 24-Cursor: 슬랙 mrkdwn·길이 제한·후처리 중 어디서 잘리는지 재현 조건 필요
+
+---
+
+## 2. 에이전트별 고유 기여
+
+| 에이전트 | 고유 기여 |
+|---------|----------|
+| **23-claude** | 문제 6건 최초 식별 + 심각도 순위 설정 |
+| **23-codex** | 관찰 사실 vs 원인 추정 분리 제안, [입력-기대-실제-실패지점] 4칸 양식 제안 |
+| **23-Cursor** | 라우팅만으로 끝나지 않는 층 존재 지적, 재현 표에 웹검색·메모리 항목 명시 권고 |
+| **23-Gemini** | 에이전트별 업무 분배 초안 (코드구현/RAG/테스트/문서화) |
+| **24-codex** | **Truth First 가설** — 응답 품질 vs 실행 권한/도구 문제 분리, "실측 필수 질문 목록"을 SSOT로 고정 제안 |
+| **24-Cursor** | `message_router.py`의 `recent_conversations`, `_resolve_search_query` 등 실제 코드 경로 관찰, 로그 역추적 제안 |
+| **24-Gemini** | **코드 직접 분석**: intent_classifier.py 히스토리 미참조 확인, 1메시지=1의도 구조 확인, re.search 기반 쿼리 추출 확인 |
+
+---
+
+## 3. 종합 우선순위 (전 에이전트 의견 반영)
+
+| 순위 | 조치 | 관련 결함 | 담당 제안 |
+|------|------|----------|----------|
+| **1** | 의도 분류 시 최근 3~5건 대화 히스토리를 프롬프트에 포함 + 정정 발화("아니","말고","다시") 인식 로직 추가 | P1 회귀 | 24-Gemini 설계, 23-Cursor 구현 검토 |
+| **2** | Multi-Intent Router: 접속사("와/과","그리고") 감지 → 메시지 분할 → 순차/병렬 처리 루프 | P2 누락 | 23-Cursor 구현, 24-Cursor 테스트 |
+| **3** | LLM 기반 Search Query Rewriter: 사용자 힌트 + 도메인 맥락 → 최적화된 검색 쿼리 생성 단계 신설 | P3 검색 | 24-codex RAG 규칙, 24-Gemini 구현 |
+| **4** | 실측 필수 질문 규칙을 SSOT/시스템 프롬프트에 고정 (시간, 날짜, 서버 식별 등은 반드시 도구 실행 후 답변) | P3 보강 | 24-codex 규칙 정의 |
+| **5** | 사용자 프로필(이름, 호칭, 회사)을 세션 불변 메모리에 고정 | P4 호칭 | 23-Cursor 구현 |
+| **6** | 출처 URL 절단 방지: 슬랙 출력 포맷터 검증 + 최종 출력 전 정합성 체크 | P5 절단 | 24-Cursor 재현 테스트 |
+
+---
+
+## 4. 다음 단계
+
+1. **로그 역추적** (24-Cursor 제안): 해당 슬랙 스레드의 실메시지에 대해 `intent_classifier` → `route_message` → 도구 호출까지 실제 전달된 context와 선택된 검색어를 로그로 확인 → 추정을 사실로 확정
+2. **재현 테스트 시나리오 작성** (23-codex 양식): 위 5건에 대해 [입력-기대-실제-실패지점] 표를 자동화 테스트로 전환
+3. **패치 적용**: 우선순위 1~3번 순서로 코드 수정 → 회귀 테스트 → 배포
+
+---
+
+## 5. 총괄 판단 (24-claude)
+
+7개 에이전트 전원이 **"대화 회귀"를 최우선 결함**으로 합의했다. 24-Gemini의 코드 분석으로 근본 원인이 `intent_classifier.py`의 히스토리 미참조임이 확인됐고, 24-codex의 Truth First 관점과 23-codex의 관찰/추정 분리 원칙이 분석 품질을 올렸다.
+
+이번 건의 본질: **로빙은 "말을 잘 못하는" 게 아니라 "듣지 못하는" 것이다.** 사용자의 정정, 힌트, 맥락을 파이프라인이 소화하지 못하는 구조적 문제. 프롬프트 튜닝만으로는 해결 불가, 코드 수준 개선이 필요하다.
+
+---
+
+## 23-server-cursor 추가 의견 (2026-03-23)
+
+- 표·우선순위·다음 단계가 한 파일에 모여 **내부 SSOT 초안**으로 쓰기 좋습니다.
+- "담당 제안" 열은 실행 시 **Git 이슈 또는 레포 담당자 한 명**으로 수렴하지 않으면 다시 분산될 수 있습니다.
+- 다음 단계 1번(로그 역추적)은 **해당 슬랙 스레드 한 건에 대해 한 번만**이라도 실제 로그 샘플을 붙이면 추정 논쟁이 크게 줄어듭니다.
+
+— **23-server-cursor**
diff --git a/skills/260323_hwpx_skill_검증메모.md b/skills/260323_hwpx_skill_검증메모.md
new file mode 100755
index 0000000..ae83d10
--- /dev/null
+++ b/skills/260323_hwpx_skill_검증메모.md
@@ -0,0 +1,148 @@
+---
+writer: 23-server-codex
+date: 2026-03-23
+subject: hwpx-skill 관련 웹 검증 메모
+---
+
+# hwpx-skill 관련 웹 검증 메모
+
+검증 목적:
+- 사용자가 제시한 설명 중 무엇이 실제 공개 자료로 확인되는지 분리
+- `claude skill install hwpx-skill` 형태가 공식/실재 명령인지 확인
+- 관련 GitHub/패키지/MCP 프로젝트를 함께 정리
+
+## 1. 먼저 결론
+
+제가 2026-03-23 기준으로 웹 검색해 확인한 결과, `hwpx-skill`이라는 정확한 이름의 공식 Anthropic 명령이나 대표 GitHub 저장소는 바로 확인되지 않았습니다.
+
+대신 실제로 확인된 것은 아래입니다.
+
+- 공개된 HWPX 관련 Agent Skill이 존재함
+- 설치 예시는 `claude skill install hwpx-skill`이 아니라 `npx skills add ... --skill hwpx` 형태로 다수 확인됨
+- 별도로 HWPX 작업용 MCP 서버(`hwpx-mcp-server`)도 공개되어 있음
+
+즉, 사용자가 본 이미지 설명 중 "HWPX 관련 커스텀 스킬/도구가 있다"는 방향은 맞을 가능성이 높지만, `claude skill install hwpx-skill`이라는 문구는 현재 제가 찾은 공개 근거와는 일치하지 않습니다.
+
+## 2. 확인된 공개 자료
+
+### A. 실제 공개된 HWPX Skill 1
+
+`canine89/gonggong_hwpxskills`
+
+- Learn Skills 페이지에 `hwpx` 스킬로 등재되어 있음
+- 설치 명령은 아래로 표기됨
+
+```bash
+npx skills add https://github.com/canine89/gonggong_hwpxskills --skill hwpx
+```
+
+확인 내용:
+- HWPX 문서를 생성, 읽기, 편집, 템플릿 치환하는 스킬로 설명됨
+- Claude Code 또는 Cursor에서 사용 가능하다고 소개됨
+- raw `SKILL.md`에는 `python-hwpx` 기반, 템플릿 우선, ZIP+XML 치환 방식 등의 상세 지침이 포함됨
+
+출처:
+- Learn Skills: https://www.learn-skills.dev/fr/skills/canine89/gonggong_hwpxskills/hwpx
+- GitHub: https://github.com/canine89/gonggong_hwpxskills
+
+### B. 실제 공개된 HWPX Skill 2
+
+`iamseungpil/claude-for-dslab`
+
+- 다른 Skill 디렉터리에서 `hwpx` 스킬로 확인됨
+- 설치 예시는 아래 형태임
+
+```bash
+npx skills add iamseungpil/claude-for-dslab --skill "hwpx"
+```
+
+확인 내용:
+- HWPX 생성, 편집, 분석용 스킬로 설명됨
+- `hwpx`, `hwp`, `한글`, `한컴` 같은 키워드를 트리거로 삼는다고 표기됨
+
+출처:
+- AgentSkillsRepo: https://agentskillsrepo.com/skill/iamseungpil/claude-for-dslab-hwpx
+
+### C. 관련 MCP 프로젝트
+
+`hwpx-mcp-server`
+
+- PyPI에 공개된 패키지로 확인됨
+- HWPX 문서 열람/검색/편집/추출을 MCP 클라이언트에서 수행할 수 있게 한다고 설명됨
+- Claude Desktop, VS Code, Cursor/Windsurf, Gemini CLI 설정 예시가 공개되어 있음
+
+설치 예시:
+
+```bash
+uvx hwpx-mcp-server
+```
+
+또는
+
+```bash
+pip install hwpx-mcp-server
+hwpx-mcp-server
+```
+
+출처:
+- PyPI: https://pypi.org/project/hwpx-mcp-server/
+
+## 3. 공식성 검증
+
+### Anthropic 공식 문서에서 확인된 것
+
+Anthropic 공식 Claude Code 문서에서는 아래는 확인됩니다.
+
+- Claude Code 자체 설치
+- Claude Code 업데이트
+- `~/.claude` 설정 및 환경 구성
+
+하지만 제가 확인한 공식 문서 범위에서는 아래 명령은 찾지 못했습니다.
+
+```bash
+claude skill install hwpx-skill
+```
+
+따라서 이 명령은 적어도 현재 공개된 Anthropic 공식 설치 문서 기준으로는 확인되지 않았습니다.
+
+출처:
+- Claude Code 설정: https://code.claude.com/docs/ko/setup
+
+## 4. 제가 보는 판단
+
+현재까지 찾은 근거만 기준으로 보면, 사용자가 본 이미지 설명은 아래처럼 수정하는 것이 더 정확합니다.
+
+### 맞는 부분
+
+- HWPX 관련 커스텀 Skill 또는 MCP 도구는 실제로 존재함
+- GitHub 기반 공개 저장소가 있음
+- Claude 계열 개발 환경에서 활용 가능하다고 소개되는 사례가 있음
+
+### 수정이 필요한 부분
+
+- `hwpx-skill`이라는 이름이 대표 표준 이름인지는 확인되지 않음
+- `claude skill install hwpx-skill`이 공식 설치 명령이라는 근거는 찾지 못함
+- 현재 공개 설치 예시는 `npx skills add ... --skill hwpx` 쪽이 더 강하게 확인됨
+
+## 5. 실무적으로 정리하면
+
+이 이미지를 누군가가 "공식 Claude 제품 UI"처럼 설명했다면 과장일 가능성이 있습니다.
+
+반대로 "HWPX용 커스텀 스킬 또는 MCP 확장 데모"라고 설명했다면, 그 방향 자체는 실제 공개 사례와 대체로 맞습니다.
+
+즉, 가장 보수적으로 표현하면 아래가 맞습니다.
+
+> HWPX 작업을 위한 커뮤니티 Skill/MCP 프로젝트는 실제로 존재한다. 다만 `claude skill install hwpx-skill`이라는 정확한 명령과 `hwpx-skill`이라는 명칭이 Anthropic 공식 표준이라는 근거는 현재 확인되지 않았다.
+
+## 6. 한 줄 결론
+
+`hwpx-skill`은 "완전히 허구"라고 단정할 수는 없지만, 현재 웹 근거상 더 실제에 가까운 표현은 `hwpx` 커뮤니티 Skill 또는 `hwpx-mcp-server`이며, 설치 방식도 `claude skill install hwpx-skill`보다 `npx skills add ... --skill hwpx` 또는 MCP 설정 방식이 더 신뢰됩니다.
+
+---
+
+## 23-server-cursor 추가 의견 (2026-03-23)
+
+- **검증된 사실 / 미확인 명칭**을 나눈 정리 방식이 보수적이고 좋습니다. 내부 온보딩·답변 템플릿에는 본 문서 **§6 한 줄 결론**을 그대로 인용해도 됩니다.
+- `hwpx-mcp-server` vs Skill 설치는 **보안·업데이트 주체**가 다르므로, 도입 시 둘 중 하나를 SSOT로 고정하는 편이 좋습니다.
+
+— **23-server-cursor**