정답과 해설

60문항을 모두 푼 뒤 채점하세요. 먼저 정답표로 빠르게 점수를 확인하고, 틀린 문항과 찍어서 맞힌 문항을 해설로 복습합니다. 각 해설은 정답 근거뿐 아니라 다른 보기가 왜 함정인지까지 설명하므로, 같은 함정 패턴을 다음 회차에서 다시 만났을 때 즉시 소거할 수 있게 됩니다.

정답표

문항별 해설

1. 정답 ④. 클라이언트 도구를 실제로 실행하고 결과를 모델에 돌려주는 주체는 애플리케이션(하니스)이다. 모델은 "무엇을 할지"만 결정하므로 ①은 틀리고, 클라이언트 도구는 Anthropic 서버가 실행하지 않으므로 ③도 틀리다. MCP는 도구 연결 방식의 하나일 뿐 모든 도구를 실행하는 주체가 아니므로 ②도 오답이다.

2. 정답 ③. 모델이 더 이상 도구가 필요 없어 자연스럽게 답을 마치면 end_turn이다. ①은 도구를 더 호출하려 할 때, ②는 토큰 한계에 걸렸을 때, ④는 서버 측 루프가 일시 정지했을 때의 값이라 모두 상황이 다르다.

3. 정답 ③. 반복 한계의 목적은 종료 조건에 도달하지 못하는 경우 무한 반복을 막는 안전장치다. 비용 계산(①), 도구 차단(②), 캐시 적중(④)은 반복 한계의 목적이 아니다.

4. 정답 ②. 도구 실행 결과는 tool_result 블록으로 만들어 다음 요청에 붙인다. ①은 모델이 도구를 요청할 때 쓰는 블록, ③은 사고 블록, ④는 시스템 지침이라 결과 전달용이 아니다.

5. 정답 ③. 서버 측 도구의 내부 샘플링 루프가 기본 반복 한계에 도달하면 pause_turn이 반환되며, 같은 메시지를 다시 보내면 서버가 이어서 처리한다. ①은 정상 종료, ②는 안전 거부, ④는 사용자 정의 종료 시퀀스라 모두 다른 상황이다.

6. 정답 ②. 작업이 독립적이고 병렬화 가능하며 격리가 필요하다는 제약이 오케스트레이터-워커 병렬 위임을 정확히 가리킨다. ①은 순차라 느리고 한 대화에 쌓이면 오염되며, ③은 한 컨텍스트에 모두 섞여 격리를 위반하고, ④는 독립 작업을 굳이 의존 체인으로 묶는 안티패턴이다.

7. 정답 ③. 서브에이전트는 격리된 컨텍스트에서 탐색의 잡음을 흡수해 메인 대화를 깨끗하게 유지한다. 이 격리가 병렬 속도 못지않게 자주 출제되는 가치다. 단가 인하(①), 도구 수 감소(②), 캐시 비활성화(④)는 서브에이전트의 본질적 이점이 아니다.

8. 정답 ④. 출력 의존이 명시된 작업은 병렬화할 수 없으므로 순차 워크플로우가 정답이다. ①은 의존을 무시한 병렬이라 함정이고, ③은 결정성이 필요한 파이프라인에서 순서를 모델 재량에 맡겨 재현성을 잃으며, ②는 의존 제약과 무관한 비용 곁가지다.

9. 정답 ④. 제목 한 줄 추출은 단순하고 사전에 완전히 명세할 수 있어 단일 호출로 충분하다. 가치가 높거나(①) 오류 복구가 불가능하거나(③) 모델이 능력이 없다는(②) 근거는 이 작업과 맞지 않는다.

10. 정답 ②. 워크플로우와 에이전트를 가르는 본질은 루프 제어 권한이 코드에 있느냐 모델에 있느냐다. 모델 크기(①), 도구 실행 위치(③), 스트리밍 여부(④)는 구분의 본질이 아니다.

11. 정답 ③. 다단계이고 사전 명세가 어렵지만 오류를 검증·롤백할 수 있다면 에이전트 티어가 적합하다. 단일 호출(①)은 다단계 미명세 작업에 부족하고, 배치(②)와 임베딩(④)은 이 판단 기준과 무관하다.

