AI 코딩 에이전트(AI Coding Agent)의 사용법이 지난 1년 사이 결정적으로 변했습니다.

불과 얼마 전까지 우리의 업무는 이랬습니다.

좋은 프롬프트(Prompt)를 작성한다. 돌아온 결과물을 읽는다. 다음 프롬프트를 작성한다. 에이전트는 도구이며, 당신은 그 도구를 "계속 손에 들고 있는" 상태입니다.

지금, 그 전제를 뒤엎는 사고방식이 확산되고 있습니다. 루프 엔지니어링 (Loop Engineering) 입니다. 한마디로 말하자면,

"에이전트에게 지시를 보내는 사람", 즉 당신 자신을 당신이 설계한 메커니즘으로 대체하는 것입니다.

Google의 Addy Osmani가 2026년 6월에 이 용어를 체계화하며 단숨에 정착시켰습니다. 루프(Loop)란 "재귀적 목표 (recursive goal)"를 의미합니다. 목적을 한 번 정의하면, 나머지는 AI가 완료될 때까지 스스로 계속 돌아갑니다. 당신의 역할은 "프롬프트를 계속 입력하는 담당자"에서 "메커니즘을 설계하는 엔지니어"로 옮겨갑니다.

서론 ── 이 기사의 위치

먼저, 이 기사의 입지를 적어두겠습니다.

지금까지 저는 기업용 설계론이나, 평가기 (evaluator)를 포함한 자율적인 루프와 같이 다소 전문적인 테마를 중심으로 글을 써왔습니다. 이번에는 의도적으로 전문성을 낮추어, 그 토대가 되는 "루프 엔지니어링이란 무엇인가"를 한 번 깔끔하게 정리해보고자 합니다. 이미 저의 다른 글들을 읽어보신 분들은 눈치채셨을지도 모르겠지만, 지난 몇 달간 저는 저의 개발 환경에서 이 루프 이론을 운용해 왔습니다. 그 과정에서 강하게 느끼고 있는 것은, 루프 엔지니어링은 단순한 편리한 자동화 테크닉이 아니라, AI 코딩 에이전트를 대하는 방식 그 자체를 바꾸는 거대한 패러다임 시프트 (Paradigm Shift)라는 점입니다.

내용의 대부분은 최전선의 실천가들이나 공식 문서에서 이미 이야기되고 있는 것들을 영어권의 1차 정보로부터 다시 정리한 것입니다. 새로운 발견이라기보다는 **"생각의 정리"**로서 읽어주시면 좋겠습니다.

다만, 정리하고 끝내지는 않겠습니다. 루프 엔지니어링을 한 차례 이해하고 나면 반드시 남는 질문이 있습니다. "이론은 알겠다. 그래서 실제로 어떻게 만드는가?" ── 이 기사는 거기까지를 하나의 흐름으로 이어가려 합니다. 전반부에서 이론을 구축하고, 마지막에는 그것을 그대로 형상화한, 바로 시도해 볼 수 있는 구현 (Implementation) 을 소개합니다. 이론과 구현을 분리하지 않고 하나의 흐름으로 받아들여 주시길 바랍니다.

이 기사의 흐름:

• 여기까지 오게 된 조류 (프롬프트 → 컨텍스트 → 하네스 → 루프)
• 루프 엔지니어링으로 실제로 무엇을 할 수 있는가
• 그 이면에 있는 이론
• 이론을 구현으로 옮기기 ── loop-kit

여기까지 오기까지 ── 쌓여온 4가지 계층

루프 엔지니어링은 어느 날 갑자기 태어난 것이 아닙니다. 지난 몇 년간, 고민의 지점이 "모델 그 자체"에서 조금씩 외부로 옮겨온 결과입니다. 순서대로 살펴보겠습니다. 각각의 층은 이전 층을 포함하는 것이며, 대체하는 것이 아닙니다.

① 프롬프트 엔지니어링 (Prompt Engineering) (~2024년경)

**"어떻게 물을 것인가"**를 고민하는 단계입니다. ChatGPT 등장 이후 약 2년 동안, 성과를 좌우한 것은 한 번의 지시문 작성 방식이었습니다. 역할을 부여하거나, 예시를 보여주거나, 단계적으로 생각하게 하는 (chain-of-thought) 등의 기법이 중심이었습니다.

한계도 명확했습니다. 한 번의 지시는 "다음에 무엇을 할지", "무엇을 완료로 간주할지"까지는 결정할 수 없습니다.

