본문으로 건너뛰기
guide-ko / ccar-f
BUILD 0610LAST DEPLOY 2026.08.11 17:53 KST

CCAR-F · 한국어 번역본 · 원문 v1.0 (2026-07)

Claude Certified Architect – Foundations 한국어 번역

이 페이지는 Anthropic 공식 Claude Certified Architect – Foundations Exam Guide(v1.0 (2026-07))를 byteforce가 한국어로 옮긴 번역본입니다. 시험의 공식 기준은 영문 원문이 우선합니다. 공식 원문(PDF)

쉽게 말해번역은 이해를 돕는 참고본입니다. 접수·응시의 최종 기준은 영문 원문과 Anthropic 안내입니다.

INSTRUMENT CLUSTER · CCAR-F · CALIBRATED FROM EXAM GUIDE v1.0 (2026-07)

시험 한 벌을, 계기 하나로

D127%D218%D320%D420%D515%

조각을 선택하면 도메인 상세가 표시됩니다

쉽게 말해원 한 바퀴가 이 시험 전체입니다. 각 조각의 각도가 그 영역의 비중이고, 안에 찍힌 점을 모두 세면 실제 문항 수(60개)가 됩니다.

SCALED 1001000 · GATE 720예측 점수 없음 — 원점수→환산 곡선은 공개되지 않습니다
ITEMS문항
60
TIME시간
120
FEE응시료
$125
PASS합격
720
VALID유효
12개월
RETAKE WAIT1차 후 · 2차 후 · 이후 순으로 대기 증가 · 유효 12개월
대상
설계자 — 에이전트·MCP·프로덕션 아키텍처
시행
Pearson VUE(온라인 감독 또는 시험센터)

READOUT LADDER / DOMAIN WEIGHTS

도메인별 정확한 비중

  • D1Agentic Architecture & Orchestration27%
  • D2Tool Design & MCP Integration18%
  • D3Claude Code Configuration & Workflows20%
  • D4Prompt Engineering & Structured Output20%
  • D5Context Management & Reliability15%
DOMAIN WEIGHTS · 5 DOMAINS · Σ 100%

쉽게 말해도메인 이름과 정확한 비중을 나란히 비교합니다 — 굵게 표시된 칸이 이 시험에서 비중이 가장 큰 영역입니다.

표로 보기
#도메인(영문 원문)가중치
1Agentic Architecture & Orchestration27%
2Tool Design & MCP Integration18%
3Claude Code Configuration & Workflows20%
4Prompt Engineering & Structured Output20%
5Context Management & Reliability15%

이 자격에 관하여About This Certification

버전 1.0 · 2026년 7월 발효 · 시험 코드: CCAR-F · 이 가이드는 사전 통지 없이 변경될 수 있습니다.

Claude Certified Architect – Foundations 자격은 실무자가 Claude로 실제 솔루션을 구현할 때 트레이드오프(tradeoff, 상충관계)에 대해 정보에 근거한 결정을 내릴 수 있음을 검증합니다. 이 시험은 Claude로 프로덕션급 애플리케이션을 구축하는 데 쓰이는 핵심 기술인 Claude Code, Claude Agent SDK, Claude API, 그리고 Model Context Protocol(MCP) 전반의 기초 지식을 평가합니다.

이 시험의 문항은 실제 고객 사용 사례에서 도출한 현실적인 시나리오에 기반합니다. 고객 지원을 위한 에이전트 시스템 구축, 멀티 에이전트 리서치 파이프라인 설계, Claude Code를 CI/CD 워크플로에 통합, 개발자 생산성 도구 구축, 비정형 문서에서 구조화된 데이터 추출 등이 여기에 포함됩니다. 응시자는 개념적 지식뿐 아니라 프로덕션 배포에서의 아키텍처·구성·트레이드오프에 대한 실무적 판단력도 입증해야 합니다.

이 가이드는 시험을 준비하는 응시자를 위한 공식 기준 문서입니다. 시험 내용을 설명하고, 출제되는 도메인과 과제 진술(task statement)을 나열하며, 샘플 문항을 제공하고, 준비 전략을 권장합니다. 시험을 예약하기 전에 이 가이드를 끝까지 읽으십시오.

대상 응시자Intended Audience

이 자격의 이상적인 응시자는 Claude로 프로덕션 애플리케이션을 설계하고 구현하는 솔루션 아키텍트(solution architect)입니다. 이 응시자는 다음 영역에서 실습 경험을 갖추고 있습니다:

· 멀티 에이전트 오케스트레이션, 서브에이전트 위임, 도구 통합, 라이프사이클 훅(lifecycle hook)을 포함해 Claude Agent SDK로 에이전트 애플리케이션 구축

· CLAUDE.md 파일, 에이전트 스킬(Agent Skill), MCP 서버 통합, 플랜 모드(plan mode)를 활용해 팀 워크플로에 맞게 Claude Code 구성 및 커스터마이즈

· 백엔드 시스템 통합을 위한 Model Context Protocol(MCP) 도구 및 리소스 인터페이스 설계

· JSON 스키마, 퓨샷(few-shot) 예시, 추출 패턴을 활용해 신뢰할 수 있는 구조화 출력을 만들어 내는 프롬프트 엔지니어링

· 긴 문서, 멀티턴 대화, 멀티 에이전트 핸드오프 전반에서 컨텍스트 윈도우(context window)를 효과적으로 관리

· 자동 코드 리뷰, 테스트 생성, 풀 리퀘스트 피드백을 위해 Claude를 CI/CD 파이프라인에 통합

· 오류 처리, 휴먼 인 더 루프(human-in-the-loop) 워크플로, 자기 평가 패턴을 포함한 적절한 에스컬레이션·신뢰성 판단

이 응시자는 통상 Claude API, Agent SDK, Claude Code, MCP로 6개월 이상의 실무 경험을 보유하며, 프로덕션 환경에서 대규모 언어 모델(LLM)의 역량과 한계를 모두 이해하고 있습니다.

시험 콘텐츠 개요(블루프린트)Exam Content Outline (Blueprint)

시험 블루프린트(blueprint)는 측정하는 콘텐츠 도메인과 각 도메인이 시험에서 차지하는 대략적 비중을 정의합니다. 비중은 직무 과제 분석(job task analysis)을 통해 결정된, 유능한 수행에 대한 각 도메인의 상대적 중요도를 반영합니다. 백분율은 각 도메인에서 출제되는 채점 문항의 대략적 비율을 나타냅니다.

시험 시나리오Exam Scenarios

이 시험은 시나리오 기반 문항을 사용합니다. 각 시나리오는 일련의 문항을 감싸는 현실적인 프로덕션 상황을 제시합니다. 시험 중에는 아래 6개 시나리오 전체 집합에서 무작위로 선정된 4개 시나리오가 제시됩니다.

시나리오 1: 고객 지원 해결 에이전트

당신은 Claude Agent SDK로 고객 지원 해결 에이전트를 구축하고 있습니다. 이 에이전트는 반품, 청구 분쟁, 계정 문제처럼 모호성이 높은 요청을 처리합니다. 에이전트는 커스텀 Model Context Protocol(MCP) 도구(get_customer, lookup_order, process_refund, escalate_to_human)를 통해 백엔드 시스템에 접근합니다. 당신의 목표는 언제 에스컬레이션해야 하는지 알면서 80% 이상의 첫 응대 해결(first-contact resolution)을 달성하는 것입니다.

주요 도메인: 에이전트 아키텍처 및 오케스트레이션, 도구 설계 및 MCP 통합, 컨텍스트 관리 및 신뢰성

시나리오 2: Claude Code를 활용한 코드 생성

당신은 소프트웨어 개발을 가속하기 위해 Claude Code를 사용하고 있습니다. 팀은 코드 생성, 리팩터링, 디버깅, 문서화에 이를 활용합니다. 커스텀 슬래시 명령(slash command)과 CLAUDE.md 구성으로 개발 워크플로에 통합해야 하며, 플랜 모드와 직접 실행(direct execution)을 각각 언제 쓸지 이해해야 합니다.

주요 도메인: Claude Code 구성 및 워크플로, 컨텍스트 관리 및 신뢰성

시나리오 3: 멀티 에이전트 리서치 시스템

당신은 Claude Agent SDK로 멀티 에이전트 리서치 시스템을 구축하고 있습니다. 코디네이터(coordinator) 에이전트가 전문 서브에이전트에게 작업을 위임합니다. 하나는 웹을 검색하고, 하나는 문서를 분석하며, 하나는 발견 사항을 종합하고, 하나는 보고서를 생성합니다. 이 시스템은 주제를 조사해 인용을 갖춘 종합적인 보고서를 산출합니다.

주요 도메인: 에이전트 아키텍처 및 오케스트레이션, 도구 설계 및 MCP 통합, 컨텍스트 관리 및 신뢰성

시나리오 4: Claude를 활용한 개발자 생산성

당신은 Claude Agent SDK로 개발자 생산성 도구를 구축하고 있습니다. 이 에이전트는 엔지니어가 낯선 코드베이스를 탐색하고, 레거시 시스템을 이해하고, 보일러플레이트 코드를 생성하고, 반복 작업을 자동화하도록 돕습니다. 내장 도구(Read, Write, Bash, Grep, Glob)를 사용하며 Model Context Protocol(MCP) 서버와 통합합니다.

주요 도메인: 도구 설계 및 MCP 통합, Claude Code 구성 및 워크플로, 에이전트 아키텍처 및 오케스트레이션

시나리오 5: 지속적 통합을 위한 Claude Code

당신은 Claude Code를 지속적 통합/지속적 배포(CI/CD) 파이프라인에 통합하고 있습니다. 이 시스템은 자동 코드 리뷰를 실행하고, 테스트 케이스를 생성하며, 풀 리퀘스트에 피드백을 제공합니다. 실행 가능한 피드백을 제공하고 거짓 양성(false positive)을 최소화하는 프롬프트를 설계해야 합니다.

주요 도메인: Claude Code 구성 및 워크플로, 프롬프트 엔지니어링 및 구조화 출력

시나리오 6: 구조화 데이터 추출

당신은 Claude로 구조화 데이터 추출 시스템을 구축하고 있습니다. 이 시스템은 비정형 문서에서 정보를 추출하고, JavaScript Object Notation(JSON) 스키마로 출력을 검증하며, 높은 정확도를 유지합니다. 예외 상황에도 무리 없이 대응하고 하위 시스템(downstream system)과 통합해야 합니다.

주요 도메인: 프롬프트 엔지니어링 및 구조화 출력, 컨텍스트 관리 및 신뢰성

도메인별 세부 목표Detailed Objectives by Domain

아래 각 도메인은 시험에서 다루는 과제 진술(task statement)과, 각 과제에 대해 측정하는 지식과 기술을 나열합니다. 시험 문항은 이 목표들을 기준으로 작성됩니다.

도메인 1: 에이전트 아키텍처 및 오케스트레이션Domain 1: Agentic Architecture & Orchestration

과제 진술 1.1: 자율 과제 실행을 위한 에이전트 루프 설계 및 구현

지식:

· 에이전트 루프 라이프사이클: Claude에 요청을 보내고, stop_reason("tool_use" 대 "end_turn")을 점검하며, 요청된 도구를 실행하고, 다음 반복(iteration)을 위해 결과를 반환하는 흐름

· 다음 행동을 모델이 추론할 수 있도록 도구 결과가 대화 이력(conversation history)에 어떻게 덧붙는지

· 모델 주도 의사결정(Claude가 컨텍스트를 근거로 다음에 호출할 도구를 추론)과 사전 구성된 결정 트리 또는 도구 시퀀스의 구분

기술:

· stop_reason이 "tool_use"일 때 계속하고 "end_turn"일 때 종료하는 에이전트 루프 제어 흐름 구현

· 모델이 새로운 정보를 추론에 반영할 수 있도록 반복 사이에 도구 결과를 대화 컨텍스트에 추가

· 루프 종료를 판단하기 위해 자연어 신호를 파싱하거나, 임의의 반복 횟수 상한을 주된 종료 수단으로 설정하거나, 완료 지표로 어시스턴트의 텍스트 콘텐츠 유무를 확인하는 등의 안티패턴(anti-pattern) 회피

과제 진술 1.2: 코디네이터-서브에이전트 패턴으로 멀티 에이전트 시스템 오케스트레이션

지식:

· 코디네이터 에이전트가 서브에이전트 간 통신, 오류 처리, 정보 라우팅을 모두 관리하는 허브 앤 스포크(hub-and-spoke) 아키텍처

· 서브에이전트가 격리된 컨텍스트에서 동작하는 방식 — 서브에이전트는 코디네이터의 대화 이력을 자동으로 물려받지 않음

