Claude Certified Architect (Foundations) 완전 정복 가이드

게시 2026/03/27

By BLUEBUG

38 분읽는 시간

출처: X(트위터) @hooeem — “I want to become a Claude architect (full course)” 작성 목적: Anthropic 파트너가 아니어도 Claude 아키텍트 수준의 실력을 갖출 수 있도록, 공인 시험 가이드를 완전 분해한 독학 커리큘럼

이 가이드란 무엇인가
시험 개요와 구조
학습 로드맵 및 실습 시나리오
도메인 1: 에이전트 아키텍처 & 오케스트레이션 (27%)
도메인 2: 도구 설계 & MCP 통합 (18%)
도메인 3: Claude Code 설정 & 워크플로우 (20%)
도메인 4: 프롬프트 엔지니어링 & 구조화 출력 (20%)
도메인 5: 컨텍스트 관리 & 신뢰성 (15%)
Anthropic 공식 추천 학습 자료
마무리: 수료증 없이도 Claude 아키텍트가 되는 법

1. 이 가이드란 무엇인가

배경

Anthropic은 Claude Certified Architect (Foundations) 라는 공식 인증 시험을 운영하고 있다. 그러나 이 시험에 응시하려면 Anthropic 공식 파트너여야 한다는 조건이 붙어 있어, 일반 개발자나 학습자는 접근이 불가능하다.

X(트위터)의 개발자 @hooeem은 이 시험 가이드를 완전히 분해하여, 시험을 보지 않아도 실제 프로덕션 수준의 Claude 애플리케이션을 구축할 수 있는 지식을 누구나 습득할 수 있도록 커리큘럼을 공개했다.

핵심 메시지

“수료증이 없어도 프로덕션 애플리케이션을 만들 수 있다. 필요한 것은 지식이지, 종이 한 장이 아니다.”

이 가이드는 시험 합격을 목표로 하지 않는다. 목표는 다음 네 가지 핵심 기술 영역을 실제로 이해하고 구현할 수 있게 되는 것이다.

Claude Code — AI 기반 코딩 도우미의 고급 설정과 활용
Claude Agent SDK — 에이전트 루프, 오케스트레이션, 훅(hook) 구현
Claude API — 메시지 API, 배치 처리, 구조화 출력
Model Context Protocol (MCP) — 외부 도구 통합, 서버 설정, 커스텀 빌드

2. 시험 개요와 구조

시험 형식

항목	내용
문제 유형	시나리오 기반 객관식 (4지선다)
합격 점수	1000점 만점 중 720점
응시 자격	Anthropic 공식 파트너만 가능
핵심 원칙	고위험 상황에서는 확률적 해결책보다 결정론적 해결책을 선택

시험 도메인별 비중

도메인	주제	비중
1	에이전트 아키텍처 & 오케스트레이션	27%
2	도구 설계 & MCP 통합	18%
3	Claude Code 설정 & 워크플로우	20%
4	프롬프트 엔지니어링 & 구조화 출력	20%
5	컨텍스트 관리 & 신뢰성	15%

3. 학습 로드맵 및 실습 시나리오

시험은 다음 6가지 실제 프로덕션 시나리오를 중심으로 문제를 출제한다. 이 시나리오들은 각 도메인을 넘나들며 반복 등장한다.

핵심 시나리오 6가지

시나리오 1: 고객 지원 해결 에이전트 Agent SDK와 MCP를 활용하여 고객 문의를 처리하고, 필요시 인간 에이전트에게 에스컬레이션하는 시스템. 결제 환불, 계정 인증, 정책 예외 처리 등을 포함한다.

시나리오 2: Claude Code를 이용한 코드 생성 CLAUDE.md 파일 구성, 플랜 모드 활용, 슬래시 커맨드 활용을 통해 팀 전체의 코딩 표준을 자동화하는 워크플로우.

시나리오 3: 멀티 에이전트 연구 시스템 코디네이터-서브에이전트 오케스트레이션 구조로 복잡한 리서치 작업을 분산 처리하는 시스템. 웹 검색, 문서 분석, 합성(synthesis) 에이전트가 협력한다.

시나리오 4: 개발자 생산성 도구 빌트인 도구와 MCP 서버를 조합하여 개발 워크플로우를 자동화하는 시스템. 코드 리뷰, 테스트 생성, 의존성 분석 등이 포함된다.

