■ lifecycle 루프

lifecycle : discovery · design · handoff · monitoring · iteration — 핸드오프 뒤 할 일6.5 본편

표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법

왜 배우나 — 시험이 요구하는 것

시험 목표 6.5 수명주기 지원 · D6 사람·문서 14%
Support lifecycle phases (discovery, design, handoff, monitoring, iteration)

이 개념으로 푸는 판단 (할 수 있어야 하는 것)

6.5① 핸드오프가 끝났다 — 아키텍트가 계속 할 일 두 가지는? (복수 응답) — 수명주기 5단계(디스커버리·설계·핸드오프·모니터링·반복)는 되돌아오는 루프 — 핸드오프 뒤 할 일
6.3② 월간 검토에서 법무팀이 놓친 조항 사례를 들고 왔다 — 이 피드백을 어디로 보내나? — 피드백 루프를 닫는 방법 (상태 보고 회의 vs 평가셋 편입)

한눈에

가이드 목표 6.5 는 5단계를 든다

discovery
설계
핸드오프
모니터링
반복

이것은 한 번 지나가는 줄이 아니다. 반복이 설계로(요구가 바뀌었으면 discovery 로) 되돌아가는 루프다. 루프 모양은 업계 일반이다. 공식 글은 "일찍 성공을 정하고, 분명히 재고, 계속 반복" 까지 말한다

핸드오프는 끝이 아니다. 그 뒤에 할 일이 두 가지 있다

모니터링 : 운영(production) 신호를 보고 사람이 정기 검토한다
반복 : 실패를 eval 과제로 넣어 다음 결정의 증거로 쓴다

비유 운영 이관 뒤에도 재발 장애는 regression(회귀) 테스트로 만든다. 작은 장애마다 아키텍처를 다시 그리지 않는다. "이관하면 끝"이 속이는 습관이다

discovery·설계·핸드오프·모니터링·반복 5단계는 한 줄이 아니라 반복이 설계로, 요구가 바뀌면 discovery 로 되돌아가는 루프이다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

정원 가꾸기와 같아요. 씨앗을 심고 끝이 아니에요.

무엇을 심을지 정하고(디스커버리), 어디에 심을지 그려요(설계).
심고 나서 관리할 사람에게 넘겨요(핸드오프).
그 뒤에도 잎을 살피고(모니터링), 병든 가지는 고쳐요(반복).
잎 하나 시들었다고 정원을 갈아엎지 않아요. 같은 병이 계속 돌면 그때 흙을 바꿔요.

개념 설명

영상 — 설계 바꾸기 전에 실패를 과제로 (약 43초 · 소리 없음 · 자막). 주 번호 · ② 기존 과제 통과 · ③ 같은 변경이 배송비 과제에서 걸림 · ④ 다시 짓는 2주는 그림용 가정 · 실측 아님 — 배송비 누락 · 이번 주 14건 · 과제 +14 · 프롬프트 v2 14/14 · 날짜 표기 오타 1건은 카드 흐름 값, '설계 변경 전 과제 먼저' 순서는 업계 일반 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

5단계와 루프

가이드 목표 6.5 는 단계 이름 5개를 준다.
- discovery
- 설계
- 핸드오프
- 모니터링
- 반복
공식 글의 요지는 일찍 성공을 정하고, 분명히 재고, 계속 반복하라는 것이다. eval 은 lifecycle(수명주기) 어느 단계에서도 쓸모가 있다.
반복이 설계(또는 discovery)로 되돌아가는 모양은 업계 일반이다. 공식은 "실패가 테스트 과제가 되고, 테스트 과제가 regression(회귀)을 막는다" 까지만 말한다.

핸드오프가 끝이 아닌 이유

