■ discovery 산출물

discovery outputs : 기준선 · 결정권자 · 요구 4범주 · 가정 목록 — "끝났다" 의 판정6.1 본편

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

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

시험 목표 6.1 요구 수집 · D6 사람·문서 14%
Conduct structured discovery and requirement gathering

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

6.1① "완벽한 계약 검토기를 만들어 달라" — 아키텍트의 첫 행동은? — 해법(모델·프롬프트·에이전트)보다 디스커버리 먼저
6.1② 성공 기준을 어떻게 적나 — SMART 로? 숫자 하나로? — 성공 기준의 요건 (Anthropic 4가지 + 여러 차원)
6.1③ 민감 데이터라며 BAA·GDPR·ZDR 을 한꺼번에 걸자고 한다 — 디스커버리에서 무엇을 사실로 확인하나? — 규정 약정을 데이터 사실(PHI 유무·거주지·보존)에서 끌어내기

한눈에

discovery 가 "끝났다" 는 회의 횟수가 아니라 산출물로 판단한다. 산출물은 아래 넷이다 업계 일반 산출물 목록은 공식 문서에 없음

지금 일의 기준선(baseline)
그 기준선에 견주어 목표를 고른 결정권자(decision owner) 한 명
네 범주로 채운 요구
확인 안 된 말을 모은 가정 목록

공식에서 가장 가까운 원칙은 둘이다. 목표는 기준선 대비로 적는다("지금 기준선보다 5% 개선"). eval 은 초기에 제품팀이 성공이 무엇인지 적게 만든다

묻는 법은 ■ discovery 에 있다. 기준 문장 쓰는 법은 ■ 성공 기준 에 있다

비유 이관 착수 체크리스트와 같다. 현재 처리량·지연(latency) 실측값, 승인권자 1명, 금지 사항, 비용 상한, 감사 증거를 적는다. 한 칸이라도 비면 착수 회의를 다시 잡는다. "워크숍 했으니 요구 수집 끝" 이 속이는 습관이다

discovery 가 끝났는지는 기준선, 결정권자 한 명, 요구 4범주, 가정 목록 네 산출물이 모두 있는지로 가린다는 체크리스트 — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

집을 고치기 전에 "다 물어봤다" 를 체크리스트로 확인하는 거예요.

지금 집을 줄자로 재 둬야, 나중에 얼마나 넓어졌는지 말할 수 있어요.
"넓게 해 주세요" 의 크기를 정하는 사람은 한 명이어야 해요.
"이 벽은 절대 헐지 마세요" 는 먼저 묻지 않으면 아무도 말 안 해요.
"수도관은 아마 여기 있을 거예요" 는 확인할 때까지 메모지에 따로 적어요.

개념 설명

영상 — discovery 끝은 무엇으로 가르나 (약 43초 · 소리 없음 · 자막). 14분·60시간·30% 단축 = 설명 '뒤집히는 때 1' 예시값 · 두 정의를 누가 읽나 · '본부장 1명' · 칸 값 모양은 그림용 가정 · ④ 새 업무 기준선 = '뒤집히는 때 4'(추론 등급) · 10시간 = 22시~8시 계산 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

"끝났다" 는 시간이 아니라 산출물로 정한다

워크숍·회의 횟수는 discovery 가 끝났다는 증거가 아니다. 설계가 기댈 아래 네 가지가 채워졌는지로 판정한다 (업계 일반).
- 기준선
- 결정권자
- 요구 4범주
- 가정 목록
묻는 법 자체(인터뷰 · eval 과제로 구체성 검사)는 ■ discovery 에 있다. 이 쪽은 "무엇이 손에 남아야 끝인가" 를 다룬다.

기준선이 없으면 목표가 뜻이 없다

"30% 단축" 은 무엇 대비인지가 있어야 약속이 된다. 공식 성공 기준 예도 "지금 기준선보다 5% 개선" 이다.
eval 이 생기면 AI 쪽 기준선(지연 · 토큰 · 과제당 비용 · 오류율)은 따라온다. 하지만 지금 사람이 하는 일의 기준선은 따로 재야 전·후 비교가 된다.

목표를 고르는 사람은 한 명이다

