■ discovery

discovery : 진짜 필요 먼저 · 데이터 사실 → 약정6.1 본편

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

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

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

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

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

한눈에

"완벽한 X 를 제일 좋은 모델로" 같은 해법 요청을 받으면, 만들기 전에 아래 셋을 묻고 적는다.

진짜 필요
범위
데이터 사실

공식 근거는 코딩 세션 문서다. 바로 코딩하면 엉뚱한 문제를 푼다. 그래서 탐색·계획을 구현과 떼고, 큰 기능은 인터뷰를 먼저 하고 명세(spec)를 쓴다

이것을 AI 시스템 설계 전체로 넓힌 것은 이 카드의 해석이다 업계 일반. 적는 법(결과·범위·증거)은 ■ 문제 정의 에 있다. 여기는 묻는 법과 사실 모으기를 다룬다

비유 "DB 더 큰 걸로 바꿔 줘" 티켓에 느린 쿼리와 목표 지연(latency)부터 묻는 것과 같다. PCI 범위는 카드 데이터가 흐르는 시스템에만 건다. 모든 워크로드에 PCI 통제(control)를 걸지 않는다

해법 요청을 받고 바로 지으면 엉뚱한 문제를 풀고, 먼저 진짜 필요·범위·데이터 사실을 묻고 적어 명세로 가야 한다는 대비 — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

"제일 센 약 주세요" 하는 손님에게 약사가 먼저 어디가 아픈지 묻는 거예요.

센 약이 늘 맞는 약은 아니에요.
묻는 건 몇 분, 잘못 먹은 약은 며칠을 버려요.
알레르기가 있는지도 물어야 어떤 약을 못 쓰는지 정해져요.
감기약 하나 사러 온 손님에겐 길게 묻지 않아요.

개념 설명

영상 — 모델 고르기 전에 먼저 묻기 (약 43초 · 소리 없음 · 자막). 묻는 항목 4개 = 업계 일반(목록 6.1①) · 전문가 판정 결과 · 시간 블록 길이 · ④ '오타 한 곳' 요청은 그림용 가정 — 방향은 설명 원리(해법 요청은 필요의 추측 · 모호함은 eval 로 드러남 · discovery 양은 범위에 비례)를 따름 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

해법 요청은 필요의 추측이다

요청자가 떠올린 해법("가장 좋은 모델로")은 문제를 풀 방법에 대한 짐작일 뿐이다. 문제 자체가 아니다.
공식(코딩 세션)은 바로 구현을 시작하면 엉뚱한 문제를 푼다고 한다. 그래서 탐색·계획을 구현과 뗀다.
묻는 비용은 잘못 짓는 비용보다 작다. 명세를 정확하게 만드는 시간이 구현을 지켜보는 시간보다 더 쓸 만하다 (공식).

모호함은 eval 로 드러난다

요구 문장을 eval 과제로 적어 본다. 그러면 전문가 둘이 같은 합격·불합격을 낼 수 있는지로 구체성을 판정할 수 있다.
같은 명세를 읽은 두 사람이 엣지 케이스를 다르게 해석한다. 이것이 나중에 "되는데 기대와 다름" 이 된다.

약정은 데이터 사실에서 나온다

약정(BAA·DPA·ZDR·거주지)은 대상·조건이 제각각이다. 그래서 아래 데이터 사실을 먼저 모아야 어느 약정이 걸리는지 정해진다.
- PHI 유무
- EU 개인정보
- 추론 위치 요구
- 보존 요구
거꾸로 약정부터 묶으면 필요 없는 제약(쓸 수 없는 모델·기능)과 비용이 붙는다. 정작 걸려야 할 조건은 빠질 수 있다.

discovery 양은 범위에 비례한다

범위가 분명하고 작으면 생략하는 것이 공식 권장이다. 탐색형 과제는 오히려 먼저 돌려 보는 것이 묻는 방법이다.

규칙과 판단

범위가 분명하고 작으면 바로 하고, 아니면 모델 고르기는 아직이며 이해관계자 인터뷰가 먼저라는 결정 나무 — 그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

①② 요청을 받으면 [6.1①]

범위가 분명하고 작나?한 문장으로 설명되는 변경

예

바로 한다

계획 없이 바로 한다. 계획에도 부담이 있다

아니오 ("완벽한 계약 검토기")

무엇부터 하나?

모델·프롬프트 고르기

아직

모델·도구는 범위·위험·성공 기준(success criteria)이 보인 뒤에 고른다 업계 일반

