이번 주 많은 시간을 쪼개어 클로드 공인 아키텍트(Claude Certified Architect) 시험을 준비했다. 모든 수험 가이드가 입을 모아 가장 먼저 마스터하라고 강조하는 영역은 바로 “비즈니스 문제를 클로드 기반 AI 솔루션으로 번역하기(Translate business problems into Claude-based AI solutions)“였다. 나는 이것이 아주 명확하고 잘 정의된 역량일 것이라 짐작했다. 하지만 뚜껑을 열어보니 전혀 그렇지 않았다. 10여 개의 수험 자료와 공식 시험 가이드를 꼼꼼히 비교해 본 결과, 시중의 프레임워크는 절반이 신화이자 맹목적인 모방(cargo cult)에 불과했으며, 진짜 문제 해결 능력은 교재들이 거의 언급하지 않는 7개의 공식 태스크(Task statement) 안에 숨어 있었다.

공부하며 깨달은 사실과 실제로 시험 대비에 유효한 핵심 내용들을 정리해 본다.

시험 명칭부터 “Professional”이 아니다

시중에 돌아다니는 수험 자료 대부분은 이 시험을 “Anthropic Certified Architect – Professional”이라고 부르며 도메인 1의 출제 비중을 17%라고 안내한다. 둘 다 틀렸다.

진짜 시험의 공식 명칭은 **Claude Certified Architect – Foundations (CCA-F)**이며, 앤트로픽 파트너 네트워크의 일환으로 2026년 3월 13일에 정식 출시되었다. 총 60문항으로 100점에서 1,000점 만점 체계이며, 합격 커트라인은 720점이다. 도메인 1의 정식 명칭은 “에이전틱 아키텍처 및 오케스트레이션(Agentic Architecture & Orchestration)“이며, 출제 비중은 17%가 아니라 무려 **27%**에 달한다. “솔루션 설계 및 아키텍처”라는 이름도 아니다.

이 차이가 중요한 이유는 잘못된 도메인 명칭으로 공부하면 시험 준비의 무게중심이 엉뚱한 곳으로 쏠리기 때문이다. 이 시험은 막연하고 일반적인 솔루션 설계가 아니라, ’에이전틱 아키텍처와 오케스트레이션’에 직접적인 점수를 부여한다. 비즈니스 문제를 기술로 번역하는 역량은 배경 지식(substrate)일 뿐, 시험의 헤드라인이 아니다.

“비즈니스 문제 번역”은 공식 태스크가 아니다

가장 놀라웠던 부분이다. 앤트로픽이 발행한 공식 가이드 PDF를 글자 하나하나 정독했다. 그 문서 어디에도 “비즈니스 문제를 클로드 기반 AI 솔루션으로 번역하기”라는 제목의 태스크는 존재하지 않는다. 도메인 1은 물론 전체 가이드 어디에도 없다.

공식 도메인 1에 적혀 있는 진짜 7가지 태스크는 다음과 같다.

1.1 자율적 작업 수행을 위한 에이전틱 루프 설계 및 구현
1.2 코디네이터-서브에이전트 패턴을 활용한 멀티 에이전트 시스템 오케스트레이션
1.3 서브에이전트 호출, 컨텍스트 전달 및 생성(spawning) 구성
1.4 강제(enforcement) 및 핸드오프(handoff) 패턴을 활용한 다단계 워크플로우 구현
1.5 툴 호출 인터셉트 및 데이터 정규화를 위한 Agent SDK 훅(hook) 적용
1.6 복잡한 워크플로우를 위한 태스크 분해(task decomposition) 전략 설계
1.7 세션 상태, 재개(resumption) 및 포킹(forking) 관리

’비즈니스 문제를 기술로 번역하는 능력’은 바로 이 7가지 태스크 질문에 정답을 고르기 위해 필요한 밑바탕이다. 모든 공식 시나리오 문제는 비즈니스 맥락(고객 지원 봇, 멀티 에이전트 리서치 시스템, 비정형 데이터 추출 등)에서 출발하며, 수험자는 이를 올바른 아키텍처로 매핑해야 한다. 하지만 채점 기준은 비즈니스 문제를 얼마나 우아하게 말로 설명했는가가 아니라, 올바른 아키텍처 형태를 선택했는가이다.

이 미묘한 차이가 “수험서 10권을 훑어본 사람”과 “실제로 시험에 합격하는 사람”을 가른다.

실전에서 통하는 5단계 아키텍처 매핑 프레임워크

공부에 실제로 활용할 수 있도록, 시중 가이드들의 공통 분모와 앤트로픽의 공식 엔지니어링 블로그(“Building Effective Agents”)를 종합하여 도출한 5단계 프레임워크다.

