Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

URL: https://www.youtube.com/watch?v=Z-c11pV_uvU 날짜: 2026-08-09 채널: aiDotEngineer 영상 ID: Z-c11pV_uvU

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

이 영상은 ==Anthropic의 Claude Certified Architect(CCA) 시험이 단순한 자격증이 아니라, agentic AI 시대를 준비하는 실전 지침서(field guide)가 될 수 있는가?==라는 질문을 던진다.

• 발표자 Frank Coyle은 30년 넘게 컴퓨터 과학을 가르쳐왔고, 현재 UC Berkeley에서 학생들이 AI 시대에 어떻게 취업 역량을 쌓을지 고민하고 있다.
• Anthropic이 CCA 시험을 설계하면서 현업에서 실제로 발생하는 agentic AI 문제들을 반영했기 때문에, 시험 범위가 곧 실무 역량 체크리스트가 된다.
• 시험의 핵심은 단순 암기가 아니라, ==각 시나리오에서 하면 안 되는 반패턴(anti-pattern)==을 아는 것이다.
• 루프, 전문화, 맥락 분리, 비용 최적화 등의 개념은 agentic AI를 넘어 일반적인 소프트웨어 엔지니어링 원칙과도 연결된다.

CCA 시험을 준비하며 배우는 다섯 가지 프로덕션 시나리오와 반패턴은, LLM 기반 에이전트를 설계하고 운영하는 실무자들에게 구체적인 체크리스트를 제공한다.

---

1. 도입: 왜 CCA 시험인가?

1.1. 발표자와 강의의 배경

1. Frank Coyle 소개

   1. 30년 이상 컴퓨터 과학 교육 경력: 현재 UC Berkeley에서 가르치고 있다.
   2. 학생들의 고민: 과거처럼 컴퓨터 과학 학위가 취업의 마법 같은 통행증(magic pathway)이 아니라는 인식이 확산되고 있다.
   3. agentic AI 준비의 필요성: 학생들이 AI와 함께 일하는 세상에서 어떤 역량을 쌓아야 할지 찾는 방법으로 CCA 시험을 주목했다.

2. 영상의 시작과 철학적 인용

   1. Sister Corita Kent의 인용: "Nothing is a mistake. There's no win and no fail. There's only make."(실수는 없다. 성패도 없다. 오직 만들기만 있다.)
   2. Thomas Edison의 인용: "I have not failed. I've only found 10,000 ways that don't work."(나는 실패한 적이 없다. 다만 작동하지 않는 10,000가지 방법을 찾았을 뿐이다.)
   3. 실험 강조: 읽기만 하지 말고 직접 만들고(make stuff) 시도해야 한다. 이는 시험 준비의 자세이기도 하다.

1.2. 반패턴(anti-pattern)의 가치

1. 디자인 패턴 운동의 연장
   1. 1990년대 객체지향 디자인 패턴: 객체를 위한 패턴이 있었듯, 이제는 에이전트를 위한 패턴이 등장하고 있다.
   2. 패턴과 반패턴: 무엇을 해야 하는지뿐 아니라 무엇을 해서는 안 되는지를 아는 것이 정답으로 이끈다.
   3. 실용적 관점: CCA 시험의 각 시나리오는 반패턴을 피하는 방법을 묻는다.

---

2. CCA 시험 개요

2.1. 시험의 기본 정보

1. 시험명과 출시 시점

   1. Claude Certified Architect(CCA): Anthropic이 출시한 공식 시험이다.
   2. 출시 시기: 2026년 3월에 출시되어 아직 새로운 시험이다.
   3. 시험 형식: 시간 제한이 있고 감독(proctored)이 있는 시나리오 기반 다지선다형 시험이다.

2. 응시 조건과 비용

   1. 개인 응시: 99달러를 내면 6개월에 한 번씩 응시할 수 있다.
   2. 기업 응시: Claude 생태계 기업(Anthropic ecosystem) 내부에서도 활용할 수 있다.
   3. 실용성: 시험을 보지 않더라도 범위 자체가 agentic AI 실무 체크리스트가 된다.

2.2. 다섯 시험 영역과 비중

1. Agentic Architecture — 27%

   1. 에이전트의 구조, 루프, 도구 호출, 상태 관리 등 전반적인 아키텍처 설계 능력을 평가한다.

2. Claude Code — 20%

   1. Claude Code 시스템과 워크플로우를 어떻게 구성하는지를 다룬다.
   2. Claude.md, 규칙 설정, CI/CD 연동 등이 포함된다.

3. Prompt Engineering — 20%

   1. 프롬프트 설계, 출력 구조화, JSON 활용 등을 다룬다.
   2. 단순한 질문 작성을 넘어 결과물의 형태를 통제하는 능력이 핵심이다.

