퀴즈: 감사·타임아웃·스키마

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. `count_orders` 가 `{"status": 5}` 로 불렸다(스키마는 string). 이 글이 권하는 서버의 답은?

   1. 도구를 실행하고 0건이라고 답한다 — 숫자 상태는 없으니 결과가 0 이다
   2. `result.isError: true` 로 '상태는 문자열이어야 한다' 고 알린다
   3. 실행하지 않고 `-32602 Invalid params` 프로토콜 오류로 답한다
   4. 5 를 문자열 "5" 로 바꿔 실행한다

2. 파이썬에서 `integer` 타입 검사를 `isinstance(v, int)` 만으로 하면 놓치는 값은?

   1. `1.0` 같은 실수 — float 이 int 로 승격되어 통과한다
   2. `"1"` 같은 숫자 문자열 — 파싱 가능하면 int 로 취급된다
   3. `None` — 비어 있는 값은 어떤 타입 검사도 통과한다
   4. `True`·`False` — bool 이 int 의 하위 타입이라 통과한다

3. 서버가 도구 실행 시간에 스스로 상한을 거는 가장 직접적인 이유는?

   1. 멈춘 도구 하나가 단일 스레드 서버 전체를 잡아 둔다
   2. 클라이언트가 타임아웃을 거는 것이 스펙에서 금지돼 있다
   3. 감사 로그의 duration_ms 를 항상 정수로 만들기 위해서다
   4. SIGALRM 이 없으면 파이썬 프로세스가 종료되지 않는다

4. `notifications/message` 로 보내는 로그 알림에 대한 설명으로 맞는 것은?

   1. 응답과 같은 `id` 를 붙여 어느 호출의 로그인지 짝을 맞춘다
   2. `level` 은 RFC 5424 의 여덟 수준 중 하나이고, 알림이라 `id` 가 없다
   3. stderr 로그를 대체하므로 stderr 에는 아무것도 쓰면 안 된다
   4. 서버가 `logging` 능력을 선언하지 않아도 보낼 수 있다

5. 프로토콜 오류로 거절된 `tools/call`(예: 잘못된 인자)도 감사 로그에 남기라는 이유는?

   1. 감사 로그의 줄 수가 응답 수와 같아야 검사기가 통과하기 때문
   2. 잘못된 인자를 반복해 보내는 클라이언트 자체가 신호이기 때문
   3. 프로토콜 오류는 실행된 것으로 간주되어 과금 대상이기 때문
   4. JSON-RPC 스펙이 오류 응답의 기록을 요구하기 때문

6. 도구별 타임아웃 값을 정하는 순서로 이 글이 권하는 것은?

   1. 처음부터 도구마다 예상 시간을 추측해 다른 값을 넣는다
   2. 타임아웃을 두지 않고 감사 로그만 보다가 문제가 생기면 넣는다
   3. 하나의 값으로 시작하고, 감사 로그의 duration_ms 분포를 보고 도구별로 나눈다
   4. 클라이언트의 타임아웃 값을 조회해 그것과 같게 맞춘다