# 260304 자기개선루프·프롬프트DB 23/로컬/24 통합 실행기록 **작성일**: 2026-03-04 **상태**: 완료 (23/로컬/24 교차검증 완료) **용도**: 로컬/23/24가 같은 문서에 실행 상태를 누적 기록 **연결 계획 문서**: - [자기개선 루프 DB/서비스 구현 실행계획](./260303_자기개선루프_DB_구현_실행계획.md) - [프롬프트 동적 관리 시스템 계획](./251225_프롬프트_동적관리_계획.md) - [23(테스트+보조)/24(프로덕션) 운영 전환 계획](./260303_23테스트보조_24프로덕션_운영전환_계획.md) --- ## 0. 공통 원칙 1. 배포·검증 순서: `23 선검증 -> 24 교차검증 -> 완료 판정` 2. 완료 판정은 `운영 경유 증거(응답/로그)` 기반으로만 수행 3. gateway 단일 진입 원칙: 신규 API는 `경로 + HTTP 메서드` 모두 검증 ## 1. 23 서버 완료 항목 (2026-03-04 기준) ### 1-1. 게이트웨이 프록시 메서드/헤더 보완 완료 - 대상: `robeing-gateway/app/main.py` - 반영 내용: - `/api/{path:path}` 프록시를 `GET/POST/PUT/PATCH/DELETE`로 확장 - upstream 전달 시 원본 요청 헤더(`Content-Type` 포함) 전달 - 보안/추적 헤더 강제: `X-User-Id`, `X-Run-Id`, `Authorization` - 반영 커밋: - `robeing-gateway` `main` -> `5b97bea` - 커밋 메시지: `fix: forward content-type and methods in gateway api proxy` ### 1-2. 운영 검증 결과(23) - 게이트웨이 컨테이너 상태: `healthy` - 이전 이슈: `POST /api/self-improvement/*`, `POST /api/prompt-db/*` -> `405`/`422` - 현재 상태(수정 후): - `POST /api/self-improvement/policy-versions` via `8100` -> `200` - `POST /api/self-improvement/runs` via `8100` -> `200` - `POST /api/prompt-db/templates` via `8100` -> `200` - 결론: - 23 게이트웨이 경유 POST 차단/바디 파싱 문제 해소 ### 1-3. Slack 403 분리 확인(23) - 확인 사실: - `X-User-Id`, `X-Run-Id` 전파는 정상 - 올바른 team_id 매핑에서 bot token/UUID 조회 정상 - 최종 403은 `rb8001`의 Slack 서명 검증 단계(`Invalid signature`)에서 발생 - 결론: - 게이트웨이 전파 계층 이슈와 Slack 서명 이슈는 분리 관리 필요 ## 2. 로컬 진행 기록 (이어쓰기) - 상태: 진행 중 - 기록 규칙: 날짜/커밋/검증명령/결과를 한 줄씩 추가 예시 템플릿: - `2026-03-04 | @ | | pass/fail | ` 실행 기록: - `2026-03-04 01:04 KST | ivada/* | for d in /home/happybell/projects/ivada/*; git -C "$d" status -sb | pass | 전체 레포 origin/main 동기화 상태 확인(로컬 변경 없음)` - `2026-03-04 01:05 KST | rb8001@3532600 | rg -n "X-Run-Id|record_message_self_improvement_artifacts|run_id" app/router/message_endpoint.py | pass | /api/message에서 run_id 생성/응답 포함 및 추적 서비스 호출 경로 확인` - `2026-03-04 01:05 KST | rb8001@3532600 | rg -n "create_self_improvement_run|log_prompt_event" app/services/message_tracking_service.py | pass | 메시지 처리 시 자기개선 run/프롬프트 이벤트 저장 함수 연결 확인` - `2026-03-04 01:05 KST | robeing-gateway@5b97bea | rg -n "X-Run-Id|run_id" app/main.py | pass | gateway에서 X-Run-Id 생성/전파 및 응답 run_id 보정 로직 확인` - `2026-03-04 01:05 KST | robeing-monitor@1221596 | git rev-parse --short HEAD | pass | 24 반영 추적용 최신 커밋 해시 동기화 확인` 로컬 한계(고정): - 로컬은 코드/정적 경로 검증까지만 완료 가능 - 23/24 운영 반영, 컨테이너 상태, gateway 경유 실트래픽 E2E는 서버 측 증거로 별도 판정 ## 3. 24 서버 교차검증 기록 (이어쓰기) - 상태: 완료 - 필수 검증 항목: 1. `gateway(8100) -> rb8001` 경유 POST 3종(정책/런/템플릿) 응답 검증 2. 동일 JWT·동일 payload 기준 direct(8001) vs gateway(8100) 결과 비교 3. `run_id` 전파 및 저장 일관성 검증 4. 로그 대조: gateway/ rb8001 동일 시각대 요청 단위 확인 ### 3-1. 24 서버 확인 기록 (2026-03-04 KST) - `2026-03-04 01:00 | rb8001 컨테이너 재기동 확인 | docker ps | Up (healthy) 확인` - `2026-03-04 01:00 | LangGraph 메인 경로 설정 확인 | docker exec rb8001 env | INTENT_ENGINE=graph, INTENT_USE_LANGGRAPH=true` - `2026-03-04 01:01 | 서비스 헬스 확인 | curl http://localhost:8001/health | {"status":"healthy"} 응답 확인` - `2026-03-04 01:01 | 비고 | 24에서 확인 가능한 운영값/헬스 반영 완료, gateway(8100) JWT 교차검증은 유효 토큰 기준 추가 수행 필요` ### 3-2. 24 교차검증 실행 결과 (2026-03-04 01:09 KST) - 테스트 마커: - `marker=cv24_1772554158` - `run_id=8670eee3-d60e-4ac2-9fd2-42dfa1220dde` - 동일 JWT/동일 payload 비교 결과: - `POST /api/self-improvement/policy-versions` - gateway(8100): `200` - direct(8001): `200` - `POST /api/self-improvement/runs` - gateway(8100): `200` - direct(8001): 최초 비교 시 `500`(동일 run_id 재삽입으로 PK 충돌), 신규 run_id 재검증 시 `200` - `POST /api/prompt-db/templates` - gateway(8100): `200` - direct(8001): `200` - run_id 저장/조회 일관성: - `GET /api/self-improvement/runs/{run_id}` gateway/direct 모두 `200` 동일 run 조회 성공 - `GET /api/self-improvement/runs?robeing_id=rb8001&limit=3` gateway/direct 모두 `200` - 로그 교차 대조: - gateway 로그: `POST /api/self-improvement/policy-versions 200`, `POST /api/self-improvement/runs 200`, `POST /api/prompt-db/templates 200`, `GET /api/self-improvement/runs/{run_id} 200` - rb8001 로그: `192.168.0.100` 소스에서 동일 경로/시각대 요청 확인 - direct 500 원인 로그: `Key (run_id)=(8670eee3-d60e-4ac2-9fd2-42dfa1220dde) already exists` (재삽입 충돌) ## 4. 완료 조건 1. 23 선검증 결과와 24 교차검증 결과가 모두 정상 2. 핵심 API(정책/런/프롬프트DB) gateway 경유 E2E 증거 확보 3. 최종 상태를 본 문서와 대응 troubleshooting 문서에 동기화 ## 5. 최종 판정 (2026-03-04) - 본 문서 범위(게이트웨이 경유 자기개선/prompt-db 교차검증)는 완료. - 23 gateway 계층의 `POST 405/422` 이슈는 해소되었고, 24에서 운영 경유 증거까지 확인됨. - Slack `Invalid signature`는 별도 운영 이슈로 분리 관리(본 완료 판정 범위 밖). ## 6. 후속 운영 안정화 기록 (2026-03-04 03:00~03:30 KST) 1. 51123 스킬 가동 상태 보강 - `skill-news(8505)`, `skill-slack(8502)`, `skill-rag-file(8508)`, `skill-embedding(8515)` 모두 healthy 복구. 2. 장애 원인 확정 - `skill-embedding` 부팅 실패 원인은 ONNX 모델 파일 부재(`model.onnx`)로 확정. - `jhgan/ko-sroberta-multitask` ONNX 생성 후 재기동으로 정상화. 3. 23/24 자동배포 안전화 반영(푸시 완료) - `skill-rag-file`: `ab3ac78` - compose 경로를 `DOCUMENT_MOUNT_ROOT`/`DOCUMENT_BASE_PATH`로 일반화. - `skill-embedding`: `5a0f357`, `ede5896` - compose 경로를 `ONNX_MODELS_HOST_PATH` 기반으로 일반화. - 24 기본값은 `/home/admin/ivada_project/onnx_models`, 23은 `.env` 오버라이드. 4. workflow 점검 결론 - `rb8001`, `skill-*`, `robeing-monitor` workflow 파일 점검 완료. - 본 이슈 기준 추가 YAML 필수 수정사항 없음(경로 이슈는 compose/.env 일반화로 해소).