퀴즈: 위험한 도구

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

1. `run_sql` 도구를 지키려고 SQL 문자열이 `SELECT` 로 시작하는지 검사했다. 이 글이 연결 자체를 읽기 전용으로 여는 쪽을 택한 이유는?

   1. 문자열 검사는 파이썬에서 느려 초당 처리량이 크게 줄기 때문
   2. 문자열 검사는 따라가야 할 변형(문장 이어 붙이기·주석·WITH 로 시작하는 문장)이 끝없이 늘고, 놓친 하나가 사고이기 때문
   3. SELECT 로 시작하는 문장은 SQLite 가 실행을 거부하기 때문
   4. 읽기 전용 연결은 쓰기 문장을 조용히 무시해 오류 처리가 필요 없기 때문

2. 허용 목록에 없는 도구를 `tools/call` 로 부르면 서버는 어떻게 답해야 하는가?

   1. 실행하되 감사 로그에 경고를 남긴다
   2. `result.isError: true` 로 '허용되지 않은 도구' 를 알린다
   3. 목록 밖 이름은 존재하지 않는 도구이므로 `-32602` 프로토콜 오류로 답한다
   4. `tools/list` 를 다시 보내라는 `list_changed` 알림으로 답한다

3. 허용 목록 파일이 없거나 JSON 이 깨져 있을 때 안전한 기본 동작은?

   1. 아무 도구도 켜지 않는다
   2. 읽기 도구만 자동으로 켠다
   3. 정의된 도구를 전부 켜고 경고를 stderr 에 남긴다
   4. 서버 시작을 거부하고 종료 코드 1 로 끝낸다

4. `delete_order` 가 `confirm` 없이 불렸을 때 이 코스가 권하는 응답은?

   1. `-32602` 로 거절해 모델이 인자를 고치게 한다
   2. 지우지 않고, 지웠다면 무엇이 사라졌을지 담은 `isError: true` 텍스트를 돌려준다
   3. 조용히 지우고 감사 로그에 confirm 누락을 남긴다
   4. `confirm` 이 없어도 `id` 가 맞으면 지운다 — 스키마의 required 가 아니므로

5. 도구 정의의 `annotations`(예: `destructiveHint`)에 대해 스펙이 클라이언트에 요구하는 태도는?

   1. 신뢰할 수 있는 서버가 아니면 믿지 않는다(MUST) — 표시용 힌트이지 안전장치가 아니다
   2. 힌트가 있는 도구는 확인 없이 실행해도 된다
   3. `destructiveHint: false` 인 도구는 감사 로그에서 제외한다
   4. 서버가 보낸 힌트를 그대로 사용자에게 강제 규칙으로 적용한다

6. 확인 단계를 넣자 '에이전트가 매번 물어봐서 느리다' 는 불만이 나왔다. 이 글이 권하는 방향은?

   1. 확인을 빼고 대신 감사 로그를 더 자세히 남긴다
   2. 확인 창을 세션당 한 번만 띄우고 이후에는 자동 승인한다
   3. 도구를 더 좁혀(예: 테스트 주문의 상태 변경만) 확인이 필요 없을 만큼 안전하게 만든다
   4. 모델에게 '위험한 작업은 하지 말라' 는 시스템 프롬프트를 추가한다