Part 10. 변경 관리: 프롬프트 변경 vs 시스템 변경, 실험과 롤백

LLM 서비스에서 "변경"은 매일 일어난다. 프롬프트를 고치고, 검색 인덱스를 업데이트하고, 정책 룰을 조정하고, 모델 라우팅을 바꾼다. 문제는 이 변경들을 같은 수준으로 취급하는 순간 시작된다. 프롬프트 문장 한 줄과 권한 정책 한 줄은 위험도가 다르다. 따라서 변경 관리는 코드 형식이 아니라 영향 범위 기반으로 설계해야 한다.

문제 제기

운영 장애의 상당수는 기능 결함보다 변경 관리 실패에서 발생한다.

프롬프트와 retrieval 설정을 동시에 바꿔 원인 분리가 불가능해진다.
정책 변경을 카나리 없이 전체 배포해 거절률 급증 사고가 난다.
롤백 경로가 "코드 배포"에만 묶여 프롬프트/정책 복구가 늦어진다.
실험 결과가 남지 않아 같은 실수를 반복한다.

실전 예시 A: 검색 품질 개선 배포

retrieval top-k 조정과 프롬프트 템플릿 개선을 한 번에 배포했다. 품질이 떨어졌지만 어떤 변경이 원인인지 알 수 없어 롤백이 지연됐다.

실전 예시 B: 보안 정책 업데이트

민감 도메인 차단 룰을 즉시 전체 적용했더니 정상 질문까지 차단되었다. 카나리 없이 배포한 정책 변경이 제품 KPI를 급격히 악화시켰다.

핵심 개념

변경 관리는 "무엇을 바꿨는가"보다 "무엇이 영향을 받는가"로 분류해야 한다.

변경 유형	영향 범위	기본 위험도	권장 배포 전략
Prompt 텍스트	응답 형태/톤	중간	소규모 카나리 + 품질 게이트
Retrieval 설정	근거/최신성	높음	도메인별 단계 배포
Policy 룰	허용/차단 경계	매우 높음	승인 필수 + 점진 확대
Tool 권한	실행 결과	매우 높음	샌드박스 검증 + 제한 카나리
모델 라우팅	비용/품질/지연	중간~높음	트래픽 분할 실험

핵심 원칙:

한 번에 한 종류의 고위험 변경만 배포한다.
변경마다 전용 게이트(품질, 보안, 비용)를 둔다.
롤백은 "시스템 전체"가 아니라 "변경 단위"로 가능해야 한다.

Mermaid diagram rendering...

실전 패턴

패턴 1: 변경 분류기(Change Classifier) 도입

변경 요청 시점에 위험 등급을 자동 분류하면 배포 절차가 일관된다.

type ChangeType = "prompt" | "retrieval" | "policy" | "tool_permission" | "routing";

type ChangeRequest = {
  id: string;
  type: ChangeType;
  touchesDomains: string[];
  hasSecurityImpact: boolean;
  expectedMetricShift?: string;
};

function classifyRisk(req: ChangeRequest): "low" | "medium" | "high" {
  if (req.type === "policy" || req.type === "tool_permission") return "high";
  if (req.hasSecurityImpact) return "high";
  if (req.type === "retrieval" && req.touchesDomains.includes("payment")) return "high";
  if (req.type === "retrieval" || req.type === "routing") return "medium";
  return "low";
}

export function requiredGates(req: ChangeRequest) {
  const risk = classifyRisk(req);
  if (risk === "high") return ["security_review", "offline_eval", "canary_1_5_10", "rollback_plan"];
  if (risk === "medium") return ["offline_eval", "canary_10_25_50"];
  return ["offline_smoke", "canary_10"];
}

운영 포인트:

변경 PR 템플릿에 risk tier와 게이트 결과를 의무화한다.
고위험 변경은 야간/휴일 배포를 제한한다.
긴급 변경에도 최소 카나리 단계를 강제한다.

패턴 2: Prompt/Policy 버전 레지스트리와 독립 롤백

코드 배포와 분리된 버전 레지스트리가 있어야 빠른 롤백이 가능하다.

{
  "release_id": "rel_20260303_1900",
  "prompt_version": "assist-v8.2.0",
  "policy_version": "sec-v13",
  "retrieval_version": "ret-v5.4",
  "routing_version": "route-v3.1",
  "canary": {
    "percent": 10,
    "target_tenants": ["tenant_a", "tenant_b"]
  },
  "rollback": {
    "prompt_version": "assist-v8.1.4",
    "policy_version": "sec-v12",
    "retrieval_version": "ret-v5.3",
    "routing_version": "route-v3.0"
  }
}

