CCAAK · 개요

CCAAK 개요와 운영자 학습 플랜

CCAAK(Confluent Certified Administrator for Apache Kafka)는 Kafka 클러스터를 세우고, 지키고, 되살리는 능력을 검증하는 시험입니다. 코드를 쓰는 시험이 아니라 증상을 보고 무엇을 먼저 확인할지 판단하는 시험이므로, 문서를 읽는 것만으로는 부족하고 클러스터를 직접 부수고 복구해 본 경험이 점수로 이어집니다. 이 페이지는 시험 개요, CCDAK와의 차이, 7개 섹션과 이 사이트의 매핑, 4주 플랜을 정리합니다.

이 페이지에서 얻어 갈 것

시험 개요 — 확인된 것과 확인되지 않은 것

아래 표에서 미공개로 적힌 항목은 이 가이드가 확인하지 못한 것이 아니라, Confluent가 공개하지 않는 항목입니다. 시중 자료에 문항 수와 합격 점수가 서로 다르게 적혀 있는 이유가 여기 있습니다. 확인되지 않은 숫자를 외우면 시험장에서 페이스 계산이 틀어지므로, 처음부터 모른다고 알고 있는 편이 낫습니다.

CCAAK 시험 조건. 값이 확인된 항목과 미공개 항목을 구분했습니다.
항목 값 비고
시험 시간 90분 원격 프록터링(proctored). 응시 환경의 네트워크·보안 요건을 사전에 점검해야 합니다.
응시료 USD 150 시도(attempt)당 부과됩니다.
문항 유형 multiple-choice · matching · list order 3종 선택형만 나오지 않습니다. 아래에서 자세히 다룹니다.
문항 수 미공개 공개 자료마다 값이 다릅니다. 이 가이드는 단정하지 않습니다.
합격 점수 미공개 동일. "몇 점이면 붙는다"는 계산 대신 전 섹션을 고르게 채우는 전략을 씁니다.
유효 기간 2년 2년마다 재인증(recertification)이 필요합니다.
재응시 불합격 후 7일 대기 7일이 지나면 재구매·재등록이 가능합니다.
기준 Kafka 버전 이 가이드는 Apache Kafka 4.3.x 시험이 어느 버전을 기준으로 출제되는지는 공표되지 않습니다. 버전 리스크를 참고하세요.

문항 유형 3종 — 선택형만 준비하면 손해입니다

CCAAK는 multiple-choice 외에 matching(연결형)과 list order(순서 배열)를 함께 출제합니다. 운영 시험에서 이 두 유형은 "절차를 아는가"를 묻는 데 쓰이므로, 개념을 알아도 순서를 못 외우면 통째로 실점합니다.

문항 유형별 대비 포인트
유형 전형적인 출제 방식 대비법
multiple-choice 증상을 주고 "가장 먼저 확인할 것" 또는 "원인"을 고르게 합니다. 메트릭 이름과 설정 기본값을 정확히. 근사값으로 외우면 경계값 문항에서 틀립니다.
matching 메트릭 ↔ 의미, 설정 ↔ 소속(브로커/토픽/클라이언트), CLI ↔ 목적을 연결하게 합니다. 메트릭·설정을 이름 단위로 외우세요. 뭉뚱그려 이해하면 연결이 안 됩니다.
list order 파티션 재할당 3단계, 롤링 업그레이드 절차, 장애 대응 순서를 배열하게 합니다. 이 가이드의 각 도메인 페이지에 있는 번호가 붙은 절차를 그대로 외우세요.

CCDAK와 CCAAK의 차이 — 누가 어느 것을 봐야 하는가

두 시험은 같은 Kafka를 다루지만 보는 방향이 반대입니다. CCDAK는 클라이언트에서 클러스터를 바라보고, CCAAK는 클러스터에서 클라이언트를 바라봅니다. 같은 min.insync.replicas를 두고 CCDAK는 "프로듀서가 무슨 예외를 받는가"를 묻고, CCAAK는 "이 값 때문에 파티션이 쓰기 불가가 되었을 때 무엇을 확인하는가"를 묻습니다.

