■ PoC → 파일럿 → 확장 게이트

세 단계는 묻는 것이 다르다 업계 일반 단계 정의는 공식 문서 없음 [6.5]

• PoC : 고른 사례로 "되나?" 를 묻는다
• 파일럿 : 실제 트래픽 일부와 좁힌 권한에서 미리 정한 선을 넘나?
• 운영 : 전체에 적용한다

공식 근거 : 수동 테스트·dogfooding·직감으로도 꽤 간다. 그러나 프로토타입 단계를 지나 운영에서 커지기 시작하면 eval 없이 개발하는 방식이 무너진다

테스트 운영 환경에 배포해 eval 을 돌리기 전에는 프롬프트가 얼마나 잘 되는지 알기 어렵다 (고객지원 가이드)

파일럿 게이트 = 시작 전에 정한다 : 아래 다섯 가지를 정한다 업계 일반 [6.5] [6.3①]

• 합격선 : 예 반품 한 건 처리 시간 · 상담원 수정률
• 중단 규칙 : 예 규정과 다른 환불 안내 1건이면 정지
• go/no-go 를 내릴 지정된 한 사람과 나머지의 발언권
• 권한 경계 : 읽기·초안만
• 검토 피드백 받는 모양

기준 없이 돈 파일럿은 사후에 판정할 수 없다. 할인·예산 마감이 있어도 기준을 정한 뒤 다시 돌린다 업계 일반

권한 : 기본은 읽기 전용이다. 코드·시스템을 바꾸는 행동 전에는 사람이 승인한다 (Claude Code 문맥이다. 파일럿 권한으로 넓힌 것은 해석이다)

자세한 것은 ■ human-in-the-loop 게이트 위치 에 있다

합격선 문장 모양은 ■ 성공 기준 에 있다. 결정권자 한 명은 ■ discovery 산출물 에 있다

반대 쪽 : 모델 벤치마크 세부 · 확정 SLA 문구 · on-call 순번은 뒤 게이트의 일이다. 파일럿 전에 다 요구하지 않는다 업계 일반. SLA 는 ■ SLA 조항 쓰기 에 있다

고른 데모 ≠ 측정 : 고른 사례 몇 건의 정확도는 "되나" 의 증거일 뿐이다. 대표 표본으로 기준선을 잰 뒤 약속한다 업계 일반 원리는 아래 [6.5] [6.3①]

공식 근거는 아래다

• 트래픽의 대표 표본을 돌려 비교한다 (thinking 조정 문맥)
• 운영 로그에서 실제 트래픽 비중대로 과제를 뽑는다 (비용 최적화 문맥)
• 자동 eval 은 실사용 패턴과 어긋나면 거짓 확신을 준다
• 몇 번 해 보고 코너 케이스 한두 개 고치는 것도 사용자의 예상 밖 입력에는 모자라다 (Skilljar)

"데모에서 잘 됨" 함정의 본편은 ■ 변경마다 eval 다시 에 있다

파일럿 성공은 가설 검증이지 운영 검증이 아니다. 그래서 넓히기 전에 먼저 묻는다. "작은 규모에서 성립한 어떤 가정이 큰 규모에서 깨지나?"(입력 분포 · 엣지 케이스 · 지원 부담 · 비용). 라이선스 · 교육 일정은 그 뒤다 업계 일반

공식 근거 : 운영 모니터링은 출시 뒤 분포 변화와 예상 못 한 실패를 잡는다. 자세한 것은 ■ 검증 층 에 있다

넓히기는 단계적으로 : 부서·문의 종류를 하나 더 넓힌다. 다른 입력 분포에서 정확도·지연이 유지되는지 잰 뒤 다음으로 간다 업계 일반 [6.5]

공식 근거 : 최종 고른 구성은 전환 전에 트래픽 일부에 shadow 로 돌린다. 전환 뒤에도 eval suite 를 계속 돌린다 (모델 구성 고르기 문맥)

사용량이 갑자기 늘면 acceleration limit(가속 한도)으로 429 가 난다. 그래서 트래픽은 조금씩 올린다. 자세한 것은 ■ API 오류별 대응 에 있다

구버전·신버전을 함께 돌리며 트래픽을 조금씩 옮기는 방법은 ■ 에이전트 상태·실패·배포 에 있다

되돌리기 어려운 결정(사람 검토 팀 해체 · 옛 시스템 폐기)은 단계적으로 줄인다. 지금 합의한 정지 선으로 되돌릴 길을 남긴다. "기준 통과했으니 예정대로 한 번에" 는 되돌리는 비용을 숨긴다 업계 일반

비용은 운영 볼륨으로, 첫 청구서 전에 본다. 프로토타입에서 운영으로 가면 비용이 핵심 설계 제약이 된다. 가장 좋은 모델이 규모에서는 너무 비쌀 수 있다. 지출 임계값 알림을 건다

그래서 전체 월 문의량으로 다시 센다. 캐싱·모델 조합·알림 설정(무엇을 언제 울릴지)을 넓히기 전에 말한다 업계 일반. 자세한 것은 ■ per-request cost · ■ 최적화 lever 하나 고르기 에 있다

넓힐 근거 : 목표 사업 지표의 전·후(같은 방법으로 측정), 대조군(control), 측정 담당자를 든다 업계 일반 [6.5] [1.6②]

요청 수 · 지연 · 오류율은 돌아간다는 증거일 뿐이다. 사업 결과가 아니다 업계 일반. 사업 지표 목록(AHT · deflection · CSAT)은 ■ impact metrics 에 있다

공식 근거 : A/B 는 실제 사용자 결과(유지율 · 과제 완료율)를 재고 교란을 통제한다. A/B 는 기준 모델·이전 버전과 비교한다

그래서 대조군 없는 전·후 비교는 그 사이 다른 변화(성수기 · 인력)와 구분하지 못한다 (해석). 자세한 것은 ■ 검증 층 에 있다

전 값만 있으면 바람일 뿐이다. 후 값만 있으면 근거 없는 주장이다 업계 일반. 후 값에 운영 시간이 모자라면 측정 시점을 마일스톤으로 잡고 담당자·대조군 기록부터 남긴다 업계 일반

새 목적 = 새 use case : 서비스가 건강해도 목적이 바뀌면 반복이 아니라 새 use case 다. 결정권자 · 기준선 · 제약부터 다시 정한다 업계 일반 [6.5] [6.1①]

목적이 바뀌는 예 : 배송 안내에서 환불 승인 여부 결정으로 바뀐다. 문의 요약에서 상담원 순위 매기기로 바뀐다

전면 거절도, 기존 릴리스 절차로 밀어 넣기도 아니다. 다시 범위를 잡는다 업계 일반. 자세한 것은 ■ discovery 산출물 에 있다. 요구가 바뀐 증거가 있을 때 discovery 로 가는 것은 ■ lifecycle 루프 · 규칙 ③ 에 있다

게이트 순서 : eval 셋과 합의된 trade-off(절충)는 handoff 계획 앞에 둔다. 되돌리기 절차와 지정된 담당자는 handoff 앞에 둔다 업계 일반. 자세한 것은 ■ handoff 패키지 에 있다

반복(iteration)은 설계로 돌아간다. discovery 로는 요구가 바뀔 때만 간다 (■ lifecycle 루프)