에이전트 시스템에서 계획과 실행을 분리해야 하는 이유

계획은 실행 기록이 아니다

에이전트가 훌륭한 작업 순서를 만들었다고 해서 그대로 실행해도 안전한 것은 아니다. 계획의 전제가 불완전할 수 있고, 도구가 설명보다 큰 효과를 일으킬 수 있다. 외부 작업은 성공했지만 그 사실을 저장하기 전에 프로세스가 종료될 수도 있다. 계획과 실행을 하나의 대화 흐름에 섞으면 세 가지 질문에 답하기 어려워진다. 무엇을 하려 했는가, 어디까지 허가받았는가, 실제로 무엇이 일어났는가?

해법은 상태 경계를 명시적으로 나누는 것이다.

계획은 검토 가능한 산출물로, 실행은 복구 가능한 상태 머신으로, 검증은 에이전트의 마지막 문장이 아닌 증거로 다룬다.

이 구조는 에이전트의 능력을 제한하기 위한 것이 아니다. 자율성이 어떤 범위에서 작동하는지 운영자가 확인하고, 멈추고, 이어서 실행하고, 통제할 수 있게 만든다.

효과를 일으키기 전에 요청의 모호함을 해소한다

첫 번째 경계는 사용자의 요청이다. 자연어 지시에는 범위, 완료 기준, 권한, 위험 허용치가 자주 빠져 있다. 예를 들어 “배포해”라는 말은 미리보기 배포를 만들라는 뜻일 수도 있고, 운영 도메인을 바꾸거나 데이터를 마이그레이션하라는 뜻일 수도 있다. 준비 상태만 보고하라는 요청일 가능성도 있다.

실행에 들어가기 전에 다음을 포함한 정규화된 미션을 만든다.

• 달성할 목표와 명시적인 비목표
• 작업 범위에 포함된 시스템, 데이터, 사람
• 완료를 입증할 증거
• 시간, 비용, 데이터, 외부 효과에 대한 제약
• 사람의 선택이 남아 있는 결정

위험이 낮은 불확실성은 읽기 전용 조사로 해소할 수 있다. 결과를 크게 바꾸거나 되돌리기 어려운 행동에 권한을 부여하는 선택은 임의로 채우지 말고 드러내야 한다.

이 미션이 계획의 입력이 된다. 이후 도구 결과에 맞춰 최초 목표를 조용히 바꿔서는 안 된다.

계획을 버전이 있는 산출물로 만든다

계획은 현재 상태에서 목표까지 가는 제안된 경로다. 각 단계에는 기대 효과, 선행 조건, 검증 방법, 롤백 또는 복구 경로가 있어야 한다. 새로운 근거가 나오면 계획을 바꿀 수 있지만, 변경 이유와 함께 새 버전으로 남기는 편이 안전하다.

계획 기록에는 다음 정보가 유용하다.

plan_id
version
mission_id
assumptions
steps[]
단계별 위험 등급
필요한 승인
기대 증거
created_at

승인은 특정 계획 버전에 묶어야 한다. 승인받은 뒤 계획을 크게 바꿔도 효력이 그대로라면 검토의 의미가 사라진다. 세부 운영 선택에는 유연성을 둘 수 있지만 경계는 분명해야 한다. 읽기 전용 자료원을 다른 자료원으로 바꾸는 것은 허용할 수 있어도, 운영 데이터 쓰기를 새로 추가한다면 새 계획으로 봐야 한다.

계획은 실행 여부를 주장해서도 안 된다. “테스트를 실행한다”는 계획에 속한다. 실제 명령, 종료 코드, 실행 시각, 결과물은 실행 증거에 속한다.

실행 상태는 계획과 별도로 관리한다

실행은 계획의 각 단계를 수행하는 영속적인 시도들의 연속이다. 단계는 준비, 실행 중, 승인 대기, 차단, 검증 중, 성공, 실패 같은 상태를 가진다. 이 상태는 모델의 서술문 밖에 저장해야 한다. 연결이 끊기거나 모델 공급자가 바뀌어도 사라지지 않아야 한다.

각 실행 시도에는 다음을 기록한다.

