커스텀 언어 모델의 10가지 CI/CD 릴리스 실패 — 그리고 각각을 잡아내는 파이프라인 단계

릴리스 사이클에서의 메모 — 2부

이 시리즈의 첫 번째 글에서는 저희가 출시하는 4단계 릴리스 파이프라인 — 등록 → 게이트 → 롤 → 관측 — 을 살펴봤습니다. 이 글은 그 증거입니다. 저희가 이 파이프라인으로 이미 잡아낸 열 가지 구체적인 실패 모드, 각각이 실제로는 어떤 모습이었는지, 그리고 파이프라인의 어느 단계가 프로덕션에 도달하기 전에 이를 막아냈는지를 다룹니다.

이 목록은 심각도가 아니라 단계별로 정리되어 있습니다. 단계가 곧, 직접 비슷한 것을 구축한다면 어디에 투자해야 하는지를 알려 주기 때문입니다. 게이트가 약한 고리라면 아래 열 가지 실패 중 여섯 가지가 계속해서 여러분을 괴롭힐 것입니다. 관측자가 약한 고리라면 두 가지가 조용히 여러분을 강타할 것입니다 — 즉, 받게 될 유일한 신호가 고객 불만이라는 뜻이며, 이는 가능한 최악의 신호입니다.

열 가지 모두를 잡아내는 파이프라인은 기능 목록이 아닙니다. 그것은 일관되게 내린 소수의 아키텍처 결정입니다. 아래의 각 실패는 어떤 결정이 적용되는지를 명시합니다.

이 목록을 읽는 법

각 실패에는 이를 잡아내는 단계가 태그로 달려 있습니다.

• ① REGISTER — 매니페스트 계층. 상태가 여러 시스템에 흩어져 있어 어떤 변경이 프로덕션을 망가뜨렸는지 알 수 없는 종류의 실패를 막습니다.
• ② GATE — 보정된 인간 기반 판정자에 대한 도메인별 Spearman. 집계 점수 안에 숨어 있는 실패를 막습니다.
• ③ ROLL — 각 체크포인트에 품질 모니터를 두고 5% → 25% → 100%로 진행하는 카나리. 규모에서만 드러나는 실패를 막습니다.
• ④ OBSERVE — 후보 모델을 통해 프로덕션 트레이스를 지속적으로 재생하고, 게이트의 판정자가 점수를 매깁니다. 지연 시간과 5xx로는 결코 눈치챌 수 없는 조용한 품질 저하를 막습니다.

각 섹션은 수정 방법으로 마무리됩니다 — Divinci에서 출시하는 정확한 구성과, 저희를 사용하지 않을 경우 직접 무엇을 구축해야 하는지입니다.

① 단계 — 등록

1. 모델 + 프롬프트 + 라우팅을 하나의 번들로 함께 배포했지만 어떤 것이 망가뜨렸는지 모르는 경우

무슨 일이 있었는가. 같은 릴리스에서 세 가지를 변경했습니다. 베이스 모델을 Gemma 4 E2B에서 Gemma 4 26B-A4B로 올렸고, “법령을 인용하라“는 지시를 추가하기 위해 법률 도메인 시스템 프롬프트를 편집했으며, 어떤 트래픽 클래스가 어떤 모델로 갈지 결정하는 라우팅 규칙을 조정했습니다. 계약 작성 정확도가 7포인트 떨어졌습니다. 세 가지 변경 중 어느 것도 독립적으로 테스트되지 않았습니다. 디버깅하려면 이틀에 걸쳐 한 번에 변수 하나씩 되돌려야 했습니다.

파이프라인이 이제 어떻게 이를 잡아내는가. Divinci 릴리스는 model_ref, prompt_template_ref, routing, dataset_version을 하나의 SHA-256 주소 지정 산출물로 묶은 불변의 매니페스트입니다. 파이프라인은 이전 릴리스의 SHA가 비교 기준으로 참조되지 않는 한, 하나 이상의 변경을 묶은 매니페스트의 배포를 거부합니다. 세 가지 변경을 한 번에 출시하고 싶다면 매니페스트에서 이를 명시적으로 인정해야 하며, 다음 릴리스는 다시 한 번에 변수 하나씩으로 강제되기 때문에 실패 귀속 경로가 깨끗하게 유지됩니다.

