계획 생성·수정·검증을 컨텍스트 격리로 분리해 LLM 플래너의 복잡도 붕괴를 막는 GRASP

무엇인가

LLM 에이전트는 자연어로 주어진 복잡한 다단계 업무를 자동화하는 패러다임으로 자리 잡았지만, 지시가 길고 복잡해질수록 성능이 급격히 무너진다. 논문은 이를 "Curse of Instructions"라고 부르며, 제약 조건 충돌과 어텐션 피로가 환각과 다단계 실행 실패를 유발한다고 설명한다. GRASP는 이 문제를 계획 자체를 명시적으로 생성하는 방식으로 우회한다. 고수준 작업 설명을 구조화된 실행 경로로 분해해, 각 하위 단계의 복잡도를 모델이 안정적으로 처리할 수 있는 범위 안에 떨어뜨리겠다는 것이다.

어떻게 동작하나

첫 단계 GenPlan은 작업 설명 T만 보고 인스턴스 I는 모르는 상태에서 거시적 기준 계획 P_G를 만든다. 지식 베이스 KB_t = <T, C_t, G_t, P_t>를 두고, 하드 제약을 뽑는 Constraint Agent, 소프트 가이드라인을 뽑는 Guidelines Agent, 계획을 합성하는 Plan Generation Agent가 이 KB를 공유하며 반복 루프를 돈다. KB가 더 이상 변하지 않으면(KB_{t+1} ≡ KB_t) 수렴으로 보고 최종 기준 계획을 확정한다. 저자들은 제약을 하드 정규화로, 가이드라인을 소프트 정규화로 규정한다. 제약은 탐색 공간에서 논리적으로 불가능한 상태를 잘라내고, 가이드라인은 디코딩 공간의 생성 드리프트를 줄인다.

무엇과 다른가

두 번째 RevPlan은 P_G를 특정 인스턴스에 맞춰 특화한다. 단일 경로로 바로 수정하지 않고 전략 공간 S = {s1, ..., sK}를 만들어 K개의 컨텍스트 격리 트랙을 병렬로 돌린다. 논문에서는 보통 K를 2~4로 둔다. 각 트랙에서 ReAct로 전략별 해 궤적을 만들고, ExtractPlan으로 실행 가능한 단계만 뽑아낸 뒤, MergePlans로 GenPlan의 구조적 청사진과 다시 합친다. 트랙 간 컨텍스트를 분리해 한 경로의 환각이 다른 경로로 번지지 않게 한 것이 핵심이다. 마지막 VerPlan은 후보 계획들을 각각 독립된 컨텍스트에서 채점한다. 작업·인스턴스·GenPlan 제약·전략별 제약·루브릭을 기준으로 0~100점 품질 점수 Ψ를 매기고, 최고 점수 계획을 최종 출력으로 고른다.

어떻게 쓰나

실험은 Natural Plan Calendar Scheduling, GPQA, SciBench Math, ZebraLogic 네 벤치마크에서 이뤄졌다. 모든 계획은 RunAgent라는 다중 에이전트 실행 플랫폼으로 실행했는데, 검증 프로토콜이 계획 품질을 대신 보정하지 못하도록 최소 기능만 켠 버전을 썼다. 결과는 Calendar Scheduling에서 GPT-4o 플래너 대비 12.4%, GPT-4o-mini 플래너 대비 20% 향상이고, GRASP(GPT-4o-mini)가 GPT-4o 플래너를 11.3% 앞선다. ZebraLogic에서는 GRASP(GPT-4o)가 GPT-4o 플래너를 30.8% 앞선다. SciBench Math에서는 GRASP(GPT-4o)가 모든 하위 집합에서 GPT-4o 플래너를 이겼고, GRASP(GPT-4o-mini)는 Stat과 Diff에서 앞서고 Calc에서는 동률이었다. 반면 GPQA에서는 3회 평균 기준으로 GPT-4o 베이스라인이나 플래너보다 통계적으로 유의미하게 나은 결과를 내지 못했다. PlanGEN(4개 변형), Tree-of-Thoughts, Best-of-N과의 비교에서는 Calendar Scheduling, SciBench Stat, ZebraLogic에서 GRASP가 앞섰고 SciBench Calc와 Diff에서는 PlanGEN과 동률이었다.