② 컨텍스트 엔지니어링 (Context Engineering) (2025년 중반~)

질문이 **"어떻게 물을 것인가"에서 "무엇을 보여줄 것인가"**로 옮겨갔습니다. Andrej Karpathy나 Shopify의 Tobi Lütke가 2025년 6월경에 "이것이야말로 진정한 기술이다"라고 발신하였고, Anthropic 또한 같은 해 9월 공식 기사 "Effective context engineering for AI agents"를 통해 개념을 정리했습니다.

Anthropic의 정의를 쉽게 말하자면, **"모델에 전달하는 토큰 (Token, 즉 컨텍스트 창 전체)을 원하는 동작이 잘 나오도록 설계하는 것"**입니다. 시스템 지시문, 검색해온 자료, 사용할 수 있는 도구, 과거의 대화 내용, 기억이나 상태 ── 이것들을 어떻게 조합하여 창(Window)에 담느냐가 모델의 말투 그 자체보다 더 효과적이라는 깨달음입니다. 멀티 턴 (Multi-turn)으로 작동하는 에이전트에게는 필수적인 사고방식이었습니다.

③ 하네스 엔지니어링 (Harness Engineering) (2026년 초반~)

「에이전트가 작동하는 환경 그 자체를 구축한다」 단계입니다. 2026년 초반에 확산된 사고방식으로, Thoughtworks의 Birgitta Böckeler가 martinfowler.com에서 "Agent = Model + Harness (에이전트 = 모델 + 하네스)"라는 명쾌한 모델로 정리하였고, Addy Osmani 또한 "Agent Harness Engineering"에서 이를 논했습니다.

하네스 (Harness)란 "모델 + 그 주변에 구축하는 모든 것"을 의미합니다. 즉, 프롬프트 (Prompt), 도구 (Tool), 후크 (Hook), 샌드박스 (Sandbox), 서브 에이전트 (Sub-agent), 피드백 경로 (Feedback path), 복구 메커니즘 (Recovery mechanism) 등을 포함합니다. Osmani에 따르면 Claude Code, Cursor, Codex, Aider, Cline은 모두 그 실체가 "하네스"입니다. 같은 모델이라도 사용자 경험을 결정짓는 것은 하네스의 완성도라는 뜻입니다.

이 단계의 핵심은 "적당한 모델 + 뛰어난 하네스"가 "뛰어난 모델 + 빈약한 하네스"를 이긴다는 점입니다. 그리고 또 하나, **"한 번 조이면 늦추지 않는다"**는 사고방식입니다. 에이전트가 실수를 할 때마다 이를 단발성 실패로 흘려보내는 것이 아니라, "다시는 이런 일이 일어나지 않도록 메커니즘을 조이는 신호"로 취급합니다. 규약(Convention)을 AGENTS.md에 추가하거나, 위험한 명령어를 차단하는 후크를 달거나, 리뷰용 서브 에이전트가 이를 감지하게 만듭니다. 이렇게 하네스는 실패를 거듭할수록 강해집니다.

다만, 하네스가 관리하는 영역은 기본적으로 **"1회 실행 (Session)의 내부"**입니다. 그 1회 실행 안에서 여러 서브 에이전트를 병렬로 구동하는 것은 오히려 흔한 일입니다 (Claude Code도 그렇게 합니다). 하네스가 다루지 않는 영역은 바로 그 실행과 실행 사이이며, 그 부분을 설계하는 것이 다음 단계인 루프입니다.

④ 루프 엔지니어링 (Loop Engineering, 2026년 6월~)

그리고 하네스의 **"한 단계 위"**에 서는 것이 루프 엔지니어링입니다. Addy Osmani가 2026년 6월 7일에 이 용어를 제시하며, 같은 취지를 먼저 이야기했던 두 실천자의 말을 하나로 묶었습니다.

Peter Steinberger (PSPDFKit의 창립자. 공개 직후 수십만 개의 스타를 모은 OSS 에이전트 "OpenClaw"를 만들었으며, 현재 OpenAI 재직 중) ── 이제 에이전트에게 프롬프트를 입력하는 것은 그만두자. 에이전트에게 프롬프트를 입력하는 "루프 (Loop)"를 설계해야 한다고 발신.

