iBetter Books
...
수정

문제 60문항

실제 CCA-F 시험과 동일하게 60문항을 출제합니다. 도메인 비중은 에이전트 아키텍처와 오케스트레이션 16문항(1~16번), Claude Code 설정과 워크플로우 12문항(17~28번), 프롬프트 엔지니어링과 구조화 출력 12문항(29~40번), 도구 설계와 MCP 통합 11문항(41~51번), 컨텍스트 관리와 신뢰성 9문항(52~60번)으로 배분했습니다. 각 문항은 4지선다이며 정답은 다음 절에 있습니다. 책을 덮고 타이머를 맞춘 뒤 한 번에 푸세요.

이번 회차는 시나리오형 문항의 비중을 높였습니다. 보기 네 개가 모두 문법적으로 맞아 보이는 문제가 많으니, "이 상황에서 무엇이 가장 적절한가"를 판단하는 데 집중하세요. 정답을 고른 뒤에도 나머지 보기를 왜 버렸는지 한 문장으로 설명할 수 있어야 다음 절의 해설과 비교할 수 있습니다.

도메인 1. 에이전트 아키텍처와 오케스트레이션 (1~16번)

  1. 에이전트 루프에서 클라이언트 도구(client tool)를 사용할 때, 도구를 실제로 실행하고 루프를 주도하는 주체는 누구인가?

    • A. Claude 모델 자신
    • B. 애플리케이션(여러분의 코드)
    • C. Anthropic의 서버 인프라
    • D. 도구 정의 안의 input_schema

  2. 한 번의 에이전트 루프 사이클에서 모델이 도구를 요청했고, 애플리케이션이 그 결과를 돌려보내려 한다. 결과는 어떤 블록으로, 누구의 메시지(role)에 담아야 하는가?

    • A. tool_use 블록, assistant 메시지
    • B. tool_use 블록, user 메시지
    • C. tool_result 블록, user 메시지
    • D. tool_result 블록, assistant 메시지

  3. 응답의 stop_reason이 tool_use로 돌아왔다. 애플리케이션은 어떻게 해야 하는가?

    • A. 도구를 실행하고 결과를 붙여 다시 요청을 보낸다
    • B. 루프를 종료하고 최종 텍스트를 사용자에게 보여 준다
    • C. 같은 요청을 그대로 재전송한다
    • D. 사용자에게 추가 입력을 요청한다

  4. 서버 측 도구(예: 웹 검색)를 사용하는 에이전트가 서버 측 샘플링 루프의 기본 반복 한계에 도달했다. 이때 반환되는 stop_reason과 올바른 후속 처리는?

    • A. end_turn — 작업이 끝났으므로 종료
    • B. max_tokens — max_tokens를 늘려 재시도
    • C. refusal — stop_details를 확인하고 중단
    • D. pause_turn — 직전 응답을 그대로 붙여 재요청해 이어서 진행

  5. 단일 LLM 호출, 워크플로우, 에이전트 세 계층 중 하나를 골라야 한다. "PDF에서 제목만 추출"하는 작업에 가장 적합한 계층은?

    • A. 에이전트 (모델이 스스로 경로를 결정)
    • B. 워크플로우 (코드가 루프를 제어)
    • C. 단일 LLM 호출
    • D. Managed Agents (서버가 루프를 운영)

  6. 에이전트를 만들지 결정할 때 점검하는 네 기준에 해당하지 않는 것은?

    • A. 복잡성 — 작업이 다단계이며 사전에 완전히 명세하기 어려운가
    • B. 가치 — 결과가 높은 비용과 지연을 정당화하는가
    • C. 오류 비용 — 오류를 포착하고 복구할 수 있는가
    • D. 인기도 — 해당 작업이 시장에서 많이 쓰이는가

  7. 두 번 이상 사용자에게 메시지를 보내는 멀티 에이전트 시스템에서, 오케스트레이터가 비싼 모델로 메인 루프를 돌리되 단순한 하위 작업은 저렴한 모델로 처리하고 싶다. 프롬프트 캐시를 깨뜨리지 않으면서 이를 달성하는 방법은?

    • A. 하위 작업용 서브에이전트를 저렴한 모델로 따로 띄운다
    • B. 메인 루프 중간에 모델을 교체한다
    • C. 시스템 프롬프트에 모델 전환 지시를 추가한다
    • D. tool_choice를 매 요청마다 바꾼다

  8. 행동을 bash 도구로 두는 것과 전용 도구(dedicated tool)로 승격하는 것 사이에서 결정한다. 다음 중 전용 도구로 승격해야 할 가장 강한 근거는?

    • A. 해당 행동이 자주 호출된다
    • B. 되돌리기 어려운 행동이라 사용자 확인으로 게이팅해야 한다
    • C. 명령 문자열이 짧다
    • D. 모델이 그 행동을 좋아한다

  9. Managed Agents에서 세션을 생성하려 한다. model, system, tools 필드는 어디에 두어야 하는가?

    • A. sessions.create()의 본문
    • B. 환경(environment) 설정
    • C. agents.create()로 만든 에이전트 객체
    • D. 컨테이너 설정

  10. Managed Agents의 권장 흐름에서 agents.create()는 얼마나 자주 호출해야 하는가?

    • A. 매 요청(세션 생성)마다
    • B. 매 크론 틱마다
    • C. 도구가 바뀔 때마다 새로 생성
    • D. 한 번만(설정 단계), 이후 ID를 저장해 재사용

  11. 어떤 에이전트가 작업 중 항상 묻기(always_ask) 권한 정책이 걸린 도구를 호출했다. 세션은 어떤 상태가 되며, 클라이언트는 무엇을 보내야 하는가?

    • A. 세션이 idle이 되고, tool_confirmation 이벤트를 보낸다
    • B. 세션이 terminated 되고, 새 세션을 만든다
    • C. 세션이 running을 유지하고, 자동으로 실행된다
    • D. 세션이 rescheduling 되고, 대기한다

  12. Managed Agents 세션의 SSE 스트림이 도구 승인 대기 중에 끊겼다가 재연결됐다. 이벤트 누락을 막는 올바른 패턴은?

    • A. 재연결 후 스트림만 다시 읽으면 충분하다
    • B. 재연결 시 events.list로 과거 이력을 먼저 가져와 이벤트 ID로 중복 제거한다
    • C. 세션을 삭제하고 새로 만든다
    • D. interrupt 이벤트를 보내 초기화한다

  13. 멀티 에이전트 오케스트레이션에서 coordinator의 로스터(multiagent.agents)는 어디에 선언하는가?

    • A. sessions.create()의 본문
    • B. tools 배열의 한 항목으로
    • C. 환경의 networking 설정
    • D. agents.create()의 최상위 multiagent 필드

  14. 코드로 제어하는 다단계 파이프라인에서, 모델이 도구를 호출할지 코드가 결정하고 루프를 직접 돌린다. 이 표현에 가장 부합하는 계층은?

    • A. 단일 LLM 호출
    • B. Managed Agents
    • C. 워크플로우(Claude API + tool use, 직접 루프 제어)
    • D. 임베딩 엔드포인트

  15. 클라이언트 측 무한 반복을 막기 위한 가장 직접적인 방어 수단은?

    • A. 클라이언트 루프에 반복 깊이 한계(max_iterations)를 둔다
    • B. max_tokens를 0으로 설정
    • C. thinking을 비활성화
    • D. tool_choice를 none으로 고정

  16. 프로그래매틱 도구 호출(PTC, programmatic tool calling)을 사용하기에 가장 적합한 상황은?

    • A. 도구가 하나뿐이고 한 번만 호출된다
    • B. 모든 도구를 사용자가 승인해야 한다
    • C. 응답을 스트리밍으로 보여 줘야 한다
    • D. 순차적 도구 호출이 많거나 중간 결과가 커서 컨텍스트에 닿기 전 걸러야 한다

도메인 2. Claude Code 설정과 워크플로우 (17~28번)

  1. 프로젝트마다 적용되는 Claude Code 지침을 저장소에 체크인해 팀과 공유하려 한다. 가장 적합한 위치는?

    • A. 프로젝트 루트의 CLAUDE.md
    • B. 개인 홈의 글로벌 설정 파일
    • C. 환경 변수
    • D. 매 세션 채팅으로 직접 입력

  2. "X를 할 때마다 자동으로 Y를 실행"처럼 결정적이고 자동화된 동작을 Claude Code에 추가하려 한다. 올바른 메커니즘은?

    • A. 메모리(memory)에 선호로 저장
    • B. 시스템 프롬프트에 부탁
    • C. settings.json의 hooks 설정
    • D. 슬래시 커맨드 이름 변경

  3. hooks가 메모리나 선호 저장으로 구현할 수 없는 동작을 처리할 수 있는 이유는?

    • A. hooks는 모델이 스스로 실행하기 때문
    • B. hooks는 하니스(harness)가 실행하므로 결정적 자동 동작을 보장하기 때문
    • C. hooks는 더 큰 컨텍스트를 갖기 때문
    • D. hooks는 토큰을 적게 쓰기 때문

  4. 권한 프롬프트를 줄이기 위해 읽기 전용 명령을 허용 목록에 추가하려 한다. 가장 적절한 위치는?

    • A. 시스템 프롬프트
    • B. 채팅 메시지
    • C. CLAUDE.md 본문
    • D. 프로젝트 .claude/settings.json의 permissions

  5. 사용자가 "/배포" 같은 슬래시 커맨드를 입력했다. 이것이 가리키는 것은?

    • A. 스킬(skill)
    • B. 셸 별칭
    • C. 환경 변수
    • D. git 훅

  6. 여러 스킬 이름이 디렉터리 범위로 한정되어 접두어가 붙어 있다(예: apps/web:deploy). 작업 파일이 해당 디렉터리 하위에 있을 때 올바른 선택 원칙은?

    • A. 항상 접두어 없는 변형을 선택
    • B. 알파벳순으로 먼저 오는 것을 선택
    • C. 가장 구체적인 디렉터리 범위의 변형을 선택
    • D. 무작위로 선택

  7. 현재 작업 디렉터리가 기본 브랜치일 때, 사용자가 커밋을 요청하지 않았는데 변경을 커밋하려 한다. 올바른 처리는?

    • A. 기본 브랜치에 바로 커밋
    • B. 사용자가 요청할 때만, 그리고 기본 브랜치라면 먼저 브랜치를 분기
    • C. 항상 강제 푸시
    • D. 커밋 메시지 없이 커밋

  8. Claude Code에서 격리가 필요한 기능 작업을 시작할 때, 현재 작업 공간과 분리하는 권장 방법은?

    • A. 같은 디렉터리에서 그대로 작업
    • B. 저장소를 복제만 한다
    • C. 모든 변경을 stash 한다
    • D. git worktree로 격리된 작업 공간을 만든다

  9. Claude Code의 효력(effort) 설정에 관한 설명으로 옳은 것은?

    • A. 낮은 effort는 더 적고 통합된 도구 호출과 짧은 확인을 낳는다
    • B. effort는 thinking과 무관하다
    • C. 높은 effort는 항상 비용이 더 싸다
    • D. effort는 max_tokens와 동일하다

  10. 커밋 메시지를 작성할 때, 이 교재 환경의 규약(Conventional Commits)을 따른다면 버그 수정 커밋의 타입으로 올바른 것은?

    • A. feat
    • B. chore
    • C. fix
    • D. docs

  11. 백그라운드로 오래 실행되는 명령을 띄우고, 종료 시 다시 호출되도록 하려 한다. 가장 적절한 방법은?

    • A. 명령 끝에 &를 붙인다
    • B. run_in_background 옵션으로 분리 실행한다
    • C. 포그라운드에서 sleep으로 대기한다
    • D. 매번 수동으로 상태를 확인한다

  12. 새 기능 구현을 시작하기 전에 명세나 요구사항을 받은 상황이다. 코드를 건드리기 전에 권장되는 작업은?

    • A. 곧바로 구현 코드 작성
    • B. 테스트를 모두 삭제
    • C. 강제 푸시 준비
    • D. 잘게 쪼갠 구현 계획을 먼저 작성

도메인 3. 프롬프트 엔지니어링과 구조화 출력 (29~40번)

  1. 응답을 특정 JSON 스키마에 맞게 강제하려 한다. Claude API에서 권장되는 방법은?

    • A. output_config: {format: {type: "json_schema", schema: ...}}를 사용한다
    • B. assistant 프리필로 {를 미리 넣는다
    • C. 시스템 프롬프트에 "JSON으로만"이라고만 적는다
    • D. 응답을 정규식으로 후처리한다

  2. 최신 Opus 4.x 계열에서 마지막 assistant 턴 프리필(prefill)로 출력 형식을 강제하려 하면 어떻게 되는가?

    • A. 정상 동작한다
    • B. 경고만 뜨고 무시된다
    • C. 400 오류가 발생하므로 구조화 출력이나 시스템 프롬프트 지시로 대체해야 한다
    • D. thinking이 자동 비활성화된다

  3. 분류 작업에서 유효한 라벨 집합으로 출력을 제한하려 한다. 가장 견고한 방법은?

    • A. 자유 텍스트로 받고 후처리
    • B. enum 필드를 가진 도구 또는 구조화 출력 사용
    • C. temperature를 0으로
    • D. max_tokens를 1로

  4. 구조화 출력(JSON schema)에서 지원되지 않는 제약은?

    • A. enum, const
    • B. anyOf, allOf
    • C. date-time 형식
    • D. minLength, maximum 같은 수치·길이 제약

  5. 특정 도구를 반드시 호출하도록 강제하려 한다. 올바른 tool_choice 설정은?

    • A. {"type": "tool", "name": "..."}
    • B. {"type": "auto"}
    • C. {"type": "any"}
    • D. {"type": "none"}

  6. 도구 설명(description)을 작성할 때, 최신 Opus 모델에서 도구 호출률을 높이는 데 가장 효과적인 작성 방식은?

    • A. 도구가 무엇을 하는지만 적는다
    • B. "CRITICAL: 반드시 사용"을 반복한다
    • C. 언제 호출해야 하는지(트리거 조건)를 명시한다
    • D. 설명을 비워 둔다

  7. 적응형 사고(adaptive thinking)에 관한 설명으로 옳은 것은?

    • A. budget_tokens로 사고량을 고정해야 한다
    • B. thinking: {type: "adaptive"}로 모델이 사고 깊이를 스스로 정한다
    • C. 적응형 사고는 도구 사용과 함께 쓸 수 없다
    • D. 적응형 사고는 항상 비활성화가 기본이다

  8. effort 파라미터의 올바른 위치와 효과는?

    • A. 최상위 파라미터이며 max_tokens를 대체한다
    • B. thinking 안에 두며 사고를 끈다
    • C. tools 안에 두며 도구 수를 제한한다
    • D. output_config 안에 두며, 사고 깊이와 토큰 소비의 균형을 조절한다

  9. 한 시스템 프롬프트가 "CRITICAL: You MUST use this tool"처럼 공격적인 지시로 가득하다. 최신 Opus 모델로 옮기면 흔히 나타나는 증상과 해법은?

    • A. 도구 과다 호출(overtrigger) — 지시를 완화
    • B. 도구 사용이 줄어든다 — 더 강하게 지시
    • C. 변화 없음 — 그대로 유지
    • D. thinking이 켜진다 — effort를 낮춘다

  10. 대화 도중 운영자(operator) 권한의 지시를 안전하게 주입하면서 캐시된 프리픽스를 보존하려 한다. 권장 방법은?

    • A. 최상위 system 프롬프트를 직접 수정
    • B. user 메시지 안에 일반 텍스트로 끼워 넣기
    • C. messages 배열 끝에 {"role": "system", ...} 메시지를 추가(지원 모델, 베타)
    • D. tools를 새로 추가

  11. client.messages.parse()(또는 Pydantic/Zod 헬퍼)를 쓰는 주된 이점은?

    • A. 토큰을 덜 쓴다
    • B. 응답을 스키마에 맞춰 자동 검증·파싱한다
    • C. 항상 더 빠르다
    • D. thinking을 자동으로 켠다

  12. 구조화 출력과 함께 쓸 수 없는(400 오류를 내는) 기능은?

    • A. 스트리밍
    • B. 배치 API
    • C. 토큰 카운팅
    • D. 인용(citations)

도메인 4. 도구 설계와 MCP 통합 (41~51번)

  1. MCP 서버를 Managed Agents 에이전트에 연결할 때, 에이전트의 mcp_servers 배열에 들어가는 필드는?

    • A. type, name, url (인증 정보 없음)
    • B. type, name, url, access_token
    • C. 인증 토큰만
    • D. 도구 스키마 전체

  2. MCP 서버의 자격 증명(인증)은 어디에 저장하고 세션에 어떻게 연결하는가?

    • A. 에이전트의 mcp_servers에 직접 토큰을 넣는다
    • B. 볼트(vault)에 저장하고 세션의 vault_ids로 연결한다
    • C. 시스템 프롬프트에 넣는다
    • D. 환경 변수로 컨테이너에 넣는다

  3. 호스팅된 MCP 서버(예: mcp.linear.app)는 보통 어떤 종류의 토큰을 요구하는가?

    • A. 서비스의 네이티브 REST API 키
    • B. SSH 키
    • C. OAuth 베어러 토큰
    • D. 평문 비밀번호

  4. 사용 가능한 도구가 매우 많지만 요청마다 관련 도구는 소수다. 모든 스키마를 미리 컨텍스트에 올리지 않으려 한다. 적합한 기능은?

    • A. 프롬프트 캐싱
    • B. compaction
    • C. 배치 API
    • D. 도구 검색(tool search)

  5. 도구 검색이 캐시를 보존하면서 동작하는 핵심 이유는?

    • A. 도구 스키마를 교체하지 않고 추가(append)하기 때문
    • B. 도구를 매번 비우기 때문
    • C. 모델을 바꾸기 때문
    • D. system 프롬프트를 수정하기 때문

  6. 도구 정의 작성의 모범 사례로 옳지 않은 것은?

    • A. 명확하고 서술적인 이름 사용
    • B. 각 속성에 description 추가
    • C. 가능한 한 많은 도구를 넣어 선택지를 늘린다
    • D. 고정된 값 집합에는 enum 사용

  7. 코드 실행(code execution) 도구에 관한 설명으로 옳은 것은?

    • A. 클라이언트에서 직접 실행해야 한다
    • B. Anthropic이 호스팅하는 샌드박스 컨테이너에서 서버 측으로 실행된다
    • C. 인터넷에 자유롭게 접근한다
    • D. tools에 선언할 수 없다

  8. 도구 실행이 실패했음을 모델에 알리는 올바른 tool_result 작성법은?

    • A. content를 비워 둔다
    • B. role을 assistant로 바꾼다
    • C. 응답을 무시한다
    • D. is_error: true와 함께 정보가 담긴 오류 메시지를 넣는다

  9. 비밀(API 키)이 필요한 비-MCP API/CLI를 self_hosted 환경에서 호출하려 한다. 환경 변수 자격 증명을 쓸 수 없는 상황에서 비밀을 호스트 측에 유지하는 패턴은?

    • A. 커스텀 도구를 선언해 오케스트레이터가 호스트 자격 증명으로 호출을 수행한다
    • B. 시스템 프롬프트에 키를 넣는다
    • C. user 메시지에 키를 넣는다
    • D. 키를 컨테이너 파일에 쓴다

  10. 서버 측 도구(예: 코드 실행)와 클라이언트 측 도구(예: 메모리)의 가장 정확한 구분은?

    • A. 서버 측이 항상 더 빠르다
    • B. 클라이언트 측은 스키마가 없다
    • C. 서버 측은 Anthropic 인프라에서 실행, 클라이언트 측은 여러분의 하니스가 실행
    • D. 둘은 동일하다

  11. limited 네트워킹 환경에서 MCP 서버에 연결하려는데 도구가 조용히 실패한다. 가장 가능성 높은 원인은?

    • A. 모델 ID가 틀렸다
    • B. allow_mcp_servers가 true가 아니거나 MCP 도메인이 allowed_hosts에 없다
    • C. max_tokens가 너무 작다
    • D. thinking이 켜져 있다

도메인 5. 컨텍스트 관리와 신뢰성 (52~60번)

  1. 프롬프트 캐싱의 단 하나의 불변식(invariant)은 무엇인가?

    • A. 캐시는 메시지 단위로 동작한다
    • B. 캐싱은 프리픽스 일치이며, 프리픽스 어디든 한 바이트만 바뀌어도 그 뒤가 모두 무효화된다
    • C. 캐시는 모델과 무관하다
    • D. 캐시는 출력 토큰에만 적용된다

  2. 반복 요청에서 cache_read_input_tokens가 계속 0이다. 가장 흔한 원인은?

    • A. max_tokens가 작다
    • B. thinking이 꺼져 있다
    • C. 시스템 프롬프트의 datetime.now()나 UUID, 정렬되지 않은 JSON 같은 조용한 무효화 요인
    • D. 도구가 없다

  3. 렌더링 순서를 고려할 때, 캐시 프리픽스를 깨뜨리는 가장 파괴적인 변경은?

    • A. user 메시지의 마지막 블록 변경
    • B. tool_choice 변경
    • C. 이미지 토글
    • D. tools(위치 0) 정의의 추가·제거·재정렬 또는 모델 교체

  4. 긴 대화가 컨텍스트 윈도를 넘어설 가능성이 있다. 서버 측에서 이전 컨텍스트를 요약하는 기능은?

    • A. compaction(컴팩션)
    • B. 컨텍스트 편집(context editing)
    • C. 프롬프트 캐싱
    • D. 토큰 카운팅

  5. compaction을 쓸 때 가장 중요한 클라이언트 처리는?

    • A. 텍스트만 추출해 다음 요청에 붙인다
    • B. response.content 전체(compaction 블록 포함)를 다음 요청에 붙인다
    • C. 매번 새 대화를 시작한다
    • D. max_tokens를 0으로 둔다

  6. 오래된 도구 결과와 완료된 사고 블록을 요약 없이 잘라내(prune) 트랜스크립트를 가볍게 유지하는 기능은?

    • A. compaction
    • B. 프롬프트 캐싱
    • C. 컨텍스트 편집(context editing)
    • D. 메모리(memory)

  7. 세션이 끝나도 상태가 유지되어야 하는(교차 세션 지속) 요구에 적합한 기능은?

    • A. 컨텍스트 편집
    • B. compaction
    • C. tool_choice
    • D. 메모리(memory)

  8. Claude Fable 5에서 안전 분류기가 요청을 거절하면 어떤 형태로 반환되며, 코드는 무엇을 먼저 확인해야 하는가?

    • A. HTTP 200에 stop_reason: "refusal" — content를 읽기 전에 stop_reason을 먼저 확인
    • B. HTTP 400 오류 — 재시도
    • C. HTTP 500 — 백오프
    • D. 빈 스트림 — 무시

  9. 비-스트리밍 요청에서 max_tokens를 매우 크게(예: 64000) 잡으면 SDK가 거부하거나 타임아웃 위험이 있다. 권장 처리는?

    • A. max_tokens를 1로 낮춘다
    • B. 스트리밍을 사용하고 get_final_message로 최종 응답을 얻는다
    • C. thinking을 끈다
    • D. 요청을 두 번 보낸다

정리

  • 이 절은 도메인 비중(16·12·12·11·9)을 그대로 반영한 60문항을 담았다. 시험은 개념의 이름이 아니라 "이 상황에서 무엇이 적절한가"를 묻는다.
  • 정답은 다음 절에 있다. 채점 전에 보기를 다시 보지 말고, 한 번에 끝까지 푼 뒤 도메인별 점수를 1회 결과와 비교하라.
  • 시나리오형 문항은 보기 네 개가 모두 그럴듯하게 설계되어 있다. 각 보기를 버린 이유를 한 문장으로 정리해 두면 다음 절의 해설과 정확히 맞춰 볼 수 있다.
← 27장. 모의고사 2회02. 정답과 해설 →