12. 정답 ①. 세션 중간에 메인 루프의 모델을 바꾸면 프롬프트 캐시가 무효화되므로, 서브태스크는 저렴한 모델의 서브에이전트로 분리하고 메인 루프는 한 모델로 유지한다. 서브에이전트도 도구를 쓸 수 있어 ②는 틀리고, 워커가 항상 서버 측이라는 ③도 사실이 아니며, 모델 단가와 격리는 무관하므로 ④도 오답이다.

13. 정답 ②. 장시간 단일 작업은 첫 턴에 전체 명세를 충분히 주고 높은 effort로 실행할 때 가장 잘 수행된다. 모호한 점진 지시(①)는 효율과 성능을 떨어뜨리고, 최저 effort(③)는 지능을 희생하며, 도구 비활성화(④)는 작업 수행 자체를 막는다.

14. 정답 ④. 독립·병렬 가능 여부 대 출력 의존 여부를 판별해야 병렬 위임과 순차 워크플로우 중 어느 구조가 정답인지가 갈린다. 모델 버전(①), 캐시 TTL(③), 도구 수(②)는 이 판별로 결정되지 않는다.

15. 정답 ①. 탐색과 요약을 서브에이전트에 위임하면 잡음은 격리된 컨텍스트가 흡수하고 메인은 정제된 요약만 받는다. 수동 삭제(②)는 비자동화라 확장성이 없고, 큰 컨텍스트 창(③)은 잡음을 그대로 두어 비용만 늘리며, 한 번에 작성(④)은 격리 없는 무대책이다.

16. 정답 ④. 코드가 짧아 보이게 하는 것은 전용 도구 승격의 정당한 기준이 아니다. 게이팅이 필요한 비가역 동작(①), staleness 검사(②), 커스텀 렌더링(③)은 모두 bash 대신 전용 도구로 승격하는 정당한 기준이다.

17. 정답 ①. CLAUDE.md는 프로젝트의 코드베이스 규칙과 작업 지침을 Claude에 전달하는 문서다. 모델 가중치 저장(②), API 키 보관(③), 빌드 산출물 캐시(④)는 CLAUDE.md의 역할이 아니다.

18. 정답 ②. Progressive Disclosure는 상위에 공통 핵심만 두고 세부 규칙은 별도 파일에 두어 경로로 참조하는 구조다. 한 파일에 몰아넣기(①)는 정반대이고, 코드 주석(③)이나 슬래시 커맨드(④)에만 규칙을 두는 것은 상시 지침 전달 방식이 아니다.

19. 정답 ④. 슬래시 커맨드는 반복되는 프롬프트·작업 흐름을 재사용 가능한 명령으로 캡슐화한다. 컨텍스트 창 확대(①), 비용 절반(③), 도구 자동 생성(②)은 슬래시 커맨드의 효과가 아니다.

20. 정답 ②. "매번 자동으로" 수행되는 동작은 Hooks로 이벤트에 바인딩해야 한다. 메모리 저장(①)이나 시스템 프롬프트 한 줄(③)은 모델이 따를 수도 안 따를 수도 있어 자동화를 보장하지 못하고, 슬래시 커맨드 한 번 실행(④)은 자동 반복이 아니다.

21. 정답 ②. CI/CD 비대화식 실행은 Workload Identity Federation 같은 비대화식 자격 증명을 써야 한다. 매 빌드 대화식 로그인(①)은 비대화 환경에 부적합하고, 키 하드코딩(③)은 보안 위반이며, 인증 없는 호출(④)은 불가능하다.

22. 정답 ④. 공통 권한은 프로젝트 설정에, 개인 권한은 로컬 설정에 분리하는 것이 올바른 관리다. 모두 개인 글로벌에 두기(①)는 팀 공유가 안 되고, CLAUDE.md 본문에 적기(③)나 매 세션 수동 허용(②)은 권한 관리 메커니즘이 아니다.

23. 정답 ②. CLAUDE.md는 항상 적용되는 상시 지침이고, 슬래시 커맨드는 사용자가 의도적으로 호출하는 작업 흐름이다. 둘이 동일하다(①)거나 가중치를 바꾼다(③)거나 한 번만 읽힌다(④)는 설명은 모두 틀리다.

