2026년 상반기 AI 엔지니어링 논의에서 가장 자주 등장한 단어는 '루프(loop)'입니다. 6월 7일 피터 스타인버거(Peter Steinberger)가 코딩 에이전트에 프롬프트를 넣는 대신 에이전트에게 프롬프트를 주는 루프를 설계해야 한다고 밝혔고, 같은 주 앤스로픽(Anthropic)의 보리스 체르니(Boris Cherny)는 무대에서 자신은 더 이상 프롬프트를 쓰지 않고 루프를 작성하며 그 루프가 일을 한다고 말했습니다. 애디 오스마니(Addy Osmani)의 'Loop Engineering', swyx(숀 왕)의 'Loopcraft', 랭체인(LangChain)의 'The Art of Loop Engineering'이 6월 한 달 사이에 연달아 발행되었고, AI Engineer World's Fair에서는 이 단어가 메인 스테이지를 채웠습니다. 7월 2일 폐회는 루프를 둘러싼 기대가 실제로 작동하는 수준을 앞질렀는지를 두고 한 시간에 걸친 토론으로 마무리되었습니다.

문제는 루프를 이야기하는 사람들이 서로 다른 것을 가리키고 있다는 점입니다. 어라이즈 AI(Arize AI)는 최근 블로그에서 하나의 단어 아래 최소 네 가지 서로 다른 아키텍처가 숨어 있다고 정리하며, 각각을 실행 루프, 태스크 루프, 제품 루프, 시스템 루프로 구분했습니다. 그리고 이 네 가지를 통제하는 가장 바깥쪽 고리에 '오버사이트 루프'라는 이름을 붙였습니다.

이 글에서는 Arize AI가 정리한 네 가지 루프의 정의와 종료 조건, 사람의 역할을 살펴보고, 루프가 실제로 닫히고 있는지 확인하기 위해 어떤 신호가 필요한지, 그리고 어라이즈 AX(Arize AX)가 그 지점에서 어떤 역할을 하는지 정리합니다.

☑️ AI 엔지니어링에서 '루프(Loop)'란 무엇인가

AI 엔지니어링에서 루프는 에이전트가 행동하고, 그 결과를 다시 입력으로 받아 다음 사이클을 반복하는 구조를 말합니다. Arize AI는 현재 이 단어가 실행 루프, 태스크 루프, 제품 루프, 시스템 루프라는 네 가지 아키텍처를 동시에 지칭하고 있으며, 각 루프는 무엇을 반복하는지, 무엇이 루프를 끝내는지, 사람이 어디에 개입하는지, 시간 단위가 어떻게 되는지가 서로 다르다고 설명합니다.

피드백이 다음 사이클로 되돌아가지 않는 구조는 루프가 아니라 파이프라인입니다. 따라서 루프를 설계한다는 것은 무엇이 이 루프를 끝내는지, 그 신호를 어디에서 가져올지를 함께 정하는 일입니다.

실행 루프(Execution loops): 에이전트가 행동하고 관찰하고 다음 행동을 결정하는 구조

실행 루프는 대부분의 사람이 '에이전트'라는 말을 들었을 때 떠올리는 형태입니다. 도구를 호출하고, 결과를 읽고, 다음 행동을 결정하고, 더 이상 호출할 도구가 없을 때까지 이를 반복합니다. 애디 오스마니는 이를 내부 실행 루프(inner execution loop)라고 부릅니다. 에이전트가 사람의 개입 없이 상당 부분 스스로 수행할 수 있게 된 구간이자, 엔지니어가 직접 설계할 수 있는 가장 안쪽 루프입니다.

실행 루프가 반복하는 단위는 하나의 작업 안에 있는 단계들입니다. 루프를 끝내는 신호는 환경 피드백, 즉 테스트 출력, API 응답, 파일 내용입니다. 사람은 루프 중간에는 대체로 등장하지 않고 경계에서 계획을 승인하거나 결과를 검토합니다.

다만 이 루프는 에이전트가 스스로 끝났다고 판단하는 순간에도 종료됩니다. 실제로 끝났는지 여부와 무관하게 종료된다는 뜻입니다. 이 문제에 대해 업계가 처음 찾은 해법은, 에이전트의 판단을 그대로 받아들이지 않는 또 하나의 루프로 실행 루프를 감싸는 것이었습니다.

