Jarred Sumner라는 개발자는 Claude Code가 Bun 런타임의 100만 줄에 달하는 코드를 Zig에서 Rust로 변환하는 과정을 지켜보는 데 2주도 채 걸리지 않았습니다. 그는 14일 내내 앉아서 프롬프트를 하나씩 입력한 것이 아닙니다. 그는 단 한 번 576줄짜리 규칙서(rulebook)를 작성하고, 프로세스를 시작한 뒤, 모델을 중심으로 구축된 시스템이 반복 작업을 수행하도록 내버려 두었습니다. 작업이 완료되었을 때, 기존의 전체 테스트 스위트(test suite)는 병합 전 CI에서 모두 통과되었으며, 번역된 100만 줄의 코드 전체에서 발생한 회귀(regression) 오류는 단 19개뿐이었고 그마저도 모두 수정되었습니다 (Anthropic, July 2026).

이것은 더 똑똑한 모델에 관한 이야기가 아닙니다. Sumner와, 별도로 단 한 번의 주말 동안 Python 코드베이스를 165,000줄의 TypeScript로 전환한 Mike Krieger는 모두 다음에 무엇을 시도할지 결정하고, 자신의 출력을 확인하며, 매 단계마다 모델의 손을 잡아주지 않고도 계속 진행하는 프로세스를 실행하고 있었습니다.

이제 그 프로세스에 이름이 생겼습니다. 사람들은 이를 **루프 엔지니어링 (loop engineering)**이라고 부르며, 누구에게 묻느냐에 따라 이것이 채팅 인터페이스 자체 이후 엔지니어가 AI와 협업하는 방식에서 가장 유용한 변화인지, 아니면 1년 전 한 취미 활동가가 실행하던 bash 스크립트의 재브랜딩인지 의견이 갈립니다. 두 가지 모두 어느 정도 사실이며, 이 둘을 구분하는 것이 이 글의 핵심입니다.

루프 엔지니어링의 실제 정의

브랜딩을 걷어내면 정의는 간단합니다. **루프 엔지니어링 (loop engineering)**이란 사람이 한 번에 하나의 메시지를 보내며 세 가지 작업(AI 에이전트에게 프롬프트 제공, 작업 결과 확인, 다음 단계 결정)을 수동으로 수행하는 대신, AI 에이전트에게 프롬프트를 제공하고, 작업을 확인하며, 다음에 무엇을 할지 결정하는 시스템을 설계하는 관행을 말합니다.

코딩 에이전트(coding agent)와 작업하던 기존 방식은 직선형이었습니다. 지시 사항을 입력하고, 결과물을 읽고, 다음 지시 사항을 입력하는 방식이었죠. 그 사이에서 에이전트가 실제 작업을 수행하긴 했지만, 당신은 몇 초마다 교정이 필요한 운전대를 잡고 있는 것처럼 내내 에이전트를 붙들고 있어야 했습니다. 루프 엔지니어링(Loop Engineering)은 그 직선을 폐쇄형 사이클(closed cycle)로 대체합니다. 즉, 에이전트가 행동을 취하고, 작업 중인 실제 환경으로부터 피드백을 받으며, 그 피드백을 사용하여 다음에 무엇을 할지 결정하고, 당신이 사전에 정의한 조건이 진정으로 충족될 때까지 스스로 계속 진행하는 방식입니다.

이를 이해하는 가장 명확한 방법은 사람들이 말하는 재귀적 목표(recursive goal)입니다. 다음 단계를 일일이 직접 입력하는 대신, "인증(auth) 모듈의 모든 테스트를 통과시켜라"와 같이 목적을 명시하면, 에이전트는 당신이 교통정리를 하듯 지시하지 않아도 그 목적을 향해 반복(iterate)합니다. 에이전트는 코드를 검사하고, 무언가를 변경하고, 체크를 실행하고, 발생한 결과를 읽고, 다음 움직임을 결정하는 과정을 목표가 달성되거나 더 이상 진행할 수 없을 때까지 반복합니다.

용어의 유래

이 용어의 배경 이야기는 매우 중요한데, 이 용어가 퍼진 속도 자체가 그 근간이 되는 역량이 이미 얼마나 많이 변화했는지를 보여주는 증거이기 때문입니다.

