01. 문제 60문항 — 합격하는 Claude Certified Architect 자격증

문제 60문항

아래 60문항을 실제 시험과 동일한 조건에서 푸세요. 각 문항은 4지선다이며 정답은 하나입니다. 보기 번호는 ①②③④로 표기합니다. 정답은 이 절에 표시하지 않으며, 60문항을 모두 푼 뒤 다음 절에서 채점하세요. 문항 번호 1부터 16까지는 에이전트 아키텍처와 오케스트레이션, 17부터 28까지는 Claude Code, 29부터 40까지는 프롬프트와 구조화 출력, 41부터 51까지는 도구와 MCP, 52부터 60까지는 컨텍스트 관리와 신뢰성 도메인입니다.

에이전트 루프에서 모델이 클라이언트 도구를 호출하기로 결정했을 때, 그 도구를 실제로 실행하고 결과를 다시 모델에 전달하는 주체는 누구인가? ① 모델 자신이 내부에서 실행한다 ② MCP 서버가 항상 실행한다 ③ Anthropic 서버가 자동으로 실행한다 ④ 애플리케이션(하니스)이 실행한다
한 번의 에이전트 루프 사이클에서 모델이 도구를 더 호출하지 않고 작업을 끝냈을 때, 응답의 stop_reason 값으로 가장 적절한 것은? ① tool_use ② max_tokens ③ end_turn ④ pause_turn
다음 중 에이전트 루프에 반복 한계(max_iterations)를 두는 가장 중요한 이유는? ① 토큰 비용을 정확히 계산하기 위해 ② 모델이 도구를 호출하지 못하게 막기 위해 ③ 종료 조건에 도달하지 못할 때 무한 반복을 방지하기 위해 ④ 프롬프트 캐시 적중률을 높이기 위해
상황. 고객 지원 봇이 사용자 질문에 답하기 위해 주문 조회 도구를 호출했고, 도구 결과를 받은 뒤 추가 도구 호출 없이 답변을 생성하려 한다. 애플리케이션이 이 결과를 모델에 전달할 때 사용해야 하는 블록 유형은? ① tool_use 블록 ② tool_result 블록 ③ thinking 블록 ④ system 블록
서버 측 도구(예: 코드 실행)를 사용할 때 서버 내부 샘플링 루프가 기본 반복 한계에 도달하면 반환되는 stop_reason은? ① end_turn ② refusal ③ pause_turn ④ stop_sequence
상황. 100건의 독립적인 계약서를 가능한 한 빨리 검토하되, 한 계약서의 검토 내용이 다른 검토에 끼어들면 안 된다. 가장 적합한 구조는? ① 단일 에이전트가 한 대화에서 100건을 순차 처리 ② 오케스트레이터가 계약서마다 서브에이전트를 병렬로 위임하고 결과 취합 ③ 100건을 한 프롬프트에 모두 넣어 단일 호출로 처리 ④ 100건을 하나의 긴 의존 체인으로 묶어 처리
멀티 에이전트에서 서브에이전트의 핵심 이점 중, "병렬 속도" 외에 시험이 자주 강조하는 가치는? ① 모델 호출 단가를 낮추는 것 ② 도구 정의 수를 줄이는 것 ③ 격리된 컨텍스트로 메인 대화를 깨끗하게 유지하는 것 ④ 프롬프트 캐시를 비활성화하는 것
상황. 데이터 파이프라인이 추출, 변환, 적재 세 단계로 이뤄지고 각 단계는 앞 단계의 출력에 의존한다. 옳은 구조는? ① 세 단계를 병렬 서브에이전트로 동시에 실행 ② 세 단계를 각각 다른 모델로 나눠 비용 최적화 ③ 한 에이전트가 순서를 자유롭게 정하도록 위임 ④ 단계 사이 의존을 지키는 순차 워크플로우
"에이전트를 만들어야 하는가"를 판단하는 네 기준(복잡성, 가치, 실현 가능성, 오류 비용) 중, "PDF에서 제목 한 줄을 추출"하는 작업이 에이전트가 아니라 단일 호출로 충분하다고 판단되는 가장 직접적 근거는? ① 가치가 너무 높기 때문 ② 모델이 이 작업을 수행할 능력이 없기 때문 ③ 오류를 복구할 수 없기 때문 ④ 작업이 단순하고 사전에 완전히 명세할 수 있기 때문
워크플로우(코드로 루프를 제어하는 다단계)와 에이전트(모델이 스스로 경로를 결정)를 구분하는 가장 본질적인 차이는? ① 사용하는 모델의 크기 ② 루프 제어 권한이 코드에 있는가, 모델에 있는가 ③ 도구를 서버에서 실행하는가 클라이언트에서 실행하는가 ④ 응답을 스트리밍하는가 여부
상황. 한 작업이 다단계이고 사전에 모든 단계를 완전히 명세하기 어렵지만, 결과를 테스트와 리뷰로 검증하고 롤백할 수 있다. 이때 가장 적절한 티어 선택은? ① 단일 LLM 호출 ② 배치 처리 ③ 에이전트(모델이 경로를 결정) ④ 임베딩 생성
오케스트레이터-워커 패턴에서 워커(서브에이전트)에 더 단순하거나 저렴한 모델을 쓰고 메인 루프는 한 모델로 유지하는 전략이 권장되는 이유로 가장 적절한 것은? ① 세션 중간에 메인 루프의 모델을 바꾸면 프롬프트 캐시가 무효화되기 때문 ② 서브에이전트는 도구를 쓸 수 없기 때문 ③ 워커는 항상 서버 측에서 실행되기 때문 ④ 저렴한 모델이 격리를 더 잘 보장하기 때문
상황. 자율 코딩 에이전트가 장시간 단일 작업을 수행한다. 작업을 가장 잘 수행하게 하려면 어떤 접근이 권장되는가? ① 모호한 지시를 여러 턴에 걸쳐 점진적으로 전달 ② 첫 턴에 전체 작업 명세를 충분히 제시하고 높은 effort로 실행 ③ effort를 최저로 두어 비용을 줄임 ④ 도구를 모두 비활성화하고 텍스트로만 답하게 함
멀티 에이전트 오케스트레이션에서 "한 작업이 독립적이고 병렬화 가능한가, 아니면 출력 의존이 있는가"를 먼저 판별해야 하는 이유로 가장 적절한 것은? ① 모델 버전을 결정하기 위해 ② 도구 정의 개수를 줄이기 위해 ③ 프롬프트 캐시 TTL을 정하기 위해 ④ 병렬 위임과 순차 워크플로우 중 어느 구조가 정답인지가 이 판별로 갈리기 때문
상황. 리서치 에이전트가 큰 코드베이스를 분석하며 수십 개 파일을 읽어 메인 컨텍스트가 빠르게 차오른다. 보고서 품질을 유지하면서 메인 대화의 토큰 부담을 줄이는 가장 좋은 방법은? ① 파일 탐색과 요약을 서브에이전트에 위임하고 메인은 최종 요약만 받음 ② 메인 대화에서 계속 읽되 오래된 메시지를 사람이 수동으로 삭제 ③ 모델을 더 큰 컨텍스트 창 버전으로 교체 ④ 파일을 다 읽은 뒤 한 번에 보고서를 작성
에이전트 설계에서 어떤 동작을 범용 bash 도구 대신 전용 도구로 승격해야 하는 대표적 판단 기준이 아닌 것은? ① 되돌리기 어려운 동작이라 사용자 확인으로 게이팅이 필요할 때 ② 파일이 변경되었는지 확인하는 staleness 검사가 필요할 때 ③ 결과를 커스텀 UI로 렌더링해야 할 때 ④ 단지 코드가 더 짧아 보이게 하기 위해
CLAUDE.md 파일의 주된 목적으로 가장 적절한 것은? ① 프로젝트의 코드베이스 규칙과 작업 지침을 Claude에 전달 ② 모델 가중치를 저장 ③ API 키를 보관 ④ 빌드 산출물을 캐시
상황. 한 팀이 모든 하위 프로젝트에 공통으로 적용되는 규칙과, 특정 프로젝트에만 적용되는 세부 규칙을 함께 관리하려 한다. Progressive Disclosure 원칙에 부합하는 구조는? ① 모든 규칙을 하나의 거대한 CLAUDE.md에 몰아넣음 ② 상위에는 공통 규칙만 두고 세부 규칙은 별도 파일에 두어 경로로 참조 ③ 규칙을 코드 주석에만 기록 ④ 규칙을 슬래시 커맨드에만 기록
슬래시 커맨드를 도입하는 가장 큰 이점으로 적절한 것은? ① 모델의 컨텍스트 창을 늘려줌 ② 도구 정의를 자동 생성 ③ API 호출 비용을 자동으로 절반으로 줄임 ④ 반복되는 프롬프트·작업 흐름을 재사용 가능한 명령으로 캡슐화
상황. 어떤 동작을 "사용자가 매번 요청할 때마다" 자동으로 수행해야 한다(예: 작업 종료 시 항상 린트 실행). 이 자동화를 구현하는 올바른 메커니즘은? ① 메모리에 선호를 저장 ② Hooks(훅)로 이벤트에 동작을 바인딩 ③ 시스템 프롬프트에 한 줄 적기 ④ 슬래시 커맨드를 한 번 실행
CI/CD 파이프라인에서 Claude Code를 비대화식으로 실행할 때 인증 방식으로 가장 적절한 것은? ① 대화식 OAuth 로그인을 매 빌드마다 수행 ② Workload Identity Federation 같은 비대화식 자격 증명 사용 ③ API 키를 소스 코드에 하드코딩 ④ 인증 없이 익명으로 호출
상황. 팀원들이 같은 저장소에서 Claude Code를 사용하는데, 일부 권한은 모두에게 공통이고 일부는 개인별로 다르다. 권한 설정을 관리하는 올바른 접근은? ① 모든 권한을 개인 글로벌 설정에만 둠 ② 권한을 매 세션 수동으로 다시 허용 ③ 권한을 CLAUDE.md 본문에 문장으로 적음 ④ 공통 권한은 프로젝트 설정에, 개인 권한은 로컬 설정에 분리
슬래시 커맨드와 CLAUDE.md의 역할 차이로 가장 정확한 것은? ① 둘은 동일하며 아무거나 써도 된다 ② CLAUDE.md는 항상 적용되는 상시 지침, 슬래시 커맨드는 사용자가 의도적으로 호출하는 작업 흐름 ③ 슬래시 커맨드는 모델 가중치를 바꾼다 ④ CLAUDE.md는 한 번만 읽히고 다시는 참조되지 않는다
상황. CLAUDE.md가 점점 비대해져 토큰 부담과 가독성 문제가 생겼다. 가장 권장되는 정리 방향은? ① 모든 내용을 그대로 두고 모델 컨텍스트 창만 키움 ② 공통 핵심만 남기고 세부 규칙은 별도 문서로 분리해 경로로 참조 ③ 파일을 삭제하고 규칙을 포기 ④ 규칙을 주석으로 코드 전체에 흩어 둠
Hooks가 일반 시스템 프롬프트 지침보다 자동화에 적합한 근본 이유는? ① 훅은 하니스가 실행을 보장하지만, 프롬프트 지침은 모델이 따를 수도 안 따를 수도 있기 때문 ② 훅은 토큰을 소비하지 않기 때문 ③ 훅은 모델을 더 똑똑하게 만들기 때문 ④ 훅은 프롬프트 캐시를 항상 무효화하기 때문
팀 단위로 Claude Code를 운영할 때 에이전트/환경 정의를 버전 관리하는 권장 방식은? ① 정의를 각자 머릿속에만 둠 ② 정의를 YAML로 작성해 저장소에 커밋하고 CI에서 적용 ③ 정의를 매번 채팅으로 즉석에서 입력 ④ 정의를 이미지 파일로 저장
상황. 슬래시 커맨드를 만들 때, 명령 안에서 외부 인자나 컨텍스트를 받아 동작을 달리하게 하려 한다. 가장 적절한 설계는? ① 명령마다 완전히 별개의 명령을 수십 개 만든다 ② 명령이 인자를 받아 동작을 분기하도록 설계한다 ③ 명령은 인자를 받을 수 없으므로 포기한다 ④ 인자를 시스템 프롬프트에 하드코딩한다
CLAUDE.md에 코드 스타일 세부 지침(예: 들여쓰기 칸 수)을 직접 넣기보다 권장되는 대안은? ① 모든 스타일을 CLAUDE.md 본문에 길게 나열 ② 린터·훅·슬래시 커맨드로 스타일을 강제 ③ 스타일을 모델이 알아서 추측하게 둠 ④ 스타일 지침을 API 키와 함께 저장
프롬프트에서 모델에 도구 사용을 유도할 때, 최신 Claude 모델(예: Opus 4.x)에서 "CRITICAL: YOU MUST 이 도구를 반드시 써라" 같은 강한 표현이 권장되지 않는 이유는? ① 모델이 그 표현을 이해하지 못해서 ② 최신 모델은 지시를 더 충실히 따르므로 도구를 과도하게 호출(overtriggering)하게 되기 때문 ③ 토큰을 더 소비해서 ④ 캐시를 무효화해서
구조화 출력에서 응답을 특정 JSON 스키마로 강제하는 권장 방법은? ① 시스템 프롬프트에 "JSON으로 답해"라고만 적기 ② 응답을 정규식으로 사후 파싱하기 ③ 어시스턴트 턴에 { 를 prefill로 채워 강제 ④ output_config.format에 json_schema를 지정(또는 SDK의 parse 헬퍼 사용)
상황. 최신 Claude 모델로 마이그레이션하면서, 마지막 어시스턴트 턴을 prefill로 채워 JSON 출력을 강제하던 코드가 400 에러를 낸다. 올바른 대체는? ① prefill을 더 길게 작성 ② 구조화 출력(output_config.format)이나 시스템 프롬프트 지침으로 대체 ③ temperature를 0으로 설정 ④ 모델을 더 오래된 버전으로 되돌림
Few-shot 프롬프팅에서 예시를 제공하는 주된 효과로 가장 적절한 것은? ① 모델의 컨텍스트 창을 늘림 ② 원하는 출력 형식·패턴을 시연해 형식 오류와 모호함을 줄임 ③ API 호출 비용을 절반으로 줄임 ④ 도구 정의를 자동 생성
구조화 출력의 JSON 스키마에서 모든 객체에 권장되거나 요구되는 설정은? ① additionalProperties: false ② minLength 제약 필수 ③ 재귀 스키마 사용 ④ 모든 필드를 optional로 둠
상황. 추출 작업에서 도구 파라미터가 항상 유효한 스키마를 따르도록 보장하고 싶다. 가장 적절한 방법은? ① 도구 정의에 strict: true를 설정 ② 도구 설명을 길게 작성 ③ tool_choice를 none으로 설정 ④ 도구를 제거하고 텍스트로 받음
프롬프트 재현성을 위해 시스템 프롬프트와 프롬프트 자산을 버전 관리해야 하는 이유로 가장 적절한 것은? ① 프롬프트 변경이 출력 동작을 바꾸므로 이력 추적과 롤백이 필요하기 때문 ② 프롬프트가 모델 가중치를 바꾸기 때문 ③ 버전 관리가 토큰을 절약하기 때문 ④ 프롬프트가 캐시를 자동 생성하기 때문
상황. 모델이 응답 앞에 "Here is the summary:" 같은 군더더기 서두를 붙인다. prefill 없이 이를 없애는 권장 방법은? ① 어시스턴트 turn prefill로 서두를 미리 채움 ② 시스템 프롬프트에 "서두 없이 바로 답하라"는 지침 추가 ③ max_tokens를 0으로 설정 ④ 응답을 정규식으로 잘라냄
tool_choice 옵션 중 "모델이 반드시 지정한 특정 도구를 쓰게" 강제하는 값은? ① {"type": "auto"} ② {"type": "any"} ③ {"type": "tool", "name": "..."} ④ {"type": "none"}
상황. 분류 작업에서 모델이 정해진 라벨 집합 중 하나만 출력하도록 보장하려 한다. 가장 견고한 방법은? ① 자유 텍스트로 답하게 하고 사람이 검수 ② 스키마의 enum이나 strict 도구로 유효 라벨을 제약 ③ temperature를 높여 다양성 확보 ④ prefill로 라벨 첫 글자를 채움
구조화 출력 JSON 스키마에서 지원되지 않는 제약은? ① enum ② anyOf ③ 숫자 범위 제약(minimum, maximum) ④ const
상황. 같은 추출 스키마로 수천 건을 비대화식으로 처리하는데, 지연보다 비용이 더 중요하다. 가장 적절한 처리 방식은? ① 매 건을 실시간 스트리밍으로 처리 ② 배치 처리(Batches API)로 비용을 절감 ③ 매 건마다 새 도구를 정의 ④ 모든 건을 한 프롬프트에 합쳐 한 번에 처리
좋은 도구 정의에서 설명(description)을 작성할 때 가장 권장되는 방식은? ① 도구가 무엇을 하는지만 적고 언제 쓰는지는 생략 ② 도구가 무엇을 하는지뿐 아니라 "언제 호출해야 하는지" 트리거 조건을 명시 ③ 설명을 비워 두고 이름만 명확히 ④ 설명에 API 키를 포함
도구 실행이 실패했을 때 결과를 모델에 돌려주는 올바른 방법은? ① 도구 결과를 보내지 않고 침묵 ② 시스템 프롬프트를 재작성 ③ 예외를 그대로 던져 루프를 중단 ④ tool_result에 is_error: true와 함께 정보가 담긴 오류 메시지를 보냄
상황. 도구가 많아질수록 모든 스키마를 컨텍스트에 올려두기 부담스럽다. 요청마다 일부 도구만 관련될 때 권장되는 기법은? ① 모든 도구를 항상 컨텍스트에 유지 ② 툴 검색(tool search)으로 관련 스키마만 동적으로 로드 ③ 도구를 매번 삭제했다가 다시 추가 ④ 도구를 시스템 프롬프트에 문장으로 적기
MCP(Model Context Protocol)의 핵심 목적으로 가장 적절한 것은? ① 모델 가중치를 배포하는 표준 ② 외부 서비스의 도구·리소스·프롬프트를 표준화된 방식으로 연결 ③ 토큰 단가를 정하는 규약 ④ 프롬프트 캐시를 관리하는 프로토콜
상황. 한 에이전트가 GitHub MCP 서버에 연결해야 한다. 에이전트 정의의 mcp_servers에는 무엇을 선언하는가? ① 서버의 타입·이름·URL만 선언하고 인증은 포함하지 않음 ② 서버 URL과 OAuth 토큰을 함께 본문에 적음 ③ API 키를 시스템 프롬프트에 포함 ④ 도구 스키마 전체를 직접 복사
MCP 서버의 인증 자격 증명을 안전하게 관리하는 권장 방식은? ① 에이전트 정의에 토큰을 직접 박아 둠 ② 자격 증명을 도구 결과에 포함 ③ 자격 증명을 사용자 메시지에 적음 ④ 자격 증명을 vault에 저장하고 세션에 vault_ids로 연결
상황. 어떤 동작이 외부 API를 호출하고 메일을 보내는 등 되돌리기 어렵다. bash 도구 대신 전용 도구로 만들면 얻는 핵심 이점은? ① 코드가 짧아진다 ② 하니스가 타입 있는 인자를 받아 게이팅·감사·렌더링할 수 있다 ③ 토큰을 절약한다 ④ 캐시를 무효화한다
클라이언트 측 도구와 서버 측 도구의 차이로 가장 정확한 것은? ① 클라이언트 측 도구는 하니스가 실행하고, 서버 측 도구는 Anthropic 인프라에서 실행됨 ② 둘 다 항상 모델이 직접 실행 ③ 서버 측 도구는 인증이 필요 없음 ④ 클라이언트 측 도구는 스키마가 없음
상황. 제한 네트워킹(limited) 환경에서 MCP 서버에 연결하려는데 도구가 조용히 실패한다. 가장 가능성 높은 원인은? ① 모델 버전이 낮아서 ② allow_mcp_servers를 켜지 않았거나 서버 도메인을 allowed_hosts에 넣지 않아서 ③ 도구 설명이 짧아서 ④ temperature가 높아서
MCP 서버가 노출하는 도구 출력이 매우 클 때(예: 100K 토큰 초과) 기본 동작으로 가장 적절한 것은? ① 출력을 그대로 컨텍스트에 모두 주입 ② 출력을 파일로 오프로드하고 모델에 잘린 미리보기와 파일 경로를 제공 ③ 도구 호출을 실패 처리 ④ 세션을 종료
도구 정의 개수를 의도적으로 적게 유지하는 것이 권장되는 이유는? ① 도구가 많으면 모델이 혼란을 일으켜 잘못된 도구를 고를 수 있기 때문 ② 도구가 많으면 모델 가중치가 커지기 때문 ③ 도구가 많으면 인증이 불가능하기 때문 ④ 도구가 많으면 스트리밍이 안 되기 때문
프롬프트 캐싱은 접두사 일치(prefix match)로 동작한다. 다음 중 캐시를 조용히 무효화하는 대표적 패턴은? ① 시스템 프롬프트 맨 앞에 datetime.now()를 끼워 넣음 ② 안정적인 시스템 프롬프트를 맨 앞에 고정 ③ 도구 목록을 결정적으로 정렬 ④ 휘발성 내용을 마지막 캐시 중단점 뒤로 보냄
상황. 장시간 대화가 컨텍스트 창 한계에 다가간다. 서버 측 compaction을 사용할 때 반드시 지켜야 하는 것은? ① 응답의 텍스트만 추출해 다음 요청에 붙임 ② 모델을 매 턴 교체 ③ 대화 기록을 모두 삭제 ④ response.content 전체(compaction 블록 포함)를 다음 요청에 붙임
멀티 턴 대화에서 운영자 지침을 중간에 주입할 때, 캐시된 접두사를 깨지 않고 프롬프트 인젝션에 안전한 권장 방법은? ① 최상위 system 프롬프트를 매번 수정 ② messages 배열에 role: "system" 메시지를 덧붙임 ③ 사용자 메시지에 평범한 텍스트로 적음 ④ 도구를 추가·삭제
캐시 적중을 검증하려 한다. 반복되는 동일 접두사 요청에서 cache_read_input_tokens가 0이라면? ① 정상이며 캐시가 잘 동작 중 ② 접두사를 매번 바꾸는 조용한 무효화 요인이 있음 ③ 모델이 응답을 거부한 것 ④ 토큰 단가가 0인 것
상황. 에이전트가 처리할 수 없는 요청을 만났거나 자신감이 낮다. 신뢰성 있는 시스템에서 권장되는 동작은? ① 추측으로 그럴듯한 답을 만들어 진행 ② 적절히 에스컬레이션하거나 한계를 명시 ③ 무한 재시도 ④ 도구를 무작위로 호출
컨텍스트가 여러 턴에 걸쳐 낡은(stale) 도구 결과로 채워질 때, 요약 없이 오래된 항목을 잘라내는 기법은? ① compaction(요약) ② tool_choice 설정 ③ 프롬프트 캐싱 ④ context editing(컨텍스트 편집)
compaction과 context editing의 차이로 가장 정확한 것은? ① compaction은 요약으로 대체하고, context editing은 낡은 항목을 잘라냄(제거) ② 둘은 완전히 같다 ③ context editing은 세션 간 영속화이다 ④ compaction은 도구를 추가한다
상황. 안정적인 시스템 프롬프트를 캐시하려는데 매 요청마다 사용자 ID를 시스템 프롬프트에 f-string으로 끼워 넣고 있다. 이 코드의 문제는? ① 캐시는 영향받지 않는다 ② 사용자별 접두사가 되어 사용자 간 캐시 공유가 불가능해진다 ③ 모델이 더 똑똑해진다 ④ 토큰이 절반으로 준다
신뢰성 높은 에이전트를 만들 때, 되돌리기 어려운 동작(삭제, 외부 전송)에 대해 권장되는 안전장치는? ① 항상 자동 실행해 속도를 높임 ② 사용자 확인(휴먼 인 더 루프)으로 게이팅 ③ 동작을 모두 bash로 처리 ④ 로그를 남기지 않음

정리

60문항을 한 번에, 책을 덮고, 타이머를 맞춰 푸세요. 중간에 해설을 보면 실제 실력이 측정되지 않습니다.
막히는 문항은 표시(mark)하고 넘어간 뒤 마지막에 돌아오세요. 한 문항에 과도한 시간을 쓰지 않는 시간 배분이 합격의 관건입니다.
보기 네 개가 모두 그럴듯할 때는 줄기에 숨은 제약(독립성·의존성·격리·되돌릴 수 있는가)을 먼저 추출해 후보를 소거하세요.
채점은 60문항을 모두 푼 뒤 다음 절에서 하고, 찍어서 맞힌 문항도 반드시 함께 복습하세요.