From 91da900bc450b7e677de04b9abee5ec64cb4b0b4 Mon Sep 17 00:00:00 2001
From: happybell80 <happybell80@naver.com>
Date: Mon, 9 Mar 2026 22:33:33 +0900
Subject: [PATCH] docs: relocate non-robeing journey records

---
 book/600_appendix/650_용어집.md            |   1 -
 ...��결정_로직_로빙_적용_리서치.md |  70 -----
 journey/research/README.md                    |   1 -
 ...727_happybell80_51124서버이전작업.md | 261 ------------------
 4 files changed, 333 deletions(-)
 delete mode 100644 journey/research/260303_구카_평가결정_로직_로빙_적용_리서치.md
 delete mode 100644 journey/troubleshooting/250727_happybell80_51124서버이전작업.md

diff --git a/book/600_appendix/650_용어집.md b/book/600_appendix/650_용어집.md
index 4e37b0a..78d3537 100644
--- a/book/600_appendix/650_용어집.md
+++ b/book/600_appendix/650_용어집.md
@@ -106,7 +106,6 @@ Docker 컨테이너의 기본이 되는 이미지. chroma_vector:1.0은 ChromaDB
 접속이라는 사건을 통해 존재가 확정되는 최소 지능 단위. "존재는 접속이다" 철학을 기술 명세로 담은 용어. 공식 표기: 연결 사건 단위.
 관련 문서:
 - [130_존재형_에이전트란_무엇인가](../100_philosophy/130_존재형_에이전트란_무엇인가.md)
-- [260303_구카_평가결정_로직_로빙_적용_리서치](../../journey/research/260303_구카_평가결정_로직_로빙_적용_리서치.md)
 
 ### 작동적 존재 (Operational Existence)
 접속 이벤트가 발생한 순간, 실제 판단·응답·행동이 실행되는 존재 상태. 운영 로그에서 검증 가능한 상태를 의미한다.
diff --git a/journey/research/260303_구카_평가결정_로직_로빙_적용_리서치.md b/journey/research/260303_구카_평가결정_로직_로빙_적용_리서치.md
deleted file mode 100644
index c8b8cb4..0000000
--- a/journey/research/260303_구카_평가결정_로직_로빙_적용_리서치.md
+++ /dev/null
@@ -1,70 +0,0 @@
-# 260303 구카 평가·결정 로직 로빙 적용 리서치
-
-## 목적
-- TheGooseCouncil(구카)의 평가/결정 체계에서 로빙 운영에 즉시 인용 가능한 규칙을 추출한다.
-
-## 확인한 원문(근거)
-- `/home/admin/TheGooseCouncil/DOCS/00_JOURNEY_OUT/07_ENGINEERING/Scoring_Formula_v1.md`
-- `/home/admin/TheGooseCouncil/DOCS/00_JOURNEY_OUT/03_EVALUATION/Evaluation_Framework.md`
-- `/home/admin/TheGooseCouncil/DOCS/00_JOURNEY_OUT/07_ENGINEERING/Policy_Externalization_and_Auto_Evolution.md`
-- `/home/admin/TheGooseCouncil/DOCS/00_JOURNEY_OUT/06_OPERATIONS/Failure_Prevention_Principles.md`
-- `/home/admin/TheGooseCouncil/tests/test_value_state_decision.py`
-
-## 구카에서 인용할 핵심
-1. 4축 고정 점수 + 컷오프 + 동점 규칙
-- 점수축: `feasibility`, `goal_fit`, `differentiation`, `risk_control`
-- 컷오프: `F < 50` 또는 `R < 40` 자동 탈락
-- 동점 우선순위: `F` > `R` > 근거 품질
-
-2. 2층 평가 루프(Judge-of-Judge)
-- 1층: 전략/산출물 점수
-- 2층: 평가자 메타점수(정확도/일관성/공정성/설명력)
-- 루프: `전략 평가 -> 메타평가 -> 다음 라운드 가중치 갱신`
-
-3. 평가자 신뢰도 동적 갱신
-- 평가자 계수 `Q`를 고정하지 않고 라운드 증거 기반으로 갱신
-- 운영식 예시: `PosteriorQ = (1-alpha)*PriorQ + alpha*EvidenceScore`
-
-4. 집계 안정화 규칙
-- 평가자별 보정 점수 집계에 평균(mean) 대신 `median` 사용
-- 이상치 평가자 영향 완화 목적
-
-5. 정책 외부화(코드 하드코딩 금지)
-- 가중치/컷오프/선발기준/라우팅을 정책 저장소(DB/버전)로 분리
-- 롤백 가능한 정책 버전 운영
-
-6. 운영 게이트 강제
-- 완료 보고 전 검증 로그 확보
-- 네트워크 검증 타임아웃 필수
-- 광범위 fallback 남용 금지
-
-## 로빙 적용 제안 (우선순위)
-### P0 (즉시)
-- 로빙의 핵심 의사결정에 `하드 컷오프` 도입
-  - 예: 인증/연결/데이터 무결성 기준 미달 시 자동 탈락(우회 금지)
-- 점수 동률/경합 상황에 동점 규칙 명시
-  - 운영 안정성 > 목적 적합성 > 근거 품질 순
-- 완료 전 게이트 고정
-  - 의존성 스캔 -> 포트 매트릭스 -> 핵심 API 실호출 -> 로그 교차검증
-
-### P1 (단기)
-- 평가자 신뢰도 개념 도입
-  - 사람/서비스/에이전트 판단 결과에 신뢰도 계수 적용
-- 집계 함수에 median 우선 적용
-  - 단일 이상치로 전체 의사결정이 흔들리지 않도록 방어
-
-### P2 (중기)
-- 정책 외부화
-  - 하드코딩된 임계치/가중치를 정책 버전으로 분리
-  - 변경 이력, 롤백, 변경 폭 제한 운영
-
-## 로빙에 바로 쓰는 결정 템플릿
-1. 입력 검증/하드 컷오프 적용
-2. 4축 점수 계산(가중치 버전 명시)
-3. 동점 규칙 적용
-4. 메타평가 반영 신뢰도 보정
-5. 최종 결정 + 근거 3줄 + 감사 로그 저장
-
-## 주의사항
-- 구카의 수치(가중치/컷오프)를 그대로 복제하지 말고, 로빙 운영 데이터로 재보정해야 한다.
-- 규칙은 코드가 아니라 정책 버전으로 관리해야 재발 방지와 롤백이 가능하다.
diff --git a/journey/research/README.md b/journey/research/README.md
index 3b465b9..eb46ba2 100644
--- a/journey/research/README.md
+++ b/journey/research/README.md
@@ -59,7 +59,6 @@
 ### [오케스트레이션·에이전트 플랫폼(Orchestration Tools)](./orchestration_tools/README.md)
 - LangGraph vs n8n 비교
 - OpenClaw 아키텍처 및 로빙 적용 리서치