24. 정답 ②. 비대해진 CLAUDE.md는 공통 핵심만 남기고 세부 규칙을 별도 문서로 분리해 경로로 참조하는 것이 권장된다. 컨텍스트 창 확대(①)는 근본 해결이 아니고, 삭제·포기(③)나 주석 흩기(④)는 잘못된 방향이다.

25. 정답 ①. 훅은 하니스가 실행을 보장하지만 프롬프트 지침은 모델이 따를 수도 안 따를 수도 있어, 반드시 일어나야 하는 자동화에는 훅이 적합하다. 토큰 미소비(②), 모델 지능 향상(③), 캐시 무효화(④)는 훅이 자동화에 적합한 근본 이유가 아니다.

26. 정답 ②. 에이전트/환경 정의는 YAML로 작성해 저장소에 커밋하고 CI에서 적용하는 것이 권장된다. 머릿속(①), 즉석 입력(③), 이미지 파일(④)은 버전 관리 방식이 아니다.

27. 정답 ②. 슬래시 커맨드는 인자를 받아 동작을 분기하도록 설계하면 재사용성이 높아진다. 수십 개 별개 명령(①)은 비효율이고, 인자를 받을 수 없다(③)는 전제가 틀리며, 인자를 시스템 프롬프트에 하드코딩(④)하면 분기 의미가 사라진다.

28. 정답 ②. 코드 스타일 세부는 린터·훅·슬래시 커맨드로 강제하는 것이 권장되며, CLAUDE.md 본문에 길게 나열하는 것은 피한다. 길게 나열(①), 모델 추측(③), API 키와 함께 저장(④)은 모두 부적절하다.

29. 정답 ②. 최신 모델은 지시를 더 충실히 따르므로 강한 명령형 표현은 도구를 과도하게 호출하게 만든다. 표현을 이해 못 해서(①)가 아니라 너무 잘 따라서 생기는 문제다. 토큰 소비(③)나 캐시(④)는 이유가 아니다.

30. 정답 ④. JSON 스키마 강제는 output_config.format에 json_schema를 지정하거나 SDK의 parse 헬퍼를 쓰는 것이 권장된다. 막연한 지시(①)는 보장이 약하고, prefill(③)은 최신 모델에서 거부되며, 사후 정규식 파싱(②)은 유효성을 보장하지 못한다.

31. 정답 ②. 최신 모델에서 마지막 어시스턴트 prefill은 400을 내므로 구조화 출력이나 시스템 프롬프트 지침으로 대체한다. prefill을 더 길게(①) 해도 거부는 그대로이고, temperature 설정(③)은 무관하며, 구형 모델 회귀(④)는 권장되지 않는다.

32. 정답 ②. Few-shot 예시는 원하는 출력 형식·패턴을 시연해 형식 오류와 모호함을 줄인다. 컨텍스트 창 확대(①), 비용 절반(③), 도구 자동 생성(④)은 few-shot의 효과가 아니다.

33. 정답 ①. 구조화 출력 스키마에서 모든 객체에는 additionalProperties: false가 요구된다. minLength 같은 문자열 제약(②)과 재귀 스키마(③)는 지원되지 않으며, 모든 필드를 optional로 두는 것(④)은 요구 사항이 아니다.

34. 정답 ①. 도구 파라미터의 유효성을 보장하려면 도구 정의에 strict: true를 설정한다. 설명을 길게(②) 한다고 스키마가 강제되지 않고, tool_choice none(③)은 도구를 못 쓰게 하며, 도구 제거(④)는 목적과 반대다.

35. 정답 ①. 프롬프트 변경은 출력 동작을 바꾸므로 이력 추적과 롤백을 위해 버전 관리가 필요하다. 프롬프트는 모델 가중치를 바꾸지 않으므로 ②는 틀리고, 토큰 절약(③)이나 캐시 자동 생성(④)은 버전 관리의 이유가 아니다.

36. 정답 ②. 군더더기 서두는 시스템 프롬프트에 "서두 없이 바로 답하라"는 지침으로 제거하는 것이 권장된다. prefill(①)은 최신 모델에서 거부되고, max_tokens 0(③)은 출력을 막으며, 정규식 절단(④)은 근본 해결이 아니다.

