AI 도구 요청을 실행하는 법: 형식 오류와 중복 작업 복구

1. 1

   AI가 “처리했습니다”라고 쓰기 전에 일어나는 일

   독서 모임에서 책 두 권을 빌릴 수 있는지 확인하고 담당자가 검토할 메모를 만들고 싶습니다. AI에게 이 일을 부탁하면 그럴듯한 완료 문장을 받을 수도 있습니다. 그러나 실제 재고를 조회하지 않았고 초안도 저장하지 않았다면 그 문장은 결과의 증거가 아닙니다. 이번 수업은 AI가 다음에 할 도구 요청을 제안하고, 프로그램이 검사한 뒤 실행하며, 그 결과를 다시 AI에 전달하는 작은 흐름을 따라갑니다.

   이 수업에서 익힐 개발 AI 활용 순서는 다음과 같습니다. AI의 제안과 프로그램 실행 구분하기 → 도구 이름과 입력 형식 정하기 → 요청 검증 흐름 이해하기 → 오류를 설명해 수정 요청하기 → 응답 유실과 중복 처리의 복구 원리 확인하기. 각 단계에서 왜 그 자료와 조건이 필요한지 이론을 먼저 설명하고, 요청 예시·완성 예제·해설로 판단 과정을 살펴봅니다. 외부 AI 도구를 사용할 때의 방법을 읽으며 배우는 교재이므로 계정이나 실행 환경을 준비하지 않아도 됩니다.

   도구는 프로그램이 제공하는 정해진 작업입니다. lookup_stock은 책 번호를 받아 연습용 재고를 읽고 create_draft는 검토용 초안을 만듭니다. AI는 어떤 이름과 인수를 보낼지 제안하지만 도구를 실행할 권한과 코드는 애플리케이션에 있습니다. 도구 호출이라는 말은 이 연결 과정을 가리킵니다. AI가 써 준 JSON 한 줄만 보고 실제 업무가 끝났다고 판단하지 않는 것이 첫 번째 원리입니다.

   이 교재는 복잡한 API 환경을 준비하기 전에 연결 구조를 이해하는 연습입니다. Claude Sonnet 5.5와 실제로 대화해 받은 도구 요청 텍스트를 보존했고, 편집자가 작성한 Python 프로그램이 그것을 로컬에서 다시 실행합니다. 실제 API의 tool_use 블록을 캡처한 예제는 아닙니다. 텍스트 제안, 로컬 도구 실행, 결과 전달이 각각 어디에서 일어나는지 명확히 표시해 따라갈 수 있게 했습니다.

   자료 속 재고, 시간, 책 번호와 초안은 모두 가상입니다. 도구는 실제 도서관, 예약, 이메일, 외부 데이터베이스와 연결되지 않습니다. 프로그램을 끝내면 메모리의 초안도 사라집니다. 따라서 실제 예약을 만들지 않고도 형식 오류와 응답 유실, 중복 생성이라는 문제를 눈으로 확인할 수 있습니다. API 계정이나 결제 없이 읽거나 Python 표준 라이브러리로 실행하면 됩니다.

   목표 결과물은 R101이라는 요청 번호에 연결된 검토용 초안 한 개입니다. 중간에 실패가 있었더라도 새 요청을 무작정 만들어 같은 초안을 여러 번 남기면 안 됩니다. 사람이 AI에게 “다시 해 줘”라고 말할 때 프로그램이 무엇을 유지해야 하는지 이 사례로 배웁니다. 직접 실행하기 어렵다면 각 단계의 AI 요청, 실제 도구 결과, 남은 초안 수를 나란히 읽는 것만으로도 과정이 보입니다.