-- [구카 평가·결정 로직 로빙 적용 리서치 (260303)](./260303_구카_평가결정_로직_로빙_적용_리서치.md)
 - [자기개선 루프 구현을 위한 DB/서비스 리서치 (260303)](./260303_자기개선루프_DB_서비스_구현_리서치.md)
 
 ## 로빙을 위한 체크리스트
diff --git a/journey/troubleshooting/250727_happybell80_51124서버이전작업.md b/journey/troubleshooting/250727_happybell80_51124서버이전작업.md
deleted file mode 100644
index 5c0ca12..0000000
--- a/journey/troubleshooting/250727_happybell80_51124서버이전작업.md
+++ /dev/null
@@ -1,261 +0,0 @@
-# 51124 서버 이전 작업 및 nginx 프록시 설정
-
-**날짜**: 2025-07-27  
-**작업자**: happybell80 & Claude  
-**관련 서버**: 51123 (nginx 프록시), 51124 (로빙 컨테이너 호스팅)
-
-## 배경
-
-로빙 프로젝트의 확장을 위해 더 강력한 CPU를 가진 51124 서버로 로빙 컨테이너들을 이전하는 작업을 진행했습니다.
-- 51123 서버: nginx 프록시 및 기타 유틸리티 서비스 담당
-- 51124 서버: 모든 로빙(rb8001, rb10408, rb10508) 및 스킬 서비스 실행
-
-## 오전 1시 00분 - 51124 서버 초기 환경 구축
-
-### 서버 정보
-- 서버 ID: 51124
-- IP: 192.168.219.52
-- SSH 포트: 51124 (커스텀 포트)
-- 역할: Docker 컨테이너 호스팅
-
-### Docker 환경 확인 및 설정
-```bash
-# Docker 버전 확인 (v28.3.2 이미 설치됨)
-docker --version
-
-# docker-compose 추가 설치
-sudo apt update
-sudo apt install -y docker-compose
-
-# 프로젝트 구조 생성
-cd ~
-mkdir -p ivada_project
-cd ivada_project
-mkdir -p rb8001 rb10408_test rb10508_test skill_email skill_news
-```
-
-### Gitea 저장소 클론
-```bash
-git clone https://happybell80:[TOKEN]@git.ro-being.com/ivada_Ro-being/rb10508_test.git
-cd rb10508_test
-
-# Git 설정
-git config --global user.name "happybell80"
-git config --global user.email "happybell80@ro-being.com"
-```
-
-### 환경변수 설정
-`.env` 파일 생성:
-- Slack API 토큰 (BOT_TOKEN, SIGNING_SECRET, APP_TOKEN)
-- AI API 키 (OpenAI, Gemini, Perplexity)
-- Database 설정
-- JWT 설정
-
-## 오전 1시 15분 - 컨테이너 권한 문제 해결
-
-### 문제 발생
-```bash
-docker ps
-# STATUS: Restarting (1) X seconds ago
-
-docker logs rb10508_test
-# PermissionError: [Errno 13] Permission denied: '/code/logs/rb10508_test_app.log'
-```
-
-### 원인
-Docker 컨테이너 내부의 appuser가 로그 디렉토리에 쓰기 권한이 없음
-
-### 해결 방법
-```bash
-# 컨테이너 중지
-docker-compose down
-
-# 필요한 디렉토리 생성 및 권한 설정
-mkdir -p logs chroma_db
-sudo chmod 777 logs chroma_db
-
-# 컨테이너 재시작
-docker-compose up -d
-```
-
-### 결과
-```bash
-docker ps | grep rb10508
-# STATUS: Up X minutes (healthy)
-
-curl http://localhost:10508/health
-# {"status":"healthy"}
-```
-
-## 오전 1시 30분 - SSH 키 교환 작업
-
-### 51124 서버 측 작업
-```bash
-# SSH 디렉토리 생성
-mkdir -p ~/.ssh
-chmod 700 ~/.ssh
-
-# SSH 키 생성 (배포용)
-ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_deploy -N ""
-```
-
-### 51123 서버 측 작업
-```bash
-# SSH 키 생성
-ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_51123_to_51124 -N "" -C "51123-to-51124-deploy"
-
-# 생성된 공개키를 51124 서버의 authorized_keys에 추가
-# (51124 서버에서 실행)
-echo "[51123 공개키 내용]" >> ~/.ssh/authorized_keys
-chmod 600 ~/.ssh/authorized_keys
-
-# SSH 연결 테스트
-ssh -p 51124 -i ~/.ssh/id_rsa_51123_to_51124 -o StrictHostKeyChecking=no admin@192.168.219.52 "echo '연결 성공!'"
-```
-
-### Gitea Actions 시크릿 설정
-Organization 레벨에서 다음 시크릿 등록:
-- SSH_PRIVATE_KEY_51124: 51123 서버의 개인키
-- SSH_HOST_51124: 192.168.219.52
-
-## 오전 2시 00분 - nginx 프록시 설정 및 문제 해결
-
-### 초기 nginx 설정
-```nginx
-# 51123 서버의 nginx 설정에 추가
-location /rb10508/ {
-    proxy_pass http://192.168.219.52:10508/;
-    proxy_set_header Host $host;
-    proxy_set_header X-Real-IP $remote_addr;
-    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-    proxy_set_header X-Forwarded-Proto $scheme;
-}
-```
-
-### 문제 1: location 우선순위 문제
-**증상**: `/rb10508/health` 요청 시 API 응답 대신 React 프론트엔드 HTML 반환
-
-**원인**: `location /` 블록의 `try_files`가 모든 요청을 처리
-
-**해결**: `^~` 플래그 추가로 우선순위 강제
-```nginx
-location ^~ /rb10508/ {
-    proxy_pass http://192.168.219.52:10508/;
-    # ... 나머지 설정
-}
-```
-
-### 문제 2: HTTP/HTTPS 서버 블록 분리 문제
-**증상**: HTTP localhost 요청 시 여전히 프론트엔드 반환
-
-**원인 분석**:
-```bash
-# HTTP localhost → 프론트엔드 반환
-curl http://localhost/rb10508/health  # HTML 반환
-
-# HTTPS localhost → 정상 작동
-curl -k https://localhost/rb10508/health  # {"status":"healthy"}
-```
-
-**근본 원인**:
-- 포트 80 default_server 블록에는 프록시 설정 없음
-- 포트 443 ro-being.com 블록에만 프록시 설정 있음
-- localhost HTTP 요청은 첫 번째 블록이 처리
-
-### 해결 방안 검토
-| 옵션 | 내용 | 장점 | 단점 |
-|------|------|------|------|
-| 1 | 첫 번째 server 블록에도 프록시 설정 추가 | 로컬 HTTP 요청 동작 | 설정 중복 |
-| 2 | 모든 HTTP를 HTTPS로 리다이렉트 | 보안 강화, 표준 방식 | 로컬 개발 시 인증서 필요 |
-| 3 | default_server 최소화 | 설정 명확성 | 로컬 테스트 불편 |
-
-## 오전 2시 30분 - Gitea Actions 워크플로우 수정
-
-### 문제: SSH 키 처리 방식
-초기 워크플로우에서 SSH 키를 직접 전달하여 오류 발생
-
-### 해결: SSH 키를 파일로 저장
-```yaml
-- name: Setup SSH
-  run: |
-    echo "🔑 Setting up SSH..."
-    mkdir -p ~/.ssh
-    echo "${{ secrets.SSH_PRIVATE_KEY_51124 }}" > ~/.ssh/deploy_key
-    chmod 600 ~/.ssh/deploy_key
-    ssh-keyscan -H ${{ secrets.SSH_HOST_51124 }} >> ~/.ssh/known_hosts
-
-- name: Deploy to 51124 Server
-  run: |
-    ssh -i ~/.ssh/deploy_key admin@${{ secrets.SSH_HOST_51124 }} << 'EOF'
-      # 배포 스크립트
-    EOF
-
-- name: Cleanup SSH
-  run: |
-    rm -f ~/.ssh/deploy_key
-```
-
-## 최종 상태 및 결과
-
-### ✅ 완료된 작업
-1. **51124 서버 환경 구축**
-   - Docker & docker-compose 설치 및 설정
-   - 프로젝트 디렉토리 구조 생성
-   - 환경변수 설정
-
-2. **컨테이너 정상화**
-   - 권한 문제 해결 (chmod 777)
-   - 헬스체크 정상 응답
-
-3. **네트워크 설정**
-   - 51123 → 51124 연결 확인
-   - nginx 프록시 설정 (HTTPS 정상 작동)
-
-4. **자동 배포 준비**
-   - SSH 키 교환 완료
-   - Gitea Actions 워크플로우 수정
-   - Organization 시크릿 설정
-
-### 📊 현재 작동 상태
-- ✅ 51124 컨테이너: 정상 작동 (healthy)
-- ✅ HTTPS 프록시: 정상 (`https://ro-being.com/rb10508/health`)
-- ✅ SSH 연결: 정상 (포트 51124)
-- ⚠️ HTTP localhost: 추가 설정 필요
-
-### 🔄 배포 플로우
-```
-로컬 push → Gitea Actions (51123) → SSH (포트 51124) → 51124 배포 
-→ Docker 컨테이너 실행 → nginx 프록시 (51123) → 사용자 접속
-```
-
-## 교훈
-
-1. **Docker 권한 관리**
-   - 컨테이너가 쓰기 권한이 필요한 디렉토리는 미리 생성하고 적절한 권한 설정 필수
-   - `network_mode: host` 사용 시 포트 매핑 불필요
-
-2. **nginx location 매칭 이해**
-   - server 블록별로 location 설정이 독립적
-   - `^~` 플래그로 우선순위 제어 가능
-   - default_server의 영향 범위 고려 필요
-
-3. **SSH 자동화 설정**
-   - Gitea Actions에서 SSH 키는 파일로 저장 후 사용
-   - 커스텀 SSH 포트 사용 시 명시적 지정 필요
-   - authorized_keys 권한은 반드시 600
-
-4. **트러블슈팅 접근법**
-   - 로그 우선 확인 (`docker logs`, nginx 액세스 로그)
-   - 네트워크 경로별 테스트 (localhost vs 도메인, HTTP vs HTTPS)
-   - 권한 문제는 대부분 디렉토리/파일 권한으로 해결
-
-5. **아키텍처 설계**
-   - 프록시 서버와 애플리케이션 서버 분리의 장점 확인
-   - 각 서버의 역할을 명확히 정의하면 관리 용이
-
-## 다음 단계
-
-1. nginx HTTP 처리 방식 결정 (옵션 2 추천: HTTPS 리다이렉트)
-2. 나머지 로빙 서비스 (rb8001, rb10408) 이전
-3. PostgreSQL 연결 설정 확인
-4. 프로덕션 환경변수 실제값 설정
\ No newline at end of file