4. Tool Design & Model Context Protocol(MCP) Integration — 20%

   1. 도구 설계와 MCP 통합을 다룬다.
   2. LLM이 어떤 도구를 언제 호출할지, 도구 스키마는 어떻게 정의할지 등이 포함된다.

5. Context Management & Reliability — 13%

   1. 맥락 관리와 신뢰성, 비용, 오류 처리를 다룬다.
   2. 긴 세션 관리, 토큰 최적화, 휴먼 인 더 루프 등이 포함된다.

2.3. 시험의 시나리오 구성

1. 6개의 프로덕션 시나리오 중 4개 출제
   1. 시험은 6개 시나리오 중 무작위로 4개를 선택해 질문을 구성한다.
   2. 각 시나리오는 현실적 제약과 상황을 반영한 문제를 제시한다.
   3. 영상에서는 다음 5가지 시나리오를 직접 다룬다.

---

3. 시나리오 1: Customer Support Resolution Agent

3.1. 시나리오의 핵심

1. 목표: 고객 지원 요청을 처리하는 에이전트를 설계한다.
2. 핵심 메커니즘: LLM과 도구를 반복적으로 교환하는 ==에이전트 루프(agentic loop)==를 구성해야 한다.

3.2. 반패턴: 한 번 호출하고 끝내기

1. 단발성 호출의 문제

   1. LLM에 한 번 질문하고 나온 답변을 그대로 사용하는 것은 위험하다.
   2. LLM은 도구를 직접 실행할 수 없으며, 실행에 필요한 파라미터만 생성할 수 있다.
   3. "에이전트가 알아서 다 한다"는 착각을 버려야 한다.

2. 올바른 접근: stop reason을 활용한 루프

   1. while True 루프: LLM 호출 → stop reason 확인 → 도구 실행 → 결과를 다시 LLM에 전달을 반복한다.
   2. stop reason의 세 가지 주요 상태: tool_use(도구 사용 필요), end_turn(응답 완료), max_tokens(토큰 한도 초과로 중단).
   3. 도구 실행 블록: LLM이 반환한 파라미터를 가지고 실제 코드에서 도구를 실행하고, 그 결과를 다시 컨텍스트에 추가한다.

3.3. 휴먼 인 더 루프와 신뢰성

1. 최종 답변 검토

   1. 루프가 종료된 후 답변의 신뢰도(confidence)를 확인하는 기회를 만든다.
   2. 신뢰도가 낮으면 인간에게 에스컬레이션(escalate)한다.

2. max_tokens stop reason의 위험성

   1. 토큰 한도에 걸려 중단된 응답은 부분적으로 생성된 내용을 포함할 수 있다.
   2. 이를 그대로 사용하면 왜곡된 결과를 초래할 수 있으므로, stop reason을 반드시 확인해야 한다.

---

4. 시나리오 2: Code Generation with Claude Code

4.1. Claude.md의 역할

1. 프로젝트 규칙 파일

   1. Claude Code는 Claude.md라는 마크다운 파일을 통해 프로젝트별 규칙을 학습한다.
   2. 이 파일에는 코드 스타일, 아키텍처 원칙, 테스트 방법, 금지 사항 등을 기록한다.

2. 계층적 규칙 구조

   1. 프로젝트 최상위: 전체 프로젝트에 적용되는 최상위 Claude.md.
   2. 프로젝트 폴더 수준: 하위 모듈이나 서비스별 규칙.
   3. 디렉터리 수준: 특정 디렉터리나 파일 그룹에만 적용되는 세부 규칙.
   4. 계층화의 효과: 모델이 상황에 맞는 규칙을 참조하여 일관되고 적절한 코드를 생성한다.

4.2. 반패턴과 모범 사례

1. 반패턴: 규칙 없이 생성하기

   1. 프로젝트의 컨텍스트 없이 코드 생성을 요청하면 품질과 일관성이 떨어진다.
   2. Claude.md를 통해 팀의 합의된 규칙을 모델에 주입해야 한다.

2. 모범 사례: 점진적 규칙 확장

   1. 작은 프로젝트에서는 최상위 규칙만으로 충분할 수 있다.
   2. 규모가 커질수록 폴더와 디렉터리 단위로 규칙을 세분화하여 모델의 혼란을 줄인다.

---

5. 시나리오 3: Multi-Agent Research System

5.1. 반패턴: 만능 에이전트 만들기

1. 도구 과다 탑재의 문제

   1. 모든 도구를 한 에이전트에 주는 것은 "백만 개 도구를 가진 잡일꾼"을 고용하는 것과 같다.
   2. Coyle은 목수를 고용했는데 배관·전기 공구까지 모두 가지고 온 사람을 원하지 않는다는 비유로 설명한다.
   3. 도구가 많아질수록 에이전트의 집중력과 정확도가 떨어진다.