운영(production) 모니터링은 출시 뒤에야 분포 변화와 예상 못 한 실패를 잡는다. 단 사후 대응이라 사용자가 먼저 겪는다.
반복이 빠지면 하나 고치면 다른 게 깨지는 사후 대응 루프에 갇힌다 (공식 "reactive loops").
eval 셋은 살아 있는 산출물이다. 담당자가 없으면 낡는다. 전담 팀이 인프라를 맡고, 도메인 전문가·제품팀이 과제를 기여한다.
모델 lifecycle : 모델 ID 마다 지원 중단·종료 일정이 있다. 교체는 반복 단계의 일이다. eval 이 있으면 며칠이 걸린다.

되돌아가는 폭 (업계 일반)

사소한 결함 한 건이면 반복 안에서 고치고 regression eval 을 한다.
같은 실패가 반복되면 설계를 바꾸기 전에 그 사례를 eval 에 넣어 커버리지부터 챙긴다. 그다음 변경을 그 사례로 검증한다.
증거가 요구 변화를 보여 주면 discovery 로 간다.

핵심 질문 두 개

핸드오프 뒤 모니터링과 반복을 누가, 무엇으로 계속하나?
들어온 문제가 어느 단계까지 되돌아갈 크기인가?

규칙과 판단

들어온 실패의 크기에 맞게 되돌아간다. 사소한 결함은 반복 안에서, 같은 실패 반복은 설계 변경 전에 eval 에 추가, 요구가 바뀌면 discovery 로 간다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

①② 핸드오프 뒤 [6.5①]

아키텍트 몫은 어떻게 되나?핸드오프 뒤에도

끝난다, 운영팀 몫

끝이 아니다

핸드오프는 끝이 아니다

계속된다

모니터링 + 반복

운영 신호를 보고 사람이 정기 검토한다. 실패를 eval 과제로 넣어 다음 결정의 증거로 쓴다

③ 어디로 되돌아가나 [6.5①] [6.3②]

무엇이 들어왔나?

사소한 결함 한 건

반복 안에서 고친다

고치고 regression eval 을 한다 업계 일반

같은 실패가 반복

eval 에 먼저 넣는다

설계 변경 승인 전에 그 사례를 eval 에 추가한다. 다음 변경을 그 사례로 검증한 뒤 배포한다 (순서는 업계 일반). 실패는 테스트 과제가 된다

요구 자체가 바뀌었다

discovery 로 간다

증거가 요구 변화를 보여 줄 때만 간다 업계 일반. 자세한 것은 ■ discovery 에 있다

지표가 서서히 떨어진다

트레이스·쪼개기부터 한다

재설계 전에 실패 세션 트레이스를 본다. eval 결과를 주제별로 쪼개 어디서 떨어졌는지부터 찾는다 (쪼개기는 업계 일반)

문서 갱신 뒤 확신에 찬 오답

검색·indexing 부터 본다

모델·지연(latency)이 그대로면 검색(retrieval)·indexing(색인)부터 본다. 자세한 것은 ■ 변경부터 묻는 진단 에 있다

④⑤ 계속 맡을 것 [6.5①]

무엇이 남나?

eval 셋

담당자를 정한다

eval 셋은 살아 있는 산출물이라 명확한 소유권이 필요하다. 인프라는 전담 팀이, 과제는 도메인 전문가·제품팀이 맡는다

모델 버전

종료 일정을 보고 eval 로 교체한다

모델 ID 마다 지원 중단·종료 일정이 있다. eval 이 있으면 교체에 며칠이 걸린다

흐름

그림 속 이름·금액·시간·토큰 수는 예시예요. 공식 한도·동작은 카드 본문 값이 기준.

장면 글로 보기

칸 : discovery → 설계 → 핸드오프 → 모니터링 → 반복

질문 : 들어온 실패는 어디로 가야 할까?

① 실패가 되돌아온다 ✓

