Planning은 할 일 목록보다 넓습니다
AI 에이전트의 Planning은 목표에 필요한 작업과 순서를 정하고, 실행 결과를 보며 다음 행동을 조정하는 계획 수립 과정입니다. 여기서 관찰은 AI가 잘했다고 말하는 것을 믿는 게 아니라, 읽어 온 자료와 도구의 반환값, 저장된 문서처럼 확인 가능한 결과를 살피는 뜻입니다.
좋은 계획에는 할 일뿐 아니라 필요한 입력, 단계별 산출물, 다음 단계로 넘어갈 조건, 질문할 때와 멈출 때가 들어갑니다. 계획은 완료를 보장하는 장치가 아닙니다. 잘못된 자료로 그럴듯한 결과를 만드는 일을 막으려면 무엇을 확인할지 함께 정해야 한다는 것이 이 글의 설계 권고입니다.
Anthropic은 코드로 경로를 미리 정한 workflow와 모델이 상황에 따라 과정·도구 사용을 정하는 agent를 구분합니다. 정해진 순서대로 분류하고 양식을 채우는 업무라면 고정 workflow로도 충분할 수 있습니다. 애매한 입력을 보고 질문하거나 경로를 바꿀 때는 모델 판단을 일부 맡길 수 있습니다. 공식 설명: Building effective agents
따라서 모든 에이전트에 독립적인 Planner, 즉 계획 전담 모듈이 필요한 것은 아닙니다. 하나의 모델이 다음 행동을 정할 수도 있고, 고정 절차에 제한적인 모델 판단을 섞을 수도 있습니다. 핵심은 모듈의 이름이 아니라 진행 조건입니다. 여러 에이전트의 역할 분담과 달리, 여기서는 한 실행 흐름이 언제 계속되고 멈추는지에 집중합니다.
가상 목표 하나를 계획으로 바꾸기
목표를 “고객 문의 10건을 배송·환불·상품문의로 분류하고, 승인된 안내 자료에 근거한 검토용 답변 초안을 작성하기”로 정해 보겠습니다. 아래 문의·안내 자료·처리표는 모두 직접 작성한 설명용 가상 사례입니다. 실제 분류 실험이나 고객 응대 결과가 아니며 성공률을 나타내지 않습니다.
먼저 사람이 문의 원문 10건과 각 문의를 구별할 번호, 세 분류의 기준, 사용할 안내 자료를 제공해야 합니다. 실제 고객 자료를 외부 AI에 제공한다면 업로드 권한과 서비스의 보관·처리 조건을 먼저 확인하고, 불필요한 개인정보는 제거해야 합니다. 배송과 환불이 섞인 문의를 어떻게 다룰지, 어느 분류에도 맞지 않으면 어떻게 표시할지도 미리 정합니다. 여기서는 억지로 한 종류를 고르지 않고 ‘검토 필요’를 표시하도록 설계합니다.
허용 범위는 자료의 읽기 전용 분석과 지정 문서의 검토용 초안 저장까지입니다. 고객에게 외부 답장을 보내거나 환불을 실행하거나 고객정보를 변경하는 일은 금지합니다. 도구도 자료 읽기와 지정 문서 저장에 필요한 범위로 제한해야 합니다. 계획에 행동이 적혔다고 실행 권한이 생기지는 않습니다.

본문의 가상 문의 처리 사례에 한정한 허용 범위입니다. 그림에 작업을 적는 것만으로 도구 권한이나 자동 실행 기능이 생기지는 않습니다.
단계마다 입력과 통과 조건을 정하기
아래 표는 적용을 위한 설계 권고입니다. ‘통과’는 다음 단계로 넘어가도 되는지 확인하는 기준이며, 모델이 스스로 확신한다는 뜻이 아닙니다.

