정답과 해설

60문항 전체의 정답과 해설입니다. 먼저 정답표로 빠르게 채점한 뒤, 도메인별 점수를 1회 결과와 비교하세요. 그다음 해설을 읽되, 맞힌 문항이라도 오답 보기가 왜 함정인지까지 확인해야 같은 함정에 다시 걸리지 않습니다. 시험은 표면을 바꿔 같은 개념을 반복해서 묻기 때문입니다.

정답표

도메인 1 해설 (1~16번)

1. 정답 B. 클라이언트 도구는 Anthropic이 이름과 스키마를 정의하더라도 실제 실행은 여러분의 애플리케이션이 한다. 모델(A)은 "무엇을 할지"만 결정하며 코드를 실행하지 못한다. 서버 인프라(C)는 서버 측 도구에만 해당한다. input_schema(D)는 입력 형식 명세일 뿐 실행 주체가 아니다.

2. 정답 C. 모델은 응답에 tool_use 블록을 담아 보내고, 애플리케이션은 그 결과를 tool_result 블록으로 만들어 user 메시지에 담아 보낸다. tool_use는 모델(assistant)이 생성하는 블록이므로 A·B는 방향이 반대다. tool_result는 user 역할에 담으므로 assistant에 담는 D도 틀리다.

3. 정답 A. tool_use는 모델이 도구를 호출하고 싶다는 신호이므로, 도구를 실행하고 tool_result를 붙여 루프를 이어 가야 한다. 종료(B)는 end_turn일 때다. 그대로 재전송(C)은 무한 반복을 부른다. 추가 입력 요청(D)은 상황과 무관하다.

4. 정답 D. 서버 측 도구의 샘플링 루프가 기본 10회 한계에 도달하면 pause_turn이 반환되며, user 메시지와 assistant 응답을 그대로 붙여 재요청하면 서버가 이어서 진행한다. "Continue" 같은 추가 메시지를 넣으면 안 된다. end_turn(A)은 정상 종료, max_tokens(B)는 출력 한계, refusal(C)은 안전 거절이다.

5. 정답 C. "제목만 추출"은 한 번의 요청과 한 번의 응답으로 끝나는 단발성 작업이므로 단일 LLM 호출이 가장 적합하다. 에이전트(A)나 Managed Agents(D)는 개방형·다단계 작업에 쓰는 과한 선택이고, 워크플로우(B)도 코드 제어 루프가 필요 없는 이 작업에는 과하다. 가장 단순한 계층을 고르는 것이 원칙이다.

6. 정답 D. 에이전트 여부를 판단하는 네 기준은 복잡성, 가치, 실행 가능성(viability), 오류 비용이다. 인기도(D)는 기준이 아니다. 시험은 "viability"가 빠진 보기나 엉뚱한 기준을 끼워 넣어 함정을 만든다.

7. 정답 A. 모델을 메인 루프 중간에 바꾸면 캐시가 깨진다. 따라서 저렴한 모델은 별도 서브에이전트로 띄우고 메인 루프는 한 모델로 유지한다. B는 캐시를 깨고, C는 system 수정으로 역시 캐시를 깬다. tool_choice 변경(D)은 비용·모델 문제와 무관하다.

8. 정답 B. 전용 도구 승격의 가장 강한 근거는 게이팅이 필요한 비가역적 행동(외부 호출, 삭제 등)이다. 전용 도구는 타입화된 인자를 주어 하니스가 가로채고 확인을 걸 수 있다. 호출 빈도(A)나 명령 길이(C), 모델 선호(D)는 결정 근거가 아니다.

9. 정답 C. Managed Agents에서 model·system·tools는 에이전트 객체에 둔다. 세션(A)은 에이전트를 ID로 참조만 한다. 환경(B)은 컨테이너 템플릿이고, 컨테이너(D)는 실행 공간이다. 이 책임 분리가 시험의 단골 함정이다.