시작 : discovery — 쪽지 : 필요: 반품 문의 자동 응대 / 범위: 환불액 · 배송비
넘김 : 설계 → 핸드오프 : 결정 기록·구현 가이드·eval 담당자를 넘긴다 — 쪽지 : ADR 3장 · 구현 가이드 / eval 셋 담당: 지원팀
포착 : 모니터링 : 분포 변화와 예상 못 한 실패를 잡는다 — 쪽지 : 로그: 배송비 누락 / 이번 주 14건
과제로 : 모니터링 → 반복 : 실패를 테스트 과제로 만든다 — 쪽지 : eval 과제 +14 / "반품 1장 = 배송비 차감"
되돌림 : 반복 → 설계 : 다음 변경을 그 사례로 검증한다 — 쪽지 : 프롬프트 v2 / 새 과제 14/14 통과
끝 : 실패가 테스트 과제가 되고, 테스트 과제가 regression 을 막는다

② 핸드오프로 끝 ≠

시작 : discovery — 쪽지 : 필요: 반품 문의 자동 응대 / 범위: 환불액 · 배송비
넘김 : 설계 → 핸드오프 : 아키텍트 역할이 끝난다 ≠ — 말 : “이제 운영팀 몫이에요.”
포착 : 모니터링 : 문제가 사용자에게 먼저 닿는다 — 쪽지 : 고객 불만: "배송비 빠졌어요" / 이번 주 14건
건너뜀 : 반복
끝 : 하나 고치면 다른 것이 깨지는 사후 대응이 된다

③ 작은 결함마다 discovery ≠

시작 : discovery — 쪽지 : 필요: 반품 문의 자동 응대 / 범위: 환불액 · 배송비
포착 : 모니터링 : 사소한 결함 한 건을 잡는다 — 쪽지 : 로그: 날짜 표기 오타 / 1건
건너뜀 : 반복
되돌림 : 모니터링 → discovery : 처음부터 다시 한다 ≠ — 쪽지 : 이해관계자 인터뷰부터 / 다시 시작
끝 : 사소한 결함 한 건은 반복 안에서 고치고 regression eval 을 한다

나머지 규칙

시험 요령 : 이 목표(6.5)는 복수 응답 문항이 나오기 쉽다. 문항마다 고를 개수를 적어 준다 (가이드 5절)

규칙 원문 ①②③④⑤ (갈림길로 그린 규칙)

5단계와 본편 : 단계마다 할 일과 본편 카드는 아래 표와 같다 [6.5①]

단계	할 일	본편
discovery	진짜 필요 · 범위 · 데이터 사실을 모은다	■ discovery · ■ 문제 정의
설계	성공 기준(success criteria)을 먼저 정하고, 그 기준을 재는 eval 을 설계한다. 만들 기능의 eval 을 먼저 만든다(eval-driven)	■ 성공 기준 · ■ 변경마다 eval 다시
핸드오프	결정 기록 · 구현 가이드와 eval 셋 담당자를 넘긴다	■ ADR·아키텍처 패키지 · ■ 구현 가이드
모니터링	출시 뒤 분포 변화와 예상 못 한 실패를 잡는다	■ 검증 층 · ■ observability 세 신호
반복	실패를 테스트 과제로 만들어 다음 변경을 검증한다	■ 운영 → eval feedback loop

가이드는 인증 보유자가 Claude 시스템의 전체 lifecycle(수명주기)을 맡거나 크게 기여한다고 적는다. 권장 경험은 discovery 부터 배포·운영화까지다

eval 은 lifecycle 어느 단계에서도 쓸모가 있다. 초기에는 성공이 무엇인지 정하게 한다. 뒤에는 품질 기준을 지킨다

핸드오프 뒤 할 일 두 가지 : 모니터링과 반복이다 [6.5①]

모니터링은 운영 모니터링(출시 뒤 분포 변화 · 예상 못 한 실패)과 사람 정기 검토(보정)다

운영 모니터링은 사후 대응이다. 문제가 사용자에게 먼저 닿는다. 자세한 것은 ■ 검증 층 에 있다

반복에서는 실패가 테스트 과제가 된다. 테스트 과제가 regression 을 막는다. 지표가 짐작을 대신한다

