(About ~15 min to read)

들어가며

LLM과 Agent를 다루는 기술에는 짧은 주기로 새 이름이 등장합니다. Prompt Engineering이 겨우 익숙해질 만하니 Context Engineering이 나왔고, Harness Engineering이라는 말이 아직 생소한데도 Loop Engineering이 등장했습니다. 용어마다 강의가 열리고 논쟁이 이어지다 보니 하나하나 쫓다가 전체 지형을 잃기 쉽습니다.

[LLM 기초 쌓기]는 그 지형도를 그리는 시리즈입니다. 최근 등장하는 AI 관련 용어 중 상당수는 이미 존재하던 것들에 이름을 붙이고 표준화한 경우입니다. 따라서 테크닉을 하나 더 배우는 것보다, 테크닉들이 놓이는 지형을 아는 것이 더 도움이 될 것입니다.

첫 주제는 나름 첨단에 있는 용어인 Loop Engineering입니다. 이번 기초편에서 개념을 잡고, 다음 실습편에서 직접 만들고 굴려보는 이야기를 하겠습니다.

1. 2026년 6월, 한 주 만에 생긴 단어와 그 유혹

다음 지시는 언제나 사람에게서 나왔다

먼저 이 글의 주인공인 에이전트(Agent)부터 간단히 설명하겠습니다. LLM에게 파일 수정, 명령 실행, 웹 검색 등 외부와 소통할 수 있는 도구(Tool)를 쥐여주고, 도구를 호출하고 결과를 관찰하고 다음 행동을 정하는 일을 스스로 반복하게 만든 시스템을 에이전트라 부릅니다. Claude Code나 Codex처럼 코드를 다루는 것이 코딩 에이전트이고, 이 글의 담론도 대부분 여기서 나옵니다.

그런데 이 에이전트가 아무리 좋아져도 이상하게 해소되지 않는 피로가 있습니다. 에이전트는 한 가지 일을 끝내면 멈춰서 기다립니다. “다음은 이거 해줘”, “이제 테스트 돌려봐”, “결과 보고 고쳐줘”. 이처럼 다음 작업 지시는 언제나 사람에게서 나옵니다. 에이전트는 자동인데, 에이전트를 돌리는 일은 수동인 역설입니다.

자고 일어나면 끝나 있다는 유혹

2026년 6월 초·중순의 한 주 사이, 이 피로에 이름이 붙었습니다. 오픈소스 에이전트 OpenClaw를 만든 Peter Steinberger가 “더 이상 코딩 에이전트를 프롬프팅하지 말고, 에이전트를 프롬프팅하는 루프를 설계하라”는 포스트로 수백만 뷰를 기록했고, 거의 같은 시기에 Anthropic에서 Claude Code를 이끄는 Boris Cherny도 같은 말을 하고 있었습니다. “나는 더 이상 Claude를 프롬프팅하지 않는다. Claude를 프롬프팅하고 무엇을 할지 정하는 루프들이 돌고 있다. 내 일은 루프를 쓰는 것이다.” 그리고 6월 7일, Google에서 Chrome과 AI 개발자 경험을 이끌었던 Addy Osmani가 이 흐름을 Loop Engineering이라는 이름으로 정리해 블로그에 올렸습니다. 한 문장이 그렇게 빨리 퍼졌다는 것은, 같은 피로가 그만큼 널리 공유되어 있었다는 뜻입니다.

그림 1: 2026년 6월, 한 주 사이의 명명 과정 — Steinberger의 포스트에서 Osmani의 명명까지.

Osmani의 정의는 짧습니다. 에이전트를 프롬프팅하는 사람의 자리에서 자신을 대체하고, 그 일을 대신할 시스템을 설계하는 것. 여기서 말하는 시스템이 곧 실행되는 루프입니다. 그리고 루프를 정의해 사람이 Harness에 건네는 문서가 루프 명세(loop specification)입니다. Harness는 에이전트를 감싸 도구 실행과 작업 환경을 제공하는 소프트웨어를 말하며, Codex, Kiro, Claude Code 같은 제품이 그 구현체입니다. 명세에 무엇이 들어가고 왜 그 자리에 있는지는 3장과 5장에서 해부합니다.