• 호출한 도구와 정규화된 인자
• 어떤 실행자, 정책, 계획 단계가 권한을 부여했는지
• 시작과 완료 시각
• 결과 또는 결과물 참조값
• 외부 효과가 이미 발생했을 가능성
• 검증 결과

같은 단계를 재시도할 때 이 정보가 특히 중요하다. 재시도는 단순히 모델에게 한 번 더 말하는 행위가 아니다. 읽기 작업을 반복하는 것인지, 중단된 작업을 이어가는 것인지, 같은 외부 효과를 두 번 일으킬 위험이 있는지 런타임이 판단해야 한다.

승인은 실제 효과가 발생하기 직전에 받는다

승인은 보호해야 할 행동의 직전에, 정확한 인자를 보여줄 때 가장 유용하다. 긴 계획 시작 전에 “앱 배포”를 한 번 승인하는 것보다, 배포 결과를 확인한 뒤 “v2.example.com을 배포 X에 연결”하는 행동을 승인하는 편이 강한 통제다.

도구나 행동을 효과에 따라 나눌 수 있다.

• 읽기 전용 — 조사, 검색, 계산
• 되돌릴 수 있는 쓰기 — 초안 생성, 미리보기 배포, 기능 브랜치 푸시
• 외부에 공개되는 쓰기 — 게시, 메시지 전송, DNS 또는 라우팅 변경
• 민감하거나 되돌리기 어려운 효과 — 결제, 삭제, 자격 증명 또는 접근 권한 변경

정책으로 일부 등급을 미리 허용하고 나머지는 별도 승인을 요구할 수 있다. OpenAI Agents SDK도 이 흐름을 직접 제공한다. 보호된 도구 호출 앞에서 실행을 멈추고, 승인 요청과 실행 상태를 반환한 뒤, 승인 또는 거절 결과를 반영해 같은 지점에서 재개한다. OpenAI의 에이전트 구축 가이드 역시 위험한 행동과 반복 실패에는 사람의 개입이 필요하다고 권고한다.

승인 기록에는 도구, 정규화된 인자, 계획 버전, 승인자, 결정, 만료 시각이 포함돼야 한다. 승인 뒤 인자가 달라지면 다시 검토해야 한다.

외부 효과의 앞뒤에 체크포인트를 둔다

오래 실행되는 에이전트는 프로세스 장애 뒤에도 불확실한 작업을 반복하지 않고 복구할 수 있어야 한다. 체크포인트에는 미션, 계획 버전, 실행 상태, 대기 중인 승인, 완료 증거의 참조값을 담는다.

가장 중요한 체크포인트는 외부 효과를 감싼다.

1. 도구를 호출하기 전에 의도와 정확한 행동을 저장한다.
2. 가능하면 안정적인 작업 식별자나 멱등성 키로 실행한다.
3. 결과와 외부 참조값을 저장한다.
4. 실제 결과 상태를 다시 확인한다.
5. 확인을 마친 뒤에만 단계를 완료로 바꾼다.

2번과 3번 사이에서 프로세스가 종료되면 상태는 자동 재시도가 아니라 결과 불명이어야 한다. 복구 절차는 안정적인 식별자로 외부 시스템을 먼저 조회한다. 결제 API에서 만나는 것과 같은 불확실성 문제다.

LangGraph의 영속성 계층은 그래프 상태를 체크포인트로 저장하고, 인터럽트 뒤 나중에 이어서 실행할 수 있게 한다. 공식 문서는 재개 시 노드 경계에서 작업이 다시 시작될 수 있다고 설명한다. 따라서 노드 안에서 일으키는 외부 효과는 결정적이거나 멱등하게 설계해야 한다. 프레임워크는 상태 저장을 제공하지만, 안전한 경계를 고르는 책임까지 대신해주지는 않는다.

검증을 독립된 단계로 둔다

에이전트가 “완료했습니다”라고 말하는 것은 증거가 아니다. 검증 기준은 미션에서 정하고, 효과가 발생한 뒤 가능한 한 독립된 관측 경로로 확인해야 한다.

예를 들면 다음과 같다.

