AI 에이전트가 말을 안 들을 때 개발자들이 가장 먼저 하는 일은 프롬프트를 고치는 것이다. 지시를 더 명확하게, 더 강하게, 더 길게. “반드시 이 단계를 건너뛰지 마세요”라는 문구가 프롬프트 곳곳에 박힌다. 그런데 어느 순간 그것도 소용이 없어진다.
소프트웨어 엔지니어 Brandon Suh가 최근 올린 글 “Agents need control flow, not more prompts”는 이 막힌 천장을 정면으로 다룬다. 그의 주장은 단순하다. 복잡한 작업을 안정적으로 수행하는 에이전트를 만들려면, 점점 정교해지는 프롬프트 체인보다 소프트웨어에 명시적으로 인코딩된 제어 흐름(Control Flow)이 필요하다는 것이다.
“MANDATORY”, “DO NOT SKIP” 같은 강조 문구를 프롬프트에 반복해서 쓰고 있다면, 그건 프롬프팅의 한계에 다다랐다는 신호다. 프롬프트로 구성된 에이전트 파이프라인은 본질적으로 비결정론적이고, 사양이 약하며, 검증하기 어렵다. 모델이 단계를 건너뛰어도, 잘못된 형식으로 응답해도, 조용히 실패해도 — 파이프라인은 그냥 계속 돌아간다. 오류가 번지고 있다는 사실조차 알아채기 어렵다.
Suh는 프로그래밍 언어와 대조한다. 코드에서 if 문은 “제안”이 아니다. 함수가 성공을 반환하면서 동시에 환각(hallucination) 상태일 수는 없다. 소프트웨어의 힘은 재귀적 구성 가능성(recursive composability)에 있다. 작은 단위들이 예측 가능한 방식으로 결합되고, 각 부분은 독립적으로 추론하고 검증할 수 있다. 프롬프트 체인에는 이 성질이 없다. 복잡도가 올라갈수록 신뢰성은 떨어진다.
이미지 출처: Unsplash
그가 제시하는 오류 관리 전략 세 가지는 현재 AI 에이전트 개발의 현실을 꽤 정확하게 묘사한다. 첫째는 ‘베이비시터(Babysitter)’ — 인간이 루프에 직접 참여해 오류가 번지기 전에 개입하는 방식이다. 둘째는 ‘감사자(Auditor)’ — 전체 실행이 끝난 뒤 결과를 철저히 검증하는 방식이다. 셋째는 ‘기도(Prayer)’ — 그냥 잘 되기를 바란다. 풍자적 표현이지만, 실제 프로덕션 에이전트 중 상당수가 세 번째 방식으로 운영되고 있다.
해결책으로 그가 제시하는 것은 결정론적 스캐폴딩(deterministic scaffolding)이다. 명시적인 상태 전환과 검증 체크포인트를 코드로 구현하고, LLM을 시스템 전체를 관장하는 오케스트레이터가 아니라 시스템의 한 컴포넌트로 취급하는 방식이다. LLM이 텍스트를 생성하면, 그 결과를 코드가 검증하고, 다음 단계로 넘길지 말지를 결정론적으로 판단한다. 에이전트가 “생각”하는 부분과 “실행”하는 부분을 분리하는 것이다.
이 관점은 최근 에이전트 프레임워크 설계에서 점점 주류가 되어가는 방향이기도 하다. LangGraph, LlamaIndex Workflows 같은 도구들이 명시적인 상태 머신(state machine)과 제어 흐름을 강조하는 방향으로 발전하고 있는 것, Google의 에이전트 관련 논문에서 “orchestrator-worker” 구조가 반복적으로 등장하는 것도 같은 맥락이다. 프롬프트로 모든 것을 해결하려는 1세대 에이전트 설계에서, 소프트웨어 엔지니어링의 원칙을 다시 끌어오는 2세대 설계로 무게중심이 이동하고 있다.
결국 이 글이 말하고자 하는 바는, AI 에이전트가 성숙해질수록 “어떻게 프롬프트를 잘 쓸 것인가”보다 “어떻게 시스템을 잘 설계할 것인가”가 더 중요한 질문이 된다는 것이다. LLM은 강력하지만, 신뢰할 수 있는 시스템을 만드는 일은 결국 소프트웨어 설계의 문제다. 프롬프트를 더 길게 쓰는 것으로는 도달할 수 없는 지점이 있다.
출처