말 그대로, 자는 동안 알아서 개선 및 완료되는 시스템. 이 유혹을 어디까지 믿어도 되는지는 마지막 장에서 다시 짚겠습니다.

왜 하필 지금인가

“또 XX Engineering이냐”는 생각이 들 수 있습니다. 하지만 이 용어는 앞선 것들과 성격이 하나 다릅니다. Prompt와 Context는 모델에게 무엇을 말하고 보여 줄지, Harness는 에이전트가 어떤 환경에서 일할지를 설계합니다. Loop Engineering은 그 전제를 변화시킵니다. 매 단계 다음 지시를 내리는 자리에서 사람을 빼는 것입니다.

이 흐름의 배경은 세 가지로 설명할 수 있습니다. 에이전트가 사람이 지켜보지 않아도 일반적인 작업을 끝낼 만큼 신뢰할 수 있게 됐고, 주요 코딩 에이전트 제품에 스케줄링 기능이 들어왔고, 한 번의 실행 비용이 “반복해서 돌려도 아깝지 않은” 수준까지 내려왔습니다. 재료가 다 갖춰지면 조합은 시간문제입니다. 실제로 사람들은 그 단어가 생기기 전부터 이미 루프를 만들고 있었고, Loop Engineering은 거기에 이름이 붙었을 뿐입니다.

2. Prompt → Context → Harness → Loop: 4계층 한눈에 보기

네 개의 용어는 서로를 대체하는 기술이 아니라, LLM에게 건네는 지시부터 여러 실행이 이어지는 전체 과정까지 설계할 수 있는 영역을 차례로 넓혀 본 지도에 가깝습니다.

대상의 범위도 다릅니다. Prompt와 Context는 모든 LLM 활용에 적용되지만, Harness부터는 도구를 쥔 에이전트의 영역입니다.

Prompt Engineering은 모델에게 직접 건넬 지시를 설계합니다. 어떤 문구와 예시를 쓰고, 어떤 역할과 톤을 부여할지가 이 영역의 관심사입니다.

Context Engineering은 각 추론 시점에 모델이 볼 정보를 설계합니다. 무엇을 검색해 넣고, 무엇을 요약하며, 낡은 정보를 언제 치울지를 계속 관리합니다. 이때 모델이 한 번의 추론에서 볼 수 있는 정보 공간을 컨텍스트 윈도우(context window)라 부릅니다. 프롬프트가 좋아도 컨텍스트에 잘못된 정보가 들어 있으면 좋은 결과를 기대하기 어렵습니다.

Harness Engineering은 에이전트가 일하는 환경과 방식을 설계합니다. 어떤 도구와 행동을 허용하고, 실패하면 어떻게 복구하며, 무엇을 개별 실행(run)의 완료로 판정할지 정합니다.

Loop Engineering은 실행과 실행이 이어지는 방식과 반복 전체의 종료를 설계합니다. 매 단계 다음 지시를 내리던 사람의 자리를 시스템이 대신하는 층입니다. 이전 실행의 결과와 상태, 검증 결과가 피드백이 되어 다음 행동을 바꾸고, 정해진 규칙에 따라 반복을 계속하거나 멈추게 합니다.

그림 2: prompt → context → harness → loop로 이어지는 4계층의 진행과 층별 핵심 질문. (원 그림: S. Macedo, arXiv:2607.00038 Figure 1, CC BY 4.0 — 한국어 재구성)

이 계층은 Claude Code, Codex, Kiro 같은 특정 제품의 고정된 아키텍처나 기술적 성숙도를 뜻하지 않습니다. 하나의 제품이 여러 층의 역할을 함께 구현할 수 있습니다.

루프를 루프로 만드는 것은 피드백 구조이고, 그 피드백을 믿을 수 있게 만드는 핵심 장치는 검증입니다. Harness에서 말하는 완료(done)는 개별 실행의 종료이고, Loop의 종료 상태는 반복 전체를 언제 어떻게 끝낼 것인가에 대한 정책입니다.

각 층은 이전 층을 버리지 않습니다. Loop 안의 각 실행에도 여전히 Prompt와 Context가 필요하고, 에이전트는 여전히 Harness가 마련한 환경에서 일합니다.