태스크 루프(Task loops): 테스트가 통과하고 스펙이 충족될 때까지 에이전트를 재시작하는 구조

태스크 루프는 이름을 얻은 첫 번째 루프이며, 제프리 헌틀리(Geoffrey Huntley)의 랄프 루프(Ralph Loop)가 대표 사례입니다. 랄프 루프는 동일한 스펙을 대상으로 코딩 에이전트를 반복해서 재시작하되, 매 반복마다 완전히 새로운 컨텍스트 윈도우를 할당하고 루프당 정확히 하나의 작업만 수행합니다.

낭비처럼 보이는 이 구조가 핵심입니다. 매번 전체 스펙을 다시 입력함으로써, 장시간 실행되는 세션의 품질을 서서히 떨어뜨리는 컨텍스트 부패(context rot)와 컴팩션 이벤트를 방지하기 때문입니다.

태스크 루프가 반복하는 단위는 하나의 산출물이고, 루프를 끝내는 신호는 스펙 준수와 테스트 통과입니다. 사람은 스펙을 작성하고 완료 여부를 판단합니다. 제프리 헌틀리는 사람에게 한 가지 역할을 더 부여합니다. 루프를 지켜보면서 실패 패턴을 찾아내고, 그 패턴이 다시 발생하지 않도록 고치는 일입니다. 그는 이 역할을 기관차를 선로 위에 유지하는 기관사에 비유했습니다.

제품 루프(Product loops): 코드베이스와 백로그를 대상으로 도는 소프트웨어 팩토리

제품 루프는 AI Engineer World's Fair에서 가장 크게 다뤄진 형태입니다. 팩토리(Factory)의 테레자 티슈코바(Tereza Tížková)는 소프트웨어 팩토리를 자율성을 갖고 소프트웨어를 개발하는 전체 루프이자 전체 라이프사이클로 정의했습니다. 워프(Warp)의 잭 로이드(Zach Lloyd)는 그 라이프사이클을 트리아지, 명세, 구현, 리뷰, 검증, 배포, 모니터링으로 구체화했습니다.

잭 로이드는 소프트웨어 엔지니어링이 팩토리 엔지니어링으로 바뀌며, 제품이 아니라 그 제품을 만들어내는 시스템을 만들게 된다고 주장합니다. 워프는 자사 오픈소스 저장소를 팩토리 플랫폼 Oz의 관리 아래 두고 이를 직접 적용하고 있으며, 도입 경로를 리스크가 낮은 저장소에서 시작해 자동 PR 병합 비율을 20퍼센트에서 60퍼센트 방향으로 끌어올리는 방식으로 설명합니다. 앤스로픽 역시 자사 제품팀 코드의 65퍼센트가 내부 버전의 Claude Tag로 작성되고 있다고 밝혔고, 마이크 크리거(Mike Krieger)는 팀의 활용 방식을 특정 버그를 고치라는 지시가 아니라 코드베이스의 특정 영역을 책임지고 피드백 채널을 모니터링하며 스스로 작업을 가져가는 위임형·능동형 방식이라고 설명했습니다.

실행 루프와 태스크 루프에는 명확한 종료 조건이 있지만, 제품 루프는 코드베이스와 백로그를 대상으로 지속적으로 돕니다. 종료 신호도 코드베이스 바깥에서 옵니다. 새로 등록된 이슈, 프로덕션 로그, 사용자 피드백, 리뷰 결과가 그 신호입니다. 사람의 역할은 고정되어 있지 않고 구성 가능한 형태가 됩니다. 라이프사이클 중 어느 부분을 자동화할지, 어느 지점에서 사람을 개입시킬지를 조직이 직접 선택합니다.

시스템 루프(System loops): 프롬프트, 평가, 하네스, 모델 자체를 개선하는 오토리서치

시스템 루프는 인트로스펙션(Introspection)의 롤랜드 가브릴레스쿠(Roland Gavrilescu)가 오토리서치(autoresearch)라고 부르는 구조입니다. 내부 루프는 사용자 대면 작업을 수행하는 기본 시스템이고, 외부 루프는 그 기본 시스템을 연구하고 유지보수합니다. 외부 루프가 반복하는 대상은 프롬프트, 하네스, 모델 선택, 그리고 평가(eval) 자체입니다. 그는 루프가 곧 제품이라고 표현합니다.