2. 함수형 프로그래밍의 교훈

   1. 단일 책임 원칙: 함수는 한 가지 일을 잘해야 한다.
   2. 에이전트 전문화: 각 에이전트를 하나의 명확한 역할에 특화하고, 사용 가능한 도구를 1~2개로 제한한다.

5.2. 맥락 분리와 집단 사고 방지

1. 맥락 유출의 비용

   1. 에이전트에게 불필요한 맥락을 주면 토큰 비용이 증가한다.
   2. 100만 토큰 맥락 창이 있어도 모든 것을 넣으면 모델이 혼란스러워진다.
   3. 핵심 원칙: 에이전트가 필요한 최소한의 정보만 전달해야 한다.

2. 집단 사고(groupthink)의 위험성

   1. 여러 에이전트가 서로 대화할 때 하나의 아이디어로 수렴하는 경향이 있다.
   2. Coyle은 "모두가 피자를 원하는 파티에서 자신도 따라가게 되는" 상황에 비유한다.
   3. 해결책: 각 에이전트에게 claim과 evidence만 전달하고, 사고 과정이나 다른 에이전트의 내부 생각은 숨긴다.
   4. 비유: "각 에이전트에게 피자 한 조각씩만 주는" 것처럼 맥락을 슬라이스화한다.

5.3. 전문화된 하위 에이전트 예시

1. Critic(비평가) 에이전트
   1. 특정 주장(claim)과 근거(evidence)만 받아 검토한다.
   2. 다른 에이전트의 생각 과정이나 전체 맥락을 주지 않는다.
   3. 이렇게 해야 비평이 독립적이고 유용해진다.

---

6. 시나리오 4: Developer Productivity

6.1. 반패턴: 하위 작업 출력을 메인 스레드에 그대로 쌓기

1. 맥락 오염의 문제

   1. 하위 작업의 전체 출력을 메인 스레드에 주입하면 메인 맥락이 복잡해진다.
   2. 이는 토큰 비용 증가와 정확도 저하를 동시에 초래한다.

2. 맥락이 무제한이라는 착각

   1. 100만 토큰의 맥락 창이 있어도 무엇이든 다 넣어서는 안 된다.
   2. LLM은 맥락이 커질수록 집중력과 정확도가 떨어지는 경향이 있다.

6.2. 모범 사례: Context Fork와 Compaction

1. Context Fork(맥락 분기)

   1. 하위 작업을 별도의 스레드/맥락에서 실행한다.
   2. 에이전트의 중간 생각과 중간 출력이 메인 맥락을 오염시키지 않도록 한다.
   3. 하위 작업이 끝나면 요약(summary)만 메인 맥락에 추가한다.

2. Compaction(맥락 압축)

   1. 세션이 길어지면 토큰 수를 모니터링한다.
   2. Coyle은 150K 토큰을 기준으로 언급하며, 이를 초과하면 Anthropic의 컴팩션 알고리즘이나 커스텀 압축 기법을 사용해야 한다.
   3. Sam Bagwell의 커스텀 컴프레션: Coyle은 Sam Bagwell의 책/자료를 언급하며, 기본 압축 알고리즘을 확장하여 자신의 데이터에 맞는 컴프레션 로직을 작성할 수 있다고 소개한다.

3. 로그 분석 예시

   1. "모든 로그에서 에러를 찾아 요약하라"는 하위 작업을 context fork에서 실행한다.
   2. 요약 결과만 메인 맥락에 반영하여 후속 작업의 효율을 높인다.

---

7. 시나리오 5: Claude Code for Continuous Integration

7.1. 반패턴: CI 파이프라인에 대화형 모드 사용하기

1. 대화형 모드의 문제

   1. Claude Code가 "이 작업을 해도 될까요?" "이 권한을 주세요" 같은 질문을 하면 파이프라인이 멈춘다.
   2. CI/CD 환경에서는 사람이 없으므로 자동 실행이 불가능해진다.

2. 모범 사례: 비대화형 모드 설정

   1. Claude Code를 승인 없이 자동으로 통과할 수 있는 모드로 설정한다.
   2. CI 환경에 맞는 권한과 플래그를 미리 정의하여 자동화한다.

7.2. 비용 최적화: Batch Mode

1. Batch Mode의 특징

   1. Claude는 배치 모드로 작업을 제출할 수 있다.
   2. 비용 절감: 토큰 비용을 50% 줄일 수 있다.
   3. 시간: 결과는 최대 24시간 이내에 제공된다.

2. 활용 시점

   1. 긴급하지 않은 작업이나 대량 처리에 적합하다.
   2. "낮잠을 자거나 휴가를 갈 때" 작업을 실행해 둘 수 있다고 Coyle은 말한다.