3. 우리가 다루는 루프

에이전트에는 이미 루프가 있습니다. 그런데 Loop 라는 단어가 서로 다른 층위의 개념을 가리키므로, 먼저 세 가지 의미를 구분할 필요가 있습니다.

첫째, 프로그래밍 루프. 그냥 제어 흐름입니다. 여기선 다루지 않습니다.

둘째, 에이전트의 내부 사이클. 한 실행(run) 안에서 도는 순환입니다. 모델이 다음 행동을 정하고 도구를 호출하면 Harness가 도구를 실행해 결과를 돌려주고, 모델은 그 결과를 보고 다음 행동을 다시 정합니다. ReAct(모델이 추론과 행동을 번갈아 수행하도록 이끈 프롬프팅 패턴) 이후의 연구와 프레임워크가 이 구조를 정형화했고, 오늘날 대부분의 에이전트 Harness가 이를 기본 실행 구조로 제공합니다.

셋째, 루프 명세(loop specification)가 정의하는 외부 루프. 사람이 설계해서 Harness에 건네는 외부 명세로 실행과 실행을 잇는 반복을 정의합니다. 에이전트가 언제 깨어나고 무엇을 목표로 일할지, 한 실행의 결과와 상태를 다음 행동에 어떻게 반영할지, 반복 전체를 언제 끝내고 사람에게 통제를 돌려줄지를 정합니다.

내부 사이클과 외부 명세를 구분하지 않으면 Loop Engineering은 에이전트에 이미 있는 반복 구조를 새 이름으로 부르는 것처럼 보입니다. 내부 사이클이 Harness 안에서 도는 엔진이라면, 루프 명세는 그 엔진을 언제 가동하고 어디에서 멈출지 정하는 운행 계획에 가깝습니다.

그림 3: 내부 사이클과 외부 루프 — Harness 안에서 도는 내부 사이클(엔진)과, 루프 명세가 정의하는 외부 루프(운행 계획).

여기서 인프라에 익숙한 독자라면 이런 질문을 떠올릴 수 있습니다. 스케줄러가 정해진 시간마다 에이전트를 호출하거나, 매니지드 워크플로 서비스가 에이전트 작업을 반복시키는 것도 이 글에서 말하는 루프일까요?

에이전트가 반복 작업을 진행한다는 사실만으로 루프가 되는 것은 아닙니다. 위와 같은 구조는 반복되더라도 매번 독립적으로 끝나는 일회성 실행의 나열입니다. 이전 실행에서 얻은 피드백이 다음 행동을 바꿀 때만 루프라고 할 수 있습니다. 바로 이 점이 루프가 필요한 순간과 그렇지 않은 순간을 구분 짓습니다.

워크플로의 조건 분기도 이전 출력에 따라 갈라지니, 그것도 루프일까요? 차이는 다음 행동을 정하는 주체에 있습니다. 워크플로 내의 분기는 설계자가 미리 만들어 둔 경로 중 하나를 고르는 것이고, 루프 안의 에이전트는 피드백을 해석해 열거된 적 없는 다음 행동을 스스로 정합니다.

4. LLM의 실수는 살아남은 횟수만큼 비용이 커진다

루프가 무엇인지 그렸으니, 이제 루프가 위험해지는 지점을 보겠습니다. 루프는 조심스럽게 설계해야 합니다. 오류가 어디에 남는지에 따라 그 비용이 달라지기 때문입니다. 에이전트가 각 층에서 잘못된 가정 하나를 사실로 받아들였다고 해봅시다.

층	잘못된 정보가 남는 곳	발견과 복구
Prompt	한 번의 답변	사람이 다음 교환에서 확인하고 지시를 고친다
Context	컨텍스트 윈도우	걷어 내기 전까지 여러 판단이 같은 방향으로 틀어진다
Harness	코드와 문서	실행이 끝나면 diff가 보이고, 리뷰에서 되돌릴 수 있다
Loop	다음 실행의 전제	후속 실행이 위에 쌓여, 발견 시점에는 되돌리기 어렵다