• 배포 URL에서 기대한 커밋과 화면이 실제로 보이는가?
• 데이터베이스 마이그레이션 상태에 대기 항목이 없고 대표 조회가 성공하는가?
• 풀 리퀘스트 검사가 통과했고 대상 브랜치에 병합 커밋이 들어갔는가?
• 생성한 미디어가 기술 검사와 시각 품질 기준을 모두 통과했는가?
• 로컬 응답이 아니라 권위 있는 외부 서비스에 기록이 존재하는가?

증거에는 무엇을, 언제, 어떤 방법으로 관측했으며 그 결과가 무엇을 입증하는지 남긴다. 빌드 성공은 컴파일 가능성을 증명하지만 운영 동작을 증명하지 않는다. HTTP 200은 접근 가능성을 보여줄 뿐, 올바른 내용이 배포됐다는 보장은 아니다.

OpenAI Agents SDK의 트레이싱은 모델 생성, 도구 호출, 핸드오프, 가드레일을 기록한다. 실행 경로를 재구성하는 데 유용하지만, 제품의 완료 여부는 도메인별 검증식으로 판단해야 한다. 로그는 경로를 설명하고, 검증은 결과를 확정한다.

공급자 전환이 외부 효과를 반복하게 해서는 안 된다

모델 공급자는 장애가 나거나 요청을 제한할 수 있고, 문맥을 잃을 수도 있다. 입력 산출물이 고정돼 있는 계획 또는 읽기 전용 분석 단계에서는 공급자를 바꿔도 비교적 안전하다. 외부 효과를 일으키는 도중에는 다르다. 새 공급자가 앞선 도구 호출의 결과를 알 수 없다면 같은 행동을 다시 실행할 수 있다.

따라서 공급자 전환은 체크포인트 경계에서만 허용하는 편이 안전하다. 새 공급자에게는 대화 원문만 넘기는 것이 아니라, 미션, 승인된 계획 버전, 현재 실행 상태, 대기 중인 결정, 증거 참조값을 전달한다. 준비나 검증 중 상태에서는 이어갈 수 있지만, 결과 불명을 새 실행 권한으로 해석해서는 안 된다.

비용 한도, 허용 도구, 승인 규칙, 데이터 경계 같은 정책도 공급자 프롬프트 밖에서 강제해야 한다. 모델이 바뀌었다고 권한이 넓어져서는 안 된다.

다섯 가지 영속 기록으로 시작한다

실용적인 구현은 다음 다섯 기록만으로도 시작할 수 있다.

1. 미션 — 목표, 제약, 범위, 완료 증거
2. 계획 — 버전이 있는 단계, 가정, 위험, 승인 요구사항
3. 승인 — 정확한 행동과 계획 버전에 묶인 결정
4. 실행 — 시도, 상태 전이, 외부 참조값, 결과 불명 상태
5. 증거 — 완료 또는 기각 판단을 뒷받침하는 관측

JARVIS 사례는 미션, 실행, 승인, 워크스페이스, 공급자 정책을 운영자용 HUD와 함께 다룬다. Arc는 StateGraph 기반 계획, 단계별 스트리밍 상태, 체크포인트 재개에 집중한다. Project Agora에는 또 다른 경계가 있다. 에이전트가 작업을 제출한 뒤 프로토콜 규칙에 따라 결과를 검증한다. 세 사례가 가리키는 방법은 같다. 제안, 승인, 실행, 입증을 분리해야 모든 전이를 이해할 수 있다.

실행 전 검토 질문

에이전트가 계획을 실행하도록 하기 전에 다음을 확인한다.

1. 목표를 정규화했고 비목표를 명시했는가?
2. 운영자가 승인 대상 계획의 정확한 버전을 볼 수 있는가?
3. 외부 효과가 있는 단계마다 위험 등급과 복구 경로가 있는가?
4. 실제 실행 직전에 정확한 도구 인자를 승인하는가?
5. 결과가 불명확한 효과를 반복하지 않고 실행을 재개할 수 있는가?
6. 완료 판단이 독립된 증거에 근거하는가?
7. 다른 공급자가 새로운 권한을 얻지 않은 채 영속 상태에서 이어갈 수 있는가?

이 질문에 영속적인 답이 있을 때 에이전트 시스템은 운영 가능한 도구가 된다. 지능은 경로를 선택한다. 런타임은 그 경로가 현실과 만나는 동안 의도, 권한, 상태, 증거를 보존한다.