---
tags: [prompt-db, prompts, hardcoded, rb8001, troubleshooting]
---

# 프롬프트 DB 부분 도입 상태와 하드코딩 프롬프트 잔존

## 관련 문서
- [프롬프트 DB 폐루프 및 하드코딩 잔존 전수 조사 리서치](../research/260319_프롬프트DB_폐루프_및_하드코딩_잔존_전수조사_리서치.md)
- [프롬프트 DB 응답생성 폐루프 미연결](./260310_프롬프트DB_응답생성_폐루프_미연결.md)
- [프롬프트 동적 관리 시스템 계획](../plans/251225_프롬프트_동적관리_계획.md)
- [프롬프트DB·자기개선루프 기본구현 검증 및 계획 종결](../worklog/260310_프롬프트DB_자기개선루프_기본구현_검증및계획종결.md)
- [NAVER WORKS 브리핑 인사이트 서두 누출](./260311_naverworks_briefing_insight_preamble_leak.md)

## 이 문서의 범위
- 이 문서는 `운영 프롬프트 다수가 아직 DB로 이관되지 않은 문제`만 다룹니다.
- 즉 핵심은 `적용 범위`, `이관 우선순위`, `하드코딩 잔존` 문제입니다.
- DB에 들어간 프롬프트가 실제 응답에 반영되는지 여부는 별도 문서 [프롬프트 DB 응답생성 폐루프 미연결](./260310_프롬프트DB_응답생성_폐루프_미연결.md) 로 분리합니다.

## 문제 정의
- 프롬프트 DB 저장/활성화/이벤트 추적 골격은 구현돼 있지만, 실제 운영 프롬프트 다수가 아직 코드 하드코딩 상태로 남아 있습니다.
- 그 결과 `프롬프트 DB화 완료`처럼 해석되기 쉬우나, 실제로는 일부 경로만 DB와 연결돼 있고 다수 생성 경로는 여전히 코드 수정 없이는 바꿀 수 없습니다.

## 재현 조건
- `rb8001` 코드에서 프롬프트 DB 연동 여부를 검색하면 `message_tracking_service.py` 중심 추적/버전관리 경로는 존재합니다.
- 반면 실제 프롬프트 문자열 검색 시 `naverworks_briefing.py`, `dm_skill.py`, `ir_deck.py`, `ir_analyzer.py`, `ir_deck_analyzer.py`, `coldmail_*`, `gemini_handler.py`, `intent_*` 등 다수 경로에 하드코딩 프롬프트가 남아 있습니다.

## 확인된 사실
- `prompt_management_repository.py`에는 `prompt_templates`, `prompt_versions`, `prompt_events` 관리 기능이 있습니다.
- `message_tracking_service.py`는 `/api/message` 흐름에서 활성 프롬프트 조회와 이벤트 적재를 수행합니다.
- 하지만 기존 문서 [260310_프롬프트DB_응답생성_폐루프_미연결.md](./260310_프롬프트DB_응답생성_폐루프_미연결.md) 가 이미 보여주듯, `/api/message`조차 활성 버전을 실제 응답 생성 전에 주입하지 않습니다.
- NAVER WORKS 브리핑 인사이트 프롬프트는 현재 `naverworks_briefing.py` 내부에 하드코딩돼 있습니다.
- 동일하게 다수 서비스/워크플로가 여전히 코드 내부 `prompt = """..."""`, `system_prompt = """..."""` 형태를 사용합니다.

## 영향 범위
- 운영자가 프롬프트를 DB에서 조정해도 실제 서비스 반영 범위가 불명확합니다.
- 특정 경로는 DB 반영, 특정 경로는 하드코딩 유지 상태라 프롬프트 SSOT가 흔들립니다.
- 이번 NAVER WORKS 브리핑처럼 프롬프트 문제를 발견해도 DB에서 즉시 교정할 수 없고 코드 수정이 필요합니다.
- `프롬프트 DB화 완료`라는 표현이 사용되면 실제 상태보다 과하게 해석될 위험이 있습니다.

## 닫힘 기준
- 운영 핵심 프롬프트 인벤토리가 확정되고, DB 이전 대상/잔여 하드코딩 목록이 명확히 관리된다.
- 우선순위 범위에 포함된 프롬프트는 하드코딩이 아니라 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 완료 시 본 문서 종결.

## 미확정 항목
- P2, P3 이관 시 template_key 분기 방식 상세는 P1 종결 후 확정한다.
- 캐싱 전략(TTL, 무효화 방식)은 구현 시 확정한다.

## 한 줄 결론
- 현재 상태는 `프롬프트 DB 기반 운영 완성`이 아니라, `프롬프트 DB 골격은 있으나 운영 프롬프트 24건이 하드코딩으로 남아 있는 부분 도입 상태`입니다.