이 패턴은 소규모와 대규모 양쪽에서 실제 사례가 확인됩니다. 최소 사례는 안드레이 카파시(Andrej Karpathy)가 2026년 3월에 공개한 오토리서치로, 약 630줄의 파이썬 코드가 GPU 한 장에서 하룻밤 사이 50회의 가설-수정-평가 실험을 수행했습니다. 실제 제품에 반영된 사례는 6월 말 발표된 메타(Meta)의 Brain2Qwerty v2로, 에이전트가 코드베이스를 반복적으로 수정하며 더 나은 디코딩 아키텍처를 만들어냈고 단어 오류율에서 상당한 개선이 있었다고 보고되었습니다. 다만 최종 학습 구성은 여전히 사람이 직접 선택했습니다.

시스템 루프를 끝내는 신호는 네 가지 루프 중 가장 까다롭습니다. 평가, 저지(judge), 필터링된 제품 피드백이 필요하고, 롤랜드의 설계에서는 에이전트가 신입 직원처럼 암묵지를 축적할 수 있도록 사람에게 묻는 도구가 명시적으로 포함됩니다.

실행 루프, 태스크 루프, 제품 루프, 시스템 루프 비교

☑️ 에이전틱 맵리듀스는 루프인가

같은 시기에 화제가 된 패턴 중 하나는 코그니션(Cognition)의 Devin Security Swarm입니다. 저장소 전반에 경계가 정해진 에이전트를 병렬로 펼치고 그 결과를 집계하는 방식으로, 코그니션은 이를 에이전틱 맵리듀스(Agentic MapReduce)라고 부릅니다.

Arize AI는 이 구조를 루프로 보지 않습니다. 디스패치, 수집, 검증은 파이프라인이며, 다음 사이클로 되먹임되는 것이 없기 때문입니다. 피드백이 없는 루프는 for 문에 불과하고, 팬아웃은 네 가지 루프 안에 배치할 수 있는 토폴로지일 뿐 그 자체로 별도의 루프는 아니라는 관점입니다.

오버사이트 루프(Oversight loop): 목표, 예산, 자율성 수준을 사람이 정하는 고리

swyx의 루프 다이어그램에서 가장 바깥 고리, 즉 루프를 만드는 루프보다 위에 있는 고리에는 이름이 없습니다. 그 고리에 적힌 역할은 목표를 설정하고, 자원을 배분하고, 작업을 쳐내는 것이며, 종료 조건은 '없음'으로 표시되어 있습니다. 

Arize AI는 이 고리에 오버사이트 루프라는 이름을 붙였습니다. 목표가 설정되고, 예산이 배분되고, 작업이 정리되는 곳이며, 사람이 반드시 있어야 하는 유일한 고리라는 의미입니다. 애디 오스마니는 무대에서 내부 루프는 역량이고 외부 루프는 주체성이라고 표현했고, 오버사이트 루프가 붙잡고 있는 것이 바로 그 주체성입니다.

이 고리를 누가 운영할 것인가를 두고 의견은 갈립니다. 자율성 다이얼을 올려야 한다는 쪽은 체크포인트를 의도적으로 선택하고 신뢰가 쌓이는 만큼 자율성을 높여가자고 주장합니다. 반대편에서는 다이얼에 멈춤 지점이 있다고 봅니다. 제프리 리트(Geoffrey Litt)는 이해를 위임하는 사람은 에이전트로 대체된다고 주장했고, 폴 바카우스(Paul Bakaus)는 자동이란 것은 없고 앞으로도 없을 것이라고 단언했습니다. 휴먼레이어(HumanLayer)의 덱스 호시(Dex Horthy)는 자신이 루프에 반대하는 것은 아니며 쿠버네티스도 제어 루프 위에 세워져 있지만 그것은 결정론적 루프라고 지적하면서, 열광이 엔지니어링을 앞질렀다는 점을 우려했습니다.