이해관계자에게 묻기

인터뷰 먼저

구현·UX·엣지 케이스·걱정·trade-off(절충)를 묻는다. 뻔한 질문 말고 안 떠올린 어려운 곳을 판다

③④ 요구가 충분히 구체적인가 [6.1①] [6.1②]

전문가 둘이 같은 판정을 내나?eval 과제로 적어 본다

아니오 (해석이 갈린다)

더 묻는다

같은 명세를 읽은 엔지니어 둘이 엣지 케이스를 다르게 해석할 수 있다. eval 이 이 모호함을 푼다. 안 적은 기대가 있으면, 초기 테스트에서 "되던" 기능이 나중에 그 기대를 못 맞춘다

예

명세로 쓴다

명세에는 관련 파일·인터페이스 이름, 범위 밖 명시, 마지막 end-to-end(처음부터 끝까지) 검증 단계를 적는다. 기준 쓰는 법은 ■ 성공 기준 에 있다

⑤ 데이터 사실에서 약정으로 [6.1③]

어떤 사실이 있나?사실마다 짝을 맞춘다

PHI 가 있다

BAA + HIPAA-ready 조직

ZDR 은 따로 필요 없다. 자세한 것은 ■ HIPAA 구성 에 있다

EU 개인정보

DPA

고객은 controller, Anthropic 은 processor 다. 역외 이전은 SCC 로 한다. 자세한 것은 ■ 규정별 계약·경로 에 있다

추론 위치 제한

inference_geo

요청마다 us·global 을 정한다 (4.6 이후 모델, us 1.1배)

보존 최소화

ZDR 검토

Covered Models(Fable 5.1 등)를 쓰는 워크스페이스에는 ZDR 이 없다(기본 30일 보존). 자격 고객에게는 한시 전환 옵션이 있다 (Fable 5.1 = 2026-08-31, 시험 뒤 변경). 자세한 것은 ■ 데이터 기본값 에 있다

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

먼저 묻기 : 처음 온 기능 요청 말고 진짜 필요를 찾는다. 공식(코딩 세션)은 바로 코딩하면 엉뚱한 문제를 푼다고 한다. 그래서 탐색·계획을 구현과 뗀다(plan mode) [6.1①]

큰 기능은 인터뷰를 먼저 한다. 구현·UX·엣지 케이스·걱정·trade-off 를 묻는다. 뻔한 질문 말고 안 떠올린 어려운 곳을 판다. 다 덮을 때까지 묻고 명세로 쓴다

반대로 범위가 분명하고 작으면 계획 없이 바로 한다. 한 문장으로 설명되는 변경이면 계획을 생략한다. 계획에도 부담이 있다
②
무엇을 묻나 (계약 검토기 예) : 아래를 묻는다 업계 일반 목록 6.1① [6.1①]
- 어떤 조항이 중요한가?
- 누가 결과를 읽나?
- 놓치면 비용이 얼마인가?
- 데이터가 민감한가?
모델·도구는 범위·위험·성공 기준이 보인 뒤에 고른다 업계 일반. 규칙이 안정적이면 LLM 없는 코드도 선택지다. 자세한 것은 ◆ 코드 vs LLM vs hybrid 에 있다
충분히 구체적인가 : eval 과제를 적어 보면 요구가 구현에 들어갈 만큼 구체적인지 드러난다 [6.1①] [6.1②]

좋은 과제는 전문가 둘이 따로 봐도 같은 합격·불합격을 낸다. 같은 명세를 읽은 엔지니어 둘이 엣지 케이스를 다르게 해석할 수 있다. eval 이 이 모호함을 푼다

안 적은 기대가 있으면 초기 테스트에서 "되는" 기능이 나중에 그 기대를 못 맞춘다. 잘 만든 eval 이면 일찍 드러났을 것이다

기준 쓰는 법(4가지 · 여러 차원)은 ■ 성공 기준 에 있다 (6.1② 본편)
④
결과물 : 명세(spec)를 쓴다. 명세는 자기완결형이다. 아래를 담는다 [6.1①] [6.4]
- 관련 파일·인터페이스 이름
- 범위 밖 명시
- 마지막에 기능이 되는지 증명하는 end-to-end 검증 단계
명세를 정확히 만드는 시간이 구현을 지켜보는 시간보다 더 쓸 만하다 (코딩 명세 기준이다. 설계 문서로 넓힌 것은 해석이다)

