부록 B. 셀프 체크 정답과 해설

1장

1-1. 다음 행동을 코드가 미리 정한 경로로 정하면 워크플로, 모델이 실행 중에 스스로 정하면 에이전트입니다. 예를 들어 문의 분류와 권한 검사는 코드가 하고, 분류된 문의 가운데 원인 조사가 필요한 것만 모델이 도구를 골라 가며 처리하는 상담 시스템은 두 방식이 섞인 구조입니다. 설계 문서에는 단계마다 "누가 다음 행동을 정하는가"를 적습니다.

1-2. 구간 나누기는 독립 하위 작업을 동시에 돌려 속도와 호출별 집중도를 얻고, 투표는 같은 작업을 여러 번 돌려 여러 관점과 시도로 더 믿을 만한 결과를 얻습니다. 투표는 호출 수만큼 비용이 늘고, 같은 근거를 쓰면 오류가 상관되어 기대만큼 정확해지지 않을 수 있습니다. 판단이 애매하고 한 번의 오류 비용이 큰 단계에만 씁니다.

1-3. 목표, 출력 형식, 쓸 도구와 출처에 대한 지침, 분명한 작업 경계입니다. 목표가 빠지면 엉뚱한 범위를 조사하고, 경계가 빠지면 여러 워커가 같은 곳을 중복 조사하고, 출력 형식이 빠지면 오케스트레이터가 결과를 합치기 어렵고, 출처 지침이 빠지면 품질이 낮은 출처를 쓰게 됩니다. 어느 것이든 하나의 증상을 들어 설명했으면 맞습니다.

1-4. 최대 반복 횟수와, 점수가 더 오르지 않거나 개선 폭이 하한 아래이면 멈추는 조건입니다. 두 조건은 모델이 아니라 루프를 돌리는 코드에 있어야 합니다. 수렴하지 않고 끝났을 때 마지막 결과와 평가 기록을 사람에게 넘기는 절차도 함께 두면 좋습니다.

1-5. handoff는 선택된 전문 에이전트에게 제어권을 넘기고, 그 에이전트가 그 턴의 남은 실행을 맡아 최종 답을 냅니다. agent-as-tool은 관리자 에이전트가 제어권을 유지한 채 전문 에이전트를 도구처럼 불러 결과만 받고, 최종 답은 관리자가 냅니다. 결과를 받아 이어 써야 하면 agent-as-tool, 전문가가 사용자를 직접 상대해야 하면 handoff입니다.

1-6. 다중 에이전트의 이득이 상당 부분 토큰을 더 쓴 결과라면, 총비용이 늘어난 만큼 성공도 늘었는지를 봐야 합니다. 그래서 비교 지표는 성공한 작업당 비용입니다. 비용이 두 배여도 성공률이 크게 오르면 정당화될 수 있고, 비용이 같아도 성공률이 그대로면 손해입니다.

1-7. 예시 답안입니다. 가장 단순한 구조는 공지마다 단일 LLM 호출로 요약하고 코드가 부서 태그로 묶어 보내는 고정 워크플로입니다. 부족해졌다는 신호는 부서 분류 오류율이 정해 둔 기준(예: 5%)을 넘거나, 여러 공지를 엮어 읽어야 하는 요약 요청이 의미 있게 늘어나는 것입니다. 그때는 부서 분류를 별도 라우팅 단계로 떼고, 엮어 읽는 요청만 도구를 쓰는 에이전트로 보냅니다. 신호를 숫자로 적었는지가 핵심입니다.

2장

2-1. 사람 개발자는 문서를 한 번 읽고 기억하지만, 에이전트는 (도구 검색 같은 지연 로딩을 쓰지 않는 한) 도구 정의와 결과를 매번 컨텍스트로 읽어야 하므로 도구가 많고 결과가 클수록 맥락 비용이 늡니다. 또 엔드포인트를 그대로 감싸면 비슷한 도구가 늘어 선택 오류가 생기고, 여러 호출을 조합하는 부담이 모델에게 갑니다. 그래서 작업 흐름 단위의 소수 도구가 낫습니다.

2-2. 늘 상세한 결과를 돌려주면 토큰이 낭비되고, 늘 간결하면 다음 호출에 필요한 식별자가 빠질 수 있습니다. 상세도 매개변수로 에이전트가 상황에 맞게 고르게 하면 두 문제를 함께 줄입니다. 다음 호출에 ID나 세부 필드가 필요할 때만 상세 응답을 고르게 합니다.