10. 정답 D. 에이전트는 버전 관리되는 영속 객체이므로 한 번만 생성해 ID를 저장하고 재사용한다. 매 요청(A)이나 크론 틱(B)마다 생성하면 고아 에이전트가 쌓이고 버전 모델을 무너뜨린다. 도구 변경(C) 시에는 새로 만들지 말고 update로 새 버전을 만든다.

11. 정답 A. always_ask 정책의 도구가 호출되면 세션은 idle이 되어 대기하고, 클라이언트는 tool_confirmation(allow/deny)을 보낸다. terminated(B)는 비가역 종료, running 유지·자동 실행(C)은 always_allow일 때, rescheduling(D)은 재시도 가능한 오류 상황이다.

12. 정답 B. SSE 스트림은 재생(replay)이 없으므로, 재연결 시 events.list로 과거 이력을 먼저 가져와 이벤트 ID로 중복 제거해야 누락을 막는다. 스트림만 다시 읽으면(A) 끊긴 사이의 이벤트를 잃는다. 세션 삭제(C)나 interrupt(D)는 진행 중 작업을 망친다.

13. 정답 D. multiagent.agents는 에이전트의 최상위 필드로 선언한다. 세션 본문(A)이나 tools 배열의 한 항목(B)으로 넣는 것은 흔한 오답 함정이다. networking(C)은 환경 설정이다.

14. 정답 C. "코드가 호출 여부를 결정하고 루프를 직접 돈다"는 워크플로우(Claude API + tool use) 계층의 정의다. 단일 호출(A)은 루프가 없고, Managed Agents(B)는 서버가 루프를 운영하며, 임베딩(D)은 무관하다.

15. 정답 A. 무한 반복은 클라이언트 루프에 반복 깊이 한계(max_iterations)를 두어 막는다. max_tokens=0(B)은 캐시 프리워밍용이고, thinking 비활성화(C)나 tool_choice=none(D)은 반복 자체를 막지 못한다.

16. 정답 D. PTC는 순차 호출이 많거나 중간 결과가 커서 컨텍스트에 닿기 전 걸러야 할 때 유용하다. 스크립트가 컨테이너에서 실행되며 중간 결과는 코드 안에서 처리되고 최종 출력만 모델에 돌아간다. 도구 하나·한 번(A), 사용자 승인(B), 스트리밍(C)은 PTC의 동기와 다르다.

도메인 2 해설 (17~28번)

17. 정답 A. 저장소에 체크인해 팀과 공유하는 프로젝트 지침은 프로젝트 루트의 CLAUDE.md에 둔다. 글로벌 설정(B)은 개인 전체에 적용되고, 환경 변수(C)나 매 세션 입력(D)은 공유·영속성이 떨어진다.

18. 정답 C. "X를 할 때마다 자동으로 Y" 같은 결정적 자동 동작은 settings.json의 hooks로 구현한다. 메모리·선호(A)나 시스템 프롬프트(B)는 모델의 자발적 판단에 의존하므로 자동 동작을 보장하지 못한다. 슬래시 커맨드 이름 변경(D)은 무관하다.

19. 정답 B. hooks는 모델이 아니라 하니스가 실행하므로, 모델의 판단과 무관하게 결정적 자동 동작을 보장한다. A는 사실과 반대다. 더 큰 컨텍스트(C)나 토큰 절약(D)은 hooks의 본질이 아니다.

20. 정답 D. 읽기 전용 명령 허용 목록은 프로젝트 .claude/settings.json의 permissions에 둔다. 시스템 프롬프트(A)·채팅(B)·CLAUDE.md 본문(C)은 권한 설정의 정식 위치가 아니다.

21. 정답 A. 사용자가 말하는 "슬래시 커맨드"는 스킬(skill)을 가리킨다. 셸 별칭(B)·환경 변수(C)·git 훅(D)은 스킬 호출 메커니즘이 아니다.

22. 정답 C. 작업 파일이 특정 디렉터리 하위에 있으면 가장 구체적인 디렉터리 범위의 변형을 선택한다. 항상 접두어 없는 변형(A)이나 알파벳순(B)·무작위(D)는 규칙이 아니다.