· 과제 분해, 위임, 결과 집계, 그리고 질의 복잡도에 따라 어떤 서브에이전트를 호출할지 결정하는 데서 코디네이터가 맡는 역할

· 코디네이터의 과제 분해가 지나치게 좁아 광범위한 리서치 주제를 불완전하게 다루게 되는 위험

기술:

· 전체 파이프라인을 항상 거치는 대신, 질의 요건을 분석해 어떤 서브에이전트를 호출할지 동적으로 선택하는 코디네이터 에이전트 설계

· 중복을 최소화하도록 서브에이전트 간 리서치 범위를 분할(예: 서로 다른 하위 주제나 출처 유형을 각 에이전트에 배정)

· 코디네이터가 종합 산출물에서 누락을 평가하고, 표적화된 질의로 검색·분석 서브에이전트에 재위임하며, 커버리지가 충분해질 때까지 종합을 재호출하는 반복적 정제(iterative refinement) 루프 구현

· 관측 가능성(observability), 일관된 오류 처리, 통제된 정보 흐름을 위해 모든 서브에이전트 통신을 코디네이터를 거치도록 라우팅

과제 진술 1.3: 서브에이전트 호출, 컨텍스트 전달, 스포닝(spawning) 구성

지식:

· 서브에이전트를 스포닝하는 메커니즘인 Task 도구, 그리고 코디네이터가 서브에이전트를 호출하려면 allowedTools에 "Task"가 포함되어야 한다는 요건

· 서브에이전트 컨텍스트는 프롬프트에 명시적으로 제공되어야 한다는 점 — 서브에이전트는 상위 컨텍스트를 자동으로 물려받거나 호출 간에 메모리를 공유하지 않음

· 각 서브에이전트 유형에 대한 설명, 시스템 프롬프트, 도구 제한을 포함하는 AgentDefinition 구성

· 공유된 분석 기준선에서 서로 다른 접근을 탐색하기 위한 포크(fork) 기반 세션 관리

기술:

· 이전 에이전트의 완전한 발견 사항을 서브에이전트 프롬프트에 직접 포함(예: 웹 검색 결과와 문서 분석 출력을 종합 서브에이전트에 전달)

· 에이전트 간 컨텍스트를 전달할 때 출처(source URL, 문서명, 페이지 번호)를 보존하도록 구조화된 데이터 형식으로 콘텐츠와 메타데이터를 분리

· 여러 턴에 걸치는 대신 단일 코디네이터 응답에서 여러 Task 도구 호출을 발행해 병렬 서브에이전트 스포닝

· 서브에이전트의 적응성을 위해 단계별 절차 지시가 아니라 리서치 목표와 품질 기준을 명시하는 코디네이터 프롬프트 설계

과제 진술 1.4: 강제(enforcement)와 핸드오프 패턴을 갖춘 다단계 워크플로 구현

지식:

· 워크플로 순서를 위한 프로그램적 강제(훅, 선행 조건 게이트)와 프롬프트 기반 안내의 차이

· 결정론적 준수가 필요할 때(예: 금융 작업 전 신원 확인) 프롬프트 지시만으로는 0이 아닌 실패율을 갖는다는 점

· 고객 정보, 근본 원인 분석, 권장 조치를 포함하는, 처리 도중 에스컬레이션을 위한 구조화된 핸드오프 프로토콜

기술:

· 선행 단계가 완료될 때까지 하위 도구 호출을 차단하는 프로그램적 선행 조건 구현(예: get_customer가 확인된 고객 ID를 반환하기 전까지 process_refund 차단)

· 다중 관심사 고객 요청을 개별 항목으로 분해한 뒤, 공유 컨텍스트를 사용해 각 항목을 병렬로 조사하고 통합된 해결안으로 종합

· 대화 기록에 접근할 수 없는 인간 상담원에게 에스컬레이션할 때 구조화된 핸드오프 요약(고객 ID, 근본 원인, 환불 금액, 권장 조치) 작성

과제 진술 1.5: 도구 호출 가로채기와 데이터 정규화를 위한 Agent SDK 훅 적용

지식:

· 모델이 처리하기 전에 도구 결과를 가로채 변환하는 훅 패턴(예: PostToolUse)

· 규정 준수 규칙을 강제하기 위해 나가는 도구 호출을 가로채는 훅 패턴(예: 임계값을 넘는 환불 차단)

· 결정론적 보장을 위해 훅을 쓰는 것과 확률적 준수를 위해 프롬프트 지시에 의존하는 것의 구분

기술:

· 서로 다른 MCP 도구에서 나온 이질적 데이터 형식(Unix 타임스탬프, ISO 8601, 숫자 상태 코드)을 에이전트가 처리하기 전에 정규화하는 PostToolUse 훅 구현

· 정책을 위반하는 조치(예: 500달러를 초과하는 환불)를 차단하고 대체 워크플로(예: 인간 에스컬레이션)로 우회시키는 도구 호출 가로채기 훅 구현

· 비즈니스 규칙이 보장된 준수를 요구할 때 프롬프트 기반 강제 대신 훅 선택

과제 진술 1.6: 복잡한 워크플로를 위한 과제 분해 전략 설계

지식:

· 고정된 순차 파이프라인(프롬프트 체이닝)과 중간 발견 사항에 근거한 동적 적응형 분해를 각각 언제 쓸지

· 리뷰를 순차 단계로 나누는 프롬프트 체이닝 패턴(예: 각 파일을 개별 분석한 뒤 파일 간 통합 패스 수행)

· 각 단계에서 발견한 내용에 따라 하위 과제를 생성하는 적응형 조사 계획의 가치

기술:

· 워크플로에 맞는 과제 분해 패턴 선택: 예측 가능한 다면 리뷰에는 프롬프트 체이닝, 개방형 조사 과제에는 동적 분해

· 주의 분산(attention dilution)을 피하기 위해 대규모 코드 리뷰를 파일별 지역 분석 패스와 별도의 파일 간 통합 패스로 분리

· 개방형 과제(예: "레거시 코드베이스에 종합 테스트 추가")를 먼저 구조를 파악하고, 영향이 큰 영역을 식별한 다음, 의존성이 드러남에 따라 조정되는 우선순위 계획을 세워 분해

과제 진술 1.7: 세션 상태, 재개, 포킹 관리

지식:

· 특정 이전 대화를 이어가기 위한 --resume <session-name>을 이용한 명명 세션 재개

· 공유된 분석 기준선에서 독립적인 분기를 만들어 서로 다른 접근을 탐색하는 fork_session

· 코드 수정 이후 세션을 재개할 때, 앞서 분석한 파일의 변경 사항을 에이전트에 알리는 것의 중요성

· 오래된 도구 결과로 재개하는 것보다 구조화된 요약으로 새 세션을 시작하는 편이 더 신뢰할 수 있는 이유

기술:

· 명명된 조사 세션을 여러 작업 세션에 걸쳐 이어가기 위해 세션 이름과 함께 --resume 사용

· 공유된 코드베이스 분석에서 병렬 탐색 분기를 만들기 위해 fork_session 사용(예: 두 가지 테스트 전략이나 리팩터링 접근 비교)

· 이전 컨텍스트가 대체로 유효할 때의 세션 재개와 이전 도구 결과가 오래되었을 때 주입된 요약으로 새로 시작하는 것 사이에서 선택

· 전체 재탐색을 요구하는 대신, 재개한 세션에 특정 파일 변경을 알려 표적 재분석 수행

도메인 2: 도구 설계 및 MCP 통합Domain 2: Tool Design & MCP Integration

과제 진술 2.1: 명확한 설명과 경계를 갖춘 효과적인 도구 인터페이스 설계

지식:

· LLM이 도구를 선택할 때 주된 근거로 삼는 도구 설명 — 설명이 빈약하면 유사한 도구 사이에서 선택이 불안정해짐

· 도구 설명에 입력 형식, 예시 질의, 예외 상황, 경계 설명을 포함하는 것의 중요성

· 모호하거나 겹치는 도구 설명이 잘못된 라우팅(misrouting)을 유발하는 방식(예: 거의 동일한 설명을 가진 analyze_content 대 analyze_document)

· 시스템 프롬프트 문구가 도구 선택에 미치는 영향: 키워드에 민감한 지시가 의도치 않은 도구 연상을 만들 수 있음

기술:

· 각 도구의 목적, 기대 입력, 출력, 그리고 유사한 대안 대비 언제 써야 하는지를 명확히 구별하는 도구 설명 작성

· 기능 중복을 없애기 위해 도구 이름을 바꾸고 설명을 갱신(예: analyze_content를 웹 특화 설명과 함께 extract_web_results로 개명)

· 범용 도구를 정의된 입출력 계약을 갖춘 목적별 도구로 분할(예: 범용 analyze_document를 extract_data_points, summarize_content, verify_claim_against_source로 분할)

· 잘 작성된 도구 설명을 덮어쓸 수 있는 키워드 민감 지시가 있는지 시스템 프롬프트 검토

과제 진술 2.2: MCP 도구를 위한 구조화된 오류 응답 구현

지식:

· 도구 실패를 에이전트에 다시 전달하는 MCP isError 플래그 패턴

· 일시적 오류(타임아웃, 서비스 이용 불가), 검증 오류(잘못된 입력), 비즈니스 오류(정책 위반), 권한 오류의 구분

· 획일적 오류 응답(일반적인 "작업 실패")이 에이전트의 적절한 복구 결정을 가로막는 이유

· 재시도 가능한 오류와 재시도 불가능한 오류의 차이, 그리고 구조화된 메타데이터 반환이 헛된 재시도를 방지하는 방식

기술:

· errorCategory(transient/validation/permission), isRetryable 불리언, 사람이 읽을 수 있는 설명을 포함한 구조화된 오류 메타데이터 반환

· 에이전트가 적절히 소통할 수 있도록 비즈니스 규칙 위반에 대해 retriable: false 플래그와 고객 친화적 설명 포함

· 일시적 실패에 대해서는 서브에이전트 내부에서 지역 오류 복구를 구현하고, 지역에서 해결할 수 없는 오류만 부분 결과 및 시도 내역과 함께 코디네이터로 전파

· 재시도 결정이 필요한 접근 실패와, 일치 결과가 없는 성공적 질의를 나타내는 유효한 빈 결과를 구분

과제 진술 2.3: 에이전트 전반에 도구를 적절히 분배하고 tool_choice 구성

지식:

· 에이전트에 너무 많은 도구(예: 4~5개가 아니라 18개)를 주면 결정 복잡도가 커져 도구 선택 신뢰성이 떨어진다는 원칙

· 전문 영역 밖의 도구를 가진 에이전트가 그 도구를 오용하는 경향(예: 종합 에이전트가 웹 검색을 시도)

· 범위 지정 도구 접근: 역할에 필요한 도구만 에이전트에 주고, 특정 고빈도 수요를 위한 제한적 교차 역할 도구만 허용

· tool_choice 구성 옵션: "auto", "any", 강제 도구 선택({"type": "tool", "name": "..."})

기술:

· 각 서브에이전트의 도구 집합을 역할과 관련된 것으로 제한해 전문 영역 교차 오용 방지

· 범용 도구를 제약된 대안으로 교체(예: fetch_url을 문서 URL을 검증하는 load_document로 교체)

· 고빈도 수요를 위한 범위 지정 교차 역할 도구를 제공(예: 종합 에이전트를 위한 verify_fact 도구)하면서 복잡한 경우는 코디네이터를 거치도록 라우팅

· 특정 도구가 먼저 호출되도록 tool_choice 강제 선택 사용(예: 보강 도구 전에 extract_metadata를 강제), 이후 단계는 후속 턴에서 처리

· 모델이 대화형 텍스트를 반환하는 대신 반드시 도구를 호출하도록 tool_choice: "any" 설정

과제 진술 2.4: MCP 서버를 Claude Code 및 에이전트 워크플로에 통합

지식:

· MCP 서버 범위: 팀 공유 도구를 위한 프로젝트 수준(.mcp.json) 대 개인/실험용 서버를 위한 사용자 수준(~/.claude.json)

· 비밀 값을 커밋하지 않고 자격 증명을 관리하기 위한 .mcp.json의 환경 변수 확장(예: ${GITHUB_TOKEN})

· 구성된 모든 MCP 서버의 도구가 연결 시점에 발견되어 에이전트에 동시에 제공된다는 점

· 탐색적 도구 호출을 줄이기 위해 콘텐츠 카탈로그(예: 이슈 요약, 문서 계층, 데이터베이스 스키마)를 노출하는 메커니즘으로서의 MCP 리소스

기술:

· 인증 토큰을 위한 환경 변수 확장과 함께 프로젝트 범위 .mcp.json에 공유 MCP 서버 구성

· 개인/실험용 MCP 서버를 사용자 범위 ~/.claude.json에 구성