2-3. 결과가 잘렸다는 사실과 전체 규모(예: 1,240건 중 20건), 그리고 범위를 좁히는 방법(필터, 다음 페이지 커서)입니다. 이 정보가 없으면 에이전트는 받은 일부를 전부로 믿고 결론을 내리거나, 필요한 항목이 없다고 잘못 판단합니다.

2-4. 프로토콜 버전, 클라이언트 능력, 클라이언트 신원입니다. 이 정보는 매 요청의 _meta에 실립니다. 버전(io.modelcontextprotocol/protocolVersion)과 능력(io.modelcontextprotocol/clientCapabilities)은 필수이고, 클라이언트 정보는 권장되지만 자기 신고 값이라 보안 판단에 쓰지 않습니다.

2-5. 주석이 없으면 사양의 기본값에 따라 읽기 전용이 아니고(readOnlyHint 기본 false), 파괴적일 수 있으며(destructiveHint 기본 true), 멱등하지 않고(idempotentHint 기본 false), 외부 세계와 상호작용할 수 있다고(openWorldHint 기본 true) 다루게 됩니다. 기본값이 보수적이어서 주석이 없는 도구는 가장 조심해야 하는 쪽으로 분류됩니다. 주석이 있어도 신뢰할 수 없는 서버의 것이면 믿지 않습니다.

2-6. 감사 추적: 하위 시스템 로그에는 MCP 서버가 아니라 원래 토큰의 주인이 호출한 것처럼 남고, 서버도 어느 클라이언트가 호출했는지 구분하지 못해 사고 조사가 어려워집니다. 속도 제한: 서버나 하위 API가 토큰의 대상과 제약에 기대 거는 통제를, 토큰을 직접 쓰는 호출이 우회할 수 있습니다.

2-7. 예시 답안입니다. 이름은 loan_extend처럼 서비스 접두사와 동작을 담습니다. 매개변수는 loan_number(예: LN-2026-00123 형식 문자열)와 새 반납일 new_due_date(ISO 날짜, 현재 반납일로부터 14일 이내)로 받아, 같은 요청이 두 번 와도 결과가 같게 합니다. 업무 오류는 "예약 대기자가 있는 도서는 연장할 수 없습니다. 반납 예정일은 2026-10-27입니다"처럼 이유와 사실을 돌려줍니다. 사람 확인은 연장 횟수 상한을 넘기려 하거나 연체료가 생기는 경우에 겁니다. 각 항목이 오용을 어떻게 줄이는지 설명했으면 맞습니다.

3장

3-1. 모델은 컨텍스트의 모든 토큰 사이 관계에 주의를 나눠 써야 하므로, 토큰이 늘수록 각 정보에 쓸 수 있는 주의가 얇아집니다. 이것이 주의 예산이고, 그 결과 정보를 정확히 떠올리는 능력이 떨어지는 현상이 컨텍스트 rot입니다. 창이 크면 더 많이 넣을 수 있을 뿐, 넣은 것을 똑같이 잘 쓰지는 못하므로 관리가 계속 필요합니다.

3-2. 대화 깊숙이 남은 원문 도구 결과는 이미 쓰였고 다시 볼 일이 드물어, 지워도 흐름과 결정이 남기 때문입니다. 다만 지운 지점부터 프롬프트 캐시가 무효가 될 수 있으므로, 자주 조금씩 지우지 말고 한 번에 충분한 양을 지워 무효화의 대가를 감수할 만하게 만듭니다. 계속 다시 참조하는 결과는 지우지 않도록 제외합니다.

3-3. 작업 상태(진행 파일, 체크포인트)가 근거입니다. 대화 기록은 요약되고 잘려 정확하지 않고, 장기 기억은 참고 자료일 뿐입니다. 작업 상태와 업무 원장이 어긋나면 원장이 사실의 기준이므로, 원장에 맞춰 작업 상태를 고친 뒤 다음 할 일을 정합니다.

3-4. 뒤의 세션이 진행 상황을 보고 일이 끝났다고 서둘러 선언하거나, 기능 목록을 마음대로 고치고 시험을 지워 통과한 것처럼 만드는 실패입니다. JSON은 마크다운보다 모델이 부적절하게 고치거나 덮어쓸 가능성이 낮았고, 바꿀 수 있는 필드를 통과 여부 하나로 제한하면 범위를 줄이거나 기준을 낮출 수 없습니다.

