5장. 출시와 운영

학습 목표

• 출시 범위(사용자군, 기능 범위, 제외할 유형)를 정하고 섀도 테스트, 카나리, 베타, A/B 실험 가운데 맞는 출시 방식을 고른다.
• 출시 전에 중단 기준과 되돌리는 방법을 정하고, 카나리 결과를 표본 크기와 대조군 비교로 판단한다.
• 시스템·품질·사용자 행동·사업 지표를 층으로 나눠 운영 지표와 알림을 설계한다.
• 모델과 프롬프트의 변경을 버전, 회귀 평가, 단계적 반영으로 관리하고 모델 수명 주기 공지에 대비한다.
• 사고가 나면 확산 차단, 알림과 정정, 원인 수정과 복구, 기록과 비난 없는 회고, 재발 방지 조치의 순서로 대응하고, 운영 데이터로 개선 우선순위를 정한다.

들어가며

AI 기능을 출시하는 날, 팀은 대개 안도합니다. 평가를 통과했고, 출시 기준도 넘었습니다. 하지만 평가 세트는 어제까지의 세상이고, 출시 뒤의 사용자는 평가 세트에 없던 질문을 하고, 모델 제공사는 모델을 바꾸고, 팀은 프롬프트를 고칩니다. AI 기능의 품질은 출시 당일에 가장 명확히 파악되고, 그 뒤로는 지켜보지 않으면 조용히 변합니다.

Anthropic은 가장 효과적인 팀이 자동 평가, 운영 모니터링, A/B 실험, 사용자 피드백, 사람의 검토를 함께 쓴다고 설명합니다. 자발적 위험 관리 지침인 NIST AI RMF는 배포 후 모니터링 계획을 실행하고, 사고와 오류를 영향받는 사람들을 포함한 관련자에게 알리라고 권합니다. 출시와 운영은 이 원칙을 일정과 숫자로 바꾸는 일입니다.

이 장은 먼저 출시 범위와 출시 방식을 고르고, 카나리와 중단 기준을 설계합니다. 그다음 운영 지표와 알림, 모델·프롬프트 변경 관리를 다루고, 마지막으로 사고 대응과 회고, 운영 데이터로 개선 우선순위를 정하는 법을 익힙니다.

핵심 개념

출시는 측정의 시작이다

출시는 개발의 마침표가 아니라 실제 세상에서 성능을 재기 시작하는 출발점입니다. 오프라인 평가가 답하지 못한 질문, 즉 실제 사용자가 어떻게 쓰는지, 어떤 입력이 들어오는지, 사업 지표가 움직이는지는 출시 뒤에야 답할 수 있습니다. 그래서 출시 계획에는 무엇을 언제까지 재고, 어떤 숫자가 나오면 넓히고, 어떤 숫자가 나오면 멈출지가 들어 있어야 합니다.

비유하자면 출시는 새 다리의 개통과 같습니다. 설계 계산(오프라인 평가)을 통과해도, 처음에는 차량 통행을 제한하고 센서로 흔들림을 재며, 기준을 넘으면 통제한다는 규칙을 미리 정해 둡니다.

출시 범위 정하기

출시 범위는 세 축으로 정합니다.

평가에서 특정 유형만 기준에 못 미쳤고 그 유형을 사람에게 보낼 경로가 있다면, 그 유형을 빼고 출시하는 것이 범위 결정입니다. 제외는 실행 단계에서 강제돼야 하므로, 의도 분류기나 규칙 필터로 해당 유형의 입력을 알아보고 모델 대신 상담원이나 기존 안내로 보내는 장치를 함께 기획합니다. 범위는 기능 플래그 같은 장치로 조절할 수 있게 만들어, 나중에 넓히거나 좁힐 때 코드 배포 없이 바꿀 수 있게 합니다.

출시 방식 비교

AWS의 섀도 테스트 설명에 따르면 새 변형은 실제 요청의 복사본을 받되 호출한 애플리케이션에는 기존(프로덕션) 변형의 응답만 돌아가고, 섀도 변형의 응답은 버리거나 기록해 오프라인 비교에 씁니다. Google SRE는 카나리를 서비스 변경의 부분적이고 시간 제한이 있는 배포와 그 평가로 정의하고, 사실상 A/B 과정이라고 설명합니다.

