VS 품질 평가 · 정책안

코드 · 스냅샷 변경은 두 게이트에서 「나빠지지 않았는지」 권고로 확인한다

develop 에서 staging 으로 갈 때 스테이징 승격 검사, staging 에서 production 으로 갈 때 운영 출시 판정(구축 중). production 뒤는 채택 · 다운로드 통계로 본다. 바뀌는 것 코드 = iui 검색(Rust) + 대치 TS(comp-frame-client) 스냅샷 = 매번 전체를 다시 추출한 새 판 develop staging production 채택 · 다운로드 통계 스테이징 승격 검사 운영 출시 판정 구축 중
결과는 권고다. 배포를 자동으로 막지 않는다.

두 게이트

두 게이트는 비교하는 짝이 다르다

스테이징 승격 검사
운영 출시 판정 구축 중
언제
iui main 머지 직후, 요청이 있을 때
운영 배포 일정마다
무엇 대 무엇
머지 직전 main대머지 커밋
스냅샷 = 그 시점 staging
지금 운영대나갈 staging
코드 + 스냅샷
무엇을 보나
변경 하나의 효과
출시 묶음 전체의 합산 효과
결정
변경 담당자
내부 담당자끼리 논의
같은 걸 두 번 재나?
아니다. 앞은 변경 하나, 뒤는 여러 변경이 쌓인 묶음이다. 묶음 안에서 누구 몫인지는 앞 게이트 결과로 돌아가 본다. 스냅샷 변경은 staging 판 대 새 dev 판(코드 = staging)을 judge 로만 잰다. 반영은 스냅샷 담당자가 정한다.

측정기

채택 판단은 tester, 안전망은 judge 가 맡는다

tester 는 기본 품질 카드 18장을 단계 다섯으로 나눠 잰다. judge 는 페이지 그림의 BAD 비율을 c4-250 표본으로 잰다. tester기본 품질 카드 18장 채택 판단 생성색인검색대치보이는 결과 G1G3G8 B2P1P2 R4R6R7R8 D2D3D4D8 E1E3E4E5 표본 = 고정 2,000 원문(상위 10 전체) + 변경을 겨냥한 묶음 judge 안전망 페이지 그림의 BAD 비율 BAD 표본 c4-250 「나빠지지 않았다」 확인용
카드별 차이의 95% 구간이 전부 악화 쪽이면 악화, 0 을 품으면 못 가림, 전부 개선 쪽이면 개선. judge 는 ±1.3%p 안이면 못 가림. 구간이 전부 악화 쪽구간이 0 을 품음구간이 전부 개선 쪽judge ±1.3%p 안 악화개선 악화개선 악화개선 악화개선 0000 악화 못 가림 개선 못 가림
측정기를 믿을 수 있나?
신뢰도 관문을 통과한 카드만 쓴다. judge 는 같은 그림을 다시 판정해도 ±1.2–1.3%p 흔들리므로 그 안은 판정하지 않는다. 카드 이름은 부록에 있다.

요청

스테이징 승격 검사는 요청 하나로 시작해 보고서로 끝난다

iui 개발자가 머지 뒤 요청을 내고, VS 평가 담당이 접수 회신과 측정을 하고, 결과가 보고서와 스레드 답글과 화면 행으로 나오면, 개발자가 staging 반영을 정한다. iui 개발자 VS 평가 담당 결과 (류민) 요청 작성 읽고 정함 ① iui main 머지 #vs-eval-request 에서 「VS tester 요청」 제출 ② 접수 회신 바뀐 경로 확인 (검색 · 프롬프트 · 대치 TS) 안 바뀌었으면 생략과 사유 ③ 측정 고정 2,000 + 겨냥 묶음 judge 는 「예」일 때만 ④ Confluence 보고서 요청마다 한 페이지 요청 스레드에 결론과 링크 화면 「스테이징 승격 검사」에 행 ⑤ staging 반영 결정 권고를 참고한다
요청 양식은 다음 장에 있다.

요청 양식

요청 양식은 여덟 칸이고, 겨냥 설정은 바꾼 것에 맞춘다

1main 머지 커밋 ID
2바꾼 것
3기대하는 변화
4겨냥 원문 수
100300500
5겨냥 순위 범위
1–31–10
6LLM judge 도 필요한가
예아니오
7tester 항목 추가
8바라는 회신 시점

바꾼 것에 맞춘 겨냥 설정

순위 · 나눠 담기 · 하위 후보 공급을 바꿈순위 1–10
프롬프트만 바꿈원문 100
여러 머지가 한 번에 staging 에 올라감커밋마다 따로 잰다

시간

결과는 반나절 안팎에 온다