수정. 사람이 손으로 릴리스를 조립하게 두지 마십시오. 릴리스 매니페스트는 조용히 묶을 수 없는 파이프라인에 의해 생성되어야 합니다. API에 대해서는 1단계 — 등록을 참고하십시오.

2. 대시보드에서 시스템 프롬프트를 편집하고 코드 리뷰 없이 출시하는 경우

무슨 일이 있었는가. 누군가가 관리자 UI에서 시스템 프롬프트를 손봐서 “모델을 덜 장황하게” 만들었습니다. 한 단어를 고친 정도로 보였습니다. 그 결과 프롬프트가 38자 짧아졌고, 이는 다운스트림 프롬프트 리라이터가 안전 보일러플레이트를 추가할지 결정할 때 사용하는 길이 임계값 아래로 떨어뜨렸습니다. 두 시간 후, 모델은 거절했어야 할 질문에 답하고 있었습니다.

파이프라인이 이제 어떻게 이를 잡아내는가. 프롬프트는 등록된 매니페스트의 일부입니다. 대시보드에서 프롬프트를 편집한다는 것은 곧 새 매니페스트를 자른다는 것이고, 새 SHA를 생성한다는 것이며, 게이트가 그 변경에 대해 실행된다는 의미입니다. 대시보드에서 프롬프트를 편집할 수는 있습니다. 다만 게이트가 보지 못한 상태로는 출시할 수 없을 뿐입니다.

수정. 프롬프트를 코드처럼 다루십시오. 콘텐츠 해시로 버전을 관리하고, 릴리스의 일부로 등록하며, 점수화된 QA 스위트로 게이팅하십시오. Tianpan의 Semver Lie 글^[1]은 바로 이 실패 모드가 실제로 발생한 사례를 묘사합니다 — “코드 리뷰를 통과하고, 평가 게이트 없이 배포되었으며, 사용자별 A/B 없이 프로덕션에 진입했고, 자동 롤백을 트리거하지 않은” 프롬프트 변경입니다.

3. 학습-서빙 전처리 스큐

무슨 일이 있었는가. 학습 파이프라인은 특정 필드의 공백을 정규화하고 소문자로 변환했습니다. 서빙 파이프라인은 그렇게 하지 않았습니다. 같은 모델, 같은 프롬프트, 같은 라우팅 — 그러나 바이트 수준에서 다른 입력이었습니다. 개발 픽스처에서는 모두 통과했습니다. 실제 트래픽에서는 모델이 마치 더 잡음 많은 데이터로 재학습된 것처럼 동작했는데, 모델의 관점에서는 실제로 그랬기 때문입니다.

파이프라인이 이제 어떻게 이를 잡아내는가. 매니페스트는 model_ref와 함께 preprocessing_ref를 등록합니다. 게이트 평가는 프로덕션 서빙 스택이 사용하는 것과 동일한 전처리를 통해 실행됩니다. 둘이 어긋나면 게이트의 오프라인 수치가 더는 프로덕션과 일치하지 않으며, 슬라이스별 Spearman은 승격 이전에 측정 가능한 방식으로 떨어집니다.

수정. 전처리를 버전 관리되는 산출물로 컨테이너화하십시오. 매니페스트에서 이를 참조하십시오. 게이트가 프로덕션이 사용할 전처리 버전과 다른 것에 대해 계산되었다면 배포를 거부하십시오.

② 단계 — 게이트

아래 네 가지 실패는 집계 점수 게이트라면 그대로 출시했을 것들입니다. 집계 게이트가 이들을 놓치는 이유는 파라미터 튜닝이 아니라 구조적인 문제입니다 — 슬라이스 전반에 걸쳐 평균을 내면, 하나의 슬라이스에 국소화된 회귀를 잡아내는 데 사용할 바로 그 신호가 파괴됩니다.