데이터 사실에서 약정으로 : 약정부터 묶지 않는다. 데이터 종류·민감도·거주지·보존 요구를 사실로 모은 뒤 맞춘다 업계 일반 원칙. 사실별 짝은 공식이다 [6.1③]

사실	약정·설정
PHI 가 있다	BAA + HIPAA-ready 조직을 쓴다. ZDR 은 따로 필요 없다. BAA 는 수락한 그 조직 하나에만 적용되고, Console·Cowork·베타 기능은 제외된다
EU 개인정보	DPA : 고객은 controller, Anthropic 은 processor 다. 역외 이전은 SCC 로 한다
추론 위치 제한	inference_geo : 요청마다 `us`·`global` 을 정한다 (4.6 이후 모델, `us` 1.1배). 저장 위치는 workspace geo 가 따로 정한다
보존 최소화	ZDR 을 쓴다. 단 Covered Models(Fable 5.1 등)를 쓰는 워크스페이스에는 ZDR 이 없다(기본 30일 보존). 자격 고객에게는 한시 전환 옵션이 있다 (Fable 5.1 = 2026-08-31, 시험 뒤 변경)

세부는 ■ HIPAA 구성 · ■ BAA 적용 범위 · ■ 데이터 기본값 · ■ 규정별 계약·경로 에 있다

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

판단 규칙

조건	답	등급	근거
큰 기능이다. 방법이 불확실하거나 여러 곳을 바꾼다	탐색·계획을 구현과 뗀다. 인터뷰한 뒤 명세를 쓴다		best-practices "for larger features have Claude interview you and write a spec before you start implementing."
한 문장으로 설명되는 작은 변경이다	계획 없이 바로 한다		best-practices "If you could describe the diff in one sentence, skip the plan."
인터뷰에서 무엇을 묻나?	구현·UX·엣지 케이스·걱정·trade-off(절충)를 묻는다. 뻔한 질문 말고 어려운 곳을 묻는다		best-practices
요구가 충분히 구체적인지 알고 싶다	eval 과제로 적어 본다. 전문가 둘이 같은 판정을 내면 충분하다		demystifying-evals
명세에 무엇을 적나?	관련 파일·인터페이스 · 범위 밖 · end-to-end 검증 단계를 적는다		best-practices (코딩 명세다. 설계 문서로 넓힌 것은 해석이다)
계약 검토기에서 묻는 항목을 정한다	중요 조항 · 읽는 사람 · 놓침 비용 · 데이터 민감도를 묻는다	업계 일반	목록 6.1① (공식 문장이 없다)
PHI 가 있다	BAA 와 HIPAA 준비 조직을 쓴다. ZDR 은 따로 필요 없다		api-and-data-retention
EU 개인정보가 있다	DPA(고객 controller · Anthropic processor)와 역외 이전 SCC 를 쓴다		dpa
추론 위치를 제한한다	`inference_geo` 를 요청마다 정한다(`us`·`global`). 4.6 이후 모델에서 된다		data-residency
보존을 최소화하고 Fable 5.1 도 쓴다	Covered Models 를 쓰는 워크스페이스에는 ZDR 이 없다		covered-models

상황 변수

변수	값	답 쪽	등급	근거
범위	한 문장 변경	바로 한다		판단 규칙 2
범위	큰 기능 · 여러 파일 · 방법 불확실	인터뷰한 뒤 명세를 쓴다		판단 규칙 1
과제 성격	탐색형(어떻게 해석하는지 보고 싶다)	먼저 돌려 본다		best-practices · 뒤집히는 때 2
요청 문구	"완벽" · "제일 좋은 모델"	해법 요청이다. 그래서 묻는다	업계 일반	목록 6.1①
데이터	건강 정보가 없는 일반 상거래	BAA 대상이 아니다		api-and-data-retention(PHI 가 조건)
데이터	EU 고객이 있다	DPA·SCC 를 쓴다		dpa
쓰는 surface	Claude Code 로 PHI	ZDR 이 BAA 조건이 된다		privacy-baa · 뒤집히는 때 3
쓰는 surface	브라우저에서 바로 API 호출 + ZDR	쓸 수 없다. 백엔드 프록시를 거친다		zero-data-retention-full
조직 구성	HIPAA 워크로드 + 일반 워크로드	조직을 나눈다 (HIPAA 는 조직 단위이고, 켜면 영구다)		api-and-data-retention

연습 문제

