작업을 시작한 뒤 아직 끝나지 않았다는 답을 여러 번 듣고 있었다. 새로운 판단이 없는 대기까지 AI의 다음 답변으로 이어지면 대화와 문맥이 늘어난다. 나는 카페·유튜브의 기존 플러그인을 쓰는 과정에서 상태 조회를 로컬 프로그램이 맡도록 바꿨다.
기다리는 일과 판단하는 일이 섞여 있었다
전송할 내용과 대상, 날짜가 정해졌는데도 진행 상태를 읽을 때마다 에이전트가 전체 흐름을 다시 보고 있었다. 결과가 달라졌다면 판단이 필요하지만 계속 running인 상태를 기다리는 것은 이미 정한 규칙으로 처리할 수 있다. 정상 대기의 주체를 바꾸는 것이 모델의 답변을 더 짧게 만드는 것보다 먼저였다.
기존 플러그인을 버리고 새 자동화를 만들 필요는 없었다. 시작은 한 번만 접수하고 받은 실행 ID로 상태를 읽으면 된다. 카페의 로컬 예약처럼 목록에서 원래 항목을 찾아야 하는 경우는 해당 조회를 사용한다. 실행 방식의 차이는 어댑터가 맡고 대기 중에 새 제출을 만들지 않는 규칙은 공통으로 유지했다.
실행 ID가 대기를 이어 주는 기준이 됐다
mcp-plugin-runner는 최초 실행과 기존 실행 조회를 나눈다. 이미 알고 있는 resumeRunId가 있으면 새 start를 하지 않고 그 ID의 상태를 읽는다. 처음 시작할 때에는 준비한 문맥과 현재 문맥이 맞는지 확인한 뒤 기존 플러그인에 한 번만 요청한다. 전송 오류가 났다고 같은 시작 호출을 반복하지 않는다.
문맥이 바뀌었다는 오류가 오면 같은 프로젝트와 프로필, 원래 실행이 유지되는지 확인한다. 다른 프로젝트가 보인다는 이유로 대상을 바꿔 조회하지 않는다. 상태를 계속 읽기 위한 편의가 실행의 소유권을 넓혀서는 안 된다. 기다림에도 원래 작업을 식별할 근거가 있어야 했다.
프로그램 안에서는 계속 확인하고 밖에는 요약을 준다
상태 읽기와 간격 대기, 최종 검증은 같은 로컬 실행 안에서 진행한다. 자세한 실행 기록과 오류는 별도 결과 폴더에 남기고 모델에 돌려줄 값은 실행 ID·상태·검증 여부처럼 필요한 요약으로 줄였다. 중간 화면 전체를 매번 대화로 출력하는 일을 줄이려는 구조다.
이때 로그를 작게 만든 것과 실제 작업을 검증한 것은 다르다. 짧은 결과가 succeeded라고 적혀 있어도 원래 플러그인의 verified와 서비스별 결과가 확인돼야 한다. 카페의 게시 확인과 YouTube의 비공개 확인도 같은 뜻으로 합치지 않는다. 요약은 근거를 숨기는 문구가 아니라 이미 남긴 근거의 읽기 입구여야 한다.
측정값은 조건과 단위를 함께 읽었다
과거 최종 비교 기록에는 외부 모델 요청이 9회에서 1회로 줄었다고 남아 있다. 캐시를 포함한 전체 토큰과 비캐시 입력에 출력을 더한 수치도 따로 기록했다. 정상 플러그인 실행 안의 모델 호출 0은 이 구조를 설명하지만 외부 Codex 대화 전체 토큰 0을 의미하지 않는다.
두 회차는 누적 대화 길이와 캐시 상태가 같은 통제 실험이 아니었다. 그래서 이 글에서 고정 절감률이나 모든 업무의 비용을 약속하지 않는다. 대기 조회를 프로그램 안으로 옮긴 실제 경로와 당시 측정의 범위를 연결하는 데 사용한다. 이번 집필에서는 이전 카페 글이나 영상을 다시 올려 수치를 재현하지 않았다.
시간 초과 뒤에도 원래 결과를 남겨 둔다
대기 제한 시간에 도달하면 같은 입력을 다시 보낼 것이 아니라 원래 실행 ID와 영수증을 보존해야 한다. 프로그램이 늦게 끝났을 수도 있고, 상태 응답만 끊겼을 수도 있다. 대기를 끝낸 사실을 원격 작업 실패라는 뜻으로 바꾸면 중복 업로드나 게시를 만들 수 있다.
새 공유 모듈은 이 경계를 작게 떼어냈다. 이미 있는 실행을 읽는 함수만 받고 새로운 실행 함수는 제공하지 않는다. 중지·범위 변경·미확정 결과·읽기 오류를 각각 멈추는 조건으로 둔다. 실제 저장 플러그인의 복구 저널을 대신하지는 않지만, 대기가 왜 재전송과 분리돼야 하는지 독자가 시험할 수 있다.
자동화 비용을 줄일 때 먼저 볼 순서
자기 업무에서도 먼저 새 판단이 필요한 대기인지 확인하면 좋다. 단순 상태 조회라면 프로그램으로 옮기고, 완료 조건과 중지·전송 제한 시간을 명시한다. 반면 대상이 달라졌거나 사용자의 선택이 필요한 상태는 모델이나 사람에게 정확한 질문으로 돌아와야 한다. 모든 멈춤을 자동 재시도로 숨기지 않는다.
나는 이 변경을 대기만 최적화한 작은 선택으로 설명한다. 입력을 줄이는 일, 필요한 스키마만 불러오는 일, 누적 대화의 관리와는 책임이 다르다. 원래 프로그램과 판단 주체의 경계를 지키면서 정상 경로를 짧게 만드는 것이다. 한 번 요청한 일이 어디까지 진행됐는지 더 적은 대화로 정확히 알 수 있기를 바랐다.