2. 2

   허용할 작업과 입력 형식을 AI에게 먼저 알려 주기

   처음 요청에는 이용자의 목표와 두 도구의 계약을 함께 넣습니다. 계약은 도구 이름, 필요한 입력, 돌아오는 결과, 같은 요청을 다시 보냈을 때의 동작을 적은 설명입니다. lookup_stock에는 book_id 하나만 필요합니다. create_draft에는 request_id, book_id, quantity, note가 모두 필요합니다. AI가 임의로 send_email 같은 도구를 만들거나 없는 입력 칸을 덧붙이지 않도록 허용 목록을 분명히 합니다.

   

   book_id는 책을 구분하는 표식입니다. 여기서는 B17과 B22만 있고 수량은 하나부터 셋 사이 정수로 제한합니다. request_id는 사용자의 같은 작업을 가리키는 번호이며 이번에는 R101로 고정합니다. 단순히 새 번호를 생성하는 기술이 아니라, “방금 실패한 것처럼 보여도 같은 일인가”를 확인할 연결 고리입니다. 같은 번호에 다른 수량이나 다른 메모를 보내면 충돌로 보류하도록 정했습니다.

   재고 결과는 아직 없으므로 첫 단계에서 초안을 만들면 안 됩니다. AI에게 여러 일을 한꺼번에 성공한 것처럼 요약해 달라고 하지 않고 지금 필요한 도구 하나만 고르게 합니다. 재고를 읽은 뒤 그 결과를 다음 요청에 붙이면 AI가 자료에 기반해 다음 작업을 제안할 수 있습니다. 도구 계약과 실제 결과를 구분하면 모델이 모르는 값을 빈칸으로 남겨야 하는 이유도 설명할 수 있습니다.

   프롬프트의 출력 형식은 JSON 한 객체로 정합니다. JSON은 이름이 붙은 값들을 정해진 문법으로 적는 형식입니다. 이 사례에는 name과 arguments라는 두 칸만 허용합니다. 읽기 쉬운 설명이나 코드 울타리가 덧붙어도 JSON만 기대하는 프로그램은 읽지 못할 수 있습니다. 첫 요청에 형식을 적는 것과 실제 응답을 프로그램으로 검사하는 일은 둘 다 필요합니다. 다음 절의 실제 실패가 그 차이를 보여 줍니다.

   직접 따라 할 때에는 새 대화를 열어 아래 요청을 그대로 보냅니다. AI 도구가 계정마다 다른 기능을 지원하더라도 이 단계는 일반 텍스트 대화로 진행할 수 있습니다. 실제 외부 도구와 연결하지 않은 상태라는 설명을 요청 안에도 넣습니다. 연습을 마친 뒤 실제 API로 옮긴다면 제공자의 도구 정의와 결과 전달 형식을 다시 확인해야 합니다. 이번 텍스트 실습이 그 공식 통신 형식을 그대로 구현했다고 소개하지 않습니다.

   AI 도구 활용을 배우는 개발자용 가상 교육 사례입니다. 아래 자료만 읽고 도구 요청 JSON을 제안하세요. 어떤 도구도 실제 실행하지 마세요. 이 응답은 실제 API tool_use 응답이 아니라 도구 요청을 설계하기 위한 텍스트입니다.
   가상 독서모임은 B17 도서 2권을 빌릴 수 있는지 먼저 조회하고, 가능하면 담당자가 검토할 요청 초안만 만들려고 합니다. 예약 확정이나 이메일 발송은 하지 않습니다.
   허용 도구 계약:
   lookup_stock({book_id:string}) -> {book_id,available,checked_at}; 읽기 전용. book_id는 B17 또는 B22.
   create_draft({request_id:string,book_id:string,quantity:integer,note:string}) -> {draft_id,status:'draft'}; 메모리상의 연습용 초안 작성. 수량1~3. 같은 request_id를 다시 주면 같은 내용의 기존 초안 반환; 내용이 다르면 conflict. 실제 저장소·예약·이메일과 연결되지 않음.
   현재 확보 정보: request_id=R101, book_id=B17,quantity=2. 재고 조회 결과는 아직 없음.
   출력 형식: JSON 객체 한 개. 키 name과arguments만. 지금 해야 할 첫 도구 한 개만 선택하세요. 근거 없는 재고값이나 draft_id를 쓰지 마세요.