법무 임원이 "완벽한 계약 검토기를 제일 좋은 모델로 만들어 달라"해법 요청고 한다. 어떤 조항이 중요한지, 누가 결과를 읽는지는 아직 아무도 말하지 않았다범위 불분명. 팀은 "일단 최상위 모델과 프롬프트부터 고르자"고 한다. 첫 걸음은 무엇일까?

시험 대비

함정

"요청대로 가장 좋은 모델과 프롬프트부터" 는 함정이다. 먼저 묻는다. 바로 코딩하면 엉뚱한 문제를 푼다 (코딩 문맥이다. 넓힌 것은 해석이다)
"완벽한 정확도를 약속하고 착수" 는 함정이다. 약속하지 않는다. 자세한 것은 ■ 문제 정의 · 규칙 ⑤ 에 있다
"민감하니 BAA·GDPR·ZDR 을 한 묶음으로" 는 함정이다. 셋은 대상·조건이 다르다. PHI 가 없으면 BAA 대상이 아니다
"HIPAA 에 ZDR 도 추가" 는 함정이다. ZDR 은 따로 필요 없다 (Claude Code 예외는 ■ BAA 적용 범위 에 있다)
"ZDR 조직에서 Fable 5.1" 은 함정이다. Covered Models 를 쓰는 워크스페이스에는 ZDR 이 없다 (한시 전환 옵션은 예외)
"인터뷰 = '뭐가 필요하세요?'" 는 함정이다. 뻔한 질문 말고 안 떠올린 어려운 곳(엣지 케이스·trade-off)을 판다
반대쪽 함정도 있다. "모든 일에 인터뷰·명세부터" 는 함정이다. 범위가 분명하고 작으면 바로 한다

신호

"Letting Claude jump straight to coding can produce code that solves the wrong problem."

"for larger features have Claude interview you and write a spec before you start implementing."

"Don't ask obvious questions, dig into the hard parts I might not have considered."

"If you could describe the diff in one sentence, skip the plan."

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

"A good task is one where two domain experts would independently reach the same pass/fail verdict."

"If your organization handles PHI, HIPAA readiness is the arrangement to use; you do not also need ZDR."

"the BAA only covers the single organization that accepted it, and excludes features such as Claude Console, Claude Cowork, or features currently in beta"

"Controls where model inference runs, on a per-request basis."

"zero data retention is not available in workspaces, Claude Enterprise organizations, or third-party platforms (e.g., Azure Subscriptions) where Covered Models can be accessed."

보통은 짓기 전에 묻고 적지만, 범위가 작고 분명하면 바로 하고, 요구자도 원하는 걸 모르면 먼저 돌려 보며 좁힌다. — 그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요

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

뒤집히는 때

1. 작은 일엔 discovery 를 생략

조건 : 범위가 분명하고 고칠 것이 작다(오타·로그 한 줄·이름 바꾸기).
판단 : 계획에도 부담이 있다. 그래서 바로 한다. "모든 요청에 인터뷰부터" 는 반대 함정이다.
근거 : best-practices

2. 탐색형이면 먼저 돌려 보는 게 묻는 방법

조건 : 요구자도 무엇을 원하는지 아직 모른다. 모델이 문제를 어떻게 해석하는지부터 보고 싶다.
판단 : 계획을 건너뛰고 모호한 프롬프트로 먼저 돌려 본 뒤 좁힌다. 결과물을 보여 주는 것이 곧 질문이다.
등급 : (문장은 코딩 세션 문맥 — 설계 discovery 로 넓힌 건 해석)
근거 : best-practices "Sometimes a vague prompt is exactly right because you want to see how Claude interprets the problem before constraining it."

3. "HIPAA 면 ZDR 불필요" 가 뒤집히는 surface

조건 : PHI 를 Claude Code(CLI · 데스크톱 로컬)로 다룬다.
판단 : API 는 HIPAA readiness 로 ZDR 없이 된다. 하지만 Claude Code 는 API HIPAA readiness 대상이 아니다. BAA 적용은 ZDR 을 켰을 때만이다. 그래서 surface 가 바뀌면 사실과 약정의 짝도 바뀐다.
근거 : api-and-data-retention · privacy-baa · 세부는 ■ BAA 적용 범위

4. Covered Models 인데 ZDR 이 되는 때

조건 : Fable 5.1 을 쓰고 싶다. 보존 최소화 요구도 있다.
판단 : 기본은 ZDR 을 쓸 수 없다(30일 보존). 단 자격 고객에게는 사내 업무 앱용 한시 ZDR 옵션이 주어진다(EFS 로 가는 전환).
등급 : 시험 뒤 변경(Fable 5.1 = 2026-08-31)
근거 : covered-models