CCDAK와 CCAAK 비교
관점 CCDAK CCAAK
정식 명칭 Confluent Certified Developer for Apache Kafka Confluent Certified Administrator for Apache Kafka
주 대상 애플리케이션 개발자, 솔루션 아키텍트 클러스터 운영자, SRE, 플랫폼 엔지니어
검증하는 능력 클라이언트 코드와 설정으로 원하는 보장(순서·중복·유실)을 만들어 내는 능력 클러스터를 구축·보안·모니터링하고 장애에서 복구하는 능력
시험 섹션 수 6개 7개
주요 소재 Producer/Consumer API, 트랜잭션, Streams DSL, Schema Registry, 테스트 리스너·SASL·ACL, 컨트롤러 쿼럼, 파티션 재할당, 쿼터, JMX 메트릭, 장애 대응
CLI 비중 낮음 — 설정과 코드 판독이 중심 높음 — kafka-*.sh 옵션이 손에 익어야 합니다
문항 성격 코드·설정 조각을 주고 결과를 묻는 형태가 많습니다 증상 → 원인 → 조치 시나리오 판단이 많습니다
가중치 공개 여부 공개 자료에서 복수 출처가 일치합니다 (이 가이드는 CCDAK 개요에 표기) 출처별 불일치 — 이 가이드는 퍼센트를 표기하지 않습니다
이 가이드의 밀도 1순위. 문항·다이어그램·전용 학습 도구가 집중되어 있습니다 정확성은 동일 기준, 분량은 CCDAK보다 작습니다

선택 기준

역할별 권장 시험
지금 하는 일 권장 이유
Kafka를 쓰는 서비스를 개발한다 CCDAK 실점이 곧 장애가 되는 지점(acks, 커밋 시점, 리밸런스)이 그대로 출제 범위입니다.
클러스터를 직접 운영한다 (또는 곧 맡는다) CCAAK 보안 리스너 조합, 재할당, 메트릭 해석은 CCDAK에 거의 나오지 않습니다.
플랫폼 팀에서 둘 다 한다 CCDAK → CCAAK 공통 기반(복제·ISR·오프셋)을 CCDAK 준비로 쌓아 두면 CCAAK 학습량이 크게 줄어듭니다.
Kafka 경험이 6개월 미만이다 기본개념 먼저 1장부터 7장까지 훑은 뒤 시험을 고르세요.

겹치는 영역 — 한 번 공부해 두 시험에 쓰는 부분

두 시험의 교집합은 생각보다 큽니다. 아래 영역은 어느 쪽을 준비해도 그대로 쓰이므로 먼저 확실히 끝내는 것이 효율적입니다.

CCDAK · CCAAK 공통 영역과 관점 차이
공통 주제 CCDAK가 묻는 각도 CCAAK가 묻는 각도 학습 위치
복제 · ISR · min.insync.replicas acks=all과 결합했을 때 프로듀서가 받는 예외 ISR 축소 원인 진단과 복구 순서 2장 · Kafka Fundamentals
오프셋 4종 (LSO · committed · HW · LEO) 커밋 시점에 따른 유실/중복 lag 측정값이 무엇을 뜻하는지, 왜 음수처럼 보이는지 1장 · Observability
Kafka Connect 커넥터 설정, SMT, DLQ, source/sink 오프셋 저장 위치 워커 스케일링, 내부 토픽 관리, 워커 장애 로그 추적 9장 · Kafka Connect
리밸런스 할당 전략과 max.poll.interval.ms 튜닝 리밸런스 스톰이 클러스터에 주는 부하와 억제 방법 5장 · Troubleshooting
메트릭 클라이언트 메트릭 (records-lag-max 등) 브로커·컨트롤러 JMX 메트릭 전반 JMX 치트시트 · Observability
리텐션 · 컴팩션 어떤 정책이 어떤 데이터 모델에 맞는가 디스크 용량 산정과 세그먼트 단위 삭제의 실제 효과 7장 · Cluster Configuration