3-5. 결과 기록 직전에 죽으면 기록만 보고는 실행했는지 알 수 없습니다. 의도를 먼저 적어 두면, 재개 코드가 "의도는 있는데 결과가 없는" 항목을 찾아 다시 실행하기 전에 멱등 키로 외부 시스템에 처리 여부를 조회할 수 있습니다. 처리되었으면 결과만 기록하고, 아니면 같은 키로 실행해 중복을 막습니다.

3-6. 첫째, 정보가 낡았는지 판단하고 만료·재확인을 할 수 있습니다. 둘째, 새 정보와 충돌할 때 어느 쪽이 더 믿을 만한지 출처의 권위와 최신성으로 가릴 수 있습니다. 출처가 있어야 잘못 저장된 기억을 추적해 정정하거나 삭제하기도 쉽습니다.

3-7. 예시 답안입니다. ① 목표와 완료 기준: 무엇을 언제까지 어떤 형식으로 내야 하는가. ② 완료 항목과 검증 결과: 무엇이 끝났고 어떻게 확인했는가. ③ 남은 일과 우선순위: 다음에 할 일의 순서. ④ 사실과 가정: 출처·확인 시각이 있는 사실과 아직 확인하지 못한 가정의 구분. ⑤ 다음 행동의 전제: 재개 전에 확인할 외부 변경, 필요한 승인, 산출물과 외부 작업 식별자의 위치. "거의 끝났다" 같은 자기평가 대신 검증된 산출물을 적었는지가 핵심입니다.

4장

4-1. 트랜스크립트는 시행 동안 에이전트가 한 말, 도구 호출, 중간 결과의 기록입니다. 결과는 시행이 끝난 뒤 환경의 상태, 즉 예약 시스템에 그 날짜의 예약이 실제로 하나 있는지입니다. 트랜스크립트는 무엇을 시도했는지 보여 주지만 그것이 환경에 남았는지는 증명하지 못합니다. "예약했습니다"가 있어도 결과에 예약이 없으면 실패이므로, 상태를 바꾸는 에이전트는 결과로 채점합니다.

4-2. 걸어야 하는 경우: '결제 전 반드시 사용자 확인'처럼 결과만 봐서는 지켰는지 알 수 없는 필수·금지 규칙이 있는 과제입니다. 걸지 말아야 하는 경우: 같은 답에 이르는 올바른 조회 순서가 여럿인 과제입니다. 이때 정확한 경로 일치를 요구하면 더 효율적인 올바른 해법까지 실패로 처리합니다.

4-3. pass@3 = 1 − (1 − 0.9)³ = 1 − 0.001 = 0.999, 약 99.9%입니다. pass^3 = 0.9³ = 0.729, 약 72.9%입니다. 세 번 중 한 번은 거의 반드시 성공하지만, 세 번 모두 성공할 확률은 73% 정도라는 뜻입니다. 재시도나 후보 선택이 가능하면 앞의 값이, 매번 한 번에 맞혀야 하면 뒤의 값이 운영 경험에 가깝습니다. 실제로는 같은 과제의 시행끼리 실패가 상관되는 경우가 많아 독립 가정 값과 다를 수 있습니다.

4-4. ① 평가 차원을 나누고 차원마다 관찰 가능한 기준과 감점 사례를 적으며, 근거가 없으면 판단 불가를 고를 수 있게 합니다. ② 전문가가 직접 채점한 표본을 만들어 채점기 판정과의 일치도를 잽니다. ③ 어긋난 사례를 읽고 기준표를 고친 뒤 다시 잽니다. 이후에도 표본을 정기적으로 뽑아 일치도가 유지되는지 확인합니다.

4-5. 트레이스는 워크플로 하나의 처음부터 끝까지이고, 스팬은 그것을 이루는 시작과 끝이 있는 작업 단위로 부모-자식 관계를 이룹니다. 에이전트 실행 하나에는 에이전트 실행 스팬, LLM 생성 스팬, 함수 도구 호출 스팬, 가드레일 스팬, handoff 스팬 등이 생깁니다(OpenAI Agents SDK의 기본 스팬 기준).

4-6. 실패는 대개 앞 단계의 잘못된 판단에서 시작해 뒤 단계에서 드러납니다. 드러난 증상만 고치면 원인이 남아 다른 모양으로 재발하고, 엉뚱한 요소를 바꿔 효과를 잘못 판단할 수 있습니다. 처음 잘못된 판단의 단계를 알아야 도구 정의, 프롬프트, 환경 중 무엇을 바꿀지 정할 수 있습니다.