Boris Cherny (Anthropic의 Claude Code 책임자) ── 자신은 이제 Claude에게 직접 프롬프트를 입력하지 않는다. Claude에게 프롬프트를 입력하고, 다음에 무엇을 할지 판단하는 "루프"를 돌리고 있다. 자신의 업무는 루프를 작성하는 것이라고 말했습니다.

하네스가 **"1회 실행의 내부"**를 구축하는 것에 반해, 루프는 **"실행과 실행 사이"**를 설계합니다. 정해진 시간에 기동하고, 필요하다면 여러 서브 에이전트를 실행하며, 스스로 다음 수를 결정하고, 스스로에게 연료를 계속 공급합니다. 할 일을 찾아 할당하고, 확인하며, 완료된 일을 기록하고, 다음 단계를 결정합니다. 이 일련의 과정을 당신 대신 수행하는 작은 시스템을 만들고, 당신은 에이전트를 재촉하는 역할에서 내려오는 것입니다.

흥미로운 점은 이것이 더 이상 "자체 도구 자랑"이 아니게 되었다는 것입니다. 1년 전이라면 bash 스크립트 더미를 직접 작성하여 영원히 유지보수해야 했을 것입니다. 지금은 동일한 부품들이 Claude Code나 Codex와 같은 제품 안에 표준으로 탑재되어 있습니다. 그렇기에 "어떤 도구인가"를 다투기보다, 어떤 도구에서도 작동하는 루프를 설계하는 것이 더욱 본질적이 되었습니다.

요약하자면 흐름은 다음과 같습니다:

중요한 보충 설명을 하나 덧붙이자면, 루프 안에서 조잡한 프롬프트를 사용하면 조잡한 작업이 빠르게 양산될 뿐입니다. 루프가 더해주는 것은 그 전체를 자율적으로 돌리는 메커니즘이지, 하위 계층의 품질까지 대신 책임져주지는 않습니다.

루프 엔지니어링으로 실제로 무엇을 할 수 있는가

이론에 앞서, 먼저 "무엇이 좋은가"를 구체적으로 살펴봅시다. Addy Osmani가 제시하는 전형적인 사례가 가장 실감이 날 것입니다.

아침의 분류(Triage) 루프. 매일 아침 스스로 기동하여, 어제의 CI 실패·미처리 Issue·최근 커밋을 읽습니다. 발견한 사항을 Markdown 파일(또는 Linear 보드)에 기록합니다. 처리해야 할 항목마다 독립된 작업 공간(worktree)을 전환하여 서브 에이전트(sub-agent)에게 수정을 맡기고, 또 다른 서브 에이전트가 그 초안을 프로젝트의 스킬(skill)이나 기존 테스트에 비추어 점검합니다. 도구 연동(connector)을 통해 PR을 열고 티켓을 업데이트합니다. 스스로 감당할 수 없는 것은 '분류용 수신함'에 넣어 인간에게 넘깁니다. 상태 파일(state file)이 있기 때문에 오늘 어디까지 진행되었는지 기억하고 있으며, 내일 아침에는 이어서 재개할 수 있습니다. ── 이것은 훌륭한 엔지니어링 흐름 그 자체입니다. 게다가 설계자는 처음에 한 번 구성했을 뿐, 개별 단계마다 프롬프트를 입력하지 않습니다.

같은 발상의 응용은 이미 현장에서 돌아가고 있습니다.

PR의 수호자 (PR babysitter): 자신의 PR을 정기적으로 감시하며, 리뷰 지적에 대응하고, 실패한 CI를 수정함
의존성 정리: 의존 라이브ся리 업데이트 및 CVE(취약점) 대응. 단, 메이저 변경은 인간의 승인을 거침
Issue 분류 / 체인지로그(changelog) 초안 작성 / 머지(merge) 후 뒷정리
정형 요약: 매일 아침 Slack의 특정 채널을 요약하는 등

OpenAI도 사내에서 일일 Issue 분류, CI 실패 요약, 커밋 요점 정리, 지난주에 섞여 들어온 버그 찾기와 같은 '지루하지만 중요한 잡무'에 이 메커니즘을 사용하고 있다고 Osmani는 쓰고 있습니다.

팀 관점에서는 다음과 같은 효과도 있습니다.

개인 의존성(silo) 해소: "이 리포지토리에서는 이렇게 수정한다"라는 각자의 암묵지를 스킬(skill, 후술)로 기록하여, 누구의 루프에서도 동일한 품질로 돌아가게 함
기존 도구와의 연동: Linear, Jira, Slack 등과 연결하여 폐쇄된 루프 안에서 티켓까지 움직임

