좋은 에이전트는 더 많이 반복하는 에이전트가 아니라, 언제 멈춰야 하는지 아는 에이전트다.
← 옆으로 밀어 전체 보기
"Loop Engineering"은 아직 굳어진 분야명이 아니다. 2026년 Macedo의 Stop Hand-Holding Your Coding Agent가 이 용어를 명시적으로 정의했고, 2026년 8월의 LoopsBench가 "Harness Engineering → Loop Engineering"이라는 전환을 코딩 에이전트 평가의 연구 문제로 직접 제시했다. 반면 2025년에는 같은 구성 요소들이 Self-Evolving Agents, Agentic Context Engineering, Adaptive Memory, Generation–Verification 같은 다른 이름으로 흩어져 연구되고 있었다.
따라서 이 글은 직접적으로 Loop Engineering을 표방하는 2026년 문헌과 그 토대를 만든 2025–2026년 self-evolving agent 연구를 하나의 연구 계보로 묶어 재구성한 것이다. 인용된 2026년 문헌 상당수는 아직 arXiv 프리프린트 단계이므로, 식별번호와 수치는 원문 대조가 필요하다.
Loop Engineering의 설계 대상은 프롬프트가 아니다. 루프 명세(loop specification)다. 이것이 이 분야를 다른 모든 것과 구분하는 첫 문장이다.
Macedo는 루프 명세를 대략 트리거·목표·검증 단계·정지 규칙·기억을 갖춘 재사용 가능한 외부 실행 명세로 정의한다. 이것은 프로그램의 for나 while이 아니다. 에이전트 내부의 단순한 perceive–act–observe 순환도 아니다. 하네스 위에서 장기 목표를 지속시키는 상위 제어 구조(outer control structure)에 가깝다.
LoopsBench는 이 관점을 한 단계 더 확장한다. 장기 코딩 에이전트에서 루프는 "다시 시도할지"만 결정하는 장치가 아니다. 과제 구조, 상태 연속성, 잔여 작업, 회귀 압력까지 관리해야 하는 장치다.
Loop Engineering은 LLM 에이전트가 장기 목표를 자율적으로 수행하도록, 목표·상태·행동·도구·검증·피드백·기억·재계획·종료 조건·자원·권한을 연결하는 반복적 폐루프 제어 구조를 설계하고 검증하고 최적화하는 공학적·학습적 연구 분야다.
여러 연구를 종합해 확장하면 루프 명세는 아홉 개 항의 튜플로 표현된다. 앞의 다섯 항은 Macedo의 명시적 정의와 직접 연결되고, 나머지 넷은 AHE·ACE·LoopsBench·LOGOS의 2025–2026년 결과를 종합한 확장이다.
Prompt Engineering은 "다음 답을 어떻게 얻을 것인가"를 설계한다.
Loop Engineering은 "답이 틀렸거나 불완전할 때 시스템이 그다음 무엇을 할 것인가"까지 설계한다.
주어진 (목표, 에이전트, 환경, 도구, 예산)에 대해 단발성 응답 y 하나를 만드는 것이 목적이 아니다. 목적은 장기 궤적을 만드는 것이다.
그리고 이 궤적을 만들어 내는 루프 ℒ 자체를 최적화 변수로 놓는다.
최근 연구가 발견한 가장 중요한 사실은 단순하고 불편하다.
2026년 Progress Mirage 연구에서 에이전트는 모든 사이클에서 스스로 개선되었다고 주장했다. 그러나 실제 측정에서는 56%가 변화 없음 또는 악화였다. 더 심각한 것은 판정자 쪽이다. 강한 in-band LLM judge조차 실제 회귀의 44%를 개선으로 받아들였고, 실제 개선의 38%를 거부했다. 연구진의 결론은 명확하다. 성공 신호가 트랜스크립트 바깥의 현실 상태에 존재한다면, 외부 세계에 접지된 검증자가 구조적으로 필요하다.
그러므로 이 분야의 핵심 문제는 "에이전트를 여러 번 실행하자"가 아니다.
어떤 증거에 근거해 다시 실행하고, 무엇을 수정하고, 어떤 상태를 보존하고, 언제 성공했다고 믿으며, 언제 멈출 것인가.
현재의 연구 흐름은 네 개의 층으로 보면 아주 명료해진다. 각 층은 서로 다른 질문에 답하고, 뒤로 갈수록 설계 범위가 바깥으로 확장된다.
| 계층 | 중심 질문 | 주요 설계 대상 |
|---|---|---|
| Prompt Engineering | 무엇을 요청할 것인가 | instruction, example |
| Context Engineering | 무엇을 보여줄 것인가 | memory, retrieved evidence, playbook |
| Harness Engineering | 무엇을 할 수 있게 할 것인가 | tools, middleware, execution |
| Loop Engineering | 어떻게 계속 진행하고 검증할 것인가 | iteration, verification, state, stop, recovery |
← 옆으로 밀어 전체 보기
ACE는 컨텍스트를 고정된 프롬프트가 아니라 시간에 따라 성장하고 정제되는 플레이북으로 다룬다. AHE는 시스템 프롬프트뿐 아니라 도구·미들웨어·기억까지 포함한 하네스 전체를 자동 진화 대상으로 만든다. Loop Engineering은 그 하네스 위에 지속적 목표 추구와 반복 제어를 다시 얹는다.
여기서 AHE의 실험 결과 하나가 특히 흥미롭다. 시스템 프롬프트만 옮겼을 때는 오히려 성능이 떨어졌고, 개선의 상당 부분은 도구·미들웨어·장기 기억이 담당했다. "좋은 에이전트 = 좋은 프롬프트"라는 관점이 "좋은 에이전트 = 좋은 시스템 + 좋은 루프"로 이동하는 이유가 이 한 줄에 들어 있다.
루프를 성립시키는 가장 중요한 요소는 생성기가 아니라 검증자다. 일반적인 형태는 다음과 같다.
ReVeal은 이를 생성–검증 교대 루프로 명시적으로 구현한다. 후보 코드와 테스트 케이스를 함께 생성하고, 외부 인터프리터의 실행 결과를 다음 턴의 피드백으로 사용한다.
2026년 VeriHarness 연구는 여기서 한 걸음 더 나아간다. 단순한 오류 메시지보다 {실패 위치, 관측된 값, 허용 가능한 대안} 형태의 구조화된 복구 정보가 훨씬 효과적이었다. 한 설정에서 성공률이 14/50에서 36/50으로 올랐다. 중요한 것은 JSON이라는 형식 자체가 아니었다. 다음 행동을 결정하는 정보의 의미적 질이었다.
긴 루프에서는 매 사이클마다 "새로운 LLM"이 등장한다고 생각하는 편이 정확하다. 이전 상태를 명시적으로 보존하지 않으면 에이전트는 같은 문제를 다시 발견하거나, 이미 해결한 문제를 다시 망가뜨린다.
추론 시점에 검증을 통과한 전략을 지속적 기억으로 쌓는다. 파라미터를 바꾸지 않고도 시스템이 학습한다.
기억을 정적 저장소가 아니라, 새 경험에 따라 연결과 표현이 변화하는 네트워크로 다룬다.
ACE는 여기서 한 단계 더 나아가 Generate → Reflect → Curate 구조를 쓴다. 전체 컨텍스트를 매번 다시 쓰지 않고 증분 델타 갱신을 수행한다. 반복적 재작성으로 세부 정보가 사라지는 컨텍스트 붕괴(context collapse)를 줄이려는 접근이다.
기존 에이전트 벤치마크에서는 마지막 결과만 맞으면 성공으로 간주하기 쉽다. 그러나 실제 장기 개발에서 진짜 중요한 실패는 이런 종류다.
새 기능은 만들었지만, 세 단계 전에 고쳐 놓은 기능을 다시 망가뜨렸다.
LoopsBench는 이 문제를 정면으로 다룬다. 이미 통과한 개발 단위의 테스트를 회귀 의무(regression obligation)로 계속 유지한다.
← 옆으로 밀어 전체 보기
2025년 연구들은 피드백 자체를 학습 자원으로 보기 시작했다. GEPA는 궤적을 자연어로 반성해 프롬프트를 진화시키고 파레토 선택을 수행한다. 저자들은 희소한 스칼라 보상보다 풍부한 자연어 피드백이 LLM에게 더 효율적인 학습 매체가 될 수 있다고 주장한다. REALM 2025의 다중 에이전트 연구는 Refinement → Execution → Evaluation → Modification → Documentation 역할을 순환시키며 에이전트 구성을 자동 개선한다.
기존 LLM 패러다임에서 능력의 중심은 모델 파라미터였다.
그러나 에이전트 시대에는 실제 시스템 성능이 이렇게 변한다.
2025년 SICA 연구가 특히 흥미로운 이유가 여기에 있다. 동일한 기반 모델을 두고도, 코딩 에이전트가 자신의 에이전트 코드와 스캐폴딩을 직접 수정함으로써 SWE-Bench Verified의 연구용 부분집합에서 17%에서 53%까지 성능이 올라갈 수 있음을 보였다. 모델은 그대로였다. 바뀐 것은 루프였다.
2025년과 2026년의 연구 질문은 서로 다르다. 한 해는 무엇을 바꿀지 물었고, 다음 해는 그 변경을 어떻게 통제할지 물었다.
A-MEM과 Dynamic Cheatsheet는 기억을, GEPA는 프롬프트를, ACE는 컨텍스트를, SICA는 에이전트 코드를, ReVeal은 생성–검증 행동을 진화 대상으로 삼았다.
Self-evolving agent 서베이는 이를 무엇을·언제·어떻게 진화시킬 것인가라는 세 질문으로 정리한다. 피드백 신호도 스칼라 보상과 텍스트 피드백으로 구분된다.
AHE는 하네스 진화를 폐루프로 만들고, Stop Hand-Holding은 명시적 루프 명세를 정의한다.
VeriHarness와 Progress Mirage는 검증자의 역할을 해부하고, LoopsBench는 루프 자체를 평가 대상으로 만든다.
연구의 축은 이 방향으로 이동하고 있다. 각 단계에서 최적화 대상이 한 겹씩 바깥으로 밀려났고, 지금 그 바깥 경계에 루프가 있다.
가장 근본적인 문제다. 에이전트가 "성공했다"고 말하는 것과 현실에서 성공한 것은 다르다.
Progress Mirage의 결과는 평가자가 동일한 트랜스크립트 안에서만 판단할 때 심각한 자기 평가 편향이 발생함을 보여 준다. 따라서 검증자는 가능한 한 에이전트가 말만으로 조작하기 어려운 채널에 접지되어야 한다.
짧은 벤치마크의 성공과 장기 실행의 성공에는 상당한 거리가 있다. SWE-EVO에서 실제 소프트웨어 진화처럼 평균 21개 파일에 걸친 다단계 변경을 요구하자 기존 단일 이슈 벤치마크 대비 성능이 크게 떨어졌다. LoopsBench에서도 가장 강한 평가 구성이 전체 장기 과제의 25%만 해결했고, 모든 루프 프로파일에서 회귀가 관찰되었다.
단일 단계 성공률을 p라 하면, 매우 단순화된 상황에서도 n단계 전체 성공 확률은 pⁿ으로 감소한다. Loop Engineering이 필요로 하는 것은 "각 단계를 잘하는 에이전트"가 아니라 오류를 탐지하고 복구해 실패의 곱셈을 끊는 시스템이다.
기억을 많이 저장한다고 항상 좋아지지 않는다. 잘못된 경험의 고착, 중복 기억, 낡은 정보, 모순되는 규칙, 컨텍스트 폭발, 반복 요약에 의한 정보 손실이 함께 발생한다. ACE가 증분적 grow-and-refine을 도입한 이유도 반복적 컨텍스트 재작성이 세부 지식을 잃게 만들기 때문이다.
성능이 좋아졌을 때 무엇 때문인가. 프롬프트인가, 도구인가, 기억인가, 모델인가, 검증자인가, 실행 순서인가. AHE는 매 변경마다 예측을 기록하고 다음 반복의 결과와 비교하는 반증 가능한 변경 명세(falsifiable change manifest)를 사용한다. 그러나 저자들도 회귀에 대한 자기 귀속이 약하다는 한계를 함께 보고한다.
좋은 루프는 무한 루프가 아니다. retry until success는 공학 명세가 아니다. 루프는 다음 상태를 서로 구별할 수 있어야 한다.
최근 루프 명세 연구가 명명된 종료 상태와 정지 규칙을 강조하는 이유가 여기에 있다. 이름 없는 종료는 검사할 수 없고, 검사할 수 없는 것은 개선할 수 없다.
에이전트와 평가자가 같은 정보, 같은 모델, 같은 목적함수를 공유하면 에이전트는 평가자가 좋아하는 출력을 학습한다.
전형적인 굿하트 문제다. ReVeal도 검증 보상을 악용하는 자명한 해를 막기 위해 별도의 강건성 장치를 도입했다.
루프가 많은 코드를 자율적으로 생성하고 수정할수록 시스템은 빠르게 발전한다. 동시에 인간이 "왜 그렇게 되었는가"를 이해하지 못할 위험도 함께 커진다. 최근 논의가 검증 부담, 이해 부채(comprehension debt), 인지적 항복(cognitive surrender)을 명시적 위험 요소로 열거하는 이유다. 이것은 성능 문제가 아니라 통제 문제다.
목표·트리거·검증·기억·정지 가운데 어떤 구성 요소가 필수이며, 도메인 독립적인 최소 루프 명세는 무엇인가.
프롬프트, 기억, 컨텍스트, 도구, 미들웨어, 하네스, 모델 가중치, 워크플로 가운데 어디를 수정하는 것이 가장 안정적인가.
매번 반성하는 편이 나은가, 실패나 불확실성이 감지될 때만 반복해야 하는가.
LLM-as-a-Judge, 자기 점검, 실행 가능한 테스트, 외부 세계 오라클은 각각 어떤 조건에서 신뢰할 수 있는가. Progress Mirage가 이 질문을 분야의 중심으로 밀어 올렸다.
단순 PASS/FAIL을 넘어 어느 정도의 진단 정보를 줘야 하는가. VeriHarness는 "가능한 대안" 정보가 특히 중요할 수 있음을 보여 준다.
어떤 정보를 작업 기억·일화 기억·의미 기억·산출물 상태로 분리할 것인가.
새 성과와 과거 성공을 동시에 유지하는 단조 혹은 근사 단조 개선을 어떻게 구현할 것인가. LoopsBench의 회귀 의무가 이 문제를 직접 겨냥한다.
더 강한 모델은 언제나 더 단순한 루프를 필요로 하는가, 아니면 모델별 최적 루프가 따로 존재하는가. AHE는 최적 하네스가 모델 특이적일 수 있음을 지적한다.
최종 성공률만으로 충분한가. LoopsBench는 의존성 진척도, 의무 유지율, 상태 연속성, 자원 사용 같은 궤적 수준 평가가 필요하다고 주장한다.
자기 자신을 바꾸는 에이전트에서 어느 변경까지 에이전트가 승인할 수 있고, 어느 변경은 인간·정책·외부 검증자가 승인해야 하는가. LOGOS 같은 연구는 학습된 프롬프트·기억·스킬·도구·워크플로를 모두 검증 전에는 신뢰되지 않는 후보로 보는 방향을 제안한다.
현재의 방법론은 크게 여덟 계열로 정리된다. 무엇을 바꾸는가, 그리고 무엇으로 그 변경을 판정하는가에 따라 갈린다.
Gₜ → Vₜ → Fₜ → Gₜ₊₁. 실행 가능한 외부 피드백으로 후보를 반복 개선한다. 가장 신뢰도 높은 루프 형태이며, 검증자가 공짜인 도메인에서 압도적으로 잘 작동한다.
궤적 → 반성 → 프롬프트 변이 → 평가 → 선택. 스칼라 보상 대신 자연어 설명으로 "왜 실패했는가"를 학습한다.
핵심은 Mₜ₊₁ = Update(Mₜ, eₜ)로 보는 것이다. 기억은 읽기 전용 데이터베이스가 아니라 학습 가능한 시스템 상태다.
에이전트가 Hₜ → Hₜ₊₁ 형태로 자신의 코드와 스캐폴딩을 수정하고, 다시 벤치마크해 더 나은 에이전트를 선택한다.
수정 공간을 프롬프트에 한정하지 않고 도구·미들웨어·기억·스킬 전체로 확대한다. 관측성을 구성 요소 · 경험 · 결정 세 층으로 구조화한다.
Refine → Execute → Evaluate → Modify → Document. 한 에이전트가 생성·평가·수정을 모두 맡을 때 생기는 자기 편향을 구조적으로 분리한다.
실제 고객 지원 상호작용에서 선호, 채택과 근거, 지식 적합성, 결손 지식을 수집해 다시 시스템 개선으로 연결한다. 오프라인 벤치마크 루프를 넘어 운영 루프로 확장한 사례다.
복잡한 목표를 평평한 목록이 아니라 DAG G=(V,E)로 본다. 부모가 충족된 노드를 준비 프런티어로 만들고, 이미 해결한 노드는 회귀 의무로 남긴다.
가장 직접적이고 가장 빠르게 발전하는 분야다. 저장소 규모의 버그 수정, 기능 개발, 리팩터링, 마이그레이션, 지속적 테스트와 복구, 소프트웨어 진화, 자기 개선 코딩 에이전트가 모두 여기에 포함된다. SICA, ReVeal, SWE-EVO, AHE, LoopsBench가 전부 이 축 위에 놓인다. 이 분야가 앞서 나가는 이유는 재능이 아니라 구조다. 컴파일러와 테스트라는 검증자가 공짜로 주어진다.
에이전트 역할과 워크플로 자체를 반복적으로 측정하고 수정한다. 실행 → KPI 측정 → 진단 → 워크플로 변경을 자동화하는 방식이며, REALM 2025의 반복적 다중 에이전트 최적화가 여기 해당한다.
Agent-in-the-Loop 같은 운영 데이터 플라이휠은 실제 운영에서 발생한 사람의 피드백을 다시 검색기와 생성 시스템의 개선으로 연결한다. 벤치마크가 아니라 매일의 트래픽이 검증자 역할을 한다.
Self-evolving agent 서베이는 프로그래밍뿐 아니라 생의학과 금융 같은 도메인 특이적 진화를 중요한 적용 영역으로 다룬다. 이 영역에서 루프는 자연어 반성만으로는 닫히지 않는다. 도메인 검증자가 반드시 들어가야 한다.
| 도메인 | 도메인 검증자 | 루프가 닫히는 지점 |
|---|---|---|
| 소프트웨어 | 컴파일러 · 테스트 스위트 | 실행 결과 |
| 금융 | 회계 규칙 · 산술 제약 | 대차 일치 검사 |
| 생의학 | 데이터베이스 · 시뮬레이션 · 제약 조건 | 정준 식별자 정합성 |
| 과학 | 실험 또는 시뮬레이션 피드백 | 물리적 측정 |
Dynamic Cheatsheet, A-MEM, ACE 계열은 에이전트가 에피소드를 넘어 경험을 축적하는 구조를 연구한다. 이 방향에서는 모델 파라미터가 같아도 다음 관계가 성립한다.
V(V(x)) = ? LLM 판정자를 더 크게 만드는 것만으로는 해결되지 않을 가능성이 최근 실험에서 나타나고 있다. 이 문제가 풀리지 않으면 자율성의 상한이 여기서 결정된다.
에이전트가 학습할수록 항상 좋아지는가. 현실에서 Qₜ₊₁ ≥ Qₜ를 보장하기는 어렵다. AHE와 LoopsBench 모두 회귀 문제가 여전히 남아 있음을 보여 준다.
기억은 상충하는 두 목표를 동시에 만족해야 한다. 유용한 옛 지식을 기억할 것, 그리고 새 증거에 적응할 것. 너무 안정적이면 학습하지 못하고, 너무 가변적이면 기존 지식을 잃는다.
L = L계획 ∘ L구현 ∘ L테스트 ∘ L리뷰일 때, 각 루프가 개별적으로 안정적이어도 전체 시스템이 진동하거나 교착에 빠질 수 있다. 이 문제에 대한 형식 이론이 현재 매우 부족하다.
P(ΔQ | ΔHᵢ)를 추정하지 못하면 에이전트 진화는 결국 시행착오 탐색에 머문다. 개선을 재현할 수 없다면 그것은 공학이 아니라 운이다.
이상적 기준은 𝔼[Qₜ₊₁ − Qₜ | xₜ] > C다음반복일 때만 계속하는 것이다. 그러나 현재 대부분의 루프는 이 정도의 정교한 연산 가치(value of computation) 정책을 갖고 있지 않다.
에이전트가 프롬프트·기억·도구·코드·워크플로까지 바꿀 수 있게 되면 공격 표면도 함께 커진다. 따라서 수정 가능 ≠ 자기 승인이어야 한다. 거버넌스 지향 연구가 수정 후보를 검증·승인 전까지 신뢰하지 않는 방향을 제안하는 이유다.
벤치마크가 고정되어 있으면 에이전트는 실제 능력 대신 벤치마크의 특성을 학습한다. Self-evolving agent 서베이도 에이전트 진화와 함께 평가 자체의 공진화가 필요하다는 문제를 제기한다.
여기부터는 앞의 논문들에서 도출할 수 있는 연구적 종합과 확장이다. 개별 논문의 주장이 아니라 그 위에 얹은 전망이다.
현재 루프는 대부분 프롬프트, 셸 스크립트, 파이썬 오케스트레이션으로 산발적으로 표현된다. 앞으로는 명시적 DSL이 가능하다.
# agent loop specification GOAL : all regression tests pass TRIGGER : new issue or failed checkpoint ACT : inspect -> modify -> test VERIFY : external executable tests MEMORY : decisions + failures + accepted patches RETRY : only on informative verifier feedback STOP : success | blocked | unsafe | budget BUDGET : 5 iterations / 200k tokens ESCALATE : human reviewer
프롬프트를 위한 프로그래밍 언어가 아니다. 자율성을 위한 프로그래밍 언어다.
지금은 대개 에이전트를 먼저 만들고 검증자를 나중에 붙인다. 앞으로는 순서가 뒤집힐 가능성이 높다.
"무엇을 성공이라고 객관적으로 측정할 것인가"가 정의되지 않은 문제는 높은 자율성을 부여하기에 부적합하다. Progress Mirage가 강하게 뒷받침하는 방향이다.
에이전트가 결과만 제출하는 대신 (행동, 증거)를 함께 제출하게 할 수 있다.
Patch + tests executed + logs + benchmark delta + dependency impact + regression checks + provenance
"믿을 수 있는 에이전트"를 만드는 것이 아니라, 증거 없이는 성공할 수 없는 에이전트를 설계하는 것이다. 신뢰를 요구하지 않는 설계가 신뢰를 요구하는 설계보다 언제나 강하다.
기억을 자연어 요약 하나로 유지하는 대신 불변 이벤트 로그 M = {e₁, e₂, …, eₙ}와 구체화된 상태로 나누는 방식이 유망하다. 출처 추적, 롤백, 인과 분석, 감사, 재현성을 동시에 개선할 수 있다.
모든 문제에 똑같이 열 번의 반성을 적용해서는 안 된다. 반복 깊이를 동적으로 선택하는 테스트 시점 연산 제어가 중요해질 것이다.
소프트웨어에 CI/CD가 있듯이 에이전트 루프에도 지속적 루프 평가가 필요해질 수 있다. 새 모델, 프롬프트, 도구, 기억 정책이 배포될 때마다 다음을 자동으로 수행하는 방식이다.
AHE가 지적하듯 모델별 하네스 최적점은 다를 수 있다. 따라서 장기적으로는 모델 ↔ Loop ABI ↔ 환경과 같은 표준 인터페이스가 필요해질 가능성이 있다. 표준화 대상은 행동 스키마, 관측 스키마, 검증 스키마, 기억 스키마, 종료 상태 스키마다.
현재 정렬 연구는 주로 모델 출력에 초점을 둔다. 그러나 장기 자율 시스템에서 중요한 것은 개별 행동이 아니라 궤적 (a₁, a₂, …, aₜ) 전체다. 앞으로는 루프 정렬(Loop Alignment)이 중요해질 것이다.
2025년과 2026년의 문헌을 한 문장으로 압축하면 이렇다.
과거에는 프롬프트 → 답을 설계했다. Loop Engineering에서는 다음 궤적 전체가 공학적 산출물이 된다.
그리고 이 패러다임의 핵심은 "더 많이 반복하는 것"이 아니다. 가장 중요한 설계 원칙은 다음 한 줄로 압축된다.
앞으로 경쟁력 있는 에이전틱 AI 시스템은 가장 강한 LLM을 쓰는 시스템이 아니다.
자신이 언제 틀렸는지 알아내고, 왜 틀렸는지 보존하며, 올바른 부분을 다시 망가뜨리지 않고, 개선이 더 이상 가치가 없거나 위험할 때 멈출 수 있는 시스템이다.
그런 점에서 Loop Engineering은 Prompt Engineering의 대체물이 아니다. 아래 표기는 엄밀한 수학적 포함관계라기보다, 설계 범위가 점차 바깥으로 확대되는 연구적 진화로 이해하는 것이 가장 정확하다.
2026년의 직접적인 Loop Engineering 논문 상당수는 아직 arXiv 프리프린트 단계다. 따라서 이 주제는 "이미 확립된 학문 분야"라기보다, Self-Evolving Agents · Context Engineering · Harness Engineering · Verification · Long-Horizon Agent Evaluation이 2026년에 하나의 시스템 연구 프레임으로 수렴하고 있는 단계로 보는 것이 현재 문헌에 가장 충실한 해석이다. 아래 식별번호와 본문의 수치는 원문 대조를 권한다.