tester 는 4.5–6시간, judge 를 더하면 0.5–2.5시간이 추가된다. 01234567시간 tester judge 추가 tester 4.5–6시간 4.5–6시간 judge 추가 0.5–2.5시간 0.5–2.5시간 최소 시간 걸릴 수 있는 범위(추정)
judge 는 요청에 「예」라고 적었을 때만 더해진다.
오후 요청은 다음 영업일에 회신한다(제안). 비용은 측정 담당이 관리한다. 요청 1건 기본 설정은 약 $22–41 이고, $35 를 넘는 설정은 접수 때 알려 준다. 비용 표 전체는 부록에 있다.

운영 출시 판정

운영 출시 판정은 출시 묶음 전체의 합산 효과를 본다 구축 중

구축 중. 운영 코드 + 스냅샷 대 staging 코드 + 스냅샷을 tester(코드만 바뀐 배포)와 judge(iframe, staging 판)로 재고, 보고서를 써서 내부 논의로 정한다. 구축 중 비교 짝 지금 운영 코드 + 스냅샷 대 나갈 staging 코드 + 스냅샷 tester 코드만 바뀐 배포 judge iframe · staging 판 보고서 내부 논의

준비 상태 (11/09)

  • 정책 초안됨
  • 환경 정보 기록 시작어느 환경에 무슨 판이 떠 있나 · iui 환경 상태 기록 · 환경 띠됨
  • judge 운영 판 기준 회차남음
  • staging iframe 수집 시험남음
  • 첫 판정남음
지금은 운영 배포마다 판정이 돌지 않는다. 내 변경의 효과는 스테이징 승격 검사로 확인한다.

비교 규칙

같은 스택끼리만 비교한다

스택 키는 코드 판과 data_version 두 칸으로 판정한다. 한 칸이라도 다르면 다름, 두 칸 모두 양쪽 기록으로 같으면 같음, 그 밖은 같은지 모름. 스택 키 코드 판 iui + 대치 TS data_version 스냅샷 규격 MAJOR 유효 컴포넌트 판 판정에 쓰는 두 칸 함께 적되 판정에 넣지 않는다 코드 판 data_version 판정 한 칸이라도 값이 다르면 A B X X ≠다름 두 칸 모두 양쪽 「기록」으로 같으면 A A X X 기록기록기록기록 =같음 그 밖 추정 · 설정값, 한쪽 모름 A A X ? 기록추정설정값 ?같은지 모름
다른 환경에서 잰 수를 섞은 것 아닌가?
회차마다 스택 키와 환경 라벨(dev · stg · prd · local)을 싣고, 스택 키가 없는 회차끼리는 비교하지 않는다. 측정기(카드 판 · 판정 모델 · 프롬프트 · 반복 수)가 바뀐 회차도 갈라 표시한다.

화면 지도

결과는 「VS 품질 평가」 화면 한 곳에서 본다

/visual-summary/quality 아래에 개요, 스테이징 승격 검사, 운영 출시 판정, 카드 상세, 환경 상세, 분석 · 측정기가 있다. 개발자는 슬랙 회신 링크로 스테이징 묶음 상세에 들어와 움직인 카드를 눌러 카드 상세로 간다. VS 품질 평가 /visual-summary/quality 개요 환경 띠 · 현재 기준선 최근 두 게이트 표 스테이징 승격 검사 /staging 운영 출시 판정 /release ◐ 구축 중 카드 상세 /cards/<카드> 환경 상세 /env 분석 · 측정기 /analysis /meters/tester /meters/judge/samples 묶음 상세 /staging/<묶음> 묶음 상세 /release/<묶음> ① 슬랙 회신 링크 ② 움직인 카드를 누른다
개발자가 주로 보는 길: 슬랙 회신 링크 → 묶음 상세(스테이징) → 움직인 카드 → 카드 상세. 화면 이름을 누르면 설명서로 간다.

화면 설명서 · 개요

개요 한 장에서 환경마다 떠 있는 판과 그 판으로 잰 최근 성능을 본다

환경 띠

개요 화면의 환경 띠. dev · stg · prd 카드에 지금 스택과 그 스택으로 잰 최근 성능이 있다.
개요 화면의 타일 셋: 운영 판, tester 판정(직전 대비), judge BAD 지금.
최근 운영 출시 판정 묶음 표와 최근 스테이징 승격 검사 요청 칸.
  1. 환경 띠: dev · stg · prd 마다 코드 판 · data_version · 규격 MAJOR · 유효 컴포넌트 판과 출처 등급.
  2. prd 와 견주기: stg 를 prd 로 올리면 바뀌는 칸. 지금은 1칸이 바뀌고 2칸은 확정하지 못했다.
  3. 그 스택으로 잰 최근 성능: 같은 스택 기록이 없으면 가장 가까운 측정과 다른 칸을 적는다.
  4. 타일: 운영 판 · tester 판정(직전 대비) · judge BAD.
  5. 최근 두 게이트: 운영 출시 판정 묶음과 스테이징 승격 검사 요청.

