AX LABS
← 블로그 에이전트 제품 설계

ReAct만으로 운영은 안 돈다

에이전트는 추론 패턴이 아니라 실행 시스템이다

AX LABS 5분 읽기

현장에서 에이전트 PoC를 보면 처음에는 모두 비슷하게 움직인다. 사용자가 지시하고, 모델이 생각하고, 도구를 호출하고, 결과를 보고 다시 움직인다. 데모는 된다. 문제는 실제 업무에 붙이는 순간부터다. 같은 요청이 반복 실행되고, 권한이 모호한 도구를 건드리며, 중간 상태를 잃고, 실패 원인이 로그에 남지 않는다.

이때 필요한 것은 더 긴 프롬프트가 아니다. ReAct를 감싸는 실행 아키텍처다. 2026년 현재 주요 SDK도 같은 방향으로 움직인다. OpenAI Agents SDK는 tracing, guardrails, handoffs를 실행 단위로 다루고, Claude Agent SDK는 PreToolUse·PostToolUse 같은 hook으로 도구 호출 전후를 제어한다. Google ADK도 multi-agent orchestration, graph-based workflows, evaluation, deployment를 한 묶음으로 제시한다.

ReAct는 사고 방식이고 제어 루프는 운영 방식이다

ReAct는 모델에게 “생각하고 행동하고 관찰하라”는 기본 리듬을 준다. 그러나 기업 업무는 리듬만으로 돌아가지 않는다. 누가 승인했는지, 어떤 데이터가 들어갔는지, 어느 도구가 어떤 권한으로 실행됐는지, 실패 후 어디서 재개할지가 정해져야 한다.

에이전트 설계의 핵심은 모델이 똑똑하게 말하게 만드는 것이 아니라, 모델이 실행할 수 있는 범위를 구조적으로 좁히는 것이다.

그래서 제어 루프는 최소한 네 층으로 나뉜다.

층 설계 질문 산출물
의도 해석 이 요청은 실행 가능한 업무인가 task contract
계획 어떤 순서로 움직일 것인가 plan graph
실행 어떤 도구를 어떤 조건에서 부를 것인가 tool policy
관찰·복구 실패와 중간 상태를 어떻게 남길 것인가 trace, checkpoint

ReAct는 이 표의 일부다. 운영 에이전트는 표 전체다.

도구 호출은 자유가 아니라 허가의 문제다

에이전트가 위험해지는 지점은 답변 생성이 아니라 도구 호출이다. 메일 발송, CRM 수정, 코드 배포, 결재 문서 생성은 모두 외부 상태를 바꾼다. “모델이 알아서 판단한다”는 말은 운영 통제 문장으로 쓸 수 없다.

최근 SDK들이 hook, guardrail, MCP 같은 구조를 전면에 둔 이유가 여기에 있다. Claude Agent SDK 문서는 도구 호출 직전 PreToolUse, 호출 직후 PostToolUse, subagent 시작·종료 같은 이벤트를 hook으로 가로챌 수 있다고 설명한다. OpenAI Agents SDK 문서는 agent run 중 LLM generation, tool call, handoff, guardrail, custom event를 tracing 대상으로 기록한다고 설명한다.

AX LABS가 보는 운영형 도구 정책은 세 가지로 나뉜다.

  1. 읽기 도구와 쓰기 도구를 분리한다.
  2. 쓰기 도구는 dry-run, 승인, 실행을 분리한다.
  3. 외부 시스템 연결은 MCP 같은 표준 인터페이스로 감싸되, 권한 정책은 별도로 둔다.

MCP는 도구 연결의 표준화에 가깝다. 통제의 표준화는 아니다. 연결이 쉬워질수록 허가와 감사는 더 명시적으로 설계해야 한다.

실행 아키텍처는 그래프와 로그로 남아야 한다

실제 업무는 선형 대화가 아니다. 고객 문의 하나에도 조회, 분류, 정책 확인, 초안 작성, 승인 요청, 시스템 반영이 섞인다. 이 흐름을 하나의 프롬프트 안에 넣으면 재현성이 사라진다.

운영 에이전트는 plan graph를 가져야 한다. 각 노드는 입력, 출력, 허용 도구, 실패 조건, 재시도 조건을 가진다. 모델은 모든 것을 결정하지 않는다. 모델은 노드 안에서 판단하고, 루프는 노드 밖에서 실행을 통제한다.

이 구분이 생기면 평가도 달라진다. “답이 그럴듯한가”가 아니라 “정해진 경로에서 벗어나지 않았는가”, “위험 도구 호출 전에 멈췄는가”, “실패 후 같은 상태에서 재개되는가”를 본다. Google ADK가 graph-based workflows와 performance evaluation을 함께 언급하는 것도 같은 맥락이다.

ReAct 이후의 설계는 모델 선택 경쟁이 아니다. context engineering, memory 전략, tool orchestration, AgentOps를 하나의 harness로 묶는 일이다. 에이전트의 품질은 모델 단독 성능보다 실행 하네스의 품질에 더 크게 좌우된다.

참고와 다음 행동은 설계 문서로 남긴다

이 글의 기준일은 2026-06-08이다. 아래 자료는 최근 12개월 이내 확인 가능한 공식 문서와 1차 자료를 중심으로 보았다.

정리하면, ReAct는 에이전트의 언어다. 운영은 제어 루프, 권한, 관찰성, 복구 설계로 완성된다. AX LABS는 이 설계를 PoC 이후가 아니라 첫 킥오프에서부터 잡는다. 에이전트를 실제 업무에 붙이려면 먼저 실행 루프를 설계해야 한다: AX Ops 방법론 →