에이전트 루프(Agent Loop) 해독: 모든 에이전트 엔지니어가 반드시 알아야 할 3가지 단계

이 기사는 blogs.oracle.com의 원문 게시물에서 제공되었습니다. 최신 업데이트를 확인하려면 해당 사이트의 정식 버전을 읽어보세요.

당신은 아마 오늘 이미 이름을 붙이지 않았을 뿐, 에이전트 루프(agent loop)를 실행했을 가능성이 높습니다.

Claude Code, Codex 또는 Cursor와 같은 코딩 동료(coding companion)와의 모든 세션이 바로 그것입니다. 모델이 요청을 읽고, 저장소(repository)를 조사하고, 파일을 수정하고, 테스트를 실행하고, 실패를 관찰한 다음, 빌드가 통과될 때까지 다시 수정하는 과정입니다.

추론(reasoning), 행동(acting), 그리고 결과 관찰(observing)의 이 사이클이 바로 작동 중인 에이전트 루프이며, 현재 거의 모든 프로덕션 에이전트 시스템의 중심에 자리 잡고 있습니다. 에이전트 루프는 단일 에이전트 턴(turn) 내에서 하네스(harness)가 실행되는 반복 사이클입니다: 컨텍스트(context)를 조립하고, 모델을 호출하여 추론하게 하며, 결정에 따라 행동하고, 중단 조건(stop condition)이 실행을 종료할 때까지 이 과정을 반복합니다.

이 글은 세 가지 이해 수준에 걸쳐 해당 루프를 풀어냅니다.

• 레벨 1(Level 1)은 대부분의 개발자가 처음 접하는 최소한의 루프입니다: LLM, 몇 가지 도구(tools), 그리고 응답(response)으로 구성됩니다.
• 레벨 2(Level 2)는 루프 내부의 라이프사이클(lifecycle)을 도입합니다. 여기서 메모리 작업(memory operations)은 상태가 없는(stateless) 프로세스를 상태를 가진 추론 엔진(reasoning engine)으로 변화시킵니다.
• 레벨 3(Level 3)은 루프 내부와 외부 모두로 작업을 확장하며, 에이전트 하네스가 그 자체로 하나의 시스템이 됩니다.

글을 마칠 때쯤이면 당신의 시스템이 어느 단계에 있는지, 단계와 작업이 일치하지 않을 때 무엇이 고장 나는지, 그리고 다음 단계로 넘어가기 위해 어떤 엔지니어링 작업이 필요한지 알게 될 것입니다. 논의된 모든 패턴은 Oracle AI Database를 기반으로 구축된 companion notebook에 구현되어 있으므로, 단순히 읽는 것에 그치지 않고 루프를 직접 실행해 볼 수 있습니다.

에이전트란 무엇인가

그림 1: 에이전트는 환경을 인지하고, LLM으로 추론하며, 행동하고, 기억한다

에이전트(Agent)란 환경을 인지하고, 인지한 내용에 대해 추론하며, 목표를 달성하기 위해 행동을 취하고, 일종의 메모리(Memory)를 가진 계산 시스템(Computational system)입니다. 이 설명은 온도 조절기, 체스 엔진, 전문직 종사자와 같은 많은 것들에 적용될 수 있습니다. AI 에이전트를 차별화하는 점은 추론(Reasoning) 단계가 대규모 언어 모델(Large Language Model, LLM)에 의해 처리되며, 가능한 행동의 범위가 이진 출력(Binary output)을 훨씬 넘어선다는 것입니다.

에이전트의 아키텍처(Architecture)는 분리 가능한 두 개의 레이어(Layer)로 구성됩니다. 첫 번째는 모델(Model)로, 추론을 수행하는 추론 엔진(Inference engine)입니다. 두 번째는 하네스(Harness)로, 컨텍스트(Context)를 준비하고, 도구 호출(Tool calls)을 실행하며, 운영 제약 조건을 강제하고, 상태(State)를 유지하는 코드입니다. 대부분의 에이전트 엔지니어링(Agent engineering) 작업은 모델이 아닌 하네스에서 이루어집니다. 이 경계를 이해하면 실패가 어디에서 발생하는지, 그리고 어디에서 개입이 효과적인지를 명확히 알 수 있습니다.

그림 2: 에이전트 아키텍처의 두 레이어: 모델과 하네스

에이전트가 유용하기 위해서는 최소한 다음 네 가지가 필요합니다:

• 지침 (Instructions): 무엇을 달성하려고 하는지 알려주는 시스템 프롬프트(System prompt) 또는 목표.
• 메모리 (Memory): 이전 컨텍스트, 검색된 지식, 학습된 패턴을 포함하여 현재 메시지 이외의 정보에 대한 접근 권한.
• 행동을 취할 수 있는 능력 (The ability to take actions): 도구 호출(Tool calls), API 요청, 데이터베이스 쓰기, 또는 외부 효과를 동반하는 모든 작업.
• 추론 엔진 (A reasoning engine): 컨텍스트를 살펴보고 다음에 무엇을 할지 결정하는 LLM.

루프(Loop)란 무엇인가?

루프(Loop)는 특정 조건이 충족될 때까지 실행 블록을 반복하는 제어 구조(control structure)입니다. 프로그래밍에서는 컬렉션(collection)을 반복(iterating)하거나, 플래그(flag)가 설정될 때까지 실행하거나, 기저 사례(base case)에 도달할 때까지 재귀적으로(recursively) 호출하는 등 어디에서나 이 구조를 접하게 됩니다.

에이전트 루프(agent loop)는 LLM 기반 시스템에 동일한 구조를 적용합니다. 에이전트는 사용자 메시지를 한 번 처리하고 정적인 응답을 반환하는 대신, 자신의 출력을 다시 자신에게 입력으로 제공하며 작업이 완료되었다고 판단할 때까지 추론(reasoning), 행동(acting), 결과 관찰(observing the result), 그리고 다시 추론하는 과정을 반복합니다.

그림 3: 에이전트 루프: 컨텍스트를 조립하고, 추론하고, 행동하며, 중단 조건(stop condition)이 실행을 종료할 때까지 반복함

에이전트 실행에서 루프가 필요한 이유는 에이전트가 적용되는 유스케이스(use cases)와 작업의 본질에서 유도될 수 있습니다. 이러한 일반적인 유스케이스는 사용자(user)와 에이전트(agent) 사이의 예상되는 상호작용 패턴인 **애플리케이션 모드(application modes)**라고 부를 수 있습니다. 여기에는 세 가지가 있습니다:

1. 어시스턴트 (Assistant)
2. 딥 리서치 (Deep Research)
3. 코딩 (Coding)

딥 리서치 모드를 예로 들어보겠습니다. 관련 소스를 찾고, 소스 간의 모순을 식별하며, 구조화된 요약을 생성하는 임무를 맡은 에이전트는 단발성 작업(single-shot task)을 수행하는 것이 아닙니다. 이 작업은 에이전트에게 다음과 같은 과정을 요구합니다:

• 관련 소스 검색.
• 찾은 내용을 읽고 평가.
• 공백(gaps) 및 모순 식별.
• 해당 공백을 채우기 위해 다시 검색.
• 모든 것을 일관된 출력물로 합성(synthesise).

그림 4: 심층 연구 사이클(deep research cycle): 검색, 평가, 공백 식별, 그리고 충분한 범위가 확보될 때까지 다시 검색하는 과정

단 한 번의 LLM 호출만으로는 이 모든 것을 수행할 수 없습니다. 모델이 추론(reason)하고, 행동(act)하며, 결과를 관찰(observe)하고, 다시 추론(reason)하며, 작업이 완료될 때까지 이 과정을 지속할 수 있게 하는 메커니즘과 스캐폴딩(scaffolding)이 필요합니다. 그 메커니즘이 바로 에이전트 루프(agent loop)입니다.

주목할 점은, 에이전트 프레임워크(agent frameworks)와 하네스(harnesses)의 구현 방식이 아무리 각기 다른 견해를 가지고 있더라도, 한 가지 공통점을 공유한다는 것입니다. 바로 최소한의 에이전트 루프 설계로 수렴한다는 점입니다. 이러한 수렴은 설계상의 선택이라기보다, 작업 자체의 논리적 결과라고 볼 수 있습니다.

에이전트 루프가 존재하는 이유는 장기적 과업(long-horizon tasks)을 단 한 번의 순방향 패스(forward pass)로 완료할 수 없기 때문입니다.

디자인 패턴으로 등장한 이 루프는 대부분의 조직에서 인간이 작동하는 방식과 유사합니다. 즉, 목표가 달성될 때까지 반복되는 작업, 검토, 피드백의 구조화된 사이클과 닮아 있습니다.

중단 조건 (Stop Conditions)

루프는 결국 종료되어야 합니다. 컴퓨터 과학 수업에서 배우는 프로그래밍 루프는 보통 두 가지 방식 중 하나로 종료됩니다. 루프의 반복 횟수(iteration count)에 도달하거나, 루프 내부의 break 문이 종료를 트리거하는 방식입니다.

잘 설계된 에이전트 루프는 명시적인 종료 기준(exit criteria)을 정의합니다. 일반적인 예시는 다음과 같습니다:

• 모델이 대기 중인 도구 호출(tool calls) 없이 최종 응답을 생성함.
• 목표 완료 체크(goal-completion check)가 true를 반환함: 단순히 도구 호출이 없는 상태가 아니라, 목표에 특화된 술어(predicate)를 확인해야 함.
• 최대 반복 횟수에 도달함.
• 실제 실행 시간(wall-clock time) 제한이 만료됨.
• 에이전트가 복구할 수 없는 오류가 발생함.
• 하네스(harness)가 에이전트가 진전 없이 동일한 행동을 반복하는 것과 같은 실패 모드(failure mode)를 식별함.
• 에이전트가 명시적으로 종료 액션을 호출하거나 완료 플래그(completion flag)를 설정함.

이 기사에 동반되는 노트북에서는 중단 조건이 하네스 내부에 직접 구현되어 있습니다:

def call_agent(query, thread_id='1', max_iterations=10, max_execution_time_s=60.0):
    start_time = time.time()
    iteration = 0
...

루프의 최대 반복 횟수(max iterations)는 기본적으로 10으로 설정됩니다. 이는 루프가 무한히 실행되는 것을 방지하기 위한 보호 장치(guard)로, 무한 실행은 추론 호출(inference calls) 전반에 걸친 토큰 소비 증가를 통해 높은 운영 비용을 초래할 수 있습니다. 또한 max_execution_time_s 파라미터가 있어, 에이전트 루프의 실행에 시간적 보호 장치를 추가합니다.

모델로부터 추가적인 도구 호출(tool calls)이 없는 종료 메시지(terminal message)가 전달되면 에이전트의 턴(turn)이 종료된다는 점에 유의해야 합니다. 이것이 사용자의 목표가 달성되었음을 의미하지는 않습니다. 모델은 명확히 하기 위한 질문, 부분적인 결과, 또는 후속 조치가 필요한 응답을 반환할 수 있습니다. 에이전트 하네스(agent harness)는 단순히 모델이 도구 호출을 중단했는지 여부가 아니라, 목표가 실제로 완료되었는지를 확인하는 책임을 집니다. 이러한 차이는 작업의 길이와 복잡성이 증가함에 따라 더욱 중요해지며, 바로 이 지점에서 에이전트 하네스 엔지니어링의 도메인 전문성(domain expertise)이 매우 중요해집니다.

실패 모드(Failure mode) 식별은 종료 경로(exit path)로서 별도로 언급할 가치가 있습니다. 루프는 작업이 완료되었을 때뿐만 아니라, 작업의 진행이 멈췄을 때도 중단되어야 합니다.

가장 명확한 예는 도구 호출 반복(tool call repetition)입니다. 에이전트가 동일한 인자(arguments)로 세 번째 연속해서 같은 도구를 호출한다면, 이는 작업 중이 아니라 정체(stuck)되어 있다는 강력한 신호입니다. 잘 설계된(well-instrumented) 하네스는 최근 도구 호출의 윈도우(window)를 유지하여 반복을 감지하고, 정체된 실행에 남은 반복 횟수를 낭비하는 대신 진단 정보와 함께 종료합니다. 두 상태 사이를 오가는 진동(Oscillation) 또한 동일한 범주의 감지 가능한 실패 유형에 속합니다.

에이전트 루프(Agent Loop) 정의

구성 요소와 종료 기준이 설정되었으므로, 이제 다음과 같이 정밀하게 정의할 수 있습니다:

에이전트 루프 (The Agent Loop)

단일 에이전트 실행 내에서 하네스가 반복적으로 수행하는 순환적이고 반복적인 실행 패턴으로, 다음과 같습니다:

1. 실행 컨텍스트 조립 (Assembles execution context): 시스템 지침 (system instructions), 대화 상태 (conversation state), 검색된 메모리 (retrieved memory), 도구 출력 (tool outputs), 그리고 모든 관련 외부 데이터를 포함합니다.
2. 추론 모델 호출 (Invokes a reasoning model): 다음에 무엇을 할지 결정하기 위해 추론 모델을 호출합니다.
3. 행동 (Acts): 사용자에게 응답하거나, 도구를 호출하거나, 메모리 또는 상태를 기록하거나, 계획을 업데이트합니다.

각 사이클은 자신의 트레이스 (trace, 어시스턴트 메시지, 도구 출력, 상태 업데이트)를 컨텍스트에 추가하며, 종료 체크 (termination check)가 실행을 종료할 때까지 반복됩니다. 컨텍스트 윈도우 압박 (Context-window pressure)과 운영 안전성 (operational safety, 타임아웃, 반복 횟수 제한, 예산 가드레일)은 사후 고려 사항이 아닌 최우선 고려 사항입니다.

에이전트 루프의 세 가지 단계 (Three Levels of the Agent Loop)