아래로 갈수록 오류의 생존 기간이 길어집니다. Loop 층에 이르면 누군가 완성된 결과를 들여다볼 때쯤 잘못된 가정이 여러 결정의 하중을 받치고 있어, 수정이 힘듭니다.

실수의 비용은 잘못된 가정 위에 후속 판단이 쌓일수록 커집니다. 검증 없는 루프는 오류가 여러 실행 속에서 살아남을 가능성을 높입니다. 반대로 매 실행마다 신뢰할 수 있는 검증을 수행하는 루프는 사람의 간헐적인 확인보다 오류를 먼저 발견할 수도 있습니다. 위험의 본질은 반복 자체가 아니라 검증되지 않은 출력이 신뢰받는 상태로 다음 입력으로 전달되는 것입니다.

그래서 루프 명세에는 무엇을 반복할지만이 아니라, 무엇을 검증하고 언제 멈추며 어떤 상태를 다음 실행에 넘길지도 들어가야 합니다.

5. Loop Specification: 루프 명세 해부

사람이 설계해 Harness에 건네는 루프 명세에는 무엇이 들어갈까요? 바로 다섯 가지 구성 요소와, 실행 사이의 상태를 이어 주는 메모리입니다.

트리거(trigger) — 사람이 직접 시작하거나, 정해진 스케줄에 깨어나거나, 새 PR 같은 이벤트에 반응합니다. 에이전트 제품에 내장된 스케줄러일 수도, 이미 운영 중인 스케줄러나 이벤트 버스일 수도 있습니다.

목표(goal) — 루프가 도달하려는 상태입니다. 테스트, 숫자, 규칙으로 판정할 수 있는 목표는 성공을 판단할 분명한 정지 조건을 제공합니다. 반대로 “노벨상급 소설 쓰기”처럼 순수한 취향에 가까운 목표는 멈출 근거가 되는 재현 가능한 확인 수단이 없어, 그대로는 루프로 돌릴 수 없습니다. 굳이 루프에 올리려면 명시적인 채점 기준, 인간 체크포인트, 예산 기반 종료로 목표 자체를 다시 정의해야 합니다.

실행(execution) — 한 번의 실행에서 에이전트가 실제로 일하는 단계입니다. 반복되는 작업을 검증된 스킬(skill, 에이전트가 호출해 쓰도록 작업 절차를 패키징한 문서)로 분리하면 매 실행의 편차를 줄이고 재사용할 수 있습니다.

검증(verification) — 현재 결과가 목표를 충족했다는 증거를 확인하는 단계입니다. 루프의 심장에 해당하므로 다음 장에서 별도로 살펴보겠습니다.

정지 규칙(stopping rule)과 종료 상태 — 목표 충족, 개선 없음, 예산 상한 등의 종료 조건을 보고 반복을 계속할지 끝낼지 결정합니다. 끝났다면 그 이유를 성공(success), 할 일 없음(no-op), 막힘(blocked), 정체(stalled), 예산 소진(exhausted)처럼 이름 붙은 상태로 남깁니다. 성공 이외의 이유로 멈춘 상태를 성공으로 오해하지 않도록 만드는 것이 핵심입니다.

메모리(memory) — 모델은 실행 사이의 상태를 스스로 보존하지 않습니다. 다음 실행이 이어서 일할 수 있도록 진행 상황, 결정, 검증 결과와 다음 행동을 파일과 Git 저장소, 데이터베이스, 객체 저장소나 작업 보드 같은 외부 영속 저장소에 남겨야 합니다. stateless한 서버리스 함수가 상태를 외부 저장소에 두는 것과 같은 원리입니다. 메모리는 대화 전체를 쌓는 공간이 아니라, 다음 판단에 필요한 상태를 선별하고 갱신하는 장치입니다.

그림 4: 루프 명세 해부도 — trigger가 실행을 시작하고, execution의 결과를 goal에 비춰 verify한 뒤 stopping rule이 계속 또는 종료 상태를 결정한다. memory는 결과와 결정을 다음 실행으로 전달하고, 예산 상한과 “개선 없음” 감지가 브레이크로 작동한다. (원 그림: S. Macedo, arXiv:2607.00038 Figure 2, CC BY 4.0 — 한국어 재구성)

