아키텍처

Loop Engineering: 에이전트 런타임이 새로운 미들웨어인 이유

글쓴이: IdeaBosque최종 업데이트: 2026年8月23日

본 글은 장기 실행 에이전트 패턴: 에이전트를 시간에서 일 단위로 살아있게 유지를 기반으로 하며, 해당 글은 시간에서 일 단위의 지평에서 나타나는 세 가지 실패 모드(궤적 수준의 정렬 불일치, 압축 기반 침식, 자가 진화)와 그것들을 포착하는 세 가지 적용 계층을 매핑했습니다. 여기서는 상호 보완적인 발전에 초점을 맞춥니다: 런타임 계층 자체가 관리되고 검사 가능한 미들웨어가 되고 있습니다 — TrueFoundry가 loop engineering이라고 부르는 것, 2026년 8월 23일 공개.

핵심 요점

LangGraph는 월간 3,450만 건의 PyPI 다운로드와 Klarna, Uber, BlackRock을 포함한 약 400개의 기업 배포를 보유 — 모델 주위의 런타임 계층이 프로덕션 차별화가 축적되는 곳이며, 모델 선택이 아닙니다 (uvik.net 프로덕션 비교)
TrueFoundry의 loop engineering 패턴은 프롬프트에서 런타임으로 이동하는 5가지 운영 결정에 이름을 부여: 승인 체크포인트, 세션 지속성, 자격 증명 격리, 컨텍스트 압축, 주문형 역량 로딩 — 각각은 런타임 속성이며, 프롬프트 지시가 아닙니다 (TrueFoundry)
그래프 엔지니어링은 루프 간의 에지를 통제: 누가 행동하는지, 무엇이 경계를 넘는지, 얼마나 비용이 드는지, 어떤 증거가 남는지 — "노드를 평가하고, 에지를 통제하라" 원칙은 권한, 데이터 이동, 지출을 토폴로지 계층에서 실행 가능하게 만듭니다 (TrueFoundry)
단일 에이전트는 벤치마크된 작업의 64%에서 멀티 에이전트 시스템과 동등하거나 능가했으며, 비용은 2배 — 첫 번째 아키텍처 결정은 여러 에이전트가 필요한지 여부이며, 루프는 그 결정이 적용되는 곳입니다 (Princeton NLP)

엔터프라이즈 소프트웨어의 모든 시대는 운영 결정이 그곳에 축적될 때까지 부차적으로 보이는 계층을 개발합니다. 클라이언트-서버 시대에는 애플리케이션 서버였습니다. 클라우드 시대에는 컨테이너 오케스트레이터. 데이터 시대에는 파이프라인 스케줄러. AI 에이전트에 대해, 그 계층에는 이름이 있습니다: 모델을 감싸고 신뢰할 수 있는 장기 실행 에이전트로 변환하는 런타임. LangGraph만으로도 월간 3,450만 건의 PyPI 다운로드와 약 400개의 기업 배포를 보유하고 있습니다 — 런타임은 부차적인 계층이 아닙니다. TrueFoundry의 문서는 에이전트 하네스를 "LLM 주위의 런타임 계층으로, 이를 신뢰할 수 있는 장기 실행 에이전트로 변환하는 것"으로 명확하게 정의합니다. 본 글은 loop engineering 패턴을 매핑합니다 — 루프가 매개하는 것, 왜 미들웨어처럼 동작하는지, 그래프 엔지니어링 거버넌스 계층이 무엇을 추가하는지 — 그리고 왜 모델이 아닌 루프가 B2B 배포 신뢰성이 결정되는 곳인지 설명합니다.

문제: 운영 판단은 루프에 존재하며, 프롬프트가 아닙니다

프롬프트 엔지니어링은 모델에게 무엇이라고 말할지 묻습니다. 컨텍스트 엔지니어링은 무엇을 보여줄지 묻습니다. 루프 엔지니어링은 모델 호출 사이에 시스템이 무엇을 하는지 묻습니다. 이 질문은 프롬프트 작성자만큼이나 플랫폼과 보안 엔지니어링에도 속합니다. 왜냐하면 루프는 기관 운영 결정이 실행 가능해지는 곳이기 때문입니다.