1. 3

   실제 첫 응답의 형식 오류를 짧은 추가 요청으로 고치기

   Claude의 첫 응답은 lookup_stock을 골랐습니다. 필요한 작업의 선택은 맞았지만 JSON 앞뒤에 코드 울타리와 설명문이 붙었습니다. 사람이 보면 친절한 답이지만 프로그램의 json.loads에 응답 전체를 넣으면 오류가 납니다. 프로그램이 기대한 형식과 실제 받은 형식이 다르기 때문입니다. 이 사례의 첫 실패는 재고 판단이 아니라 응답을 읽는 단계의 실패입니다.

   이때 개발자가 문자열에서 중괄호 사이만 대충 잘라 실행하면 예제가 쉽게 끝나는 것처럼 보일 수 있습니다. 그러나 이번에는 무엇을 받아들일지 정한 계약대로 잘못된 형식을 보류합니다. 그 뒤 AI에게 “선택한 도구는 맞지만 설명이 붙어 JSONDecodeError가 난다”고 실제 이유를 전달했습니다. 수정 요청에서 JSON 객체 하나만, 코드 울타리와 설명 없이 출력하도록 범위를 좁혔습니다.

   두 번째 실제 응답은 name과 arguments만 있는 한 줄 JSON이었습니다. 이를 그대로 읽었을 때 lookup_stock과 B17이 나옵니다. 모호하게 “제대로 출력해”라고 한 것이 아니라 첫 응답에서 맞은 부분은 유지하고 틀린 형식만 지정했으므로, 업무 내용까지 불필요하게 바꾸지 않고 고칠 수 있습니다. 후속 요청은 모델의 모든 판단을 다시 시작시키기보다 필요한 변화 하나를 명확히 설명하는 데 씁니다.

   프로그램은 JSON 문법 외에도 이름과 입력을 검사합니다. JSON이 잘 읽혀도 name이 허용되지 않은 도구면 실행하지 않습니다. 수량에 문자열 “2”나 참/거짓을 보내는 경우도 정수 둘과 같은 값으로 취급하지 않습니다. 입력 검사는 모델이 보낸 문장을 애플리케이션의 실제 작업으로 바꾸기 직전에 둡니다. 프롬프트가 길고 명확하더라도 이 검사를 생략하지 않습니다.

   아래 인용에는 첫 응답의 코드 울타리와 설명이 그대로 들어 있습니다. 두 번째 응답과 비교하면 왜 읽기 오류가 났는지 확인할 수 있습니다. 독자는 AI에게 처음부터 완벽한 형식을 강요하는 요령을 외우기보다, 실제 응답의 어떤 부분이 계약을 어겼는지 찾아 추가 요청으로 고치는 방식을 배웁니다. 실제 API의 구조화 출력이나 엄격한 도구 스키마를 쓰더라도 업무 입력의 타당성은 별도로 확인해야 합니다.

   프로그램에서 당신의 첫 응답 전체를 json.loads로 읽으면 JSONDecodeError가 납니다. 코드 울타리와 뒤의 설명이 붙었기 때문입니다. lookup_stock 선택 자체는 맞습니다. JSON 한 객체만 출력하세요. 마크다운과 설명문 없이 첫 글자를 { 로 시작하고 마지막을 } 로 끝내 주세요. name과arguments 두키만, 현재 재고는 여전히 미확인입니다. 실제도구호출금지.

   실제 첫 응답 원문입니다. 코드 울타리와 뒤의 설명까지 포함돼 있어, 전체 문자열의 JSON 파싱은 실패합니다.

   실제 두 번째 응답은 다음과 같습니다.

   두 번째 실제 응답: {"name":"lookup_stock","arguments":{"book_id":"B17"}}

   응답 예제복사

   외부 AI 도구의 활용 과정을 설명하는 교재 예제입니다. 요청 조건에 따라 결과는 달라집니다.

   {
     "name": "lookup_stock",
     "arguments": {
       "book_id": "B17"
     }
   }
   

   재고 조회 결과가 아직 없으므로, 읽기 전용인 lookup_stock을 먼저 호출합니다. create_draft는 available이 수량 2권을 충족한다는 결과를 확인한 뒤에만 request_id: "R101", book_id: "B17", quantity: 2로 제안하는 것이 안전합니다.