23. 정답 B. 커밋·푸시는 사용자가 요청할 때만 하며, 기본 브랜치라면 먼저 브랜치를 분기한다. 기본 브랜치 직접 커밋(A)·강제 푸시(C)·메시지 없는 커밋(D)은 모두 안전하지 않은 처리다.

24. 정답 D. 격리가 필요한 기능 작업은 git worktree로 분리된 작업 공간을 만든다. 같은 디렉터리 작업(A)은 격리가 안 되고, 단순 복제(B)나 stash(C)는 의도와 다르다.

25. 정답 A. effort는 사고 깊이와 토큰 효율의 절충을 조절하며, 낮은 effort는 더 적고 통합된 도구 호출과 짧은 확인을 낳는다. effort는 thinking과 함께 동작하므로 B는 틀리고, 높은 effort가 더 싸다(C)는 반대이며, max_tokens(D)와는 다른 개념이다.

26. 정답 C. Conventional Commits에서 버그 수정은 fix다. feat(A)은 새 기능, chore(B)는 잡일, docs(D)는 문서만 변경할 때다.

27. 정답 B. 오래 실행되며 종료 시 재호출이 필요한 명령은 run_in_background로 분리 실행한다. &(A)는 불필요하고 권장되지 않으며, 포그라운드 sleep(C)은 막혀 있고, 수동 확인(D)은 비효율적이다.

28. 정답 D. 명세를 받은 다단계 작업은 코드를 건드리기 전에 잘게 쪼갠 구현 계획을 먼저 작성하는 것이 권장된다. 즉시 구현(A)·테스트 삭제(B)·강제 푸시 준비(C)는 모두 잘못된 순서다.

도메인 3 해설 (29~40번)

29. 정답 A. JSON 스키마 강제는 output_config.format(json_schema)으로 한다. 프리필(B)은 최신 모델에서 400을 내고, "JSON으로만"이라는 지시만(C)이나 정규식 후처리(D)는 보장이 약하다.

30. 정답 C. 최신 Opus 4.x 계열에서 마지막 assistant 턴 프리필은 400 오류를 낸다. 따라서 구조화 출력이나 시스템 프롬프트 지시로 대체해야 한다. 정상 동작(A)·경고 후 무시(B)·thinking 비활성화(D)는 모두 틀리다.

31. 정답 B. 분류 라벨 제한은 enum 필드를 가진 도구 또는 구조화 출력으로 한다. 자유 텍스트 후처리(A)는 견고하지 않고, temperature=0(C)이나 max_tokens=1(D)은 라벨 집합을 강제하지 못한다.

32. 정답 D. 구조화 출력은 minLength·maximum 같은 수치·길이 제약을 지원하지 않는다. enum·const(A), anyOf·allOf(B), date-time 형식(C)은 지원된다. SDK는 미지원 제약을 클라이언트 측에서 검증한다.

33. 정답 A. 특정 도구 강제는 {"type": "tool", "name": "..."}다. auto(B)는 모델이 결정, any(C)는 도구 중 하나를 반드시 사용, none(D)은 도구 사용 금지다.

34. 정답 C. 최신 Opus는 도구를 보수적으로 호출하므로, 설명에 "언제 호출해야 하는지"라는 트리거 조건을 명시하면 호출률이 오른다. 무엇을 하는지만(A)으로는 부족하고, "CRITICAL: 반드시"(B)는 과다 호출을 부르며, 빈 설명(D)은 최악이다.

35. 정답 B. 적응형 사고는 thinking: {type: "adaptive"}로 설정하며 모델이 사고 깊이를 스스로 정한다. budget_tokens 고정(A)은 최신 모델에서 폐기·400이고, 도구 사용과 병행 불가(C)는 거짓이며, 적응형 사고는 명시적으로 켜야 동작한다(D 거짓).

36. 정답 D. effort는 output_config 안에 두며 사고 깊이와 토큰 소비의 균형을 조절한다. 최상위·max_tokens 대체(A), thinking 안에 두어 사고를 끔(B), tools 안에 두어 도구 수 제한(C)은 모두 틀리다.

37. 정답 A. 최신 Opus는 시스템 프롬프트를 더 충실히 따르므로 "CRITICAL: MUST" 같은 공격적 지시는 도구 과다 호출을 부른다. 해법은 지시를 완화하는 것이다. 더 강하게 지시(B)나 그대로 유지(C)는 증상을 악화시키고, D는 인과가 다르다.

38. 정답 C. 대화 도중 운영자 지시는 messages 끝에 {"role": "system", ...} 메시지로 주입하면 캐시된 프리픽스를 보존하면서 운영자 권한을 갖는다(베타, 지원 모델). 최상위 system 수정(A)은 캐시를 깨고, user 텍스트(B)는 스푸핑 가능하며, tools 추가(D)는 캐시를 깬다.

39. 정답 B. parse() 계열 헬퍼는 응답을 스키마에 맞춰 자동 검증·파싱해 준다. 토큰 절약(A)·항상 더 빠름(C)·thinking 자동 켜짐(D)은 헬퍼의 이점이 아니다.

40. 정답 D. 구조화 출력은 인용(citations)과 함께 쓰면 400 오류를 낸다. 스트리밍(A)·배치 API(B)·토큰 카운팅(C)과는 함께 동작한다.

도메인 4 해설 (41~51번)

41. 정답 A. 에이전트의 mcp_servers에는 type·name·url만 넣고 인증 정보는 넣지 않는다. 토큰을 넣는 B나 인증만(C), 스키마 전체(D)는 틀리다. 자격 증명은 볼트로 분리한다.

42. 정답 B. MCP 자격 증명은 볼트(vault)에 저장하고 세션의 vault_ids로 연결한다. mcp_servers에 직접 토큰(A)·시스템 프롬프트(C)·컨테이너 환경 변수(D)는 비밀 분리 원칙에 어긋난다.

43. 정답 C. 호스팅된 MCP 서버는 보통 OAuth 베어러 토큰을 요구하며, 서비스의 네이티브 REST API 키(A)와는 다른 인증 체계다. SSH 키(B)나 평문 비밀번호(D)도 아니다. 이 구분이 시험의 함정이다.

44. 정답 D. 도구가 많지만 요청마다 소수만 관련될 때는 도구 검색(tool search)으로 관련 스키마만 동적으로 불러온다. 프롬프트 캐싱(A)·compaction(B)·배치 API(C)는 이 목적과 다르다.

45. 정답 A. 도구 검색은 스키마를 교체하지 않고 추가(append)하므로 기존 프리픽스가 보존되어 캐시가 유지된다. 매번 비움(B)·모델 교체(C)·system 수정(D)은 모두 캐시를 깬다.

46. 정답 C. 가능한 한 많은 도구를 넣는 것은 모범 사례가 아니다. 도구가 너무 많으면 모델이 혼란스러워하므로 집합을 좁혀야 한다. 서술적 이름(A)·속성 description(B)·enum 사용(D)은 올바른 모범 사례다.

47. 정답 B. 코드 실행은 Anthropic이 호스팅하는 격리 샌드박스에서 서버 측으로 실행되며, tools에 선언만 하면 된다. 클라이언트 직접 실행(A)·자유로운 인터넷 접근(C)·선언 불가(D)는 모두 틀리다.

48. 정답 D. 도구 실패는 is_error: true와 정보가 담긴 오류 메시지로 알려야 모델이 적응한다. content를 비움(A)·role 변경(B)·응답 무시(C)는 잘못된 처리다.

49. 정답 A. 환경 변수 자격 증명을 쓸 수 없는 self_hosted 상황에서는 커스텀 도구를 선언해, 오케스트레이터가 자신의 호스트 자격 증명으로 호출을 수행하고 결과만 돌려준다. 비밀을 시스템 프롬프트(B)·user 메시지(C)·컨테이너 파일(D)에 두면 이벤트 이력에 영속되어 위험하다.

50. 정답 C. 서버 측 도구는 Anthropic 인프라에서 실행되고, 클라이언트 측 도구는 여러분의 하니스가 실행한다. 항상 더 빠름(A)·클라이언트 측에 스키마 없음(B)·동일함(D)은 모두 틀리다.

51. 정답 B. limited 네트워킹에서 MCP 도구가 조용히 실패하면, allow_mcp_servers가 true가 아니거나 MCP 도메인이 allowed_hosts에 없는 경우가 가장 흔하다. 모델 ID(A)·max_tokens(C)·thinking(D)은 네트워킹 실패의 원인이 아니다.

도메인 5 해설 (52~60번)

52. 정답 B. 프롬프트 캐싱은 프리픽스 일치이며, 프리픽스 어디든 한 바이트만 바뀌어도 그 뒤가 모두 무효화된다. 이것이 모든 캐싱 설계가 따르는 단 하나의 불변식이다. 메시지 단위(A)·모델 무관(C)·출력 토큰만(D)은 모두 틀리다.

53. 정답 C. cache_read가 계속 0이면 시스템 프롬프트의 datetime.now()·UUID·정렬되지 않은 JSON 같은 조용한 무효화 요인이 작동하는 경우가 가장 흔하다. max_tokens(A)·thinking 꺼짐(B)·도구 없음(D)은 캐시 히트와 무관하다.

54. 정답 D. 렌더링 순서는 tools→system→messages이므로, 위치 0의 tools 정의를 바꾸거나 모델을 교체하면 전체 캐시가 무효화된다. user 마지막 블록(A)·tool_choice(B)·이미지 토글(C)은 더 낮은 계층만 무효화한다.

55. 정답 A. 컨텍스트 윈도를 넘어설 가능성이 있는 긴 대화는 compaction이 서버 측에서 이전 컨텍스트를 요약한다. 컨텍스트 편집(B)은 요약이 아니라 잘라내기이고, 캐싱(C)·토큰 카운팅(D)은 요약 기능이 아니다.

56. 정답 B. compaction은 response.content 전체(compaction 블록 포함)를 다음 요청에 붙여야 한다. 텍스트만 추출(A)하면 compaction 상태를 조용히 잃는다. 새 대화 시작(C)·max_tokens=0(D)은 잘못이다.

57. 정답 C. 오래된 도구 결과·완료된 사고 블록을 요약 없이 잘라내는 기능은 컨텍스트 편집(context editing)이다. compaction(A)은 요약하고, 캐싱(B)은 비용 절감, 메모리(D)는 교차 세션 지속이다.

58. 정답 D. 세션이 끝나도 상태가 유지되어야 하는 교차 세션 지속에는 메모리(memory)가 적합하다. 컨텍스트 편집(A)·compaction(B)은 세션 내에서 동작하고, tool_choice(C)는 무관하다.

59. 정답 A. Claude Fable 5의 안전 분류기 거절은 HTTP 200에 stop_reason: "refusal"로 반환되므로, content를 읽기 전에 stop_reason을 먼저 확인해야 인덱스 오류를 피한다. 400(B)·500(C)·빈 스트림 무시(D)는 거절의 형태가 아니다.

60. 정답 B. 큰 max_tokens(예: 64000)는 스트리밍을 사용하고 get_final_message로 최종 응답을 얻는 것이 권장된다. max_tokens=1(A)은 출력을 끊고, thinking 끄기(C)·두 번 전송(D)은 타임아웃 문제의 해법이 아니다.

정리

• 정답표로 채점한 뒤 도메인별 점수를 1회와 비교하라. 두 회차 모두 약한 도메인이 진짜 약점이며, 해당 PART로 돌아가 보강할 우선순위다.
• 시험의 단골 함정은 책임 분리(누가 실행·주도하는가), 캐시 무효화(프리픽스 불변식), 기능 구분(compaction·컨텍스트 편집·메모리)이다. 이 세 축에서 틀렸다면 개념을 다시 정리하라.
• 맞힌 문항이라도 오답 보기를 버린 이유를 해설과 맞춰 보라. 운으로 넘긴 개념은 시험에서 표면을 바꿔 다시 나온다.