표를 좌우로 밀어 전체 열을 확인하세요.
| 단계 | 필요한 입력 | 산출물 | 통과 조건 | 질문·중단 조건 |
|---|---|---|---|---|
| 1. 입력 확인 | 원문 10건, 문의 번호, 허용 범위 | 대상 목록과 누락 기록 | 10건을 구별하고 읽을 수 있음 | 부족·중복·파일 오류는 질문 후 대기 |
| 2. 기준 확인 | 세 분류의 정의, 복합 문의 처리 규칙 | 분류 기준표 | 애매한 문의의 처리 방식이 정해짐 | 기준이 충돌하면 사람에게 선택 요청 |
| 3. 분류 | 확인한 원문과 기준표 | 번호별 분류·짧은 근거·보류 표시 | 각 번호가 빠짐없이 한 행에 대응 | 내용 누락·기준 밖 문의는 검토 필요로 보류 |
| 4. 초안 작성 | 분류표, 승인된 안내 자료 | 검토용 답변 초안과 확인할 질문 | 사실·근거와 미확인을 구분 | 근거 없는 배송일·환불 약속은 쓰지 않음 |
| 5. 저장·대조 | 초안, 지정 저장 위치 | 저장 문서와 미해결 목록 | 다시 읽어 번호·내용·누락 여부 확인 | 저장 실패·위치 불일치는 완료 처리 금지 |
OpenAI 가이드는 지침의 각 단계에 구체적인 행동이나 산출물을 적고, 필수 정보가 빠진 경우의 분기까지 준비하도록 설명합니다. 위 표는 그 원칙을 이 가상 목표에 맞춰 구성한 것이며 공식 문서의 표를 옮긴 것은 아닙니다. 공식 설명: Configuring instructions
완성 예시: 가상 문의 10건 처리표
이 예시에서 사람이 승인했다고 가정한 안내 자료도 다음 세 문장으로 한정합니다. S1: “배송 상태는 주문내역에서 확인합니다.” R1: “환불 요청은 주문번호와 사유를 접수해 담당자가 검토합니다.” P1: “가상 상품 X의 색상은 검정과 흰색입니다.” 배송일, 환불 승인·입금 시점에 관한 규정은 없습니다.
분류 기준은 배송 상태·일정은 ‘배송’, 환불 요청·조건은 ‘환불’, 색상·규격은 ‘상품문의’입니다. 두 범주가 겹치거나 범위 밖·자료 부족이면 ‘검토 필요’로 두고 이유를 씁니다. 아래 ‘추가 검토’의 ‘아니요’도 발송 승인이 아니라 이 기준상 추가 질문이 없다는 뜻이며, 모든 답변은 사람 검토용 초안입니다.
표를 좌우로 밀어 전체 열을 확인하세요.
| 번호·가상 문의 | 분류 | 근거 | 검토용 답변 초안 | 추가 검토 필요 |
|---|---|---|---|---|
| 1. 배송 상태는? | 배송 | 상태 조회·S1 | 주문내역에서 배송 상태를 확인해 주세요. | 아니요 |
| 2. 내일 도착하나요? | 검토 필요 | 도착일 질문·S1에 일정 없음 | 주문내역 확인이 필요하며 내일 도착 여부는 확인되지 않았습니다. | 예: 도착일 자료 없음 |
| 3. 환불 신청하려면? | 환불 | 신청 절차·R1 | 환불 요청은 주문번호와 사유를 접수해 담당자가 검토합니다. | 아니요 |
| 4. 환불금 오늘 들어오나요? | 검토 필요 | 입금일 질문·R1에 일정 없음 | 안내 자료에 입금일이 없어 담당자 확인이 필요합니다. | 예: 입금일 자료 없음 |
| 5. X는 무슨 색인가요? | 상품문의 | 색상 질문·P1 | 상품 X의 색상은 검정과 흰색입니다. | 아니요 |
| 6. X에 흰색 있나요? | 상품문의 | 색상 질문·P1 | 상품 X의 색상에는 흰색이 있습니다. | 아니요 |
| 7. 배송 상태와 환불 방법은? | 검토 필요 | 배송+환불·S1/R1 | 배송 상태는 주문내역에서 확인하며, 환불은 주문번호와 사유를 접수해 검토합니다. 두 요청의 처리 범위를 확인해 주세요. | 예: 두 범주 겹침 |
| 8. X 색상과 배송일은? | 검토 필요 | 상품+배송·P1/S1 | X는 검정·흰색이며 배송일은 자료에 없습니다. 두 요청을 나눠 확인해야 합니다. | 예: 두 범주 겹침·일정 없음 |
| 9. X 크기는 얼마인가요? | 검토 필요 | 상품 규격·P1에 크기 없음 | 크기 정보가 없어 승인된 규격 자료가 필요합니다. | 예: 자료 부족 |
| 10. 비밀번호를 잊었어요. | 검토 필요 | 세 분류 밖·관련 자료 없음 | 계정 문의 안내 자료가 필요해 담당자 확인을 요청해야 합니다. | 예: 분류 범위 밖 |
완성 산출물의 범위: 10건 모두에 분류·근거·답변 초안·추가 검토 여부를 채웠습니다. 2·4·7~10번은 미해결 목록에 남깁니다. 여기서는 처리표 작성까지 마쳤으며, 실제 도구 저장·재열람이나 답장 발송을 수행했다는 뜻은 아닙니다.
관찰 결과가 달라지면 재계획하기
재계획은 처음부터 무조건 다시 하는 일이 아닙니다. 무엇이 달라졌는지 기록하고, 영향을 받은 단계로 돌아가는 일입니다. 정보 부족, 틀린 입력, 도구 실패는 서로 다르게 다뤄야 합니다.

