실패한 작업을 목표에 맞게 다시 이어 가려면

문제의 출발점

계획이 검토를 통과하고 실행이 승인돼도 실패는 남아요. 계산 함수가 잘못된 값을 반환할 수도 있고, 실제 작업은 진행됐는데 응답을 받지 못할 수도 있어요. 두 경우 모두 화면에는 작업이 끝나지 않은 것처럼 보일 수 있지만, 다음 행동은 달라야 해요.

실패 복구의 기준은 목록의 첫 번째 항목으로 돌아가는 것이 아니에요. 원래 목표를 유지하면서 현재 무엇이 확인됐고 무엇이 달라졌는지부터 구분해야 해요. 그래야 필요한 작업만 고치면서도 오래된 근거를 잘못 재사용하지 않을 수 있어요.

응답이 없다는 사실을 실패로 확정하지 않기

SQLite transaction은 Engine 내부 상태를 관리해요. provider가 외부에서 만드는 효과까지 같은 transaction으로 묶을 수는 없어요. 원장에 실행 의도인 intent를 기록하고 호출한 뒤, provider가 작업을 수행했지만 결과 receipt를 기록하기 전에 연결이 끊길 수 있어요.

intent 기록 → provider 실행 → 효과 발생 → 응답 수신과 receipt 기록
                              └ 이 뒤에서 응답이 사라질 수 있음

이 상태에서 같은 실행을 다시 만들면 이미 발생한 효과를 중복할 수 있어요. Engine은 기존 요청 digest와 thread·turn을 연결하고 원래 실행을 먼저 관측해요. 외부 효과는 대상과 동작의 identity, adapter receipt 및 대상 재관측도 확인해요. 확인할 수 없으면 EXTERNAL_EFFECT_UNKNOWN으로 멈춰요. operation 기록, 효과 checkpoint 복구 검사

RuntimeJobSupervisor가 관측 stream과 receipt를 관리하더라도 수집기의 종료를 provider 작업의 종료로 해석하지 않아요. 재연결 조건과 기존 실행 상태를 확인해요. 이 구조는 exactly-once 실행이나 자동 rollback을 보장하지 않으며, 관측으로 해소하지 못한 상태는 계속 정지 조건이 될 수 있어요. RuntimeJob 감독

확인된 검사 실패라면 고칠 지점을 정하기

앞서 직접 변환하는 total은 재사용 검사에서 실패했어요. 이 경우에는 응답 유실이 아니라 명령의 종료 코드와 실패한 assertion이 있어요. 고칠 대상도 분명해요. 테스트 기대값을 바꾸는 대신 합계 구현을 기존 함수에 연결해요.

def total(prices: list[str]) -> int:
    return sum(cents(price) for price in prices)

격리 복사본에서는 이 변경 뒤 원래의 전체 6개 검사가 통과했어요. 확인한 것은 fixture의 행동과 조건이며 실제 provider 실행이나 Engine 완료 전이를 수행한 결과는 아니에요.

Engine의 EvidenceFirstFailureClassifier도 provider가 관측한 오류, Engine의 직접 오류와 검사 evidence를 우선해요. 모델이 응답에 적은 원인 설명은 따로 보존하고 자동 복구의 확정 근거로 승격하지 않아요. 직접 근거가 부족하면 unclassified로 남겨요. 실패 분류

같은 Task의 구현을 고치는 repair와 Goal·Plan을 바꾸는 revision은 다른 경로예요. 재시도와 재계획에는 횟수, provider 호출 수와 deadline 한도가 있어요. 새 근거 없이 같은 실패를 반복하거나 임의로 provider를 바꾸는 것은 복구 전략이 아니에요.

끝난 작업의 표식보다 유효한 근거를 재사용하기

합계 구현만 고치면 되는데 변환 함수까지 처음부터 다시 만드는 것은 불필요할 수 있어요. 반대로 T1이 완료됐다는 이유만으로 그 결과를 계속 사용할 수도 없어요. 그 뒤 money.py나 지침, 입력이 바뀌었다면 이전 검사는 현재 상태를 설명하지 못할 수 있어요.

