프롬프트 그 이상: 신뢰할 수 있는 에이전트에게 결정론적 제어 흐름이 необходимо의 이유

현재의 AI 에이전트 개발 시대는 한계에 부딪히고 있습니다. 많은 개발자들에게 이 여정은 단순한 프롬프트로 시작하여, 복잡한 지시 사항의 체인으로 진화하고, 결국 MANDATORY 또는 DO NOT SKIP와 같은 대문자 키워드를 사용하여 강제로 준수를 시도하는 절망적인 시도로 이어집니다.

LLM에게 대문자로 소리를 지르는 단계에 도달했다면, 당신은 더 나은 프롬프트를 찾은 것이 아니라 프롬프트 엔지니어링의 한계에 도달한 것입니다. 근본적인 문제는 우리가 본질적으로 확률론적인 매체를 사용하여 복잡하고 신뢰할 수 있는 시스템을 구축하려고 시도하고 있다는 점입니다. "vibe-based" 프로토타입에서 프로덕션 수준의 소프트웨어로 넘어가기 위해서는, 로직을 산문(prose)에서 런타임으로 옮겨야 합니다.

"완벽한 프롬프트"의 오류

소프트웨어는 예측 가능한 동작을 제공하는 라이브러리, 모듈, 함수와 같은 재귀적 구성 가능성을 통해 확장됩니다. 이를 통해 로컬 추론(local reasoning)이 가능해집니다. 즉, 전체 시스템 상태를 머릿속에 담아둘 필요 없이 코드의 일부를 이해할 수 있는 능력입니다. 프롬프트 체인은 이러한 특성을 결여하고 있습니다. 이들은 비결정론적이며, 명세가 약하고, 검증하기가 매우 어렵기로 유명합니다.

명령문이 단순한 제안에 불과하고, 함수가 실제 결과를 환각(hallucination)하면서 "Success"를 반환하는 프로그래밍 언어를 상상해 보십시오. 그러한 언어에서는 추론이 불가능해지며 복잡성이 증가함에 따라 신뢰성이 무너집니다. 이것이 현재 많은 "agentic" 워크플로우의 상태입니다. 한 커뮤니티 구성원이 언급했듯이, LLM에서 결정론적 요소를 추출하려는 시도는 패배할 수밖에 없는 싸움입니다:

"LLM에서 신뢰성과 결정론을 얻으려고 노력한다면, 당신은 이미 패배한 것입니다."

로직을 런타임으로 이동하기

신뢰성은 결정론적 비계(scaffold)를 필요로 합니다. 에이전트에게 "워크플로우를 관리하라"고 요청하는 대신, 워크플로우는 소프트웨어로 인코딩되어야 하며, LLM을 시스템 자체가 아닌 하나의 구성 요소로 취급해야 합니다. 이는 명시적인 상태 전이(state transitions)와 검증 체크포인트를 구현하는 것을 의미합니다.

"Harness" 방식

몇몇 산업계의 사례는 이러한 전환의 성공을 강조합니다. 예를 들어, Stripe의 "Minions" 시스템은 비결정론적인 LLM 작업 간의 품질 보증을 처리하기 위해 결정론적 노드를 활용합니다. 마찬가지로, AI 코딩 어시스턴트의 획기적인 발전은 반드시 원시 지능의 도약이 아니라, 핵심 프로세스 실행을 프롬프트에서 harness로 옮긴 결과였습니다.

"thin harness" 또는 구조화된 워크플로우 엔진을 구현함으로써 개발자는 다음과 같은 몇 가지 중요한 목표를 달성할 수 있습니다:

  • 토큰 낭비 감소: LLM은 더 이상 워크플로우를 설명하는 방대한대한 시스템 프롬프트를 입력받을 필요가 없습니다. 특정 작업에만 집중하면 됩니다.
  • 실행 보장: 소프트웨어 오케스트레이터가 순서를 강제하기 때문에 단계를 "건너뛰거나" "잊어버릴" 수 없습니다.
  • 디버깅 용이성: 실패가 발생했을 때, 실패가 결정론적 라우팅에서 발생했는지 아니면 확률론적 생성에서 발생했는지 명확히 구분할 수 있습니다.

검증 격차

결정론적 오케스트레이션은 싸움의 절반에만 해당됩니다. 조용한 실패(silent failure)가 발생하기 쉬운 시스템에서, 공격적인 오류 탐지 기능이 없는 에이전트는 단순히 잘못된 결론에 도달하는 빠른 방법일 뿐입니다. 프로그래밍 방식의 검증 없이 개발자는 세 가지 최적화되지 않은 선택지 중 하나를 선택해야 합니다: 오류를 잡기 위해 지속적으로 "베이비시팅"을 하거나, 실행 후 철저한 사후 감사(audit)를 수행하거나, 단순히 출력값을 "vibe-accepting" 하는 것입니다.

토론에서 지적되었듯이, 많은 개발자들은 권한 레이어(에이전트가 무엇을 할 수 있는지)는 구축하고 있지만 검증 레이어(에이전트가 실제로 무엇을 했는지 증명하는 것)는 소홀히 하고 있습니다. 진정한 신뢰성은 다음의 조합에서 옵니다:

  1. 결정론적 제어 흐름: 경로를 정의함.
  2. 프로그래밍 방식의 검증: 출력값을 엄격한 규칙(예: linting, type-checking, 또는 unit tests)에 따라 검증함.
  3. Про러머빌리티(Observability): 로직이 정확히 어디서 벗어났는지 식별하기 위해 흐름을 자연스럽게 추적함.

반론 및 뉘앙스

결즘론적 방향으로의 추진은 강력하지만, 일부에서는 에이전트를 과도하게 제약하는 것이 LLM의 가치를 만드는 핵심적인 유연성을 제거할다고 주장합니다. "Rube Goldberg" 시스템—프롬프트가 대체한 프롬프트보다 유지보수가 더 어려운 과도하게 복잡한 결정론적 웹을 만드는 위험이 있습니다.

한 가지 제안된 절충안은 "Supervisor-Orchestrator-Worker" 패턴입니다. 이 모델에서는 supervisor가 루프를 관리하고, orchestrator가 작업을 위임하고 가드레일을 강제합니다. worker는 작업 단위를 실행합니다. 이는 높은 수준의 목표가 확률론적 드리프트(probabilistic drift)에 빠져 길을을 잃지 않도록 보장하면서도 적응성을 유지합니다.

결론: 에이전트 엔지니어링의 미래

우리는 제1원칙(first principles)으로의 회귀를 목격하고 있습니다. 초기 "prompt engineering"의 열풍 이후, 업계계는 전통적인 소프트웨어 엔지니어링의 가치치를 재발견하고 있습니다: 상태 머신(state machines), DAGs (Directed Acyclic Graphs), 그리고 엄격한 검증.

목표는 LLM의 창의성을 제거하는 것이 아니라, 그것을 제어하는 것입니다. 확률론적 엔진을 결정론적 harness를 통해 감싸는으로써, 우리는 데모에서만 인상적인 것이 아니라 프로덕션 환경에서 신뢰할 수 있는 에이전트를 구축할 수 있습니다.

Sources