루프가 각 회로에서 매개하는 것을 나열하면, 이 구별은 구체화됩니다. 프로덕션 시스템에 쓰는 구성된 도구 호출이 진행되는지, 인간을 위해 일시 정지하는지. 세션 상태가 재연결과 재시작을 견디는지. 생성된 코드가 하네스 자격 증명을 볼 수 있는지. 긴 작업이 컨텍스트를 다듬거나 오프로드하는지. 위임된 하위 작업이 전체 작업 기록이 아닌 최종 결과를 반환하는지. 이것들 중 어느 것도 모델 동작만으로 신뢰성 있게 적용되지 않습니다. 각각은 조직이 일관되게 적용하기를 원할 수 있는 운영 결정입니다 — 그리고 그것이 루프가 미들웨어처럼 보이기 시작하는 이유입니다.

번역 테이블은 패턴을 가시화합니다:

운영 판단	프롬프트로서는...	루프에서는 ...이 됩니다
쓰기/파괴적 작업이 인간을 기다림	제안	강제된 체크포인트
재연결/재시작 후 작업 재개	최선의 노력	지속적 세션
자격 증명이 실행 중인 코드에서 멀리 유지	희망	아키텍처에 의한 격리
긴 작업이 컨텍스트 관리	무제한 기록	관리된 압축
역량이 필요할 때 도착	페이로드 팽창	주문형 발견

루프 결정은 런타임 정책이 각 턴을 결정론적으로 매개할 수 있기 때문에 프롬프트 지시와 다르게 누적됩니다. 압축이 발생하는 곳을 변경하면, 해당 런타임을 사용하는 모든 장기 실행 작업이 변경을 상속받습니다. 승인 경계를 추가하면, 위험한 작업의 클래스가 이제 행동 규율에만 의존하는 대신 명시적 승인이 필요합니다. 이 메커니즘은 미들웨어에서 익숙합니다 — 제어를 한 번 정의하고, 일관되게 적용합니다 — 그리고 시니어 엔지니어링의 주목이 런타임으로 이동하는 이유를 설명합니다.

이 패턴은 부모 글이 문서화하는 세 가지 실패 모드에 직접 연결됩니다. 압축 기반 침식(거버넌스 붕괴)은 루프 문제입니다: 안전 규칙을 버리는 요약자는 루프의 컨텍스트 관리 단계에 존재합니다. 궤적 수준의 정렬 불일치는 루프 문제입니다: 작업별 게이팅은 통과한 도구 호출의 시퀀스를 보지만, 루프에 속하는 궤적 수준 모니터링은 편차를 봅니다. 자가 진화는 루프 문제입니다: 자신의 제약을 편집하는 에이전트는 루프 관리 상태를 편집하고 있습니다. 루프는 세 가지 실패 모드가 모두 나타나거나 억제되는 기질입니다.

미들웨어로서의 루프: 역사적 해석

기술 시대를 가로지르는 반복 패턴은 미들웨어가 불가피하게 오픈 소스가 된다는 것이 아닙니다. 엔터프라이즈 애플리케이션 서버는 여전히 오픈 표준과 나란히 주요 독점 제품을 포함합니다. 컨테이너 오케스트레이션은 오픈 소스 Kubernetes 주위로 강하게 수렴했습니다. 워크플로우 스케줄링은 관리되는 대안과 나란히 영향력 있는 오픈 소스 시스템(Apache Airflow)을 가지고 있습니다. 교훈은 더 좁습니다: 운영 계층이 전략적으로 중요해지면, 기업은 검사 가능성, 이식성, 그리고 자체 조건으로 계층을 실행하거나 교체하는 능력을 중시합니다.

시대	찬사받은 컴포넌트	결과를 결정한 계층	최종 위치
클라이언트-서버	데이터베이스	애플리케이션 서버	혼합: 독점 플러스 오픈 표준
클라우드	VM	컨테이너 오케스트레이터	오픈 소스 Kubernetes가 지배적
데이터	데이터 웨어하우스	파이프라인 스케줄러	오픈 소스 스케줄러가 관리 서비스와 공존
에이전트	모델	루프	결정 중

에이전트 루프는 그 호의 일부를 따를 수 있습니다. 개방성의 주장은 구체적입니다: 소스 가용성은 구현 수준 감사를 가능하게 합니다(배포된 바이너리가 신뢰할 수 있음을 증명하지는 않지만, 감사를 가능하게 합니다). 자체 호스팅을 지원하는 런타임은 실행 계층을 경계 내에 배치할 수 있습니다. 확장 가능한 오픈 구현은 팀이 벤더 로드맵을 기다리지 않고 압축, 체크포인팅, 또는 통합 동작을 변경할 수 있게 합니다. TrueFoundry는 하네스 TrueForge를 MIT 라이선스로 로컬 및 호스팅 작동과 함께 공개했으며, 모델, MCP 서버, 샌드박스 제공자를 연결된 종속성으로 취급합니다.

