게이트(Gate)는 의도 분류(Intent-classification) 평가에서 90%라는 고정 임계값(Threshold)을 기준으로 설정되어 있었습니다. 변경 사항은 91%로 들어왔고, 기준을 통과하여 배포되었습니다. 고정된 통과율 게이트는 급격한 붕괴(Collapse)는 잡아내지만, 드리프트(Drift)는 잡아내지 못합니다. 이것은 드리프트였고, 그대로 통과해 버렸습니다.

거짓말을 한 숫자: 91%

평가 점수는 몇 주 동안 96-97%를 유지해 왔습니다. 검색(Retrieval) 변경 사항으로 인해 하나의 슬라이스(Slice, 모호한 환불 요청)가 98%에서 74%로 떨어졌습니다. 해당 슬라이스는 트래픽의 4%를 차지하므로, 전체 합계(Aggregate)는 91%로만 떨어졌습니다. 90%를 넘었기에 게이트는 초록불(Green)을 유지했습니다. 합계 수치는 합계 수치가 하는 일을 정확히 수행했습니다. 즉, 실제 실패를 노이즈(Noise) 속으로 평균화해 버린 것입니다.

해당 슬라이스에 해당하는 사용자들은 91%를 경험한 것이 아닙니다. 그들은 74%를 경험했습니다.

절대 임계값(Absolute threshold)이 실제로 측정하는 것

정적인 임계값은 한 가지 질문에만 답합니다. "전체가 낭떠러지로 떨어졌는가?" 그것은 다른 모든 것이 버티고 있는 동안 특정 슬라이스가 조용히 악화되었는지에 대해서는 아무것도 말해주지 않습니다. 96개의 슬라이스가 괜찮고 하나가 폭락한다면, 높은 하한선(Floor)이 그 폭락을 가려버립니다. 당신은 이를 CI(지속적 통합)가 아니라 고객 지원 티켓을 통해 알게 됩니다.

해결책: 슬라이스별 델타(Delta) 기반 게이트

우리는 절대적인 수치로 게이트를 설정하는 것을 중단하고, 마지막으로 통과한 실행(Run)을 기준으로 게이트를 설정하기 시작했습니다. 다음 두 가지 규칙이 모두 충족되어야 합니다:

1. 단일 슬라이스가 베이스라인(Baseline) 대비 3포인트 이상 하락하지 않을 것.
2. 전체 합계가 베이스라인 대비 1.5포인트 이상 하락하지 않을 것.

def gate(current, baseline):
    failures = []
    for slice_name, score in current.slices.items():
...

환불 슬라이스가 24포인트 하락했다면, 전체 합계가 어디에 위치하든 첫 번째 실행에서 규칙 1을 위반하여 실패했을 것입니다.

뼈아픈 부분: 베이스라인 관리

델타 게이트(Delta gating)는 베이스라인이 당신과 함께 아래로 드리프트되는 순간 무너집니다. 만약 베이스라인이 매 실행마다 업데이트된다면, 매일 0.5포인트씩 미끄러지는 현상은 매번 통과될 것이고, 당신은 2주에 걸쳐 성능 퇴보(Regression)로 직행하게 됩니다. 스스로 골대를 옮기는 게이트에게 느린 드리프트는 보이지 않습니다.

따라서 베이스라인(Baseline)은 main 브랜치가 초록불(Green)일 때만 업데이트되며, 의도적인 성능 하락이 발생할 경우 그것이 새로운 바닥(Floor)이 되기 전에 반드시 사람의 승인을 거쳐야 합니다. 베이스라인은 '가장 최근의 기록'이 아니라, '검증된 양호한 기록'입니다.

가장 먼저 확인해야 할 사항

• 슬라이스(Slice)별로 지난 5번의 초록불 실행(Green runs) 동안의 분산(Variance)을 추출하세요. 만약 특정 슬라이스가 실행 간의 변화량(Delta) 임계값(Threshold)보다 더 크게 요동친다면, 당신의 임계값은 신호(Signal)가 아니라 노이즈(Noise)입니다.
• 가장 작은 슬라이스를 가져와서 질문해 보세요: 전체 집계(Aggregate)가 감지하기 전에 이 슬라이스가 얼마나 더 떨어질 수 있는가? 만약 그 답이 "매우 많이"라면, 전체 집계가 문제를 숨기고 있는 것입니다.
• 베이스라인이 오직 사람이 개입된(Human in the loop) 상태에서 초록불 main 브랜치에서만 전진하는지 확인하세요. 만약 매 실행마다 업데이트된다면, 당신은 드리프트(Drift)를 차단(Gating)하고 있는 것이 아니라, 드리프트를 따라 아래로 내려가고 있는 것입니다.