7개 섹션과 이 사이트의 매핑

섹션 이름은 아래 7개입니다. 앞서 설명한 이유로 퍼센트는 붙이지 않았습니다. 각 섹션 페이지는 운영자 관점으로 구성되어 있습니다 — 개념 요약, 필수 CLI, 외울 설정값, 장애 시나리오와 대응, 자주 나오는 함정, 미니 퀴즈 순서입니다.

CCAAK 7개 섹션 ↔ 이 사이트 페이지 ↔ 기본개념 장
섹션 이 사이트의 섹션 페이지 배경이 되는 기본개념 장 관련 빠른참조
Kafka Fundamentals Kafka Fundamentals 2장 아키텍처, 3장 KRaft, 7장 스토리지 CLI
Kafka Security Kafka Security 11장 운영 기초 보안 설정
Kafka Connect Kafka Connect 9장 Connect Connect REST · SMT
Deployment Architecture Deployment Architecture 3장 KRaft, 부록 레거시 CLI
Cluster Configuration Cluster Configuration 2장, 7장, 11장 설정값
Observability Observability 11장 운영 기초 JMX 메트릭
Troubleshooting Troubleshooting 5장, 7장, 11장 결정 트리

학습 배분 — 실습 난이도와 장애 빈도 기준

가중치를 쓸 수 없으므로, 대신 두 축으로 배분합니다. 실습 난이도는 그 영역을 손으로 익히는 데 드는 비용(노드 수, 인증서, 부하 생성)이고, 장애 빈도는 실제 운영에서 그 영역이 사고를 일으키는 빈도입니다. 시나리오 문항은 장애 빈도가 높은 영역에서 나오고, 오답은 실습 난이도가 높은 영역에서 나옵니다.

섹션별 실습 난이도 · 장애 빈도와 그에 따른 학습 순서
섹션 실습 난이도 장애 빈도 학습 순서 배분 근거
Kafka Fundamentals 낮음 — 선행 나머지 6개 섹션의 전제입니다. 여기서 흔들리면 시나리오 문항을 읽을 수 없습니다.
Cluster Configuration 중 높음 1 재할당·동적 설정·쿼터는 운영 중 가장 자주 손대는 영역이고, 손대다 사고가 납니다.
Troubleshooting 높음 높음 1 시나리오 문항의 본진입니다. 장애를 직접 주입해 보지 않으면 순서 문항에서 무너집니다.
Kafka Security 매우 높음 중 2 리스너 3종 조합은 운영자 최다 실수 지점입니다. 실습 비용이 커서 미루면 끝까지 약점으로 남습니다.
Observability 중 중 2 Troubleshooting의 입력값입니다. 메트릭 이름을 모르면 장애 문항의 지문을 해석할 수 없습니다.
Kafka Connect 중 중 3 CCDAK와 겹치는 부분이 많아 이미 공부했다면 운영 관점(워커·내부 토픽)만 보강하면 됩니다.
Deployment Architecture 높음 낮음 3 한 번 정하면 오래 유지되므로 빈도는 낮지만, 사이징 문항은 암기로 확실히 맞힐 수 있습니다.

4주 학습 플랜 — 구축 · 장애 주입 · 복구 훈련

운영자 시험이므로 플랜의 축은 읽기가 아니라 클러스터 한 대를 세워 부수고 되살리는 사이클입니다. 3노드 KRaft 클러스터를 로컬에 띄우는 방법은 예제 1에 있습니다. 매주 마지막 날에는 그 주의 미니 퀴즈를 다시 풀어 80% 이상을 확인하고 넘어가세요.

1주차 — 클러스터를 내 손으로 세운다

  1. 2장·3장을 읽고 Kafka Fundamentals를 끝냅니다.
  2. kafka-storage.sh random-uuid → format → 기동 순서로 컨트롤러 3대 + 브로커 3대를 직접 띄웁니다.
  3. kafka-metadata-quorum.sh describe --status와 --replication 출력을 읽을 수 있게 됩니다.
  4. 토픽을 만들고 kafka-topics.sh --describe로 리더·ISR·복제 배치를 확인합니다.
  5. 브로커 1대를 정상 종료하고, ISR과 리더가 어떻게 움직이는지 관찰합니다.