이 논쟁에서 가장 구체적인 근거는 앤스로픽 내부에서 나왔습니다. Claude Tag를 운영하는 팀조차 리뷰 단계와, 시스템이 무엇을 하고 있는지 사람이 개념화하는 능력에서 병목이 발생하고 있다고 보고했습니다. 사람이 스스로를 위해 남겨둔 체크포인트가 이제 제약 조건이 된 것입니다.

루프가 실제로 닫히고 있는지 어떻게 확인하는가

자율성은 네 가지 루프 각각에 별도로 존재하는 다이얼입니다. 감독이 강한 제품 루프 안에서 완전 자율 실행 루프를 돌릴 수도 있고, 시스템 루프를 에이전트에 맡기면서 목표 설정은 전부 사람이 유지할 수도 있습니다. Arize AI가 던지는 질문은 어느 진영이 옳은가가 아니라, 각 다이얼을 올바르게 설정하려면 어떤 정보가 필요한가입니다.

여기서 핵심은 신호를 이름 붙이는 것과 실제로 배선하는 것이 다르다는 점입니다. Arize AI는 신호가 배선되지 않은 루프는 수렴하지 않고, 외부에서 무언가 멈춰 세울 때까지 그냥 돌아갈 뿐이라고 설명합니다. 프로덕션 규모에서 루프가 실제로 닫히고 있는지 알려면, 트랜스크립트를 표본 점검하는 대신 트레이스를 지속적으로 훑고 실패를 클러스터링해야 합니다. Arize AX가 수행하도록 설계된 작업이 바로 이 지점입니다.

☑️ Arize AX가 에이전트 개선 루프를 닫는 방식

Arize AX는 LLM, RAG, AI 에이전트 서비스의 실행 과정을 트레이스로 기록하고, 평가와 저지로 그 동작의 품질을 측정하며, 측정 결과를 개선 작업까지 연결하는 AI 옵저버빌리티·평가 플랫폼입니다. 루프 관점에서 보면 Arize AX가 다루는 대상은 루프의 종료 신호입니다. 에이전트가 무엇을 했는지는 트레이스가, 그 동작이 좋은 동작이었는지는 평가와 저지가, 변경이 실제로 개선이었는지는 실험이 알려줍니다.

프로덕션 트래픽은 사전 테스트가 놓친 엣지 케이스를 드러냅니다. 타임아웃이나 도구 오류, 깨진 JSON처럼 알람으로 잡히는 실패도 있지만, 잘못된 문맥을 검색하거나, 필요한 단계를 건너뛰거나, 도구에 잘못된 인자를 넘기거나, 잘못된 추론 위에 그럴듯한 답변을 만들어내는 실패는 트레이스를 들여다봐야 확인할 수 있습니다. Arize AX는 이 과정을 하나의 엔지니어링 워크플로우로 묶어, 에이전트 개선을 매번 새로 시작하는 조사 작업이 아니라 반복 가능한 프로세스로 만드는 것을 목표로 합니다.

앞서 정리한 네 가지 루프에 대입하면 역할이 분명해집니다. 실행 루프의 동작은 트레이스와 스팬으로 기록되어 도구 호출과 판단 경로를 사후에 확인할 수 있게 됩니다. 제품 루프의 종료 신호인 이슈, 로그, 리뷰 결과는 시그널과 관리형 에이전트를 통해 조사 가능한 형태로 정리됩니다. 시스템 루프의 종료 신호인 평가와 저지는 에이전트 애즈 어 저지와 에이전트 실험으로 만들어집니다. 자율성 수준을 어디까지 올릴지 판단하는 오버사이트 루프에는, 이렇게 만들어진 신호가 근거로 올라갑니다.

트레이스는 늘어나는데 사람의 검토가 따라가지 못할 때

에이전트 트래픽은 확장되지만 사람의 검토는 확장되지 않습니다. 하나의 트레이스에서 문제를 발견할 수는 있어도, 수천에서 수백만 건의 트레이스를 가로질러 반복되는 패턴을 찾아내는 일은 곧 불가능해집니다.