반복이 빠지면 하나 고치면 다른 것이 깨지는 사후 대응이 된다

이미 운영 중이면 버그 트래커·지원 큐의 실제 실패부터 과제로 만든다. 자세한 것은 ■ 운영 → eval feedback loop 에 있다

"이해관계자 품질 검토"라는 이름은 목록 표현이다. 공식 글은 도메인 전문가·제품팀이 과제를 기여하고, 사람 정기 검토로 보정한다고 적는다

결함 크기에 맞게 되돌아간다 업계 일반 공식은 "실패 → 테스트 과제" 까지 [6.5①] [6.3②]

들어온 것	되돌아갈 곳
사소한 결함 한 건	반복 안에서 고치고 regression eval 을 한다
같은 실패가 반복	설계 변경 승인 전에 그 사례를 eval 에 추가한다. 다음 변경을 그 사례로 검증한 뒤 배포한다
증거가 요구 변화를 보여 준다	discovery 로 간다
지표가 서서히 떨어진다 (모델·프롬프트는 그대로이고, 새 기능·사용 변화는 있다)	재설계 전에 실패 세션 트레이스를 보고, eval 결과를 주제별로 쪼개 어디서 떨어졌는지부터 찾는다. 전체 점수 하나로는 어디가 떨어졌는지 못 짚는다 업계 일반. 운영 트레이스로 에이전트가 왜 실패했는지 진단한다. transcript 를 읽어야 eval 이 중요한 것을 재는지 확인할 수 있다
문서 갱신 뒤 확신에 찬 오답이 나온다. 모델·지연은 그대로다	검색(retrieval)·indexing(색인)부터 본다. 자세한 것은 ■ 변경부터 묻는 진단 에 있다

eval 과제를 정의해 보는 것은 요구가 구현을 시작할 만큼 구체적인지 시험하는 좋은 방법이다

그래서 과제로 못 적으면 discovery 쪽 신호다 (연결은 업계 일반)

eval 셋은 핸드오프 뒤에도 담당자가 있어야 : eval 셋은 살아 있는 산출물이다. 계속 손보고 명확한 소유권이 있어야 쓸모가 있다 [6.5①]

가장 잘 된 방식에서는 전담 eval 팀이 핵심 인프라를 맡는다. 도메인 전문가·제품팀이 과제 대부분을 기여하고 직접 돌린다. PM · 고객 성공 매니저 · 영업도 Claude Code 로 과제를 PR 로 기여한다

100% 통과한 capability(능력) eval 은 regression 스위트로 옮긴다. 100% eval 은 regression 만 잡고 개선 신호가 없다(포화). 자세한 것은 ◆ capability eval vs regression eval 에 있다
모델 lifecycle : 모델 ID 는 고정 스냅숏이다. 새 버전은 새 ID 다. 모델 ID 마다 지원 중단·종료 일정이 따로 있다 [6.5①]

교체는 반복 단계의 일이다. eval 이 있으면 며칠, 없으면 몇 주가 걸린다. effort 설정도 이전 모델에서 가져오지 말고 자체 eval 에서 새로 스윕한다. 자세한 것은 ■ 변경마다 eval 다시 에 있다

더 깊이 : 판단 규칙 · 상황 변수 (설명)

판단 규칙