1단계 — 고통의 발견과 분해 (Discover & Deconstruct)

아키텍처를 고민하기 전에 진짜 고통이 어디에 있는지 파악해야 한다.

  • 고통을 겪는 주체는 누구인가? (경영진, 실무자, 최종 고객?)
  • 어떤 도구를 원하는지가 아니라, 궁극적으로 달성하려는 목표가 무엇인가? (Job to be done)
  • 현재는 그 일을 어떻게 처리하고 있는가? (기준선 — 비용, 소요 시간, 오류율)
  • 제약 조건은 무엇인가? (규제 요건, 지연 시간 한도, 비용 상한선, 인간 개입 필수 여부)
  • 성공을 나타내는 단 하나의 정량적 지표는 무엇인가? (성공 메트릭)

모든 수험서가 이를 강조하며, 시험의 모든 시나리오는 수험자가 이 지점을 짚어냈는지 테스트한다.

2단계 — 클로드가 필요한 문제인지 판별 (Claude Fit Test)

다음 질문을 던져 클로드 도입의 타당성을 검증한다.

  1. 입력이나 출력이 비정형 자연어인가? 아니라면 전통적인 결정론적 코드를 써라.
  2. 모호함을 해석하거나, 주관적 판단이나 종합적 추론이 필요한가? 아니라면 규칙(rules) 기반 로직을 써라.
  3. 단순 조회를 넘어선 배경 지식이나 논리적 추론이 필요한가? 그렇다면 클로드가 강력한 후보다.
  4. 실패가 발생했을 때 인간 개입(HITL)이나 안전장치로 피해를 막을 수 있는가? 통제 불가능하다면 완전 자동화를 적용해서는 안 된다.

시중 연습 문제 중 상당수가 결정론적 코드가 훨씬 적합한 상황(예: 급여세 계산 등)임에도 “클로드를 써야 한다”고 무리수를 둔다. 시험에서는 과도하게 AI를 남발하는 오버엔지니어링 선택지에 감점을 준다.

3단계 — 문제의 형태 분류 (Classify the Problem Shape)

공식 시나리오를 살펴보면 대체로 다섯 가지 형태로 귀결된다.

문제 형태 기본 권장 패턴
분류 및 정보 추출 구조화된 출력을 사용하는 보강된 LLM (Augmented LLM)
생성 및 종합 워크플로우 (검색 → 생성 → 검증)
추론 및 의사결정 작업 분해 워크플로우 또는 에이전틱 루프
대화 및 오케스트레이션 명시적 도구와 에스컬레이션을 갖춘 에이전틱 시스템
탐색 및 리서치 RAG 또는 멀티 에이전트 리서치 시스템

시중 교재에서 흔히 보는 “보강된 LLM / 워크플로우 / 에이전틱” 3분법은 사실 부정확하다. 앤트로픽의 공식 위계에서 보강된 LLM은 기본 빌딩 블록이며, 상위 시스템의 형태는 워크플로우와 에이전트 두 가지뿐이다. 그리고 워크플로우에는 5가지 공식 서브 패턴이 존재한다: 프롬프트 체이닝(prompt chaining), 라우팅(routing), 병렬화(parallelization), 오케스트레이터-워커(orchestrator-workers), 평가자-최적화자(evaluator-optimizer). 시중 수험서 대부분이 이 5가지 공식 명칭을 빠뜨리고 있는데, 이는 명백한 결함이다.

4단계 — 아키텍처 형태 결정 및 도메인 1 기술 적용

워크플로우와 에이전트 중 하나를 선택한다.

  • 워크플로우: 입력이 예측 가능하고 단계가 정해져 있을 때 적합하다. 컴플라이언스, 감사, 정형화된 비즈니스 프로세스에 쓰인다.
  • 에이전트: 전체 단계 수를 사전에 예측할 수 없는 열린 문제에 적합하다.

앤트로픽이 강조하는 기본 원칙: 가장 단순한 구조에서 시작하고, 단순한 구조가 명백히 실패할 때만 더 복잡한 에이전트로 확장하라. 대다수 프로덕션 시스템은 에이전트가 아니라 워크플로우여야 한다.

