에이전트에 필요한 것은 더 많은 프롬프트가 아닌 제어 흐름이다
에이전트가 복잡한 작업을 안정적으로 수행하려면 프롬프트 체인에 의존할 것이 아니라, 소프트웨어적으로 구현된 결정론적 제어 흐름과 명시적 상태 전환이 필수적입니다. LLM을 시스템 전체가 아닌 하나의 구성 요소로 취급하고, 치명적인 오류를 막기 위해 철저한 프로그래밍 방식의 검증 로직을 런타임에 포함해야 한다는 핵심 주장입니다.
에이전트에 필요한 것은 더 많은 프롬프트가 아닌 제어 흐름이다 2026년 5월 7일
주장: 복잡한 작업을 안정적으로 처리하는 에이전트는 점점 더 정교해지는 프롬프트 체인(prompt chain)이 아니라, 소프트웨어로 명확하게 구현된 결정론적 제어 흐름(deterministic control flow)이 필요합니다.
만약 당신이 프롬프트에 '반드시(MANDATORY)'나 '절대 건너뛰지 마시오(DO NOT SKIP)' 같은 문구를 적어본 적이 있다면, 당신은 이미 프롬프팅의 한계에 부딪힌 것입니다. 프로그래밍 언어의 명령문이 단순한 '제안'에 불과하고, 함수가 환각(hallucination)을 일으키면서 '성공'을 반환하는 상황을 상상해 보십시오. 이런 환경에서는 추론이 불가능해지며, 복잡성이 증가할수록 신뢰성은 완전히 무너집니다.
소프트웨어는 라이브러리, 모듈, 함수 등을 조합해 만드는 '재귀적 구성 가능성(recursive composability)'을 통해 확장됩니다. 궁극적으로 모든 것은 코드로 이루어져 있습니다. 코드는 예측 가능한 동작을 노출하여 국소적인 추론(local reasoning)을 가능하게 합니다. 프롬프트 체인은 이러한 속성이 부족합니다. 제한된 작업에는 유용할지 모르나, 프롬프트는 본질적으로 비결정적(non-deterministic)이고 명세가 불명확하며, 검증하기가 매우 어렵습니다.
신뢰성을 확보하려면 자연어로 된 산문(prose)에서 로직을 빼내어 런타임 환경으로 옮겨야 합니다. 우리는 결정론적 뼈대(scaffold)가 필요합니다. 즉, LLM을 시스템 전체가 아닌 하나의 구성 요소로 취급하고, 명시적인 상태 전환(state transition)과 유효성 검사 체크포인트(validation checkpoint)를 갖추어야 합니다.
하지만 결정론적 오케스트레이션(orchestration)은 전투의 절반에 불과합니다. 조용한 실패(silent failure)가 발생하기 쉬운 시스템에서, 공격적인(aggressive) 오류 감지 기능이 없는 에이전트는 단지 '잘못된 결론에 빠르게 도달하는 방법'에 불과합니다. 프로그래밍 방식의 검증(verification)이 없다면 우리에게는 다음 세 가지 선택지만 남게 됩니다:
- 베이비시터(Babysitter): 오류가 전파되기 전에 인간이 직접 개입해 오류를 잡아냅니다.
- 감사자(Auditor): 실행이 끝난 후에 전체적인 종단간(end-to-end) 검증을 수행합니다.
- 기도(Prayer): 그저 마음속으로 '이 정도면 괜찮겠지' 하고 직관(vibe)에 맡겨 출력 결과를 그대로 수용합니다.