출처 등급 기록배포 기록설정값추정없음

화면 설명서 · 스테이징 승격 검사

내 요청은 한 행으로 쌓이고, 상세에서 카드별 차이와 바뀐 장을 본다

스테이징 승격 검사 목록. 아직 요청이 없어 빈 상태다. 위에 전체 · 코드 · 스냅샷 칩과 생략 건 보이기 상자가 있다.
  1. 전체 · 코드 · 스냅샷: 바뀐 것의 종류로 거른다.
  2. 생략 건 보이기: 바뀐 경로가 없어 생략한 요청을 펼친다.
  3. 지금은 요청 0건이라 빈 상태다.
  4. tester 탭: 고정 2,000 과 겨냥 묶음을 따로 보인다. judge 는 judge 탭.
  5. 카드마다 A(머지 직전 main) · B(머지 커밋) · 차이[95%] · 판정.
  6. 행을 누르면 바뀐 장 그림 쌍, 그 아래 「그 장의 YAML 몫」 접기.

화면 설명서 · 운영 출시 판정

배포 회차마다 tester 판정 카드 수와 judge BAD 를 같은 칸에 쌓는다 구축 중

운영 출시 판정 화면. 위 tester 판정 카드 수 막대, 아래 judge BAD 비율 선, 맨 아래 배포 묶음 표.
  1. 위 차트: 직전 기준선 대비 악화 · 못 가림 · 개선 카드 수. 높이 = 카드 수.
  2. 아래 차트: judge BAD 비율. 가로 점선 = 목표 5%.
  3. 세로 점선: 코드 + 스냅샷이 함께 바뀐 구간. 차이는 합산 효과다.
  4. ⚠: 판정자 · 잣대 · 판이 바뀐 점. 그 구간 기울기를 제품 변화로 읽지 않는다.
  5. 배포 묶음 표: 묶음마다 대상 · 전 → 후 · tester 판정 요약 · 보고서.
지금 두 묶음은 기준선이다. 기준선 2.7 · 2.6 모두 「정식 운영 출시 판정 회차 아님」 표지가 붙어 있다.

화면 설명서 · 묶음 상세 → 카드 상세

묶음에서 움직인 카드를 고르고, 카드 상세에서 결함이 어디서 나는지 본다

묶음 상세 · baseline-2.7-1102 · tester 탭

묶음 상세 baseline-2.7-1102 tester 탭. 직전 기준선 대비 칩, 카드 18장 결함 비율 막대, 카드 타일.

카드 상세 · D3

tester 카드 D3 상세. 결함 비율 1.0%, 관문 통과, 유형별 · 순위별 표.
  1. 직전 기준선 대비: 악화 1 · 못 가림 6 · 개선 1. 악화 P1 · 개선 E3.
  2. 한눈에 보기: 카드 18장의 결함 비율. 단계별로 나눈다.
  3. 카드 타일: 결함 비율 · 구간 · 관문. 누르면 카드 상세.
  4. 머리: 결함 비율 1.0% [1.0–1.1] · 관문 통과 · 책임 모듈.
  5. 유형별 · 순위별: 전체 대비 차가 큰 행부터. 아래에 사례 그림.
  6. 기준 회차에서 이 카드 열기: baseline-2.6-1027 의 같은 카드.

화면 설명서 · 환경 상세

환경 상세는 칸마다 값 · 등급 · 출처 · 기준 시각을 나란히 적는다

환경 상세 화면 위쪽. 출처 넷, stg 를 prd 로 올리면 바뀌는 칸, dev 환경의 칸별 표, 스냅샷 · 매핑.
  1. 출처: 검색 로그 · iui env-status.json · iui state.json · 데이터 버전 번들, 각각 읽은 기준 시각.
  2. stg 를 prd 로 올리면 바뀌는 칸: 코드 판만 다르다. data_version · 규격 MAJOR 는 설정값이라 확정 못 한다.
  3. 칸별 표: 코드 판 · data_version · 규격 MAJOR · 유효 컴포넌트 판의 값 · 등급 · 출처 · 언제 기준. 출처가 여럿이면 나란히 둔다.
  4. 스냅샷 · 매핑: 버킷 · live · 미리 올림 · next · 매핑.
  5. 묶음마다: 이 환경의 지금 스택과 같은지.
