프롬프트를 코드 밖 저장소에 두고 버전을 남기며 코드 배포 없이 고치고 되돌리는 운영 방식이다. 처음엔 하드코딩으로 충분하지만, 프롬프트를 자주 고치거나 여러 사람이 함께 다듬어 어떤 버전이 잘 됐는지, 누가 언제 바꿨는지 추적하기 어려워질 때 쓴다.
| 항목 | 코드에 하드코딩 | 프롬프트 관리 도구 |
|---|---|---|
| 수정 방법 | 코드 수정 후 배포 | 화면에서 고치고 바로 반영 |
| 변경 이력 | git 커밋에 섞임 | 프롬프트별 버전 기록 |
| 롤백 | 재배포 필요 | 이전 버전 지정만 |
| 협업 | 개발자 중심 | 기획자·도메인 전문가도 참여 |
LangSmith, Langfuse 같은 LLM 운영 도구와 Amazon Bedrock, Vertex AI 같은 클라우드 서비스에 프롬프트 관리 기능이 있다. 프롬프트를 이름으로 등록하면 고칠 때마다 새 버전이 쌓이고, 코드는 내용이 아니라 이름만 알면 된다.
예를 들어 LangSmith에서는 client.pull_prompt("my-prompt")로 등록된 프롬프트를 불러온다. 운영은 보통 이 순서로 한다.
| 단계 | 하는 일 |
|---|---|
| 1. 등록 | 질문 등 바뀌는 부분을 변수로 둔 템플릿으로 저장 |
| 2. 수정·테스트 | 새 버전을 만들고 샘플 입력으로 결과 비교 |
| 3. 배포 | 검증된 버전에 운영용 라벨(태그)을 붙임 |
| 4. 롤백 | 문제가 생기면 라벨을 이전 버전으로 옮김 |
버전만 쌓는다고 프롬프트가 좋아지지는 않는다. 같은 테스트 질문 묶음으로 새 버전과 이전 버전의 답을 나란히 비교하고, 실제 서비스 로그에 어떤 버전이 답했는지 남겨야 '어떤 버전이 가장 잘 됐는지'에 답할 수 있다.
프롬프트와 함께 모델 이름, temperature 같은 설정도 같이 저장해 두면 나중에 같은 결과를 다시 만들기 쉽다. 프롬프트만 같고 모델이 바뀌면 답도 달라지기 때문이다.
| 상황 | 추천 |
|---|---|
| 프롬프트가 몇 개뿐이고 거의 안 바뀜 | 코드·설정 파일에 두고 git으로 관리 |
| 자주 고치고 결과를 비교해야 함 | 프롬프트 관리 도구 |
| 비개발자가 문구를 다듬음 | 관리 도구 (화면에서 수정) |
주의할 점도 있다. 요청마다 외부에서 프롬프트를 받아오면 응답이 느려지고 장애 지점이 하나 늘어나므로, 캐시를 두고 불러오기에 실패할 때 쓸 기본 프롬프트를 코드에 남겨 둔다. 또 배포 없이 바로 반영되는 만큼, 운영 라벨을 누가 옮길 수 있는지 권한과 리뷰 절차를 정해 두는 게 안전하다.
가장 흔한 방식은 서비스 중인 LLM 앱의 프롬프트를 관리 도구에 올려 두고, 코드는 이름과 운영 라벨만 참조하게 하는 것이다. 문구를 고치고 비교하고 되돌리는 일은 모두 도구 화면에서 한다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 고객 응대 챗봇 | 기획자·CS 담당자가 말투와 안내 문구를 화면에서 고치고, 테스트 질문으로 비교한 뒤 운영 라벨을 옮긴다 |
| 사내 문서 검색 | 답변 형식·출처 표시 지시를 버전별로 바꿔 보고, 로그로 어떤 버전이 답했는지 확인한다 |
| 에이전트·자동화 파이프라인 | 단계별 프롬프트를 이름으로 나눠 등록하고, 모델·temperature 설정도 함께 저장한다 |
| 배포 직후 문제 대응 | 새 버전에서 답이 이상해지면 라벨을 이전 버전으로 되돌려 재배포 없이 복구한다 |