시그널(Signal)은 제품 루프의 종료 신호를 만들어내는 기능입니다. 새로 들어오는 프로덕션 트레이스를 지속적으로 검토하고, 이미 확인된 이슈를 기억하며, 새로 나타나는 실패 패턴을 표면화하는 상시 동작 AI 워커입니다. 관련된 트레이스를 묶어 요약, 근본 원인 분석, 영향도, 제안된 다음 조치가 담긴 조사 리포트로 정리합니다. 모니터가 울릴 때까지 기다리는 대응형 디버깅 대신, 우선순위가 매겨진 이슈 목록과 근거를 확보한 상태에서 하루를 시작할 수 있는 구조입니다.

신호를 조사와 수정안으로 연결하는 단계

실패가 식별된 뒤에도 팀은 트레이스를 조사하고, 무엇이 바뀌었는지 파악하고, 근본 원인을 찾고, 수정 방향을 정하고, 결과를 검증해야 합니다. 이 작업 대부분이 여전히 수작업으로 남아 있습니다.

관리형 에이전트(Managed agents)는 신호를 조사와 수정안으로 옮기는 단계를 담당합니다. 저장소를 인지하는 장기 실행 에이전트를 오케스트레이션해 트레이스를 검사하고, 외부 시스템에 접근하고, 코드를 분석하고, 조사 산출물을 만들고, 변경 사항을 풀 리퀘스트 형태로 제안합니다. 회귀 트리아지, 프로덕션 동작 디버깅, 데이터셋 큐레이션, 평가 생성, 보안 리뷰, 코드 수정 같은 엔지니어링 워크플로우에 맞춰 구성할 수 있습니다. 이 워커들은 스스로 변경을 반영하는 자율 프로덕션 에이전트가 아니며, 조사하고 근거를 모아 제안할 뿐 승인과 반려는 엔지니어가 합니다.

스웜 옵저버빌리티(Swarm observability)는 이렇게 늘어난 AI 워커들의 상태, 활동, 트라젝토리, 토큰 사용량, 비용을 한 화면에서 확인할 수 있게 합니다. 운영 관점에서는 제품 루프와 시스템 루프의 체크포인트를 어디에 둘지 판단할 때 참고할 수 있는 정보에 해당합니다.

변경이 실제로 개선인지 검증하는 단계

프로덕션 에이전트는 프롬프트만으로 이루어져 있지 않습니다. 도구, 검색, 라우팅, 메모리, 모델, 폴백, 애플리케이션 코드, 비즈니스 로직으로 구성된 시스템이며, 어느 한 계층의 작은 변경이 한 동작을 개선하면서 다른 동작을 망가뜨릴 수 있습니다.

에이전트 실험(Agent experiments)은 루프의 검증 단계에 해당합니다. 큐레이션된 데이터셋을 전체 에이전트 시스템에 통과시킨 뒤, 실행 간 출력, 트레이스, 평가 결과를 비교해 변경이 동작을 개선했는지 아니면 새로운 회귀를 만들었는지 확인합니다. 도구 사용이 좋아졌는지, 지연 시간이 달라졌는지, 검색 품질이 유지되었는지, 모델 업그레이드가 최종 답변 품질은 높이면서 도구 호출 신뢰성은 떨어뜨리지 않았는지를 이 단계에서 판단합니다.

예상하지 못한 실패 모드가 나타날 때

기존의 LLM 저지는 무엇을 찾아야 하는지 이미 알고 있을 때 가장 잘 작동합니다. 그러나 에이전트 실패는 그렇게 예측 가능한 경우가 드물고, 도구와 사용자, 변화하는 환경과 상호작용하면서 새로운 실패 모드가 프로덕션에서 나타납니다.

에이전트 애즈 어 저지(Agent-as-a-Judge)는 시스템 루프의 종료 신호인 평가 자체를 프로덕션 동작에 맞춰 갱신하는 기능입니다. 팀이 사전에 정의하지 않은 실패 모드가 드러났을 때 개선 루프가 적응할 수 있도록 돕습니다. 좋은 동작이 무엇인지 서술하면, 에이전틱 저지가 트레이스를 검사하고 관련 스팬을 식별해 이슈를 분류하고, 이후 모니터링과 평가, 실험에 재사용할 수 있는 라벨을 생성합니다.