카나리 설계

Google SRE의 카나리 장에서 기획자가 가져갈 원칙은 다섯 가지입니다.

1. 작게 시작한다. 결함이 미치는 영향은 결함에 노출된 트래픽에 비례한다.
2. 대조군과 비교한다. 카나리는 변경된 부분과 나머지 서비스(대조군)를 비교하는 과정이다. 시간이 관측 지표를 바꾸는 가장 큰 요인 가운데 하나이므로, 출시 전후가 아니라 같은 기간의 대조군과 비교한다.
3. 지표를 고른다. 지표는 문제를 드러낼 수 있어야 하고, 대표성이 있어야 하며, 변경에 귀속될 수 있어야 한다.
4. 충분히 오래, 충분히 크게. 카나리는 전체 배포를 대표할 만큼 커야 하고 충분히 오래 지속돼야 하며, 대표성 있는 표본을 처리할 만큼 트래픽을 받아야 한다.
5. 한 번에 하나. 동시에 여러 카나리를 돌리지 않는다. 두 변경을 함께 내보내면 지표 변화를 어느 쪽 탓으로 돌릴지 알 수 없다.

AI 기능의 카나리에서는 시스템 지표(오류, 지연)뿐 아니라 품질과 사용자 행동 지표(신고율, 상담 전환율, 재생성률)를 함께 봅니다. AI의 실패는 오류 응답 없이 일어나기 때문입니다.

중단 기준과 되돌리기

중단 기준은 출시 전에 숫자로 정합니다. "신고율이 대조군보다 0.5%p 이상 높으면 중단", "근거 인용 없는 답변이 2%를 넘으면 중단"처럼 씁니다. 결과를 본 뒤에 기준을 정하면 결과에 맞춰 기준을 고르게 됩니다.

중단 기준에는 판정에 필요한 최소 표본도 함께 적습니다. 대화 60건에서 나온 2%p 차이는 우연일 수 있고, 2만 건에서 나온 차이는 그렇지 않습니다. 비율로 판정하는 지표는 표본이 부족하면 넓히지도 되돌리지도 않고 노출 비율을 유지한 채 관찰을 늘립니다. 충분한 표본에서 기준을 넘으면 논쟁 없이 멈추고 되돌린 뒤 원인을 조사합니다. 다만 개인정보 노출, 유해한 생성물, 법 위반처럼 한 건도 허용하지 않는 즉시 중단 조건은 표본 크기와 관계없이 발견 즉시 멈추고 되돌립니다. 어떤 조건이 즉시 중단인지도 출시 전에 적어 둡니다. Google SRE는 문제가 보이면 배포를 멈추고 되돌리거나 사람을 불러 문제를 해결하라고 합니다. 기준을 넘은 상태에서 고친 버전을 바로 다시 내보내는 것은 검증하지 않은 변경을 또 노출하는 일입니다.

되돌리는 방법도 출시 전에 시험합니다. 기능 플래그를 끄면 이전 상태로 돌아가는지 확인하고, 이미 처리된 결과(발송된 메시지, 실행된 도구 호출, 반영된 정산)를 어떻게 바로잡을지 정해 둡니다. 정정 안내 발송, 반대 거래로 되돌리는 처리, 담당자의 수동 보정 가운데 무엇을 누가 할지까지 출시 계획서에 적습니다.

A/B 실험의 조건

A/B 실험은 효과를 기능에 귀속하는 가장 확실한 방법이지만, 조건이 맞아야 합니다.

1. 위험이 낮다. 절반의 사용자에게 새 안을 보여도 괜찮아야 한다.
2. 트래픽이 충분하다. 목표 지표의 차이를 우연과 구분할 만큼 표본이 쌓여야 한다.
3. 목표 지표가 하나로 정해져 있다. 결과를 보고 지표를 고르면 우연한 차이를 효과로 착각한다.
4. 가드레일 지표가 있다. 목표 지표가 좋아져도 신고율이나 환불률이 나빠지면 멈춘다.
5. 무작위로 나눈다. 사용자가 스스로 고르게 하면 성향이 다른 집단을 비교하게 된다.

Anthropic은 A/B 실험이 충분한 트래픽이 있을 때 큰 변경을 검증하는 방법이라고 설명합니다. 트래픽이 부족하면 실험 대신 운영 지표와 기록 검토, 사용자 인터뷰를 함께 보고 결론의 확실성을 낮춰 보고합니다.

운영 지표의 층

운영 지표는 네 층으로 나눠야 빈틈이 없습니다.

시스템 지표만 보면 지어낸 답을 놓칩니다. 오류 응답 없이 그럴듯한 오답이 나가기 때문입니다. Google PAIR 가이드가 말하는 배경 오류, 즉 사용자도 시스템도 오류로 인식하지 못하는 실패는 사용자 행동 지표에도 잡히지 않을 수 있습니다. 그래서 품질 층의 지표, 예를 들어 근거 인용 비율이나 매일 뽑는 표본의 자동·사람 채점이 필요합니다. 반대로 에이전트가 같은 도구를 반복 호출하다 결국 맞는 답을 내는 실패는 품질 지표에는 안 잡히고 요청당 토큰 같은 비용 지표에 잡힙니다.

알림 설계

지표는 보는 사람이 있어야 의미가 있습니다. 알림은 세 가지를 정합니다.

1. 기준. 어느 값을 넘으면 알리는가. 평소의 흔들림 폭을 알고 그 바깥으로 정한다.
2. 받는 사람과 할 일. 누가 받고, 받으면 무엇을 하는가(확인, 기능 축소, 중지).
3. 긴급도. 바로 대응할 것(서비스 장애, 개인정보 노출, 비용 폭증)과 다음 업무일에 볼 것(완만한 품질 저하)을 나눈다.

비용은 알림만으로 부족할 때가 있습니다. 에이전트의 반복 호출처럼 비용이 몇 시간 만에 불어나는 사고에 대비해 제공사 콘솔의 지출 한도 같은 강제 상한을 함께 둡니다. Claude 문서는 조직이나 워크스페이스에 설정한 지출 한도에 닿으면 API가 오류를 돌려준다고 설명합니다.

NIST AI RMF는 운영 중인 시스템의 기능과 동작을 모니터링하라고 하고(MEASURE 2.4), 배포 후 모니터링 계획에 사용자와 관련자의 의견을 포착해 평가하는 장치, 이의 제기와 무효화, 시스템 폐기, 사고 대응, 복구, 변경 관리를 포함하라고 합니다(MANAGE 4.1). 알림은 이 계획의 신경망입니다. 알림이 너무 많으면 아무도 보지 않으므로, 지표마다 "이 알림을 받으면 무엇을 하는가"에 답할 수 없다면 알림이 아니라 대시보드에 둡니다.

모델·프롬프트 변경 관리

AI 기능은 코드가 그대로여도 바뀝니다. 프롬프트를 고치면, 모델을 바꾸면, 제공사가 모델을 은퇴시키거나 API를 바꾸면 결과가 달라집니다. 그래서 프롬프트와 모델 설정도 코드처럼 관리합니다.

1. 버전을 남긴다. 프롬프트, 모델 이름, 설정을 버전으로 기록하고, 운영 기록에 어느 버전이 답했는지 남긴다.
2. 반영 전에 회귀 평가를 돌린다. 한 줄 수정도 다른 유형의 답을 바꿀 수 있다. 회귀 묶음으로 사례별 비교를 한다.
3. 모델 교체는 품질·지연·비용을 함께 잰다. 같은 프롬프트도 모델이 바뀌면 결과와 비용이 달라진다.
4. 단계적으로 반영한다. 큰 변경은 카나리로 내보낸다.

모델 수명 주기에도 대비합니다. Claude 문서는 모델 상태를 Active(완전 지원, 권장), Legacy(더 이상 업데이트되지 않고 앞으로 지원 중단될 수 있음), Deprecated(동작하지만 권장되지 않고 대체 모델과 은퇴일이 정해짐), Retired(사용 불가, 요청이 실패함)로 나눕니다. 공개 모델은 은퇴 최소 60일 전에 알리며, 은퇴일보다 충분히 앞서 새 모델로 시험하라고 권합니다. 모델만이 아닙니다. 같은 문서의 매개변수 지원 중단 표에 따르면 temperature, top_p, top_k 같은 샘플링 매개변수는 2026-10-21 API 버전에서 제거돼 지정하면 400 오류를 돌려주고, 그 이전 API 버전에서도 Claude 4.7 이후 모델에 기본값이 아닌 값을 주면 400 오류가 납니다. 제공사의 공지를 정기적으로 확인하는 일도 운영 업무입니다.

사고 대응

AI 기능의 사고는 잘못된 안내, 개인정보 노출, 부적절한 생성물, 비용 폭증처럼 다양합니다. 대응 순서는 다음과 같습니다.

1. 확산을 막는다. 기능을 끄거나, 해당 유형을 사람에게 돌리거나, 이전 버전으로 되돌린다.
2. 영향받은 사람을 찾고 알리며 바로잡는다. 잘못된 정보를 믿고 행동할 사람이 남아 있으면 알리는 일이 먼저다.
3. 원인을 고치고 복구한다. 원인을 찾아 고친 버전을 회귀 평가로 확인한 뒤 단계적으로 다시 연다.
4. 기록을 보고서로 정리한다. 대응하는 동안 상태와 조치를 계속 기록하고, 끝나면 경위, 영향, 원인, 조치를 사고 보고서로 정리한다.
5. 회고한다. 개인을 탓하지 않고 기여 원인을 중심으로 분석한다.
6. 재발 방지 조치를 실행하고 확인한다. 담당자와 기한을 붙인다.

NIST AI RMF는 사고와 오류를 영향받는 공동체를 포함한 관련자에게 알리라고 합니다(MANAGE 4.3). 원인을 고쳐 배포했다고 사고 대응이 끝나지 않습니다. 이미 잘못된 안내를 받은 사람이 남아 있기 때문입니다.

비난 없는 회고

Google SRE는 회고(postmortem)를 사고와 그 영향, 완화나 해결을 위해 한 조치, 근본 원인, 재발을 막기 위한 후속 조치를 담은 기록으로 정의합니다. 회고를 여는 조건의 예로 사용자에게 보이는 일정 수준 이상의 장애나 품질 저하, 모든 종류의 데이터 손실, 담당자의 개입(배포 되돌리기, 트래픽 돌리기 등)을 듭니다. 그리고 비난 없는 회고는 개인이나 팀을 탓하지 않고 사고의 기여 원인을 찾는 데 집중해야 한다고 강조합니다.

AI 기능의 회고에서 자주 나오는 기여 원인은 이렇습니다. 프롬프트 변경이 회귀 평가 없이 반영됐다, 평가 세트에 해당 유형이 없었다, 품질 지표에 알림이 없었다, 검토자에게 근거가 보이지 않았다. 재발 방지 조치는 이 원인을 겨눠야 합니다. 사고 사례를 회귀 묶음에 넣고, 빠진 알림을 만들고, 변경 절차를 고칩니다. 운영 대화를 평가 세트에 넣을 때는 개인정보를 먼저 가리거나 비식별 처리합니다. Google SRE도 사고 지휘자가 대응 중 살아 있는 사고 문서를 유지하고, 그 기록을 회고 분석에 쓰도록 보존하라고 합니다.

운영 데이터로 개선 우선순위 정하기

운영 데이터가 쌓이면 고칠 것이 많아집니다. 개선 인력은 한정돼 있으므로 순서를 정해야 합니다. NIST AI RMF는 기록된 위험의 처리 우선순위를 영향, 가능성, 가용 자원이나 방법에 따라 정하라고 합니다(MANAGE 1.2).

실무에서는 실패 유형마다 "월 발생 건수 × 건당 피해 × 고객에게 실제로 나간 비율"을 계산합니다. 이미 있는 통제(검증 단계, 사람 검토)가 걸러 내는 몫은 마지막 항에서 빠집니다.

이 표에서는 가장 위험해 보이는 "근거 없는 안내"보다 과잉 거절이 먼저입니다. 다만 숫자로만 정하지 않는 예외가 있습니다. 법·안전 문제나 신뢰를 크게 해칠 수 있는 유형은 건수가 적어도 통제가 충분한지 따로 확인합니다. 유형 이름이 주는 인상과 실제 피해를 구분하는 것이 이 판단의 핵심입니다.

단계적 출시 계획서

[단계적 출시 계획서]
기능과 버전:
출시 범위: 사용자군 / 포함 유형 / 제외 유형과 그 처리 경로
출시 방식: 섀도 / 카나리 / 베타 / A/B, 고른 이유
단계: 예) 1% → 10% → 50% → 100%(트래픽과 위험에 맞춰 조정), 단계별 최소 기간과 최소 표본
비교 대상: 같은 기간 대조군
중단 기준: 지표, 기준값, 판정 최소 표본
되돌리는 방법: 플래그, 이전 버전, 이미 처리된 결과의 처리
운영 지표와 알림: 시스템 / 품질 / 사용자 행동 / 사업, 받는 사람과 할 일
변경 관리: 프롬프트·모델 버전, 회귀 평가 조건, 제공사 공지 확인 주기
사고 대응: 연락 체계, 회고 조건

깊이 읽기

지표를 바꾸고 싶은 유혹

출시 뒤 목표 지표가 움직이지 않으면 다른 지표를 찾고 싶어집니다. "전환율은 그대로지만 추천 클릭 수는 30% 늘었다." 이 보고는 거짓이 아니지만, 기능이 목적을 이뤘다는 증거도 아닙니다. 클릭은 늘었는데 구매가 그대로라면 추천이 호기심만 끌고 쓸모는 없다는 뜻일 수도 있습니다.

Google PAIR 가이드는 단기적으로 좋아 보이는 지표(예를 들어 공유 수)를 최적화하는 것이 장기적으로 해로울 수 있다고 경고하고, 지표가 완벽하게 최적화됐을 때 사용자와 사회에 무슨 일이 생길지 상상해 보라고 권합니다. 목표 지표와 가드레일 지표는 출시 전에 정하고, 결과가 나쁘면 지표를 바꾸는 대신 원인을 찾습니다. 지표를 바꾸는 것이 정당한 경우는 처음 고른 지표가 목적을 재지 못한다는 것이 결과와 무관한 근거로 밝혀졌을 때뿐이며, 그때도 바꾼 이유를 기록합니다.

조용한 품질 저하

AI 기능의 품질은 아무것도 바꾸지 않아도 떨어질 수 있습니다. 사용자층이 넓어지며 입력의 분포가 바뀌고(새 지역, 새 상품군, 새 표현), 근거 문서가 갱신되며 낡은 인용이 남고, 제공사의 모델이 바뀝니다. 출시 때의 평가 세트는 이 변화를 모릅니다.

조용한 저하를 잡는 방법은 세 가지입니다. 매일이나 매주 운영 기록에서 표본을 뽑아 같은 채점 방식으로 점수를 매겨 추이를 봅니다. 입력의 유형 분포를 출시 때와 비교해 새로운 유형이 늘었는지 봅니다(입력 분포의 변화를 흔히 데이터 드리프트라고 부릅니다). 사용자 행동 지표(재생성, 상담 전환)의 추세를 봅니다. 셋 중 하나가 움직이면 기록을 읽고, 새로 찾은 실패를 평가 세트에 더합니다.

기능을 끄는 결정

모든 AI 기능이 계속 돌아야 하는 것은 아닙니다. 운영 비용이 효과를 넘거나, 사용자가 쓰지 않거나, 위험이 통제되지 않으면 기능을 줄이거나 끄는 것도 운영 결정입니다. NIST AI RMF는 의도한 용도에서 벗어난 시스템을 대체하거나 해제하거나 끄는 장치와 책임을 두라고 합니다.

기능을 끌 때도 계획이 필요합니다. 사용자에게 미리 알리고, 대체 경로를 안내하고, 기능이 남긴 데이터(대화 기록, 생성물)를 정책대로 처리하고, 왜 껐는지 기록합니다. 끄기로 한 판단의 근거는 1장의 AI 적용 판단 메모(과제, 처리량, 해법, 데이터·비용 조건, 법적 검토, 결론)와 같은 형식으로 남기면, 나중에 같은 아이디어가 다시 올라왔을 때 무엇이 바뀌어야 하는지 알 수 있습니다.

실무 장면