문의가 10건보다 적으면 나머지 내용을 추측하지 말고 자료를 요청합니다. 번호가 중복되거나 다른 기간의 자료가 섞였다면 잘못된 입력을 확인하고, 정정된 부분의 분류와 초안을 다시 검토합니다. 분류 기준이 바뀌면 그 기준에 영향을 받는 행도 다시 확인합니다. 이미 쓴 초안을 그대로 두고 제목만 고치는 것은 충분하지 않습니다.
읽기 도구가 실패하면 접근 권한이나 파일 상태를 확인합니다. 저장 도구가 시간 초과되면 ‘실패했으니 다시 저장’으로 바로 넘어가지 않습니다. 지정 위치에 문서가 생겼는지, 내용이 일부라도 저장됐는지 먼저 확인합니다. 실제 상태를 알 수 없으면 중복 저장을 피하도록 멈추고 사람에게 넘기는 편을 권합니다. 외부 상태를 확인한 뒤에만 허용된 재시도를 판단합니다.
Anthropic은 각 단계의 도구 결과 등 환경의 실제 정보를 보고 진행 상황을 판단하고, 장애가 있으면 사람의 피드백을 받거나 반복 횟수 같은 중단 조건을 둘 수 있다고 설명합니다. 공식 설명: Agents
완료와 중단도 계획의 일부입니다
이 예시의 완료는 고객 문제 해결이나 답장 발송이 아닙니다. 10건이 빠짐없이 분류 또는 검토 필요로 표시되고, 초안·근거·미확인 질문이 지정 문서에 저장되어 다시 읽어 확인된 상태입니다. 사람이 검토할 수 있는 초안이 완성됐다는 뜻이지, 모든 분류가 정확하다고 검증됐다는 뜻은 아닙니다.
상한도 사람이 정합니다. 예를 들어 전체 작업 10분, 도구 호출 20회, 같은 읽기 오류의 재시도 1회를 임시 상한으로 둘 수 있습니다. 이는 이 글의 예시값이며 권장 표준이나 제품의 자동 중단 기능 보장이 아닙니다. 실제로 제한을 적용할 코드·설정과 시간·호출 기록을 확인해야 합니다. 상한에 도달하면 완료한 부분, 남은 부분, 필요한 입력을 남기고 중단합니다.

OpenAI는 실행을 종료 조건까지 이어 가는 반복으로 설명하며, 오류·최대 실행 횟수 등 종료 조건과 실패 시 사람에게 제어를 넘기는 설계를 다룹니다. 공식 설명: Single-agent systems 및 Plan for human intervention
Planning의 실용성은 긴 계획표보다 “무엇이 확인되어야 다음으로 가는가”에서 드러납니다. 필요한 입력을 받고, 결과를 관찰하고, 달라진 조건에 맞춰 계획을 고치고, 완료 또는 중단을 구분하는 짧은 흐름부터 설계해 보세요.
핑백: AI 에이전트란 무엇인가? 쳇봇과 가장 큰 차이 – nextsignal24
핑백: 멀티에이전트 시스템이란? 여러 AI가 역할을 나눠 일하는 원리 – nextsignal24
핑백: AI 에이전트는 왜 실수할까? 오류가 생기는 원리와 한계 – nextsignal24