여기까지는 스케줄에 따라 움직이는 루프가 중심이었습니다. 또 하나, 성격이 조금 다른 사용법이 있습니다. "단 한 번이지만, 복잡한 구현"을 루프에 맡기는 방식입니다.

예를 들어, 어떤 기능을 통째로 구현하고 싶지만 요구사항은 아직 모호하고 스스로도 세부 사항이 정리되지 않았을 때 ── 이때 사용할 수 있습니다. 먼저 루프에게 요구사항 자체를 정리하게 합니다. 무엇이 불명확한지, 어디에 판단이 필요한지를 파악하여 당신에게 확인을 받고 사양(specification)으로 확정합니다. 확정되면 그 사양에 대한 테스트를 작성하고 구현하며, 테스트가 전부 통과할(초록색이 될) 때까지 스스로 시행착오를 계속합니다. 당신이 처음에 요구사항을 전달하고 승인한 후에는 완료될 때까지 손을 뗄 수 있습니다. 매일 아침 돌아가는 것도, 무인으로 계속 회전하는 것도 아닙니다. 하지만 "정지 조건을 만족할 때까지 사이클을 돌린다"는 점에서 이것 역시 훌륭한 루프입니다.

요컨대 루프가 잘하는 것은 **"완료 조건이 명확하고, 기계적으로 검증할 수 있는 일"**입니다. 그것이 매일 반복되는 정형 작업이라면 당신이 자는 동안 처리해 줄 것입니다. 단 한 번의 복잡한 구현이라면 당신이 다른 일에 집중하는 동안 초록색이 될 때까지 끈기 있게 매달려 줄 것입니다.

메커니즘을 이해하기 ── 루프의 이론

"편리해 보인다"는 생각의 이면에 있는 개념을 여기서 정리합니다. 이 부분을 이해하면 좋은 루프와 위험한 루프의 차이가 보입니다.

애초에 루프란 무엇인가

Anthropic 공식(Claude Code 팀)의 정의가 가장 명쾌합니다. **루프란 "정지 조건을 만족할 때까지 작업 사이클을 반복하는 에이전트(agent)"**를 말합니다.

단적으로 말하면, **루프란 "체크(검증)가 포함된 태스크(task)"**입니다. 체크가 없는 태스크는 그저 바람에 불과합니다. 이 점이 모든 토대의 핵심입니다. 무언가를 한다 → 결과를 확인한다 → 계속할지 멈출지를 결정한다. 기술의 대부분은 "그 확인을 진짜로 만드는 것"과 "언제 멈출지를 결정하는 것"에 깃들어 있습니다.

Anthropic이 정리한 4가지 루프 유형

Anthropic의 공식 문서에서는 루프를 기동 및 정지 방식에 따라 4가지로 분류하고 있습니다. 입문용으로 이 분류는 매우 통찰력이 좋으므로 그대로 소개하겠습니다 (Claude Code의 기능명을 예로 들었지만, 사고방식은 도구에 종속되지 않습니다).

턴 방식 (turn-based): 당신의 프롬프트로 기동하며, Claude가 "완료했다" 또는 "정보가 부족하다"라고 판단하면 멈춥니다. 매번의 대화가 이것입니다. 가장 기본적인 루프입니다.
목표 방식 (goal-oriented): 당신이 "완료 조건"을 정의합니다. 각 턴이 끝난 후, /goal...

）작업 역할과는 별개의 작은 평가 모델 (Evaluation Model) (기본값은 Haiku)이 조건을 충족했는지 판정하며, 충족할 때까지 (또는 조건에 기재한 시도 횟수의 상한까지) 계속하게 합니다. 여기서 한 가지 정확히 짚고 넘어가야 할 점이 있습니다. 현재 사양 (2026년 7월 기준, Claude Code v2.1.139 이후)에서는, 이 평가 모델은 스스로 명령어를 실행하거나 파일을 읽지 않습니다. 대화(Transcript)에 이미 출력된 내용만을 보고 판정합니다. 따라서 조건은 "Claude 자신의 출력으로 보여줄 수 있는 형태"로 작성해야 합니다. "테스트가 모두 통과한다"가 기능하는 이유는 Claude가 테스트를 실제로 실행하고, 그 결과가 대화에 남기 때문입니다. 즉, 기계적으로 판정할 수 있는 증거가 대화에 남는 조건일수록 효과적이라는 뜻입니다.

