에이전트 워크플로우와 JSON의 함정: 백엔드 엔진으로 LLM이 적절한가?
Agentic workflows and the JSON trap: are we using the wrong engine for the backend?
핵심 요약
LLM을 결정론적 엔진처럼 쓰려는 시도의 한계를 지적하며, 의도 파악은 LLM이, 로직 검증은 비확률적 솔버가 담당하는 아키텍처를 제안함.
- 구조적 취약성 — LLM의 확률적 특성으로 인해 복잡한 에이전트 체인이 쉽게 붕괴됨.
- 의도 파악 분리 — LLM은 의도 해석에만 집중하고 로직 검증은 결정론적 솔버에 위임하는 방식 제안.
- 프롬프트 한계 — 프롬프트 엔지니어링만으로 복잡한 로직을 제어하는 것은 근본적인 한계가 있음.
- 생산 환경 고려 — 실제 프로덕션 환경에서는 확률적 예측보다 물리적 제약이 보장되는 솔버가 필수적임.
우리는 확률적 텍스트 생성기가 엄격한 결정론적 규칙 엔진처럼 행동하도록 강요하는 데 실제로 얼마나 많은 시간을 쓰고 있을까요?
최근 복잡한 멀티 에이전트 체인을 구축하고 있는데, 솔직히 구조적인 취약성 때문에 지쳐가고 있습니다. 우리는 작업을 라우팅하고, 출력을 검증하고, 정확한 도구 호출을 실행하기 위해 LLM에 의존합니다. 하지만 근본적인 수준에서 모델은 여전히 다음 토큰을 추측할 뿐입니다. 아무리 많은 방어적 프롬프트 레이어나 출력 파서를 덧씌워도, 확률 분포가 조금만 바뀌면 환각된 변수나 깨진 스키마 때문에 전체 체인이 붕괴됩니다.
프롬프트 엔지니어링에 의존해 로직 오류를 수정하려는 현재의 메타는 고위험 라우팅에 있어 근본적으로 결함이 있다고 느껴집니다. 저는 Logical Intelligence의 에너지 기반 솔버 접근 방식처럼 엄격한 제약 만족을 처리하는 대안 아키텍처를 살펴보고 있으며, 이는 우리의 표준 스택을 다시 생각하게 만듭니다.
언어 모델이 엄격한 조건부 로직을 '생각'하게 강요하고 유효한 구문을 출력하기를 바라는 대신, 아마도 우리의 체인은 LLM을 순수하게 의도 파악용으로만 사용해야 할지도 모릅니다. 의도가 포착되면, 실제 추론과 검증은 즉시 구조적 오류를 환각할 수 없는 비자기회귀적(non-autoregressive) 솔버로 넘겨야 합니다. 우리는 트랜스포머에게 애초에 설계되지 않은 일을 시키고 있는 것일지도 모릅니다.