6. 심장은 프롬프트가 아니라 검증이다

문제는 어떤 증거를 “완료됐는가”의 성공 판정으로 받아들일 것인가입니다. 실행 결과에 대해 “아니오”라고 말할 장치가 없는 루프는 잘못 설계된 루프입니다.

검증의 다섯 레벨

루프 안의 검증이라고 다 같은 검증이 아닙니다. 루프의 검증 방식을 다섯 레벨로 나눌 수 있습니다. 다만 절대적인 정확도 순위는 아닙니다.

• L1 결정론적(deterministic) 검증: assertion, exit code, 기대 출력 비교처럼 명시된 조건에서 성공과 실패가 기계적으로 정해지는 검사입니다. 즉시 자동으로 실행할 수 있고 재현 가능합니다.
• L2 규칙 검증: 린터, 스키마, 정책처럼 정해진 형식과 제약을 지켰는지 확인합니다. 역시 자동화와 재현이 가능합니다.
• L3 실환경 검증: 배포 상태, 운영 환경에서의 테스트, 실제 사용자 반응처럼 외부 환경에서 결과가 늦게 돌아오는 검증입니다. 실제 동작에 가깝지만 느리고 노이즈가 있을 수 있습니다.
• L4 모델 판정(model-as-judge): 모델이 루브릭에 따라 품질을 평가합니다. 빠르게 실행할 수 있지만 프롬프트와 컨텍스트에 민감한 모델의 판단입니다.
• L5 인간 체크포인트: 사람이 직접 검토하고 승인합니다. 자동 검증이 아니라 인간의 감독입니다.

레벨은 도구의 이름보다 최종 판정이 기대는 증거로 구분합니다. 같은 테스트라도 통제된 조건에서 즉시 exit code를 반환하면 L1에 가깝고, 배포·운영 환경에 의존해 결과가 늦게 돌아오면 L3에 가깝습니다.

그림 5: 검증의 다섯 레벨 — 위쪽일수록 판정이 기계적이고 재현 가능하다. L4 및 L5는 모델 또는 사람의 판단이 개입하는 검증이다. (원 그림: S. Macedo, arXiv:2607.00038 Figure 3, CC BY 4.0 — 한국어 재구성)

이 분류 체계는 설계 도구로 활용할 수 있습니다. 검증 설계 시, 목표에서 기계적으로 확인할 수 있는 부분을 먼저 찾아 L1·L2로 바꿉니다. “문서의 요약이 괜찮은가”처럼 직관적으로 L4·L5만 가능해 보이는 질문에서도 글자 수, 필수 섹션, 출처 URL의 존재는 규칙으로 검사할 수 있습니다. 객관적으로 분해할 수 있는 부분을 늘리되, 남은 판단의 수준을 숨기지 않는 것이 루프 설계의 중요한 포인트입니다.

L4 Tip: 왜 자기 채점만으로는 부족한가

에이전트가 방금 만든 결과를 같은 컨텍스트에서 평가하면 생성 과정의 근거와 자기설득까지 함께 보게 됩니다. 그 결과 자신의 가정과 맹점을 공유하고, 결과를 후하게 해석할 수 있습니다. 생성과 평가를 같은 모델 컨텍스트에서 반복하면 평가 점수만 오르는 reward hacking이 자발적으로 나타난다는 실험 보고도 있습니다(Pan et al., 2024). 그렇기에 최소한 생성과 평가의 컨텍스트를 분리해야 합니다. 가능하면 별도의 세션에서 평가 기준과 현재 결과물만 전달하고, 생성자의 자기변호와 작업 이력은 넘기지 않아야 합니다.

이 구조를 실제로 적용할 때는 두 가지 실무 원칙이 유용합니다.

첫째, 별도의 평가자에게 회의적인 역할과 명확한 반려 기준을 줍니다. 생성자를 자기비판적으로 만들기보다는, 평가자가 새로운 컨텍스트에서 실패한 증거와 반례를 먼저 찾고 반려 사유를 생성자에게 돌려주게 하는 편이 생성자의 자기설득과 맹점을 그대로 공유할 가능성을 줄일 수 있습니다.

