Agents에는 더 많은 프롬프트가 아니라 제어 흐름이 필요하다

Agents에는 더 많은 프롬프트가 아니라 제어 흐름이 필요하다

최근 AI 에이전트 개발 커뮤니티에서 급속히 퍼지고 있는 통찰이 있다. "더 강력한 프롬프트를 만들어야 한다"는 오래된 접근 방식의 한계가 본격적으로 드러나고 있는 것이다. 복잡한 작업을 수행하는 신뢰할 수 있는 에이전트를 구축하려면, 정교한 프롬프트 체인이 아니라 소프트웨어에 인코딩된 결정적 제어 흐름이 필요하다는 주장이 힘을 얻고 있다.

프롬프트의 한계에 도달한 순간

AI 에이전트 개발자라면 한 번쯤 경험해 봤을 것이다. 태스크가 복잡해질수록 프롬프트를 아무리 정교하게 만들어도 신뢰성이 떨어지는 현상. "MANDATORY", "DO NOT SKIP" 같은 지시를 프롬프트에 추가하기 시작했다는 것은 이미 프롬프트 엔지니어링의 한계에 도달했다는 신호다.

Brian의 블로그에 따르면, 이 문제는 구조적인 한계에서 비롯된다. 프로그래밍 언어를 생각해 보자. 각 문장이 권고에 불과하고 함수가 "성공"이라고 출력하면서도 내용을 그르친다면? 추론 자체가 불가능해지고, 복잡성이 증가할수록 신뢰성은 붕괴한다. 소프트웨어가 확장 가능한 이유는 라이브러리, 모듈, 함수를 통해 재귀적으로 조합 가능하기 때문이다. 코드는 예측 가능한 동작을 노출하고 지역적 추론을 가능하게 한다.

그런데 프롬프트 체인은 이 속성을 갖지 못한다. 좁은 범위의 태스크에는 유용하지만, 본질적으로 비결정적이며 약하게 명시되어 있고 검증하기 어렵다.

결정적 제어 흐름이 답이다

신뢰할 수 있는 에이전트를 만들려면 논리를 산문에서 런타임으로 이동해야 한다. LLM을 프롬프트의 주체가 아니라 시스템의 구성 요소로 취급하는 것이다.

LangGraph가 이 접근의 선구자다. 에이전트 워크플로우를 상태 저장 그래프로 취급한다. 그래프의 노드는 "데이터 추출", "데이터베이스 쿼리" 같은 개별 함수를 나타내고, 엣지는 노드 간의 명시적 전환을 정의한다. 전환은 LLM의 일정에임유되지 않고, 논리적 조건, 도구 출력 또는 명시적 상태 변경에 의해 결정된다.

from langgraph.graph import StateGraph, ENDdef extract_data(state):# 데이터 추출 LLM 호출return {"data": "extracted_info"}def query_database(state):# 데이터베이스 쿼리 도구 호출return {"results": "db_results"}def generate_report(state):# 요약 LLM 호출return {"report": "final_summary"}builder = StateGraph(AgentState)builder.add_node("extract_data", extract_data)builder.add_node("query_database", query_database)builder.add_node("generate_report", generate_report)builder.set_entry_point("extract_data")builder.add_edge("extract_data", "query_database")builder.add_edge("query_database", "generate_report")builder.add_edge("generate_report", END)graph = builder.compile()

이 코드는 함수를 체인으로 연결하는 것 이상이다. LLM을 강력하지만 경계된 추론 엔진으로 Embedding하고, 강력한 소프트웨어 스택 안에 배치하는 것이다.

감시가 없는 에이전트는 빠른 Wrong 결론 도달료

결정적 오케스트레이션은 전설의 절반에 불과하다. 실패할 수 있는 시스템에서 에이전트가 적극적 오류 감지를 갖추지 않으면, 그건 그냥 잘못된 결론에 빠르게 도달하는 빠른 방법일 뿐이다.

프로그래밍적 검증 없으면 세 가지 선택지만 남는다:

• Babysitter: 전파되기 전에 인간이 에러를 감지하기 위해 루프에 머무름

• Auditor: 실행 후 철저한 종단 간 검증 수행

• Prayer: 출력을 그냥 vibes로 수락

세 가지 모두 비효율적이다. 검증 체크포인트와 명시적 상태 전환을 갖춘 에이전트 아키텍처가 필요하다.

자연어 Meets 구조적 실행

자연어를 에이전트 개발에서 완전히Eliminate하려는 것이 아니다. 구조적 프로세스를Guidance하기 위해Leverage하는 것이다. AutoGen의 GraphFlow는 "대화형 프로그래밍" 패러다임을 도입했다. 자연어가 워크플로를Steer할 수 있지만, 도구 실행, 종료 조건, 복잡한 의사 결정 같은 중요한 접점에서는 명시적 코드가 개입한다.

이 접근은 순차적, 병렬적, 조건부, 루핑 동작을 허용하며, 모두 유향 그래프(Digraph)로 관리된다. LLM이 대화에 기반해 다음 단계를 제안할 수 있지만, 프레임워크가 그 단계가 올바른 도구를 사용하고 상태 전환을 올바르게 처리하도록 보장한다.

Mastra와 Arazzo 같은 프레임워크도 이 트렌드를 강화한다. 명시적 제어를 강조하는 유형화되고 검증 가능한 워크플로를 제공한다.

제어 흐름 프레임워크 비교

프레임워크	접근 방식	제어 흐름 유형	검증 가능성
LangGraph	상태 저장 그래프	노드-엣지 기반	높음
AutoGen GraphFlow	대화형 프로그래밍	Hybrid DiGraph	중간
Mastra	Typed 워크플로	명시적 타입	높음
Arazzo	명시적 오케스트레이션	규칙 기반	높음

결론: 제어 흐름의 시대

프롬프트에 모든 것을기탁하려는 현재의집착은위험적 환상이다. 명시적 제어 흐름 없이 에이전트는취약하다. 잘못된 출력을 생성하고, 데이터를 손실하며, 규정 준수 규정을 위반할 수 있다. 이는 사소한 불편함이 아니라 실제 배포를 위한 시스템의 중요한 실패 지점이다.

업계의 합의가 굳어지고 있다. LLM은 강력하지만 본질적으로 확률적인 구성 요소로, 결정적 소프트웨어 아키텍처 내에서 활용하는 것이 가장 효과적이다. 복잡하고 임무 중요한 태스크에 필요한 신뢰성, 확장성, 검증 가능성은 순수 프롬프팅으로는 보장할 수 없다.

신뢰성이 복잡성과 함께 무너질 때, 더 나은 프롬프트를 찾지 못한 것이 아니라 프롬프트 기반 상호작용의 한계에 도달한 것이다. 제어 흐름을 Embracing할 때다.

핵심 요약

1. 프롬프트의 한계: 복잡한 태스크에서 프롬프트 체인은 비결정적이고 검증하기 어렵다

2. 제어 흐름의 필요성: LLM을 시스템의 구성 요소로 취급하고, 소프트웨어로 제어 흐름을 인코딩한다

3. 그래프 기반 아키텍처: LangGraph, AutoGen GraphFlow 등이 상태 저장 그래프로 신뢰성 있는 에이전트를 구축한다

4. 검증 체크포인트: Silent 실패를 방지하기 위해 프로그래밍적 검증이 필수적이다

5. 하이브리드 접근: 자연어의 유연성과 소프트웨어의 예측 가능성을 결합한다

AI 에이전트의 다음 단계는 더 정교한 프롬프팅이 아니라 더 강력한 제어 흐름 아키텍처다. 개발자라면 이 변화를 선제적으로 받아들여야 한다.

---

이 글은 2026년 5월 최신 AI 에이전트 개발 트렌드를 바탕으로 작성되었습니다.

---

📚 출처

• https://news.hada.io/topic?id=29296