조건	답	등급	근거
핸드오프 뒤 할 일을 묻는다 (복수 응답)	운영 모니터링을 한다. 실패를 eval 과제로 넣어 다음 결정의 증거로 쓴다		demystifying-evals · 가이드 목표 6.5
이미 운영 중인 시스템의 첫 eval 과제를 만든다	버그 트래커 · 지원 큐의 실제 실패에서 뽑는다		demystifying-evals
첫 eval 셋 크기를 정한다	실제 실패에서 뽑은 20~50개로 시작한다		demystifying-evals
핸드오프 때 eval 셋을 넘긴다	담당자를 정한다. 도메인 전문가·제품팀이 과제를 기여한다		demystifying-evals
capability(능력) eval 이 100% 에 닿았다	regression 스위트로 옮긴다. 새 capability eval 이 필요하다(포화)		demystifying-evals
모델이 종료되거나 새 모델이 나왔다	eval 로 교체를 판단한다. effort 를 새로 스윕한다		model-ids-and-versions · demystifying-evals · effort
같은 실패가 반복된다	설계 변경 승인 전에 eval 에 먼저 넣는다. 그 사례로 다음 변경을 검증한다	업계 일반(순서) · 확인(실패 → 과제)	demystifying-evals
사소한 결함 한 건이다	discovery 를 다시 시작하지 않는다. 반복 안에서 고친다	업계 일반	—
요구 자체가 바뀐 증거가 있다	discovery 로 간다	업계 일반	eval 과제로 요구의 구체성을 시험하는 원칙과 이어진다
문서 갱신 뒤 확신에 찬 오답이 나온다. 모델·지연(latency)은 그대로다	검색(retrieval)·indexing(색인)부터 본다		가이드 샘플 3 정답 B · ■ 변경부터 묻는 진단

상황 변수

변수	값	답 쪽	등급	근거
들어온 문제	1회성이고 작다	반복 안에서 고친다	업계 일반	판단 규칙 8
들어온 문제	같은 유형이 반복된다	eval 에 먼저 넣고 설계를 바꾼다	업계 일반(순서)	판단 규칙 7
들어온 문제	요구 변화 증거가 있다	discovery 로 간다	업계 일반	판단 규칙 9
핸드오프 뒤 담당	eval 담당자와 기여 경로가 있다	루프가 돌아간다
핸드오프 뒤 담당	담당자가 없다	eval 이 낡는다. 그래서 거짓 확신이 생긴다		"ongoing maintenance … to avoid drift"
eval 통과율	100% 다	regression 만 잡아낸다. 개선 신호가 없다
모델	종료 일정이 공지됐다	반복 단계가 열린다. eval 이 있으면 며칠이 걸린다		model-ids
문항 형식	복수 응답이다	문항이 고를 개수를 말해 준다		가이드 5절

연습 문제

출시 석 달 뒤, 고객지원 Agent 가 같은 "반품 배송비 누락" 을 매주 되풀이같은 실패 반복한다. 팀장은 "바로 설계를 바꾸고 더 큰 모델로 올리자"고 한다. 설계 변경 승인 전에 먼저 무엇을 해야 하나?

시험 대비

함정

"핸드오프로 아키텍트 역할은 끝, 이제 운영팀 몫" 은 함정이다. 핸드오프 뒤에도 모니터링과 반복을 한다
"사소한 버그마다 discovery 를 처음부터 다시" 는 함정이다. 결함 크기에 맞게 되돌아간다 업계 일반
"같은 누락이 반복되니 바로 설계 변경 · 더 큰 모델" 은 함정이다. 그 사례를 eval 에 먼저 넣어 커버리지부터 챙긴다 (순서는 업계 일반). 실패는 테스트 과제가 된다
"지표가 떨어지니 새 구조(멀티 에이전트 등)로 다시 짓자" 와 "eval 다시 돌려 전체 점수만 비교" 는 함정이다. 트레이스를 보고 주제별로 쪼개 어디서 떨어졌는지부터 찾는다 (쪼개기는 업계 일반)
"eval 은 출시 전에 한 번 만들면 끝" 은 함정이다. eval 은 살아 있는 산출물이고 명확한 소유권이 필요하다
"eval 이 100% 라 더 할 게 없다" 는 함정이다. 그것은 포화다. regression 만 잡고 개선 신호가 없다
"모델이 드리프트해서 품질이 떨어졌다" 는 함정이다. 고정 ID 는 가중치·구성을 안 바꾼다. 자세한 것은 ■ 변경부터 묻는 진단 에 있다
"대시보드가 멀쩡하니 모니터링 끝" 은 함정이다. 운영 모니터링은 사후 대응이다. 자세한 것은 ■ 검증 층 에 있다
복수 응답 문항에서 하나만 고르는 것은 함정이다. 문항이 고를 개수를 말해 준다