2주차 — 구성을 바꾸고 되돌린다

  1. Cluster Configuration을 끝냅니다.
  2. 브로커를 1대 추가하고 kafka-reassign-partitions.sh 3단계로 파티션을 옮깁니다. --throttle을 걸고, --verify로 해제까지 반드시 해 봅니다.
  3. kafka-configs.sh로 토픽·브로커 설정을 동적으로 바꾸고 --delete-config로 되돌립니다.
  4. 사용자·클라이언트 쿼터를 걸고, 부하를 주어 스로틀이 실제로 걸리는지 확인합니다.
  5. Deployment Architecture를 읽고 broker.rack을 붙여 재배치 결과를 비교합니다.

3주차 — 잠그고 들여다본다

  1. Kafka Security를 끝냅니다. 이 주가 가장 힘듭니다.
  2. SASL/SCRAM 자격증명을 kafka-storage.sh --add-scram과 kafka-configs.sh로 각각 만들어 봅니다.
  3. listeners / advertised.listeners / listener.security.protocol.map을 내부·외부 2개 리스너로 구성하고, 일부러 틀리게 해서 나오는 에러 메시지를 수집합니다.
  4. kafka-acls.sh로 producer/consumer ACL을 부여하고, 빼앗아 실패 메시지를 확인합니다.
  5. Observability를 읽고 JMX를 열어 4대 지표를 실제로 조회합니다.

4주차 — 부수고 되살린다

  1. Troubleshooting과 Kafka Connect를 끝냅니다.
  2. 장애 주입: 브로커 강제 종료, 디스크 채우기, 컨슈머 처리 지연으로 리밸런스 유발, 컨트롤러 노드 정지.
  3. 각 장애에서 어느 메트릭이 먼저 움직였는지 기록합니다. 이것이 시나리오 문항의 정답 근거입니다.
  4. 케이스 2·케이스 6·케이스 10을 읽고 자기 실습과 대조합니다.
  5. 시험 당일 전략을 읽고, 7개 섹션 미니 퀴즈를 순서대로 한 번씩 더 풉니다.

실습 필수 항목 — 이건 반드시 손으로 해 보세요

아래 다섯 가지는 읽어서 대체되지 않습니다. 시험 문항이 "무엇을 먼저 확인하는가"를 묻기 때문에, 한 번이라도 직접 해 본 사람과 안 해 본 사람의 답이 갈립니다.

필수 실습 5종과 확인 지점
실습 최소 구성 끝났다고 판단하는 기준
KRaft 클러스터 직접 구축 컨트롤러 3 + 브로커 3 (또는 combined 3노드) kafka-metadata-quorum.sh describe --status에서 리더와 voter 목록을 설명할 수 있음
브로커 장애 시뮬레이션 RF=3, min.insync.replicas=2 토픽 1대 정지 시 URP 값 변화와 쓰기 가능 여부, 2대 정지 시 결과를 예측할 수 있음
파티션 재할당 브로커 4대 이상 --generate/--execute/--verify를 순서대로 쓰고 스로틀을 해제까지 함
ACL 설정 SASL 리스너 1개 + StandardAuthorizer 권한 부족 시 나오는 오류 이름(TOPIC_AUTHORIZATION_FAILED 등)을 보고 원인을 짚음
lag 모니터링 느린 컨슈머 1개 CLI·클라이언트 메트릭·브로커 메트릭 세 경로로 lag을 확인할 수 있음

버전 리스크 — 4.x와 3.x가 갈리는 지점

공식 문서 출처

시험 조건은 Confluent 공식 인증 페이지, 기술 사실은 Apache Kafka 4.3.1 문서에서 확인했습니다. 섹션별 가중치는 공식 Exam Guide로 확정하지 못했으므로 표기하지 않았습니다.