agent loop

한 줄로 말하면

agent loop는 에이전트가 한 번 답하고 끝나는 대신, 목표를 보고 행동한 뒤 그 결과를 다음 판단에 다시 넣어 끝낼 조건이 올 때까지 반복하는 실행 구조야.

비유로 이해하기

처음 가는 길을 운전한다고 생각해 보자. 목적지를 입력하고 출발하는 것만으로는 충분하지 않아. 갈림길을 고르고, 길이 막혔는지 보고, 잘못 들었으면 되돌아가고, 도착하면 멈춰야 해.

agent loop도 마찬가지야. 모델의 답변은 출발 신호일 뿐이야. 도구를 실행한 결과가 다음 행동을 바꾸고, 더 할 일이 없거나 위험한 판단이 필요하면 멈추거나 사람에게 넘겨야 해.

정확한 정의

agent loop에는 보통 다섯 가지가 들어가. Anthropic은 agent를 LLM이 자신의 과정과 도구 사용을 동적으로 지휘하는 시스템으로 구분하고, 실행 중에는 도구 결과나 코드 실행 결과처럼 환경에서 온 ground truth를 단계마다 받아 진행을 평가해야 한다고 설명해.¹ OpenAI Agents SDK도 이 구조를 더 직접적으로 “도구 호출을 처리하고, 결과를 LLM에 되돌려 보내고, 작업이 끝날 때까지 계속하는 내장 agent loop”로 설명해.²

flowchart TD
    A["목표와 현재 맥락"] --> B["다음 행동 선택"]
    B --> C["도구 실행 또는 응답 생성"]
    C --> D["결과 확인과 상태 갱신"]
    D --> E{"끝낼 조건인가?"}
    E -->|"아니오"| B
    E -->|"성공"| F["결과 전달"]
    E -->|"실패·한도 초과"| G["중단 또는 사람에게 넘김"]

첫째는 목표와 맥락이야. 무엇을 끝내야 하고, 지금까지 무엇을 했는지를 잃지 않아야 해. 둘째는 다음 행동의 선택이야. 검색할지, 파일을 읽을지, 계산할지처럼 한 단계의 행동을 고른다. 셋째는 실제 실행이고, 넷째는 그 결과를 읽어 상태를 갱신하는 일이야.

마지막이 특히 중요해. loop는 무한히 계속하라는 뜻이 아니야. Anthropic은 agent가 과제를 끝내면 종료할 수 있고, 통제를 위해 최대 반복 횟수 같은 중단 조건을 넣는 일이 흔하다고 설명해.¹ 정보가 부족하거나 사람의 판단이 필요하면 체크포인트에서 멈추거나 넘겨야 하고, 작업이 끝났다면 더 돌지 않아야 해.

왜 중요한가

agentic workflow가 도구·권한·검증·사람의 개입까지 묶은 작업 흐름이라면, agent loop는 그 안에서 한 과제를 앞으로 밀어가는 반복 단위야. 계획을 세웠더라도 도구 결과가 예상과 다르면 다음 행동을 바꿔야 하므로, 한 번의 프롬프트만으로는 그 과정을 설명하기 어려워.

반복 구조는 성능에도 영향을 줘. 모델 호출 뒤 파일을 읽고, 테스트를 돌리고, 결과를 확인한 다음에야 다음 단계로 갈 수 있는 작업은 순서가 묶여 있어. 단일 스레드 성능이 이런 작업의 지연을 따로 봐야 하는 이유도 여기에 있어.

운영 설계도 달라져. loop를 직접 소유하면 도구 실행, 상태 저장, 결과 해석, 사람에게 넘길 조건을 애플리케이션 코드가 책임진다. 반대로 OpenAI Agents SDK 같은 런타임을 쓰면 turns, tool execution, guardrails, handoffs, sessions 같은 반복 실행의 일부를 런타임이 관리한다.² 어느 쪽이든 중요한 질문은 “모델이 다음에 무엇을 할 수 있나”가 아니라 “이전 결과를 보고 다음 상태를 어떻게 갱신하나”야.

실제 예시

코드 수정 과제를 맡은 에이전트를 생각해 보자. 먼저 저장소를 읽고 수정할 곳을 고른다. 파일을 고친 뒤 테스트를 실행하고, 실패하면 오류 메시지를 읽어 다음 수정으로 돌아간다. 테스트가 통과하면 결과를 정리해 끝내고, 권한이 필요한 배포나 요구사항이 모호한 변경을 만나면 사람에게 질문한다.

Anthropic도 coding agent를 좋은 예로 들어. 코드는 자동 테스트로 검증할 수 있고, agent가 테스트 결과를 피드백으로 삼아 해법을 반복할 수 있기 때문이야.¹ 하지만 자동 테스트만으로 충분하다는 뜻은 아니야. 넓은 요구사항과 설계 의도는 여전히 사람이 봐야 할 수 있어.

이 예시에서 중요한 것은 에이전트가 몇 번 도구를 불렀는지가 아니야. 각 행동이 이전 결과를 어떻게 바꾸고, 어느 조건에서 멈췄는지를 읽을 수 있어야 해. 그래야 같은 loop가 단순한 재시도인지, 문제를 좁혀 가는 과정인지 구분할 수 있어.

헷갈리지 말아야 할 점

• agent loop는 무인 실행과 같은 말이 아니야. 중간 승인이나 질문을 넣어도 결과를 보고 다음 행동을 고르는 반복 구조라면 loop가 될 수 있어.
• 반복 횟수가 많다고 더 잘하는 것은 아니야. 같은 실패를 되풀이하면 비용과 시간만 늘어난다. 재시도 횟수와 중단 기준이 필요한 이유야.
• 계획은 loop의 대체물이 아니야. 긴 과제에서는 처음 계획이 실제 도구 결과와 달라질 수 있어. 계획은 다음 행동을 돕지만, 결과를 받아 고치는 과정이 따로 필요해.
• 종료는 실패가 아니야. 정보가 부족하거나 위험한 행동이 남았을 때 사람에게 넘기는 것은, loop가 제 역할을 한 결과일 수 있어.
• loop와 reflection은 겹치지만 같지 않아. reflection은 결과를 평가해 개선하는 패턴이고, agent loop는 도구 실행·상태 갱신·handoff·종료 조건까지 포함하는 더 넓은 실행 구조야.

관련 문서

• 도구·권한·검증을 함께 설계하는 큰 작업 흐름: agentic workflow
• 순서가 묶인 도구 작업의 지연을 읽는 관점: 단일 스레드 성능
• 에이전트가 외부 도구와 만나는 연결 규약: Model Context Protocol(MCP)

남은 질문들

• 실제 에이전트 런타임은 성공·실패·재시도 한도·사람에게 넘길 조건을 어떤 상태 모델로 표현할까?
• 긴 과제에서 계획을 언제 다시 세우고, 이전 실행 기록은 어느 범위까지 다음 판단에 남겨야 할까?
• 장기 실행 능력 벤치마크는 과제 완료, 중단, 잘못된 행동의 비용을 어떻게 구분해 측정할까?

각주

1. Anthropic, 「Building effective agents」(2024-12-19) 공식 글 ↩︎ ↩︎² ↩︎³

2. OpenAI, 「OpenAI Agents SDK」(2026-07-12 확인) 공식 문서 ↩︎ ↩︎²