· 에이전트가 더 유능한 MCP 도구보다 내장 도구(예: Grep)를 선호하지 않도록, 역량과 출력을 상세히 설명하게끔 MCP 도구 설명 보강

· 표준 통합(예: Jira)에는 커스텀 구현보다 기존 커뮤니티 MCP 서버를 선택하고, 커스텀 서버는 팀 특화 워크플로에만 사용

· 탐색적 도구 호출 없이도 에이전트가 가용 데이터를 파악하도록 콘텐츠 카탈로그를 MCP 리소스로 노출

과제 진술 2.5: 내장 도구(Read, Write, Edit, Bash, Grep, Glob) 선택 및 효과적 적용

지식:

· 콘텐츠 검색을 위한 Grep(함수명, 오류 메시지, import 문 같은 패턴을 파일 내용에서 검색)

· 파일 경로 패턴 매칭을 위한 Glob(이름이나 확장자 패턴으로 파일 찾기)

· 전체 파일 작업을 위한 Read/Write, 고유한 텍스트 매칭으로 특정 부분을 수정하는 Edit

· 고유하지 않은 텍스트 매칭 때문에 Edit가 실패할 때, 신뢰할 수 있는 파일 수정을 위한 대안으로 Read + Write 사용

기술:

· 코드베이스 전반의 코드 콘텐츠 검색에 Grep 선택(예: 함수의 모든 호출부 찾기, 오류 메시지 위치 파악)