---

8. 루프는 새로운 것이 아니다: Böhm과 Jacopini(1966)

8.1. "루프가 새로운 트렌드"라는 환상 깨기

1. 최근의 유행어: "루프가 새로운 것", "이제는 루프를 설계하는 시대" 등의 발언이 많다.

   1. Boris Cherney: "코드는 안 쓰지만 루프는 쓴다."
   2. Peter Steinberger(OpenClaw): "코딩은 안 하고 루프만 설계한다."

2. 역사적 근거

   1. Böhm과 Jacopini, 1966: 튜링 완전한 언어가 되기 위해 필요한 제어 구조는 단 세 가지뿐이라고 증명했다.
   2. 세 가지 구조: 순차 실행(sequential statements), 조건문(if-then conditionals), 반복문(loop).
   3. 의미: 루프는 1960년대부터 컴퓨터 과학의 핵심 구조였으며, agentic AI에서 부활하고 있을 뿐이다.

8.2. Agentic AI에서 루프의 부활

1. 기존 LLM 활용: 주로 순차적 프롬프트와 단순 if-then 조건에 머물렀다.
2. agentic AI의 변화: 루프를 추가함으로써 LLM이 도구와 상호작용하며 문제를 반복적으로 해결할 수 있게 되었다.
3. 핵심 통찰: 루프는 구조적 패러다임의 부활이며, 이는 엔지니어링의 기본 원칙을 다시 적용하는 것이다.

---

주요 발언 모음

"Nothing is a mistake. There's no win and no fail. There's only make." — Sister Corita Kent

"I have not failed. I've only found 10,000 ways that don't work." — Thomas Edison

"Computer science is no longer the magic pathway to a job." — Frank Coyle

"The exam is based on scenarios, timed, proctored." — Frank Coyle

"The LLM can't execute tools. It's a probabilistic next-word predictor. It can only talk back to you." — Frank Coyle

"You don't want to hire a carpenter who shows up with plumbing, carpentry, and electrical tools and says, 'I can do anything.'" — Frank Coyle

"Loops are not new. Böhm and Jacopini, 1966, proved you only need three things for Turing completeness." — Frank Coyle

"If you have more than 150,000 tokens, run a compact." — Frank Coyle

"Batch mode: 50% fewer token cost, results in at least 24 hours." — Frank Coyle

"Nothing is a mistake. There's no win, there's no fail, there's no exam, only make." — Frank Coyle(결론)

---

핵심 데이터 & 수치

• Agentic Architecture: CCA 시험의 27%를 차지한다.
• Claude Code: CCA 시험의 20%를 차지한다.
• Prompt Engineering: CCA 시험의 20%를 차지한다.
• Tool Design & MCP Integration: CCA 시험의 20%를 차지한다.
• Context Management & Reliability: CCA 시험의 13%를 차지한다.
• 개인 응시 비용: 99달러, 6개월에 한 번씩 응시 가능.
• 프로덕션 시나리오: 6개 중 4개가 무작위로 출제된다.
• 토큰 컴팩션 기준: 150,000 토큰 이상일 때 compaction을 고려해야 한다.
• Batch Mode 비용 절감: 50% 절감, 최대 24시간 이내 결과 수신.

---

결론 및 시사점

1. CCA 시험은 자격증을 넘어 실전 지침서다: 시험의 각 시나리오와 반패턴은 agentic AI 시스템을 설계하고 운영하는 데 직접 적용할 수 있다.
2. 반패턴 중심 학습: 정답을 외우는 대신, 어떤 설계가 왜 잘못되는지를 이해하는 것이 핵심이다.
3. LLM의 한계를 명확히 인식: LLM은 도구를 직접 실행하지 못하며, 루프와 stop reason을 통해 제어해야 한다.
4. 에이전트 전문화와 맥락 분리: 만능 에이전트를 피하고, 각 에이전트의 역할과 도구를 제한하며, 맥락을 최소화해야 한다.
5. 비용과 신뢰성 최적화: context fork, compaction, batch mode, 비대화형 CI 모드 등을 적극 활용해야 한다.
6. 역사적 원칙의 재발견: 루프, 조건문, 순차 실행은 1966년에 이미 증명된 튜링 완전의 기둥이며, agentic AI도 이 원칙을 따른다.
7. 실천적 자세: 읽기만 하지 말고 직접 만들고 실험하라. 실패는 방법을 찾는 과정일 뿐이다.
8. 후속 행동: Frank Coyle은 Berkeley 이메일(coil@berkeley)과 웹사이트 co-supreme.ai를 통해 연락할 수 있으며, 그는 재즈팬으로 John Coltrane의 A Love Supreme에서 사이트 이름을 따왔다고 소개한다.