목표에는 가치 판단이 들어간다(얼마나 빨라야 투자할 만한가). 그래서 사업 쪽 담당자 몫이다. 승인자가 둘이면 두 목표로 설계가 갈린다 (업계 일반).
아키텍트 몫은 두 가지다. 그 목표를 이룰 수 있는지 가늠하는 것과 재는 법이다. 가늠할 때는 공식 "달성 가능" 기준대로 업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에 기댄다.

"하면 안 됨" 은 묻지 않으면 안 나온다

사람은 원하는 것을 말한다. 금지 사항은 당연하다고 여겨 빠뜨린다 (업계 일반). 공식 고객지원 가이드도 프롬프트에 dos and don'ts 와 권한 없는 약속 금지를 따로 적으라고 한다.
금지 칸이 사람 승인 게이트 위치를 정한다. 그래서 이 칸이 비면 게이트를 못 놓는다.

들은 말은 가정이다

"아마" 가 붙은 말을 요구로 적으면, 틀렸을 때 그 위에 선 설계 전체를 다시 짠다. 가정으로 적고 담당자와 확인 기준을 달면, 틀려도 한 줄만 고친다 (업계 일반).

규칙과 판단

기준선이 없으면 먼저 재고, 목표를 결정권자 한 명이 골랐는지, 요구 네 칸이 찼는지 차례로 묻고, 다 차면 검사 가능한 문장으로 바꾸는 결정 나무 — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

①② 끝났나 [6.1①]

지금 일의 기준선이 있나?같은 잣대로 잰 값

없다

먼저 잰다

지금 일을 같은 잣대로 측정한다. 운영 데이터와 실제 사용자·데이터 소유자 인터뷰를 쓴다 업계 일반. 목표는 기준선 대비로 적는다

있다

목표를 누가 골랐나?

아키텍트 · 벤치마크 숫자 · 빈칸

아직

이름이 정해진 결정권자 한 명이 기준선에 견주어 고른다 업계 일반. 아키텍트 몫은 이룰 수 있는 목표인지 가늠하는 것이다. 업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에 기댄다. 벤치마크는 달성 가능한지 가늠하는 재료이고, 목표를 고르는 것은 담당자다 (해석)

결정권자 한 명

↓ 아래 「요구 4범주」 갈림길로 이어짐

다음 물음 — 네 칸이 다 찼나?

③ 요구 4범주 [6.1①] [6.1②]

네 칸이 다 찼나?해야 함 · 하면 안 됨 · 비용 · 증명

"해야 함" 이 비어 있다

과제로 쪼갠다

맡길 과제 목록을 만든다. 이상적인 대화를 과제로 쪼갠다. 자세한 것은 ■ 문제 정의 · 규칙 ② 에 있다

"하면 안 됨" 이 비어 있다

따로 묻는다