같은 스택은 코드 판과 data_version 이 둘 다 기록으로 같을 때만이다.

화면 설명서 · 분석 · 측정기

분석은 종류 지정이 BAD 를 바꾸는지, 측정기는 카드를 믿을 만한지 본다

분석 · 종류 회차 1013-e4-kinds

분석 화면. 종류 회차 1013-e4-kinds 와 추천 대조군 1016-c4-visual 을 골라 종류별 추천 BAD 와 지정 BAD 를 견준 표.

측정기 · tester 평가기

측정기 화면 tester 평가기 탭. 카드 50장 상태 요약과 카드별 일치도 · F1 · 결함률 · 비용 · 상태 표.
  1. 종류 회차를 고른다. 고르기 전에는 비어 있다.
  2. 추천 대조군: 같은 표본의 추천 회차.
  3. 종류별 결론: 추천 BAD 대 지정 BAD, 차 ±95%. 이 회차에서 지정 전체는 21.7% → 41.0%.
  4. 하위 탭: tester 평가기 · judge 표본 · judge 프롬프트.
  5. 카드 50장 상태: 경향 유지 28 · 질문 수정 18 · 규칙 대체 2 · 참고 1 · 은퇴 1.
  6. 카드마다 일치도 · F1 · 결함률 · 비용 · 상태.

부록 · 카드 이름표

tester 카드 18장은 생성부터 보이는 결과까지 다섯 단계를 나눠 맡는다

생성

G1
유형이 원문에 맞지 않음
G3
원문 항목이 YAML 에서 빠짐
G8
원문에 없는 내용을 지어냄

색인

B2
카테고리가 컴포넌트에 맞지 않음
P1
structure map 이 노드 역할에 맞지 않음
P2
경계 안 core 글이 어느 자리에도 묶이지 않음

검색

R4
온전하지 않은 컴포넌트를 제공
R6
더 온전한 후보가 아래 순위에 있음
R7
상위 10 안에 같은 모양 중복
R8
경계 밖 차트 · 표가 남는 후보를 피하지 못함

대치

D2
질의 글이 결과에 없음
D3
질의 글이 다른 자리에 들어감
D4
제목 자리가 있는데 문서 제목이 빠짐
D8
글이 상자를 벗어나거나 겹침

보이는 결과

E1
뜻이 보존되지 않음
E3
채워지지 않은 자리가 보임
E4
글이 다 읽히지 않음
E5
정보 구조와 순서가 흐려짐

부록 · 용어

정책은 여덟 낱말로 읽는다

용어뜻
반영 게이트구간 사이에서 품질을 확인하는 곳. develop → staging 은 스테이징 승격 검사, staging → production 은 운영 출시 판정이다.
스택 키회차마다 싣는 코드 판 · data_version · 규격 MAJOR · 유효 컴포넌트 판. 같은 스택인지는 코드 판과 data_version 으로만 판정한다.
환경 라벨회차를 잰 환경. dev · stg · prd · local.
고정 2,000늘 같은 원문 2,000개. 상위 10 전체를 잰다. 채택률 · 다운로드율이 상위 10 을 기준으로 재기 때문이다.
겨냥 묶음변경이 겨냥하는 범위(표/차트 · 데이터셋 · 긴 원문 등)에서 고른 원문. 고정 2,000 과 겹치는 원문은 뺀다. 설정이 다른 묶음끼리는 비교하거나 합치지 않는다.
합산 효과여러 변경이 쌓인 출시 묶음 전체의 차이. 변경별 몫은 스테이징 승격 검사 결과로 돌아가 본다.
못 가림카드별 차이의 95% 구간이 0 을 품는 경우. judge 는 ±1.3%p 안의 차이.
출처 등급환경 띠 값이 어디서 왔는지 나타내는 등급. 기록 · 배포 기록 · 설정값 · 추정 · 없음.

부록 · 비용 · 시간 (추정)

비용과 시간은 게이트와 대상에 따라 다르다

반영 게이트 · 대상tester 비용tester 시간judge 비용judge 시간
스테이징 승격 · 코드
요청 1건, 겨냥 기본 설정		약 $22–41약 4.5–6시간(요청 시) 약 $85약 0.5–2.5시간
스테이징 승격 · 스냅샷돌리지 않음—약 $85약 0.5–2.5시간
운영 출시 · 코드만 바뀐 배포약 $16–39
겨냥 묶음 하나 · 기본 설정		약 4.5–6시간약 $85–97약 1–2.5시간
운영 출시 · 스냅샷이 바뀐 배포돌리지 않음—약 $85–97약 1–2.5시간

부록 · 근거

정책 · 보고서 · 결정 기록은 아래 링크에 있다