본문으로 건너뛰기
learn / cert / ccar-f / scenarios
BUILD 0610LAST DEPLOY 2026.08.11 17:53 KST

CCAR-F · DESIGN SCENARIOS · 6 MODULES

결정으로 배우는 아키텍처.

아키텍트 시험은 정답 암기가 아니라 설계 판단을 묻습니다. 실제 현장에서 마주하는 난제를 한 편씩 펼쳐, 전개되는 갈림길마다 근거를 따져 고르는 연습입니다. 모듈 끝에는 그 선택에서 남는 설계 원칙을 정리했습니다.

쉽게 말해먼저 상황을 읽고, 각 결정에서 보기를 고른 뒤 해설로 근거를 확인하세요 — 챕터를 한 바퀴 돈 다음 풀면 효과가 큽니다.

SCENARIO 01 · D1 · D2 · D5

환불을 실행하는 고객지원 에이전트 — 게이트·식별·인계의 설계

국내 구독형 이커머스 기업 A사는 매일 수천 건씩 밀려드는 주문·환불 문의를 Claude 기반 고객지원 에이전트로 1차 처리하려 합니다. 이 에이전트는 주문 조회, 본인 확인, 환불 실행, 상담사 연결까지 네 가지 도구를 갖추고, 정형화된 문의는 스스로 끝내되 판단이 필요한 건은 사람에게 넘기는 구조입니다. 제약은 분명합니다 — 환불은 실제 결제 취소이므로 엉뚱한 사람에게 잘못 나가서는 안 되고, 같은 건이 두 번 처리돼서도 안 됩니다. 목표는 자동 해결률을 끌어올리면서도, 돈이 오가는 행동에서만큼은 실수를 구조적으로 막는 설계입니다. 당신은 이 에이전트의 아키텍트로서 전개되는 몇 가지 갈림길에서 결정을 내려야 합니다.

SC 01 · 01/4

환불 도구는 반드시 '본인 확인을 마친 뒤에만' 실행돼야 합니다. 한 신입 아키텍트가 '시스템 프롬프트에 「환불하기 전에 반드시 본인 확인을 먼저 하라」고 강하게 지시하면 된다'고 제안합니다. 돈이 오가는 이 행동을 안전하게 설계하는 방법으로 가장 알맞은 것은 무엇입니까?

설계 원칙 정리

  • 되돌릴 수 없는 행동의 선행조건은 프롬프트 지시가 아니라 코드의 게이트로 강제한다 — 모델의 준수에 안전을 의존하지 않는다.
  • 환불 같은 행동의 대상은 모델이 대화에서 뽑은 이름이 아니라 검증 단계가 돌려준 확정 식별자로 지목하고, 도구 스키마가 애매한 입력을 처음부터 거부하게 한다.
  • 에스컬레이션은 대화를 통째로 던지거나 끊는 것이 아니라 확정 사실·시도·사유·미해결 질문을 정형화해 넘기는 인계다 — 사람이 판단에만 집중하도록 맥락을 구조화한다.
  • 본인 확인·환불 완료 같은 권위 있는 사실은 대화의 기억이 아니라 그 밖의 상태에 두고 게이트가 매번 다시 읽으며, 되돌리기 어려운 도구는 멱등하게 설계해 이중 실행을 원천 차단한다.

SCENARIO 02 · D1 · D5

멀티에이전트 리서치 파이프라인의 설계 — 분해, 컨텍스트 전달, 출처 보존, 에러 전파

국내 이차전지 소재 기업 A사의 전략기획실은 유럽 배터리 규제와 경쟁사 동향을 주간 단위로 취합하던 리서치 업무를 멀티에이전트 리서치 파이프라인(multi-agent research pipeline, 여러 에이전트가 역할을 나눠 조사하고 종합하는 처리 흐름)으로 자동화하려 합니다. 코디네이터 에이전트(coordinator, 과제를 분해·배분하고 결과를 종합하는 상위 에이전트)가 '유럽 규제 변화가 우리 공급망에 미치는 영향' 같은 광범위한 질의를 받아 세부 조사 과제로 나누고, 각 서브에이전트(subagent, 배분받은 세부 조사를 독립 수행하는 하위 에이전트)가 조사한 결과를 코디네이터가 하나의 보고서로 합성하는 구조입니다. 전략기획실은 두 가지 제약을 걸었습니다 — 보고서의 모든 주장은 원출처로 역추적할 수 있어야 하고(경영진 의사결정의 근거가 되기 때문입니다), 서브에이전트 일부가 실패해도 전체 파이프라인이 무너지지 않아야 합니다. 아키텍트인 당신은 과제 분해 범위, 서브에이전트로의 컨텍스트 전달, 출처 보존 합성, 에러 전파를 차례로 설계해야 합니다.

SC 02 · 01/4

첫 번째 결정입니다. 코디네이터가 '유럽 규제 변화가 공급망에 미치는 영향'이라는 광범위한 질의를 서브에이전트에게 어떻게 분해해 배분해야 할까요?

설계 원칙 정리

  • 분해는 병렬 이득과 조율 비용의 균형입니다 — 서로 겹치지 않는 자기완결 단위로, 범위와 산출 형식을 명시해 나눕니다.
  • 서브에이전트는 코디네이터의 기억을 공유하지 않습니다 — 필요한 컨텍스트는 과제에 맞게 추려 명시적으로 전달해야 합니다.
  • 합성은 출처가 사라지기 쉬운 지점입니다 — 주장과 근거의 연결을 반환 구조에서부터 유지해야 역추적이 살아 있습니다.
  • 에러는 구조로 전파돼야 합니다 — 실패를 삼키지도 지어내지도 않고, 확보분은 살리고 공백은 정직하게 드러냅니다.

SCENARIO 03 · D3 · D4

대규모 코드베이스 리뷰 자동화 — 다중패스 리뷰 파이프라인 설계

한국의 중견 이커머스 플랫폼 '마루커머스'는 주문·결제·정산 도메인을 하나의 대형 모노레포(monorepo, 여러 서비스를 한 저장소에 두는 구조)에서 관리합니다. 하루에 올라오는 풀 리퀘스트(PR)가 수십 건인데, PR 하나에 바뀌는 파일이 많게는 수백 개에 이르러 사람 리뷰어가 병목이 되었고, 정산 로직의 경계조건 실수가 프로덕션까지 새어 나간 적도 있습니다. 테크리드인 당신은 Claude Code를 CI/CD 파이프라인에 넣어 코드 리뷰를 자동화하고, 그 결과를 머지 게이트(merge gate, 통과해야 병합되는 관문)에 연결하는 설계를 맡았습니다. 제약은 분명합니다 — CI는 사람이 개입하지 않는 비대화형 환경이고, 리뷰 품질은 인스턴스마다 일관돼야 하며, 결과는 자동으로 파싱해 머지 여부를 판정할 수 있어야 합니다. 목표는 화려한 자동화가 아니라, 대규모에서도 무너지지 않고 재현 가능한 리뷰 구조를 세우는 것입니다.

SC 03 · 01/4

첫 설계 결정은 리뷰 패스 구조입니다. PR 하나에 수백 개 파일이 바뀌는 상황에서, 리뷰를 어떻게 나눠 실행하도록 설계하겠습니까?

설계 원칙 정리

  • 대규모 코드베이스는 단일 프롬프트로 삼키지 말고, 파일별 1차 리뷰와 파일 간 상호작용을 보는 통합 패스로 책임을 나눈 다중패스로 설계한다.
  • 리뷰 인스턴스는 서로 독립시켜 문맥 오염과 편향을 차단하고, 통합 패스에는 원문 누적이 아니라 필요한 요약만 전달한다.
  • CI 자동화의 핵심은 비대화형 실행과 사전 정의 스키마의 구조화 출력 — 게이트가 파싱할 수 있어야 리뷰가 판정으로 이어진다.
  • 일관성은 모델의 성실함이 아니라 명시적 리뷰 기준에서 나온다 — 검사 항목·심각도 정의·무시 대상을 고정해 모든 인스턴스에 동일 적용한다.

SCENARIO 04 · D4 · D5

스캔 서류 4만 건을 심사 데이터로: 보험금 청구 추출 파이프라인 설계

국내 대형 손해보험사 A사의 보상 플랫폼팀은 매달 4만여 건의 자동차 보험금 청구 서류를 처리합니다. 진단서·치료비 영수증·사고 경위서가 스캔 PDF로 들어오면 담당자가 손으로 핵심 항목(청구인·진단명·청구액·치료 기간)을 입력하는데, 성수기에는 처리 지연이 일주일을 넘기고 오타에 따른 재작업도 잦습니다. 당신은 이 팀에 합류한 아키텍트로서 Claude 기반 문서 추출 파이프라인을 설계해, 서류에서 구조화된 항목을 뽑아 심사 시스템에 넘기는 흐름을 만들어야 합니다. 제약은 분명합니다 — 항목이 실제로 서류에 없을 때 값을 지어내면 안 되고, 잘못된 추출이 그대로 지급으로 이어져서는 안 되며, 야간에 대량을 감당하되 비용은 통제돼야 합니다. 목표는 사람의 입력을 대체하는 것이 아니라, 확실한 건은 자동으로 통과시키고 애매한 건만 사람에게 모으는 구조입니다.

SC 04 · 01/4

추출 결과를 안정적으로 구조화하려고 tool_use(도구 정의로 모델이 정해진 JSON을 채우게 하는 방식)를 쓰기로 했습니다. 그런데 진단서에는 '치료 종료일'이 아직 기재되지 않은 경우가 흔합니다. 없는 값을 지어내지 않으면서도 출력 구조가 깨지지 않으려면 스키마를 어떻게 설계해야 할까요?

설계 원칙 정리

  • 구조화 출력에서 '값 없음'은 항목 생략이 아니라 nullable로 명시한다 — 모든 항목을 required로 두고 null을 허용해야 부재와 미발견을 지어냄 없이 구분할 수 있다.
  • tool_use는 타입 준수는 보장하지만 값의 정합성은 보장하지 않는다 — 결정적 검증과, 실패 사유를 되돌려 재요청하는 상한 있는 재시도 루프를 애플리케이션 층에서 설계한다.
  • 즉시 응답이 필요 없고 대량이 한꺼번에 몰리는 작업은 배치 API가 정답이다 — 비용·처리량 이점을 얻되, 결과 순서 미보장은 custom_id 매칭으로 설계상 해결한다.
  • 사람 검토는 위험 신호에 정렬한다 — 모델 신뢰도·검증 실패·핵심 값 부재를 기준으로 애매한 건만 라우팅해, 자동화의 처리량과 사람 판단의 안전을 함께 얻는다.

SCENARIO 05 · D2 · D1

41개로 불어난 MCP 도구 세트 — 선택 신뢰성을 다시 설계하다

국내 한 중견 풀필먼트(주문 이후 보관·포장·배송을 대행하는 물류 서비스) 기업이 사내 운영 담당자를 돕는 Claude 기반 에이전트를 1년째 확장해 왔습니다. 사내 시스템을 MCP(Model Context Protocol, 모델과 외부 도구·데이터를 잇는 표준 연결 규격)로 붙이며 처음 6개였던 도구가 주문 조회·재고 이동·배송 예약·정산·반품 처리로 늘어 지금은 41개에 이르렀고, 최근 들어 에이전트가 엉뚱한 도구를 부르거나 이름이 비슷한 도구를 혼동하는 오작동이 눈에 띄게 잦아졌습니다. 특히 get_order·lookup_order·search_orders처럼 기능이 겹쳐 보이는 도구 앞에서 선택이 흔들리고, 자주 바뀌지 않는 참조 데이터(배송 권역표)를 매 턴 도구 호출로 다시 읽느라 응답이 느려집니다. 당신은 이 회사의 에이전트 플랫폼 아키텍트로서 도구 세트를 다시 설계해 선택 신뢰성을 회복하고 지연을 예산 안으로 되돌려야 합니다. 다만 운영 도구 일부는 재고를 실제로 옮기는 되돌릴 수 없는 작업이라, 잘못된 맥락에서 호출되면 곧바로 실손해로 이어진다는 제약이 있습니다.

SC 05 · 01/4

세 도구의 설명(description)을 확인하니 각각 "주문을 조회합니다", "주문을 찾습니다", "주문들을 검색합니다"로 거의 같은 문장이었습니다. 에이전트의 도구 혼동을 줄이기 위해 가장 먼저, 그리고 가장 원칙적으로 손대야 할 곳은?

설계 원칙 정리

  • 도구 선택 신뢰성의 첫 지렛대는 설명 문구다 — 설명은 '무엇을 하는가'가 아니라 '언제·어떤 입력·어떤 출력으로 다른가'로 도구들을 구별해야 한다.
  • 도구 과잉은 국면·역할별 분할 노출로, 위험한 실행은 범위 격리와 tool_choice 게이트로 다룬다 — 노출 목록과 tool_choice가 신뢰성·안전의 두 손잡이다.
  • 도구는 '행동', 리소스는 '읽기 전용 맥락'이다 — 자주 바뀌지 않는 참조 데이터는 도구 호출이 아니라 MCP 리소스로 모델에 붙인다.
  • 실패 응답은 모델을 위한 인터페이스다 — 오류 코드·원인·다음 행동을 담아 실패를 명시해야 모델이 반복이나 환각 없이 복구한다.

SCENARIO 06 · D3 · D2

팀 Claude Code 표준화 — 설정 계층과 안전 경계 설계

국내 핀테크 스타트업 '페이로'의 플랫폼 아키텍트인 당신은 엔지니어 12명이 하나의 모노레포(monorepo, 여러 앱과 패키지를 한 저장소에 모아 두는 구조)에서 Claude Code로 일하도록 표준을 세우는 임무를 맡았습니다. 도입 두 달 만에 문제가 드러났습니다 — 팀원마다 개인 설정과 CLAUDE.md가 제각각이라 같은 코드베이스에서도 Claude의 행동이 엇갈렸고, 일부는 개인 설정에 넓은 실행 권한을 열어 두어 결제 모듈의 키 파일까지 편집 범위에 들어왔습니다. 경영진은 PCI 범위(PCI scope, 카드 결제 정보를 다루어 규제가 적용되는 코드 영역)의 안전과 팀 전체의 일관성을 동시에 요구합니다. 당신은 어떤 규칙을 어느 설정 계층이 소유해야 하는지 진단하고, 결제 하위 트리에는 더 엄격한 경로 규칙을 걸며, 저장소 전반에 파급되는 리팩터는 검토를 거친 뒤 실행되도록 표준을 설계해야 합니다.

SC 06 · 01/4

먼저 표준의 뼈대를 세워야 합니다. 팀 전체가 반드시 지켜야 할 안전 규칙(예: 넓은 셸 실행 차단, 비밀 파일 읽기 금지)이 어느 개인의 설정으로도 덮어써지지 않게 하려면, 각 규칙을 어느 설정 계층에 두어야 합니까?

설계 원칙 정리

  • 강제가 필요한 규칙은 하위 계층이 덮어쓸 수 없는 관리형 정책 계층에, 공유가 필요한 관례는 저장소에 커밋되는 프로젝트 계층에 — 규칙의 성격에 맞는 계층이 소유한다.
  • 경로 규칙에서 별표 하나는 한 단계를, 별표 둘은 중첩 전체를 잡으며 deny는 언제나 allow를 이긴다 — 비밀 보호는 안내가 아니라 권한 계층에서 강제한다.
  • 읽기 위주의 대규모 탐색은 격리된 포크(서브에이전트) 컨텍스트로 분리하고 정제된 결과만 되돌려받아, 본 작업 컨텍스트를 가볍게 유지한다.
  • 플랜 모드는 파급이 큰 구조 변경을 위한 실행 전 검토 관문이고 직접 실행은 위험이 낮은 기계적 편집의 몫이다 — 실행 방식은 속도 취향이 아니라 파급 범위에 맞춘다.

본 콘텐츠는 byteforce가 자체 제작한 학습 자료입니다. Anthropic 공식 Exam Guide v1.0 (2026-07)을 기준으로 작성되었으며, 시험의 공식 정보는 Anthropic 원문 가이드가 우선합니다.