Agent는 왜 작업 실행 전에 계획을 먼저 생성하는가
장면 빈도, 사람의 비용, 결과의 검증 가능성, 오류의 대가, 데이터 피드백 폐루프.
실행 계획은 사용자에게 보여주는 장식이 아니라, 목표·단계·리스크·도구 경계를 미리 펼쳐놓아 Agent가 추측하면서 조작하는 것을 막는 장치다 — 그것이 낮추는 것은 통제 불가능한 실행의 리스크다. 계획에는 최소한 네 가지가 들어가야 한다: 작업 목표, 입력과 도구, 읽기·쓰기 권한(어느 단계가 읽기 전용이고 어느 단계가 데이터를 바꾸는지), 실패 후 롤백 또는 일시정지 방법.
계획에 반드시 포함되어야 할 네 가지
| # | 요소 | 의미 |
|---|
| 1 | 작업 목표 | 최종적으로 달성할 결과를 명확히 |
| 2 | 입력과 도구 | 작업 수행에 필요한 자원과 능력 |
| 3 | 읽기·쓰기 권한 | 읽기 전용 단계와 데이터 변경 단계를 구분 |
| 4 | 실패 처리 | 실패 후 어떻게 롤백하거나 일시정지할지 |
이 네 가지가 있어야 시스템과 사용자 모두 이 Agent가 어떤 상태에 있는지 판단할 수 있다.
계획은 동적 조정을 허용하되 규율이 있어야 한다
- 계획을 변경할 때마다 이유가 있어야 한다
- 원래의 경계를 몰래 우회해서는 안 된다
- 고위험 변경은 다시 확인해야 한다
정리
Agent가 실행 계획을 먼저 세우는 것은 목표·단계·도구·리스크를 명시화하기 위함이다. 상용 환경에서는 초안 계획과 실행 가능 계획을 구분하고, 계획 변경에 대해 기록과 확인을 해야 한다.
핵심 통찰
- 계획의 가치는 「가독성」이 아니라 「제약 가능성」이다 — 계획을 사람이 보는 설명서로 여기면 「더 명확해진다」는 얕은 답만 얻게 되고, 그것을 실행기의 화이트리스트로 여길 때 비로소 안전 메커니즘이 된다. 이것이 이 문제의 분수령이다.
- 「추측하면서 조작하기」는 Agent 사고의 보편적 형태다 — 대모델의 불확실성은 읽기 전용 작업에서는 감내 가능하지만 쓰기 작업에서는 불가역 손실로 증폭된다. 계획 단계의 본질은 불확실성을 쓰기 작업 앞에서 막아내는 것이다.
- 읽기·쓰기 분리는 Prompt로 상기시킬 게 아니라 계획 구조에 써넣어야 한다 — 「어느 단계가 읽기 전용이고 어느 단계가 데이터를 바꾸는가」가 4요소 중 하나로 꼽혔다는 것은 저자가 이것을 일급 필드로 본다는 뜻이다. 또한 가장 구현하기 쉬운 안전 이득이기도 하다: 읽기 전용 단계는 풀어서 돌리고, 쓰기 단계는 확인을 강제한다.
- 두 계층 계획의 본질은 「인간-기계 계약」과 「기계 계약」의 분리다 — 자연어 계층은 사람에게 의도를 확인시키고, 구조화 계층은 기계에게 행위를 제약한다. 하나로 섞으면 사용자가 못 알아보거나 시스템이 검증하지 못한다.
- 「실행 가능 계획 안의 동작만 실행 허용」은 Agent의 최소 권한 원칙이다 — 도구 호출에 화이트리스트 검증을 한 겹 추가한 것과 같아서, 모델이 실행 중에 즉흥적으로 고위험 도구를 호출하는 것을 막는다.
- 계획은 변할 수 있지만 변경은 흔적을 남겨야 한다 — 동적 조정을 허용하는 것은 현실의 복잡성을 인정하는 것이고, 「이유 + 경계 미우회 + 고위험 재확인」을 요구하는 것은 「조정이라는 명목으로 제약을 회피하는」 구멍을 막는 것이다. 이 셋이 합쳐져야 완전한 방안이며, 하나만 빠져도 퇴화한다.
- 실패 처리는 계획 시점에 정의해야지 사고 후에 생각하면 안 된다 — 롤백이나 일시정지가 4요소에 속한다는 것은, 실패 경로를 명확히 쓰지 않은 계획은 그 자체로 불합격 계획이라는 뜻이다.