plan-and-execute

이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.

한 줄로 말하면

plan-and-execute는 큰 목표를 바로 한 번에 처리하지 않고, 할 일을 나눈 계획을 세운 뒤 한 단계씩 실행하고 결과가 달라지면 계획도 고치는 방식이야.

비유로 이해하기

이사를 준비한다고 생각해 보자. 짐을 싸고, 차를 부르고, 새집에 들여놓는 순서는 미리 적을 수 있어. 하지만 엘리베이터가 고장 나거나 큰 가구가 문을 못 통과하면, 처음 목록을 고집할 수는 없지. 운반 순서를 바꾸거나 사람을 더 부르거나 다음 날로 미뤄야 해.

긴 과제를 맡은 에이전트도 비슷해. 계획은 출발 전에 길을 보게 해 주지만, 실행 결과가 새 사실을 보여 주면 다음 길은 달라져. 계획을 세우는 일과 실제로 도구를 쓰는 일을 나눠 보는 이유가 여기 있어.

정확한 정의

이 방식은 보통 네 단계가 이어져.

flowchart TD
    A["목표와 완료 조건"] --> B["작은 과업으로 나눈 계획"]
    B --> C["한 과업 실행"]
    C --> D["결과와 검증 신호 확인"]
    D -->|"계획이 여전히 맞음"| E{"남은 과업이 있나?"}
    E -->|"있음"| C
    E -->|"없음"| F["결과 전달"]
    D -->|"전제가 바뀜·막힘"| G["계획 수정 또는 사람에게 질문"]
    G --> B

먼저 목표를 완료된 상태로 바꿔 적어야 해. 그다음 목표를 확인할 수 있는 작은 과업으로 나누고, 한 과업을 실행해. 실행이 끝나면 결과물이 맞는지, 오류가 났는지, 처음 가정이 유지되는지를 확인하지. 이 확인이 없으면 계획은 할 일 목록일 뿐이야.

계획을 다시 세우는 것은 실패를 인정하는 의식이 아니야. 새 파일을 읽었더니 수정 범위가 넓어졌거나, 테스트가 예상과 다르게 실패했거나, 필요한 권한이 없다는 사실을 알게 됐을 때 다음 행동을 바꾸는 일이지. Microsoft는 Foundry Agent Service를 여러 단계의 계획, 도구 사용, 과업 실행을 엮는 구성으로 설명하며, 별도의 통제면에서 응답 평가와 규칙 위반 차단을 함께 둬.¹

왜 중요한가

한 번의 답변으로 끝나는 일은 계획을 길게 세울 이유가 적어. 반면 코드를 고치고 테스트를 돌리거나, 여러 문서를 대조해 결론을 만들거나, 서로 의존하는 작업을 처리할 때는 순서가 결과를 바꿔. 먼저 무엇을 확인할지 정하면 빠진 단계를 줄일 수 있어.

다만 긴 계획 자체가 품질을 보장하지는 않아. 처음에 세운 단계가 틀렸다면, 그 계획을 충실히 따르는 편이 더 큰 낭비가 될 수 있어. 그래서 계획과 실행 사이에는 결과를 읽고 방향을 바꾸는 지점이 꼭 필요해.

실제 예시

에이전트에게 버그를 고치라고 맡겼다고 해 보자. 처음 계획은 오류를 재현하고, 관련 코드를 찾고, 수정한 뒤 테스트를 돌리는 순서가 될 수 있어. 테스트가 실패하면 오류 메시지가 다음 행동을 정해. 처음 고친 함수가 아니라 호출하는 쪽을 바꿔야 할 수도 있고, 요구사항이 모호하면 사람에게 물어야 할 수도 있어.

이때 agent loop는 실행 결과를 보고 다음 행동을 고르는 반복 구조를 말해. plan-and-execute는 그 반복 안에서 큰 목표를 어떤 과업으로 쪼개고, 언제 목록을 다시 짤지를 다루는 관점이야. 더 넓게는 agentic workflow가 도구 권한, 검증, 기록, 사람의 개입까지 포함한 전체 작업 흐름을 설명해.

헷갈리지 말아야 할 점

• 계획은 고정된 스크립트가 아니야. 실행 뒤에 얻은 정보가 처음 가정과 충돌하면 계획도 바뀌어야 해.
• 재계획은 매 단계마다 처음부터 다시 생각하는 일이 아니야. 완료 조건과 현재 상태를 비교해, 바꿔야 할 부분만 고치는 편이야.
• 작은 과업으로 나눈다고 검증이 자동으로 되지는 않아. 파일 변경에는 테스트, 조사에는 원문 확인처럼 과업마다 맞는 확인 신호가 필요해.
• 계획을 세운다고 사람의 판단이 사라지는 것은 아니야. 권한이 필요한 행동, 목표가 모호한 경우, 실패 비용이 큰 결정은 멈추고 물어야 해.

관련 문서

• 실행 결과를 다음 행동으로 돌려보는 반복 구조: agent loop
• 도구·권한·검증을 포함한 더 넓은 작업 설계: agentic workflow

남은 질문들

• 긴 과제에서 처음 계획을 얼마나 자세히 쪼개야 실행 비용보다 이득이 커질까?
• 실패한 과업은 언제 재시도하고, 언제 계획에서 빼거나 사람에게 넘겨야 할까?
• 재계획이 실제 성공률을 높이는지 알려면 어떤 과업별 검증 신호와 비용을 함께 기록해야 할까?

각주

1. Microsoft Azure, 「Claude in Microsoft Foundry is now generally available」(2026-07-10) 원문 ↩︎