• 시간형 (Time-based): 일정 간격으로 실행됩니다. 반복적인 정형 작업이나 외부 시스템 (PR 또는 CI 등)의 변화에 반응하는 용도에 적합합니다. /loop, /schedule 사용.
• 프로액티브형 (Proactive): 이벤트나 스케줄에 따라 실시간으로 인간의 개입 없이 구동됩니다. 각 태스크는 목표 달성 시 종료되며, 루틴 자체는 당신이 멈출 때까지 계속됩니다.

태스크가 단순하다면 복잡한 루프는 필요 없습니다. 가장 단순한 방법부터 시작하여, 필요한 때에만 위의 유형으로 격상시킨다 ── 이것이 Anthropic의 권장 사항입니다.

루프를 구성하는 부품: 5개 + "기억"

Addy Osmani는 도구에 의존하지 않는 루프의 구성 요소를 **"5가지 부품과, 이와 별개인 1곳의 기억"**으로 꼽았습니다 (Claude Code와 Codex 모두 현재 이 5가지를 모두 갖추고 있습니다).

• 자동화 (Automations): 스케줄에 따라 구동되며, 발견과 분류를 스스로 수행합니다. 루프를 일정 간격으로 일으키는 기점입니다.
• 워크트리 (Worktrees): 병렬로 실행할 때 에이전트끼리 파일을 서로 침범하지 않도록 격리합니다. Git의 독립된 작업 디렉토리로, 한쪽의 편집이 다른 쪽에 영향을 주지 않습니다.
• 스킬 (Skills): 에이전트가 방치하면 추측으로 채워버릴 프로젝트 지식을 외부에 써둡니다 (예: SKILL.md). 긴 지시문을 매번 붙여넣는 대신 이름으로 호출합니다.
• 플러그인 / 커넥터 (Plugins and connectors): 티켓 업데이트, PR 생성, Slack 알림 등 당신이 이미 사용 중인 도구에 에이전트를 연결합니다 (MCP 기반).
• 서브 에이전트 (Sub-agents): 한쪽이 아이디어를 내고, 다른 한쪽이 이를 점검합니다 (후술할 가장 중요한 원칙).

그리고 Osmani가 "6번째 것"이라고 부르는 것이 바로 **기억 (State / Memory)**입니다. Markdown 파일이어도 좋고, Linear 보드여도 좋습니다. 하나의 대화 외부에서 계속 살아남아 "무엇이 완료되었는지, 다음은 무엇인지"를 유지하는 것입니다. 모델은 실행과 실행 사이에 모든 것을 잊어버립니다. 따라서 기억은 컨텍스트 (Prompt) 내부가 아니라 디스크 상 (파일이나 git 히스토리)에 두어야 합니다. "에이전트는 잊지만, 리포지토리는 잊지 않는다". 이것이 장시간 작동하는 루프가 공통적으로 의존하는 장치입니다.

보충: 이 "매번 백지 상태의 컨텍스트로 시작하고, 기억은 파일에 기록한다"는 방식은, Geoffrey Huntley가 2026년 초에 "Ralph (랄프) 테크닉"으로 퍼뜨린 것이 그 원류 중 하나입니다. 소박한 while 루프 안에서 에이전트를 돌리며, 작성된 사양에 대해 매번 새로운 문맥으로 한 단계씩 진행합니다.

가장 중요한 원칙 ── 만드는 자와 채점하는 자를 분리하라

루프 이론의 핵심이 바로 이것입니다. 코드를 작성한 모델은 자신의 숙제를 채점하기에는 너무 관대합니다.

생성하는 모델에는 "자신이 쓴 것을 긍정하고 싶어 하는" 관성이 작용합니다. 반면, 다른 지시(때로는 다른 모델)로 바라보는 리뷰어는, 첫 번째 모델이 자신을 설득하여 통과시킨 부분을 잡아낼 수 있습니다. 따라서 코드를 작성하는 에이전트와 그것을 점검하는 에이전트를 분리해야 합니다 (maker–checker 분리 / generator–evaluator 분리).

Claude Code의 /goal

