이 섹션이 다루는 내용

시험은 MCP / 오케스트레이션 메커니즘뿐만 아니라 대화형 UX 판단력 — 모호함 처리, 에스컬레이션 보정, 고객 상호작용 트레이드오프 — 에 크게 의존합니다. 가장 어려운 문제 다수는 best vs second-best로, 여러 옵션이 기술적으로 변호 가능하고, 정답은 Anthropic의 선호 철학에 부합하는 것입니다. 이 섹션은 실제 응시자가 표면화한 반복 패턴을 체계화합니다.

Best-vs-second-best 사고 모형

몇몇 distractor는 운영상 합리적입니다. '이것이 작동하는가?'를 묻지 말고 — '이것이 Anthropic의 선호 트레이드오프에 부합하는가?'를 물으십시오. 반복되는 선호 벡터:

휴리스틱 추측보다 최소한의 안전한 행동.
암묵적 공유 메모리보다 명시적 상태 & 컨텍스트.
불변량(invariant)에는 결정론적 보장; 프롬프트는 선호 사항에만.
오케스트레이션이나 인프라를 추가하기 전에 실제 실패 모드에 대한 간단하고 직접적인 수정.
사용자 의도 보존 — 초안을 덮어쓰지 말고, 파괴적으로 중단하지 마십시오.
코디네이터 중재 handoff; 서브에이전트는 결코 암묵적으로 메모리를 공유하지 않습니다.

다중 매칭 → 추측하지 말고 명료화하기

조회 결과가 둘 이상의 후보(여러 고객, 직원, 주문, 제품)를 반환할 때, 기대되는 동작은 구분되는 식별자를 요청하는 것입니다. 시험은 휴리스틱 선택을 강하게 싫어합니다.

시나리오	선호되는 동작
디렉터리 조회가 'Sarah Chen'이라는 이름의 직원 3명을 반환	질문: 부서, 사무실, 또는 이메일
주문 조회가 동일 이메일로 최근 주문 2건을 반환	질문: 주문 ID 또는 주문 날짜
이름으로 고객 조회가 여러 계정을 반환	질문: 계정 이메일, 전화번호, 또는 고객 ID
'가장 가능성이 높은' / '가장 최근' / '첫 매칭'을 조용히 선택	안티 패턴. 모호한 신원 문제에서 신뢰도 기반 추측

최소 안전 명료화 — 거대한 인테이크 폼이 아닙니다

선호되는 명료화는 10개 필드의 사전 폼이 아니라 한두 개의 정보량 높은 질문입니다. 날짜와 인원 수가 누락된 예약 컨시어지는 완전한 여행 선호도 설문지가 아니라 먼저 날짜+인원 수를 요청해야 합니다. 잘못된 끝은 대칭적입니다: 조용히 추측하지도 말고, 사용자를 마찰로 대화에서 밀어내지도 마십시오.

안전하게 진행할 수 있게 하는 최소한의 정보를 요청하십시오.
첫 질문이 다음 질문을 필터링하도록 순서를 정하십시오.
사용자가 필요한 것의 일부를 제공하면, 그것으로 작업하십시오 — 전체 폼으로 재시작하지 마십시오.

에스컬레이션 뉘앙스

공식 가이드는 명확합니다: 명시적 사람 또는 매니저 요청 → 즉시 에스컬레이션. 하지만 시험에는 일부 모의 시험이 강화한 더 부드러운 패턴이 포함되어 있습니다:

신호	기대되는 동작
'사람과 이야기할 수 있나요?' / '매니저를 불러주세요'	즉시 에스컬레이션. 조사 없음, 명료화 폼 없음.
명시적 사람 요청 없이 좌절 / 위협 언어	가벼운 명료화 한 번, 해결되지 않으면 에스컬레이션.
에이전트가 안전하게 처리할 수 없는 복잡/엣지 케이스 요청	무엇이 필요한지에 대한 가벼운 명료화, 그 다음 구조화된 패키지로 에스컬레이션.

시험이 처벌할 잘못된 행동: handoff 전에 4번의 조사용 도구 호출 실행, 전송 전 전체 인테이크 폼 요구, 이미 실패한 도구를 한 번 더 재시도.

구조화된 handoff — 절대 맹목 전송 금지

에스컬레이션할 때 사람 운영자는 일반적으로 전체 대화 트랜스크립트를 가지지 않습니다. 에이전트는 구조화된 자기 완결적 패키지를 전달해야 합니다.

고객 ID + 고객 이름
이슈 요약(한 문장)
주문 ID / 관련 엔티티 ID
근본 원인(최선의 추론)
이미 취한 행동들(도구 호출, 시도한 환불, 조회)
관련 시 금융 세부사항(환불 금액, 분쟁 총액)
권장 행동
에스컬레이션 사유

안티 패턴: 대화 로그를 통째로 사람 에이전트에게 던지는 것을 handoff로 삼는 것.

비동기 / 실시간 UX — 결코 파괴적이지 않게

상태 업데이트, 도구 결과, 또는 백그라운드 이벤트가 대화 도중에 도착할 때, 선호되는 동작은 비파괴적인 것입니다:

사용자 입력 보존. 사용자가 입력 중이면, 초안을 덮어쓰거나 지우지 마십시오.
준비하되, 밀어붙이지 마십시오. 현재 응답을 중단하는 것이 아니라 다음 적절한 응답에서 업데이트를 표면화하십시오.
idempotent 상태 업데이트 — 동일한 비동기 이벤트가 두 번 도착해도 중복 적용되어서는 안 됩니다.
표면 어포던스, 모달이 아닙니다. 작은 배지나 인라인 알림이 차단 다이얼로그를 이깁니다.

결정론적 강제 vs 프롬프트 지시

시험은 이 구분을 반복적으로 강화합니다. 프롬프트는 선호 사항을 위한 것이고, 결정론적 메커니즘은 불변량(invariant)을 위한 것입니다.

도메인	프롬프트로 처리할 것	결정론적으로 처리할 것
금융	환불 메시지의 톤	환불 임계값, 승인 게이트, idempotency 키
컴플라이언스	공시 카피의 스타일	필수 필드 스키마, 차단 목록 강제
보안	거절을 어떻게 표현할지	allow/deny 목록, 샌드박스 경계, 스코프 토큰
도구 순서	지시문에 제안된 순서	hook으로 강제된 사전조건, 스키마에 필수 필드
출력 구조	불릿 vs 산문 선호	JSON 스키마 검증, 파서가 거부한 출력

옵션이 강한 불변량을 프롬프트 지시에 넣으면 거의 확실히 틀린 답입니다 — 대신 hook, validator, 또는 스키마를 선택하십시오.

간단한 직접 수정 > 광범위한 아키텍처 변경

시험은 종종 실제 실패 모드를 겨냥한 가장 단순한 올바른 수정을 보상합니다. 한 줄 변경으로 근본 원인을 다룰 수 있을 때 오케스트레이터, evaluator, 또는 멀티 에이전트 흐름을 도입하는 과잉 엔지니어링 옵션을 경계하십시오.

실패 모드	선호되는 수정
도구 선택이 일관되지 않음 — description이 모호	도구 description 개선. 더 스마트한 오케스트레이터를 추가하는 것이 아닙니다.
컨텍스트 부풀음 — 도구가 40개 컬럼을 반환, 에이전트는 5개 사용	PostToolUse trim. 결과가 컨텍스트에 들어가기 전에 5개 필드로 줄이십시오.
장황한 워크플로가 메인 컨텍스트를 오염	`context: fork` — 시끄러운 스킬 / 서브에이전트를 격리.
도구 계약 모호성 → 잘못된 파라미터 형태	더 빡빡한 도구 스키마, retry 로직이나 모델 업그레이드가 아닙니다.
모델 업그레이드 이후 프롬프트 drift	모델을 핀(pin)하고 프롬프트를 재평가 — 'Opus로 전환'이 아닙니다.

코디네이터 중재 handoff — 암묵적 공유 메모리 없음

서브에이전트는 마법처럼 상태를 공유하지 않습니다. 코디네이터는 각 서브에이전트가 필요로 하는 입력을 명시적으로 전달하고 구조화된 결과를 다시 받아야 합니다.

잘못됨: '서브에이전트 B가 서브에이전트 A의 스크래치패드를 읽어서 고객 ID를 가져옴.'
잘못됨: '에이전트들이 누락된 데이터를 발견하기 위해 협력함.'
올바름: 코디네이터가 A의 구조화된 출력에서 고객 ID를 추출하고, B의 프롬프트에 주입.
크래시 복구: 각 서브에이전트가 알려진 manifest로 상태를 export; 코디네이터가 resume 시 재로드 + 재주입.

컨텍스트를 공격적으로 trim하고, 시끄러운 작업은 fork

동일한 근본 통찰, 두 가지 메커니즘. 둘 다 출제되었습니다.

패턴	사용 시점
PostToolUse trim hook	장황한 도구 결과 하나를 컨텍스트에 도달하기 전에 필터링하고 싶을 때
스킬 / 서브에이전트에 `context: fork`	그렇지 않으면 수십 개의 중간 메시지를 부모에 덤프할 전체 워크플로(lint 패스, 로그 스캔, 다단계 스킬)
리턴 시 구조화된 요약	서브에이전트가 의사결정에 관련된 주장만을 코디네이터로 다시 표면화
사이드 채널의 스크래치패드	LLM 컨텍스트 윈도우에 들어가지 말아야 할 작업 메모 — 파일이나 외부 상태 저장소를 사용

모호한 UX 문제를 위한 빠른 체크리스트

최적화 대상을 식별하십시오. 시나리오가 안전(환불, 보안), 전환(예약, 지원), 또는 처리량(batch 처리) 중 무엇을 최적화하고 있는가? 올바른 트레이드오프는 그에 따릅니다.
위험 등급. 고위험(금융, 되돌릴 수 없음) → 결정론적 + 명시적 명료화. 저위험(추천, 요약) → 최소 마찰 허용 가능.
추측 옵션 제거. 신원 해결 문제에서 '가장 가능성이 높은 것 선택' / '첫 번째 선택' / '컨텍스트에서 추론'이라고 말하는 모든 것은 잘못입니다.
과잉 엔지니어링 옵션 제거. 한 줄 도구 description 수정으로 해결될 일이라면, 멀티 에이전트 오케스트레이터 답은 잘못입니다.
프롬프트-as-invariant 옵션 제거. 강한 비즈니스 규칙을 시스템 프롬프트에 두는 답은 hook/validator 대안에 패배합니다.
두 옵션이 남으면, 더 명시적인 것(상태, 컨텍스트, 스키마, 식별자)이 보통 이깁니다.