에이전트 하네스 설계 · 5/10
초기 엔진에도 재시도는 있었습니다. 일시적인 공급자 오류가 나면 같은 요청을 다시 보냈고, 품질 판정이 기준에 못 미치면 피드백을 붙여 새 답을 만들었습니다. 정책 검사는 모델 호출 전후와 도구 실행 직전, 회차 경계에 배치했습니다. 각 장치는 따로 보면 동작했지만 실제 도구 실행과 결합하자 종료의 의미가 겹치기 시작했습니다.
6월 8일부터 10일까지 캔버스 하네스를 검증할 때 종착 도구를 호출하고도 실행이 계속되는 경우가 나타났습니다. 반대로 이전 회차에 종착 도구를 쓴 기록만 보고 현재 회차까지 끝난 것으로 판단할 위험도 있었습니다. ‘도구 호출 성공’, ‘답변 품질 통과’, ‘작업 완료’가 하나의 성공 값으로 합쳐져 있으면 어느 쪽도 정확히 표현할 수 없습니다.
문제를 풀기 위해 다시 호출하는 이유와 종료를 소유하는 위치를 나눴습니다. 기준은 간단했습니다. 다음 호출에서 무엇이 그대로이고 무엇이 달라지는가, 그리고 이번 회차에 완료를 증명한 사건이 있는가.
공급자 오류는 실행 상태를 전진시키지 않습니다
속도 제한이나 일시적인 과부하로 모델 응답을 받지 못했다면 답 후보도 도구 요청도 없습니다. 이때 다시 보내는 것은 새로운 작업이 아니라 같은 논리 호출을 복구하는 일입니다.
그래서 복구 가능한 오류는 모델 공급자 계층 안에서 처리합니다. 요청과 대화 상태는 그대로 두고 오류 종류에 맞는 대기 시간을 적용한 뒤 다시 호출합니다. 정한 시도를 모두 사용하면 호출 실패를 상위 실행 루프로 돌려보냅니다. 빈 응답을 만들어 정상 결과처럼 다음 단계에 넘기지 않습니다.
여기서 늘어나는 값은 공급자 호출 시도뿐입니다. 에이전트의 전체 회차나 품질 재작성 횟수는 아직 움직이지 않습니다. RetryEvent에는 오류 종류와 시도 번호, 대기 시간을 남깁니다. 그래야 전체 지연에서 모델 추론과 전송 복구 대기를 나눠 볼 수 있습니다.
도구 뒤의 모델 호출은 재시도가 아니라 진행입니다
모델이 검색 도구를 요청했다면 호출 자체는 성공했습니다. 최종 답이 없을 뿐 작업은 새로운 관측을 얻는 방향으로 전진했습니다. 하네스는 도구 실행 전 정책을 확인하고, 결과를 메시지와 실행 상태에 추가한 뒤 모델을 다시 부릅니다.
이 전이는 retry가 아니라 continue입니다. 도구를 세 번 사용했다고 품질 재시도 세 번을 소비하지 않습니다. 대신 실행 루프의 전체 회차와 토큰·비용 예산이 늘어납니다. 도구를 계속 부르며 끝나지 않는 실행은 max_iterations와 실행 예산이 막습니다.
이 구분이 없으면 품질 상한을 낮췄을 때 정상적인 도구 탐색까지 중간에 끊깁니다. 반대로 상한을 크게 잡으면 공급자 복구와 도구 진행, 답변 재작성이 모두 같은 카운터를 공유해 비용을 예측하기 어려워집니다. 같은 max_retries라는 이름을 설정에 쓰더라도 어느 계층이 읽고 어떤 사건을 세는지는 달라야 합니다.
종착 도구는 현재 회차에서 호출됐을 때만 끝냅니다
일부 도구는 결과를 얻기 위한 중간 행동이 아니라 제출 자체를 뜻합니다. 메시지 전송이나 최종 저장처럼 호출이 성공하면 해당 작업을 더 이어 갈 이유가 없는 도구입니다. 이를 종착 도구로 등록하면 모델이 별도의 마무리 문장을 만들지 않아도 완료로 전이할 수 있습니다.
초기에는 전체 대화 이력에서 종착 도구 이름을 찾는 방식이 섞여 있었습니다. 이 방법은 두 가지 방향으로 잘못됩니다. 도구는 실행됐는데 결정 단계가 현재 호출을 보지 못하면 불필요한 모델 호출이 한 번 더 생깁니다. 반대로 과거 회차의 종착 기록이 남아 있으면 이후 진행 중인 회차를 일찍 끝낼 수 있습니다.
종료 판단의 범위를 현재 회차로 좁혔습니다. 가장 최근 모델 응답이 이번 회차에 만든 도구 요청인지, 그 도구가 종착으로 등록됐는지, 실행이 성공했는지를 함께 봅니다. 세 조건이 맞을 때만 완료로 전이합니다. 대화 기록은 근거로 남지만 현재 상태를 대신하지 않습니다.
현재 응답에 도구 요청 없음 → 일반 답변 판정
현재 응답에 중간 도구 있음 → 결과를 더하고 continue
현재 응답에 종착 도구 있음 → 성공 확인 후 complete
이 규칙으로 종착 도구 뒤에 불필요한 모델 호출이 이어지는 문제를 막았습니다. 후속 캔버스 출력 노드까지 포함한 부수효과의 중복 소유권은 이 시점에 끝난 문제가 아니었고, 이후 9편에서 별도로 정리했습니다.
품질 미달은 같은 요청을 복구하는 일이 아닙니다
도구 결과를 바탕으로 만든 답은 기술적으로 정상 응답일 수 있습니다. 다만 별도 판정기가 기준 미달로 판단했다면 그대로 다시 호출해서는 결과가 달라질 이유가 없습니다. 부족한 항목을 다음 입력에 넣고 새 답을 만들어야 합니다.
따라서 품질 재시도는 공급자 계층이 아니라 판정과 결정 단계가 소유합니다. 기준별 점수와 미달 사유를 교정 피드백으로 넘기고 재작성 횟수를 올립니다. 상한에 도달하면 더 이상 후보를 만들지 않되, 이를 품질 통과로 기록하지는 않습니다. 최종 결과에는 마지막 판정과 재시도 소진 여부가 함께 남습니다.
완성된 텍스트가 없는 도구 진행 회차에는 일반 답변과 같은 품질 판정을 적용하지 않습니다. 도구를 요청했다는 이유로 ‘답변 부족’ 판정을 내리면 정상적인 탐색이 재작성 실패로 바뀝니다. 초기의 judge hardening은 판정이 적용될 수 있는 응답과 도구 진행 중인 응답을 실행 단계에서 구분하는 데 초점을 맞췄습니다.
후에 후보와 점수가 회차를 넘어 남는 더 미세한 최신성 문제가 발견됐지만, 이 시점에는 반복의 종류와 현재 회차의 종료 사건을 분리하는 것이 먼저였습니다. 해당 최신성 보강은 마지막 편에서 다시 다룹니다.
종료 검사는 소유한 계층에서 실행했습니다
한 회차의 순서는 모델 호출, 응답 정책 검사, 도구 정책과 실행, 품질 판정, 회차 경계 결정으로 이어집니다. 순서가 중요한 이유는 각 검사가 보호하는 대상이 다르기 때문입니다. 입력이 허용됐어도 모델 응답에 민감정보가 생길 수 있고, 안전한 응답이라도 도구 실행에는 별도 승인이 필요할 수 있습니다.
상한도 반복이 시작된 계층에서 확인합니다. 공급자 호출 시도는 모델 호출 계층이, 품질 재작성은 판정 경로가, 도구를 포함한 전체 진행은 실행 루프가 제한합니다. 정책이나 비용 한도는 해당 검사 지점에서 종료 이유를 만들고, 그 뒤의 모델 또는 도구 호출을 막습니다.
테스트는 최종 문자열보다 사건의 순서를 확인했습니다. 일시 오류 뒤에는 논리 응답이 하나만 만들어지는지, 도구 회차가 품질 재시도 횟수를 건드리지 않는지, 종착 도구가 현재 회차에서 실행되면 추가 모델 호출 없이 끝나는지, 과거의 종착 기록만으로는 종료하지 않는지를 봤습니다. 차단 정책 뒤에 호출이 더 이어지지 않는지도 확인했습니다.
호출 횟수는 결과일 뿐입니다. 각 호출이 같은 요청을 복구했는지, 새 관측으로 작업을 전진시켰는지, 판정 피드백으로 새 후보를 만들었는지를 구분해야 실행 시간과 비용을 설명할 수 있습니다. 이 경계가 생기자 판정 점수를 단순 로그가 아니라 다음 실행의 설정을 바꾸는 신호로 써 볼 수 있었습니다. 다음 편에서는 그 설정 탐색을 안전하게 제한한 방법을 다룹니다.
이전 편 → 생성과 판정을 별도 실행 단계로 나눈 이유(4편) 다음 편 → 판정 점수로 설정 후보를 탐색하는 방법(6편)