Claude Code의 /goal이 "멈춰도 되는지"를 판단하는 것을 작업 역할과는 별개의 모델에 맡기는 것 또한 이러한 발상의 한 형태입니다. 다만 앞서 언급했듯이, 그 평가 모델은 대화에 적힌 내용을 읽을 뿐, 스스로 테스트를 다시 실행하지는 않습니다. 즉, "판단의 독립성"은 있어도 "검증의 독립성"까지는 없다는 뜻입니다. 작업 역할이 "테스트를 통과했다"라고 대화에 쓰면, 평가 역할은 그것을 전제로 판정합니다. 이 한 단계 더 나아가 ── 점검 역할이 검증 명령을 자신의 손으로 직접 실행하게 만드는 것까지 파고드는 것이, 후반부에서 소개할 loop-kit의 목표입니다.

그리고 평가 순서는 **"기계적이고 신뢰할 수 있는 것을 먼저"**입니다. 먼저 결정론적인 체크(테스트를 실제로 실행하여 통과하는지), 그다음 AI에 의한 리뷰, 인간은 마지막에 증거(evidence)만을 확인합니다. 검증의 질이 루프 전체의 질을 결정하는 급소가 됩니다.

멈추는 법의 설계 ── "끝났다"와 "잘 되었다"는 별개다

폭주를 방지하는 설계도 이론의 일부입니다. 여기서 흔히 발생하는 함정은 정지 조건과 성공 조건을 혼동하는 것입니다. 분류 루프가 아무 일 없이 깔끔하게 종료되었지만, 사실은 아무것도 고치지 못했다 ── 그런 사고는 드물지 않습니다. "루프가 멈췄다"는 것이 "잘 되었다"를 의미하지는 않습니다. 따라서 정지 규칙은 단순히 "끝났는가"가 아니라 **"출력을 채점하는 것"**이어야 합니다.

실무에서는 다음과 같은 "하드한 제동 장치"를 명시적으로 둡니다.

• 반복 횟수의 상한 (예: 5번 시도하면 멈춤)
• 예산·토큰의 상한 (무제한적인 소모를 방지)
• 정체 감지 (같은 실수를 반복하고 있지 않은지, 차분이 나타나고 있는지)
• 인간 게이트 (Human Gate): 돌이킬 수 없는 조작이나 요건 자체를 바꾸는 판단은 반드시 인간이 멈춤

루프가 대신해주지 않는 것 ── 잘 돌아갈수록 날카로워지는 3가지 문제

루프는 강력하지만, Addy Osmani는 같은 열정으로 위험성도 경고하고 있습니다. 그가 강조하는 것은 **"루프가 좋아질수록, 쉬워지는 것이 아니라 오히려 더 날카로워지는 3가지 문제"**입니다.

• 검증은 여전히 당신의 몫 (Verification is still on you): 무인으로 돌아가는 루프는 무인으로 실수를 저지르는 루프이기도 합니다. "해냈다"는 주장일 뿐, 증명이 아닙니다. 당신의 일은 실제로 작동함을 확인한 코드를 출하하는 것이다 ── Osmani는 이를 반복해서 말합니다.
• 이해의 부채 (comprehension debt): 당신이 작성하지 않은 코드를 루프가 빠르게 출하할수록, "실제로 존재하는 것"과 "당신이 파악하고 있는 것" 사이의 간극이 벌어집니다. 매끄럽게 돌아가는 루프는 방치하면 이 차이를 빠르게 넓힙니다. 그러므로 당신이 읽어야 합니다.
• 인지의 양도 (cognitive surrender): 루프가 알아서 돌아가고 있으면, 의견을 갖는 것을 그만두고 돌아온 결과물을 그대로 받아들이고 싶어집니다. 루프를 설계하는 행위는 판단을 가지고 행하면 "약"이 되지만, 생각하지 않기 위해 행하면 "독"이 됩니다 ── 같은 행동으로 정반대의 결과가 나타납니다.

Osmani의 인상적인 지적 중에는 **"같은 루프를 두 사람이 돌려도 정반대의 결과가 나올 수 있다"**는 것이 있습니다. 한 사람은 확보된 시간으로 어려운 문제의 이해를 심화시키고, 다른 한 사람은 이해를 피하기 위해 그 시간을 사용합니다. 루프는 그 차이를 알지 못합니다. 아는 것은 당신뿐입니다. 그렇기에 루프 설계는 프롬프트 설계보다 쉽지 않으며, 오히려 더 어렵습니다.

Cherny의 말의 요점도 같습니다. 편해진 것이 아니라, 중요한 작업이 옮겨간 것이다 ── 프롬프트를 쓰는 것에서 루프를 설계하는 것으로.

Osmani의 맺음말을 빌리자면 다음과 같습니다: 루프를 만들어라. 단, "버튼을 누르는 사람"이 아니라, "엔지니어로 남고자 하는 사람"으로서 만들어라.