여기에 더해 음성 에이전트(Voice agents) 지원으로 오디오 세션, 트랜스크립트, 멀티모달 트레이스를 관찰하고 검색하고 재생하고 평가할 수 있습니다. 음성 대화를 텍스트 에이전트와 동일한 옵저버빌리티·평가 워크플로우로 가져오면, 개선 루프의 적용 범위가 대화형 AI 시스템까지 확장됩니다.

☑️ 자주 묻는 질문

AI 엔지니어링에서 루프란 무엇인가요?

루프는 AI 에이전트가 행동하고 그 결과를 다시 입력으로 받아 다음 사이클을 반복하는 구조입니다. 어라이즈 AI는 이 단어가 실행 루프, 태스크 루프, 제품 루프, 시스템 루프라는 네 가지 아키텍처를 동시에 지칭하고 있으며, 각각 반복 대상과 종료 신호, 사람의 역할이 다르다고 정리합니다.

실행 루프와 태스크 루프의 차이는 무엇인가요?

실행 루프는 하나의 작업 안에서 도구 호출과 결과 관찰을 반복하며 환경 피드백으로 종료되고, 태스크 루프는 동일한 스펙에 대해 에이전트를 반복 재시작하며 테스트 통과와 스펙 준수로 종료됩니다. 태스크 루프는 매 반복마다 새로운 컨텍스트 윈도우를 할당해 장시간 세션에서 발생하는 컨텍스트 부패를 방지합니다.

에이전틱 맵리듀스도 루프인가요?

어라이즈 AI는 에이전틱 맵리듀스를 루프가 아니라 파이프라인으로 봅니다. 디스패치, 수집, 검증 구조에는 다음 사이클로 되돌아가는 피드백이 없기 때문입니다. 팬아웃은 네 가지 루프 안에 배치할 수 있는 토폴로지에 해당합니다.

루프가 제대로 닫히고 있는지 어떻게 확인할 수 있나요?

루프의 종료 신호가 실제로 시스템에 배선되어 있는지 확인해야 합니다. 어라이즈 AI는 신호가 배선되지 않은 루프는 수렴하지 않는다고 설명하며, 프로덕션 규모에서는 트랜스크립트 표본 점검 대신 트레이스를 지속적으로 훑고 실패를 클러스터링하는 방식이 필요하다고 밝혔습니다.

어라이즈 AX는 에이전트 개선 루프에서 어떤 역할을 하나요?

어라이즈 AX는 트레이스로 동작을 기록하고, 평가와 저지로 신호를 만들고, 관리형 에이전트로 조사와 수정안을 도출하고, 실험으로 변경 효과를 검증하는 과정을 하나의 워크플로우로 제공합니다. 시그널, 관리형 에이전트, 스웜 옵저버빌리티, 에이전트 실험, 에이전트 애즈 어 저지, 음성 에이전트 지원이 이 워크플로우를 구성하는 기능입니다.

☑️ 마무리

네 가지 루프의 형태는 다르지만, 그 아래에는 같은 실무가 놓여 있습니다. 추상화 수준을 한 단계 올리고, 사람의 판단을 스택 위쪽으로 밀어 올리는 일입니다. Arize AI는 이 지점에서 종료 신호를 이름 붙이는 것과 실제로 배선하는 것은 다르며, 신호가 배선되지 않은 루프는 수렴하지 않는다고 정리합니다. 운영 관점에서는 자율성 수준을 높이기 전에, 각 루프가 닫히고 있는지 확인할 수 있는 트레이싱과 평가 체계가 먼저 마련되어 있는지 확인할 필요가 있습니다.

현재 어떤 루프를 만들고 있는지, 그 루프의 종료 신호가 실제로 배선되어 있는지 확인하는 일이 AI 에이전트 운영의 출발점입니다. 클라우드네트웍스는 Arize AI 공식 파트너로서, 고객 환경에서 운영 중인 LLM·RAG·AI 에이전트 서비스에 트레이싱과 평가 체계를 적용하고, Arize AX 기반의 에이전트 개선 루프를 설계·구축·운영하는 과정을 함께 검토할 수 있습니다.

▶ 어라이즈 AI(Arize AI) 자세히보기

[출처 : Arize AI, "What is a loop in AI engineering, anyway?", Arize AI, "Building the AI factory for self-improving agents: What's new in Arize AX"]