4. 지식재산 라이선싱 붕괴 (슬라이스 인식 회귀 #1)

무슨 일이 있었는가. QLoRA 파인튜닝이 법률 Q&A 정확도를 다섯 개의 하위 도메인에서 개선했지만 지식재산 라이선싱에서는 무너뜨렸습니다 — 계약 작성 0.71, 법령 해석 0.74, 판례 요약 0.69, 규제 컴플라이언스 0.66, 관할 분석 0.62, 지식재산 라이선싱 0.41. 여섯 카테고리 전반의 집계 Spearman ρ는 0.64였습니다. 게이트 임계값은 0.65였습니다. 단일 집계 점수로는 릴리스가 간발의 차이로 선 아래에 있었습니다. 슬라이스별 관점으로는 한 하위 도메인이 27포인트 무너져 있었습니다.

파이프라인이 이제 어떻게 이를 잡아내는가. 게이트의 임계값은 집계가 아니라 슬라이스별입니다. 어떤 단일 슬라이스라도 자신의 임계값 아래로 떨어지면, 평균이 어떻게 보이든 릴리스는 gate_fail로 표시됩니다. 1번 글의 게이트 임계값 차트는 이런 릴리스에 대해 파이프라인이 실제로 만들어 내는 시각화입니다.

수정. 게이트를 슬라이스로 나누십시오. 중요한 슬라이스는 가져온 평가 프레임워크에 들어 있는 분류 체계가 아니라, 여러분의 고객 세그먼트 하위 도메인입니다.

5. 소아 종양학 슬라이스 회귀 (슬라이스 인식 회귀 #2)

무슨 일이 있었는가. 의료 Q&A 모델이 추가적인 성인 심장학 데이터로 파인튜닝되었습니다. 집계 의료 정확도는 4포인트 개선되었습니다. 소아 종양학 정확도는 11포인트 떨어졌습니다 — 분명히 새 학습 데이터가 소아 용량 조정을 미묘하게 덜 강조했던 것입니다. 집계 게이트라면 이를 승격시켰을 것입니다.

파이프라인이 이제 어떻게 이를 잡아내는가. 소아 종양학은 고객이 점수화된 QA 스위트를 등록할 때 구성한 슬라이스 중 하나였습니다. 게이트-2 평가가 만들어 낸 슬라이스별 Spearman ρ는 0.72에서 0.61로 떨어졌고, 이는 소아 종양학 임계값 0.68 아래였습니다. gate_fail로 표시되었습니다. 배포되지 않았습니다.

수정. 플랫폼이 정의한 슬라이스가 아니라 고객이 정의한 슬라이스를 사용하십시오. 플랫폼은 고객이 코드를 작성하지 않고도 슬라이스와 슬라이스별 임계값을 추가할 수 있게 해야 합니다 — 왜냐하면 고객의 도메인 경계는 그 고객 본인만큼 잘 아는 사람이 Divinci에 없기 때문입니다.

6. 다국어 하위 언어 드리프트 (슬라이스 인식 회귀 #3)

무슨 일이 있었는가. 다국어 모델이 프랑스어 응답을 개선하기 위해 파인튜닝되었습니다. 집계 프랑스어 정확도는 3포인트 개선되었습니다. 그러나 “프랑스어” 안에서, 모델은 벨기에 프랑스어와 스위스 프랑스어 지역 변종에 대해 이제 더 나쁘게 동작했습니다 — 학습 코퍼스가 파리 프랑스어에 치우쳐 있었기 때문입니다. 집계 프랑스어 게이트라면 이를 출시했을 것입니다.

파이프라인이 이제 어떻게 이를 잡아내는가. 로케일 변종은 언어 슬라이스의 하위 슬라이스입니다. 하위 슬라이스별 Spearman이 승격 이전에 벨기에 변종에서의 회귀를 잡아냈습니다. 릴리스는 (a) 더 다양한 학습 데이터를 위해 반환되거나, (b) 작성된 정당화 사유와 함께 강제 오버라이드되었습니다 (“이번 롤아웃에서는 집계 프랑스어 개선이 더 중요하기 때문에 지역적 회귀를 수용합니다”) — 그리고 그 오버라이드는 감사 추적에 기록됩니다.

수정. 슬라이스의 깊이가 중요합니다. “프랑스어“는 너무 거칩니다. “벨기에 프랑스어“가 회귀가 실제로 숨는 수준입니다.

7. 작성된 오버라이드 사유 없이 게이트를 우회하는 경우

무슨 일이 있었는가. 압박이 큰 릴리스 윈도였습니다. 게이트가 한 슬라이스에서 실패했습니다 — 팀의 판단으로는 중요하지 않은 슬라이스였습니다. 누군가 강제 오버라이드 플래그에 손을 뻗었습니다. 파이프라인의 이전 버전에서는 강제 오버라이드가 단일 불리언이었습니다. 플래그가 뒤집혔고, 릴리스가 출시되었으며, 3주 후에는 누가 어떤 슬라이스에 대해 무엇을 결정했는지 아무도 재구성할 수 없었습니다.

파이프라인이 이제 어떻게 이를 잡아내는가. 강제 오버라이드는 두 필드 게이트입니다. forceGateOverride: true AND overrideReason: "...". 사유는 사용자 ID 및 오버라이드된 슬라이스별 게이트 결과와 함께 감사 로그에 기록되는 필수 자유 텍스트 문자열입니다. 파이프라인은 사유 없이는 오버라이드를 거부합니다. 오버라이드는 여전히 가능합니다 — 다만 익명으로는 오버라이드할 수 없을 뿐입니다.

수정. 거버넌스 게이트는 별도의 단계가 아닙니다. 그것은 게이트 단계의 한 속성입니다. 모든 오버라이드는 정당화 텍스트가 담긴 서명된 영수증입니다.

③ 단계 — 롤

8. 트래픽을 0%에서 100%로 한 번에 올리는 경우

무슨 일이 있었는가. 한 모델이 게이트를 깨끗하게 통과했습니다. 즉시 트래픽의 100%로 푸시되었습니다. 대화 길이의 한 특성 때문에, 새 모델은 약 2,400토큰을 넘는 응답에서 타임아웃되었습니다 — 게이트의 100문항 평가 세트에서는 드러나지 않은 동작이었습니다. 모든 테스트 프롬프트가 짧았기 때문입니다. 누군가가 수동으로 롤백할 때까지 18분 동안 사용자 15%가 타임아웃을 받았습니다.

파이프라인이 이제 어떻게 이를 잡아내는가. 롤 단계는 dwell_5pct_seconds (기본값 240) OR requests_5pct (기본값 1,000) 중 나중의 것까지 5%에서 머무릅니다. 5% 트래픽에서, 긴 대화 타임아웃은 약 3분 안에 5xx 비율 모니터에 드러납니다. 어떤 체크포인트 모니터든 자신의 대역을 벗어나면 파이프라인은 5%를 넘어 진행하기를 거부합니다. 평균 중지 시간은 4분이었고, 중지 이후 완전 롤백까지의 평균 시간은 약 12초였습니다.

수정. 지연 시간과 5xx만이 아니라 품질 모니터를 둔 3단계 카나리를 사용하십시오. “20초 만에 5%, 끝” 패턴이 위험한 쪽입니다. “5%에서 4분간 유지” 패턴이 안전한 쪽입니다.

④ 단계 — 관측

아래 두 가지 실패는 인프라 지표 카나리라면 그대로 승격시켰을 것들입니다. 인프라 지표가 이들을 놓치는 이유 또한 구조적입니다 — 모델이 조용히 답변을 회피하거나, 거절하거나, 환각을 일으키는 동안에도 지연 시간과 5xx는 완벽하게 깨끗하게 유지될 수 있습니다.

9. 법률 쿼리에서의 조용한 답변 회피 (조용한 품질 저하 #1)

무슨 일이 있었는가. 안전성 튜닝된 모델 업데이트로 법률 도메인 어시스턴트가 눈에 띄게 더 보수적으로 변했습니다. 같은 지연 시간, 같은 5xx 비율, 같은 토큰 사용량. 그러나 이전 버전이 “공소시효는 X년입니다“라고 답하던 곳에서, 새 버전은 “변호사와 상담하셔야 합니다“라고 말했습니다. 고객들은 몇 시간 안에 알아챘습니다. 대시보드는 결코 움직이지 않았습니다.

파이프라인이 이제 어떻게 이를 잡아내는가. 4단계 관측자는 프로덕션 트레이스를 활성 모델을 통해 지속적으로 재생하고, 게이트-2를 구동한 것과 동일한 보정된 판정자로 점수를 매깁니다. 답변 회피는 즉시 드러납니다. 보정된 판정자 — “좋은” 법률 답변이 어떤 모습인지에 대한 인간 평가에 앵커링되어 있는 — 가 답이 기대되는 상황에서의 거절에 페널티를 주기 때문입니다. 출력 품질 모니터가 연속 3분간 자신의 대역 아래로 떨어졌고 파이프라인이 자동 롤백되었습니다. 총 경과 시간은 5분 미만이었습니다.

수정. 지연 시간과 5xx만 모니터링하지 마십시오. 실제 프로덕션 트레이스에 대해 보정된 판정자로부터 도출된 품질 점수를 모니터링하십시오. SageMaker의 배포 가드레일^[2]은 CloudWatch 알람에서 자동 롤백됩니다 — 인프라에 유용하지만, 알람은 어떤 지표에서 발화해야 하고 “모델이 답변을 회피하고 있다“는 CloudWatch가 보는 지표가 아닙니다.

10. 파인튜닝 이후 환각된 날짜 (조용한 품질 저하 #2)

무슨 일이 있었는가. 일정 어시스턴트 파인튜닝이 입력에 존재하지 않는 날짜를 자신 있게 삽입하기 시작했습니다. “회의는 3월 32일 목요일입니다.” 지연 시간은 변함없었습니다. 5xx 비율도 변함없었습니다. 환각은 안전 필터를 통과했는데, “3월 32일“을 유해한 것으로 표시하는 것이 아무것도 없었기 때문입니다 — 그저 불가능할 뿐이었습니다.

파이프라인이 이제 어떻게 이를 잡아내는가. 관측자의 보정된 판정자 — 합성 트레이스가 아니라 실제 프로덕션 일정 트레이스에서 실행되는 — 는 자신 있지만 틀린 답변에 적절한 “모르겠습니다” 거절보다 더 나쁜 점수를 줍니다. 환각 클래스의 하락은 2분 안에 분당 관측자 임계값을 트리거했습니다. 자동 롤백이 발화했습니다.

수정. 도메인 전문성에 대해 보정된 판정자를 사용하십시오. 일반적인 LLM-as-judge는 사람이 훑어볼 때 “3월 32일 목요일“을 놓치는 것과 같은 방식으로 이를 놓칠 것입니다. 도메인 보정 판정자 — 도메인 전문가 평가에 앵커링된 — 는 그렇지 않습니다.

파이프라인에 매핑된 10가지 실패

빨간색으로 칠해진 막대들은 저희가 이 파이프라인을 출시하는 과정에서 발견한 실패들입니다 — 다른 모든 사람이 하듯이 인프라 지표를 가진 일반적인 카나리를 출시하는 대신, 슬라이스 인식 게이트와 트레이스 재생 관측자를 구체적으로 구축하게 된 이유입니다.

LLM CI/CD가 소프트웨어 CI/CD와 무엇이 다른가?

짧게 말하자면, LLM 릴리스는 결정론적 산출물이 아닙니다. 같은 프롬프트가 실행마다 다른 출력을 만들어 냅니다. 같은 평가 세트가 하드웨어마다 다른 점수를 만들어 냅니다. 같은 모델이 집계 품질 검사를 통과하면서도 평가에 포함하지 않은 슬라이스에서 조용히 실패할 수 있습니다. 전통적인 CI/CD가 기반으로 삼은 가정들 대부분은 확률적 시스템과 접촉하면 살아남지 못합니다.

세 가지 구체적인 결과가 있습니다.

1. expect(output).toEqual(X) 어서션을 쓸 수 없습니다. 픽스처에 대한 동등성이 아니라, 인간 기반 채점자에 대한 순위 상관관계를 소비하는 분포 인식 평가가 필요합니다.
2. “CI를 통과한” 모델이 망가진 동작을 출시할 수 있습니다. CI가 통과했다는 것은 코드가 실행된다는 의미입니다. 모델이 맞다는 의미가 아닙니다. 릴리스 파이프라인은 CI가 제공하는 정확성 게이트 위에 품질 게이트를 강제해야 합니다.
3. 롤백은 선택 사항이 아니며 느리지도 않습니다. 실패 모드가 확률적이고 — 일부는 인프라 계층에서 조용하기 때문에 — 롤백 경로는 백업 계획이 아니라 주요 인프라여야 합니다. 릴리스 매니페스트는 정확히 롤백을 원자적으로 만들기 위해 존재합니다.

이 시리즈의 첫 번째 글은 이러한 결과에 대응하는 4단계 아키텍처를 설명합니다. 이 글은 그것이 잡아내는 실패들을 설명합니다.

커스텀 LM을 위한 실패에 강한 CI/CD 파이프라인을 어떻게 구축할 것인가?

정직한 답은 다음과 같습니다. 실패가 발생할 것임을 받아들이고, 실패가 발생하는 시점과 프로덕션 트래픽이 알려진 정상 버전으로 돌아오는 시점 사이의 시간을 최소화하는 것입니다. 위의 4단계 파이프라인은 그 원칙의 한 구체적인 구현이지만, 중요한 것은 원칙 그 자체입니다.

Divinci를 사용하지 않고 동등한 것을 구축하고 싶다면, 부하를 지탱하는 부품들은 다음과 같습니다.

• 모델 + 프롬프트 + 라우팅 + 데이터셋 + 전처리를 하나의 SHA로 묶는 불변의 릴리스 매니페스트. 이것이 1, 2, 3을 잡아낼 수 있게 만듭니다. (1단계)
• 플랫폼 소유자가 아니라 도메인 소유자가 정의한 임계값을 가진 슬라이스별 게이트. 이것이 4, 5, 6을 잡아낼 수 있게 만듭니다. (2단계)
• 각 체크포인트에 지연 시간과 5xx뿐 아니라 품질 모니터링이 있는 카나리. 이것이 8을 잡아낼 수 있게 만들고, 9와 10이 프로덕션에 도달한 후에도 살아남게 만듭니다. (3단계)
• 활성 모델을 통해 실제 프로덕션 트레이스에, 게이트를 구동한 것과 동일한 보정된 판정자로 점수를 매기는 지속적인 관측자. 이것이 9와 10을 잡아낼 수 있게 만듭니다. (4단계)
• 모든 결정에 대한 서명된 감사 영수증. 해시 체인이며 외부적으로 앵커링 가능합니다. 오픈 웨이트 모델 백킹의 경우, 영수증에는 활성 가중치가 매니페스트가 등록한 것임을 증명하는 vindex 가중치 어테스테이션이 내장되어 있습니다. 클로즈드 API 백킹의 경우, 영수증은 결정 체인을 다루지만 가중치 출처는 주장할 수 없으며 — 감사 추적은 이를 명시적으로 기재합니다.

이 부품들은 개별적으로는 새롭지 않습니다. 모든 MLOps 플랫폼이 그중 하나 둘은 가지고 있습니다. 그 조합 — 슬라이스 인식 게이트 + 프로덕션 트레이스 관측자 + 원자적 롤백 + 증명 가능한 영수증 — 은 2026년에 다른 누구도 출시하지 않는 부분입니다.

다음으로 갈 곳

• 동반 글 — Divinci AI로 LLM CI/CD 파이프라인을 구축하는 방법 — 아키텍처와 API를 다룹니다.
• 컴플라이언스 페이지 는 모든 릴리스 결정을 뒷받침하는 vindex 영수증 형식과 그것이 EU AI Act, GDPR 제17조, HIPAA, NIST AI RMF에 어떻게 매핑되는지를 문서화합니다.
• AutoRAG 제품 페이지 는 게이트-2와 4단계 관측자를 구동하는 보정된 판정자와 자연스럽게 짝을 이루는 RAG 측 환각 감소를 다룹니다.
• API 레퍼런스 — 이 시리즈에서 참조된 모든 명령은 실제 엔드포인트입니다.

FAQ

커스텀 언어 모델에서 가장 흔한 CI/CD 실패는 무엇입니까?

저희가 출시해 온 릴리스 전반에서, 단일하게 가장 치명적인 실패는 집계 게이트를 통과하는 슬라이스 인식 회귀 입니다 — 평균적으로는 개선되면서도 특정 하위 도메인에서 조용히 무너지는 모델입니다(위의 실패 4, 5, 6). 이는 롤백 누락보다 흔하고, 프롬프트 드리프트보다 흔하며, 둘 중 어느 것보다도 탐지하기 어렵습니다. 수정은 파라미터 튜닝이 아니라 구조적입니다. 평균이 아니라 슬라이스별로 게이팅하십시오.

잘못된 LLM 릴리스를 얼마나 빨리 롤백할 수 있어야 합니까?

분 단위가 아니라 초 단위입니다. Divinci 파이프라인의 평균 롤백 시간은 약 12초입니다 — 이는 매니페스트 스왑 자체가 아닌, 약 100개 레플리카 서비스에서의 인플라이트 요청 드레인입니다. 매니페스트 스왑은 1초 미만입니다. 이를 가능하게 하는 아키텍처적 결정은 묶인 릴리스 매니페스트입니다. 모든 컴포넌트(가중치, 프롬프트, 라우팅, 데이터셋)가 하나의 SHA로부터 참조되기 때문에, 롤백은 단일한 원자적 재지정입니다. 공개 사후 부검과 비교해 보십시오. Cloudflare의 2022년 6월 사건^[3]은 엔지니어들이 서로의 되돌리기를 밟고 있었기 때문에 되돌리는 데 44분이 걸렸고, Atlassian의 2022년 4월 장애^[4]는 상태가 여러 시스템에 흩어져 있었기 때문에 영향받은 사이트당 복구에 12시간이 걸렸습니다.

프롬프트 변경이 왜 그렇게 많은 프로덕션 장애를 일으킵니까?

프롬프트가 CI/CD 파이프라인 바깥에서 일상적으로 편집되기 때문입니다 — 대시보드에서, 관리자 UI에서, 때로는 엔지니어링 리뷰 없이 사람들에 의해서요. 그것들은 구성으로 다뤄지지만, 코드처럼 동작합니다. 시스템 프롬프트에 대한 38자짜리 편집이 모델 재학습보다 더 다운스트림 모델 동작을 바꿀 수 있습니다. 수정은 프롬프트를 릴리스 매니페스트의 일부로 등록하고, 모델이 통과하는 동일한 게이트를 통과하도록 요구하는 것입니다.

LLM 출력에서 조용한 품질 저하를 어떻게 탐지합니까?

인프라 지표로는 안 됩니다. 지연 시간, 5xx 비율, 토큰 사용량은 답변 회피, 답이 기대되는 상황에서의 거절, 환각된 날짜를 잡아내지 못합니다. 탐지 신호는 실제 프로덕션 트레이스에 대해 보정된 판정자가 계산한 품질 점수에서 와야 합니다. Divinci 파이프라인의 4단계 관측자는 프로덕션 트레이스의 롤링 샘플을 활성 모델을 통해 재생하고, 게이트-2를 구동한 것과 동일한 인간 기반 Spearman 판정자로 점수를 매기며, 품질 점수가 연속 3분 동안 임계값 아래로 떨어지면 자동 롤백을 트리거합니다.

AI 모델 배포에 어떤 감사 추적 요구사항이 적용됩니까?

EU AI Act, GDPR 제17조(잊혀질 권리), HIPAA, NIST AI 위험 관리 프레임워크는 모두 조직이 모델 버전, 평가 결과, 승인 결정, 롤아웃의 기록을 유지하도록 요구합니다. 네 가지 모두의 밑에 깔린 명시되지 않은 요구사항은 그 기록이 검증 가능 해야 한다는 것입니다 — 감사 가능하다는 것은 “우리는 로그를 가지고 있다” 이상의 의미입니다. Divinci의 vindex 영수증은 해시 체인이며 외부적으로 앵커링 가능하므로, 감사인이 저희의 로그를 신뢰하지 않고도 체인을 검증할 수 있습니다. 오픈 웨이트 모델 백킹의 경우 영수증에는 가중치 어테스테이션도 내장되어 있고, 클로즈드 API 백킹의 경우 영수증은 가중치 출처가 주장되지 않음을 명시적으로 기재합니다.

References

1. Tianpan — The Semver Lie: how an LLM minor update breaks production (April 2026). Names the dashboard-prompt-edit failure mode directly. Companion: LLM postmortem template — fields SRE missed.
2. AWS SageMaker — Use canary traffic shifting. The standard infrastructure-metric-driven auto-rollback. Useful comparison for what Stage 4 Observe is doing differently (quality score, not CloudWatch alarms).
3. Cloudflare — Cloudflare outage on June 21, 2022. 44-minute revert because engineers walked over each other's reverts. Cited as the "rollback is its own kind of incident" anchor.
4. Atlassian — Post-Incident Review: April 2022 Outage. 12 hours per site to restore. State-spread-across-systems failure mode in its worst form.
5. DORA — Software delivery performance metrics. The "failed deployment recovery time" elite-performer threshold is documented as under one hour. Useful framing for "how fast is fast enough" on rollback.
6. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv:2306.05685, 2023). The reference for why LLM-as-judge can match human ratings overall but vary widely per category — which is exactly the pattern that makes per-slice gating necessary.

시리즈의 다음 글: 규제 영역에서 커스텀 LM을 검증하고 출시하기. 위의 파이프라인은 아키텍처입니다. 컴플라이언스 경로는 그것을 사용하는 실천입니다. EU AI Act, GDPR 제17조, HIPAA, NIST AI RMF — 각각이 릴리스 프로세스에 요구하는 것과, 어떤 vindex 영수증 필드가 어떤 요구사항을 다루는지입니다.