AI 기능 구현 시 모델 설정보다 프롬프트와 평가 데이터셋을 먼저 버전 관리하세요

당신은 AI 기능을 출시했습니다. 슬랙 스레드에는 모델 이름이 고정되어 있습니다. 실제로 동작을 구동하는 프롬프트는 무작위 PR에 있거나, 더 나쁘게는 실행 중인 컨테이너 안에만 있을 수 있습니다.

그러자 품질이 떨어집니다.

지원 티켓의 요약은 점점 나빠지고, 에이전트는 정책을 지어내기 시작합니다. 지연 시간(Latency)은 괜찮아 보이고, 비용도 괜찮아 보입니다. 아무도 가장 유용한 질문인 **무엇이 바뀌었는지?**에 답할 수 없습니다.

프롬프트를 비교할 수 없다면, 품질 저하를 디버깅할 수 없습니다.

진정한 출처(Source of Truth)는 모델 문자열이 아닙니다

모델 교체는 잡음이 많습니다. 누군가 “X로 옮겼다”고 게시하고, 설정이 업데이트되고, 대시보드가 급등하며, 사람들이 알아차립니다.

프롬프트 수정은 조용합니다. 시스템 메시지에 한 줄만 변경해도 배포 노트도 없고, 태그된 릴리스도 없고, 롤백 버튼도 없이 제품 동작을 재작성할 수 있습니다. 평가 데이터셋(Eval datasets)도 같은 이야기입니다. 만약 골든 예시(golden examples)가 누군가의 노트북에 있는 스프레드시트에 있다면, 프롬프트가 표류할 때 회귀 신호(regression signal)를 가질 수 없습니다.

프롬프트를 코드처럼 다루세요. 평가 데이터셋을 테스트 스위트처럼 다루세요. 모델 및 제공업체 설정을 그 두 가지 이후에 오는 인프라스트럭처-애즈-코드(infrastructure-as-code)로 취급하세요.

AWS Prescriptive Guidance는 이를 명확하게 제시합니다: 프롬프트는 버전 관리가 필요하고, 저장소 또는 레지스트리, PR 스타일의 검토, 환경 승격이 필요한 중요한 소프트웨어 아티팩트이며, 임시 텍스트 파일이 아닙니다. Managing the generative AI prompt lifecycle를 참조하세요.

일반적인 레포지토리에 맞는 실용적인 워크플로우

당신은 플랫폼 재작성이 필요하지 않습니다. 기능 옆에 세 가지 아티팩트가 필요합니다.

1. git에 있는 프롬프트 (또는 git 히스토리가 있는 레지스트리)

프롬프트 텍스트를 레포에 보관하여 모든 변경 사항이 diff로, 모든 릴리스가 태그로 남도록 하세요. 플랫 파일(flat files)을 초과하는 경우, 여전히 커밋을 버전 관리하는 프롬프트 레지스트리를 사용하세요. Langfuse는 Prompt management at scale에서 대규모로 프롬프트를 구성하고, 버전 관리하며, 테스트하는 문서를 제공합니다.

2. 프롬프트와 함께 버전 관리되는 Golden 평가 데이터셋

입력(inputs)과 기대 속성(expected properties)이 포함된 작은 JSONL (또는 YAML) 세트만으로 시작하기에 충분합니다. 이를 모든 프롬프트 PR에서 실행하세요. 프로덕션 실패 사례를 통해 이 데이터셋을 확장해 나가세요. 이것 없이는 '더 좋아 보인다'가 유일한 테스트 기준이 됩니다.

3. 코드로서의 모델 및 제공업체 설정 (Model + provider config as code)

모델 ID, 온도(temperature), 타임아웃(timeouts), 폴백(fallbacks)을 앱이 로드하는 설정 파일에 고정하세요. 기록하기 쉽고(Easy to log), 롤백하기도 쉽습니다(Easy to roll back). 하지만 여전히 프롬프트와 평가 데이터셋보다 부차적입니다. 왜냐하면 고정된 프롬프트와 평가 세트 없이 모델을 교체하는 것은 단지 노이즈를 옮기는 것일 뿐이기 때문입니다.

4. 프롬프트 변경에 대한 PR 검토

