플래닝 패턴

LLM이 큰 목표를 바로 실행하지 않고 할 일 목록을 먼저 만든 뒤 하위 작업을 순서대로 처리하게 하는 방식이다. 단계가 많고 중간 결과에 따라 다음 행동이 바뀌는 긴 작업을 에이전트에게 맡길 때 효과가 크다.

계획을 세울 때는 목표를 하위 작업으로 나누고, 무엇이 먼저 끝나야 하는지 따져서 순서를 정한다.

프롬프트 한 줄로 시작할 수 있다

가장 쉬운 방법은 프롬프트에 "먼저 단계별 계획을 세우고, 그다음 실행하라"고 적는 것이다. 예를 들어 "마케팅 캠페인 기획서를 만들어줘"라고 하면 에이전트가 "시장 조사 → 경쟁사 분석 → 타깃 정의 → 전략 수립 → 문서 작성" 순서를 먼저 내놓고 차례로 진행한다. 계획을 먼저 보여 달라고 하면, 실행 전에 내가 순서를 고칠 수 있다.

Claude처럼 확장 사고(extended thinking)를 지원하는 모델은 이 기능을 켜면 답하기 전에 스스로 더 깊이 계획을 세운다. 계획 품질을 높이고 싶을 때 프롬프트 지시와 함께 쓰면 좋다.

에이전트에서는 계획 담당과 실행 담당을 나눈다

직접 에이전트를 만든다면 계획을 세우는 호출과 각 단계를 실행하는 호출을 분리하는 구성이 흔하다. 계획 단계에는 생각을 깊게 하는 강한 모델을 쓰고, 정해진 단계를 처리하는 실행에는 빠르고 싼 모델을 써서 비용을 맞출 수 있다.

처음 세운 계획을 끝까지 믿지 않는다

처음 세운 계획은 틀릴 수 있다. 검색 결과가 비었거나 코드 테스트가 실패했는데도 원래 계획대로 밀고 가면 엉뚱한 결과가 나온다. 단계마다 결과를 확인하고 필요하면 계획을 다시 세우게 해야 한다.

계획이 너무 길어지는 것도 문제다. 단계가 늘수록 앞 단계의 작은 실수가 뒤로 쌓이므로, 목표를 적당한 크기로 나누고 중간 확인 지점을 두는 편이 안전하다.

짧은 일에는 오히려 손해다

번역, 요약, 간단한 질문처럼 한 번에 끝나는 일에 계획 단계를 넣으면 시간과 토큰만 더 든다. 플래닝은 여러 단계를 거쳐야 하고 중간에 판단이 필요한 작업에만 쓰고, 단순한 일은 바로 답하게 두는 것이 낫다.

여러 단계짜리 일을 맡길 때 주로 쓴다

가장 흔한 건 코딩 에이전트와 리서치 에이전트다. 할 일 목록을 먼저 만들게 하고, 중간 결과를 보며 남은 계획을 고치게 하는 방식으로 쓴다.