3줄 요약
- 이 글은 Oracle의 AI Developer Advocate인 Casius Lee가 2026년 3월 16일에 쓴 아키텍처 해설로, 챗봇과 에이전트를 가르는 것은 모델의 능력이 아니라 단 하나의 구조 — LLM이 도구를 부르며 완료될 때까지 반복하는 while 루프 — 라는 데서 출발한다.
- 에이전트 루프는 인지(Perceive) → 추론(Reason) → 계획(Plan) → 실행(Act) → 관찰(Observe) 다섯 단계가 닫힌 원을 이루며 도는 사이클이고, OpenAI·Anthropic·Google·Microsoft·Meta·LangChain이 이름과 SDK는 달라도 똑같은 실행 패턴으로 수렴했다.
- 컨트롤된 환경에서 잘 돌던 루프는 프로덕션에서 두 가지 제약에 부딪힌다 — 비용(에이전트는 일반 챗 대비 약 4배, 멀티에이전트는 약 15배의 토큰을 쓴다)과 관측가능성(20번 반복하며 8개 도구를 부른 실행을 추적·재현·해석할 수 있는가). 그리고 정지 조건이 없는 루프는 루프가 아니라 영수증이다.
이 글은 “루프 엔지니어링” 연재의 세 번째 편이다. 1편(Addy Osmani)과 2편(Firecrawl)이 “에이전트를 프롬프트하지 말고 루프를 설계하라"는 실무자·제품 관점에서 출발했다면, 이번 Oracle 글은 한 칸 아래로 내려가 “그래서 그 루프란 대체 무엇인가"를 아키텍처의 언어로 정의한다. 앞 두 편이 루프를 어떻게 쓰는가를 말했다면, 이 글은 루프가 무엇으로 이루어져 있는가를 말한다.
챗봇과 에이전트를 가르는 한 줄
저자는 익숙한 장면에서 시작한다. 챗봇을 만들었고, 잘 돌아간다. 사용자가 묻고, 답이 생성되고, 상호작용이 끝난다. 그런데 누군가 한 번에 끝나지 않는 일을 시킨다.
“다음 달 도쿄행 항공권 중 가장 싼 세 개를 찾고, 내 적립 포인트로 그중 무엇을 살 수 있는지 확인한 다음, 가장 나은 걸 예약해 줘.”
챗봇은 이 일을 진행할 방법이 없다. 답을 하나 생성하고 멈춘다. 항공권에 대해 설명할 수는 있어도 워크플로를 실행하지는 못한다. 각 프롬프트가 고립되어 처리되고, 지속되는 맥락도, 중간 결과에 대한 접근도, 단계를 가로질러 결정을 이어 가는 능력도 없기 때문이다.
저자가 분명히 하는 지점은, 이것이 모델의 한계가 아니라는 것이다. ChatGPT도 Claude도 Gemini도 여러 단계의 문제를 추론할 능력은 있다. 한계는 아키텍처에 있다. 챗봇은 응답하도록 만들어졌고, 에이전트는 행동하도록 만들어졌다. 그 차이는 단 하나, while 루프다.
에이전트 루프의 정의
저자가 내놓는 정의는 이렇다. 에이전트 루프란 모든 에이전트형 AI 시스템의 핵심에 있는 반복 실행 사이클이다. 매 반복마다 에이전트는 가용한 입력에서 맥락을 조립하고, LLM을 불러 추론하고 행동을 고르며, 그 행동을 실행하고, 결과를 관찰한 뒤, 그 관찰을 다음 반복으로 되먹인다. 이 과정이 작업이 끝나거나 정해진 정지 조건에 닿을 때까지 반복된다.
Oracle이 함께 일하는 엔지니어링 팀들에서 작동하는 프로토타입과 프로덕션급 시스템을 일관되게 가르는 단 하나의 패턴이 바로 이 루프라고 저자는 말한다. 언어 모델을 텍스트 생성기에서, 행동을 취하고 결과에 적응하며 여러 단계의 작업을 자율적으로 완수하는 무언가로 바꿔 놓는 아키텍처다.
단일 패스가 벽에 부딪히는 이유
표준 챗봇 상호작용은 단순하다. 사용자가 메시지를 보내고, 모델이 답을 생성하면, 끝이다. 입력 하나, 출력 하나, 턴 사이에 상태 없음. 질의응답·요약·창작에는 훌륭하게 작동하지만, 모델이 현실 세계에서 무언가를 해야 하는 순간 무너진다. 저자는 단일 패스 응답의 근본 제약 세 가지를 든다.
- 결과 위에서 반복할 수 없다. 한 턴 안에서 도구를 한 번 부를 수는 있어도, 그 행동이 성공했는지 평가하거나 결과에 적응하거나 후속 결정을 이어 갈 메커니즘이 없다. 피드백 루프가 없다.
- 실패에서 복구할 수 없다. 반복 실행이 없으면, 실패한 도구 호출이나 빈 결과나 모호한 API 응답이 전략 수정을 촉발하지 못한다. 모델은 하류의 결과를 들여다볼 시야가 없다.
- 의존적인 작업을 분해할 수 없다. 현실의 워크플로는 정보를 모으고, 그걸 바탕으로 결정하고, 행동하고, 그 결과를 처리하기를 요구한다. 각 단계가 앞 단계의 결과에 의존한다. 그건 직선이 아니라 루프다.
저자는 30년 묵은 정의를 끌어온다. Russell과 Norvig는 1995년에 에이전트를 “센서를 통해 환경을 인지하고 액추에이터를 통해 환경에 작용하는 것"으로 규정했다. 핵심 단어는 응답이 아니라 작용이다. 그리고 이를 LLM에서 실용적으로 만든 것이 Princeton과 Google Research의 ReAct 프레임워크(Yao et al., 2022)다. 추론과 행동을 하나의 프롬프트 주도 루프 안에서 교직했더니, 모델이 추론하고·행동하고·관찰하고·다시 추론할 수 있을 때 ALFWorld에서 34%, WebShop에서 10% 성능이 올랐다. 단일 패스는 아키텍처적으로 제약일 뿐 아니라, 측정 가능한 성능을 테이블 위에 그냥 남겨 둔다.
다섯 단계의 멘탈 모델
에이전트 루프는 작업이 끝나거나 정지 조건에 닿을 때까지 반복되는 다섯 단계로 작동한다.
| 단계 | 하는 일 |
|---|---|
| Perceive (인지) | 입력을 받는다. 사용자 메시지일 수도, API 응답일 수도, 에러일 수도, 직전 행동의 결과일 수도 있다. |
| Reason (추론) | LLM이 맥락의 모든 것을 처리하고 다음에 무엇을 할지 결정한다. |
| Plan (계획) | 복잡한 작업이면 목표를 개별 하위 작업으로 분해한다. 단순한 워크플로는 이 단계 없이 곧장 실행으로 간다. |
| Act (실행) | 무언가를 실행한다 — 도구 호출, API 요청, DB 질의, 코드 실행. |
| Observe (관찰) | 결과를 살핀다. 잘 됐는가? 작업이 끝났는가? 계획을 조정해야 하는가? |
그리고 다시 1단계로 돌아간다. 의사코드로 줄이면 전체 패턴은 여섯 줄로 수렴한다.
while not done:
response = call_llm(messages)
if response has tool_calls:
results = execute_tools(response.tool_calls)
messages.append(results)
else:
done = True
return response
이 여섯 줄이 현재 프로덕션에 올라간 모든 자율 AI 시스템의 바탕이다. Anthropic의 엔지니어링 팀은 이를 직설적으로 표현한다. “에이전트는 정교한 작업을 다룰 수 있지만 그 구현은 종종 단순하다. 대개는 그저 환경 피드백에 기반해 루프 안에서 도구를 쓰는 LLM이다.”
루프가 답이 아닐 때
저자는 균형추도 분명히 둔다. 에이전트 루프가 모든 경우에 맞는 아키텍처는 아니다. 루프는 필요한 단계 수를 미리 예측할 수 없고, 중간 결과에 따라 적응해야 하며, 지연 비용이 작업 완료의 가치에 비해 받아들일 만한 작업에 적합하다. 반대로 고정되고 예측 가능한 순서를 따르는 워크플로는 결정론적 파이프라인이 낫고, LLM 호출 한 번과 도구 호출 한 번으로 끝나는 단일 단계 작업은 루프의 오버헤드에서 얻을 게 없다. OpenAI와 Anthropic의 공개 가이드가 한목소리로 말하는 원칙은 이것이다 — 문제를 푸는 가장 단순한 아키텍처에서 시작하라. 반복 추론과 적응적 도구 사용이 정말 필요할 때만 루프를 들여라.
모든 메이저 AI 회사가 같은 구조로 수렴한 이유
SDK 설계도, 명명도, 아키텍처 철학도 다르지만, 주요 AI 조직은 모두 같은 실행 패턴에 도달했다. 저자가 정리한 표는 이렇다.
| 회사 | 부르는 이름 | 핵심 패턴 | 기여 |
|---|---|---|---|
| OpenAI | Agent Loop | Codex SDK 기반 도구 호출 루프 | 코드 우선; 선언적 그래프 반대 철학 |
| Anthropic | Agent loop | 증강 LLM + 도구 루프 | 단순성 우선; 워크플로 vs 에이전트 구분 |
| Orchestration layer | ReAct (Thought-Action-Observation) | Chain-of-Thought 발명, ReAct 공동 창안 | |
| Microsoft | Think-Act-Learn | 대화 주도 루프 | 이중 루프 원장 계획(Magentic-One) |
| Meta | Agent loop | Llama Stack의 ReAct | 오픈소스 빌딩 블록; 보안 우선(‘Rule of Two’) |
| LangChain | Agent executor / StateGraph | 도구 호출 상태 기계 | 그래프 기반 오케스트레이션; 미들웨어 훅 |
이름과 SDK는 달라도 실행 패턴은 동일하다. Lilian Weng의 공식이 이를 간명하게 잡는다 — Agent = LLM + Memory + Planning + Tool Use. 에이전트 루프는 이 네 부품을 묶는 런타임이다.
루프는 실제로 어떻게 도는가
정전 패턴은 ReAct, 추론과 행동을 교직하는 방식이다. 모델은 그저 도구를 고르는 게 아니라, 왜 그 도구가 적절한지 추론하고, 호출을 실행하고, 결과를 처리하고, 다시 추론한다. 저자가 든 예는 “2026년에 발표된 에이전트 메모리에 관한 가장 많이 인용된 논문을 찾아 핵심 발견을 요약하라"는 작업이다.
- 반복 1 — 에이전트는 2026년 에이전트 메모리 논문을 검색해야 한다고 추론하고 검색 도구를 고른다. 인용 수와 함께 15편이 돌아온다.
- 반복 2 — 인용 340회의 최상위 결과를 짚고, 문서 검색 도구로 전체 초록과 핵심 절을 가져온다.
- 반복 3 — 정보가 충분하다고 판단하고 요약을 생성한 뒤 루프를 나간다.
세 번의 반복, 세 번의 도구 호출, 단일 패스 챗봇은 만들 수 없었던 하나의 완성된 답.
도구 통합의 보편 패턴
제공자가 누구든 도구 통합은 같은 구조를 따른다. 도구는 이름·설명·JSON Schema 파라미터로 정의되고, 모델이 어떤 도구를 어떤 인자로 부를지 결정하면, 시스템이 함수를 실행해 도구 메시지로 결과를 돌려주고, 모델이 그 결과를 처리해 루프를 이어 갈지 최종 응답을 낼지 정한다. 저자는 도구를 세 부류로 나눈다.
- 데이터 도구 — 맥락을 가져온다(DB 질의, 벡터 검색, 문서 검색).
- 행동 도구 — 부작용 있는 작업을 한다(레코드 쓰기, 외부 API 호출, 코드 실행).
- 오케스트레이션 도구 — 다른 에이전트를 호출 가능한 하위 모듈로 불러 멀티에이전트 협업을 이룬다.
설계 시점에 도구를 명확히 분류해 두면 런타임에서 모델의 모호한 행동이 줄어든다. 그리고 Anthropic의 Model Context Protocol(MCP)이 에이전트가 외부 도구를 발견하고 연결하는 방식의 선도적 개방 표준으로 떠올라 OpenAI·Google·Microsoft와 더 넓은 생태계로 채택이 번지고 있다.
기본 루프 너머
핵심 ReAct 루프가 대부분의 경우를 다루지만, 패턴은 두 방향으로 확장된다.
Plan-and-execute는 계획과 실행을 분리한다. 매 단계마다 LLM을 부르는 대신, 계획자가 전체 작업 분해를 앞에서 만들고, 실행자가 하위 작업을 처리하며, 재계획자가 실행이 계획에서 벗어나면 조정한다. LangChain의 LLMCompiler는 의존성을 명시한 작업의 방향 그래프(DAG)를 스트리밍해 병렬 실행을 가능케 하고, 원 논문(Kim et al., ICML 2024)은 순차 ReAct 대비 3.6배 속도 향상을 보고했다. 매 LLM 호출이 직접 비용을 지는 프로덕션 규모에서, 매 단계 추론 대신 앞에서 계획하기로 한 결정은 측정 가능한 재무적 함의를 갖는다.
멀티에이전트 오케스트레이션은 일을 전문화된 에이전트들에 분산한다. Anthropic의 Claude Research는 리드 에이전트가 하위 에이전트를 띄워 여러 갈래를 병렬 탐색하는 오케스트레이터-워커 패턴을 쓰고, 그 멀티에이전트 시스템은 내부 연구 평가에서 단일 에이전트보다 90.2% 더 나은 성능을 냈다. Microsoft의 Magentic-One은 한 걸음 더 나아가 외부 루프(전략 계획)와 내부 루프(단계별 실행)의 이중 루프 시스템으로, 진전이 멈추면 전략 전체를 리셋할 수 있다.
강력한 확장이지만 모든 회사의 조언은 같다 — 작동하는 가장 단순한 루프에서 시작하라. 개선을 측정할 수 있을 때만 복잡성을 더하라.
엔터프라이즈의 현실: 비용과 관측가능성
통제된 환경에서 잘 돌던 에이전트 루프는 프로덕션 규모에서 새로운 실패 양상을 드러낸다. 엔터프라이즈 배포를 지배하는 두 제약은 비용과 관측가능성이다.
비용은 반복과 함께 늘어난다
모든 루프 반복이 LLM 호출이다. Anthropic의 내부 데이터에 따르면 에이전트는 일반 챗 대비 약 4배의 토큰을 쓰고, 멀티에이전트 시스템은 약 15배까지 간다. 하루 수천 건의 에이전트 세션이면 토큰 비용이 반복마다 복리로 불어난다. 아키텍처 차원에 비용 통제를 심어 두지 않으면 이건 심각한 운영 제약이 된다. 완화 전략은 모두 아키텍처적이다 — plan-and-execute로 LLM 호출 수를 줄이고, 자주 쓰는 도구 결과를 캐싱해 중복 작업을 피하고, 에이전트 실행당 토큰·비용 예산을 설정해 폭주 지출을 막는다. 이 통제들은 나중에 덧붙이는 게 아니라 처음부터 설계에 넣어야 한다.
관측가능성: 에이전트가 무엇을 왜 했는지 안다는 것
표준 챗은 단일 LLM 호출에서 단일 응답을 낸다. 반면 15번 반복하고 8개 도구를 부르며 여러 추론 경로로 분기하는 에이전트는 복잡한 실행 트레이스를 만든다. 실패가 났을 때 진단하려면 그 트레이스의 모든 단계에 구조적 가시성이 필요하다 — 모델이 무엇을 추론했고, 어떤 도구를 어떤 인자로 불렀고, 결과가 무엇이었으며, 다음 반복 전에 그 결과를 어떻게 해석했는지. Microsoft의 AutoGen 0.4는 이를 위해 OpenTelemetry 위에 서고, LangChain의 미들웨어 훅(before_model, after_model, modify_model_request)은 매 반복을 가로채 들여다보게 한다.
정지 조건은 다른 한 축의 핵심이다. 없으면 에이전트는 무한히 돌며 토큰을 태우고 점점 더 일관성 없는 결과를 낸다. 저자가 든 사례가 선명하다. 웹사이트를 긁어 데이터를 요약하라고 배포한 에이전트가 있다. 대상 사이트가 구조를 바꾸자 스크래핑 도구가 빈 결과를 돌려준다. 에이전트엔 하드 정지 조건이 없고 프롬프트는 데이터를 얻을 때까지 재시도하라고 시킨다. 에이전트는 폭주 루프에 빠져 5분간 망가진 도구를 400번 부르며 수천 토큰을 태우다 플랫폼 레이트 리밋에 막힌다. 최대 반복 3회 제한 하나면 이 실패는 통째로 막혔을 것이다. 모든 프로덕션 시스템은 최대 반복 한도, 무진전 감지(반복해도 새 정보가 없으면 나가기), 토큰·비용 예산이라는 하드 가드레일을 갖춰야 한다.
어디로 가고 있는가
저자는 세 가지 구조적 이동을 짚는다.
- 코어 루프 아키텍처는 안정적이다. while 루프 자체는 바뀌지 않는다. 활발히 발전하는 곳은 그 둘레에 지어지는 인프라 — 맥락 관리, 다중 루프 협조, 결정 감사 가능성이다.
- 에이전트 미들웨어가 표준 추상화 계층으로 떠오른다. 루프 자체를 고치는 대신 그 위에 행동을 얹는다 — 요약, PII 마스킹, 휴먼인더루프 승인, 동적 모델 전환. 웹 프레임워크를 강력하게 만든 바로 그 패턴이다. 요청-응답 사이클을 바꾸지 말고 미들웨어를 더하라.
- 태스크당 비용이 토큰당 비용을 대체한다. 토큰 사용량은 입력 지표일 뿐이다. 실제 사업 가치를 반영하는 건 작업을 끝까지 완수하는 데 드는 총비용이다. 토큰을 15배 더 쓰고도 사람의 개입 없이 고객 문제를 해결하는 에이전트가, 토큰은 덜 쓰지만 완수에 사람 손이 필요한 챗봇보다 싸다.
남은 가장 큰 미해결 문제는 관측가능성 도구의 성숙 속도라고 저자는 본다. 20번 반복한 에이전트 실행을 디버깅하려면 지금도 구조적 로그·도구 호출 트레이스·LLM 추론 출력을 여러 시스템에 걸쳐 짜맞춰야 한다. 빌딩 블록(OpenTelemetry, 구조적 로깅, 미들웨어 훅)은 이미 있지만, 개발자 경험은 아직 풀리지 않은 문제다.
가장 눈여겨본 지점
내가 가장 곱씹은 대목은 “모든 메이저 AI 회사가 같은 구조로 수렴했다"는 표였다. 보통 이런 수렴은 한 회사가 표준을 쥐고 나머지가 따라갈 때 일어나는데, 여기선 정반대다. OpenAI는 선언적 그래프를 반대하며 코드 우선으로 갔고, LangChain은 정확히 그 그래프 기반 오케스트레이션으로 갔다. 철학이 정면으로 부딪히는데도 바닥의 실행 패턴 — LLM이 도구를 부르며 루프를 돈다 — 은 동일하다. 이건 누가 베껴서가 아니라, 자율적으로 행동하는 시스템을 만들려면 그 구조밖에 없기 때문에 도달한 수렴으로 읽힌다.
그래서 앞 두 편과 겹쳐 읽으면 그림이 입체적으로 선다. 1편 Osmani와 2편 Firecrawl이 “이 루프를 어떻게 설계하고 멈출 것인가"라는 실천의 질문을 던졌다면, Oracle의 이 글은 그 루프가 왜 보편 구조인지를 정의로 떠받친다. 흥미롭게도 세 글의 결론은 한 점에서 만난다 — 정지 조건 없는 루프는 루프가 아니다. 1편은 그것을 “검증은 내 몫"이라 했고, 2편은 “루프를 멈추는 게 진짜 일"이라 했으며, 이 글은 “최대 반복 3회면 막혔을 실패"라는 영수증으로 같은 말을 한다. 각도는 달라도 가드레일을 사람이 설계해야 한다는 결론은 흔들리지 않는다.
출처
Casius Lee (AI Developer Advocate, Oracle), 2026년 3월 16일 발행. (Oracle Developers Blog) 원문: https://blogs.oracle.com/developers/what-is-the-ai-agent-loop-the-core-architecture-behind-autonomous-ai-systems
원문에는 5단계 루프 다이어그램·토큰 비용 스케일링 도식 등 본문 도식이 여러 장 실려 있으나, 사이트가 자동 수집을 차단해 원본 이미지를 가져오지 못했다. 그래서 본문은 텍스트 중심으로 옮기고, 커버는 닫힌 순환이라는 글의 핵심 이미지를 새로 그려 얹었다.