37. 정답 ③. 특정 도구를 반드시 쓰게 강제하는 값은 {"type": "tool", "name": "..."}이다. auto(①)는 모델 재량, any(②)는 적어도 하나 사용, none(④)은 도구 사용 금지라 모두 다르다.

38. 정답 ②. 정해진 라벨 집합으로 제약하려면 스키마의 enum이나 strict 도구를 쓰는 것이 가장 견고하다. 자유 텍스트+수검(①)은 보장이 약하고, 높은 temperature(③)는 다양성을 키워 역효과이며, prefill(④)은 최신 모델에서 거부된다.

39. 정답 ③. 구조화 출력 스키마는 숫자 범위 제약(minimum, maximum)을 지원하지 않는다. enum(①), anyOf(②), const(④)는 지원되는 키워드다.

40. 정답 ②. 지연보다 비용이 중요한 대량 비대화식 처리는 배치 처리(Batches API)로 50퍼센트 비용을 절감한다. 실시간 스트리밍(①)은 지연 최적화이고, 매 건 새 도구 정의(③)나 한 프롬프트 합치기(④)는 부적절하다.

41. 정답 ②. 좋은 도구 설명은 무엇을 하는지뿐 아니라 "언제 호출해야 하는지" 트리거 조건을 명시한다. 언제 쓰는지 생략(①), 빈 설명(③), 키 포함(④)은 모두 좋지 않다.

42. 정답 ④. 도구 실패는 tool_result에 is_error: true와 정보가 담긴 오류 메시지를 보내 모델이 적응하게 한다. 침묵(①)이나 예외로 중단(③)은 모델이 회복할 수 없게 하고, 시스템 프롬프트 재작성(②)은 대응이 아니다.

43. 정답 ②. 도구가 많고 요청마다 일부만 관련되면 툴 검색으로 관련 스키마만 동적으로 로드한다. 항상 유지(①)는 컨텍스트 부담이고, 매번 삭제·추가(③)는 캐시를 깨며, 문장으로 적기(④)는 도구 호출이 안 된다.

44. 정답 ②. MCP는 외부 서비스의 도구·리소스·프롬프트를 표준화된 방식으로 연결하는 프로토콜이다. 모델 가중치 배포(①), 토큰 단가(③), 캐시 관리(④)는 MCP의 목적이 아니다.

45. 정답 ①. 에이전트의 mcp_servers에는 서버의 타입·이름·URL만 선언하고 인증은 포함하지 않으며, 자격 증명은 vault에 둔다. 토큰을 본문에(②), 키를 시스템 프롬프트에(③), 스키마 전체 복사(④)는 모두 잘못된 방식이다.

46. 정답 ④. MCP 자격 증명은 vault에 저장하고 세션에 vault_ids로 연결하는 것이 권장된다. 정의에 박기(①), 사용자 메시지에 적기(③), 도구 결과에 포함(②)은 자격 증명을 위험하게 노출한다.

47. 정답 ②. 비가역 동작을 전용 도구로 만들면 하니스가 타입 있는 인자를 받아 게이팅·감사·렌더링할 수 있다. 코드 길이(①), 토큰(③), 캐시(④)는 핵심 이점이 아니다.

48. 정답 ①. 클라이언트 측 도구는 하니스가 실행하고 서버 측 도구는 Anthropic 인프라에서 실행된다. 둘 다 모델이 직접 실행한다(②)는 틀리고, 서버 측 도구가 인증이 필요 없다(③)거나 클라이언트 도구가 스키마가 없다(④)는 것도 사실이 아니다.

49. 정답 ②. limited 네트워킹에서 MCP가 조용히 실패하면 보통 allow_mcp_servers를 켜지 않았거나 서버 도메인을 allowed_hosts에 넣지 않은 것이 원인이다. 모델 버전(①), 도구 설명 길이(③), temperature(④)는 네트워킹 도달성과 무관하다.

50. 정답 ②. MCP 도구 출력이 매우 클 때(100K 토큰 초과) 기본적으로 파일로 오프로드되고 모델은 잘린 미리보기와 파일 경로를 받아 필요하면 읽는다. 전부 주입(①)은 컨텍스트를 폭주시키고, 실패 처리(③)나 세션 종료(④)는 기본 동작이 아니다.

51. 정답 ①. 도구가 많으면 모델이 혼란을 일으켜 잘못된 도구를 고를 수 있으므로 도구 집합을 적게·집중해서 유지한다. 가중치(②), 인증 불가(③), 스트리밍 불가(④)는 도구 수와 무관하다.

52. 정답 ①. 시스템 프롬프트 맨 앞에 datetime.now()를 끼우면 접두사가 매 요청마다 달라져 캐시가 조용히 무효화된다. 안정 프롬프트 고정(②), 결정적 정렬(③), 휘발성 내용을 뒤로 보내기(④)는 모두 캐시를 살리는 올바른 패턴이다.

53. 정답 ④. compaction을 쓸 때는 response.content 전체(compaction 블록 포함)를 다음 요청에 붙여야 한다. 텍스트만 추출하면(①) compaction 상태가 사라지고, 기록 삭제(③)나 모델 교체(②)는 잘못된 동작이다.

54. 정답 ②. 멀티 턴 운영자 지침은 messages 배열에 role: "system" 메시지를 덧붙이면 캐시된 접두사를 깨지 않고 인젝션에 안전하다. 최상위 system 수정(①)은 캐시를 무효화하고, 사용자 메시지 평문(③)은 위조 가능하며, 도구 추가·삭제(④)는 더 큰 무효화를 부른다.

55. 정답 ②. 동일 접두사 반복인데 cache_read_input_tokens가 0이면 접두사를 매번 바꾸는 조용한 무효화 요인이 있는 것이다. 정상(①)이 아니며, 거부(③)나 단가 0(④)과도 무관하다.

56. 정답 ②. 처리할 수 없거나 자신감이 낮을 때 신뢰성 있는 시스템은 적절히 에스컬레이션하거나 한계를 명시한다. 추측 진행(①), 무한 재시도(③), 무작위 도구 호출(④)은 신뢰성을 해친다.

57. 정답 ④. 낡은 도구 결과를 요약 없이 잘라내는 기법은 context editing이다. compaction(①)은 요약으로 대체하는 다른 기법이고, 프롬프트 캐싱(③)이나 tool_choice(②)는 컨텍스트 정리 기법이 아니다.

58. 정답 ①. compaction은 요약으로 대체하고 context editing은 낡은 항목을 잘라내(제거) 차이가 있다. 둘이 같다(②)거나 context editing이 세션 간 영속화(③)라거나 compaction이 도구를 추가한다(④)는 설명은 모두 틀리다.

59. 정답 ②. 사용자 ID를 시스템 프롬프트에 f-string으로 끼우면 사용자별 접두사가 되어 사용자 간 캐시 공유가 불가능해진다. 영향 없다(①)는 틀리고, 모델 지능(③)이나 토큰 절반(④)과는 무관하다.

60. 정답 ②. 되돌리기 어려운 동작(삭제, 외부 전송)은 사용자 확인(휴먼 인 더 루프)으로 게이팅하는 것이 권장된다. 자동 실행(①)은 위험하고, 모두 bash로 처리(③)하면 동작별 게이팅이 어려워지며, 로그 미기록(④)은 감사를 포기하는 것이다.

정리

• 정답표로 빠르게 채점한 뒤, 도메인별로 몇 개를 틀렸는지 집계해 약한 도메인을 진단하세요.
• 시나리오형 문항(6·8·15 등)은 직전 문항의 정답 패턴을 반사적으로 적용하지 않는지 점검하는 장치이므로, 줄기의 제약을 매번 새로 읽는 습관이 중요합니다.
• 반복 등장하는 함정은 "더 큰 모델·더 큰 창으로 구조 문제 덮기", "사람 수동 개입 비자동화", "독립 작업을 의존 체인으로 묶기", "최신 모델에서 prefill 사용"입니다.
• 틀린 문항은 해당 도메인 PART로 돌아가 보강하고, 찍어서 맞힌 문항도 함께 복습해 다음 회차에서 같은 개념에 다시 흔들리지 않게 하세요.