신호

"Support lifecycle phases (discovery, design, handoff, monitoring, iteration)" (가이드 목표 6.5)

"Writing evals is useful at any stage in the agent lifecycle."

"define success early, measure it clearly, and iterate continuously."

"development accelerates as failures become test cases, test cases prevent regressions, and metrics replace guesswork."

"Production monitoring kicks in post-launch to detect distribution drift and unanticipated real-world failures."

"An eval suite is a living artifact that needs ongoing attention and clear ownership to remain useful."

"Defining eval tasks is one of the best ways to stress-test whether the product requirements are concrete enough to start building."

"Adding full production tracing let us diagnose why agents failed and fix issues systematically."

"Reading transcripts is how you verify that your eval is measuring what actually matters"

"Every model ID, whether dated or dateless, has its own distinct deprecation and retirement schedule."

"Multiple-choice and multiple-response items; each item states how many responses to select" (가이드 5절)

보통은 실패를 eval 과제로 넣어 반복하지만, 원인이 요구 변화면 discovery 로, 피해가 진행 중이면 먼저 막고, eval 이 100% 면 regression 으로 돌리고 새 셋을 만든다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요

더 깊이 : 뒤집히는 때 · 오답 재료 (설명)

뒤집히는 때

1. 작은 결함인데 discovery 로 가야 할 때

조건 : 서식 오류 한 건이 들어왔다. 그런데 원인이 "법무팀이 새 규정을 도입해 출력 양식 자체가 바뀜" 이다.
판단 : 결함의 크기가 아니라 원인이 요구 변화면 discovery 로 간다. "작으면 반복 안에서" 는 원인이 기존 요구 안에 있을 때만 맞다.
등급 : 업계 일반
근거 : 공식 문장은 없다. eval 과제를 정의하는 것이 요구의 구체성을 시험한다(demystifying-evals)는 원칙과 같은 방향이다.

2. 반복 실패인데 eval 추가보다 먼저 막아야 할 때

조건 : 하루 1,200건 중 30건(2.5%)에서 환불 금액을 잘못 안내한다. 고객 금전 피해가 진행 중이다.
판단 : 피해가 진행 중이면 먼저 사람 검토 경로를 넓히거나 기능을 좁혀 막는다. 그다음 그 사례를 eval 에 넣어 설계 변경을 검증한다. "eval 먼저" 는 피해를 방치하라는 뜻이 아니다.
등급 : 업계 일반 (사람 검토 경로 = ■ human-in-the-loop 게이트 위치 · ◆ 100% 약속 vs 측정된 SLO + 사람 안전망)
근거 : 공식 순서 문장은 없다.

3. 아키텍트 개인이 빠져도 되는 때

조건 : 핸드오프 때 eval 셋 담당 팀이 정해지고, 도메인 전문가가 과제를 PR 로 기여하는 경로가 있다.
판단 : 틀린 보기 "핸드오프로 아키텍트 역할은 끝" 이 틀린 이유는 모니터링·반복이 멈추기 때문이다. 그 사람이 꼭 남아야 해서가 아니다. 소유권이 넘어가 루프가 돌면 개인은 빠져도 된다.
등급 : (소유권·기여 구조) · 업계 일반(개인 역할 해석)
근거 : demystifying-evals

4. eval 이 100% 인데 할 일이 남을 때

조건 : capability eval 40문항이 석 달째 40/40 이다.
판단 : 포화다. regression 만 잡고 개선 신호가 없다. 이 셋은 regression 스위트로 옮긴다. 운영에서 들어온 새 실패로 capability eval 을 새로 만든다.
근거 : demystifying-evals