2. 4

   조회 결과를 다시 주고 검토용 초안 요청받기

   형식 검사를 통과한 두 번째 응답을 로컬 lookup_stock에 전달했습니다. 편집자가 실행한 결과는 B17, available 2, 확인 시각 2026-10-28T10:00:00+09:00입니다. 이 시각은 연습 데이터에 고정한 값이며 현재 재고를 실시간으로 조회한 것이 아닙니다. 프로그램이 실제로 반환한 가상 결과와 외부 현실의 최신 정보를 구분해 기록합니다.

   이 결과를 같은 대화의 다음 메시지에 붙입니다. AI에게는 앞선 이용자 목표가 그대로인지, 지금 새로 알게 된 값이 무엇인지 함께 알려 줍니다. 이번에는 두 권을 확인했으므로 create_draft를 제안할 수 있습니다. 다만 초안의 note에는 재고 조회 시점 기준이고 예약은 미확정이라는 뜻을 남기도록 요청했습니다. 조회한 수량이 바로 실제 예약 성공을 뜻하지 않기 때문입니다.

   세 번째 실제 응답에는 request_id R101, book_id B17, quantity 2가 들어 있고 note에는 담당자 검토용 초안이라고 적혔습니다. 존재하지 않는 draft_id를 미리 만들지도 않았습니다. draft_id는 도구 실행 뒤 돌아올 결과이므로 AI가 제안 단계에서 성공 번호를 쓰면 안 됩니다. 입력과 출력의 자리를 구분하는 이런 작은 규칙이 실제 애플리케이션의 진행 상태를 정확히 표시하는 데 중요합니다.

   편집자 프로그램은 조회 이력이 없으면 초안 생성을 보류합니다. 조회한 가용 수량보다 많은 초안을 요청한 경우도 보류합니다. 이러한 조건은 AI 응답을 믿거나 불신하는 태도의 문제가 아니라 프로그램이 제공하는 작업 계약입니다. AI가 재고가 충분하다고 자연어로 설명했더라도 코드에 조회 결과가 없다면 이 사례에서는 실행하지 않습니다. 같은 자료로 누구나 확인할 수 있는 경계입니다.

   여기까지의 흐름을 다른 업무에도 대입할 수 있습니다. 재고 대신 행사 좌석을 읽고 안내문 초안을 만들거나, 제품 정보 문서를 읽고 제안서 초안을 만드는 경우입니다. 핵심은 실제로 받은 도구 결과를 다음 요청에 넣고, AI가 아직 수행하지 않은 일을 완료했다고 쓰지 않게 하는 것입니다. 이 교재에서는 초안 생성 후 응답이 유실되는 상황까지 만들어, 다음 단계의 재시도 요청이 왜 필요한지 확인합니다.

   수정한 순수 JSON은 프로그램의 형식 검사를 통과했습니다. 이제 편집자가 작성한 로컬 연습용 lookup_stock을 실행한 결과를 전달합니다. 실제 재고나 예약 시스템과는 연결되지 않습니다.
   {"book_id":"B17","available":2,"checked_at":"2026-10-28T10:00:00+09:00"}
   사용자 요청은 여전히 R101, B17, 2권의 검토용 초안입니다. 다음 도구 한 개만 JSON 객체로 출력하세요. note에는 '재고조회 시점 기준, 예약 미확정'의 뜻을 남겨주세요. 마크다운·설명문·완료 선언을 붙이지 마세요. 아직 초안을 실제로 만들었다고 말할 수 없습니다.

   실제 세 번째 AI 응답 원문입니다. 초안을 만드는 요청이며 아직 성공 응답이 아닙니다.

   응답 예제복사

   외부 AI 도구의 활용 과정을 설명하는 교재 예제입니다. 요청 조건에 따라 결과는 달라집니다.

   {"name":"create_draft","arguments":{"request_id":"R101","book_id":"B17","quantity":2,"note":"재고조회 시점(2026-10-28T10:00:00+09:00) 기준 2권 가용, 예약 미확정. 담당자 검토용 초안."}}

