docs: 프롬프트 DB 문서 세트 보강 — 리서치 결과 반영

- 트러블슈팅 #3: 확정 항목 추가 (주입 계층, P1 대상, fallback 정책)
- 트러블슈팅 #7: 24건 인벤토리 확정, 이관 우선순위 반영
- 계획: 인벤토리 목록화 체크리스트 완료 처리
- 리서치: 캐싱 전략 상세 보강 (TTL, 무효화, 실패 처리)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

journey/plans/251225_프롬프트_동적관리_계획.md

@@ -311,7 +311,7 @@
 ## 11. 체크리스트 (누락 방지)
 
 ### 설계
-- [ ] 실제 하드코딩 인벤토리 목록화 완료
+- [x] 실제 하드코딩 인벤토리 목록화 완료 (2026-03-19, 24건 확인. [전수 조사 리서치](../research/260319_프롬프트DB_폐루프_및_하드코딩_잔존_전수조사_리서치.md) §3)
 - [ ] scope 우선순위 충돌 규칙 정의
 - [ ] 안전 제약(금지 규칙) 최종 우선순위 명시
 

journey/research/260319_프롬프트DB_폐루프_및_하드코딩_잔존_전수조사_리서치.md

@@ -172,15 +172,28 @@ P1 3건의 현재 하드코딩 내용을 DB `prompt_versions`에 v1으로 적재
   └─ (worklog 작성 예정)                                ← 단계별 종결 시 작성
 ```
 
-## 9. 리스크
+## 9. 캐싱 전략
+
+프롬프트는 매 요청마다 변하지 않으므로 메모리 캐싱이 필수.
+
+| 항목 | 값 | 근거 |
+|------|---|------|
+| 캐시 위치 | `llm_service.py` 내 모듈 레벨 dict | 프로세스 내 공유, 외부 의존 없음 |
+| TTL | 60초 | 프롬프트 변경 빈도 낮음, 1분 내 반영이면 운영 충분 |
+| 캐시 키 | `template_key` | 1:1 매핑 |
+| 무효화 | TTL 만료 시 자동. 즉시 반영 필요 시 컨테이너 재시작 또는 `/api/prompt-db/cache/invalidate` 엔드포인트 추가 (2단계에서 검토) |
+| 실패 처리 | 캐시 miss + DB 조회 실패 → 하드코딩 fallback (`safe_prod`) |
+
+## 10. 리스크
 
 | 리스크 | 대응 |
 |--------|------|
-| DB 조회 지연으로 응답 속도 저하 | 프롬프트 캐싱 (TTL 60초 권장) |
+| DB 조회 지연으로 응답 속도 저하 | 캐싱으로 해소 (§9). 첫 요청만 DB 조회, 이후 60초간 메모리 |
 | DB 장애 시 응답 불가 | 하드코딩 fallback 유지 (`safe_prod` 모드) |
 | 23에서 rb8001 코드 동시 수정 중 | P1 수정 범위가 `llm_service.py` 1곳으로 좁아 충돌 가능성 낮음, 단 사전 확인 필요 |
+| 캐시와 DB 불일치 | 최대 60초 지연 허용. 즉시 반영이 필요한 장애 대응은 컨테이너 재시작으로 해소 |
 
-## 10. 결론
+## 11. 결론
 
 - 폐루프 연결은 `llm_service.py` 1곳 수정으로 가능. 이미 검증된 `system_instruction` + `skip_default_prompt` 패턴 활용.
 - 하드코딩 프롬프트 총 24건 확인. P1(3건) → P2(8건) → P3(13건) 순서로 DB 이관.

journey/troubleshooting/260310_프롬프트DB_응답생성_폐루프_미연결.md

@@ -48,7 +48,12 @@ tags: [rb8001, prompt-db, self-improvement, tracking, troubleshooting]
 - DB에서 활성 버전을 바꾸면 사용자가 실제 응답 변화로 이를 체감할 수 있다.
 - `prompt_events.version_id`와 실제 응답 내용이 같은 버전을 가리킨다는 운영 검증 증거가 남는다.
 
+## 확정 항목 (2026-03-19 리서치 결과)
+- 주입 계층: `llm_service.py`의 `process_request()` 진입 시 DB 활성 프롬프트를 읽어 `context['system_instruction']` + `context['skip_default_prompt']`로 전달. 이미 `companyx_grounding_service.py`에서 검증된 패턴.
+- P1 대상: `system_chat_openai`, `system_chat_gemini`, `constraints_emotion_stats` 3건.
+- fallback: DB 조회 실패 시 기존 하드코딩 유지 (`safe_prod` 모드).
+- 상세는 [전수 조사 리서치](../research/260319_프롬프트DB_폐루프_및_하드코딩_잔존_전수조사_리서치.md) §6 참조.
+
 ## 미확정 항목
-- 실제 응답 생성 경로에서 어느 계층에 프롬프트 버전 병합을 넣을지가 아직 확정되지 않았다.
-- `message_chat` 외의 task별 템플릿(`meeting_summary`, `clarify` 등)을 어떤 우선순위로 적용할지도 아직 미확정이다.
-- 프롬프트 DB를 읽는 순간 기존 하드코딩 프롬프트와 어떤 fallback 규칙으로 공존시킬지도 미확정이다.
+- `message_chat` 외 task별 템플릿 확장 우선순위는 P1 종결 후 결정한다.
+- 캐싱 전략(TTL, 무효화 방식)은 구현 시 확정한다.

journey/troubleshooting/260311_prompt_db_partial_adoption_and_hardcoded_prompts.md

@@ -42,10 +42,16 @@ tags: [prompt-db, prompts, hardcoded, rb8001, troubleshooting]
 - 우선순위 범위에 포함된 프롬프트는 하드코딩이 아니라 DB 버전 관리 경로로 이동한다.
 - 새 프롬프트 변경이 코드 수정이 아니라 DB 변경으로 가능한 범위가 문서상 명확해진다.
 
+## 확정 항목 (2026-03-19 전수 조사 결과)
+- 하드코딩 프롬프트 **총 24건** 확인. 전체 인벤토리는 [전수 조사 리서치](../research/260319_프롬프트DB_폐루프_및_하드코딩_잔존_전수조사_리서치.md) §3 참조.
+- 이관 우선순위 확정: P1(핵심 대화 3건) → P2(운영 스킬 8건) → P3(보조/분석 13건).
+- fallback 정책: DB 조회 성공 시 DB 프롬프트 사용, 실패 시 기존 하드코딩 유지 (`safe_prod` 모드).
+- 적용 계층: `llm_service.py`의 `process_request()` 진입 시 DB 조회 → `context` 주입. 검증된 기존 패턴 재사용.
+- 닫힘 순서: P1 완료 시 트러블슈팅 #3 종결, P2~P3 완료 시 본 문서 종결.
+
 ## 미확정 항목
-- 어떤 프롬프트를 1차 DB 이전 대상으로 볼지 우선순위가 아직 고정되지 않았습니다.
-- 하드코딩 프롬프트를 DB로 옮길 때 task 분류 기준과 fallback 정책이 아직 정해지지 않았습니다.
-- `message_chat` 외 task별 템플릿 키 체계와 적용 계층(노드 내부 / 서비스 계층 / 공통 LLM 계층)도 아직 미확정입니다.
+- P2, P3 이관 시 template_key 분기 방식 상세는 P1 종결 후 확정한다.
+- 캐싱 전략(TTL, 무효화 방식)은 구현 시 확정한다.
 
 ## 한 줄 결론
-- 현재 상태는 `프롬프트 DB 기반 운영 완성`이 아니라, `프롬프트 DB 골격은 있으나 실제 운영 프롬프트 다수가 하드코딩으로 남아 있는 부분 도입 상태`입니다.
+- 현재 상태는 `프롬프트 DB 기반 운영 완성`이 아니라, `프롬프트 DB 골격은 있으나 운영 프롬프트 24건이 하드코딩으로 남아 있는 부분 도입 상태`입니다.