Planning 기반과 Reactive 기반 중 무엇이 더 좋은가를 묻는 것은, 설계도를 먼저 그리는 것과 현장에서 바로 만드는 것 중 무엇이 더 좋은가를 묻는 것과 비슷합니다. 상황에 따라 다릅니다. 하지만 선택 기준을 잘못 잡으면, 나중에 실패의 원인을 추적할 수 없게 됩니다.
Planning 기반과 Reactive 기반 중 무엇이 더 좋은가를 묻는 것은, 설계도를 먼저 그리는 것과 현장에서 바로 만드는 것 중 무엇이 더 좋은가를 묻는 것과 비슷합니다. 상황에 따라 다릅니다. 하지만 선택 기준을 잘못 잡으면, 나중에 실패의 원인을 추적할 수 없게 됩니다.
계획을 먼저 수립하는 구조의 가장 큰 장점은 감사 가능성입니다. 에이전트가 실행 전에 "이런 순서로 진행하겠습니다"라는 계획을 내놓으면, 사람이 그 계획을 검토하고 승인할 수 있습니다. 실행 이후 문제가 생겼을 때도 "계획의 어느 단계에서 벗어났는가"를 확인할 수 있습니다. 규제 환경에서 운영하거나, 실패의 비용이 크거나, 사후 설명이 필요한 업무라면 Planning 기반이 맞습니다.
Planning 기반의 또 다른 장점은 비용 구조입니다. 계획 수립에는 큰 모델을 쓰고 실행에는 작은 모델이나 코드를 써서 비용을 절감할 수 있습니다. 장기 계획이 안정적으로 유지되어야 하는 복잡한 워크플로우, 규정 준수 검토나 다단계 문서 처리 같은 업무에서 이 구조가 빛을 발합니다. 반면 환경이 예측하기 어려울 때는 초기 계획이 자주 깨져 재계획 오버헤드가 발생합니다. 그럼에도 실패의 원인이 "계획의 3단계에서 벗어남"처럼 구체적으로 특정되는 것은 Planning 기반에서만 가능한 장점입니다. 에이전트가 "왜 이 경로를 선택했는가"를 사후에 구조적으로 설명할 수 있는 것은 규제 환경에서 매우 큰 가치입니다.
환경이 실시간으로 변하고, 사전에 모든 경로를 계획하는 것이 현실적으로 불가능할 때 Reactive Agent가 유연성을 발휘합니다. 그러나 이 유연성은 명확한 비용을 동반합니다. 에이전트가 어떤 이유로 그 판단을 내렸는지 사후에 설명하기 어렵습니다. 오류가 발생했을 때 "왜 이 방향을 선택했는가"를 추적하는 것이 Planning 기반보다 훨씬 복잡합니다. 매 단계마다 LLM을 호출하므로 단계가 길어질수록 비용과 지연도 선형으로 늘어납니다.
이 업무에서 실패가 발생했을 때, 그 원인을 반드시 설명해야 하는 대상이 있는가. 감사, 법무 검토, 경영진 보고 같은 상황이 예상된다면 Planning 기반을 선택해야 합니다. 설명보다 속도와 적응성이 중요한 내부 실험 환경이라면 Reactive도 고려할 수 있습니다.
실제 시스템에서는 둘을 혼합하는 경우도 있습니다. 전체 계획은 Plan-and-Execute로 수립하고, 각 단계 실행은 ReAct 방식으로 처리하는 구성입니다. 전체 구조의 감사 가능성을 확보하면서도 개별 단계에서의 유연성을 살릴 수 있습니다. 어떤 구조를 선택하든, "실패했을 때 어떻게 설명할 것인가"라는 질문이 선택의 출발점이 되어야 합니다. 기능 비교가 아니라 실패 관리 철학이 선택의 본질입니다. 실패를 설명할 수 있는 구조를 선택하십시오.
[Alli's Insight: 프롬프트가 아닌 '구조'로 계획하다]
계획된 업무 수행은 단순히 말로 시킨다고 되지 않습니다. 시스템적인 파이프라인이 필요합니다. 계획된 업무 수행을 위해서는 프롬프트 엔지니어링만으로는 부족합니다.
알리의 LLM 실행 노드는 에이전트가 수행해야 할 단계별 과업을 명확히 정의하고, 각 단계의 결과를 변수로 저장해 다음 단계로 전달하는 '계획된 파이프라인'을 구축합니다.
우리 조직의 업무가 Agentic AI로 구현 가능한지 고민되시나요?
올거나이즈의 엔터프라이즈 전담 팀이 귀사의 업무 시나리오를 분석하고, 실제 구현 가능한 아키텍처를 진단해 드립니다. 단순 툴 체험이 아닌, 실제 비즈니스 적용을 고민하는 기업 담당자분들의 문의를 기다립니다.