3. 5

   응답이 끊겼을 때 새 번호로 다시 만들지 않기

   이제 일부러 실패를 넣습니다. 프로그램은 세 번째 요청으로 초안을 메모리에 하나 만든 뒤 성공 응답을 보내기 직전에 TimeoutError를 냅니다. 시간 초과라는 메시지만 보면 아무 일도 일어나지 않은 것처럼 보이지만 편집자가 확인한 초안 수는 이미 하나입니다. 실제 시스템에서도 결과가 돌아오지 않았다는 사실과 작업이 수행되지 않았다는 사실은 구분해야 합니다. 이 사례는 그 차이를 작은 코드로 재현합니다.

   

   AI에게는 “성공 응답을 받지 못했다”는 관찰과 도구 계약을 전달합니다. 같은 request_id와 같은 인수로 재시도하면 기존 초안을 돌려주고 다른 인수면 충돌로 처리한다는 규칙입니다. 재시도 예산은 한 번만 남았다고 명시했습니다. 그러면 AI는 새 작업을 시작하는 것이 아니라 방금 요청한 같은 작업의 결과를 다시 받기 위한 JSON을 제안해야 합니다.

   네 번째 실제 응답은 세 번째와 request_id, 책 번호, 수량, note가 완전히 같습니다. 프로그램은 R101에 이미 있는 초안을 찾아 DRAFT-R101과 status draft를 반환합니다. 최종 초안 수는 하나이고 도구 실행 시도는 조회 한 번, 생성 한 번, 같은 생성 요청의 재시도 한 번으로 셋입니다. 첫 응답은 형식 단계에서 막혔으므로 도구 실행 시도에 들어가지 않습니다. 숫자가 무엇을 세는지까지 기록합니다.

   이런 재시도 성질을 멱등성이라고 부릅니다. 어려운 단어를 외우기보다 같은 작업 번호와 같은 내용으로 반복해도 결과가 하나로 유지되는 성질이라고 이해하면 됩니다. 프롬프트에 “중복하지 마”라고 쓰는 것만으로 생기지 않습니다. 프로그램이 번호와 저장된 인수를 대조하고 기존 결과를 돌려주는 동작을 실제로 구현해야 합니다. AI의 요청과 코드의 보장이 함께 있어야 합니다.

   같은 번호에 수량 셋을 보내거나 메모를 새로 고치면 이 예제에서는 충돌입니다. 새로운 목표가 생겼는지 사람이 확인한 뒤 별도의 변경 절차를 정해야 합니다. 또 이 메모리 실습은 프로세스가 종료되면 기록이 없어지므로 서버 재시작과 여러 서버 사이의 중복 방지까지 보장하지 않습니다. 실제 적용에는 지속 저장과 동시 실행의 처리도 필요합니다. 이 제한을 이해하고도, 실패 후 무엇을 AI에 다시 전달할지는 여기서 충분히 연습할 수 있습니다.

   로컬연습도구에서 앞서요청한 create_draft를 실행하다가 응답 대기시간 초과가 났습니다. 실제실행오류: simulated_reply_lost_after_create
   AI에게는 성공응답이 전달되지않았습니다. 이 도구는 같은 request_id와 같은 인수로 재시도하면 이미있던초안을반환하고 다른인수면 conflict를내는 계약입니다. 아직 재시도 예산1회가남았습니다. 앞선요청의 request_id/book_id/quantity/note를 한글자도 바꾸지않고 재시도할 JSON을 주세요. 새로운 request_id를만들지마세요. JSON객체만, 실행완료주장금지. 실제도구호출금지.

   실제 네 번째 응답입니다. 세 번째 응답과 인수를 비교해 보세요.

   편집자 재실행 결과: draft_id DRAFT-R101, status draft, 도구 시도 3회, 최종 초안 1개. 실제 예약이나 발송은 없습니다.

   응답 예제복사

   외부 AI 도구의 활용 과정을 설명하는 교재 예제입니다. 요청 조건에 따라 결과는 달라집니다.

   {"name":"create_draft","arguments":{"request_id":"R101","book_id":"B17","quantity":2,"note":"재고조회 시점(2026-10-28T10:00:00+09:00) 기준 2권 가용, 예약 미확정. 담당자 검토용 초안."}}