전략적 요약: 당신의 판단을 적용하는 계층은 당신이 판단할 수 있는 계층이어야 합니다.

루프에 무엇을 물어야 하는가

루프가 운영 판단이 존재하는 곳이라면, 조달 질문은 런타임이 검사 가능하고 이식 가능한지 여부입니다. 여섯 질문이 심문을 구성합니다:

작업이 재시작을 견디는가? 세션 지속성은 런타임 속성입니다. 매번 중단 후 처음부터 시작해야 하는 에이전트는 장기 실행 에이전트가 아닙니다 — 계속 재시작되는 단기 에이전트입니다.
코드 실행 환경은 무엇을 볼 수 있는가? 샌드박스 설계는 하네스 자격 증명을 모델의 범위 밖에 유지합니다. 모델이 자체 컴퓨트를 프로비저닝하는 API 키를 읽을 수 있다면, 격리는 프롬프트이지 경계가 아닙니다.
어떤 작업이 인간을 위해 일시 정지하는가 — 런타임에 의해, 아니면 희망에 의해? 도구 승인은 강제된 체크포인트와 제안의 차이입니다. 루프가 그것을 결정론적으로 만듭니다.
역량이 주문형으로 로드되는가, 아니면 매 턴마다 실려 오는가? 지연된 도구와 기술은 페이로드 팽창을 줄입니다. 각 회로에서 모든 도구 설명을 전송하는 루프는 에이전트가 추론에 필요한 컨텍스트 창을 낭비합니다.
실행을 그 트레이스에서 재구성할 수 있는가? 추가 전용 세션 로그 패턴 — DeepSeek Harness와 Meta Muse Code가 독립적으로 수렴한 — 리플레이, 롤백, 감사를 위한 기질입니다. 부모 글이 이 수렴을 상세히 문서화합니다.
내일 런타임 벤더를 떠나면 무엇을 잃는가? 진정한 이식성은 데이터 형식, 통합, 운영 관행에 의존하며, 소스 가용성만이 아닙니다. 하지만 구현을 검사할 수 없는 런타임은 심층 감사, 자체 호스팅, 수정, 이탈 계획을 더 어렵게 만듭니다.

루프에서 그래프로: 연결 통제하기

지속적인 루프를 가진 단일 에이전트는 실행 문제를 해결합니다. 하지만 프로덕션 시스템은 드물게 단일 에이전트를 실행합니다. 에이전트에서 루프, 그래프로의 진행은 각 단계에서 다른 시스템 질문을 추가합니다. TrueFoundry의 From Agent to Loop to Graph 아키텍처 포스트는 에스컬레이션을 구성합니다: 첫 번째 작동하는 에이전트는 역량과 도구 사용 질문을 도입합니다. 지속적인 루프는 상태, 복구, 컨텍스트, 승인 우려를 추가합니다. 그래프는 토폴로지, 조정, 위임을 추가합니다. 자가 수정은 검증, 봉쇄, 승격 질문을 제기합니다. 오케스트레이션은 결합된 시스템을 운영 문제로 변환합니다.

중요한 구별은 그래프가 루프를 대체하지 않는다는 것입니다 — 루프와 다른 노드를 편성합니다. 프로덕션 그래프에는 에이전트, 결정론적 함수, 라우터, 조인, 대기열, 인간 체크포인트, 평가자, 데이터베이스 쓰기, 일반 서비스가 포함될 수 있습니다. 에이전트 노드만이 자체 로컬 실행 루프가 필요합니다. 그래프는 다음에 어떤 노드가 실행되는지, 브랜치가 병렬로 실행되는지, 어떤 결과가 조인을 해제하는지, 하나의 브랜치가 실패하면 어떻게 되는지, 어떤 경로가 인간 체크포인트가 필요한지를 소유합니다. 에이전트 노드 내의 루프는 다른 세트를 소유합니다: 에이전트가 어떤 컨텍스트를 보는지, 어떤 도구를 선택하는지, 관찰을 어떻게 처리하는지, 언제 재시도하는지, 로컬 작업이 언제 완료되는지.

두 번째 구별이 중요합니다: 그래프 오케스트레이션은 지식 그래프가 아닙니다. 지식 그래프는 정보를 구조화합니다 — 엔티티와 관계. 에이전트 실행 그래프는 실행을 구조화합니다 — 행위자, 계산 노드, 전환, 종속성, 작업 상태. 하나가 다른 하나를 먹일 수 있지만, 다른 질문에 답합니다. 연구 에이전트가 지식 그래프를 조회한 다음 검증을 두 번째 에이전트에 위임한다면, 지식 그래프는 시스템이 아는 것의 일부이고, 실행 그래프는 시스템이 수행하는 것을 설명합니다.