둘째, 평가자는 읽는 데서 멈추지 않아야 합니다. 특히 개발 영역에서 코드를 읽는 것만으로는 “맞아 보이는가”를 판단할 수 있을 뿐, 실제로 동작하는지는 확인할 수 없습니다. 가능한 경우 평가자가 직접 페이지를 열고 버튼을 클릭하고 테스트를 실행해 증거를 수집하게 합니다. 그러면 판정의 근거가 “괜찮아 보인다”에서 “직접 실행했고 이 결과를 관찰했다”로 바뀝니다. 평가자의 기본값은 신뢰보다 의심에 가깝습니다. “증명되기 전까지 깨져 있다”고 가정하고 승인할 근거를 직접 수집하게 합니다.

7. 마무리 — 루프는 판단을 자동화하지 않는다

1장의 유혹으로 돌아가겠습니다. “자는 동안 알아서 개선 및 완료되는 시스템”은 이 분야에서 가장 매력적이지만, 가장 쉽게 오해가 쌓이는 부분입니다. 오해의 핵심은 루프가 판단까지 자동화해 준다는 기대입니다.

여기서 판단은 에이전트가 실행 중 내리는 모든 선택을 뜻하지 않습니다. 피드백을 보고 다음 행동을 정하는 것은 루프 안에서 자동화되지만, 무엇을 목표로 삼고 무엇을 성공으로 인정할지는 루프가 스스로 정하지 않습니다.

루프가 자동화하는 것	사람에게 남는 것
지시문 타이핑	목표와 성공 기준
반복 실행	어떤 증거를 성공으로 인정할지
피드백에 따른 국소적 선택	통제를 돌려받을 경계와 최종 책임

Loop Engineering은 판단을 없애는 기술이 아니라, 목표와 성공 기준, 사람에게 통제를 돌려줄 경계를 실행 전에 시스템으로 옮겨 적는 기술입니다. 루프는 그 범위 안에서 반복과 국소적인 선택을 자동화하지만, 목표와 허용 가능한 위험, 최종 책임은 사람에게 남습니다. 지시 입력이 줄어도 검토가 사라지는 것은 아닙니다. 생성 속도가 빨라질수록 사람이 확인해야 할 결과도 늘어나므로, 병목은 생성에서 검토와 책임으로 이동할 수 있습니다. 한 연구자의 표현을 빌리면, 루프가 자동화하는 것은 지시문 타이핑이지 판단이 아닙니다.

다음 실습편에서는 이 원칙을 반영한 루프 명세를 직접 작성하고 실행까지 해볼 예정입니다. 루프 명세 작성을 돕는 인터뷰 스킬과, 실제로 사용하며 얻은 시행착오를 공유하겠습니다.

---

참고 문헌

• S. Macedo, “Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting,” arXiv:2607.00038, 2026 (CC BY 4.0). — 3장의 세 가지 루프 구분과 엔진/파일럿 비유, “피드백이 다음 행동을 바꿀 때만” 원칙, 검증 레벨, 루프 명세 5요소 (trigger·goal·execution·verification·stopping rule)+메모리, 노벨상 예시, “타이핑을 자동화할 뿐 판단은 아니다”
• “Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents,” HuaShu Orange Book v260615의 IEEE 스타일 독립 재조판, 2026 (huasheng.ai/orange-books). — 4계층 프레임, 탄생 서사(“한 주 사이”, 배경 세 가지), 4장 층별 오류 생존 예시, 생성자/평가자 사례의 출처 (실무 가이드)
• J. Pan et al., “Spontaneous Reward Hacking in Iterative Self-Refinement,” arXiv:2407.04549, 2024. — 6장 자기 채점의 한계(생성·평가 컨텍스트 분리) 근거
• A. Osmani, “Loop Engineering,” addyosmani.com, 2026-06-07. — 정의, Cherny·Steinberger 발언의 재인용 출처. Osmani도 루프의 “다섯 요소”를 꼽지만(automations·worktrees·skills·connectors·sub-agents) 이는 도구 부품 목록으로, 5장의 Macedo 5요소(명세 구성 요소)와 층이 다름