애플리케이션 코드와 동일한 기준을 적용하세요: 리뷰어, CI 체크, 병합(merge). Langfuse의 Prompt CI/CD 글은 이 순환 고리를 버전 관리 → 게이트(gate) → 배포(rollout)로 구성합니다. 설령 여러분의 '레지스트리'가 단지 폴더일지라도 이것이 올바른 사고방식입니다.

폴더 구조 예시 (Folder sketch)

다음과 같이 간단한 것만으로도 Slack 아카이브보다 낫습니다:

ai/
  prompts/
    support_summarizer.v3.md
...

support_summarizer.v3.md — 시스템/사용자 템플릿과 짧은 변경 로그 헤더가 포함됩니다.

support_summarizer.jsonl — 줄마다 하나의 객체: 입력 티켓, 기대 필드, 그리고 아마도 루브릭 레이블이 들어갑니다.

support_summarizer.yaml — 모델 ID, 제공업체(provider), 온도, 최대 토큰 수(max tokens), 폴백 설정입니다.

프롬프트 PR에서는 CI가 v3와 JSONL을 로드하고, 실행 점수를 매긴 후, 재현율(recall)/정밀도(precision)/루브릭이 임계값 이하로 떨어지면 빌드를 실패시킵니다. 리뷰어들은 프롬프트의 차이점(diff)을 서비스 변경 사항을 읽는 방식과 동일하게 읽게 됩니다. 왜냐하면 그것은 실제로 서비스 변경 사항이기 때문입니다.

예시 평가 라인:

{"id":"t-1042","input":"고객이 45일 후에 환불을 요청했습니다. 정책은 30일입니다.","expect":{"tone":"firm_empathetic","must_cite_policy":true,"must_not_invent_exception":true}}

예시 설정:

feature: support_summarizer
prompt: prompts/support_summarizer.v3.md
eval: evals/support_summarizer.jsonl
...

행동(behavior)이 변경되면 프롬프트 버전을 올리세요. 실제 놓친 사례(real misses)를 통해 평가 데이터셋을 지속적으로 늘려가야 합니다. 운영팀(ops)이 제공업체 사고(provider incidents)와 상관관계를 파악할 수 있도록 모든 호출마다 모델 문자열(model string)을 기록하세요. 단, 모델 문자열 자체가 제품이라고 착각해서는 안 됩니다.

일반적으로 잘못되는 점

애플리케이션 코드의 프롬프트 문자열에만 존재. 검토하기 어렵고, A/B 테스트도 어렵습니다. 핫픽스(hotfix)로 '수정'하고 잊어버리기 쉽습니다.

실제 배포되지 않는 평가 데이터셋(Evals). 노트북 파일 하나가 게이트 역할을 할 수 없습니다. 파일을 레포지토리(repo)에 넣고 CI에서 실행하세요.

모델을 먼저 버전 관리하는 것. 유용하지만 불완전합니다. gpt-4.1-mini를 영원히 고정하더라도 화요일에 조용한 프롬프트 회귀(prompt regression)가 발생할 수 있습니다.

소유권 부재(No ownership). 누구나 PR 없이 프로덕션 프롬프트를 수정할 수 있다면, 결국 월요일 아침의 미스터리한 문제가 배포될 것입니다.

이번 주부터 시작하기

AI 기능 하나를 선택하세요. 해당 기능을 위한 프롬프트를 prompts/ 디렉터리로 옮기세요. 지난 한 달간 접수된 불만 사례 중 20~50개의 골든 예시(golden examples)를 추가하세요. 명확한 회귀가 발생하면 실패하는 저렴한 CI 작업을 연결하세요. 프롬프트 PR에 인간의 검토를 요구하세요.

이것은 관료주의가 아닙니다. 품질이 떨어졌을 때 차이점(diff)을 얻는 방법입니다.

설문조사 — 아래 댓글로

AI 기능에 대해 가장 먼저 버전 관리를 하는 아티팩트(artifact)는 무엇인가요?

• A) 프롬프트
• B) 평가 데이터셋 / 골든 예시
• C) 모델 + 제공업체 설정
• D) 아직 아무것도 버전 관리하지 않음

제 의견: A와 B를 함께. 모델 ID는 나중에 기록하기 쉽습니다. 프롬프트를 차이점(diff)으로 비교할 수 없다면, 하락세를 디버깅할 수 없습니다.

오늘 귀하의 팀에 해당하는 문자는 무엇이며, 지난번에 품질이 떨어졌을 때 어떤 것이 문제를 일으켰나요?