5. 거주지 요구를 사실 확인 없이 걸면 드는 값

조건 : "민감하니까 미국 안에서만" 을 사실 확인 없이 inference_geo: "us" 로 고정한다.
계산 : 월 입력 3억, 출력 5천만 토큰에 Sonnet 5($2 / $10 백만 토큰당)를 쓴다. global = 300 × $2 + 50 × $10 = $1,100 이다. us 는 1.1배라 $1,210 이다. 월 $110 를 더 낸다.
전제 : 캐싱·배치는 없다. 가격은 2026-09-28 조회값이다. Sonnet 5 는 4.6 이후 모델이라 inference_geo 를 지원한다.
등급 : 계산 (1.1배는 확인)
근거 : data-residency · prompt-caching 표(Sonnet 5 가격)
판단 : 거주지 요구가 사실이면 당연히 낸다. 사실이 아니면 값만 붙은 제약이다. 그래서 사실을 먼저 본다.

오답 재료

오답	왜 끌리나	왜 틀리나	등급	근거
"요청대로 가장 좋은 모델과 프롬프트부터 고른다"	요청자 뜻을 존중하는 것 같다 · 빨라 보인다	바로 지으면 엉뚱한 문제를 푼다. 모델은 범위·위험·성공 기준(success criteria)이 보인 뒤에 고른다	(코딩 문맥) + 업계 일반	best-practices
"완벽한 정확도를 약속하고 착수"	고객이 원한다	달성 가능한 목표만 둔다. 권한 없는 약속은 하지 않는다		■ 문제 정의 · 규칙 ⑤
"민감하니 BAA·GDPR·ZDR 을 한 묶음으로 체결"	안전해 보인다 · 빠짐없어 보인다	셋은 대상·조건이 다르다. PHI 가 없으면 BAA 대상이 아니다. ZDR 은 Covered Models 를 막는다		api-and-data-retention · covered-models
"HIPAA 에 ZDR 도 추가"	겹겹이 막으면 더 안전해 보인다	API 에서는 따로 필요 없다(HIPAA readiness 가 대안). 단 Claude Code 는 예외다		api-and-data-retention · 뒤집히는 때 3
"ZDR 조직에서 Fable 5.1 사용"	최신 모델과 최소 보존을 다 가진다	Covered Models 를 쓰는 워크스페이스에는 ZDR 이 없다 (한시 옵션은 예외)		covered-models
"인터뷰는 '무엇이 필요하세요?' 로 충분"	열린 질문이 중립적이다	뻔한 질문 말고 안 떠올린 어려운 곳(엣지 케이스·trade-off)을 파야 한다		best-practices
"작은 변경에도 인터뷰·명세부터"	절차를 지키는 것 같다	계획은 부담이다. 한 문장 변경이면 바로 한다		best-practices
"요구 문서만 받으면 충분히 구체적"	문서가 있으니 된다고 본다	같은 명세를 두 사람이 다르게 읽는다. eval 과제로 적어 봐야 드러난다		demystifying-evals

참고

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

출처

상태

업계 일반 4줄(AI 설계로 넓힘 · 묻는 항목 · 모델은 뒤에 · 사실 먼저 원칙)
시험 뒤 변경 1곳(Fable 5.1 Covered Model)

미해결

D6 "구조화된 discovery" 를 직접 다룬 공식 문서는 못 찾았다. 근거는 코딩 세션 문서(best-practices)와 eval 글을 AI 시스템 설계로 넓힌 해석이다. 시험이 "공식 원칙" 으로 이 문장을 쓰는지는 모른다.
목록 6.1③ 은 "30일 보존 필수인 Covered Models(Fable 5.1 등)는 ZDR 에서 못 쓴다" 고 적었다. 공식은 "기본 불가 + 자격 고객 한시 옵션" 이다(covered-models). 목록에는 예외가 빠졌다.
목록 6.1③ 은 "Console·베타 기능 제외" 라 적었다. 공식은 Console · Cowork · 베타 기능이다(privacy-baa). 목록에는 Cowork 가 빠졌다.
목록 6.1① 의 "누가 결과를 읽나 · 놓치면 비용" 같은 묻는 항목은 공식 문장이 없다(업계 일반).
Skilljar 는 이번에 보지 않았다. 받아 둔 Skilljar 30개 파일 제목 중 discovery 주제가 없다(ls ccarp/raw/skilljar · 제외 = 받지 않은 과정·강의).