새싹뱅크의 이체 문의 상담

인터넷 은행 '새싹뱅크'는 이체 한도와 수수료 문의에 답하는 AI 상담을 출시하려 합니다. 하루 문의는 3만 건이고, 오프라인 평가에서 차단 기준을 모두 넘었습니다. 다만 해외 송금 수수료 유형은 기준에 못 미쳐 범위에서 빼고 기존 상담원 경로로 보내기로 했습니다.

기획자는 카나리를 골랐습니다. 결과를 고객이 보고 잘못되면 상담원이 정정할 수 있어 되돌리기 쉬웠고, 실제 고객의 신고율과 상담 전환율을 봐야 했기 때문입니다. 단계는 1% → 10% → 50% → 100%로, 1% 단계는 최소 3일·대화 900건, 10% 단계부터는 최소 3일·대화 5,000건 이상을 판정 조건으로 걸었습니다. 중단 기준은 "수수료 오안내 신고율이 대조군보다 0.3%p 이상 높음"과 "근거 인용 없는 답변 1% 초과"였습니다. 같은 기간에 예정돼 있던 앱 메인 화면 개편은 카나리가 끝난 뒤로 미뤘습니다. 두 변경이 겹치면 지표 변화를 어느 쪽 탓으로 돌릴지 알 수 없기 때문입니다.

10% 단계 사흘째, 그 단계의 누적 대화 9,000건에서 근거 인용 없는 답변이 1.6%로 기준을 넘었습니다. 팀은 확대를 멈추고 기능 플래그를 꺼 모든 문의를 기존 상담 경로로 되돌린 뒤 원인을 찾았습니다. 수수료 규정 문서가 개정돼 이전 문서와 새 문서가 함께 검색되고 있었습니다. 1%와 10% 단계의 기록을 모두 확인하니 이전 수수료를 안내한 대화가 152건이었고, 팀은 그 고객들에게 정정 안내를 보낸 뒤 문서 색인을 고치고 회귀 평가를 거쳐 1%부터 다시 열었습니다. 그리고 회고를 열었습니다. 회고에서 나온 재발 방지 조치는 "근거 문서 개정 시 이전 버전 색인 제거 절차"와 "문서 개정일을 회귀 평가 실행 조건에 추가"였습니다. 버린 안은 "프롬프트에 새 문서를 우선하라는 문장을 넣어 같은 비율로 바로 재개"였습니다. 원인이 확인되기 전이었고, 검증하지 않은 변경을 다시 노출하는 일이었습니다. 검색 색인에 남은 이전 문서는 프롬프트 지시만으로 확실히 막을 수도 없었습니다.

노을티비의 검색 도우미 운영

동영상 서비스 '노을티비'는 AI 검색 도우미를 넉 달째 운영하고 있습니다. 개선 인력은 다음 분기에 두 가지 과제만 맡을 수 있습니다. 운영 데이터에서 나온 후보는 다섯 가지였습니다. 출연자 이름을 잘못 연결하는 오류, 성인 콘텐츠가 어린이 프로필 결과에 섞이는 오류, 응답 지연, 검색어를 이해하지 못해 거절하는 경우, 추천 결과가 매번 비슷한 문제였습니다.

기획자는 월 건수, 건당 피해, 고객에게 실제로 나간 비율로 월 피해를 계산한 표를 만들었습니다. 거절은 월 2만 건으로 가장 많았고, 거절 뒤 이탈로 시청 시작이 줄었습니다. 어린이 프로필 오류는 월 6건이었지만 차단 필터를 통과한 실제 노출이 2건 있었고, 법·신뢰 문제로 이어질 수 있었습니다. 기획자는 숫자로는 거절을 첫 과제로, 건수는 적지만 통제가 뚫린 어린이 프로필 오류를 둘째 과제로 골랐습니다. 이미 통제되고 있는 위험과 실제로 뚫린 위험을 구분한 결정이었습니다.

변경 관리도 정비했습니다. 그동안 프롬프트는 담당자가 필요할 때 운영 환경에서 고쳐 왔습니다. 이제 프롬프트를 버전으로 남기고, 매주 화요일 정기 반영 때만 회귀 묶음 400건을 돌려 통과한 버전을 10% 카나리로 내보내기로 했습니다. 모델 제공사의 지원 중단 공지는 매달 첫째 주에 확인하고, 은퇴 공지가 나오면 그 주에 대체 모델로 전체 평가를 돌리는 규칙도 넣었습니다.

