로컬 실행기가 상태를 읽게 만들면 대기 중 모델 호출이 모두 없어질까. 실제 작업에서는 바깥 도구가 프로세스를 기다리는 방식이 한 겹 더 남았다. 기존 로컬 대기 글의 다음 장으로, 실행기 내부의 조회를 줄이는 일과 모델이 다시 깨어나는 횟수를 줄이는 일을 나눠 본다.
실행기 내부의 반복은 이미 프로그램이 맡았다
mcp-plugin-runner는 기존 실행을 시작하거나 기록된 ID로 이어서 읽고, running·queued인 동안 상태를 조회한다. 상태가 끝나면 결과를 반환한다. 이 안에서 매번 새로운 문장 판단을 받아 다음 조회를 정하지 않는다. 실행기 안의 타이머와 읽기 요청은 로컬 프로그램의 반복이다.
그런데 바깥 코드 도구가 프로세스를 짧게 기다린 뒤 제어를 모델에 돌려주면 모델은 다시 결과를 읽고 다음 대기를 요청할 수 있다. 플러그인 안의 모델 호출이 0이어도 바깥 모델 요청은 남는다. 나는 내부 상태 조회 수와 바깥 재개 수를 별도 계수로 보아야 이 구조의 병목을 찾을 수 있다고 판단했다.
짧은 개별 대기를 같은 도구 실행 안에서 이어 갔다
과거 최종 실행은 코드 도구 한 번 안에서 프로세스 종료까지 기다렸고 개별 프로세스 대기는 20초 이하로 나눴다. 전체 실행은 약 117초였다. 프로그램의 상태 조회를 모델이 중간에 다시 판단하지 않아도 도구 코드가 다음 짧은 대기를 이어 갈 수 있는 환경을 사용한 것이다.
그 기록의 도구 실행 한도는 당시 환경 설정이다. 현재 모든 실행 도구에 같은 숫자를 넣으라는 일반 규칙이 아니다. 실제 호스트의 실행 시간과 사용자 중지 전달 조건을 지켜야 한다. 긴 실행의 진행 알림은 유지하되 알림을 새 모델 판단의 필수 단계로 만들지 않는 것이 구조상의 선택이었다. 실행 종료를 확인하기 전에는 후속 발행이나 입력 변경을 이어 붙이지 않는 순서도 필요하다.
실행 핸들과 업무 실행 ID는 서로 다른 표식이다
바깥 프로세스의 세션 핸들은 아직 돌아가는 실행기를 기다리기 위한 것이다. 플러그인의 runId는 원래 업무 결과를 읽기 위한 것이다. 도구가 잠깐 출력 없이 돌아갔다고 다른 실행기를 새로 시작하면 두 계층을 모두 중복시킬 수 있다. 먼저 같은 프로세스가 살아 있는지와 이미 기록한 업무 ID를 확인해야 한다.
원래 실행기는 의도만 있고 ID가 없는 상태를 결과 불확실로 멈춘다. 완료 영수증 재사용도 새 서버 검증으로 부르지 않는다. 바깥 도구 대기를 합치는 개선이 재전송 보호를 우회하는 이유가 되어서는 안 된다. 프로세스가 끝난 사실 역시 서비스의 결과 검증을 대신하지 못한다.
상태 58번을 읽었다는 수치와 모델 한 번은 함께 성립한다
당시 최종 기록은 프로그램이 상태 응답 58회를 처리했고 문맥 이동 재확인을 포함한 로컬 상태 요청은 59회였다고 구분한다. 바깥 모델 요청은 한 번이었다. 조회를 0으로 만든 것이 아니라 조회의 주체를 프로그램으로 옮긴 결과다. 이 숫자를 설명하지 않으면 짧은 출력이 검사를 줄인 것처럼 보일 수 있다.
최종 플러그인은 새 비공개 결과를 확인했으며 앞선 회차의 수동 복구를 최종 자동 성공에 섞지 않았다. 이 글에서는 당시 계정·원고·영상 식별자는 공개하지 않는다. 역사적 실행 경로와 수치의 관계를 설명하는 것이며 지금 새 글이나 영상을 올려 재현한 검수도 아니다.
마지막 요약은 결과와 사용량을 각각 가리킨다
짧은 요약에는 상태·검증 여부·내부 모델 호출 수와 재전송 금지 같은 실행 의미가 필요하다. 실제 원자료와 상세 로그는 결과 폴더에서 읽을 수 있어야 한다. 모델에 전체 로그를 다시 보내지 않는 것과 근거를 버리는 것은 다르다. 요약만으로 판단하기 어려운 실패에서는 관련 영수증을 좁게 열 수 있다.
함께 공개한 사용량 원장은 이 바깥 실행의 단위를 나눠 기록하는 예제다. 프로세스를 실행하거나 대기를 대신하지는 않는다. 나는 실행기 내부의 조회, 도구가 기다린 구간, 모델 호출의 사용량과 서비스 완료를 각자 확인할 수 있게 남겼다. 한 층을 최적화했다고 나머지 층까지 무료가 됐다고 부르지 않기 위해서다.