4. 6

   완성 프로그램으로 실패와 복구 과정을 확인하기

   완성 파일 tool-workflow-recovery.py에는 편집자가 쓴 요청 검사기, 가상 재고 도구, 초안 저장과 네 번의 실제 AI 제안이 들어 있습니다. 파일 머리말에는 텍스트 제안을 재생하는 오프라인 실습이라고 표시했습니다. 어떤 부분이 모델 응답이고 어떤 부분이 검증 코드인지 구분할 수 있도록 원문 대화도 별도 파일로 제공합니다. 이 구조를 유지하면 나중에 AI 응답이 달라져도 어느 경계에서 문제가 생겼는지 찾기 쉽습니다.

   

   Python 3에서 파일을 실행하면 turn 1은 invalid_json, turn 2는 재고 둘, turn 3은 응답 유실 오류, turn 4는 기존 초안의 결과가 나옵니다. 이어 tool_attempts는 3, draft_count는 1로 표시됩니다. 마지막 숫자만 보는 대신 네 단계의 이유를 말해 보세요. 잘못된 JSON은 실행 전에 막혔고 재고를 읽은 뒤 초안을 만들었으며 응답이 끊긴 뒤 같은 번호로 결과를 다시 받은 것입니다.

   추가 확인으로 허용하지 않은 도구를 보내 봅니다. 예를 들어 send_email이라는 이름은 JSON 문법에 맞아도 허용 목록에 없으므로 거부됩니다. 조회 없이 create_draft를 보내는 경우, 수량을 음수로 보내는 경우, 같은 R101에 다른 내용을 보내는 경우도 각각 다른 이유로 보류합니다. 각각의 조건은 다운로드 코드에 있으므로 AI가 지시를 얼마나 잘 따랐는지와 별개로 프로그램이 경계를 지키는지 확인할 수 있습니다.

   반복 실행의 상한도 있습니다. 이 연습은 도구 실행 시도 네 번까지만 허용합니다. 실패할 때마다 무한히 다시 요청하면 동일한 오류를 계속 만들거나 실제 서비스에서는 비용과 작업 수를 늘릴 수 있습니다. 한도를 넘으면 사람이 상태를 확인하도록 멈춥니다. 최종 상태가 draft인 것도 설명할 수 있어야 합니다. 초안과 승인, 검토와 발송은 프로그램의 다른 상태이며 여기에서는 초안까지만 구현했습니다.

   실제 API로 발전시킬 때는 공식 도구 호출 문서에서 모델이 반환하는 도구 ID, 입력 스키마, 결과 메시지의 연결 방식을 확인하세요. 이 교재의 name과 arguments는 구조를 쉽게 이해하기 위한 연습용 약속입니다. 실제 SDK의 필드 이름을 그대로 구현한 예제라고 옮기면 안 됩니다. 반면 허용 목록, 입력 검사, 실행 결과 전달, 같은 작업의 재시도라는 개념은 API 방식이 바뀌어도 검토할 수 있는 기본 연결입니다.

   완성 도구 활용 프로그램

   파일	내용
   tool-workflow-recovery.py	Python 3 · four recorded proposals · local replay

   완성 도구 활용 프로그램 내려받기

   편집자가 실제로 실행한 최종 흐름입니다.

   코드 예시복사

   turn 1: invalid_json turn 2: B17 available=2 turn 3: simulated_reply_lost_after_create turn 4: DRAFT-R101 status=draft tool_attempts: 3 draft_count: 1

정답을 맞혀야 다음 수업으로 가는 시험이 아닙니다. 해설을 읽고 이해하는 데 사용하세요.

1. Q1AI가 올바른 lookup_stock을 골랐지만 JSON 앞뒤에 설명을 붙였습니다. 첫 후속 요청에는 무엇을 유지하고 무엇을 바꾸라고 할까요?

   내 생각 적기 (선택)

   내 생각 적기 (선택)

   작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.

   답과 해설 보기

   도구 선택과 B17 입력은 유지하고 출력 형식만 JSON 한 객체로 고치라고 합니다. 실제 파싱 오류와 코드 울타리·설명문이 원인임을 알려 줍니다. 잘못된 응답은 실행 전에 막아 도구 실행 횟수에 포함하지 않습니다.

   해설을 읽고 이해했어요

   직접 비교한 표시이며 자동 채점은 아니에요.

2. Q2초안 생성 뒤 시간 초과가 났습니다. 새 request_id를 만들어 다시 보내면 왜 위험할까요?

   내 생각 적기 (선택)

   내 생각 적기 (선택)

   작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.

   답과 해설 보기

   첫 초안이 이미 만들어졌을 수 있으므로 새 번호는 별개의 초안을 만들 수 있습니다. 같은 번호와 완전히 같은 인수로 재시도하고 기존 결과를 돌려주는 도구 계약을 사용합니다. 프롬프트만으로 중복 방지가 생기는 것은 아닙니다.

   해설을 읽고 이해했어요

   직접 비교한 표시이며 자동 채점은 아니에요.