TrueFoundry가 7단어로 압축한 거버넌스 원칙: 노드를 평가하고, 에지를 통제하라. 여전히 노드 동작을 평가합니다 — 모델 평가는 사라지지 않습니다. 하지만 평가만으로는 프로덕션 데이터베이스가 쓰기를 거부하거나, 예산을 적용하거나, 파괴적 작업 전에 승인을 요구하게 만들 수 없습니다. 런타임, 게이트웨이, 다운스트림 인가 경계는 관련 트래픽이 그것들을 통과할 때 그 제약을 적용합니다. 결과적으로 중요한 모든 에지는 5가지 질문에 답해야 합니다:

질문	왜 중요한가	가능한 소유자
누가 또는 무엇이 행동하는가?	귀속, 최소 권한, 감사	아이덴티티/레지스트리
이 노드는 무엇에 도달할 수 있는가?	발견은 인가가 아닙니다	오케스트레이터 + 게이트웨이 + 다운스트림 정책
무엇이 에지를 넘을 수 있는가?	데이터 최소화, 프롬프트 인젝션 방어	애플리케이션 정책 + 게이트웨이 가드레일
얼마나 지출하거나 팬아웃할 수 있는가?	그래프는 재시도, 브랜치, 모델 호출을 곱합니다	오케스트레이터 + 게이트웨이 예산
어떤 증거가 남는가?	설계된 그래프와 실행된 그래프는 분기합니다	오케스트레이터 + 하네스 + 기록 시스템

프레임워크 환경: loop engineering이 적합하는 곳

Loop engineering은 런타임 수준 패턴이지, 프레임워크 선택이 아닙니다. 프레임워크 환경은 2026년 8월 현재 안정적입니다:

LangGraph — 월간 3,450만 건의 PyPI 다운로드, Klarna, Uber, LinkedIn, BlackRock, JPMorgan을 포함한 약 400개 기업 배포. 체크포인팅, 타임 트래블 디버깅, 네이티브 MCP 지원을 갖춘 스테이트풀 에이전트의 프로덕션 표준. 관측성에는 LangSmith.
CrewAI — 44,600개 이상의 GitHub 스타, 플랫폼에서 월간 10M 이상의 에이전트 실행, 약 60%의 Fortune 500이 탐색 중. 단순 작업에서 LangGraph 대비 최대 3x 높은 토큰 오버헤드.
Microsoft Agent Framework — 2026년 4월 3일 1.0 GA 출시, AutoGen 대체(현재 유지보수 모드). 네이티브 MCP 지원, 별도 어댑터(베타)로 A2A.
OpenAI Agents SDK — 약 19,000개의 GitHub 스타, 월간 10.3M 다운로드.
Google ADK — Gemini 네이티브, A2A 퍼스트.
DeepSeek Harness — MIT 라이선스, 33K개 이상의 GitHub 스타, 추가 전용 세션 로그.

Princeton NLP의 발견이 첫 번째 아키텍처 결정을 정압합니다: 단일 에이전트는 벤치마크된 작업의 64%에서 멀티 에이전트 시스템과 동등하거나 능가했으며, 비용은 2배. 멀티 에이전트 그래프를 선택하기 전에, 작업이 조정 오버헤드를 정당화하는지 물으십시오. 루프는 그 결정이 적용되는 곳입니다 — 체크포인트/재개, 승인 게이트, 컨텍스트 관리를 갖춘 잘 엔지니어링된 루프는 멀티 에이전트 그래프가 더 높은 비용과 더 많은 실패 표면으로 수행할 작업을 수행할 수 있습니다.

Loop engineering은 이 모든 프레임워크와 호환됩니다. 패턴은 런타임이 무엇을 매개하는지에 관한 것이지, 어떤 프레임워크 위에 구축하는지가 아닙니다. LangGraph의 체크포인팅과 타임 트래블 디버깅은 loop engineering 프리미티브입니다. DeepSeek Harness의 추가 전용 세션 로그는 loop engineering 프리미티브입니다. TrueForge의 도구 승인과 샌드박스 격리는 loop engineering 프리미티브입니다. 수렴이 신호입니다: 여러 독립적인 런타임이 동일한 운영 제어 세트를 구현할 때, 제어는 구조적 요구사항이지 벤더 선택이 아닙니다.

Loop engineering 패턴 — 모델과 비즈니스 시스템 간의 실행 주기에서 축적되는 런타임 결정: