해당글은 실제 현업에서 개발하면서 느낀 부분을 gpt랑 질문하며 정리한 글입니다. 할루시네이션이 있을수 있음을 인지 부탁드립니다.
리액트 방식의 문제점이라고 생각하는 부분
ReAct 방식의 검증된 한계점
- 반복 횟수 제한과 불완전한 종료
반복 횟수(max_iterations)를 설정해도 모델이 작업 완료를 인식하지 못하면 의미 없는 중간 결과가 반환되거나, "iteration limit" 오류로 조기에 멈추는 경우가 많다. LLM이 언제 결과를 최종화해야 할지 인지하지 못한 채 계속 추가 도구를 호출하는 현상 역시 대표적 위험이다. - 무한 루프 및 환각(Hallucination)
에이전트가 이미 수행된 도구 결과를 무시하고 반복하거나, 실제로 존재하지 않는 도구를 호출해 자기 내부 대화만 이어가는 현상이 발생한다. 특히 경량 또는 로컬 모델에서 이러한 루프와 환각이 심화되고, 프롬프트 해석 과정의 오류도 흔하다. - 토큰 비용 폭증
Reasoning → Acting → Observation 사이클마다 전체 컨텍스트를 반복적으로 LLM에 입력해야 하므로, 단순 질의 대비 3~5배 이상 토큰을 소모한다. 서비스 환경에서는 이 비용이 빠르게 증폭된다.
슈퍼바이저 패턴의 실전 문제점
- 컨텍스트 전파의 딜레마
모든 메시지를 하위 에이전트에 전달하면 정보량과 비용이 급증하고, 요약하면 중요한 문맥이 손실될 뿐 아니라 추가적인 LLM 호출 비용이 발생한다. 병렬로 작동하는 에이전트들 사이에서 컨텍스트 불일치로 인해 중복 작업 또는 모순된 결과가 생길 수 있다. - 라우팅 정확도 저하
에이전트가 늘어날수록 “다음에 어떤 에이전트에게 태스크를 배분”해야 할지 결정 오류가 자주 발생한다. 컨텍스트가 복잡할수록 분배와 추적 관리가 어려워지고, 계층형 슈퍼바이저 도입 시에도 복잡성과 비용이 올라간다. - 종료 조건의 불확실성
슈퍼바이저가 각 작업의 완료 시점을 확실히 판단하기 어렵고, 일부 하위 에이전트의 부분 성공이나 모호한 반환이 전체 플로우의 불안정성을 유발한다.
추가로 알려진 한계
- 도구 선택 비효율성
활용 가능한 도구가 많아지면 최적 도구 선택 오류로 불필요한 호출이 늘어나고, 실제 서비스 단위에서 큰 비용 이슈가 된다. - LLM 예측 불가능성
규칙 기반이 아니라 실시간 응답 생성으로, 결과의 정확성과 일관성을 보장하기 어렵고, 특히 자유 입력 환경에서는 이 문제가 심화된다. - 관찰성과 디버깅 한계
이상 결과나 오작동 원인을 효과적으로 추적하거나 복구하는 기능이 부족하다. 버전·상태 관리도 별도 설계가 필요하다. - API 불안정성 대응 부족
외부 시스템 오류, 대기 시간 지연 등 발생 시 자동 복구·재시도 로직이 부족해 운영 설계가 복잡해질 수 있다. - 병렬 실행 관리의 어려움
여러 도구를 동시 호출할 때 결과 동기화, 오류 처리 복잡도가 높고, 순차 실행 기반 구조에서는 병렬화 최적화가 제한적이다.
현실적인 완화 전략
- 프롬프트 간결화, 프롬프트 캐싱, 컨텍스트 축소 등으로 토큰 비용 절감
- 단순 작업과 고난이도 작업을 각각 경량/고성능 모델로 분리하는 모델 캐스케이딩
- 컨텍스트 구조화로 직전 결정만 전달하고 전체 기록은 별도 저장소로 분리하는 방식
- 각 에이전트의 단일 책임 설계로 혼란 방지 및 효율화
- 반복 횟수 이외 목표 달성 여부 확인, 특정 도구 호출 후 바로 종료 등 루프 방지 로직 추가
- 세션 체크포인팅과 재개 기능을 활용해 장기 작업의 운영성과 UX 향상
도메인/예시 없이, 위와 같은 형태로 ReAct 방식 및 슈퍼바이저 에이전트 패턴의 기술적 한계와 실전 대응 전략을 정리할 수 있다.아래는 ReAct 방식 및 멀티에이전트/슈퍼바이저 패턴의 구조적 한계와 실전 이슈를 특정 분야, 제품 이름 없이 정리한 글이다.
ReAct 방식의 검증된 한계점
- 반복 횟수를 지정해도 모델이 작업 완료를 인지하지 못하면 "중간 결과"나 "iteration limit" 오류가 발생한다. LLM이 최종 결과를 언제 생성해야 하는지 판단하지 못한 채 여러 번 도구 호출을 반복하는 경우도 흔하다.
- 에이전트가 같은 작업을 반복하거나, 실제로 없는 도구를 호출해서 내부 루프/환각(hallucination)이 발생한다. 경량 모델이나 로컬 모델을 쓸 때 이런 현상이 더 자주 나타난다.
- Reasoning → Acting → Observation의 반복에서 전체 컨텍스트가 계속 LLM에 전달되어 토큰 비용이 기하급수적으로 커진다. 실제 서비스 환경에서는 단순 질의 대비 3~5배까지 토큰이 발생할 수 있다.
슈퍼바이저 패턴의 실전 문제점
- 컨텍스트 전파 딜레마로, 에이전트 간에 전체 메시지를 공유할수록 노이즈와 운영 비용이 늘고, 요약하면 중요한 정보가 누락되고 추가 LLM 호출이 필요해진다. 병렬 에이전트 간 컨텍스트 불일치 때문에 중복 작업이나 논리 충돌도 생긴다.
- 슈퍼바이저가 관리하는 에이전트 수가 많아질수록 다음에 어떤 에이전트를 호출해야 할지 불확실성이 증가한다. 복잡한 컨텍스트에서는 분배/관리의 정확도가 급격히 저하되는 케이스가 많다.
- 언제 작업이 완료되는지, 어떤 조건에서 플로우를 끝내야 하는지 명확히 판단하기 어렵다. 하위 에이전트가 모호한 결과를 내면 추가 결정이 불안정해진다.
추가로 널리 보고되는 문제점
- 도구가 늘어나면 최적 선택 오류, 중복 호출 등 운영 비효율성이 심각해진다.
- LLM은 규칙 기반 소프트웨어와 달리 결과 예측 불가능성이 높으며, 자유 입력과 동적 환경에서는 그 영향이 더욱 커진다.
- 에이전트의 잘못된 행동이나 결정을 추적/디버깅하는 과정이 부족하다. 상태와 버전 관리 등은 별도 설계가 필요하다.
- 외부 API가 실패하거나 지연될 때, 재시도/fallback 로직이 부족하며 전체 설계 복잡도가 늘어난다.
- 여러 도구를 동시에 호출할 때 동기화나 실패 처리가 어려워지고, 순차 실행 기반 구조에서는 병렬 처리에 제한이 많다.
현실적 완화 전략
- 프롬프트 간결화, 캐싱, RAG 기반 컨텍스트 관리로 토큰 비용을 절감
- 간단 작업과 복잡 작업을 경량/고성능 모델로 분리하는 모델 캐스케이딩 적용
- 슈퍼바이저와 하위 에이전트 간에는 이전 결정만 구조화해 전달하고, 전체 기록은 별도 저장소에 집중
- 각 에이전트에 단일 책임만 부여하여 혼란과 비효율을 방지
- 반복 횟수·목표 확인·특정 도구 호출 후 즉시 종료 등 명시적 루프 방지 로직 마련
- 체크포인트 기능과 세션 복원으로 장기 작업·이탈 후 재개를 지원하고 운영성을 높임
요구사항과 외부 API가 명확히 정의된 도메인 특화 서비스에서는 ReWOO/Plan-and-Execute 방식이 훨씬 합리적이다.
워크플로우 접근이 적합한 이유
도메인 특화성은 범용 챗봇과 달리 명확한 태스크 흐름이 존재하는 서비스의 핵심 장점이다. Anthropic의 공식 가이드도 "tasks with clearly defined workflows should use structured approaches, not open-ended agent loops"라고 명시한다.
토큰 효율성은 서비스 경제성의 생명줄로, ReWOO가 ReAct 대비 64~80% 토큰 절감과 4.4% 정확도 향상을 달성했다는 연구 결과가 있다. HotpotQA 벤치마크에서 ReWOO는 2,000 토큰으로 42.4% 정확도를 달성한 반면, ReAct는 9,795 토큰으로 40.8% 정확도를 기록했다.
통제 가능성은 지적한 대로 핵심 차별점으로, LangGraph의 명시적 그래프 구조는 "even if your LLM tries to go rogue, the graph won't allow it"라는 강제력을 제공한다. 워크플로우는 각 노드의 입출력을 테스트하고 로깅할 수 있어 프로덕션 신뢰성이 훨씬 높다.
병렬 실행은 계획된 작업의 최대 강점으로, 의존성 없는 작업들을 동시에 수행할 수 있다. ReAct는 순차 실행만 가능하지만, ReWOO는 플레이스홀더로 병렬 처리를 구현한다.
Orchestrator-Worker 패턴의 검증된 효과
슈퍼바이저 기반 아키텍처는 실제로 "separate concerns by role"이 프로덕션 안정성의 핵심이라는 Azure와 LangChain의 공식 권장사항이다. 각 전문 에이전트가 단일 책임만 수행하면 디버깅과 최적화가 명확해진다.
컨텍스트 최소화 전략은 하위 에이전트에게 전체 대화가 아닌 구조화된 상태만 전달하는 방식이다. LangGraph의 TypedDict State는 이런 구조를 강제해 "노이즈 없는 컨텍스트"를 보장한다.
계획 취합 노드는 Plan-and-Execute의 Solver 단계에 해당하며, 각 하위 에이전트의 결과를 종합해 최종 응답을 생성한다. 이 단계만 고성능 LLM을 사용하고 나머지는 경량 모델이나 확정적 함수를 쓰면 비용과 품질을 동시에 확보한다.
웰노운 워크플로우 패턴
Orchestrator-Worker Pattern은 중앙 오케스트레이터가 작업을 분해하고 전문 워커에게 배분한 뒤 결과를 취합하는 방식으로, "most useful for tasks requiring structured approach and careful planning"에 해당한다.
Prompt Chaining with Parallelization은 LangChain이 공식 제시한 첫 번째 워크플로우 패턴으로, 단계별 프롬프트를 체인으로 연결하되 독립 작업은 병렬 실행한다.
Evaluator-Optimizer Loop는 생성된 결과를 평가하고 기준 미달 시 재시도하는 패턴으로, 결과물이 제약조건을 만족하지 못하면 다시 검색하는 로직에 적용할 수 있다.
현실적인 한계 인정의 중요성
**"완벽한 답은 못 만들어도 통제 가능"**이라는 표현이 프로덕션의 본질을 정확히 짚었다. 워크플로우는 "보장된 실행 순서"를 제공하지만 각 단계의 LLM 출력 품질은 여전히 확률적이므로, 출력 검증과 fallback 로직이 필수다.
Structured Output Enforcement는 각 노드의 출력을 Pydantic 스키마로 강제해 다음 노드가 항상 예측 가능한 입력을 받도록 하는 기법으로, Anthropic과 OpenAI 공식 가이드에서 강력히 권장한다.
Explicit Planning Transparency는 사용자가 진행 상황을 볼 수 있도록 하는 것으로, 신뢰도와 UX를 동시에 향상시킨다.
구현 시 핵심 권장사항
노드별 책임 명확화는 각 노드가 하나의 도구나 하나의 판단만 수행하도록 설계하는 것으로, 각각 독립적으로 테스트하고 교체할 수 있다.
조건부 라우팅은 LangGraph의 conditional_edges로 구현하며, 상황에 맞는 경로를 선택한다. ReAct의 무한 루프 위험 없이 명확한 분기를 제공한다.
체크포인팅과 재개는 LangGraph의 핵심 기능으로, 사용자가 이탈했다가 나중에 재개할 수 있도록 지원한다.
도구 실패 처리는 ReWOO가 ReAct보다 우수한 영역으로, 계획 단계에서 이미 모든 도구 호출을 명시했으므로 실패 시 재시도나 대체 도구 선택을 체계적으로 수행할 수 있다.
제안한 아키텍처는 "명확한 요구사항 + 정의된 툴 + 전문 에이전트 + 병렬 실행 + 중앙 취합"이라는 Plan-and-Execute의 이상적 사용 케이스이며, 실제 프로덕션 배포 시 토큰 비용과 신뢰성 측면에서 ReAct보다 압도적으로 유리하다.
그래서 정말 리콰이어먼트가 없는 그런 에이전틱한 ai를 만들때에는 리액트 방식이 조금 나을수도 있겠으나...에이전틱ai는 리액트 방식을 넘어서 정말 ai가 발전해야하며, 대부분의 프로덕션에서 목적성이 있는 서비스는 rewoo가 낫지 않을까 싶다.
'AI' 카테고리의 다른 글
| 벡터디비 및 임베딩 관련 글 (0) | 2025.10.02 |
|---|---|
| [devopsTool] K6 MCP설계 (0) | 2025.05.09 |
| [devopsTool] 기본적인 구조 (0) | 2025.05.02 |
| [devopsTool] k6, argocd 시나리오 수립 (0) | 2025.04.20 |
| [Agentic AI] 랭그래프 기반 개발을 해보며 생각한 것들 (개인 생각 정리 공간) (1) | 2025.04.19 |