5. 모델 종료 공지가 반복을 강제로 여는 때

조건 : 쓰던 모델 ID 에 종료 일정이 공지됐다.
판단 : 모델 ID 는 고정 스냅숏이라 스스로 안 바뀐다. 그러나 종료 일정은 ID 마다 있다. 그래서 교체는 반복 단계의 일이다. eval 이 있으면 며칠, 없으면 몇 주가 걸린다. effort 설정은 가져오지 말고 새로 스윕한다.
근거 : model-ids-and-versions · demystifying-evals · effort

오답 재료

오답	왜 끌리나	왜 틀리나	등급	근거
"핸드오프로 아키텍트 역할은 끝, 이제 운영팀 몫"	인수인계를 책임 이전으로 본다	모니터링·반복이 멈추면 사후 대응 루프가 된다		demystifying-evals
"사소한 버그마다 discovery 를 처음부터 다시"	꼼꼼해 보인다	결함 크기·원인에 맞게 되돌아간다. 이것은 과한 재설계다	업계 일반	목록 6.5① (영상 Part 23 Q4 오답)
"같은 누락이 반복되니 바로 더 큰 모델로"	모델이 약해 보인다	먼저 사례를 eval 에 넣어 커버리지부터 챙긴다. 모델 교체도 eval 로 판단한다	업계 일반(순서) · 확인(교체는 eval 로)	demystifying-evals
"주간 상태 보고 회의에서 공유하고 주의를 당부"	소통을 했으니 루프를 닫은 것 같다	실패가 테스트 과제가 되지 않는다. 그래서 regression 을 못 막는다		demystifying-evals (본문 = ■ 운영 → eval feedback loop)
"eval 은 출시 전에 한 번 만들면 끝"	테스트는 출시 관문 같다	살아 있는 산출물이다. 계속 손봐야 한다		demystifying-evals
"eval 100% 니 개선할 게 없다"	만점이다	포화다. 개선 신호가 없다		demystifying-evals
"모델이 드리프트해서 품질이 떨어졌다"	흔한 말이다	고정 ID 는 가중치·구성을 안 바꾼다. 공식의 드리프트는 입력 분포 변화다		model-ids-and-versions · demystifying-evals
복수 응답 문항에서 하나만 고름	습관이다	문항이 고를 개수를 말해 준다		가이드 5절

참고

함께 보기

더 깊이 : 출처 · 상태 · 미해결 (참고)

출처

가이드 목표 6.5 공식 시험 가이드 v1.0
2절 ("full lifecycle")
4절 (권장 경험)
5절 (문항 형식)
demystifying-evals
multi-agent-research-system
model-ids-and-versions
effort
define-success

상태

업계 일반 5곳(루프 모양 · ③ 되돌아갈 곳 표 · 설계 변경 전 eval 순서 · 주제별 쪼개기 · 과제로 못 적으면 디스커버리)

미해결

5단계를 루프로 잇는 공식 문장은 없다. 가이드는 단계 이름만 준다. demystifying-evals 는 "define success early, measure it clearly, and iterate continuously"까지 말한다. 카드의 루프 모양은 업계 일반이다.
"설계 변경 승인 전에 eval 에 먼저" 의 순서와 "사소한 결함은 discovery 재시작 X" 는 공식 문장이 없다(업계 일반, 목록 6.5① 규칙).
목록의 "이해관계자 품질 검토" 는 공식 표현이 아니다. 공식은 "periodic human review for calibration"과 도메인 전문가·제품팀의 과제 기여를 말한다. 그래서 카드는 "사람 정기 검토" 로 고쳐 썼다.
핸드오프 산출물(결정 기록 · 구현 가이드)의 세부는 6.4 쪽 몫이다. 이 카드는 가리키기만 한다.
목록 영어 신호 3개는 모두 원문에서 찾았다 (가이드 목표 6.5 · demystifying-evals · 가이드 5절).