어떤 형태를 골랐든, 시험에서 빈출되는 도메인 1의 핵심 구현 기술은 다음과 같다.

  • stop_reason 필드를 활용한 루프 제어: tool_use일 때는 루프를 계속 돌리고, end_turn일 때만 종료한다. 자연어를 파싱해서 종료 시점을 판단하거나, 단순 반복 횟수 제한을 주된 흐름 제어로 삼아서는 안 된다. 또한 response.content[0].type == "text"인지 검사하는 것으로 종료 여부를 판단해서도 안 된다(텍스트 블록과 tool_use 블록은 한 응답 안에 공존할 수 있다).
  • 허브 앤 스포크(Hub-and-spoke) 오케스트레이션과 격리된 컨텍스트: 서브에이전트는 코디네이터의 전체 대화 기록을 통째로 물려받지 않고 독립된 컨텍스트를 유지해야 한다.
  • 서브에이전트 생성을 위한 Task 툴: 코디네이터가 서브에이전트를 호출하려면 allowedTools에 “Task”가 명시되어 있어야 한다.
  • 규정 준수를 위한 프로그래밍 방식 강제(Programmatic enforcement): 시험에 가장 단골로 나오는 개념이다. “환불 전 고객 신원 확인 필수” 같은 비즈니스 규칙이 있다면, 프롬프트 지시문 따위에 기대지 말고 반드시 프로그래밍 방식의 게이트(gate)를 통해 강제해야 한다.
  • PostToolUse 훅: 결과 정규화 및 정책 검증을 위해 툴 실행 전후 훅을 적용한다.
  • 적절한 태스크 분해: 정형화된 다각도 검토에는 프롬프트 체이닝을, 열린 조사에는 동적 분해를 사용한다.

5단계 — 비즈니스 가치로 매핑

시험의 모든 선택지는 결국 측정 가능한 비즈니스 결과와 연결되어야 한다. 교재들이 반복하는 5대 가치는 효율성(Efficiency), 혁신(Transformation), 생산성(Productivity), 비용(Cost), SLA 성능(Performance SLAs)이다.

다만 한 가지 짚고 넘어갈 점이 있다. 앤트로픽의 공식 문서 어디에도 “가치 기둥(value pillars)“이라는 단어는 등장하지 않는다. 수험용으로는 유용한 틀일 수 있지만, 외부 교육 업체들이 만들어낸 프레임일 수 있다. 어쨌든 시험은 아키텍처 선택을 구체적인 비즈니스 수치와 연결할 줄 아는 수험자에게 높은 점수를 준다.

교재들이 정확히 지적한 함정 하나: “고객 지원 상담 시간 30% 단축”은 언뜻 생산성처럼 보이지만 실제로는 효율성(Efficiency)이다. 반면 “상담원이 지치지 않고 2배의 티켓을 처리하도록 지원”하는 것은 생산성(Productivity)이다. 이 표현의 차이가 중요한 이유는 요구되는 아키텍처 설계가 달라지기 때문이다.

수험서들이 잘못 해설하는 의료 청구서 문제

한 수험서에 다음과 같은 연습 문제가 실려 있었다.

한 의료 청구 회사가 150페이지 분량의 환자 기록(약 6만 토큰)을 5페이지 분량의 보험 약관 문서(약 2천 토큰)와 대조 분석해야 한다. 매일 2,000명의 서로 다른 환자에 대해 동일한 보험 약관을 처리한다. 이 보험 약관 문서를 어떻게 처리해야 할까?

  • 보기 A: 문서를 청크로 쪼개 검색하는 RAG 파이프라인 구축.
  • 보기 B: 시스템 프롬프트 맨 끝에 약관을 붙이고 프롬프트 캐싱을 적용한 뒤, 환자 기록은 유저 메시지로 전달.
  • 보기 C: 문서 맨 앞에 [co-locate] 태그와 함께 약관을 배치하고 프롬프트 캐싱을 활성화한 뒤 환자 기록 스트리밍.

교재는 정답을 명쾌히 설명하지 않는다. 정확한 해설은 다음과 같다.

A는 오답이다. RAG는 데이터가 방대하거나 동적으로 계속 변할 때 쓴다. 컨텍스트 윈도우에 충분히 들어가고 모든 요청에서 동일하게 반복되는 2천 토큰짜리 문서는 RAG가 아니라 프롬프트 캐싱(Prompt Caching)을 써야 하는 교과서적인 사례다.

B는 대체로 맞지만 미묘한 버그가 있다. 환자 기록이 들어가는 유저 메시지 쪽에 cache_control을 걸어버리면, 매 요청마다 접두사 해시가 달라져 캐시 히트가 일어나지 않는다. 캐시 중단점(breakpoint)은 가변 블록이 아니라 정적인 시스템 접두사의 마지막 블록에 걸어야 한다. 앤트로픽 공식 문서에서도 흔히 범하는 실수로 경고하는 부분이다.