· 명명 패턴에 맞는 파일 찾기에 Glob 선택(예: **/*.test.tsx)

· Edit가 고유한 앵커 텍스트를 찾지 못할 때 Read로 전체 파일 내용을 불러온 뒤 Write 사용

· 모든 파일을 미리 읽는 대신 Grep으로 진입점을 찾고 Read로 import를 따라가며 흐름을 추적하는 식으로 코드베이스 이해를 점진적으로 구축

· 먼저 export된 모든 이름을 식별한 뒤 각 이름을 코드베이스 전반에서 검색해 래퍼 모듈에 걸친 함수 사용처 추적

도메인 3: Claude Code 구성 및 워크플로Domain 3: Claude Code Configuration & Workflows

과제 진술 3.1: 적절한 계층, 범위, 모듈식 구성을 갖춘 CLAUDE.md 파일 구성

지식:

· CLAUDE.md 구성 계층: 사용자 수준(~/.claude/CLAUDE.md), 프로젝트 수준(.claude/CLAUDE.md 또는 루트 CLAUDE.md), 디렉터리 수준(하위 디렉터리 CLAUDE.md 파일)

· 사용자 수준 설정은 해당 사용자에게만 적용된다는 점 — ~/.claude/CLAUDE.md의 지시는 버전 관리를 통해 팀원과 공유되지 않음

· CLAUDE.md를 모듈식으로 유지하기 위해 외부 파일을 참조하는 @import 문법(예: 각 패키지에 관련된 특정 표준 파일 가져오기)

· 단일 거대 CLAUDE.md의 대안으로 주제별 규칙 파일을 정리하는 .claude/rules/ 디렉터리

기술:

· 구성 계층 문제 진단(예: 지시가 프로젝트 수준이 아니라 사용자 수준 구성에 있어 신규 팀원이 지시를 받지 못하는 경우)

· 관리자의 도메인 지식에 근거해 각 패키지의 CLAUDE.md에 관련 표준 파일을 선택적으로 포함하도록 @import 사용

· 큰 CLAUDE.md 파일을 .claude/rules/의 주제별 집중 파일로 분할(예: testing.md, api-conventions.md, deployment.md)

· 어떤 메모리 파일이 로드되었는지 확인하고 세션 간 일관되지 않은 동작을 진단하기 위해 /memory 명령 사용

과제 진술 3.2: 커스텀 슬래시 명령 및 스킬 생성 및 구성

지식:

· .claude/commands/의 프로젝트 범위 명령(버전 관리로 공유) 대 ~/.claude/commands/의 사용자 범위 명령(개인용)

· context: fork, allowed-tools, argument-hint 등의 프런트매터(frontmatter) 구성을 지원하는 SKILL.md 파일을 갖춘 .claude/skills/의 스킬

· 스킬 출력이 메인 대화를 오염시키지 않도록 스킬을 격리된 서브에이전트 컨텍스트에서 실행하는 context: fork 프런트매터 옵션

· 개인 스킬 커스터마이즈: 팀원에게 영향을 주지 않도록 ~/.claude/skills/에 다른 이름의 개인 변형 생성

기술:

· 버전 관리를 통한 팀 전체 가용성을 위해 .claude/commands/에 프로젝트 범위 슬래시 명령 생성

· 장황한 출력을 내는 스킬(예: 코드베이스 분석)이나 탐색적 컨텍스트(예: 대안 브레인스토밍)를 메인 세션에서 격리하기 위해 context: fork 사용

· 스킬 실행 중 도구 접근을 제한하도록 스킬 프런트매터에 allowed-tools 구성(예: 파괴적 조치를 막기 위해 파일 쓰기 작업으로 제한)

· 인수 없이 스킬을 호출한 개발자에게 필수 매개변수를 안내하도록 argument-hint 프런트매터 사용

· 스킬(과제 특화 워크플로를 위한 온디맨드 호출)과 CLAUDE.md(항상 로드되는 보편 표준) 사이에서 선택

과제 진술 3.3: 조건부 컨벤션 로딩을 위한 경로 특화 규칙 적용

지식:

· 조건부 규칙 활성화를 위한 글롭(glob) 패턴을 담은 YAML 프런트매터 paths 필드를 갖춘 .claude/rules/ 파일

· 경로 범위 규칙이 매칭되는 파일을 편집할 때만 로드되어 불필요한 컨텍스트와 토큰 사용을 줄이는 방식

· 여러 디렉터리에 걸치는 컨벤션(예: 코드베이스 전반에 흩어진 테스트 파일)에 대해 디렉터리 수준 CLAUDE.md보다 글롭 패턴 규칙이 갖는 이점

기술:

· 매칭되는 파일을 편집할 때만 규칙이 로드되도록 YAML 프런트매터 경로 범위 지정으로 .claude/rules/ 파일 생성(예: paths: ["terraform/**/*"])

· 디렉터리 위치와 무관하게 파일 유형별로 컨벤션을 적용하도록 경로 특화 규칙에서 글롭 패턴 사용(예: 모든 테스트 파일에 **/*.test.tsx)

· 컨벤션이 코드베이스 전반에 흩어진 파일에 적용되어야 할 때 하위 디렉터리 CLAUDE.md보다 경로 특화 규칙 선택

과제 진술 3.4: 플랜 모드와 직접 실행을 각각 언제 쓸지 결정

지식:

· 플랜 모드는 대규모 변경, 복수의 타당한 접근, 아키텍처 결정, 다중 파일 수정을 수반하는 복잡한 과제를 위해 설계되었다는 점

· 직접 실행은 단순하고 범위가 명확한 변경(예: 한 함수에 검증 하나 추가)에 적합하다는 점

· 플랜 모드가 변경을 확정하기 전에 안전한 코드베이스 탐색과 설계를 가능케 해 값비싼 재작업을 방지한다는 점

· 장황한 발견 출력을 격리하고 요약을 반환해 메인 대화 컨텍스트를 보존하는 Explore 서브에이전트

기술:

· 아키텍처적 함의가 있는 과제에 플랜 모드 선택(예: 마이크로서비스 재구조화, 45개 이상 파일에 영향을 주는 라이브러리 마이그레이션, 인프라 요건이 다른 통합 접근 사이의 선택)

· 범위가 명확하고 잘 이해된 변경에 직접 실행 선택(예: 스택 트레이스가 분명한 단일 파일 버그 수정, 날짜 검증 조건문 추가)

· 다단계 과제에서 컨텍스트 윈도우 소진을 막기 위해 장황한 발견 단계에 Explore 서브에이전트 사용

· 조사에는 플랜 모드를, 구현에는 직접 실행을 결합(예: 라이브러리 마이그레이션을 계획한 뒤 계획된 접근을 실행)

과제 진술 3.5: 점진적 개선을 위한 반복적 정제 기법 적용

지식:

· 산문 설명이 일관되지 않게 해석될 때, 기대하는 변환을 전달하는 가장 효과적인 방법인 구체적 입출력 예시

· 테스트 주도 반복: 먼저 테스트 스위트를 작성한 뒤 테스트 실패를 공유해 점진적 개선을 이끄는 방식

· 인터뷰 패턴: 구현에 앞서 개발자가 미처 예상하지 못한 고려 사항을 드러내도록 Claude가 질문하게 하는 것

· 모든 문제를 단일 메시지로 제공할지(서로 영향을 주는 문제) 순차적으로 수정할지(독립적 문제)의 판단

기술:

· 자연어 설명이 일관되지 않은 결과를 낼 때, 2~3개의 구체적 입출력 예시로 변환 요건 명확화

· 기대 동작, 예외 상황, 성능 요건을 아우르는 테스트 스위트를 구현 전에 작성한 뒤 테스트 실패를 공유하며 반복

· 낯선 도메인에서 해법을 구현하기 전에 설계 고려 사항(예: 캐시 무효화 전략, 실패 모드)을 드러내기 위해 인터뷰 패턴 사용

· 예외 처리를 바로잡기 위해 예시 입력과 기대 출력을 갖춘 구체적 테스트 케이스 제공(예: 마이그레이션 스크립트의 null 값)

· 수정이 서로 영향을 줄 때는 단일 상세 메시지로 여러 상호작용 문제를 함께 다루고, 독립적 문제에는 순차 반복 적용

과제 진술 3.6: Claude Code를 CI/CD 파이프라인에 통합

지식:

· 자동화 파이프라인에서 Claude Code를 비대화형 모드로 실행하는 -p(또는 --print) 플래그

· CI 맥락에서 구조화 출력을 강제하는 --output-format json 및 --json-schema CLI 플래그

· CI가 호출하는 Claude Code에 프로젝트 컨텍스트(테스트 표준, 픽스처 컨벤션, 리뷰 기준)를 제공하는 메커니즘으로서의 CLAUDE.md

· 세션 컨텍스트 격리: 코드를 생성한 바로 그 Claude 세션이 독립적인 리뷰 인스턴스보다 자기 변경을 검토하는 데 덜 효과적인 이유

기술:

· 대화형 입력 대기를 막기 위해 -p 플래그로 CI에서 Claude Code 실행

· 인라인 PR 코멘트로 자동 게시할 수 있는, 기계가 파싱 가능한 구조화된 발견 사항을 만들기 위해 --output-format json과 --json-schema 사용

· 새 커밋 이후 리뷰를 재실행할 때 이전 리뷰 발견 사항을 컨텍스트에 포함하고, 중복 코멘트를 피하도록 새롭거나 아직 해결되지 않은 이슈만 보고하도록 Claude에 지시

· 테스트 생성이 이미 테스트 스위트가 다루는 시나리오를 중복 제안하지 않도록 기존 테스트 파일을 컨텍스트에 제공

· 테스트 생성 품질을 높이고 가치가 낮은 테스트 출력을 줄이도록 테스트 표준, 가치 있는 테스트 기준, 가용 픽스처를 CLAUDE.md에 문서화

도메인 4: 프롬프트 엔지니어링 및 구조화 출력Domain 4: Prompt Engineering & Structured Output

과제 진술 4.1: 정밀도를 높이고 거짓 양성을 줄이도록 명시적 기준을 갖춘 프롬프트 설계

지식:

· 모호한 지시보다 명시적 기준의 중요성(예: "주석이 정확한지 확인하라"보다 "주장된 동작이 실제 코드 동작과 모순될 때만 주석에 표시하라")

· "보수적으로 하라"나 "높은 신뢰도의 발견만 보고하라" 같은 일반 지시가 구체적 범주 기준에 비해 정밀도 개선에 실패하는 방식

· 거짓 양성률이 개발자 신뢰에 미치는 영향: 거짓 양성이 많은 범주는 정확한 범주에 대한 신뢰까지 무너뜨림

기술:

· 신뢰도 기반 필터링에 의존하기보다, 어떤 이슈를 보고하고(버그, 보안) 어떤 것을 건너뛸지(사소한 스타일, 지역적 패턴) 정의하는 구체적 리뷰 기준 작성

· 거짓 양성이 많은 범주의 프롬프트를 개선하는 동안 개발자 신뢰를 회복하기 위해 해당 범주를 일시적으로 비활성화

· 일관된 분류를 위해 각 심각도 수준마다 구체적 코드 예시를 갖춘 명시적 심각도 기준 정의

과제 진술 4.2: 출력 일관성과 품질을 높이기 위한 퓨샷 프롬프팅 적용

지식:

· 상세한 지시만으로 일관되지 않은 결과가 나올 때, 일관된 형식과 실행 가능한 출력을 얻는 가장 효과적인 기법인 퓨샷 예시

· 모호한 경우의 처리를 시연하는 데서 퓨샷 예시가 맡는 역할(예: 모호한 요청에 대한 도구 선택, 분기 수준 테스트 커버리지 누락)

· 퓨샷 예시가 미리 지정된 경우만 매칭하는 것을 넘어 모델이 새로운 패턴으로 판단을 일반화하게 하는 방식

· 추출 과제에서 환각(hallucination)을 줄이는 데 대한 퓨샷 예시의 효과(예: 비공식 측정값 처리, 다양한 문서 구조)

기술:

· 타당한 대안 대신 특정 조치를 택한 이유의 추론을 보여 주는, 모호한 시나리오용 표적 퓨샷 예시 2~4개 작성

· 일관성을 위해 원하는 출력 형식(위치, 이슈, 심각도, 제안 수정)을 시연하는 퓨샷 예시 포함

· 일반화를 가능케 하면서 거짓 양성을 줄이도록, 허용 가능한 코드 패턴과 실제 이슈를 구별하는 퓨샷 예시 제공

· 다양한 문서 구조(인라인 인용 대 참고문헌, 방법론 절 대 본문에 삽입된 세부)를 올바로 처리하도록 퓨샷 예시 활용

· 필수 필드의 빈/null 추출을 해소하기 위해, 다양한 형식의 문서에서 올바른 추출을 보여 주는 퓨샷 예시 추가

과제 진술 4.3: 도구 사용과 JSON 스키마를 이용한 구조화 출력 강제

지식:

· JSON 구문 오류를 없애고 스키마를 보장 준수하는 구조화 출력을 얻는 가장 신뢰할 수 있는 방법인, JSON 스키마를 갖춘 도구 사용(tool_use)

· tool_choice: "auto"(모델이 도구 호출 대신 텍스트를 반환할 수 있음), "any"(모델이 반드시 도구를 호출하되 어느 것인지는 선택 가능), 강제 도구 선택(모델이 지정된 특정 도구를 반드시 호출)의 구분

· 도구 사용을 통한 엄격한 JSON 스키마가 구문 오류는 없애지만 의미 오류(예: 총합과 맞지 않는 항목 금액, 잘못된 필드의 값)는 막지 못한다는 점

· 스키마 설계 고려 사항: 필수 필드 대 선택 필드, 확장 가능한 범주를 위한 "other" + 상세 문자열 패턴을 갖춘 enum 필드

기술:

· JSON 스키마를 입력 매개변수로 갖는 추출 도구를 정의하고 tool_use 응답에서 구조화 데이터 추출

· 여러 추출 스키마가 있고 문서 유형을 알 수 없을 때 구조화 출력을 보장하도록 tool_choice: "any" 설정

· 보강 단계 전에 특정 추출이 먼저 실행되도록 tool_choice: {"type": "tool", "name": "extract_metadata"}로 특정 도구 강제

· 원본 문서에 정보가 없을 수 있을 때 스키마 필드를 선택(nullable)으로 설계해, 모델이 필수 필드를 채우려 값을 지어내는 것을 방지

· 모호한 경우를 위한 "unclear" 같은 enum 값과, 확장 가능한 분류를 위한 "other" + 상세 필드 추가

· 일관되지 않은 원본 형식을 처리하도록 엄격한 출력 스키마와 함께 프롬프트에 형식 정규화 규칙 포함

과제 진술 4.4: 추출 품질을 위한 검증, 재시도, 피드백 루프 구현

지식:

· 오류 피드백을 곁들인 재시도: 재시도 시 특정 검증 오류를 프롬프트에 덧붙여 모델을 교정으로 유도

· 재시도의 한계: 필요한 정보가 원본 문서에 아예 없을 때(형식·구조 오류와 달리) 재시도는 효과가 없음

· 피드백 루프 설계: 어떤 코드 구성이 발견을 유발하는지(detected_pattern 필드)를 추적해 기각 패턴의 체계적 분석 가능

· 의미 검증 오류(값이 합산되지 않음, 잘못된 필드 배치)와 (도구 사용으로 제거되는) 스키마 구문 오류의 차이

기술:

· 모델의 자기 교정을 위해 원본 문서, 실패한 추출, 특정 검증 오류를 포함하는 후속 요청 구현

· 재시도가 효과 없을 때(예: 정보가 제공되지 않은 외부 문서에만 존재)와 성공할 때(형식 불일치, 구조적 출력 오류)를 식별

· 개발자가 발견을 기각할 때 거짓 양성 패턴을 분석할 수 있도록 구조화된 발견에 detected_pattern 필드 추가

· 자기 교정 검증 흐름 설계: "stated_total"과 함께 "calculated_total"을 추출해 불일치를 표시하고, 원본 데이터가 불일치할 때 "conflict_detected" 불리언 추가

과제 진술 4.5: 효율적인 배치(batch) 처리 전략 설계

지식:

· Message Batches API: 50% 비용 절감, 최대 24시간 처리 창(window), 지연 시간 보장(SLA) 없음

· 배치 처리는 비차단·지연 허용 워크로드(야간 리포트, 주간 감사, 야간 테스트 생성)에 적합하고 차단형 워크플로(병합 전 검사)에는 부적합하다는 점

· 배치 API는 단일 요청 내 멀티턴 도구 호출을 지원하지 않는다는 점(요청 도중 도구를 실행해 결과를 반환할 수 없음)

· 배치 요청/응답 쌍을 상관 짓기 위한 custom_id 필드

기술:

· 워크플로의 지연 요건에 API 방식을 맞추기: 차단형 병합 전 검사에는 동기 API, 야간/주간 분석에는 배치 API

· SLA 제약에 근거해 배치 제출 빈도 계산(예: 24시간 배치 처리로 30시간 SLA를 보장하기 위한 4시간 창)

· 배치 실패 처리: 실패한 문서만(custom_id로 식별) 적절한 수정(예: 컨텍스트 한도를 초과한 문서 청킹)과 함께 재제출

· 대량 배치 처리 전 표본 집합에 프롬프트 정제를 적용해 첫 패스 성공률을 최대화하고 반복 재제출 비용 절감

과제 진술 4.6: 다중 인스턴스 및 다중 패스 리뷰 아키텍처 설계

지식:

· 자기 리뷰의 한계: 모델이 생성 시의 추론 컨텍스트를 유지하고 있어 같은 세션에서 자기 결정을 의심할 가능성이 낮음

· (이전 추론 컨텍스트가 없는) 독립적 리뷰 인스턴스가 자기 리뷰 지시나 확장 사고보다 미묘한 이슈를 더 잘 잡아냄

· 다중 패스 리뷰: 주의 분산과 상충되는 발견을 피하기 위해 대규모 리뷰를 파일별 지역 분석 패스와 파일 간 통합 패스로 분리

기술:

· 생성기의 추론 컨텍스트 없이 생성된 코드를 검토하도록 두 번째 독립 Claude 인스턴스 사용

· 대규모 다중 파일 리뷰를 지역 이슈용 파일별 집중 패스와 파일 간 데이터 흐름 분석용 별도 통합 패스로 분리

· 보정된 리뷰 라우팅을 가능케 하도록, 모델이 각 발견과 함께 신뢰도를 자기 보고하는 검증 패스 실행

도메인 5: 컨텍스트 관리 및 신뢰성Domain 5: Context Management & Reliability

과제 진술 5.1: 긴 상호작용 전반에서 핵심 정보를 보존하도록 대화 컨텍스트 관리

지식:

· 점진적 요약의 위험: 수치, 백분율, 날짜, 고객이 진술한 기대를 모호한 요약으로 압축

· "중간 소실(lost in the middle)" 효과: 모델이 긴 입력의 처음과 끝은 안정적으로 처리하지만 중간 부분의 발견은 누락할 수 있음

· 도구 결과가 컨텍스트에 누적되어 관련성에 비해 토큰을 과도하게 소비하는 방식(예: 관련 필드가 5개뿐인데도 주문 조회당 40개 이상 필드)

· 대화의 일관성을 유지하려면 이후 API 요청에 완전한 대화 이력을 전달하는 것의 중요성

기술:

· 거래 관련 사실(금액, 날짜, 주문 번호, 상태)을 요약된 이력과 별도로 각 프롬프트에 포함되는 지속적 "케이스 사실(case facts)" 블록으로 추출

· 다중 이슈 세션을 위해 구조화된 이슈 데이터(주문 ID, 금액, 상태)를 별도의 컨텍스트 계층으로 추출·유지

· 장황한 도구 출력이 컨텍스트에 누적되기 전에 관련 필드만 남기도록 정리(예: 주문 조회에서 반품 관련 필드만 유지)

· 위치 효과를 완화하도록 핵심 발견 요약을 집계 입력의 앞부분에 배치하고 상세 결과를 명시적 절 제목으로 정리

· 정확한 하위 종합을 지원하도록 서브에이전트가 구조화 출력에 메타데이터(날짜, 출처 위치, 방법론적 맥락)를 포함하게 요구

· 하위 에이전트의 컨텍스트 예산이 제한적일 때 상위 에이전트가 장황한 콘텐츠와 추론 사슬 대신 구조화 데이터(핵심 사실, 인용, 관련성 점수)를 반환하도록 수정

과제 진술 5.2: 효과적인 에스컬레이션 및 모호성 해소 패턴 설계

지식:

· 적절한 에스컬레이션 트리거: 고객의 인간 상담원 요청, 정책 예외/공백(단지 복잡한 경우가 아니라), 그리고 유의미한 진전을 이룰 수 없음

· 고객이 명시적으로 요구할 때 즉시 에스컬레이션하는 것과, 이슈가 단순할 때 해결을 제안하는 것의 구분

· 감정 기반 에스컬레이션과 자기 보고 신뢰도 점수가 실제 사안 복잡도의 신뢰할 수 없는 대용 지표인 이유

· 여러 고객이 일치할 때 휴리스틱 선택이 아니라 (추가 식별자를 요청하는) 명확화가 필요한 이유

기술:

· 언제 에스컬레이션하고 언제 자율 해결할지 시연하는 퓨샷 예시와 함께 명시적 에스컬레이션 기준을 시스템 프롬프트에 추가

· 먼저 조사하지 않고 인간 상담원에 대한 고객의 명시적 요청을 즉시 존중

· 이슈가 에이전트의 역량 범위 안일 때는 불만을 인정하면서 해결을 제안하고, 고객이 선호를 재차 밝힐 때만 에스컬레이션

· 정책이 고객의 특정 요청에 대해 모호하거나 침묵할 때 에스컬레이션(예: 정책이 자사 사이트 조정만 다루는데 경쟁사 가격 매칭 요청)

· 도구 결과가 여러 일치를 반환할 때 휴리스틱으로 선택하는 대신 추가 식별자를 요청하도록 에이전트에 지시

과제 진술 5.3: 멀티 에이전트 시스템 전반의 오류 전파 전략 구현

지식:

· 지능적 코디네이터 복구 결정을 가능케 하는 구조화된 오류 맥락(실패 유형, 시도한 질의, 부분 결과, 대안 접근)

· 접근 실패(재시도 결정이 필요한 타임아웃)와 유효한 빈 결과(일치가 없는 성공적 질의)의 구분

· 일반적 오류 상태("검색 이용 불가")가 코디네이터로부터 가치 있는 맥락을 숨기는 이유

· 오류를 조용히 억누르는 것(빈 결과를 성공으로 반환)과 단일 실패에 전체 워크플로를 종료하는 것이 둘 다 안티패턴인 이유

기술:

· 코디네이터의 복구를 가능케 하도록 실패 유형, 시도 내역, 부분 결과, 잠재적 대안을 포함하는 구조화된 오류 맥락 반환

· 코디네이터가 적절히 결정하도록 오류 보고에서 접근 실패와 유효한 빈 결과를 구분

· 서브에이전트가 일시적 실패에 대해 지역 복구를 구현하고, 해결할 수 없는 오류만 시도 내역과 부분 결과와 함께 전파

· 어떤 발견이 근거가 충분한지와 어떤 주제 영역이 출처 부재로 공백이 있는지를 표시하는 커버리지 주석과 함께 종합 출력 구조화

과제 진술 5.4: 대규모 코드베이스 탐색에서 컨텍스트를 효과적으로 관리

지식:

· 장기 세션에서의 컨텍스트 저하: 모델이 일관되지 않은 답을 내기 시작하고 앞서 발견한 구체적 클래스가 아니라 "전형적 패턴"을 참조함

· 컨텍스트 경계를 넘어 핵심 발견을 유지하기 위한 스크래치패드(scratchpad) 파일의 역할

· 메인 에이전트가 상위 이해를 조율하는 동안 장황한 탐색 출력을 격리하는 서브에이전트 위임

· 크래시 복구를 위한 구조화된 상태 유지: 각 에이전트가 알려진 위치에 상태를 내보내고, 코디네이터가 재개 시 매니페스트(manifest)를 로드

기술:

· 메인 에이전트가 상위 조율을 유지하는 동안 특정 질문(예: "모든 테스트 파일 찾기", "환불 흐름 의존성 추적")을 조사하도록 서브에이전트 스포닝

· 컨텍스트 저하에 대응하도록 에이전트가 핵심 발견을 기록하는 스크래치패드 파일을 유지하고 이후 질문에서 이를 참조

· 다음 단계의 서브에이전트를 스포닝하기 전에 한 탐색 단계의 핵심 발견을 요약하고, 초기 컨텍스트에 요약 주입

· 코디네이터가 재개 시 로드해 에이전트 프롬프트에 주입하는 구조화된 에이전트 상태 내보내기(매니페스트)로 크래시 복구 설계

· 장황한 발견으로 컨텍스트가 가득 차는 장기 탐색 세션에서 컨텍스트 사용을 줄이기 위해 /compact 사용

과제 진술 5.5: 인간 검토 워크플로와 신뢰도 보정 설계

지식:

· 종합 정확도 지표(예: 전체 97%)가 특정 문서 유형이나 필드의 저조한 성능을 가릴 수 있는 위험

· 고신뢰 추출의 오류율 측정과 새로운 오류 패턴 탐지를 위한 층화 무작위 표집(stratified random sampling)

· 검토 주의를 라우팅하기 위해 레이블된 검증 집합으로 보정한 필드 수준 신뢰도 점수

· 고신뢰 추출을 자동화하기 전에 문서 유형과 필드 구간별로 정확도를 검증하는 것의 중요성

기술:

· 지속적 오류율 측정과 새로운 패턴 탐지를 위해 고신뢰 추출의 층화 무작위 표집 구현

· 인간 검토를 줄이기 전에 모든 구간에서 일관된 성능을 확인하도록 문서 유형과 필드별로 정확도 분석

· 모델이 필드 수준 신뢰도 점수를 출력하게 한 뒤 레이블된 검증 집합으로 검토 임계값 보정

· 제한된 검토자 역량의 우선순위를 정하도록, 모델 신뢰도가 낮거나 원본이 모호/모순되는 추출을 인간 검토로 라우팅

과제 진술 5.6: 다중 출처 종합에서 정보 출처를 보존하고 불확실성 처리

지식:

· 발견이 출처-주장 매핑을 보존하지 않은 채 압축될 때 요약 단계에서 출처 귀속이 사라지는 방식

· 종합 에이전트가 발견을 결합할 때 반드시 보존·병합해야 하는 구조화된 주장-출처 매핑의 중요성

· 신뢰할 만한 출처들의 상충하는 통계를 처리하는 법: 한 값을 임의로 고르는 대신 출처 귀속과 함께 상충을 주석 처리

· 시간 데이터: 시간적 차이가 모순으로 오해되지 않도록 구조화 출력에 발행/수집 날짜를 요구

기술:

· 하위 에이전트가 종합을 거쳐 보존하는 구조화된 주장-출처 매핑(출처 URL, 문서명, 관련 발췌)을 서브에이전트가 출력하도록 요구

· 정립된 발견과 논쟁적인 발견을 구분하는 명시적 절로 보고서를 구조화하고, 원 출처의 표현과 방법론적 맥락을 보존

· 코디네이터가 종합에 넘기기 전에 조정 방식을 결정하도록, 상충하는 값을 포함하고 명시적으로 주석 처리한 채 문서 분석 완료

· 올바른 시간적 해석이 가능하도록 서브에이전트가 구조화 출력에 발행 또는 데이터 수집 날짜를 포함하게 요구

· 종합 출력에서 콘텐츠 유형을 적절히 렌더링 — 금융 데이터는 표로, 뉴스는 산문으로, 기술적 발견은 구조화 목록으로 — 모든 것을 획일적 형식으로 변환하지 않음

준비 방법How to Prepare

이 자격 시험을 준비하려면:

· Claude Agent SDK로 에이전트 구축: 도구 호출, 오류 처리, 세션 관리를 갖춘 완전한 에이전트 루프를 구현하십시오. 서브에이전트를 스포닝하고 그 사이에 컨텍스트를 전달하는 연습을 하십시오.

· 실제 프로젝트에 Claude Code 구성: 구성 계층을 갖춘 CLAUDE.md를 설정하고, .claude/rules/에 경로 특화 규칙을 만들며, 프런트매터 옵션(context: fork, allowed-tools)을 갖춘 커스텀 스킬을 구축하고, 최소 하나의 MCP 서버를 통합하십시오.

· MCP 도구 설계 및 테스트: 유사한 도구를 명확히 구별하는 도구 설명을 작성하십시오. 오류 범주와 재시도 가능 플래그를 갖춘 구조화된 오류 응답을 구현하십시오. 모호한 요청으로 도구 선택 신뢰성을 테스트하십시오.

· 구조화 데이터 추출 파이프라인 구축: JSON 스키마와 함께 tool_use를 사용하고, 검증-재시도 루프를 구현하며, 선택/nullable 필드로 스키마를 설계하고, Message Batches API로 배치 처리를 연습하십시오.

· 프롬프트 엔지니어링 기법 연습: 모호한 시나리오용 퓨샷 예시를 작성하십시오. 거짓 양성을 줄이도록 명시적 리뷰 기준을 정의하십시오. 대규모 코드 리뷰를 위한 다중 패스 리뷰 아키텍처를 설계하십시오.

· 컨텍스트 관리 패턴 학습: 장황한 도구 출력에서 구조화된 사실을 추출하고, 장기 세션을 위한 스크래치패드 파일을 구현하며, 컨텍스트 한도를 관리하는 서브에이전트 위임을 설계하는 연습을 하십시오.

· 에스컬레이션과 휴먼 인 더 루프 패턴 검토: 언제 에스컬레이션할지(정책 공백, 고객 요청, 진전 불가) 대 언제 자율 해결할지 이해하십시오. 신뢰도 기반 라우팅을 갖춘 인간 검토 워크플로 설계를 연습하십시오.

준비 실습Preparation Exercises

시험에서 다루는 주제에 대한 실무 친숙도를 쌓도록 아래 실습 과제를 완료하십시오. 각 과제는 하나 이상의 시험 도메인에 걸친 지식을 강화하도록 설계되었습니다.

실습 1: 에스컬레이션 로직을 갖춘 다중 도구 에이전트 구축

목표: 도구 통합, 구조화된 오류 처리, 에스컬레이션 패턴을 갖춘 에이전트 루프 설계 연습.

단계:

· 각 도구의 목적, 기대 입력, 경계 조건을 명확히 구별하는 상세 설명을 갖춘 MCP 도구 3~4개를 정의하십시오. 선택 혼동을 피하려면 신중한 설명이 필요한, 기능이 유사한 도구를 최소 둘 포함하십시오.

· 도구 실행을 계속할지 최종 응답을 제시할지 판단하도록 stop_reason을 점검하는 에이전트 루프를 구현하십시오. "tool_use"와 "end_turn" 두 종료 사유를 모두 올바로 처리하십시오.

· 도구에 구조화된 오류 응답을 추가하십시오: errorCategory(transient/validation/permission), isRetryable 불리언, 사람이 읽을 수 있는 설명을 포함하십시오. 에이전트가 각 오류 유형을 적절히 처리하는지(일시적 오류는 재시도, 비즈니스 오류는 사용자에게 설명) 테스트하십시오.

· 도구 호출을 가로채 비즈니스 규칙을 강제하는(예: 임계 금액을 넘는 작업 차단) 프로그램적 훅을 구현하고, 트리거될 때 에스컬레이션 워크플로로 우회시키십시오.

· 다중 관심사 메시지(예: 여러 이슈가 얽힌 요청)로 테스트해 에이전트가 요청을 분해하고, 각 관심사를 처리하며, 통합된 응답으로 종합하는지 확인하십시오.

강화 도메인: 도메인 1(에이전트 아키텍처 및 오케스트레이션), 도메인 2(도구 설계 및 MCP 통합), 도메인 5(컨텍스트 관리 및 신뢰성)

실습 2: 팀 개발 워크플로를 위한 Claude Code 구성

목표: 다중 개발자 프로젝트를 위한 CLAUDE.md 계층, 커스텀 슬래시 명령, 경로 특화 규칙, MCP 서버 통합 구성 연습.

단계:

· 보편 코딩 표준과 테스트 컨벤션을 담은 프로젝트 수준 CLAUDE.md를 생성하십시오. 프로젝트 수준에 둔 지시가 모든 팀원에게 일관되게 적용되는지 확인하십시오.

· 서로 다른 코드 영역에 대해 YAML 프런트매터 글롭 패턴을 갖춘 .claude/rules/ 파일을 생성하십시오(예: API 컨벤션에 paths: ["src/api/**/*"], 테스트 컨벤션에 paths: ["**/*.test.*"]). 매칭되는 파일을 편집할 때만 규칙이 로드되는지 테스트하십시오.

· context: fork와 allowed-tools 제한을 갖춘 프로젝트 범위 스킬을 .claude/skills/에 생성하십시오. 스킬이 메인 대화 컨텍스트를 오염시키지 않고 격리 실행되는지 확인하십시오.

· 자격 증명을 위한 환경 변수 확장과 함께 .mcp.json에 MCP 서버를 구성하십시오. ~/.claude.json에 개인 실험용 MCP 서버를 추가하고 둘 다 동시에 제공되는지 확인하십시오.

· 복잡도가 다른 과제에서 플랜 모드와 직접 실행을 테스트하십시오: 단일 파일 버그 수정, 다중 파일 라이브러리 마이그레이션, 복수의 타당한 구현 접근이 있는 신규 기능. 플랜 모드가 언제 가치를 주는지 관찰하십시오.

강화 도메인: 도메인 3(Claude Code 구성 및 워크플로), 도메인 2(도구 설계 및 MCP 통합)

실습 3: 구조화 데이터 추출 파이프라인 구축

목표: JSON 스키마 설계, 구조화 출력을 위한 tool_use 사용, 검증-재시도 루프 구현, 배치 처리 전략 설계 연습.

단계:

· 필수·선택 필드, "other" + 상세 문자열 패턴을 갖춘 enum, 원본 문서에 없을 수 있는 정보를 위한 nullable 필드를 담은 JSON 스키마로 추출 도구를 정의하십시오. 일부 필드가 없는 문서를 처리해 모델이 값을 지어내지 않고 null을 반환하는지 확인하십시오.

· 검증-재시도 루프를 구현하십시오: Pydantic 또는 JSON 스키마 검증이 실패하면 문서, 실패한 추출, 특정 검증 오류를 포함한 후속 요청을 보내십시오. 어떤 오류가 재시도로 해결 가능한지(형식 불일치)와 그렇지 않은지(정보가 원본에 없음)를 추적하십시오.

· 다양한 형식(예: 인라인 인용 대 참고문헌, 서술형 설명 대 구조화된 표)의 문서에서 추출을 시연하는 퓨샷 예시를 추가하고 구조적 다양성의 처리가 개선되는지 확인하십시오.

· 배치 처리 전략을 설계하십시오: Message Batches API로 문서 100개 배치를 제출하고, custom_id로 실패를 처리하며, 실패 문서를 수정(예: 크기가 큰 문서 청킹)해 재제출하고, SLA 제약 대비 총 처리 시간을 계산하십시오.

· 인간 검토 라우팅 전략을 구현하십시오: 모델이 필드 수준 신뢰도 점수를 출력하게 하고, 저신뢰 추출을 인간 검토로 라우팅하며, 일관된 성능을 확인하도록 문서 유형과 필드별로 정확도를 분석하십시오.

강화 도메인: 도메인 4(프롬프트 엔지니어링 및 구조화 출력), 도메인 5(컨텍스트 관리 및 신뢰성)

실습 4: 멀티 에이전트 리서치 파이프라인 설계 및 디버깅

목표: 서브에이전트 오케스트레이션, 컨텍스트 전달 관리, 오류 전파 구현, 출처 추적을 갖춘 종합 처리 연습.

단계:

· 최소 두 서브에이전트(예: 웹 검색과 문서 분석)에 위임하는 코디네이터 에이전트를 구축하십시오. 코디네이터의 allowedTools에 "Task"가 포함되고, 각 서브에이전트가 자동 컨텍스트 상속에 의존하지 않고 리서치 발견을 프롬프트로 직접 받도록 하십시오.

· 코디네이터가 단일 응답에서 여러 Task 도구 호출을 발행하게 해 병렬 서브에이전트 실행을 구현하십시오. 순차 실행 대비 지연 개선을 측정하십시오.

· 콘텐츠와 메타데이터를 분리하는 서브에이전트 구조화 출력을 설계하십시오: 각 발견에는 주장, 근거 발췌, 출처 URL/문서명, 발행 날짜가 포함되어야 합니다. 종합 서브에이전트가 발견을 결합할 때 출처 귀속을 보존하는지 확인하십시오.

· 오류 전파를 구현하십시오: 서브에이전트 타임아웃을 시뮬레이션해 코디네이터가 구조화된 오류 맥락(실패 유형, 시도한 질의, 부분 결과)을 받는지 확인하십시오. 코디네이터가 부분 결과로 진행하고 최종 출력에 커버리지 공백을 주석 처리할 수 있는지 테스트하십시오.

· 상충하는 출처 데이터(예: 통계가 다른 두 신뢰할 만한 출처)로 테스트해, 종합 출력이 한 값을 임의로 고르는 대신 두 값을 출처 귀속과 함께 보존하고, 정립된 발견과 논쟁적인 발견을 구분하도록 보고서를 구조화하는지 확인하십시오.

강화 도메인: 도메인 1(에이전트 아키텍처 및 오케스트레이션), 도메인 2(도구 설계 및 MCP 통합), 도메인 5(컨텍스트 관리 및 신뢰성)

시험 채점 방식How the Exam Is Scored

Claude Certified Architect – Foundations 시험은 준거참조(criterion-referenced) 평가입니다. 각 응시자는 다른 응시자가 아니라 고정된 수행 기준에 견주어 측정됩니다. 동료 중 일정 비율을 앞지르는 것이 아니라, 블루프린트에 정의된 지식과 기술을 입증함으로써 합격합니다.

합격 기준. 합격 점수는 훈련된 주제 전문가(subject matter expert)가 최소 자격 응시자(minimally qualified candidate)에게 기대되는 수행 수준을 판정한 공식 표준 설정 연구(standard-setting study)를 통해 정해졌습니다. 점수는 100~1,000의 환산 범위로 보고되며, 합격선(cut score)은 720입니다. 환산 점수 모형은 난이도가 다소 다를 수 있는 여러 시험 양식 간 점수를 등화(equate)하는 데 도움이 됩니다.

결과 보고. 결과는 100에서 1,000까지의 환산 점수와 함께 합격 또는 불합격 상태로 보고됩니다. 점수 보고서에는 각 콘텐츠 도메인에서 맞힌 문항의 백분율도 표시됩니다. 구간별 백분율은 자신의 수행을 이해하는 데 도움을 주기 위해 제공되며, 합격/불합격 판정에는 사용되지 않습니다. 판정은 총 환산 점수에 근거합니다.

등록 및 일정 예약Registration and Scheduling

등록과 일정 예약은 Anthropic Partner Academy와 Pearson VUE를 통해 처리됩니다:

· Anthropic Partner Academy에서 응시할 시험의 자격 페이지로 이동해 시험 세부 사항을 검토하십시오.

· Exam Guide를 내려받고, 등록 전에 자격 약관(Certification Terms and Conditions)과 자격 시험 정책(Certification Exam Policy)을 검토하십시오.

· 시험을 등록하고 결제를 완료하십시오. 결제 시 표시되는 요금은 파트너 등급에 적용되는 할인을 반영합니다.

· 확인 안내에 따라 Pearson VUE 계정을 생성한 뒤, 로그인하여 시험 세션 일정을 예약하십시오.

· 가능한 날짜를 선택하고 온라인 프록터링 또는 Pearson 시험 센터 중 하나를 고르십시오. 시험은 Pearson VUE가 제공합니다.

· 예약 시각 24시간 전까지 취소 또는 일정 변경이 가능합니다. 24시간 이내의 변경은 시험 응시료를 상실합니다.

시험 정책Exam Policies

신원 확인

시험 당일 유효하고 기한이 지나지 않은 정부 발급 사진 신분증을 제시해야 합니다. 신분증의 이름은 등록 이름과 정확히 일치해야 합니다. 등록 이름을 정정해야 한다면, 시험 일정을 예약하기 전에 certifications-support@anthropic.com으로 연락하십시오.

편의 제공

문서화된 장애나 필요가 있는 응시자에게는 관련 법률에 따라 합리적 편의(accommodation)가 제공됩니다. 편의는 시험 일정을 예약하기 전에 Pearson VUE의 요청·승인을 받아야 합니다. 요청이 승인될 때까지 예약을 하지 마십시오. 편의는 pearsonvue.com/us/en/test-takers/accommodations에서 요청하십시오.

재응시 정책

불합격한 응시자는 필수 대기 기간이 지난 뒤 재응시할 수 있습니다. 대기 기간은 실패할 때마다 늘어납니다: 첫 실패 후 14일, 두 번째 후 30일, 세 번째 후 90일. 12개월의 이동 기간(rolling twelve-month period) 내에 한 시험을 최대 4회까지 응시할 수 있습니다. 한도는 시험별로 적용되므로, 한 시험에 불합격해도 다른 시험 등록은 막히지 않습니다. 시험 응시료는 매 응시마다 적용됩니다.

미출석 및 지각

예약한 시험에 출석하지 않거나 허용된 지각 시간 이후에 도착한 응시자는 시험 응시료를 상실하고 재등록해야 합니다. 취소 및 일정 변경 기한은 11절에 설명되어 있습니다.

시험 당일 경험 및 행동 규칙Exam-Day Experience and Rules of Conduct

시험은 표준화되고 보안이 유지되는 프록터링 환경에서 시행됩니다. 온라인으로 응시하든 Pearson VUE 시험 센터에서 응시하든, 이 자격을 보유한 모든 사람을 위해 자격의 무결성을 보호하고자 다음 규칙이 적용됩니다.

시험 중 다음을 지켜야 합니다:

· 온라인 응시라면 세션 내내 프록터와 웹캠 시야 안에 머무를 것

· 노트, 책, 휴대폰, 보조 모니터 등 자료가 없도록 작업 공간을 정돈할 것

· 시험 중 다른 사람과 소통하지 말 것

· 어떤 형태로도 시험 내용을 캡처, 복사, 촬영, 복제하지 말 것

금지 물품에는 휴대폰, 스마트워치, 헤드폰, 학습 자료, 모든 녹음 장치가 포함됩니다. 프록터가 제공하는 연습 용지 등 허용 물품이 있다면 Pearson VUE가 명시합니다.

부정행위의 결과. 부정행위, 금지된 자료 접근 시도, 시험 내용 유출은 결과 무효, 자격 취소, 향후 시험 응시 금지로 이어질 수 있습니다.

기밀 유지 및 비공개 협약Confidentiality and Non-Disclosure Agreement

시험이 시작되기 전에 기밀 유지 및 비공개 협약(NDA)에 동의해야 합니다. 동의함으로써 질문, 답안 선택지, 시나리오를 포함한 모든 시험 내용이 Anthropic의 기밀이자 독점 자산임을 인정하고, 그 어떤 부분도 유출, 복제, 배포하지 않기로 합의합니다. 협약에 동의하지 않으면 시험 세션이 종료되며 환불은 이루어지지 않습니다.

자격 유지 및 재인증Credential Maintenance and Recertification

Claude Certified Architect – Foundations 자격은 부여된 날로부터 12개월간 유효합니다. 기반 기술이 빠르게 변하기 때문에, 보유자가 최신 지식을 유지하도록 자격에는 기간 제한이 있습니다.

제때 갱신하려면, 인증 이후 무엇이 바뀌었는지 검토하고 Anthropic Partner Academy에서 무료·비프록터링 평가를 완료합니다. 제때 갱신하는 데는 요금이 없습니다. 자격이 만료되면, 인증 상태를 되찾기 위해 정규 응시료로 전체 시험을 다시 치러야 합니다.

시험 내용이 크게 바뀌면, Anthropic은 보유자에게 갱신 평가 대신 전체 시험 재응시를 요구할 수 있습니다.

보유자는 13절에 설명된 행동 규칙의 적용을 계속 받습니다.

응시자 지원, 이의 제기, 개인정보Candidate Support, Appeals, and Privacy

지원

등록 이름을 정정하려면 certifications-support@anthropic.com으로 연락하십시오. 등록, 일정 예약, 편의 제공, 결과를 포함한 그 밖의 모든 문의는 pearsonvue.com/us/en/anthropic.html에서 Pearson VUE 지원에 연락하십시오.

이의 제기 및 불만

결정을 통지받은 날로부터 14일 이내에, 또는 시험 결과에 관한 우려라면 시험일로부터 14일 이내에 이의를 제기할 수 있습니다. 위 링크의 Pearson VUE 지원으로 이의를 제출하십시오. 이의는 프로그램의 이의 정책에 따라 검토됩니다. 표준 설정 결과와 개별 시험 문항의 내용은 이의 제기 대상이 아닙니다.

개인정보

등록 및 시험 중 수집된 개인 데이터는 Anthropic의 개인정보 처리방침, Pearson VUE의 개인정보 처리방침, 그리고 관련 데이터 보호법에 따라 처리됩니다.

부록Appendix

기술 및 개념

다음은 시험에 나올 수 있는 기술과 개념 목록입니다:

· Claude Agent SDK — 에이전트 정의, 에이전트 루프, stop_reason 처리, 훅(PostToolUse, 도구 호출 가로채기), Task 도구를 통한 서브에이전트 스포닝, allowedTools 구성

· Model Context Protocol(MCP) — MCP 서버, MCP 도구, MCP 리소스, isError 플래그, 도구 설명, 도구 분배, .mcp.json 구성, 환경 변수 확장

· Claude Code — CLAUDE.md 구성 계층(사용자/프로젝트/디렉터리), YAML 프런트매터 경로 범위 지정을 갖춘 .claude/rules/, 슬래시 명령을 위한 .claude/commands/, SKILL.md 프런트매터(context: fork, allowed-tools, argument-hint)를 갖춘 .claude/skills/, 플랜 모드, 직접 실행, /memory 명령, /compact, --resume, fork_session, Explore 서브에이전트

· Claude Code CLI — 비대화형 모드를 위한 -p / --print 플래그, --output-format json, 구조화 CI 출력을 위한 --json-schema

· Claude API — JSON 스키마를 갖춘 tool_use, tool_choice 옵션("auto", "any", 강제 도구 선택), stop_reason 값("tool_use", "end_turn"), max_tokens, 시스템 프롬프트

· Message Batches API — 50% 비용 절감, 최대 24시간 처리 창, 요청/응답 상관을 위한 custom_id, 완료 폴링, 멀티턴 도구 호출 미지원

· JSON Schema — 필수 대 선택 필드, enum 유형, nullable 필드, "other" + 상세 문자열 패턴, 구문 오류 제거를 위한 strict 모드

· Pydantic — 스키마 검증, 의미 검증 오류, 검증-재시도 루프

· 내장 도구 — Read, Write, Edit, Bash, Grep, Glob — 각각의 목적과 선택 기준

· 퓨샷 프롬프팅 — 모호한 시나리오용 표적 예시, 형식 시연, 새로운 패턴으로의 일반화

· 프롬프트 체이닝 — 순차적 과제 분해를 통한 집중 패스

· 컨텍스트 윈도우 관리 — 토큰 예산, 점진적 요약, 중간 소실 효과, 컨텍스트 추출, 스크래치패드 파일

· 세션 관리 — 세션 재개, fork_session, 명명 세션, 세션 컨텍스트 격리

· 신뢰도 점수 — 필드 수준 신뢰도, 레이블된 검증 집합을 이용한 보정, 오류율 측정을 위한 층화 표집

시험 범위 주제

다음 주제는 시험에서 명시적으로 다룹니다:

· 에이전트 루프 구현: stop_reason 기반 제어 흐름, 도구 결과 처리, 루프 종료 조건

· 멀티 에이전트 오케스트레이션: 코디네이터-서브에이전트 패턴, 과제 분해, 병렬 서브에이전트 실행, 반복적 정제 루프

· 서브에이전트 컨텍스트 관리: 명시적 컨텍스트 전달, 구조화된 상태 유지, 매니페스트를 이용한 크래시 복구

· 도구 인터페이스 설계: 효과적인 도구 설명 작성, 도구 분할 대 통합, 모호성을 줄이는 도구 명명

· MCP 도구 및 리소스 설계: 콘텐츠 카탈로그를 위한 리소스, 조치를 위한 도구, 도입을 위한 설명 품질

· MCP 서버 구성: 프로젝트 대 사용자 범위, 환경 변수 확장, 다중 서버 동시 접근

· 오류 처리 및 전파: 구조화된 오류 응답, 일시적 대 비즈니스 대 권한 오류, 에스컬레이션 전 지역 복구

· 에스컬레이션 의사결정: 명시적 기준, 고객 선호 존중, 정책 공백 식별

· CLAUDE.md 구성: 계층(사용자/프로젝트/디렉터리), @import 패턴, 글롭 패턴을 갖춘 .claude/rules/

· 커스텀 명령 및 스킬: 프로젝트 대 사용자 범위, context: fork, allowed-tools, argument-hint 프런트매터

· 플랜 모드 대 직접 실행: 복잡도 평가, 아키텍처 결정, 단일 파일 변경

· 반복적 정제: 입출력 예시, 테스트 주도 반복, 인터뷰 패턴, 순차 대 병렬 이슈 해결

· tool_use를 통한 구조화 출력: 스키마 설계, tool_choice 구성, 환각을 막는 nullable 필드

· 퓨샷 프롬프팅: 모호한 시나리오 표적화, 형식 일관성, 거짓 양성 감소

· 배치 처리: Message Batches API 적합성, 지연 허용도 평가, custom_id를 통한 실패 처리

· 컨텍스트 윈도우 최적화: 장황한 도구 출력 정리, 구조화된 사실 추출, 위치를 고려한 입력 배열

· 인간 검토 워크플로: 신뢰도 보정, 층화 표집, 문서 유형과 필드별 정확도 구분

· 정보 출처: 주장-출처 매핑, 시간 데이터 처리, 상충 주석, 커버리지 공백 보고

시험 범위 외 주제

다음 관련 주제는 시험에 나오지 않습니다:

· Claude 모델 파인튜닝 또는 커스텀 모델 훈련

· Claude API 인증, 청구, 계정 관리

· (도구 및 스키마 구성에 필요한 수준을 넘어서는) 특정 프로그래밍 언어나 프레임워크의 상세 구현

· MCP 서버 배포 또는 호스팅(인프라, 네트워킹, 컨테이너 오케스트레이션)

· Claude의 내부 아키텍처, 훈련 과정, 모델 가중치

· Constitutional AI, RLHF, 안전 훈련 방법론

· 임베딩 모델 또는 벡터 데이터베이스 구현 세부

· 컴퓨터 사용(브라우저 자동화, 데스크톱 상호작용)

· 비전/이미지 분석 기능

· 스트리밍 API 구현 또는 서버 전송 이벤트(server-sent events)

· 속도 제한, 쿼터, API 요금 계산

· OAuth, API 키 순환, 인증 프로토콜 세부

· 특정 클라우드 제공자 구성(AWS, GCP, Azure)

· 성능 벤치마킹 또는 모델 비교 지표

· 프롬프트 캐싱 구현 세부(존재한다는 사실을 아는 수준을 넘어서)

· 토큰 계수 알고리즘 또는 토크나이제이션 세부

문서 관리Document Control

버전 1.0 — 서식 및 레이아웃 갱신 — 2026년 7월

버전 0.2 — 초안 개정 — 2026년 6월

버전 0.1 — 최초 초안 — 2026년 2월

SAMPLE QUESTIONS

공개 샘플 문항

원문 가이드에 실린 예시 문항입니다 — 실제 출제 문항이 아니며, 형식과 난이도를 보여 주는 용도입니다. 직접 풀어 보세요.

  1. 샘플 1 · 시나리오: 고객 지원 해결 에이전트

    프로덕션 데이터에 따르면, 사례의 12%에서 에이전트가 get_customer를 아예 건너뛰고 고객이 진술한 이름만으로 lookup_order를 호출하며, 이따금 계정 오인식과 잘못된 환불로 이어집니다. 이 신뢰성 문제를 가장 효과적으로 해결할 변경은 무엇입니까?

    • A get_customer가 확인된 고객 ID를 반환할 때까지 lookup_order와 process_refund 호출을 차단하는 프로그램적 선행 조건을 추가한다.
    • B 주문 작업 전에 get_customer를 통한 고객 확인이 필수임을 명시하도록 시스템 프롬프트를 보강한다.
    • C 고객이 주문 정보를 자발적으로 제공하더라도 에이전트가 항상 get_customer를 먼저 호출하는 것을 보여 주는 퓨샷 예시를 추가한다.
    • D 각 요청을 분석해 그 요청 유형에 적합한 도구 하위 집합만 활성화하는 라우팅 분류기를 구현한다.

    해설 정답: A. 중요한 비즈니스 로직에 특정 도구 시퀀스가 요구될 때(예: 환불 처리 전 고객 신원 확인), 프로그램적 강제는 프롬프트 기반 접근이 줄 수 없는 결정론적 보장을 제공합니다. 선택지 B와 C는 확률적 LLM 준수에 의존하는데, 오류가 금전적 결과를 낳을 때 이는 불충분합니다. 선택지 D는 도구 순서가 아니라 도구 가용성을 다루므로 실제 문제가 아닙니다.

  2. 샘플 2 · 시나리오: 고객 지원 해결 에이전트

    프로덕션 로그에 따르면, 사용자가 주문에 대해 물을 때(예: "내 주문 #12345 확인해 줘") 에이전트가 lookup_order 대신 get_customer를 자주 호출합니다. 두 도구 모두 설명이 빈약하고("고객 정보 조회" / "주문 세부 조회") 유사한 식별자 형식을 받습니다. 도구 선택 신뢰성을 높이기 위한 가장 효과적인 첫 단계는 무엇입니까?

    • A 주문 관련 질의를 lookup_order로 라우팅하는 5~8개 예시로, 올바른 도구 선택 패턴을 시연하는 퓨샷 예시를 시스템 프롬프트에 추가한다.
    • B 각 도구의 설명을, 처리하는 입력 형식, 예시 질의, 예외 상황, 그리고 유사 도구 대비 언제 써야 하는지를 설명하는 경계까지 포함하도록 확장한다.
    • C 매 턴 전에 사용자 입력을 파싱해, 탐지된 키워드와 식별자 패턴을 근거로 적절한 도구를 미리 선택하는 라우팅 계층을 구현한다.
    • D 두 도구를, 아무 식별자나 받아 내부적으로 어느 백엔드를 조회할지 판단하는 단일 lookup_entity 도구로 통합한다.

    해설 정답: B. 도구 설명은 LLM이 도구를 선택할 때 쓰는 주된 메커니즘입니다. 설명이 빈약하면 모델은 유사한 도구를 구별할 맥락이 부족합니다. 선택지 B는 이 근본 원인을 적은 노력으로 큰 효과를 내며 직접 해결합니다. 퓨샷 예시(A)는 근본 문제를 고치지 않은 채 토큰 부담만 더합니다. 라우팅 계층(C)은 과잉 설계이며 LLM의 자연어 이해를 우회합니다. 도구 통합(D)은 타당한 아키텍처 선택이지만, 당장의 문제가 부적절한 설명일 때 "첫 단계"로는 과한 노력을 요합니다.

  3. 샘플 3 · 시나리오: 고객 지원 해결 에이전트

    당신의 에이전트는 첫 응대 해결 55%로 80% 목표에 크게 못 미칩니다. 로그를 보면, 사진 증거가 있는 표준 파손 교체처럼 간단한 사례는 에스컬레이션하면서, 정책 예외가 필요한 복잡한 상황은 자율적으로 처리하려 합니다. 에스컬레이션 보정을 개선하는 가장 효과적인 방법은 무엇입니까?

    • A 언제 에스컬레이션하고 언제 자율 해결할지 시연하는 퓨샷 예시와 함께, 명시적 에스컬레이션 기준을 시스템 프롬프트에 추가한다.
    • B 매 응답 전에 에이전트가 신뢰도 점수(1~10)를 자기 보고하게 하고, 신뢰도가 임계값 아래로 떨어지면 자동으로 요청을 사람에게 라우팅한다.
    • C 과거 티켓으로 훈련한 별도 분류기 모델을 배포해, 메인 에이전트가 처리를 시작하기 전에 어떤 요청이 에스컬레이션이 필요한지 예측한다.
    • D 감정 분석을 구현해 고객 불만 수준을 탐지하고, 부정 감정이 임계값을 넘으면 자동으로 에스컬레이션한다.

    해설 정답: A. 명시적 에스컬레이션 기준을 퓨샷 예시와 함께 추가하면 근본 원인, 즉 불분명한 결정 경계를 직접 해결합니다. 이는 인프라를 더하기 전의 비례적 첫 대응입니다. 선택지 B는 LLM의 자기 보고 신뢰도가 제대로 보정되지 않아 실패합니다 — 에이전트는 이미 어려운 사례에서 잘못된 확신을 보입니다. 선택지 C는 프롬프트 최적화를 시도하지 않은 채 레이블 데이터와 ML 인프라를 요구하는 과잉 설계입니다. 선택지 D는 전혀 다른 문제를 풉니다 — 감정은 실제 문제인 사안 복잡도와 상관되지 않습니다.

  4. 샘플 4 · 시나리오: Claude Code를 활용한 코드 생성

    팀의 표준 코드 리뷰 체크리스트를 실행하는 커스텀 /review 슬래시 명령을 만들려고 합니다. 이 명령은 저장소를 클론하거나 풀할 때 모든 개발자가 쓸 수 있어야 합니다. 이 명령 파일을 어디에 생성해야 합니까?

    • A 프로젝트 저장소의 .claude/commands/ 디렉터리에
    • B 각 개발자 홈 디렉터리의 ~/.claude/commands/에
    • C 프로젝트 루트의 CLAUDE.md 파일에
    • D commands 배열을 담은 .claude/config.json 파일에

    해설 정답: A. 프로젝트 범위 커스텀 슬래시 명령은 저장소 내 .claude/commands/ 디렉터리에 두어야 합니다. 이 명령들은 버전 관리되며 개발자가 저장소를 클론하거나 풀할 때 자동으로 제공됩니다. 선택지 B(~/.claude/commands/)는 버전 관리로 공유되지 않는 개인 명령용입니다. 선택지 C(CLAUDE.md)는 명령 정의가 아니라 프로젝트 지시와 맥락용입니다. 선택지 D는 Claude Code에 존재하지 않는 구성 메커니즘을 설명합니다.

  5. 샘플 5 · 시나리오: Claude Code를 활용한 코드 생성

    팀의 단일 애플리케이션(모놀리스)을 마이크로서비스로 재구조화하는 일을 맡았습니다. 이 작업은 수십 개 파일에 걸친 변경을 수반하며 서비스 경계와 모듈 의존성에 대한 결정을 요구합니다. 어떤 접근을 택해야 합니까?

    • A 플랜 모드로 진입해 코드베이스를 탐색하고 의존성을 이해하며, 변경에 착수하기 전에 구현 접근을 설계한다.
    • B 직접 실행으로 시작해 점진적으로 변경하며, 구현이 자연스러운 서비스 경계를 드러내게 둔다.
    • C 각 서비스를 어떻게 구성할지 정확히 상술한 포괄적 사전 지시와 함께 직접 실행을 사용한다.
    • D 직접 실행 모드로 시작하고, 구현 중 예상치 못한 복잡성을 만날 때만 플랜 모드로 전환한다.

    해설 정답: A. 플랜 모드는 대규모 변경, 복수의 타당한 접근, 아키텍처 결정을 수반하는 복잡한 과제를 위해 설계되었으며, 모놀리스에서 마이크로서비스로의 재구조화가 바로 그러합니다. 이는 변경을 확정하기 전 안전한 코드베이스 탐색과 설계를 가능케 합니다. 선택지 B는 의존성이 뒤늦게 드러날 때 값비싼 재작업의 위험이 있습니다. 선택지 C는 코드를 탐색하지 않은 채 올바른 구조를 이미 안다고 가정합니다. 선택지 D는 복잡성이 나중에 나타날 수 있는 것이 아니라 이미 요건에 명시되어 있다는 점을 간과합니다.

  6. 샘플 6 · 시나리오: Claude Code를 활용한 코드 생성

    당신의 코드베이스에는 서로 다른 코딩 컨벤션을 가진 뚜렷한 영역들이 있습니다: React 컴포넌트는 훅을 쓰는 함수형 스타일, API 핸들러는 특정 오류 처리를 갖춘 async/await, 데이터베이스 모델은 리포지토리 패턴을 따릅니다. 테스트 파일은 코드베이스 전반에 그것이 테스트하는 코드 옆에 흩어져 있고(예: Button.tsx 옆의 Button.test.tsx), 위치와 무관하게 모든 테스트가 동일한 컨벤션을 따르길 원합니다. 코드를 생성할 때 Claude가 올바른 컨벤션을 자동으로 적용하도록 하는 가장 유지보수하기 좋은 방법은 무엇입니까?

    • A 파일 경로에 따라 컨벤션을 조건부로 적용하도록 글롭 패턴을 지정한 YAML 프런트매터를 갖춘 규칙 파일을 .claude/rules/에 생성한다.
    • B 모든 컨벤션을 루트 CLAUDE.md 파일에 영역별 헤더 아래 통합하고, 어느 절이 적용되는지 Claude가 추론하게 맡긴다.
    • C 각 코드 유형에 대한 스킬을 .claude/skills/에 생성하고 관련 컨벤션을 그 SKILL.md 파일에 포함한다.
    • D 각 하위 디렉터리에 그 영역의 특정 컨벤션을 담은 별도의 CLAUDE.md 파일을 둔다.

    해설 정답: A. 선택지 A가 옳은 이유는, 글롭 패턴(예: **/*.test.tsx)을 갖춘 .claude/rules/가 디렉터리 위치와 무관하게 파일 경로에 따라 컨벤션을 자동 적용하게 해, 코드베이스 전반에 흩어진 테스트 파일에 필수적이기 때문입니다. 선택지 B는 명시적 매칭이 아니라 추론에 의존하여 신뢰성이 낮습니다. 선택지 C는 수동 스킬 호출이나 Claude가 로드하기로 선택하는 데 의존하므로, 파일 경로에 따른 결정론적 "자동" 적용이라는 요구와 모순됩니다. 선택지 D는 CLAUDE.md 파일이 디렉터리에 묶이므로 여러 디렉터리에 흩어진 파일을 쉽게 다루지 못합니다.

  7. 샘플 7 · 시나리오: 멀티 에이전트 리서치 시스템

    "AI가 창작 산업에 미치는 영향"이라는 주제로 시스템을 실행한 뒤, 각 서브에이전트가 성공적으로 완료됨을 관찰합니다: 웹 검색 에이전트는 관련 기사를 찾고, 문서 분석 에이전트는 논문을 올바로 요약하며, 종합 에이전트는 일관된 출력을 산출합니다. 그러나 최종 보고서는 시각 예술만 다루고 음악, 글쓰기, 영화 제작은 완전히 빠뜨립니다. 코디네이터 로그를 살펴보니, 주제를 "디지털 아트 창작의 AI", "그래픽 디자인의 AI", "사진의 AI"라는 세 하위 과제로 분해했습니다. 가장 유력한 근본 원인은 무엇입니까?

    • A 종합 에이전트가 다른 에이전트에게서 받은 발견에서 커버리지 공백을 식별하는 지시가 없다.
    • B 코디네이터 에이전트의 과제 분해가 지나치게 좁아, 주제의 모든 관련 영역을 다루지 못하는 서브에이전트 배정으로 이어졌다.
    • C 웹 검색 에이전트의 질의가 충분히 포괄적이지 않아 더 많은 창작 산업 부문을 다루도록 확장해야 한다.
    • D 문서 분석 에이전트가 지나치게 엄격한 관련성 기준 때문에 비시각 창작 산업 관련 출처를 걸러내고 있다.

    해설 정답: B. 코디네이터 로그가 근본 원인을 곧바로 드러냅니다: "창작 산업"을 시각 예술 하위 과제(디지털 아트, 그래픽 디자인, 사진)로만 분해하고 음악, 글쓰기, 영화를 완전히 누락했습니다. 서브에이전트는 배정된 과제를 올바로 수행했으며, 문제는 무엇이 배정되었는가입니다. 선택지 A, C, D는 배정된 범위 안에서 올바로 작동하고 있는 하위 에이전트에게 잘못을 돌립니다.

  8. 샘플 8 · 시나리오: 멀티 에이전트 리서치 시스템

    웹 검색 서브에이전트가 복잡한 주제를 조사하던 중 타임아웃됩니다. 이 실패 정보가 코디네이터 에이전트로 되돌아가는 방식을 설계해야 합니다. 지능적 복구를 가장 잘 가능케 하는 오류 전파 접근은 무엇입니까?

    • A 실패 유형, 시도한 질의, 부분 결과, 잠재적 대안 접근을 포함한 구조화된 오류 맥락을 코디네이터에 반환한다.
    • B 서브에이전트 내부에 지수 백오프를 갖춘 자동 재시도 로직을 구현하고, 모든 재시도가 소진된 후에만 일반적인 "검색 이용 불가" 상태를 반환한다.
    • C 타임아웃을 서브에이전트 내부에서 잡아 성공으로 표시된 빈 결과 집합을 반환한다.
    • D 타임아웃 예외를 전체 리서치 워크플로를 종료하는 최상위 핸들러로 직접 전파한다.

    해설 정답: A. 구조화된 오류 맥락은 코디네이터가 지능적 복구 결정 — 수정된 질의로 재시도할지, 대안 접근을 시도할지, 부분 결과로 진행할지 — 을 내리는 데 필요한 정보를 제공합니다. 선택지 B의 일반적 상태는 코디네이터로부터 가치 있는 맥락을 숨겨 정보에 근거한 결정을 막습니다. 선택지 C는 실패를 성공으로 표시해 오류를 억눌러 어떤 복구도 막고 불완전한 리서치 결과의 위험을 낳습니다. 선택지 D는 복구 전략이 성공할 수 있는데도 전체 워크플로를 불필요하게 종료합니다.

  9. 샘플 9 · 시나리오: 멀티 에이전트 리서치 시스템

    테스트 중, 종합 에이전트가 발견을 결합하면서 특정 주장을 자주 검증해야 함을 관찰합니다. 현재는 검증이 필요할 때 종합 에이전트가 코디네이터에게 제어를 반환하고, 코디네이터가 웹 검색 에이전트를 호출한 뒤 그 결과로 종합을 재호출합니다. 이는 과제당 2~3회 왕복을 더하고 지연을 40% 늘립니다. 평가에 따르면 이 검증의 85%는 단순 사실 확인(날짜, 이름, 통계)이고 15%는 더 깊은 조사가 필요합니다. 신뢰성을 유지하면서 오버헤드를 줄이는 가장 효과적인 접근은 무엇입니까?

    • A 종합 에이전트에 단순 조회를 위한 범위 지정 verify_fact 도구를 주고, 복잡한 검증은 코디네이터를 거쳐 웹 검색 에이전트에 계속 위임한다.
    • B 종합 에이전트가 모든 검증 필요를 누적해 패스 종료 시 배치로 코디네이터에 반환하고, 코디네이터가 그것들을 한꺼번에 웹 검색 에이전트에 보낸다.
    • C 종합 에이전트에 모든 웹 검색 도구 접근을 주어, 코디네이터를 거치는 왕복 없이 어떤 검증 필요든 직접 처리하게 한다.
    • D 웹 검색 에이전트가 초기 리서치 중 각 출처 주변의 추가 맥락을 미리 캐싱해, 종합 에이전트가 무엇을 검증할지 예상한다.

    해설 정답: A. 선택지 A는 최소 권한 원칙을 적용해, 종합 에이전트에 85% 흔한 경우(단순 사실 검증)에 필요한 것만 주면서 복잡한 경우에는 기존 조율 패턴을 유지합니다. 선택지 B의 배치 방식은, 종합 단계가 앞서 검증된 사실에 의존할 수 있으므로 차단 의존성을 만듭니다. 선택지 C는 종합 에이전트를 과도하게 무장시켜 관심사 분리를 위반합니다. 선택지 D는 종합 에이전트가 무엇을 검증할지 신뢰성 있게 예측할 수 없는 추측적 캐싱에 의존합니다.

  10. 샘플 10 · 시나리오: 지속적 통합을 위한 Claude Code

    파이프라인 스크립트가 claude "이 풀 리퀘스트의 보안 이슈를 분석하라"를 실행하지만 작업이 무한정 멈춥니다. 로그를 보면 Claude Code가 대화형 입력을 기다리고 있습니다. 자동화 파이프라인에서 Claude Code를 실행하는 올바른 접근은 무엇입니까?

    • A -p 플래그를 추가한다: claude -p "이 풀 리퀘스트의 보안 이슈를 분석하라"
    • B 명령 실행 전에 환경 변수 CLAUDE_HEADLESS=true를 설정한다.
    • C stdin을 /dev/null에서 리디렉션한다: claude "이 풀 리퀘스트의 보안 이슈를 분석하라" < /dev/null
    • D --batch 플래그를 추가한다: claude --batch "이 풀 리퀘스트의 보안 이슈를 분석하라"

    해설 정답: A. -p(또는 --print) 플래그는 Claude Code를 비대화형 모드로 실행하는 문서화된 방법입니다. 프롬프트를 처리하고 결과를 stdout으로 출력한 뒤 사용자 입력을 기다리지 않고 종료하는데, 이는 바로 CI/CD 파이프라인이 요구하는 것입니다. 나머지 선택지는 존재하지 않는 기능(CLAUDE_HEADLESS 환경 변수, --batch 플래그)을 참조하거나, Claude Code의 명령 구문을 제대로 다루지 못하는 Unix 우회책을 씁니다.

  11. 샘플 11 · 시나리오: 지속적 통합을 위한 Claude Code

    팀이 자동 분석의 API 비용을 줄이려 합니다. 현재 실시간 Claude 호출이 두 워크플로를 구동합니다: (1) 개발자가 병합하기 전 반드시 완료되어야 하는 차단형 병합 전 검사, (2) 이튿날 아침 검토용으로 야간에 생성되는 기술 부채 리포트. 매니저는 50% 비용 절감을 이유로 둘 다 Message Batches API로 전환하자고 제안합니다. 이 제안을 어떻게 평가해야 합니까?

    • A 기술 부채 리포트에만 배치 처리를 쓰고, 병합 전 검사는 실시간 호출을 유지한다.
    • B 완료 확인을 위한 상태 폴링과 함께 두 워크플로 모두 배치 처리로 전환한다.
    • C 배치 결과 순서 문제를 피하기 위해 두 워크플로 모두 실시간 호출을 유지한다.
    • D 배치가 너무 오래 걸리면 실시간으로 되돌아가는 타임아웃 폴백과 함께 둘 다 배치 처리로 전환한다.

    해설 정답: A. Message Batches API는 50% 비용 절감을 제공하지만 처리 시간이 최대 24시간이며 지연 시간 보장(SLA)이 없습니다. 이 때문에 개발자가 결과를 기다리는 차단형 병합 전 검사에는 부적합하지만, 기술 부채 리포트 같은 야간 배치 작업에는 이상적입니다. 선택지 B는 "대체로 더 빠름"에 의존하는데 이는 차단형 워크플로에 허용되지 않으므로 틀립니다. 선택지 C는 오해를 반영합니다 — 배치 결과는 custom_id 필드로 상관 지을 수 있습니다. 선택지 D는 각 API를 적절한 용도에 맞추는 더 단순한 해법이 있는데도 불필요한 복잡성을 더합니다.

  12. 샘플 12 · 시나리오: 지속적 통합을 위한 Claude Code

    한 풀 리퀘스트가 재고 추적 모듈 전반의 14개 파일을 수정합니다. 모든 파일을 함께 분석하는 단일 패스 리뷰는 일관되지 않은 결과를 냅니다: 어떤 파일에는 상세한 피드백을, 다른 파일에는 피상적 코멘트를 주고, 명백한 버그를 놓치며, 모순된 피드백을 냅니다 — 같은 PR에서 한 파일의 패턴을 문제로 표시하면서 다른 곳의 동일한 코드는 승인합니다. 리뷰를 어떻게 재구성해야 합니까?

    • A 집중 패스로 분리한다: 각 파일을 지역 이슈에 대해 개별 분석한 뒤, 파일 간 데이터 흐름을 살피는 별도의 통합 중심 패스를 실행한다.
    • B 자동 리뷰 실행 전에 개발자가 큰 PR을 3~4개 파일의 작은 제출로 나누도록 요구한다.
    • C 더 큰 컨텍스트 윈도우를 가진 상위 등급 모델로 전환해, 한 패스에서 14개 파일 모두에 충분한 주의를 준다.
    • D 전체 PR에 독립적 리뷰 패스 세 번을 실행하고, 세 번 중 최소 두 번에 나타나는 이슈만 표시한다.

    해설 정답: A. 리뷰를 집중 패스로 분리하면 근본 원인, 즉 많은 파일을 한꺼번에 처리할 때의 주의 분산을 직접 해결합니다. 파일별 분석은 일관된 깊이를 보장하고, 별도의 통합 패스는 파일 간 이슈를 잡아냅니다. 선택지 B는 시스템을 개선하지 않고 부담을 개발자에게 떠넘깁니다. 선택지 C는 더 큰 컨텍스트 윈도우가 주의 품질 문제를 해결하지 못한다는 점을 오해합니다. 선택지 D는 간헐적으로만 잡히는 이슈에 합의를 요구함으로써 실제 버그의 탐지를 오히려 억누릅니다.

한국어 대비 코스는 /learn/cert/ccar-f 컴패니언에서, 어떤 시험이 맞는지는 /cert-guide 트랙 선택에서 이어집니다.