reuse_completed_tasks가 먼저 비교하는 것은 이전 Plan과 새 Plan의 goal_contract_digest예요. 두 값이 다르면 완료 근거를 재사용하지 않아요. 같은 Goal이어도 task_ref로 찾은 이전 Task의 의미와 들어오는 의존관계가 현재 Task와 일치해야 해요. 재사용의 계약 조건

if previous.definition.goal_contract_digest != plan.definition.goal_contract_digest:
    return ()

그다음 원래 완료 기록과 파일·Context의 관측 checkpoint를 확인해요. 필요한 validation ID 집합이 같고, 최신 검사 결과와 evidence가 그 checkpoint에 연결돼 있어야 해요. 과거 Attempt와 receipt를 새 실행으로 옮기는 것이 아니라 출처를 보존해요. 외부 효과의 현재 유효성은 로컬 파일 관측으로 증명할 수 없으므로 같은 방식의 재사용 대상에서 제외해요.

예를 들어 새 수용 기준을 추가해 Goal digest가 달라졌다면, money.py가 그대로이고 이전 변환 검사가 통과했어도 이 재사용 경로는 적용되지 않아요. Goal digest가 같더라도 T1의 작업 의미나 선행 작업 관계를 바꾸면 다른 조건에서 거부될 수 있어요. 파일이 바뀌었는지만 확인해서는 부족한 이유예요.

그래서 재사용할 수 있는 것은 단순한 ‘완료’ 표식이 아니에요. 지금의 목표와 입력에도 유효하다고 확인한 결과와 근거예요. 과거 기록은 보존하면서 현재 판단에는 사용하지 않을 수도 있어요. 이 구분이 있어야 작업을 이어 가는 기능과 잘못된 결과를 계속 믿는 행동을 나눌 수 있어요.

AI에게 맡길 범위는 어디까지일까요

다섯 편에서 질문은 실행 자동화에서 시작했어요. 작업 목록을 AI가 만들게 하자 각 작업의 성공이 원래 목표를 만족하는지 확인해야 했어요. 그래서 경로를 먼저 검토하고, 계획·실행·승인·완료 판정의 역할을 나누었어요. 실패한 뒤에는 그 기준을 유지하면서 다음 행동과 근거의 재사용 여부를 정해야 했어요.

현재 구현에는 이 과정을 지원하는 구조와 회귀 검사가 있어요. 그렇다고 어떤 요청이든 자율적으로 끝낼 수 있다는 결론을 낼 수는 없어요. 패키지는 0.2.0a1이고 1.0 판정은 NO-GO예요. 현재 RuntimeJob 실행은 Windows 전용이고 GUI는 실제 Engine과 연결되지 않았어요. 표준 Codex provider의 필수 governance 지원도 막혀 있어요. 실제 provider·설치 후보·전체 제품 qualification의 검증 과제가 남아 있어요.

scripts/installed_candidate_qualification.py와 qualification manifest는 source에서 실행한 검사와 설치된 wheel의 근거를 구분해요. 같은 실행 입력과 artifact가 어느 후보에 연결됐는지 확인하려는 장치예요. 이번 글에서 실행한 것은 fixture의 격리 복사본 검사이며, 앞선 표적 검사에서 남은 시간 관련 실패도 공통 부록에 보존했어요. 이 결과를 전체 제품 검증의 통과로 확대하지 않아요. 설치 후보 검사, 검증 근거 manifest

AI에게 더 많은 문제 해결 과정을 맡기려면, 실행할 일뿐 아니라 선택한 경로를 받아들이고 결과를 확인할 기준도 함께 설계해야 해요. 사람은 목표와 허용할 행동을 확인하고, AI는 그 안에서 계획과 실행·검토를 맡으며, 시스템은 확인된 계약과 근거에 맞게 상태를 바꿔요. 어디까지 맡길 수 있는지는 이 역할 사이의 경계가 실제 환경에서도 작동하는지 입증한 범위에서 판단해야 해요.

공통 검증 부록