자주 틀리는 지점

1. "오프라인 평가를 통과했으니 바로 전체 출시해도 된다." 실제 사용자와 입력은 평가 세트와 다릅니다. 노출을 제한하고 재며 넓힙니다.
2. "카나리는 출시 전과 후를 비교하면 된다." 시간이 지표를 바꾸는 가장 큰 요인 가운데 하나입니다. 같은 기간의 대조군과 비교합니다.
3. "중단 기준은 결과를 보고 정하면 된다." 결과를 본 뒤 정한 기준은 결과에 맞춰집니다. 출시 전에 숫자와 최소 표본을 정합니다.
4. "기준을 넘었으면 고쳐서 바로 다시 내보내면 된다." 먼저 멈추고 되돌린 뒤 원인을 확인합니다. 검증하지 않은 변경을 다시 노출하지 않습니다.
5. "여러 변경을 함께 단계적으로 내보내면 시간을 아낀다." 효과를 귀속할 수 없게 됩니다. 한 번에 하나의 카나리를 돌립니다.
6. "오류 응답과 지연만 보면 운영 상태를 안다." AI의 실패는 오류 없이 일어납니다. 품질과 사용자 행동 지표가 필요합니다.
7. "지원 중단된 모델은 은퇴일 뒤에도 느려질 뿐 동작한다." 은퇴한 모델로 보낸 요청은 실패합니다. 은퇴일보다 충분히 앞서 교체를 평가합니다.
8. "원인을 고쳐 배포했으면 사고 대응은 끝났다." 잘못된 안내를 받은 사람에게 알리고, 기록하고, 재발 방지 조치를 실행해야 끝납니다.

한눈에 정리

공식 문서로 확인하기

• Google SRE Workbook — Canarying Releases: 카나리의 정의, 대조군 비교, 지표 선택, 기간과 규모, 한 번에 하나.
• Google SRE Book — Postmortem Culture: Learning from Failure: 회고의 정의와 조건, 비난 없는 회고.
• Google SRE Book — Managing Incidents: 대응 중 살아 있는 사고 문서.
• AWS — Amazon SageMaker AI shadow tests: 섀도 테스트의 동작 방식.
• Claude Docs — Model deprecations: 모델 수명 주기, 은퇴 공지 기간, API 매개변수 지원 중단.
• Anthropic — Demystifying evals for AI agents: 자동 평가, 운영 모니터링, A/B 실험, 사람 검토의 조합.
• NIST AI RMF — Core: MANAGE 1.2(우선순위), 2.4(대체·해제·중지), 4.1(배포 후 모니터링), 4.3(사고 알림).
• Google PAIR Guidebook — User Needs + Defining Success: 보상 함수와 단기 지표 최적화의 위험.

셀프 체크

5-1. Google SRE가 카나리 지표에 요구하는 세 가지 성질을 쓰라.

5-2. 섀도 테스트로 잴 수 없는 것은 무엇이고, 그것이 필요하면 어떤 출시 방식을 써야 하는가?

5-3. 중단 기준에 최소 표본을 함께 적어야 하는 이유를 설명하라.

5-4. 운영 지표의 네 층을 쓰고, 지어낸 답이 오류 응답률에 잡히지 않는 이유를 설명하라.

5-5. Claude 문서의 모델 수명 주기 네 단계를 쓰고, 마지막 단계에서 요청이 어떻게 되는지 쓰라.

5-6. 사고 대응의 여섯 단계를 순서대로 쓰라.

5-7. 월 50건, 건당 피해 4만 원, 검증 단계에서 90%가 차단되는 유형과, 월 1,200건, 건당 피해 2,000원, 차단 장치가 없는 유형이 있다. 월 피해로 비교하면 어느 쪽이 먼저인가?

5-8. (설계) 지금 맡은 AI 기능의 단계적 출시 계획서를 이 장의 양식으로 쓰되, 중단 기준 두 개에 최소 표본을 붙이라.

실습 과제