시나리오 5: CI/CD를 위한 Claude Code 비대화형(non-interactive) 파이프라인에서 Claude Code를 실행하고, 구조화 출력을 통해 PR 자동 리뷰 코멘트를 생성하는 통합 방식.

시나리오 6: 구조화 데이터 추출 JSON 스키마, tool_use API, 검증-재시도 루프를 활용하여 비정형 문서에서 정형 데이터를 안정적으로 추출하는 파이프라인.

4. 도메인 1: 에이전트 아키텍처 & 오케스트레이션 (27%)

이 도메인은 전체 시험에서 가장 높은 비중(27%) 을 차지하는 핵심 영역이다. 에이전트 루프의 동작 원리부터 멀티 에이전트 협업, 보안 강화 훅까지 다룬다.

태스크 1.1: 에이전트 루프 (Agentic Loop)

에이전트 루프의 전체 생애주기

에이전트 루프란 Claude가 도구를 사용하여 작업을 완료할 때까지 반복하는 사이클이다. 올바른 구현 방식은 다음과 같다.

요청 전송: Messages API를 통해 Claude에게 요청을 보낸다.
stop_reason 확인: 응답의 stop_reason 필드를 확인한다.
분기 처리:
- stop_reason이 "tool_use"인 경우 → 요청된 도구를 실행하고, 결과를 대화 히스토리에 추가한 뒤 Claude에게 다시 전송한다.
- stop_reason이 "end_turn"인 경우 → 에이전트가 작업을 완료한 것이므로 최종 응답을 반환한다.
반복: 도구 결과가 포함된 전체 대화 히스토리를 항상 함께 전송해야 Claude가 이전 정보를 기반으로 다음 단계를 추론할 수 있다.

절대 해서는 안 되는 3가지 안티패턴

시험에서 반드시 거부해야 하는 잘못된 구현 방식이다.

안티패턴 1: 자연어 신호로 루프 종료 판단

  
# 잘못된 방식
if "완료했습니다" in response.content[0].text:
    stop_loop()

자연어는 모호하고 불안정하다. Claude가 “완료했습니다”라는 말 뒤에 도구 호출을 추가할 수도 있다. stop_reason 필드가 바로 이 목적을 위해 존재한다.

안티패턴 2: 임의의 반복 횟수를 기본 종료 조건으로 사용

  
# 잘못된 방식
for i in range(10):  # 10번만 실행
    response = call_claude()

10번 이전에 작업이 끝나면 불필요한 반복이 발생하고, 10번 안에 끝나지 않으면 작업이 중단된다. 모델이 stop_reason으로 완료를 신호할 때까지 실행해야 한다.

안티패턴 3: 텍스트 응답 존재 여부로 완료 판단

  
# 잘못된 방식
if response.content[0].type == "text":
    return response.content[0].text  # 완료로 잘못 판단

모델은 tool_use 블록과 함께 텍스트를 동시에 반환할 수 있다. 텍스트가 있다고 해서 반드시 완료된 것이 아니다.

올바른 구현 예시

  
while True:
    response = client.messages.create(
        model="claude-opus-4-5",
        messages=conversation_history,
        tools=tools
    )
    
    conversation_history.append({
        "role": "assistant",
        "content": response.content
    })
    
    if response.stop_reason == "end_turn":
        # 에이전트가 작업 완료를 신호함
        break
    elif response.stop_reason == "tool_use":
        # 도구 결과를 처리하고 히스토리에 추가
        tool_results = execute_tools(response.content)
        conversation_history.append({
            "role": "user",
            "content": tool_results
        })

태스크 1.2: 멀티 에이전트 오케스트레이션

허브-앤-스포크 아키텍처

멀티 에이전트 시스템의 기본 구조는 코디네이터 에이전트(허브)와 서브에이전트(스포크)로 이루어진다.

                    [코디네이터 에이전트]
                    /         |          \
          [웹검색 에이전트] [문서분석 에이전트] [합성 에이전트]

코디네이터의 역할은 다음과 같다.

작업 분해(task decomposition): 큰 작업을 서브에이전트가 처리할 수 있는 단위로 쪼갠다.
어떤 서브에이전트를 호출할지 동적으로 결정한다.
서브에이전트에게 필요한 컨텍스트를 명시적으로 전달한다.
결과를 집계하고, 에러를 처리하며, 서브에이전트 간 정보를 중계한다.

절대 원칙: 서브에이전트끼리는 직접 통신하지 않는다. 모든 통신은 반드시 코디네이터를 통해야 한다.

