Claude Certified Architect (Foundations) 완전 정복 가이드 - k82022603/k82022603.github.io GitHub Wiki

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

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

목차

  1. 이 가이드란 무엇인가
  2. 시험 개요와 구조
  3. 학습 로드맵 및 실습 시나리오
  4. 도메인 1: 에이전트 아키텍처 & 오케스트레이션 (27%)
  5. 도메인 2: 도구 설계 & MCP 통합 (18%)
  6. 도메인 3: Claude Code 설정 & 워크플로우 (20%)
  7. 도메인 4: 프롬프트 엔지니어링 & 구조화 출력 (20%)
  8. 도메인 5: 컨텍스트 관리 & 신뢰성 (15%)
  9. Anthropic 공식 추천 학습 자료
  10. 마무리: 수료증 없이도 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가 도구를 사용하여 작업을 완료할 때까지 반복하는 사이클이다. 올바른 구현 방식은 다음과 같다.

  1. 요청 전송: Messages API를 통해 Claude에게 요청을 보낸다.
  2. stop_reason 확인: 응답의 stop_reason 필드를 확인한다.
  3. 분기 처리:
    • stop_reason이 "tool_use"인 경우 → 요청된 도구를 실행하고, 결과를 대화 히스토리에 추가한 뒤 Claude에게 다시 전송한다.
    • stop_reason이 "end_turn"인 경우 → 에이전트가 작업을 완료한 것이므로 최종 응답을 반환한다.
  4. 반복: 도구 결과가 포함된 전체 대화 히스토리를 항상 함께 전송해야 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 (수정된 전체 파일 작성)로 폴백한다.

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

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

도메인 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 부분 해당 디렉토리에서 작업할 때만 적용됨.

시험이 가장 좋아하는 함정

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

모듈식 구성

<!-- .claude/CLAUDE.md -->
@import ./standards/api-conventions.md
@import ./standards/testing.md
@import ./standards/deployment.md

@import 구문으로 외부 파일을 참조하여 하나의 거대한 파일 대신 주제별 규칙 파일로 나눌 수 있다.

/memory 명령어

로드된 메모리 파일을 확인하는 디버깅 도구다. 세션 간 일관성 없는 동작을 디버깅할 때 사용한다.

태스크 3.2: 커스텀 슬래시 커맨드와 스킬

디렉토리 구조

위치 범위
.claude/commands/ 프로젝트 범위, 버전 관리를 통해 공유
~/.claude/commands/ 개인 범위, 공유 안 됨
.claude/skills/ (SKILL.md 파일 포함) 온디맨드 호출, 설정 포함

스킬 프론트매터 옵션

---
context: fork          # 격리된 서브에이전트 컨텍스트에서 실행 (상세 출력이 메인 대화를 오염시키지 않음)
allowed-tools:         # 이 스킬이 사용할 수 있는 도구 제한
  - read_file
  - grep
argument-hint: "분석할 파일 경로를 입력하세요"  # 인수 없이 호출 시 안내 메시지
---

스킬 vs CLAUDE.md 구분

구분 스킬 CLAUDE.md
적용 방식 온디맨드 (필요할 때 호출) 항상 자동 로드
내용 태스크 특화 워크플로우 보편적 표준
예시 /review 명령어 코딩 스타일 가이드

중요: 태스크 특화 절차를 CLAUDE.md에 넣지 말고, 보편적 표준을 스킬에 넣지 마라.

태스크 3.3: 경로 특화 규칙 (Path-Specific Rules)

.claude/rules/ 파일 형식

---
paths: ["terraform/**/*"]
---
# Terraform 관련 규칙
- 모든 리소스에 required_tags 변수 사용
- 민감한 변수는 반드시 sensitive = true 설정

디렉토리 레벨 CLAUDE.md 대비 핵심 장점

비교 .claude/rules/ (glob 패턴) 디렉토리 CLAUDE.md
적용 범위 코드베이스 전체에서 매칭 해당 디렉토리만
예시 **/*.test.tsx — 모든 테스트 파일 그 디렉토리의 테스트 파일만
토큰 효율성 매칭되는 파일 편집 시에만 로드 항상 로드

50개 이상의 디렉토리에 걸쳐 분산된 테스트 파일에 동일한 컨벤션을 적용해야 한다면, .claude/rules/의 glob 패턴이 올바른 해결책이다.

태스크 3.4: 플랜 모드 vs 직접 실행

결정 프레임워크

플랜 모드를 사용해야 할 때:

  • 대규모 변경이 포함된 복잡한 작업
  • 여러 가지 유효한 접근 방식이 존재하여 커밋 전에 평가가 필요한 경우
  • 아키텍처적 결정이 필요한 경우
  • 다중 파일 수정이 필요한 경우 (예: 45개 이상의 파일에 영향을 미치는 라이브러리 마이그레이션)
  • 변경 전에 코드베이스를 탐색하고 설계해야 하는 경우

직접 실행을 사용해야 할 때:

  • 명확하고 제한된 범위의 잘 이해된 변경
  • 단일 파일 버그 수정 (명확한 스택 트레이스 포함)
  • 날짜 유효성 검사 조건부 추가 등 단순 작업
  • 올바른 접근 방식이 이미 알려진 경우

Explore 서브에이전트

상세한 탐색 출력을 메인 대화에서 격리한다. 요약만 메인 대화에 반환하여 컨텍스트 창 고갈을 방지한다. 다중 단계 작업에서 사용한다.

조합 패턴

플랜 모드로 조사하고 설계한 후, 직접 실행으로 계획된 접근 방식을 구현한다. 실무에서 가장 많이 사용되는 패턴이며 시험에도 출제된다.

태스크 3.5: 반복적 정제

기법 우선순위

  1. 구체적인 입출력 예시 (2~3개의 before/after 예시): 항상 산문 설명보다 효과적이다.
  2. 테스트 주도 반복: 먼저 테스트를 작성하고 실패를 공유하여 개선을 유도한다.
  3. 인터뷰 패턴: 구현 전에 Claude가 질문을 하도록 유도한다 (익숙하지 않은 도메인에서 놓칠 수 있는 고려 사항을 발굴한다).

피드백 배치 vs 순차 기준

  • 단일 메시지로 일괄 처리: 수정 사항들이 서로 영향을 미칠 때 (하나를 바꾸면 다른 것에 영향)
  • 순차적 반복: 문제들이 독립적일 때 (하나를 수정해도 다른 것에 영향 없음)

태스크 3.6: CI/CD 통합

-p 플래그 (시험 Q10에서 직접 출제)

Claude Code를 비대화형 모드(print mode)로 실행한다. 이 플래그 없이 CI 파이프라인에서 실행하면 CI 작업이 대화 입력을 기다리며 무한정 멈춘다.

# CI 파이프라인에서 올바른 사용법
claude -p "이 PR을 분석하세요" --output-format json

구조화 CI 출력

claude -p "코드 리뷰 수행" \
  --output-format json \
  --json-schema review_schema.json

자동화 시스템이 결과를 PR 인라인 코멘트로 게시할 수 있다.

독립 리뷰 인스턴스

동일한 세션에서 코드를 생성하고 리뷰하면 효과가 떨어진다. 모델이 자신의 결정을 의문시할 가능성이 낮아진다. 코드 리뷰를 위해 이전 컨텍스트가 없는 독립 인스턴스를 사용해야 한다.

증분 리뷰 컨텍스트

새 커밋 후 리뷰를 다시 실행할 때는 이전 리뷰 결과를 컨텍스트에 포함시키고, 새로운 또는 아직 해결되지 않은 문제만 보고하도록 지시한다. 중복 코멘트는 개발자의 신뢰를 잃게 만든다.

도메인 3 빌드 실습

목표: CLAUDE.md 계층 구조(프로젝트 + 디렉토리 레벨), 테스트 파일과 API 파일에 대한 glob 패턴이 포함된 .claude/rules/, context: fork를 사용하는 커스텀 스킬, JSON 출력을 포함한 -p 플래그를 사용하는 CI 스크립트가 있는 프로젝트 설정.

7. 도메인 4: 프롬프트 엔지니어링 & 구조화 출력 (20%)

이 도메인에서 기억해야 할 두 단어가 있다. "명시적으로". 막연한 지시사항은 아무것도 개선하지 못한다. 구체적인 기준이 작동한다.

태스크 4.1: 명시적 기준

올바른 방식 vs 잘못된 방식

잘못된 방식 (모호한 기준):

  • "보수적으로 판단하세요."
  • "확실한 발견 사항만 보고하세요."

올바른 방식 (명시적 기준):

  • "주석의 설명이 실제 코드 동작과 모순될 때만 플래그를 지정하세요. 버그와 보안 취약점을 보고하세요. 사소한 스타일 선호도와 로컬 패턴은 건너뛰세요."

거짓 양성(False Positive) 신뢰 문제

특정 카테고리의 높은 거짓 양성 비율은 모든 카테고리에 대한 신뢰를 파괴한다. 해결책: 거짓 양성이 높은 카테고리를 일시적으로 비활성화하여 신뢰를 회복하면서, 그 카테고리에 대한 프롬프트를 개선한다.

심각도 보정

심각도 기준을 산문으로 설명하지 말고, 각 수준에 대한 구체적인 코드 예시를 제공해야 한다.

태스크 4.2: Few-Shot 프롬프팅

Few-shot 예시는 일관성을 위한 가장 효과적인 기법이다. 더 많은 지시사항보다, 신뢰도 임계값보다 효과적이다.

투입 시점

  • 상세한 지시사항만으로는 일관성 없는 포맷이 생성될 때
  • 모델이 모호한 케이스에서 일관성 없는 판단을 내릴 때
  • 추출 작업에서 실제로 존재하는 정보에 대해 빈/null 필드가 생성될 때

구성 방법

  • 모호한 시나리오에 대해 2~4개의 타겟 예시 작성
  • 각 예시는 왜 하나의 행동이 가능한 대안보다 선택되었는지 이유를 보여줘야 한다
  • 이렇게 하면 단순한 패턴 매칭이 아닌 새로운 케이스로의 일반화가 가능하다

환각(Hallucination) 감소 효과

다양한 문서 구조(인라인 인용 vs 참고문헌, 서술형 vs 구조화 표)의 올바른 처리를 보여주는 few-shot 예시는 추출 품질을 극적으로 향상시킨다.

태스크 4.3: tool_use를 사용한 구조화 출력

신뢰성 계층

방법 신뢰성
JSON 스키마를 포함한 tool_use 구문 오류를 완전히 제거
프롬프트 기반 JSON 모델이 잘못된 형식의 JSON을 생성할 수 있음

tool_use가 방지하지 못하는 것

  • 의미적 오류: 라인 항목의 합이 명시된 합계와 일치하지 않음
  • 필드 배치 오류: 잘못된 필드에 값이 들어감
  • 날조: 소스에 정보가 없는 경우 모델이 필수 필드의 값을 발명함

스키마 설계 원칙

{
  "type": "object",
  "properties": {
    "invoice_number": { "type": "string" },
    "total_amount": { "type": ["number", "null"] },  // nullable - 소스에 없을 수 있음
    "payment_method": {
      "type": "string",
      "enum": ["credit_card", "bank_transfer", "cash", "unclear", "other"]  
      // "unclear"와 "other" enum 값으로 날조 방지
    },
    "payment_method_detail": { "type": "string" }  // "other" 케이스를 위한 자유 텍스트
  }
}
  • Nullable/Optional 필드: 소스에 정보가 없을 수 있는 경우. 날조를 방지한다.
  • "unclear" enum 값: 모호한 케이스를 처리한다.
  • "other" + 상세 문자열: 확장 가능한 분류를 위해.

태스크 4.4: 검증-재시도 루프

재시도 방법

# 에러 피드백과 함께 재시도
retry_prompt = f"""
원본 문서: {original_document}
실패한 추출: {failed_extraction}
특정 유효성 검사 오류: {validation_error}
위의 오류를 수정하여 다시 추출하세요.
"""

재시도 효과 경계

효과적인 경우 효과적이지 않은 경우
형식 불일치 소스 문서에 정보가 없는 경우
구조적 출력 오류
잘못된 위치의 값

시험에서 두 시나리오를 구분할 수 있어야 한다.

자기 수정 흐름

  • 불일치를 플래그하기 위해 stated_total과 함께 calculated_total 추출
  • 불일치하는 소스 데이터를 위해 conflict_detected 불리언 추가

태스크 4.5: 배치 처리

Message Batches API 특성

특성 세부 내용
비용 절감 50% 절약
처리 시간 최대 24시간
지연 시간 SLA 보장 없음
멀티턴 도구 호출 ❌ 지원 안 됨
요청-응답 매핑 custom_id로 상관관계 파악

동기 vs 배치 선택 기준

API 종류 사용 시점
동기 API 블로킹 워크플로우 (사전 병합 검사, 개발자가 기다리는 모든 것)
Batches API 지연 허용 워크플로우 (야간 보고서, 주간 감사, 야간 테스트 생성)

시험에서 매니저가 "배치 API를 모든 것에 사용하자"고 제안하는 문제가 나온다. 올바른 답은 블로킹 워크플로우는 계속 동기식을 유지하는 것이다.

태스크 4.6: 멀티 인스턴스 리뷰

자기 리뷰의 한계

동일한 세션에서 자신의 출력을 검토하는 모델은 이전 추론 컨텍스트를 유지하고 있어, 자신의 결정을 의문시할 가능성이 낮다. 독립 인스턴스는 더 많은 미묘한 문제를 발견한다.

멀티 패스 아키텍처

  1. 파일별 로컬 분석 패스: 파일당 일관된 깊이를 보장한다.
  2. 별도의 크로스 파일 통합 패스: 파일 간 데이터 흐름 문제를 발견한다.

이를 통해 주의 희석과 모순된 발견을 방지한다.

신뢰도 기반 라우팅

  • 모델이 발견 사항별로 자신의 신뢰도를 자체 보고
  • 신뢰도가 낮은 발견 사항을 인간 리뷰로 라우팅
  • 라벨이 붙은 유효성 검사 세트를 사용하여 신뢰도 임계값을 보정

도메인 4 빌드 실습

목표: JSON 스키마(필수, 선택, nullable 필드, "other" 포함 enum)로 추출 도구 생성. 검증-재시도 루프 구현. 10개 문서 처리 후 varied 형식을 위한 few-shot 예시 추가. before/after 추출 품질 비교.

8. 도메인 5: 컨텍스트 관리 & 신뢰성 (15%)

가장 낮은 비중이지만, 여기서의 실수는 모든 도메인에 연쇄적으로 영향을 미친다. 컨텍스트 관리 문제는 에이전트 실패, 잘못된 추출, 신뢰할 수 없는 합성으로 이어진다.

태스크 5.1: 컨텍스트 보존

점진적 요약의 함정

대화 히스토리를 압축할 때 수치 데이터, 날짜, 고객 기대값이 손실된다.

"고객이 2024년 3월 3일에 주문번호 #8891로 구매한 항목에 대해 $247.83 환불을 원합니다" → 압축 후 → "고객이 최근 주문에 대한 환불을 원합니다"

이것은 수용할 수 없는 정보 손실이다.

해결책: 거래 사실(transactional facts)을 영구 "케이스 사실(case facts)" 블록에 추출한다. 모든 프롬프트에 포함시킨다. 절대 요약하지 않는다.

"중간에서 길을 잃는" 효과 (Lost in the Middle)

모델은 긴 입력의 시작과 끝 부분을 안정적으로 처리한다. 중간에 묻혀 있는 발견 사항은 놓칠 수 있다.

해결책: 핵심 발견 요약을 처음에 배치하고, 전체에 걸쳐 명시적인 섹션 헤더를 사용한다.

도구 결과 트리밍

주문 조회가 40개 이상의 필드를 반환하지만 5개만 필요한 경우, 컨텍스트에 추가하기 전에 관련 필드만 남기도록 트리밍해야 한다. 관련 없는 데이터가 누적되면 토큰 예산이 고갈된다.

태스크 5.2: 에스컬레이션과 모호성 해결

3가지 유효한 에스컬레이션 트리거

  1. 고객이 명시적으로 인간을 요청: 즉시 처리한다. 먼저 해결하려 하지 말 것.
  2. 정책 예외 또는 공백: 요청이 문서화된 정책의 범위를 벗어남 (예: 정책이 자사 사이트만 커버하는데 경쟁사 가격 매칭 요청이 들어옴)
  3. 의미 있는 진전 불가: 에이전트가 해결을 진전시킬 수 없음

2가지 신뢰할 수 없는 트리거 (시험에서 유혹적으로 제시됨)

  • 감정 기반 에스컬레이션: 불만이 케이스 복잡성과 상관관계가 없다.
  • 자기 보고 신뢰도 점수: 모델은 어려운 케이스에서 잘못되게 자신감이 있고, 쉬운 케이스에서 불확실해질 수 있다.

불만 고객 처리 세분화

  • 문제가 간단하고 고객이 불만인 경우: 불만을 인정하고 해결책을 제시한다.
  • 도움을 제공한 후 고객이 인간 에이전트를 다시 요청하는 경우에만 에스컬레이션한다.
  • 고객이 명시적으로 "인간과 얘기하고 싶다"고 말하는 경우: 즉시 에스컬레이션하고, 먼저 조사하지 않는다.

태스크 5.3: 에러 전파

구조화 에러 컨텍스트

에러를 전파할 때 포함해야 할 내용:

  • 실패 유형 (일시적, 검증, 비즈니스, 권한)
  • 시도한 것 (사용된 특정 쿼리, 파라미터)
  • 실패 전에 수집된 부분 결과
  • 잠재적 대안 접근 방식

2가지 안티패턴

안티패턴 1: 에러 조용한 억제 빈 결과를 성공으로 표시하여 반환한다. 이렇게 하면 어떤 복구도 불가능하다.

안티패턴 2: 단일 실패로 전체 워크플로우 종료 하나의 서브에이전트가 실패하면 전체 파이프라인을 죽인다. 이렇게 하면 모든 부분 결과가 버려진다.

커버리지 주석

합성 출력은 어떤 발견이 충분히 뒷받침되는지와 어떤 영역에 공백이 있는지를 명시해야 한다. "저널 접근 불가로 인해 지열 에너지 섹션이 제한적입니다"가 조용히 생략하는 것보다 훨씬 낫다.

태스크 5.4: 코드베이스 탐색

컨텍스트 저하 문제

긴 세션에서 모델이 이전에 발견한 특정 클래스 대신 "전형적인 패턴"을 참조하기 시작한다. 컨텍스트가 상세한 탐색 출력으로 가득 차면서 초기 발견 사항에 대한 파악력을 잃는다.

완화 전략

전략 설명
스크래치패드 파일 핵심 발견 사항을 파일에 기록하고 후속 질문에서 참조
서브에이전트 위임 특정 조사를 위해 서브에이전트를 생성, 메인 에이전트는 고수준 조정 유지
요약 주입 한 단계의 발견 사항을 요약한 후 다음 단계를 위한 서브에이전트 생성
/compact 컨텍스트가 상세한 탐색 출력으로 가득 찼을 때 사용

태스크 5.5: 인간 리뷰와 신뢰도 보정

집계 지표의 함정

97%의 전체 정확도는 특정 문서 유형에서 40%의 오류율을 숨길 수 있다.

자동화하기 전에 항상 문서 유형별 AND 필드 세그먼트별로 정확도를 검증해야 한다.

계층화 무작위 샘플링

진행 중인 검증을 위해 높은 신뢰도 추출 결과를 샘플링한다. 이렇게 하면 원래 감지되지 않을 새로운 오류 패턴을 발견할 수 있다.

태스크 5.6: 정보 출처 관리 (Information Provenance)

구조화 클레임-소스 매핑

{
  "claim": "태양광 패널 비용이 2023년 대비 15% 하락",
  "source_url": "https://example.com/solar-report",
  "document_name": "2024 태양광 시장 보고서",
  "relevant_excerpt": "평균 패널 비용은 전년 대비...",
  "publication_date": "2024-03-15"
}

다운스트림 에이전트는 합성을 통해 이 매핑을 보존하고 병합해야 한다. 요약 중에 출처가 손실되면 안 된다.

충돌 처리

두 신뢰할 수 있는 소스가 서로 다른 통계를 보고하는 경우, 임의로 하나를 선택하지 말아야 한다. 두 값과 소스 귀속을 모두 주석으로 달아 소비자가 판단하도록 해야 한다.

시간적 인식

구조화 출력에 발행/데이터 수집 날짜를 요구한다. 날짜가 다르면 숫자가 달라지는 이유를 설명할 수 있다. 날짜 없이는 이것이 모순처럼 보일 수 있다.

컨텐츠 적절 렌더링

컨텐츠 유형 렌더링 형식
금융 데이터 테이블
뉴스 산문
기술적 발견 사항 구조화 목록

모든 것을 동일한 형식으로 평탄화하지 않는다.

도메인 5 빌드 실습

목표: 2개의 서브에이전트가 있는 코디네이터 구축. 영구 케이스 사실 블록 구현. 구조화 에러 전파로 타임아웃 시뮬레이션. 충돌하는 소스로 테스트하여 합성이 출처 귀속을 보존하는지 확인.

9. Anthropic 공식 추천 학습 자료

@hooeem이 공유한 Anthropic의 공식 추천 학습 자료 4가지다.

번호 과정명 내용
1 Building with the Claude API Claude API를 사용한 애플리케이션 구축 방법
2 Introduction to Model Context Protocol MCP 프로토콜 소개 및 통합 방법
3 Claude Code in Action Claude Code의 실제 활용 사례
4 Claude 101 Claude 기초 개념

도메인별 심화 학습 자료

도메인 1 (에이전트 아키텍처):

  • Agent SDK Overview — 에이전트 루프 메커니즘과 서브에이전트 패턴
  • Building Agents with the Claude Agent SDK — 훅, 오케스트레이션, 세션에 대한 Anthropic 모범 사례
  • Agent SDK Python repo + examples — 훅, 커스텀 도구, fork_session 실습 코드

도메인 2 (도구 설계 & MCP):

  • MCP Integration for Claude Code — 서버 스코핑, 환경 변수 확장, 프로젝트 vs 사용자 설정
  • MCP 명세 및 커뮤니티 서버 — 프로토콜 이해, 커뮤니티 서버 vs 커스텀 빌드 판단
  • Claude Agent SDK TypeScript repo — 도구 정의 패턴 및 구조화 에러 응답

도메인 3 (Claude Code 설정):

  • Claude Code 공식 문서 — CLAUDE.md 계층, rules 디렉토리, 슬래시 커맨드, 스킬 프론트매터
  • Claude Code CLI 치트시트 — 명령어, 스킬, 훅, CI/CD 플래그 실용 레퍼런스
  • Creating the Perfect CLAUDE.md — 실제 팀 설정 패턴과 MCP 통합

도메인 4 (프롬프트 엔지니어링):

  • Anthropic 프롬프트 엔지니어링 문서 — few-shot 패턴, 명시적 기준, 구조화 출력
  • Anthropic API Tool Use 문서 — tool_use, tool_choice 설정, JSON 스키마 강제

도메인 5 (컨텍스트 관리):

  • Building Agents with the Claude Agent SDK — 컨텍스트 관리, 에러 전파, 에스컬레이션 설계
  • Agent SDK 세션 문서 — 재개, fork_session, /compact
  • Everything Claude Code repo — 검증된 컨텍스트 관리 패턴, 스크래치패드 파일, 전략적 압축

10. 마무리: 수료증 없이도 Claude 아키텍트가 되는 법

핵심 요약

이 가이드에서 다룬 기술들은 다음으로 요약된다.

도메인 1의 가장 중요한 교훈: 서브에이전트는 컨텍스트를 공유하지 않는다. 모든 것을 명시적으로 전달하라. 고위험 상황에는 반드시 훅을 사용하라.

도메인 2의 가장 중요한 교훈: 도구 설명이 도구 선택을 결정한다. 설명이 모호하면 라우팅이 신뢰할 수 없어진다. 가장 낮은 노력의 수정부터 시작하라.

도메인 3의 가장 중요한 교훈: 설정 파일의 위치가 결과를 결정한다. 팀 전체에 적용해야 하는 것은 반드시 프로젝트 레벨에 있어야 한다.

도메인 4의 가장 중요한 교훈: 명시적이 되어라. 막연한 지시사항은 아무것도 개선하지 못한다. Few-shot 예시가 가장 강력한 일관성 도구다.

도메인 5의 가장 중요한 교훈: 거래 데이터는 절대 요약하지 마라. 에러는 조용히 억제하지 마라. 에스컬레이션 트리거는 신뢰할 수 있는 신호에 기반해야 한다.

수익화 가능한 기술들

@hooeem이 강조한 대로, 이 가이드에서 다루는 모든 기술은 직접 수익화가 가능하다.

  • 에이전트 개발: 기업용 자동화 솔루션 구축 (고객 지원, 연구 자동화, 데이터 추출)
  • MCP 통합: 팀의 기존 도구(Jira, GitHub, Slack, Salesforce 등)와 Claude 통합
  • CI/CD 자동화: 코드 리뷰, 테스트 생성, 품질 게이팅 자동화
  • 구조화 데이터 추출: 비정형 문서에서 정형 데이터를 추출하는 파이프라인
  • 개발자 생산성: 팀 표준이 내장된 Claude Code 설정으로 개발 속도 향상

마지막 당부

수료증은 능력을 증명하지 않는다. 실제로 구축하는 것이 능력을 증명한다.

이 가이드에서 제안하는 각 도메인의 빌드 실습을 실제로 구현하라. 이론을 읽는 것과 프로덕션 수준의 에이전트 시스템을 실제로 구축하는 것은 전혀 다른 경험이다.

Claude Certified Architect 시험을 볼 수 없더라도, 이 지식을 갖추고 있다면 당신은 이미 비공인 Claude 아키텍트다.

이 문서는 X(트위터) @hooeem의 스레드를 기반으로 작성되었습니다. 원문: https://x.com/hooeem/status/2033198345045336559