2026년 6월 7일, OpenClaw 에이전트 프로젝트를 구축한 것으로 알려진 개발자 Peter Steinberger는 X(구 트위터)에 두 문장으로 된 메시지를 게시하며, 개발자들이 코딩 에이전트에게 직접 프롬프트를 입력하는 것을 멈추고, 에이전트를 대신해 프롬프트를 제공할 루프(loops)를 설계하기 시작해야 한다고 주장했습니다.

며칠 전인 6월 2일, Anthropic에서 Claude Code를 이끄는 Boris Cherny는 WorkOS Acquired Unplugged 이벤트 무대에서 이와 유사한 발언을 했습니다. 그는 더 이상 Claude에게 직접 프롬프트(prompt)를 입력하지 않으며, 그의 실제 업무는 자신을 대신해 프롬프트를 입력하는 루프(loop)를 작성하는 것이 되었다고 말했습니다. 이어 6월 8일, 엔지니어이자 저자인 Addy Osmani는 “Loop Engineering”이라는 제목의 에세이를 발표하며 이 아이디어에 구체적인 형태를 부여했습니다. 그는 다섯 가지 빌딩 블록(building blocks)과 그 아래를 받치는 여섯 번째 요소를 제시했습니다. 이 에세이는 바이럴(viral)된 의견을 다른 사람들이 기반으로 삼고 논쟁할 수 있는 하나의 어휘로 탈바꿈시켰습니다.

이 모든 것이 갑자기 나타난 것은 아니기에 그 계보를 언급할 가치가 있습니다. 직접적인 실무적 조상은 2025년 7월, 이 용어가 존재하기 몇 달 전 개발자 Geoffrey Huntley가 설명한 Ralph라는 방식입니다. 이는 에이전트(agent)가 목표를 달성할 때까지 동일한 목표에 대해 반복적으로 실행된다는 단순한 아이디어를 바탕으로 구축된 평범한 bash 루프(loop)입니다. 학술적 조상은 훨씬 더 거슬러 올라갑니다. 2022년 Yao와 동료들이 발표한, 단일 루프 내에서 추론(reasoning)과 행동(acting)을 교차시키는 ReAct 패턴, 그리고 여기에 메모리(memory)와 자기 비판(self-critique)을 추가한 2023년 Shinn과 동료들의 Reflexion이 있습니다. 2026년 6월의 순간은 이 중 그 무엇도 발명하지 않았습니다. 다만 연구자뿐만 아니라 일반 개발자들에게도 의도적으로 루프를 구축하기 시작할 이유와 공유된 어휘를 제공했을 뿐입니다.

그리고 이 용어는 여전히 변화하고 있습니다. 2026년 7월 18일, Steinberger는 다시 한번 게시물을 올렸는데, 이번에는 루프 시대가 이미 그가 그래프 엔지니어링 (graph engineering)이라고 부르는 무언가로 넘어가고 있음을 시사했습니다. 이는 하나의 루프 대신, 팀들이 여러 개의 상호 연결된 루프를 실제 의존성(dependencies)을 가진 상태로 서로 엮는 방식입니다.

프롬프트, 컨텍스트, 그리고 하네스 엔지니어링과의 관계

Loop engineering은 이전의 그 어떤 것도 대체하지 않았습니다. 이는 2022년부터 구축되어 온 발전 과정의 가장 최신 레이어(layer)이며, 각 레이어는 이전 레이어를 쓸모없게 만드는 대신 그 아래의 레이어를 감싸는 방식으로 작동합니다.

1. 프롬프트 엔지니어링 (Prompt engineering): 대략 2022년부터 2024년까지의 시기로, 단어 선택(wording)에 관한 것이었습니다. 모델에게 역할을 부여하고, 작업을 단계별로 나누며, 예시를 제공하는 작업이 핵심이었습니다. 이는 당신이 말하는 방식을 최적화했지만, 그 한계는 명확했습니다. 완벽하게 작성된 프롬프트라 할지라도 모델에게 한 번도 주어진 적 없는 사실을 전달할 수는 없기 때문입니다.