가장 많이 오해하는 개념: 서브에이전트의 컨텍스트 격리

이것이 멀티 에이전트 시스템에서 가장 자주 틀리는 개념이다.

서브에이전트는 코디네이터의 대화 히스토리를 자동으로 상속받지 않는다. 서브에이전트끼리는 서로의 메모리를 공유하지 않는다. 서브에이전트가 필요한 모든 정보는 해당 서브에이전트의 프롬프트에 명시적으로 포함되어야 한다.

즉, 코디네이터가 웹검색 에이전트의 결과를 문서분석 에이전트에게 전달하려면, 그 결과를 문서분석 에이전트의 프롬프트 안에 직접 삽입해야 한다.

좁은 분해 실패 패턴

시험 문제(Q7)에 등장하는 유명한 함정이다. “AI가 창의 산업에 미치는 영향”을 조사하는 코디네이터가 서브에이전트를 시각예술 관련 서브토픽으로만 분해했다면, 음악·글쓰기·영화 분야가 완전히 누락된다. 이때 문제의 근본 원인은 하위 에이전트가 아니라 코디네이터의 작업 분해 로직이다.

태스크 1.3: 서브에이전트 호출과 컨텍스트 전달

Task 도구

서브에이전트를 생성하는 메커니즘은 Task 도구다. 코디네이터의 allowedTools에 "Task"가 포함되어 있어야 서브에이전트를 생성할 수 있다. 각 서브에이전트는 AgentDefinition으로 정의되며, 설명(description), 시스템 프롬프트, 허용 도구 목록을 포함한다.

병렬 서브에이전트 생성

코디네이터가 하나의 응답에서 여러 개의 Task 도구 호출을 동시에 내보내면, 서브에이전트들이 병렬로 실행된다. 이는 순차적 실행보다 훨씬 빠르다.

  
# 코디네이터가 한 번의 응답에서 여러 서브에이전트를 동시에 생성
response = coordinator.invoke([
    Task(agent=web_search_agent, query="태양광 발전 최신 기술"),
    Task(agent=web_search_agent, query="풍력 발전 최신 기술"),
    Task(agent=doc_analysis_agent, document=uploaded_report),
])

fork_session

fork_session은 공유된 분석 기준점에서 독립적인 브랜치를 생성하는 기능이다. 예를 들어, 동일한 코드베이스 분석을 바탕으로 두 가지 리팩토링 전략을 비교하고 싶을 때 사용한다. 각 포크는 분기 이후 독립적으로 동작한다.

구조화된 컨텍스트 전달

서브에이전트에게 정보를 전달할 때는 콘텐츠와 메타데이터(출처 URL, 문서명, 페이지 번호)를 분리된 구조화 형식으로 전달해야 한다. 이렇게 해야 에이전트를 거치면서도 출처 귀속(attribution)이 유지된다.

태스크 1.4: 워크플로우 강제 실행과 핸드오프

강제 실행 스펙트럼

에이전트가 특정 단계를 반드시 따르도록 만드는 방법에는 두 가지가 있다.

방법 1: 프롬프트 기반 가이드 시스템 프롬프트에 지시사항을 포함한다. (“항상 먼저 고객 인증을 완료하세요.”) 대부분의 경우에는 잘 작동하지만, 실패할 확률이 0이 아니다.

방법 2: 프로그래밍 방식 강제 실행 훅(hook) 또는 전제조건 게이트(prerequisite gate)를 구현하여 전제조건이 충족되지 않으면 후속 도구 자체를 물리적으로 차단한다. 이 방법은 항상 100% 작동한다.

강제 실행 방식 선택 기준

이것이 시험(Q1)에서 직접 출제되는 핵심 판단 기준이다.

결과가 금융, 보안, 규정 준수와 관련된 경우 → 프로그래밍 방식 강제 실행 (훅/게이트) 사용 결과가 스타일, 포맷 선호도 등 저위험인 경우 → 프롬프트 기반 가이드로 충분

예를 들어, 환불 처리 전에 반드시 계정 소유권을 인증해야 하는 경우, 시스템 프롬프트에 “먼저 인증하세요”라고 적는 것으로는 부족하다. 환불 도구가 인증 도구 실행 전에는 아예 호출되지 않도록 게이트를 코드로 구현해야 한다.

구조화된 핸드오프 프로토콜

에이전트가 인간 에이전트에게 케이스를 넘길 때, 인간 에이전트는 전체 대화 기록에 접근할 수 없다는 점을 반드시 고려해야 한다. 따라서 핸드오프 요약은 완전히 자기 완결적이어야 한다.

핸드오프 패키지에 포함되어야 할 항목:

고객 ID
대화 요약
근본 원인 분석
환불 금액 (해당되는 경우)
권장 조치 사항

태스크 1.5: Agent SDK 훅 (Hooks)

PostToolUse 훅

도구 실행 후, 모델이 결과를 처리하기 전에 개입하는 훅이다. 주요 사용 사례는 데이터 정규화다. 서로 다른 MCP 도구들이 다양한 데이터 형식(Unix 타임스탬프 vs ISO 8601, 숫자 상태 코드 vs 문자열)으로 결과를 반환할 때, 이 훅에서 일관된 형식으로 변환한다. 모델은 항상 깔끔하고 일관된 데이터를 받게 된다.

도구 호출 인터셉션 훅

도구 실행 전에 개입하는 훅이다. 주요 사용 사례는 정책 강제 실행이다.

예시:

$500 초과 환불 요청을 차단하고 인간 에스컬레이션 워크플로우로 리다이렉트
컴플라이언스 규정(예: 특정 작업에 매니저 승인 요구) 강제 실행

훅 vs 프롬프트 결정 기준

비즈니스가 단 한 번의 실패로 금전적 손실이나 법적 위험에 노출될 수 있다면 → 훅 사용 그 외 선호도나 유연한 규칙 → 프롬프트 사용

태스크 1.6: 작업 분해 전략

고정 순차 파이프라인 (프롬프트 체이닝)

작업을 미리 정해진 단계로 순차적으로 분해하는 방식이다.

장점: 예측 가능하고 신뢰성이 높다. 단점: 예상치 못한 발견에 적응하지 못한다. 적합한 경우: 코드 리뷰, 문서 처리 등 구조적이고 예측 가능한 작업.

동적 적응형 분해

각 단계에서 발견된 내용을 바탕으로 서브태스크를 동적으로 생성하는 방식이다.

예시: 레거시 코드베이스에 테스트를 추가하는 작업. 먼저 구조를 파악하고, 영향도가 높은 영역을 식별한 뒤, 의존성이 드러나면서 우선순위 계획을 적응적으로 수정한다.

장점: 문제에 맞게 적응한다. 단점: 예측 가능성이 낮다. 적합한 경우: 오픈 엔드 탐색 작업.

주의 희석(Attention Dilution) 문제

14개 파일을 단일 패스로 처리하면 일부 파일에는 상세한 피드백이 제공되지만 다른 파일의 명백한 버그를 놓치는 현상이 발생한다. 또한 한 파일에서는 특정 패턴을 문제로 플래그하면서 동일한 코드가 다른 파일에서는 승인될 수 있다.

해결책: 파일별 로컬 분석 패스와 별도의 크로스 파일 통합 패스로 분리한다.

태스크 1.7: 세션 상태와 재개

세션 관리 옵션 비교

옵션	명령어	사용 시점
재개	`--resume <session-name>`	이전 컨텍스트가 여전히 유효하고 파일이 크게 변경되지 않은 경우
포크	`fork_session`	공유 분석 기준점에서 서로 다른 접근 방식을 탐색해야 할 경우
새 세션 + 요약 주입	새 세션 시작 후 요약 삽입	도구 결과가 오래되었거나, 파일이 변경되었거나, 긴 세션으로 컨텍스트가 저하된 경우

오래된 컨텍스트 문제

코드 수정 후 세션을 재개하면, 에이전트가 수정된 파일에 대해 오래된 도구 결과를 바탕으로 모순된 조언을 할 수 있다. 올바른 접근 방식은 변경된 특정 파일에 대해 에이전트에게 알리고 타겟 재분석을 수행하도록 하는 것이다. 처음부터 전체를 다시 탐색하도록 요구하지 않아도 된다.

도메인 1 빌드 실습

목표: 코디네이터 에이전트 + 2개 서브에이전트(웹검색, 문서분석) 구축. 구조화 메타데이터를 포함한 컨텍스트 전달, 프로그래밍 방식 전제조건 게이트, PostToolUse 정규화 훅 구현. 다중 관심사 요청으로 테스트.

5. 도메인 2: 도구 설계 & MCP 통합 (18%)

이 도메인에서 가장 자주 간과되는 개념이 하나 있다. 도구 설명(tool description) 이다. 도구 설명은 Claude가 어떤 도구를 선택할지 결정하는 데 사용하는 가장 중요한 메커니즘이다.

태스크 2.1: 도구 인터페이스 설계

좋은 도구 설명의 구성 요소

도구 설명이 최소화되어 있으면(“고객 정보를 조회합니다”) 유사한 도구들 사이에서 올바른 도구를 선택하는 것이 불안정해진다.

좋은 도구 설명에 포함되어야 할 내용:

도구가 하는 일 (주요 목적)
예상 입력값 (형식, 타입, 제약 조건)
이 도구가 잘 처리하는 예시 쿼리
엣지 케이스와 한계
명시적인 경계: 이 도구를 사용해야 할 때 vs 유사 도구를 사용해야 할 때

잘못된 라우팅 문제

시험 Q2는 get_customer와 lookup_order가 서로 거의 동일한 설명으로 인해 지속적으로 잘못 라우팅되는 문제를 다룬다. 잘못된 수정 방법과 올바른 수정 방법을 명확히 구분해야 한다.

수정 방법	평가
더 나은 도구 설명 작성	✅ 올바른 첫 번째 단계
few-shot 예시 추가	❌ 잘못된 근본 원인에 대한 해결책 (토큰 낭비)
라우팅 분류기 추가	❌ 과도하게 복잡한 첫 번째 단계
도구 통합	❌ 너무 많은 노력이 필요한 첫 번째 단계

원칙: 낮은 노력, 높은 레버리지의 수정을 우선한다.

도구 분리 원칙

범용 도구를 정해진 입출력 계약을 가진 목적별 도구로 분리해야 한다.

예시:

analyze_document → extract_data_points, summarize_content, verify_claim_against_source

시스템 프롬프트 충돌 주의

시스템 프롬프트의 키워드 민감 지시사항이 잘 작성된 도구 설명을 무효화하는 의도치 않은 도구 연관성을 만들 수 있다. 도구 설명을 업데이트한 후에는 항상 시스템 프롬프트에 충돌이 없는지 검토해야 한다.

태스크 2.2: 구조화 에러 응답

MCP isError 플래그 패턴

에이전트에게 실패를 전달하는 MCP 표준 방식은 isError 플래그를 사용하는 것이다.

4가지 에러 카테고리

카테고리	설명	재시도 가능 여부
일시적(Transient)	타임아웃, 서비스 불가	✅ 재시도 가능
검증(Validation)	잘못된 입력 (형식, 누락 필드)	✅ 입력 수정 후 재시도
비즈니스(Business)	정책 위반 (환불 한도 초과)	❌ 재시도 불가, 대안 워크플로우 필요
권한(Permission)	접근 거부	❌ 에스컬레이션 또는 다른 자격 증명 필요

에러 메타데이터에 errorCategory, isRetryable 불리언, 사람이 읽을 수 있는 설명을 포함시켜야 에이전트가 적절한 방식으로 응답할 수 있다.

접근 실패 vs 유효한 빈 결과 구분

이것은 시험에서 반드시 구분할 수 있어야 하는 핵심 개념이다.

접근 실패: 도구가 데이터 소스에 접근하지 못한 경우 (타임아웃, 인증 실패). 재시도를 고려해야 한다. 유효한 빈 결과: 도구가 성공적으로 소스를 쿼리했지만 결과가 없는 경우. 재시도하지 말아야 한다. “결과 없음”이 정답이다.

이 둘을 혼동하면 잘못된 재시도 로직이 발생한다.

태스크 2.3: 도구 배포와 tool_choice

도구 과부하 문제

에이전트에게 18개의 도구를 제공하면 선택 신뢰성이 저하된다. 각 에이전트는 역할과 관련된 4~5개의 도구로 범위를 제한해야 한다.

합성 에이전트는 웹 검색 도구를 가져서는 안 된다.
웹 검색 에이전트는 문서 분석 도구를 가져서는 안 된다.

tool_choice 옵션 완벽 이해

옵션	동작	사용 시점
`"auto"`	모델이 도구 호출 여부를 결정 (기본값)	일반 동작
`"any"`	반드시 도구를 호출해야 하지만 어떤 도구를 호출할지는 선택	다중 스키마 중 하나에서 구조화 출력이 필요할 때
`{"type": "tool", "name": "extract_metadata"}`	이 특정 도구를 반드시 호출	필수 첫 단계를 강제할 때

범위가 제한된 교차 역할 도구

시험 Q9에서 테스트되는 패턴이다. 합성 에이전트가 단순한 팩트 확인을 위해 코디네이터에게 매번 제어권을 반환하면 작업당 2~3번의 추가 라운드 트립과 40%의 지연이 발생한다. 해결책은 85%의 단순한 케이스를 위한 범위가 제한된 verify_fact 도구를 합성 에이전트에게 직접 제공하는 것이다.

태스크 2.4: MCP 서버 통합

스코핑 계층 구조

레벨	위치	특징
프로젝트 레벨	`.mcp.json` (프로젝트 저장소 내)	버전 관리, 팀 전체 공유
사용자 레벨	`~/.claude.json`	개인용, 버전 관리 안 됨, 공유 안 됨

모든 설정된 서버의 도구들은 연결 시점에 발견되어 동시에 사용 가능하다.

환경 변수 확장

.mcp.json은 ${GITHUB_TOKEN} 구문을 지원한다. 이 방식으로 자격 증명을 버전 관리에서 제외할 수 있다. 각 개발자는 자신의 토큰을 로컬에서 설정한다.

  
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@anthropic/mcp-server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

커스텀 빌드 vs 기존 서버 사용 결정

표준 통합(Jira, GitHub, Slack 등)에는 기존 커뮤니티 MCP 서버를 먼저 검토한다. 커뮤니티 서버가 처리할 수 없는 팀 특화 워크플로우에만 커스텀 서버를 빌드한다.

태스크 2.5: 빌트인 도구

Grep vs Glob 구분

도구	역할	사용 시점
Grep	파일 내용에서 패턴 검색	함수 호출자 찾기, 에러 메시지 위치 찾기, import 구문 검색
Glob	경로 기반 파일 이름 패턴 매칭	확장자별 파일 찾기 (`*/.test.tsx`), 설정 파일 위치 찾기

시험은 의도적으로 둘을 혼동하게 만드는 시나리오를 제시한다.

Read/Write/Edit 패턴

Edit: 고유 텍스트 매칭을 사용한 타겟 수정. 빠르고 정밀하다.
Edit가 실패할 경우 (고유하지 않은 텍스트 매칭): Read (전체 파일 로드) + Write (수정된 전체 파일 작성)로 폴백한다.

코드베이스 점진적 이해 전략

Grep으로 엔트리 포인트 찾기 (함수 정의, import 구문)
Read로 엔트리 포인트에서부터 흐름을 추적
모든 파일을 처음부터 읽지 말 것 — 컨텍스트 예산을 낭비한다.

도메인 2 빌드 실습

목표: 의도적으로 모호한 쌍이 포함된 3개의 MCP 도구 생성. 4가지 에러 카테고리를 포함한 에러 응답 작성. 환경 변수 확장을 포함한 .mcp.json 설정. forced selection을 위한 tool_choice 테스트.

6. 도메인 3: Claude Code 설정 & 워크플로우 (20%)

이 도메인은 Claude Code를 단순히 사용하는 개발자와 팀을 위해 제대로 설정한 개발자를 구분한다. 구성 파일의 위치와 동작을 알거나 모르거나 두 가지다. 직접 손으로 설정해 본 경험이 없으면 시험을 통과하기 어렵다.

태스크 3.1: CLAUDE.md 계층 구조

3단계 계층

레벨	위치	공유 여부	특징
사용자 레벨	`~/.claude/CLAUDE.md`	❌	나 자신에게만 적용. git 버전 관리 안 됨. 팀원이 저장소를 클론해도 이 설정은 적용되지 않음.
프로젝트 레벨	`.claude/CLAUDE.md` 또는 루트 `CLAUDE.md`	✅	모두에게 적용. 버전 관리됨. 팀 전체 표준이 여기에 있어야 함.
디렉토리 레벨	하위 디렉토리 내 CLAUDE.md	부분	해당 디렉토리에서 작업할 때만 적용됨.

시험이 가장 좋아하는 함정

신입 팀원이 지시사항을 받지 못하는 이유를 묻는 문제가 출제된다. 정답은 항상 지시사항이 사용자 레벨 설정에 있기 때문이다 — 버전 관리가 되지 않아 팀에 공유되지 않는다.

모듈식 구성

```markdown

AI, Claude

AI Anthropic claude-certified-architect Claude.write