# 변경 단위 롤백 예시
./ops/release/rollback-component.sh \
  --component policy_version \
  --to sec-v12 \
  --reason "false refusal spike"

운영 포인트:

component 단위 롤백 시간을 KPI로 측정한다.
카나리 대상 테넌트를 다양화해 특정 패턴 편향을 줄인다.
롤백 후 반드시 회귀 원인 태깅을 남긴다.

패턴 3: 실험 결과를 배포 의사결정과 연결

실험은 보고서로 끝내면 의미가 없다. 승격 규칙을 사전에 고정해야 한다.

예시 승격 규칙:

품질: resolved_rate 기준선 대비 -1%p 이내
안전: policy_violation_rate 증가 없음
비용: cost_per_resolved_request +10% 이내
지연: p95_latency +15% 이내

운영 포인트:

기준선은 7일 이동 평균으로 계산한다.
단일 지표 통과가 아닌 다중 지표 동시 통과를 요구한다.
실험 실패 케이스를 평가셋에 편입해 재발을 줄인다.

실패 사례/안티패턴

장애 시나리오: "동시 변경으로 원인 실종"

상황:

같은 릴리즈에서 prompt/retrieval/policy를 동시에 변경했다.
배포 후 30분 내 follow_up_ratio와 false_refusal_rate가 동시 상승했다.
변경 축이 많아 원인 분리가 안 되었고, 전체 롤백까지 90분이 소요됐다.

탐지 절차:

품질/정책 지표 복합 경보 확인
release manifest에서 동시 변경 구성 확인
세부 trace 태그(prompt_version, policy_version, retrieval_version) 비교

완화 절차:

정책 버전만 우선 롤백하여 차단률 정상화
retrieval 설정을 이전 값으로 부분 복구
프롬프트는 유지하되 트래픽 20%로 축소

회복 절차:

고위험 변경 동시 배포 금지 규칙 추가
release gate에 "component count 2 이하" 제한 적용
postmortem에서 분리 배포 원칙을 표준화

대표 안티패턴

"잘 될 것 같다"는 직감으로 게이트 생략
카나리를 단순 트래픽 분할로만 보고 품질 지표를 연결하지 않음
롤백 경로 없이 forward-fix만 준비
실험 결과를 문서화하지 않고 개인 기억에 의존

체크리스트

변경 요청에 risk tier가 자동/수동으로 분류되는가?
고위험 변경은 승인자와 배포 창이 별도 관리되는가?
prompt/policy/retrieval/routing 버전이 분리 추적되는가?
component 단위 롤백이 10분 내 가능한가?
카나리 승격 기준에 품질/안전/비용/지연이 모두 포함되는가?
동시 변경 개수 제한 규칙이 존재하는가?
실험 실패 케이스가 평가셋으로 환류되는가?

요약

LLM 운영에서 변경 관리의 본질은 속도가 아니라 통제 가능성이다. 변경 유형별로 위험을 분리하고, 전용 게이트와 부분 롤백 경로를 준비해야 사고 반경을 줄일 수 있다. 프롬프트 변경과 시스템 변경을 같은 방식으로 다루는 순간 운영 복원력은 급격히 떨어진다.

다음 편 예고

다음 편에서는 지금까지 논의한 원칙을 하나로 묶은 레퍼런스 아키텍처를 제시한다. 제어면(control plane)과 실행면(data plane)을 분리하고, 품질/비용/보안/신뢰성 지표가 어떻게 하나의 운영 루프로 연결되는지 엔드투엔드로 정리한다.

이전 편: Part 9. 제품화: 실패 UX, Human-in-the-loop, 운영 거버넌스

다음 편: Part 11. 레퍼런스 아키텍처: 엔드투엔드 운영 설계

문제 제기

실전 예시 A: 검색 품질 개선 배포

실전 예시 B: 보안 정책 업데이트

핵심 개념

실전 패턴

패턴 1: 변경 분류기(Change Classifier) 도입

패턴 2: Prompt/Policy 버전 레지스트리와 독립 롤백

패턴 3: 실험 결과를 배포 의사결정과 연결

실패 사례/안티패턴

장애 시나리오: "동시 변경으로 원인 실종"

대표 안티패턴

체크리스트

요약

다음 편 예고

댓글