C는 완전히 오답이다. [co-locate]라는 태그는 클로드에 존재하지 않는다. 다른 플랫폼의 문법을 가져왔거나 환각된 단어다. 클로드의 프롬프트 캐싱은 접두사 일치(prefix matching)를 통해 이미 물리적으로 인접 처리된다.

올바른 구현은 시스템 프롬프트에 보험 약관을 두고, 약관의 마지막 블록에 cache_control: { type: "ephemeral" }을 지정한 후, 유저 메시지로 환자 기록을 넘기는 것이다. 하루 2,000건의 동일 약관 요청이 들어오면 캐시 쓰기 비용은 1회만 지불하고 나머지 1,999건은 기본 입력 비용의 10%만 내면 된다. 약관 처리 비용이 90% 절감된다.

그런데 더 중요한 반전이 있다. 공식 CCA-F 시험에서 프롬프트 캐싱의 세부 구현 문법은 출제 범위 제외(out of scope) 항목이다. 공식 가이드 PDF에는 “프롬프트 캐싱의 개념적 존재 여부를 넘어선 구체적 구현 디테일”은 출제되지 않는다고 명시되어 있다. 즉, 직관을 기르는 데는 유용한 문제지만 실제 시험 문제의 형태와는 거리가 있다.

반드시 외워야 할 6가지 안티패턴

시험에서 반복해서 오답으로 유도하는 대표적인 6가지 안티패턴이다.

  1. 루프 종료를 자연어 파싱으로 판단하는 것: 반드시 stop_reason을 확인해야 한다.
  2. 임의의 반복 횟수 제한(iteration cap)을 주 제어 흐름으로 사용하는 것: 반복 제한은 폭주를 막는 안전망이지 제어 흐름이 아니다.
  3. 어시스턴트 텍스트 내용으로 완료 여부를 판단하는 것: 텍스트 블록과 툴 호출 블록은 동시에 반환될 수 있다.
  4. 엄격한 규정 준수가 필요한 곳에 프롬프트 지시문만 사용하는 것: 금융, 본인 인증, 결제·환불은 반드시 프로그래밍 방식의 훅/게이트로 강제해야 한다.
  5. 툴 설명의 중복: 설명이 부실한 18개의 툴을 던져주면 모델의 도구 선택 능력이 급격히 떨어진다. 이름을 명확히 바꾸고, 쪼개고, 차별화해야 한다.
  6. 방대한 입력에 대한 단일 패스(single-pass) 검토: 어텐션 희석으로 인해 상충되는 결과가 나온다. 항목별 개별 패스를 돌린 뒤 종합 패스를 거쳐야 한다.

실전 준비를 위한 권고사항

비즈니스 문제를 기술로 번역하는 감각은 매우 중요하다. 거의 모든 시험 문제의 밑바탕에 깔려 있기 때문이다. 하지만 수험서의 추상적인 5단계 프레임워크를 달달 외우는 것은 합격의 길이 아니다. 도메인 1의 7가지 공식 태스크와 그 안의 구현 기술 목록을 뼈대에 새겨야 한다.

외주 강사들이 만든 “도메인 1.1 = 비즈니스 문제 번역”이라는 프레임은 강의 커리큘럼을 짜기에는 편할지 몰라도, 실제 시험의 평가 방식과는 거리가 있다. 시험은 문제를 얼마나 잘 번역했는가가 아니라, 그 번역을 바탕으로 올바른 아키텍처적 결정을 내렸는가를 채점한다.

CCA-F 시험을 준비하는 분들을 위한 현실적인 조언:

  1. 공식 시험 가이드 PDF를 처음부터 끝까지 정독하라. 군더더기 없이 짧고 명확하다.
  2. 앤트로픽 공식 엔지니어링 블로그의 “Building Effective Agents”를 반드시 읽어라. 시험이 전제하는 워크플로우와 에이전트의 구분이 여기에 정의되어 있다.
  3. 플랫폼 공식 문서에서 프롬프트 캐싱, Stop Reason, Agent SDK 개요를 숙지하라.
  4. 도메인 1의 7가지 태스크를 직접 코드로 구현해 보라. 서브에이전트, 프로그래밍 방식 강제 게이트, stop_reason 루프를 직접 손으로 만들어 봐야 한다.
  5. 그 후 시간이 남는다면, 자신의 설계를 비즈니스 관점에서 설명하기 위한 보조 수단으로 비즈니스 가치 프레임워크를 얹어라.

시험은 프레임워크를 암기한 사람이 아니라, 아키텍처를 깊이 고민하고 직접 만들어본 사람에게 합격을 안겨준다. 이름표를 붙이기 전에 먼저 손으로 만들어보자.