이해관계자가 스스로 말하지 않는다 업계 일반. 가드레일(dos and don'ts)을 둔다. 권한 없는 약속은 하지 않는다. 위험이 큰 결정 전에는 사람이 통제한다

"비용" 이 비어 있다

따로 묻는다

월 문의량 예측, 건당 상한, 지연 목표를 묻는다 업계 일반. 허용 지연은 사용자 기대에 달려 있다

"증명" 이 비어 있다

합격 숫자·증거

감사·규정 증거를 정한다 업계 일반. 합격 숫자의 예는 에스컬레이션 정확도 95% 이상이다

다 찼다

검사 가능한 문장인가?

형용사뿐 ("더 빠르게")

검사 가능하게

"지금 무엇이 그렇지 못한가" 를 묻고 측정 가능한 행동 하나로 바꾼다 업계 일반. "좋은 성능" 대신 "정확한 감정 분류" 처럼 쓴다

예

↓ 아래 「들은 말·새 요청」 갈림길로 이어짐

다음 물음 — 무엇이 들어왔나?

④⑤ 들은 말·새 요청 [6.1③] [6.5]

무엇이 들어왔나?

확인 안 된 말 ("아마 ~")

무엇에 관한 말인가?

데이터 위치·권한·보존

가정 목록 + 담당자에게 직접

확인 전에는 가정이다. 데이터 소유자·법무에게 직접 묻는다. 이것은 모델 후보 고르기·기술 스파이크보다 앞이다 업계 일반. 확인된 사실과 약정의 짝은 ■ discovery · 규칙 ⑤ 에 있다

그 밖

가정 목록에

진술, 걸리는 제약, 따라오는 결정, 담당자와 확인 기준을 한 줄에 적는다 업계 일반

산출물이 다 찬 뒤 새 요청

다시 열지 않는다

범위 판단은 결정권자에게 맡긴다. 일은 프로토타입·ADR 로 한다 업계 일반

흐름

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

장면 글로 보기

칸 : 본부장 → 아키텍트 → 가정 목록 → 설계

규칙 (가정 목록) : 확인 전에는 가정이다. 담당자와 확인 기준을 단다

질문 : 들은 말을 바로 요구로 적어도 될까?

① 가정으로 등록 ✓

시작 : 본부장 — 말 : “반품 사진은 아마 국내 서버에만 있을 거예요.”
받음 : 본부장 → 아키텍트 : 확인 전에는 가정이다 — 쪽지 : "아마" / = 확인 안 됨
등록 : 아키텍트 → 가정 목록 : 진술, 제약, 담당자를 적는다 — 쪽지 : A-3 국내만? / 제약: 국외 불가 / 담당: 주문DB팀
확인 : 가정 목록 → 설계 : 데이터 소유자에게 직접 묻는다 — 쪽지 : A-3 풀림 / 해외 백업 / 있음
끝 : 확인된 사실만 설계의 제약으로 쓴다

② 들은 말을 요구로 ≠

시작 : 본부장 — 말 : “반품 사진은 아마 국내 서버에만 있을 거예요.”
받음 : 본부장 → 아키텍트 : 들은 말을 요구로 적는다 — 쪽지 : 요구 7 / 사진 국내만
건너뜀 : 가정 목록
설계 : 아키텍트 → 설계 : 확인 안 한 전제로 설계한다 — 쪽지 : 국내 전용 / 저장 설계
틀림 : 설계 : 나중에 드러난다 ≠ — 쪽지 : 해외 백업 / 발견 → / 설계 다시
끝 : 확인 안 된 말이 요구가 됐다. 담당자 확인이 빠졌다

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

기준선(baseline) : 지금 일을 같은 잣대로 측정한다. 예는 "반품 문의 1건, 접수부터 환불 승인까지 걸린 분" 이다. 운영 데이터와 실제 사용자·데이터 소유자 인터뷰를 쓴다 업계 일반 [6.1①]

공식 : 목표는 기준선 대비로 적는다. "지금 기준선보다 5% 개선" 이 달성 가능한 목표의 예다. A/B 는 기준 모델이나 이전 버전과 비교한다

만들기 전에 잰다 : 스킬도 스킬 없이 대표 과제로 돌려 빈 곳을 적고 기준선부터 측정한다 (Skills 문맥이다. discovery 로 넓힌 것은 해석이다)

eval 이 생기면 지연·토큰·과제당 비용·오류율 기준선은 따라온다. 단 그것은 AI 쪽 기준선이다. 지금 사람이 하는 일의 기준선은 따로 측정한다 업계 일반

스폰서 워크숍 하나로 "완료" 를 표시하면 미완이다. 현장 상담원이 실제로 하는 일을 빗나간다 업계 일반
②
결정권자 한 명 : 이름이 정해진 결정권자 한 명이 기준선에 견주어 측정 가능한 목표를 고른다. 승인자가 둘이면 한 명으로 정리한다 업계 일반 [6.1①] [6.3]

아래 상태로는 설계에 들어가지 않는다
- 아키텍트가 대신 정한다
- 벤치마크 숫자로 채운다
- 빈칸으로 둔다
아키텍트 몫은 이룰 수 있는 목표인지 가늠하는 것이다. 업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에 기댄다. 현재 프런티어 모델 역량에 비해 비현실적이면 안 된다

벤치마크는 달성 가능한지 가늠하는 재료이고, 목표를 고르는 것은 담당자다 (해석)

목표 문장 모양(구체적·측정 가능·달성 가능·관련 · 여러 차원)은 ■ 성공 기준 에 있다

요구 4범주 : 해야 함(must-do) · 하면 안 됨(must-not-do) · 비용(must-cost) · 증명(must-prove)이다. 하나가 비면 된다·안 된다 판정을 내지 못한다 업계 일반 과정 고유 틀, 공식 문서에 없음 [6.1①] [6.1②]

범주	채우는 것 (고객지원 예)	가까운 공식 줄
해야 함	맡길 과제 목록이다. 이상적인 대화를 과제로 쪼갠다	■ 문제 정의 · 규칙 ②
하면 안 됨	권한 없는 약속 · 없는 상품 안내 · 반드시 사람에게 가는 사례	가드레일(dos and don'ts) · 권한 없는 약속 금지 · 위험이 큰 결정 전 사람의 통제
비용	월 문의량 예측 · 건당 상한 · 지연 목표	허용 지연은 사용자 기대에 달려 있다 (나머지 업계 일반)
증명	감사·규정 증거 · 합격 숫자(예 에스컬레이션 정확도)	에스컬레이션 정확도 95% 이상 (감사 증거는 업계 일반)

"하면 안 됨" 은 이해관계자(stakeholder)가 스스로 말하지 않는다. 그래서 따로 묻는다. 이 칸이 사람 승인 게이트 위치를 정한다 업계 일반. 자세한 것은 ■ human-in-the-loop 게이트 위치 에 있다

뻔한 질문 말고 안 떠올린 어려운 곳을 판다 (■ discovery · 규칙 ① 에서 왔다. 금지 칸에 쓴 것은 해석이다)

형용사 요구("직관적·매끄럽게·더 빠르게")는 요구가 아니다. "지금 무엇이 그렇지 못한가" 를 묻고 측정 가능한 행동 하나로 바꾼다 업계 일반

공식은 "좋은 성능" 대신 "정확한 감정 분류" 처럼 구체적으로 쓰라고 한다. 자세한 것은 ■ 성공 기준 에 있다

자신 있는 설계 스케치를 먼저 보이면 스폰서가 제약 말하기를 멈춘다. 그래서 질문을 끝낸 뒤 제안한다 업계 일반

④
가정 목록 : 지나가며 들은 말("아마 국내 서버에만" · "상담원이 다 잡아 줄 것")은 확인 전에는 가정이다. 한 줄에 아래를 차례로 적는다 업계 일반 [6.1①] [6.1③]
- 진술
- 걸리는 제약
- 따라오는 결정
- 담당자와 확인 기준
확인된 사실만 설계의 제약으로 쓴다. 확인 안 된 말이 요구가 되면, 틀렸을 때 그 위에 선 설계를 다시 짠다 업계 일반

출처 없는 요구 줄은 지우지도 그대로 두지도 않는다. 가정으로 표시하거나 "증명" 질문으로 직접 묻는다 업계 일반

데이터 위치·거주지·접근 권한·보존은 데이터 소유자·법무에게 직접 묻는다. 모델 후보 고르기·기술 스파이크·위험 수락서보다 앞이다 업계 일반. 확인된 사실과 약정의 짝은 ■ discovery · 규칙 ⑤ 에 있다

말하지 않은 기대는 초기 테스트에서 "되는" 기능이 나중에 못 맞춘다 (■ discovery · 규칙 ③ 에서 왔다. 가정 목록으로 넓힌 것은 해석이다)
반대 함정, 다시 열지 않는다 : 기준선·목표·요구 4범주·담당자가 다 있으면 새 요청이 와도 discovery 를 처음부터 다시 열지 않는다. 범위 판단은 결정권자에게 맡긴다. 일은 프로토타입·ADR 로 한다 업계 일반 [6.1①] [6.5]

요구 자체가 바뀌었다는 증거가 있을 때만 discovery 로 돌아간다 업계 일반. 자세한 것은 ■ lifecycle 루프 · 규칙 ③ 에 있다

한 문장으로 설명되는 작은 변경이면 계획 없이 바로 한다 (■ discovery · 규칙 ①)

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

판단 규칙

조건	답	등급	근거
목표를 적는다	기준선 대비로 적는다 ("지금보다 N% 개선")		define-success en-full "which is a 5% improvement over the current baseline (Achievable)."
무엇을 만들기 전이다	그것 없이 대표 과제로 돌려 빈 곳을 적는다. 그리고 기준선부터 측정한다	(Skills 문맥 — discovery 로 넓힌 건 해석)	agent-skills best-practices "Establish baseline: Measure Claude's performance without the Skill"
기준선을 어떻게 재나?	한 정의로 잰다. 운영 데이터와 실제 사용자·데이터 소유자 인터뷰를 쓴다	업계 일반	공식 문장이 없다
목표를 누가 고르나?	이름이 정해진 결정권자 1명이 고른다	업계 일반	공식 문장이 없다
목표를 이룰 수 있는지 가늠한다	업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에 기댄다		define-success en-full
요구 칸을 나눈다	해야 함 · 하면 안 됨 · 비용 · 증명 4범주로 나눈다	업계 일반 (과정 고유 틀)	공식 문서에 이 이름이 없다
"하면 안 됨" 칸을 채운다	가드레일 dos and don'ts 를 둔다. 권한 없는 약속은 하지 않는다. 위험이 큰 결정 전에는 사람이 통제한다	(요구 범주로 묶은 건 해석)	customer-support-chat en-full · safe-trustworthy-agents
"비용" 칸의 지연 목표를 정한다	사용자 기대에서 나온다		define-success en-full
"증명" 칸의 합격 숫자를 정한다	예는 에스컬레이션 정확도 95% 이상이다		customer-support-chat en-full
형용사 요구가 있다	구체적으로 쓴다. "좋은 성능" 대신 "정확한 감정 분류" 처럼 쓴다		define-success en-full
확인 안 된 말이 있다	가정 목록에 적는다 (진술, 제약, 결정, 담당자와 확인 기준)	업계 일반	공식 문장이 없다
데이터 위치·권한·보존에 관한 말이 있다	데이터 소유자·법무에게 직접 묻는다. 모델 고르기보다 앞이다	업계 일반	사실과 약정의 짝은 ■ discovery · 규칙 ⑤ (확인)
산출물이 다 찬 뒤 새 요청이 왔다	discovery 를 다시 열지 않는다. 담당자가 범위를 판단한다	업계 일반	—

상황 변수

변수	값	답 쪽	등급	근거
들은 사람	스폰서 한 명만	미완이다. 현장 사용자·데이터 소유자까지 듣는다	업계 일반	—
목표 칸	형용사("더 빠르게")	미완이다. 측정 가능한 행동으로 바꾼다		판단 규칙 10
목표 칸	숫자는 있고 기준선은 없다	미완이다. 기준선부터 잰다	업계 일반	판단 규칙 1 · 뒤집히는 때 1
승인자	둘	한 명으로 정리한다	업계 일반	—
요구 칸	"하면 안 됨" 이 비어 있다	따로 묻는다	업계 일반	판단 규칙 7
들은 말	"아마 ~일 것"	가정 목록에 적는다	업계 일반	—
변경 크기	한 문장으로 설명되는 작은 변경	산출물을 다 채우지 않고 바로 한다	(코딩 문맥 — 넓힌 건 해석)	best-practices · 뒤집히는 때 2
요구자 상태	무엇을 원하는지 본인도 모른다	먼저 돌려 보고 그 결과로 묻는다	(코딩 문맥 — 넓힌 건 해석)	best-practices · 뒤집히는 때 3
지금 하는 일	아예 없다(새 업무)	기준선은 지금 고객이 겪는 값이다(아침까지 기다리는 시간)	추론	뒤집히는 때 4

연습 문제

고객지원 본부장과 워크숍을 한 번 한 뒤 PM 이 discovery 를 "완료" 로 표시했다. 목표 칸에는 "반품 처리를 더 빠르게"형용사 목표뿐이고, 지금 반품 한 건이 접수부터 환불까지 몇 분 걸리는지는 아무도 재지 않았다기준선 없음. 본부장은 "반품 사진은 아마 국내 서버에만 있을 거예요들은 말" 라고 했다. 설계에 들어가도 될까?

시험 대비

함정

"스폰서 워크숍을 했으니 discovery 완료" 는 함정이다. 기준선·담당자·4범주·가정 목록이 없으면 미완이다 업계 일반
"기준선은 운영하며 재고, 목표는 업계 벤치마크 숫자로" 는 함정이다. 목표는 기준선 대비로 적는다. 벤치마크는 달성 가능한지 가늠하는 재료이고, 고르는 것은 담당자다 (해석)
"목표는 아키텍트가 정해 두고 나중에 승인받자" 나 "본부장과 상담팀장 둘 다 승인권자" 는 함정이다. 결정권자는 한 명이다 업계 일반
"'더 빠르게' 를 요구로 받아 설계 시작" 은 함정이다. 검사할 수 있게, 구체적으로 쓴다 (■ 성공 기준)
"원하는 기능만 받아 적음" 은 함정이다. "하면 안 됨" 칸이 비어 있다. 그래서 따로 묻는다 업계 일반. 권한 없는 약속 금지는 공식 가드레일이다
들은 말 "아마 국내에만" 을 요구로 적거나, 출처가 없다고 지우는 것은 함정이다. 가정 목록에 적고 담당자에게 직접 묻는다 업계 일반
"모델 후보 벤치마크 스파이크부터, 데이터 위치는 나중에" 는 함정이다. 제약 확인이 먼저다 업계 일반
반대쪽 함정도 있다. "새 요청이 올 때마다 discovery 를 처음부터" 는 함정이다. 산출물이 다 있으면 담당자가 범위를 판단한다 업계 일반

신호

"which is a 5% improvement over the current baseline (Achievable)."

"Achievable: Base your targets on industry benchmarks, prior experiments, AI research, or expert knowledge."

"Establish baseline: Measure Claude's performance without the Skill" (Agent Skills 모범 사례)

"Early on, evals force product teams to specify what success means for the agent, while later they help uphold a consistent quality bar."

"You will also want to include any important instructions outlining dos and don'ts for how Claude should interact with the customer."

"Don't make promises or enter into agreements it's not authorized to make."

"humans should retain control over how their goals are pursued, particularly before high-stakes decisions are made."

"What is the acceptable response time for the model? This depends on your application's real-time requirements and user expectations."

"Aim for an escalation accuracy of 95% or higher."

discovery 는 보통 산출물 네 개를 다 채우지만, 한 줄 변경은 바로 하고, 요구자도 모르면 작게 돌려 보며, 같은 목표도 기준선 구간부터 정한다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요

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

뒤집히는 때

1. 같은 "30% 단축" 이 전혀 다른 약속이 되는 때

조건 : 목표는 "반품 처리 30% 단축" 이다. 기준선을 한 정의로 재지 않았다.
계산 : 정의 A 는 "접수부터 상담원 첫 응답까지" 다. 기준선이 14분이면 30% 단축은 9.8분이다(4.2분을 줄인다). 정의 B 는 "접수부터 환불 승인까지" 다. 기준선이 2.5일(60시간)이면 30% 단축은 42시간이다(18시간을 줄인다). 같은 문장이 4분짜리 약속도, 18시간짜리 약속도 된다.
전제 : 두 기준선 값은 예시다. 정의만 다르고 같은 반품 흐름이다.
등급 : 계산 (기준선 대비 목표는 확인)
근거 : define-success en-full
판단 : 그래서 "기준선 있음" 은 숫자 하나가 아니다. "무엇부터 무엇까지" 정의까지 있어야 한다.

2. 작은 변경이면 산출물을 다 채우지 않음

조건 : 반품 안내 문구 한 줄 고치기처럼 한 문장으로 설명되는 변경이다.
판단 : 네 산출물을 다 채우는 것은 과하다. 계획에도 부담이 있다. 그래서 바로 한다. "모든 요청에 산출물 전부" 는 반대 함정이다.
등급 : (코딩 세션 문맥 — 설계 discovery 로 넓힌 건 해석)
근거 : best-practices "If you could describe the diff in one sentence, skip the plan."

3. 요구자도 원하는 걸 모를 때

조건 : 본부장이 "뭔가 AI 로 반품을 편하게" 라고만 한다. 무엇이 불편한지 본인도 못 짚는다.
판단 : 질문만 계속하면 빈 답만 모인다. 작게 먼저 돌려 보고 결과물을 보여 주는 것이 곧 질문이다. 그 반응으로 기준선·목표·금지 칸을 채운다.
등급 : (코딩 세션 문맥 — 넓힌 건 해석)
근거 : best-practices "Sometimes a vague prompt is exactly right because you want to see how Claude interprets the problem before constraining it."

4. 지금 하는 사람이 없는 새 업무

조건 : 야간(22시~8시) 반품 문의는 지금 아무도 응대하지 않는다. 그래서 잴 "현재 프로세스" 가 없다.
판단 : 기준선은 지금 고객이 겪는 값이다(아침까지 기다리는 시간 · 그 사이 이탈률). "기준선 없음" 이 "재지 않아도 됨" 은 아니다.
등급 : 추론
근거 : define-success en-full(기준선 대비 목표)에서 한 걸음 더 나간 것이다

오답 재료

오답	왜 끌리나	왜 틀리나	등급	근거
"스폰서 워크숍을 마쳤으니 discovery 완료, 설계 착수"	일정표에 "완료" 가 찍힌다	기준선·담당자·4범주·가정 목록이 없으면 미완이다	업계 일반	—
"기준선은 운영하며 재고, 목표는 업계 벤치마크로"	벤치마크는 객관적 숫자 같다	목표는 기준선 대비로 적는다. 벤치마크는 달성 가능한지 가늠하는 재료이지 목표를 고르는 주체가 아니다	해석	define-success en-full
"아키텍트가 목표를 정하고 나중에 승인"	전문가가 빨리 정한다	목표에는 가치 판단이 들어간다. 그래서 결정권자 1명이 고른다	업계 일반	—
"'더 빠르게' 를 요구로 설계 시작"	요청자 말을 존중하는 것 같다	형용사는 검사할 수 없다. 그래서 구체적으로 쓴다		define-success en-full
"원하는 기능 목록만 받으면 요구 수집 끝"	기능 목록이 곧 요구 같다	"하면 안 됨"·"비용"·"증명" 칸이 비어 있다	업계 일반 (칸마다 가까운 공식 줄 있음)	판단 규칙 7~9
"들은 말을 요구로 적음" / "출처 없으니 지움"	빨리 정리된다	확인 전에는 가정이다. 지우면 제약을 놓친다	업계 일반	—
"모델 후보 벤치마크 스파이크부터"	기술 불확실성이 가장 커 보인다	데이터 위치·권한 제약이 후보 자체를 바꿀 수 있다. 그래서 제약 확인이 먼저다	업계 일반	—
반대 함정 : "새 요청마다 discovery 를 처음부터"	절차를 지키는 것 같다	산출물이 다 있으면 담당자가 범위를 판단한다. 작은 변경은 바로 한다	업계 일반 + 확인(작은 변경)	best-practices
"자신 있는 설계 스케치를 먼저 보여 줘 신뢰를 얻는다"	전문성이 보인다	스폰서가 제약 말하기를 멈춘다. 그래서 질문을 끝낸 뒤 제안한다	업계 일반	—

참고

함께 보기

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

출처

상태

업계 일반 (산출물 목록 · 기준선 재는 법 · 결정권자 1명 · 4범주 이름 — 과정 고유 틀 · 금지 칸 따로 묻기 · 가정 목록 · 데이터 소유자 직접 확인 · 다시 안 엶 — 8가지)
해석 3곳(스킬 기준선 → discovery · 벤치마크는 재료 · 말하지 않은 기대 → 가정 목록)

미해결

공식 근거를 못 찾은 규칙은 일곱 가지다. 산출물 목록 · 결정권자 1명 · 요구 4범주 이름(must-do/must-not-do/must-cost/must-prove) · 가정 목록이 그 넷이다. 실무자 인터뷰 의무 · 데이터 소유자 직접 확인 · 스케치를 먼저 보이지 않기가 나머지 셋이다. 검색어는 stakeholder · decision.?maker · business owner · assumption · baseline · requirements 였다. 범위는 ccarp/raw/official-docs/en-*.md · ccarp/raw/skilljar/*.md · exam-guide.json 이다. 제외는 받지 않은 문서·ko 판이다. 결과는 D6 뜻 0건이다. stakeholder 는 가이드 목표 문구와 차별 평가 논문에만 나온다.
공식 "기준선" 문장은 AI 쪽 기준선(모델 성능 · 스킬 없이 잰 성능 · eval 의 지연·비용)이다. "지금 사람이 하는 일의 기준선" 을 discovery 산출물로 적으라는 문장은 없다. 이것은 이 카드의 해석이다.
후보 절 공식 근거 7줄은 모두 원문의 그 줄에서 확인했다. 그 줄은 define-success en-full 53 · demystifying-evals 277·44 · customer-support-chat en-full 89·360 · safe-trustworthy-agents 17 · agent-skills best-practices 705 다. 추가로 찾아 쓴 줄은 define-success en-full 15·35·45·88 · customer-support-chat en-full 160·352 다.
"벤치마크로 목표를 채우지 않음"(후보 규칙)은 공식 "달성 가능 = 업계 벤치마크에 기댐" 과 부딪혀 보인다. 그래서 이 카드는 "벤치마크 = 달성 가능한지 가늠하는 재료, 목표를 고르는 건 담당자" 로 나눴다. 이 구분은 해석이다.
Skilljar 는 이번에 보지 않았다. ccarp/raw/skilljar 를 위 검색어로 찾은 결과 discovery 산출물 주제가 없었다 (제외 = 받지 않은 과정·강의).