전제와 한계

가장 눈에 띄는 것은 멀티태스크 확장 실험이다. 단일 태스크에서는 모든 플래너가 44.5~45.8%로 비슷하지만, 태스크를 2개·3개로 늘리면 직접 플래너들이 컨텍스트 오염으로 무너진다. GPT-4o 직접 플래너는 30.5%에서 29.1%로, GPT-4o-mini 플래너는 24.5%에서 21.2%로 떨어진다. GRASP(GPT-4o)는 이중 태스크 45.7%, 삼중 태스크 46.6%로 오히려 유지·상승하며 직접 플래너를 17.5% 앞선다. GRASP(GPT-4o-mini)도 이중 태스크에서 41.2%를 기록해 직접 베이스라인 대비 16.7% 절대 향상을 냈다. GPT-5-mini를 직접 플래너로 쓴 비교에서도 GPT-5-mini는 이중 26.7%, 삼중 25.5%에 그쳤고, GRASP(GPT-4o-mini)가 이중 태스크에서 14.5% 절대 격차로 앞섰다. 이중 태스크 절제 실험에서는 GenPlan만 쓸 때 40.8%, VerPlan만 쓸 때 30.7%인 반면, GenPlan 없이 RevPlan만 돌리면 10.9%, RevPlan+VerPlan은 12.5%로 폭락했다. 전략 수를 1~4개로 바꾸면 73.0%, 74.1%, 75.4%, 71.2%로 3개에서 정점을 찍었고, GenPlan의 제약·가이드라인 생성을 빼면 75.4%가 58.5%로 떨어졌다. 비용은 GRASP(GPT-4o)가 약 13.5배, GRASP(GPT-4o-mini) 3전략 구성은 약 0.95배였다.

개발자 관점에서 이 논문이 주는 실무적 신호는 두 가지다. 첫째, 복잡한 에이전트 워크플로에서 단일 프롬프트에 전역 제약·변수 추적·로컬 단계 생성을 몰아넣는 방식은 확장성이 없다는 점을 수치로 보여준다. 계획 생성, 인스턴스 특화, 검증을 별도 컨텍스트로 분리하는 것만으로 표준 LLM이 프런티어 추론 모델을 앞설 수 있다는 주장은 파이프라인 설계에 직접 참고할 만하다. 둘째, 로컬 전략 탐색은 전역 가드레일 없이는 오히려 해롭다. GenPlan을 뺀 RevPlan이 10.9%까지 떨어지는 결과는 전략 탐색을 붙이면 좋아진다는 통념에 대한 경고다. 도입을 검토한다면 전략 수 K, GenPlan의 제약·가이드라인 품질, 그리고 지연 시간과 토큰 비용을 함께 측정해야 한다.

저자들이 명시한 한계도 분명하다. GRASP는 반복 생성·다중 전략 탐색·검증을 수행하기 때문에 단일 패스 생성보다 런타임 지연이 크고, 즉시 응답이 중요한 실시간 대화형 애플리케이션에는 부적합할 수 있다. 또한 GRASP는 추론 시점의 계획 정규화기일 뿐 모델 자체의 저수준 추론 능력을 끌어올리는 장치가 아니다. 백본 모델이 해당 도메인을 근본적으로 모른다면 그 결손을 메우지 못하며, 실제로 GPQA와 SciBench Diff·Calc에서는 직접 플래너를 앞서지 못했다. 마지막으로 최적 전략 수는 보편 상수가 아니라 태스크 의존 하이퍼파라미터여서, 이질적인 도메인에 배포하려면 수동 튜닝이 필요하다. 삼중 태스크에서 GRASP(GPT-4o-mini)가 28.1%로 무너지는 결과는 소형 모델의 파라미터 용량 한계도 드러낸다.