그리고 하나 더, 잊어서는 안 될 균형 감각이 있습니다. 직접 프롬프트를 입력하는 방식도 여전히 유효합니다. 모든 것을 루프에 맡길 필요는 없습니다. 핵심은 구분해서 사용하는 것입니다.

이론을 구현으로 옮기기 ── 구현 예시로서의 loop-kit

지금까지 나열한 원칙들 ── 검증을 중심에 두기 / 만드는 자와 채점하는 자를 분리하기 / 기억을 외부에 두기 / 하드한 제동 장치로 폭주를 막기 ── 가 실제 코드에서는 어떤 형태가 될까요? 앞서 언급한 세 가지 경고 중 loop-kit가 정면으로 받아내는 것은 첫 번째인 **"검증은 여전히 당신의 몫"**입니다. "해냈다"라는 주장을 시스템 측면에서 증명으로 바꾸는 것 ── 그것을 하나의 구현 예시로서 형상화한 것이 제가 공개하고 있는 loop-kit입니다.

중요한 것은 이것이 책상 위의 시제품이 아니라는 점입니다. loop-kit은 본래 저 자신이 구축하여 일상적인 실운용에서 사용하고 있는 메커니즘을, 특정 프로젝트를 위한 맞춤형 설계를 덜어내고 범용화·간소화한 것입니다. 실운용을 견딜 수 있음을 전제로 설계 및 검증된 것을, 누구나 쉽게 루프 엔지니어링 (Loop Engineering)을 시도할 수 있는 형태로 다시 정돈했습니다. 한마디로 말하자면 **「Claude Code를 단 한 번의 채팅이 아니라, 『정지 조건을 만족할 때까지 작업 사이클을 계속 돌리는 메커니즘』으로 작동시키는, 얇은 쉘(Shell) 형태의 하네스(Harness)와 스킬 집합」**입니다. 서버도 데몬(Daemon)도 필요 없으며, 쉘 스크립트(Shell Script)와 프롬프트(Prompt)만으로 동작합니다.

loop-kit이 구현하고 있는 것은 4가지 루프 유형 중 골형 (Goal-type) 입니다 ── 사양을 하나 고정하고, 녹색(성공)이 될 때까지 끝까지 돌리는 방식입니다. 앞서 언급한 「단 한 번이지만 복잡한 구현을 루프에 맡기는」 사용법이 바로 여기에 해당합니다. 왜 여기서부터 시작하는가. 검증을 중심으로 둔 골형이야말로 향후 모든 하네스의 공통적인 기본 단위가 될 것이라고 생각하기 때문입니다. 골형은 그 자체로 작고 완결된 부품이며, 시간형(Time-type)이나 프로액티브형(Proactive-type) 같은 외부 메커니즘 ── 정해진 시각에 기동하거나 이벤트에 반응하는 것 ── 은 이 부품을 호출하여 조합함으로써 성립합니다. 제가取り組んでいる(매진하고 있는) 자기 개선형 루프도 동일한 뿌리 위에 쌓아 올릴 것입니다. 입문을 위한 구현으로서 우선 이곳을 파악하는 것이 이치에 맞습니다.

요구사항을 한 번 전달하면, 어떤 일이 일어나는가

당신이 요구사항을 한 번 전달한 후, 완료까지는 대략 다음 순서로 진행됩니다.

• 계약을 만든다 ── Claude Code가 대화를 통해 리포지토리(Repository)를 조사하고, **스스로는 채울 수 없는 「미지(Unknown)」**를 질문하면서 요구사항, 비목표, 수락 조건, **성공 조건 (=언제 멈춰도 되는가)**을 「계약」으로서 작성한다.
• 계약을 승인한다 ── 당신이 승인한 순간의 내용이 해시(Hash)로 고정되어, 이후 몰래 성공 조건을 수정할 수 없게 된다.
• 태스크로 나눈다 ── 계약에 따라 구현 계획을 세우고, 의존성이 있는 것은 순차적으로, 독립적인 것은 병렬로 (각각 격리된 작업 공간에서) 진행한다.
• 루프를 돌린다 ── 각 태스크에서 계약, 계획, 진척도를 읽고 1단계만 구현하며, 모델을 거치지 않는 스크립트가 당신의 검증 커맨드(Command)를 스스로 재실행하여 확인하고(검증), 완전히 새로운 문맥(Context)을 가진 리뷰어가 요구사항을 먼저, 차분(Diff)을 나중에 읽어 사양으로부터의 이탈이나 퇴보를 점검한다(리뷰). 성공 조건을 만족하면 멈추고, 만족하지 못하면 매번 완전히 새로운 문맥에서 이 순환을 반복한다. 반복·시간 상한에 도달하거나 인간의 판단이 필요한 상황(되돌릴 수 없는 조작, 요구사항 자체의 변경)에 맞닥뜨리면 거기서 멈추고 당신에게 넘긴다.
• 증거를 제시한다 ── 완료되면 차분의 더미가 아니라 「무엇을 어떻게 검증했는가」의 증거 리포트를 출력한다. 병렬로 실행된 부분은 머지(Merge)한 전체를 다시 한번 최초의 계약에 비추어 최종 리뷰한다.