3. Q3새 가상 요청 R202는 B22 두 권을 원하고 조회 결과는 영 권입니다. AI가 수량을 영으로 바꾼 초안을 제안했습니다. 받아들일까요?

   내 생각 적기 (선택)

   내 생각 적기 (선택)

   작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.

   답과 해설 보기

   받아들이지 않습니다. 가상 연습 자료에서 이용자가 요청한 수량은 둘이고 허용 수량은 하나부터 셋입니다. 재고 부족을 설명하고 다음 확인을 요청해야 하며 입력을 몰래 바꿔 성공처럼 만들지 않습니다.

   해설을 읽고 이해했어요

   직접 비교한 표시이며 자동 채점은 아니에요.

4. Q4최종 초안은 하나이고 도구 시도는 셋인데 AI 응답은 네 번입니다. 숫자가 다른 이유는 무엇인가요?

   내 생각 적기 (선택)

   내 생각 적기 (선택)

   작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.

   답과 해설 보기

   첫 응답은 JSON 형식 검사에서 막혀 도구가 실행되지 않았습니다. 이후 조회, 생성, 같은 생성 요청의 재시도 세 번이 실행됐습니다. 같은 R101과 같은 인수의 재시도는 기존 초안을 반환해 결과가 하나로 유지됐습니다.

   해설을 읽고 이해했어요

   직접 비교한 표시이며 자동 채점은 아니에요.

1. 7

   직접 해 보기: 재고가 없는 새 요청을 AI에게 전달하기

   새 자료는 B22 도서 두 권을 원하는 요청 R202입니다. 가상 재고 도구에서 B22의 available은 영입니다. 먼저 이용자의 요청과 허용 도구는 유지하되 책 번호와 요청 번호만 새 자료에 맞춰 바꿔 AI에게 다음 도구 한 개를 요청합니다. 처음부터 “재고가 없으니 초안을 만들지 마”라는 정답을 주기보다, 조회 결과가 아직 없을 때 먼저 읽기 작업을 선택하는지 확인해 보세요.

   조회 결과를 받은 뒤에는 B22, available 0, 확인 시각을 같은 대화에 전달합니다. AI에게 지금 가능한 다음 행동과 사용자에게 설명할 문장을 요청합니다. 이 경우 create_draft는 가용 수량 조건을 만족하지 못하므로 만들 수 없습니다. 다른 책의 재고를 대신 가져오거나 quantity를 임의로 영으로 바꾸는 행동도 사용자가 원한 두 권의 요청을 해결한 것이 아닙니다. 부족한 사실을 그대로 남기는 것이 올바른 활용 결과입니다.

   모델이 그래도 초안 생성 JSON을 제안하면 실제 프로그램에서 insufficient_stock으로 보류되는지 확인할 수 있습니다. 이 실패를 다시 AI에게 전달하고 조건에 맞는 설명으로 수정하도록 요청합니다. “처리 불가”라는 한 단어로 끝내지 말고 어떤 값이 부족하고 무엇을 추가 확인할지 설명하는 답을 비교하세요. AI의 친절한 표현을 이용하면서도 프로그램이 지키는 조건을 바꾸지 않는 연습입니다.

   또 다른 상황으로 R101의 수량만 셋으로 바꾸고 같은 번호를 보내 보세요. 원래 초안과 인수가 달라 request_id_conflict가 나야 합니다. 이는 새 요청 번호를 아무 때나 만들라는 뜻이 아닙니다. 이용자가 이전 초안을 변경하려는 것인지 별개의 작업을 원하는 것인지 먼저 확인하고 상태 변경 절차를 정해야 합니다. 현재 교재의 도구에는 수정 기능이 없다는 한계도 AI에게 전달합니다.

   직접 실행 없이 공부한다면 세 가지를 설명해 보세요. 재고가 없을 때 무엇을 만들지 않아야 하는지, 성공 응답을 잃었을 때 무엇을 그대로 다시 보내야 하는지, 실제 프로그램이 실패를 어디에서 막는지입니다. 실제로 실행했다면 요청과 응답, 도구 결과, 최종 초안 수를 함께 남깁니다. 네 가지 기록이 이어져 있으면 AI가 제안한 행동이 실제로 어떤 결과로 마무리됐는지 초보자도 추적할 수 있습니다.

   요청과 실제 응답 원문

   파일	내용
   tool-workflow-recovery-conversation.txt	Exact recorded Korean conversation

   요청과 실제 응답 원문 내려받기