[프롬프트] LLM 프롬프트 중앙 관리 Langfuse SWR 캐싱

부제: 프롬프트를 코드에서 빼되, 코드에도 남긴 이유

LLM 프롬프트를 어디서 관리하느냐는 은근히 큰 문제다.
처음엔 당연하게 코드(파이썬 파일)에 문자열로 박아 뒀다.

코드에 박으면 배포에 묶인다

프롬프트는 자주, 빠르게 고치고 싶은 물건이다.
문구 한 줄만 바꿔도 답의 품질이 달라지니, 여러 번 손보게 된다.

그런데 코드에 있으면 그때마다 코드를 고치고 배포해야 한다.
프롬프트 한 단어 바꾸자고 배포 사이클을 한 바퀴 도는 셈이다. 느리다.
버전을 비교하거나 되돌리기도 번거롭다.

중앙 관리로 옮기되, 코드도 남긴다

그래서 프롬프트를 관측·프롬프트 관리 도구(Langfuse)로 옮겨 중앙에서 관리하기로 했다.
웹 UI에서 고치고 라벨로 배포하면, 앱이 알아서 최신 프롬프트를 가져다 쓴다.
배포 없이 프롬프트만 바꿀 수 있다.

다만 코드에서 완전히 빼지는 않았다. 이게 핵심 결정이었다.
프롬프트를 코드에도 파일로 남겨 둔다.

• 앱이 시작할 때 코드의 프롬프트를 관리 도구에 자동으로 등록(시딩)한다. 수동 설정이 필요 없고, 새 환경도 켜자마자 동작한다.
• 코드에 있으니 Git으로 변경 이력이 그대로 추적된다.
• 즉 "코드 = 씨앗, 관리 도구 = 운영 편집"의 이중 구조다.

빠르게, 그리고 죽어도 돌게 — SWR

한 가지 걱정이 남았다.
프롬프트를 매 요청마다 관리 도구에서 가져오면 느리고, 그 도구가 죽으면 서비스가 같이 멈춘다.

그래서 캐싱을 SWR(stale-while-revalidate)로 걸었다.
캐시에 있는 걸 일단 즉시 내주고(빠름), 뒤에서 조용히 최신으로 갱신한다.
그래서 관리 도구가 잠깐 죽어도 캐시된 프롬프트로 서비스가 계속 돈다.
최악의 경우엔 코드에 남겨 둔 프롬프트로 떨어진다.

속도(캐시)와 가용성(폴백)을 한 번에 잡은 것이다.

정리

• 프롬프트를 코드에 박으면 한 줄 고치는 데도 배포가 필요해 느리다
• 중앙 관리 도구로 옮겨 배포 없이 수정·라벨 배포하게 했다
• 단, 코드에도 파일로 남겨 — 앱 시작 시 자동 시딩 + Git 이력 추적 + 장애 폴백
• 캐싱은 SWR로 — 캐시를 즉시 쓰고 뒤에서 갱신, 관리 도구가 죽어도 무중단

자주 바뀌는 설정은 배포에서 떼어 중앙에서 관리하되, 코드에 씨앗을 남겨 두는 게
자동화와 안전망을 같이 얻는 길이었다.