심장부는 주로 4가지 루프입니다:

구현 → (외부 평가기에서) 검증 → (독립 리뷰어에서) 리뷰 → 만족하면 정지 / 미달 시 구현으로 복귀

포인트는, 루프를 멈춰도 좋다고 결정하는 것이 작업자의 자기 신고가 아니라는 것입니다. 판정하는 것은 검증 커맨드를 기계적으로 재실행하는 외부 평가기와 별도의 문맥을 가진 독립 리뷰어입니다. 이것이 전반부에서 언급한 /goal과의 차이 ── 「판단의 독립성」뿐만 아니라 「검증의 독립성」까지 파고드는 것 ── 의 정체입니다.

이 흐름의 각 단계에는 전반부에서 언급한 원칙이 그대로 심어져 있습니다 ── 계약은 고정·구현은 자유 / 자기 채점 금지 / 기억은 외부에 두고 매번 새로 시작 / 강력한 제동 장치로 폭주를 방지 / 인간은 차분이 아닌 증거를 본다.

loop-kit은 최신 루프 엔지니어링 이론에 맞춰 향후에도 계속 개선될 가능성이 있습니다. 구체적인 사용법, 설정, 커맨드, 그리고 현시점의 구현 상세 내용은 항상 최신 리포지토리의 README를 참조해 주세요. 시도하기 전에 두 가지만 말씀드립니다. 기본적으로 Opus를 사용하는 것을 전제로 하므로, 플랜에 따라 가벼운 모델로의 전환이 필요할 수 있습니다. 또한 요구사항에 따라 반복 횟수가 늘어나 토큰(Token) 소비도 증가할 수 있으므로, 우선은 작고 리스크가 낮은 태스크부터 돌려보는 것을 추천합니다.

마치며

루프 엔지니어링은 2026년 6월에 단번에 주목을 받은, AI 시대 엔지니어링의 본질적인 변화입니다. 단순한 「자동화」가 아닙니다. 「어디까지 판단을 자신에게 남기고, 어디를 시스템에 위임할 것인가」를 설계하는 한 단계 높은 수준의 스킬입니다.

아직 태동기라 신중해야 할 부분도 많습니다. 토큰 비용은 방심하면 불어날 수 있고, 이해의 부채(understanding debt)는 조용히 쌓입니다. 그렇기에 낮은 위험도의 패턴(단순 보고서 분류 등)부터 하나 시도해보고, 직접 한 번 돌려보면서 드러난 약점을 보완하는 것부터 시작하는 것을 추천합니다. loop-kit 역시 그 '우선 한번 돌려보는' 입구로 사용해주시면 좋겠습니다.

도구에 저항하기보다는, 무비판적으로 맡기는 것도 아닙니다. 판단력과 시스템을 통찰하는 힘을 갈고닦는 것. 그것이 이 새로운 계층에서도 '엔지니어로 남아있는' 것이라고 생각합니다.

본 기사는 Addy Osmani의 'Loop Engineering', 'Agent Harness Engineering', Anthropic 공식 문서('Effective context engineering for AI agents' 및 Claude Code 팀의 루프 설명), Birgitta Böckeler(Thoughtworks/martinfowler.com)의 하네스 엔지니어링 논, Peter Steinberger와 Boris Cherny의 발언, Geoffrey Huntley의 'Ralph' 테크닉 등 2026년 시점의 영어권 일차 정보 및 공식 정보를 기반으로 정리되었습니다. 도구의 기능이나 명령어는 변경될 수 있으므로, 구체적인 사양은 각 공식 사이트에서 확인해 주십시오.

토론