에이전트가 처음 만든 계획을 끝까지 따르다가 실제 환경 변화에 대응하지 못합니다. 계획과 재계획은 어떻게 관리하나요?

계획은 실행 전에 확정된 진실이 아니라 목표를 달성하기 위한 가설입니다. 모델이 단계 목록을 만들었다면 각 단계의 전제·입력·완료 조건을 확인하고, 실행 관찰이 전제를 깨면 필요한 범위만 다시 계획하겠습니다. 계획을 길게 쓰는 것과 실행 가능한 의존 관계를 만드는 것은 다릅니다.

목표와 작업 상태를 분리합니다

코드 수정 요청이라면 성공 조건은 기능 동작과 기존 테스트 보존이고, 계획은 파일 조사·최소 수정·검증 같은 수단입니다. 조사 결과 예상한 라이브러리가 없다면 구현 수단을 바꾸되 사용자 목표나 승인된 범위까지 바꾸지 않습니다. 단계별로 예정·실행 중·완료·차단 상태를 기록하고, 모델이 계획 문장에 체크 표시를 했다는 이유만으로 완료로 인정하지 않습니다. 실제 diff나 테스트 결과가 상태 전이의 근거여야 합니다.

재계획은 매 도구 응답마다 전체 계획을 새로 만드는 방식보다 중요한 조건 변화에 반응하는 편이 단순합니다. 파일 버전 변경, 권한 거절, 예상하지 못한 외부 비용, 검증 실패처럼 다음 행동을 바꾸는 사건을 구분합니다. 일시적인 네트워크 실패는 같은 단계의 제한된 재시도로 처리할 수 있지만, 권한 부족을 다른 도구나 다른 에이전트로 우회하는 계획은 허용하지 않습니다.

실행권과 의존성을 다시 확인합니다

처음 계획에서 읽은 주문 상태가 실행 때 달라질 수 있으므로 계획의 승인이 현재 데이터에 대한 쓰기 승인은 아닙니다. 변경 직전에 대상 버전과 승인 범위를 검사하고 달라졌으면 재조회·재승인을 요청합니다. 독립 단계는 병렬로 실행할 수 있지만 한 단계의 산출물이 다음 단계 입력이면 완료와 검증을 기다려야 합니다. 목록상 번호가 있다는 사실만으로 런타임의 의존 관계가 강제되지는 않습니다.

과도한 재계획은 비용을 키우고 이미 한 일을 다시 할 수 있습니다. 완료한 작업의 식별자·관찰 결과와 미완료 조건을 유지하고, 이전에 실패한 선택을 근거 없이 반복하지 않게 합니다. 장기 작업에서는 계획을 파일이나 내구 저장소에 보관하되 그것도 읽을 때 현재 환경과 대조합니다. 평가에서는 초기 계획의 그럴듯함보다 전제 변경 후의 회복, 불필요한 재작업, 목표 이탈과 사용자 확인의 적절성을 보겠습니다. 계획자는 선택을 제안하고 실행기는 권한·순서·상태를 강제하는 역할 분리가 필요합니다.

실행 사례로 확인합니다

계획의 단계가 '테스트 수정'으로 되어 있어도 그것이 제품의 실제 버그를 고치는 것인지, 잘못된 기대값을 바로잡는 것인지 구분해야 합니다. 검증 실패를 발견했다고 모델이 성공 기준을 낮추는 방향으로 재계획하면 과제의 목적이 바뀝니다. 요구를 고정한 채 새 관찰에 따라 구현 수단만 바꾸도록 하고, 요구 자체가 모순되면 사용자에게 근거를 제시합니다. 한 단계가 차단되면 독립 작업은 계속할 수 있지만 그 결과가 차단된 전제를 의존하는지 확인합니다. 계획 상태에는 단순 순서뿐 아니라 차단 원인과 의존 작업을 표시해야 완료되지 않은 결과를 다른 단계가 소비하지 않습니다. 이는 자연어 계획을 실행 상태와 연결하는 최소한의 구조입니다.