2. 컨텍스트 엔지니어링 (Context engineering): 2025년을 거치며 본격화되었으며, 초점이 단어 그 자체에서 모델이 응답하는 순간 실제로 보는 모든 것(대화 기록, 검색된 문서, 도구 출력 등)으로 이동했습니다. Anthropic은 2025년 9월 이를 추론(inference) 중에 사용 가능한 최적의 토큰 세트를 큐레이션하고 유지하는 것으로 공식화했으며, 이로 인해 프롬프팅은 별개의 분야가 아닌 더 큰 학문 체계 내부의 하나의 요소가 되었습니다.

3. 하네스 엔지니어링 (Harness engineering): 2026년 초, 에이전트(agents)가 실제 운영 환경에서 더 길고 자율적인 작업을 처리하기 시작하면서 등장했습니다. 하네스(harness)는 에이전트를 둘러싼 환경 전체를 의미합니다. 즉, 스캐폴딩(scaffolding), 도구, 제약 조건, 그리고 에이전트의 실수를 잡아내는 피드백 루프(feedback loops)를 모두 포함합니다.

Loop engineering은 이 세 가지 모두의 위에 자리 잡고 있습니다. 하네스 엔지니어링이 에이전트에게 어떤 환경이 필요한지를 묻는다면, loop engineering은 더 좁고 운영적인 질문을 던집니다. "어떤 사이클이 에이전트를 목표를 향해 계속 움직이게 만드는가, 그리고 그 사이클은 정확히 언제 멈추는가?"

당신은 여전히 프롬프트를 작성합니다. 여전히 컨텍스트를 큐레이션합니다. 여전히 하네스를 구축합니다. 루프(loop)는 단순히 이 모든 것들이 작동을 시작하고 리듬을 부여받는 지점입니다.

루프를 성공시키거나 실패하게 만드는 세 가지 요소

Anthropic의 자체 팀부터 IBM의 설명서, 그리고 이미 프로덕션 환경에서 루프를 운영 중인 실무자들에 이르기까지, 이 주제에 대한 모든 진지한 논의는 동일한 세 가지 난제로 수렴됩니다. 이 중 하나라도 잘못되면 루프는 유용성을 상실하며, 때로는 소리 없이 작동을 멈추기도 합니다.

1. **컨텍스트 관리 (Context management)**가 첫 번째입니다. 컨텍스트 윈도우 (Context window)는 에이전트의 작업 기억 (Working memory)이며, 여기에는 엄격한 한계가 있습니다. 긴 루프의 매 단계는 그 기록에 더 많은 내용을 추가합니다. 더 많은 추론 (Reasoning), 더 많은 도구 출력 (Tool output), 더 많은 오류 등이 쌓이게 됩니다. 이를 관리하지 않으면 그 기록은 완전히 넘쳐버리거나, 규모가 커짐에 따라 품질이 저하됩니다. 사람들은 이를 '컨텍스트 부패 (Context rot)'라고 부르기 시작했는데, 이는 모델이 점점 길어지는 트랜스크립트 (Transcript) 내부에 묻혀 있는 실제로 중요한 정보에 덜 신뢰성 있게 집중하게 되는 현상을 말합니다. 해결책은 오래된 단계들을 짧은 요약본으로 압축하고, 오래된 출력을 가지치기 (Pruning)하며, 서브 에이전트 (Sub-agents)에게 사이드 태스크 (Side tasks)를 위한 깨끗한 컨텍스트 윈도우를 별도로 부여하여 오직 결론만을 보고하도록 하는 것입니다.

2. **종료 (Termination)**가 두 번째이며, 이를 잘못 설정하는 것은 루프 설계에서 아마도 단일 항목 중 가장 비용이 많이 드는 실수일 것입니다. 루프에는 서로 중첩된 여러 개의 독립적인 탈출구가 필요합니다. 실제 목표가 달성되었는지 확인하는 검증기 (Verifier), 반복 횟수에 대한 엄격한 상한선 (Hard ceiling), 토큰 또는 시간 예산, 그리고 더 미묘한 요소인 '진전 없음 감지 (No-progress detection)'가 필요합니다. 진전 없음 감지는 마지막 몇 단계가 동일한 오류를 생성하거나 상태를 기능적으로 변화 없이 그대로 두는 경우를 포착합니다. 이러한 계층화된 탈출 장치 없이는 루프가 영원히 실행되거나, 추측에 따라 임의로 멈춰버리게 되며, 당신이 잠든 동안 실행되도록 설계된 시스템에서 이 두 가지 상황 모두 용납될 수 없습니다. 이는 가설적인 위험이 아닙니다. 보도에 따르면 Uber는 회사의 연간 AI 예산을 4개월 만에 소진한 후, 엔지니어당 AI 코딩 도구 사용료를 월 1,500달러로 제한했다고 합니다. 실질적인 종료 로직이 없는 무제한 루프는 이러한 종류의 예상치 못한 비용 발생의 큰 원인입니다.

**검증 (Verification)**은 세 번째 단계이며, 이는 본질적으로 신뢰의 문제입니다. 가장 이상적인 표준은 결정론적 검증 (deterministic verification)입니다. 즉, 테스트 (tests), 타입 체커 (type checkers), 컴파일러 (compilers), 린터 (linters)와 같이 모델이 논리로 빠져나갈 수 없는 객관적인 통과(pass) 또는 실패(fail)를 반환하는 도구들입니다. 모델이 스스로의 판사 역할을 하는 방식은 더 유연하며 기계적으로 확인할 수 없는 모든 작업에 진정으로 필요하지만, 동시에 속임수(gameable)에 취약합니다. 자신이 생성한 결과물을 스스로 채점하는 모델은 구조적으로 설계 단계부터 취약한 검증 방식입니다. 가장 강력한 루프는 결정론적 검증기 (deterministic verifier)가 존재할 수 있는 곳이라면 어디든 그에 의존하며, 모델의 판단은 오직 다른 방법으로는 측정할 수 없는 작업의 특정 부분에만 한정하여 사용합니다.

튜토리얼: 작은 작동 루프 구축하기

위의 모든 내용은 실제로 루프를 직접 구축해 본 후에야 더 쉽게 이해할 수 있습니다. 따라서 이 섹션에서는 처음부터 끝까지 실제적이고 작으며 위험 부담이 적은 루프를 단계별로 살펴봅니다. 작업 목표는 다음과 같습니다: 저장소 내의 한 디렉토리를 대상으로 매일 밤 린트(lint)를 수행하고, 안전하게 수정 가능한 부분을 고친 뒤, 발생한 일에 대한 기록을 남기는 것. 의도적으로 화려함은 배제했습니다. 루프 엔지니어링 (loop engineering)의 가치는 처음부터 무엇을 크게 자동화하느냐에 있는 것이 아니라, 중요한 작업에 적용하기 전에 각 구성 요소들이 실제로 잘 맞물려 돌아가는지 확인하는 데 있습니다.

1단계: 명확한 종료 조건이 있는 목표 설정하기

"코드를 정리하라"는 에이전트나 인간 모두가 검증할 수 있는 목표가 아닙니다. 반면 "/src/utils 내의 모든 파일이 eslint를 통과하며 에러가 0개여야 하고, 해당 디렉토리 내의 기존 테스트 중 실패하는 것이 없어야 한다"는 검증 가능한 목표입니다. 이 두 문장의 차이가 바로 이 학문 전체를 축소해 놓은 핵심입니다.

2단계: 다른 무엇보다 검증기(verifier)를 먼저 작성하기

검증기는 "완료"라는 상태가 모델의 주관적인 의견이 아닌, 실질적인 의미를 갖게 만드는 요소입니다. 이 루프의 경우, 두 가지 명령어가 검증기 역할을 합니다: 린터 (linter), 그리고 수정 대상 디렉토리에 한정된 기존 테스트 스위트 (test suite)입니다. 두 명령어가 모두 깨끗한 결과를 반환하면 루프는 종료될 수 있습니다. 만약 어느 하나라도 실패하면, 루프는 계속 진행하거나 다음 단계로 에스컬레이션 (escalate)합니다.

**3단계: 루프 자체를 작성하기

오늘날 사용되는 거의 모든 프로덕션 루프 (production loop)의 밑바탕이 되는 골격은 다음과 같습니다.

# state는 목표와 더불어, 지금까지 시도된 내용에 대한
# 실행 중인 스크래치패드 (scratchpad)를 보유합니다. 이것이
# 루프를 통과할 때마다 모델에 다시 피드백되는 정보이며,
# 디스크에 기록되는 내용이기도 합니다.
...