4-7. 예시 답안입니다. 반드시 통과: 금지 행동 0건, 회귀 세트 통과율이 정해 둔 기준 이상. 비교 지표: 결과 기준 성공률과 pass^3이 기존 버전 이상, 업무 유형별로 퇴보한 유형이 없음. 운영 제약: 성공한 과제당 비용이 기존의 1.2배 이하, 첫 응답 지연이 계약 기준 안. 판단 유보: 두 버전의 차이가 반복 실행 변동 폭보다 작거나 표본이 기준보다 적으면 시행을 늘려 다시 잽니다. 반드시 통과 조건을 평균과 분리했는지가 핵심입니다.

5장

5-1. 첫째, 한 턴 안에서 비싼 도구를 여러 번 부르거나 큰 결과를 읽는 경우로, 실행당 토큰·비용 한도로 막습니다. 둘째, 같은 검색이나 조회를 반복하는 정체로, 같은 인자 반복 탐지와 진전 없음 탐지로 막습니다. 하위 에이전트가 계속 늘어나는 경우를 들고 하위 작업 수·재위임 깊이 상한을 답해도 맞습니다.

5-2. 계층마다 독립적으로 재시도하면 시도 횟수가 곱으로 불어나, 한 번의 실패가 수십 번의 호출이 되고 과부하를 키웁니다. 재시도는 한 계층에서만 하고, 일시적 오류에만, 지수 백오프와 지터로 간격을 두고, 횟수에 상한을 두며, 서버의 retry-after를 따릅니다. 다른 계층은 재시도 대신 회복 지시를 전달합니다.

5-3. 결제, 예약, 발송처럼 부작용이 있는 호출은 요청이 처리된 뒤 응답만 사라졌을 수 있습니다. 이때 실패로 보고 다시 보내면 같은 효과가 두 번 일어납니다. 먼저 멱등 키나 요청 식별자로 처리 여부를 조회하고, 처리되지 않았을 때만 같은 키로 다시 보냅니다.

5-4. 승인 요청이 너무 많으면 승인자가 읽지 않고 누르는 승인 피로가 생겨, 정작 위험한 요청도 형식적으로 통과합니다. 승인 대상은 되돌림 가능성(되돌리기 어려운가)과 영향 범위(고객·외부·금전에 미치는가)의 두 축으로 고르고, 되돌릴 수 있고 영향이 작은 행동은 한도 안에서 자동화합니다.

5-5. 종료 코드 2로 차단하는 PreToolUse 훅은 권한 규칙 평가 전에 호출을 멈추므로, allow 규칙이 있어도 호출이 막히고 훅의 표준 오류 내용이 차단 사유로 전달됩니다. 반대로 훅이 허용을 반환해도 deny나 ask 규칙을 건너뛰지 못합니다. 권한 규칙 자체는 deny → ask → allow 순으로 평가되고 처음 맞는 규칙이 결과를 정합니다. 단, 설치한 mod의 tool.check는 관리 설정이나 Team·Enterprise 로그인이 없는 환경에서 이 결정을 뒤집을 수 있습니다.

5-6. 샌드박스는 셸 명령과 그 하위 프로세스를 감쌉니다. 감싸지 않는 것은 Read·Edit·WebFetch 같은 내장 파일·웹 도구, 그리고 훅과 로컬 MCP 서버처럼 Claude Code가 띄우는 다른 프로세스입니다. 내장 도구는 권한 규칙으로 통제하고, 사용자의 전체 권한으로 도는 훅과 로컬 MCP 서버는 믿을 수 있는 것만 쓰고 필요하면 따로 격리합니다. 대부분의 세션에서 !로 직접 입력한 셸 명령, 제외 명령, 샌드박스 밖 재시도를 들어도 맞습니다.

5-7. 예시 답안입니다. 한도는 사용자별 하루 비용(예: 3,000원 상당 토큰)으로 정하고, 진행 중인 실행이 쓸 예상 비용은 시작 전에 예약합니다. 80%에 이르면 사용자에게 남은 한도를 알리고, 비싼 기능(긴 조사, 다중 에이전트)은 작은 모델이나 범위를 좁힌 경로로 바꿉니다. 100%에 이르면 새 실행을 시작하지 않고, 진행 중인 실행은 부분 결과를 저장하고 멈추며, 다음 날 초기화 시각과 한도 상향 요청 방법을 안내합니다. 두 지점에서 시스템이 하는 일이 코드로 강제되는지가 핵심입니다.