Loop Engineering(루프 엔지니어링)은 AI 코딩 에이전트와의 관계를 한 단계 끌어올리는 사고방식입니다. Google의 엔지니어인 Addy Osmani 씨가 2026년 6월 블로그 기사에서 이름을 붙이면서 널리 알려지게 되었습니다. 한마디로 말하면, "에이전트에게 매번 프롬프트(Prompt)를 쓰는" 것을 그만두고, "에이전트를 반복적으로 호출하는 시스템(루프)을 설계하는" 쪽으로 발상을 전환하는 것입니다.

계기가 된 것은 현장 실무자들의 발언이었습니다. Claude Code를 이끄는 Boris Cherny 씨는 인터뷰나 이벤트에서 "이제 Claude에게 직접 프롬프트를 작성하지 않는다. 루프를 실행하고 있으며, 프롬프트를 하는 것은 그 루프다. 나의 일은 루프를 작성하는 것이다"라는 취지의 말을 했다고 알려져 있습니다. 같은 시기, OpenClaw의 Peter Steinberger 씨도 "이제 코딩 에이전트에게 프롬프트를 하는 것이 아니라, 에이전트에게 프롬프트를 하는 루프를 설계해야 한다"라고 게시하며 이 말이 크게 확산되었습니다.

이 기사에서 알 수 있는 것:

• 🧭 prompt → context → harness → loop engineering으로 이어지는 용어의 계보
• 🔁 루프를 구성하는 5가지 부품과 6번째인 "메모리(Memory)"
• 📅 하루의 루프가 실제로 어떻게 돌아가는지 (아침의 트리아지(Triage)부터 인수인계까지)
• 🛠️ Claude Code와 OpenAI Codex에서의 구현 기능 (공식 확인 가능 여부 포함)
• ✅ 왜 "검증"만은 완전히 자동화되지 못하고 사람과 서브 에이전트(Sub-agent)에게 남는가
• ⚠️ 이해의 부채, 사고의 포기, 비용 폭주라는 함정
• 🧑⚖️ "같은 루프라도 사람에 따라 결과는 정반대가 될 수 있다"는 핵심

Loop Engineering은 갑자기 나타난 용어가 아니라, 용어들이 쌓여온 결과입니다. 순서대로 보면 위치를 이해하기 쉽습니다.

이 그림의 포인트는 관심의 대상이 점점 "바깥쪽"으로 확장되고 있다는 점입니다.

Context Engineering은 2025년 6월에 Shopify의 Tobi Lütke 씨가 "prompt engineering보다 context engineering이라는 말을 좋아한다. 태스크를 LLM이 해결할 수 있도록 필요한 컨텍스트(Context)를 모두 제공하는 기술을 가리킨다"라고 언급하고, Andrej Karpathy 씨도 이에 동조하면서 퍼졌습니다. Simon Willison 씨는 프롬프트를 다듬는 수준을 넘어 "모델이 보는 입력 전체(지시, 예시, 검색 결과, 이력, 도구)를 구성하는 실무"를 정확하게 나타내는 용어라고 정리했습니다. -
Harness Engineering은 Osmani 씨의 말에 따르면 "모델을 둘러싼 발판(프롬프트, 도구, 컨텍스트 방침, 훅(Hook), 피드백 루프) 전체를 설계하는 규율"입니다. "Agent = Model + Harness"라는 관점이 핵심에 있습니다. -
그리고
Loop Engineering은 그 harness의 "한 계층 위"에 서 있습니다. 발판을 언제, 어떤 빈도로, 누가 기동할지까지 포함하여, 자율적으로 돌아가는 루프로서 설계한다는 뜻입니다.

💡 정리하자면, Prompt는 "모델에게 말하는 법", Context는 "모델에게 보여주는 것", Loop는 "언제, 무엇을, 누가 프롬프트를 하고, 결과가 허용 범위 내인지 누가 결정하는가"라는 자율 시스템의 설계, 라는 대비가 됩니다.

Osmani 씨는 도구에 의존하지 않는 추상화로서, 루프를 5가지 부품으로 설명하고 있습니다. 그리고 동일한 부품이 Claude Code에도 Codex에도 구현되어 있다는 점이 중요합니다.

여기에 더해 Osmani 씨가 6번째로 강조하는 것이 State / Memory (상태·기억) 입니다. 인상적인 문장이 있습니다.

"the memory has to be on disk and not in the context. The agent forgets, the repo doesnt."

(기억은 컨텍스트가 아니라 디스크에 두어야 한다. 에이전트는 잊어버리지만, 리포지토리(Repo)는 잊지 않는다.)

기억은 Markdown 파일이나 Linear의 보드와 같이 컨텍스트(Context) 외부에 영속화합니다. 실행 완료됨·진행 중·다음에 할 일을 기록하여, 에이전트 간 또는 날짜를 넘나드는 실행의 '인수인계 지점'으로 삼는다는 개념입니다. 전체적인 모습은 다음과 같습니다.

이 그림의 핵심은 루프가 '똑똑한 에이전트 한 개'가 아니라, 기동·격리·지식·연계·분업·기억을 조합한 시스템이라는 점입니다. Skills(기술)에 대해 Osmani 씨는 다음과 같이 기술했습니다. "기술이 없다면 루프는 매 사이클마다 프로젝트 전체를 처음부터 다시 도출해야 한다. 기술이 있다면 말하자면 차곡차곡 쌓여간다."

추상적인 논의만으로는 이미지를 떠올리기 어려우므로, Osmani 씨가 제시하는 '전형적인 하루의 루프'를 따라가 보겠습니다.

이 그림의 핵심은 Osmani 씨의 말대로 "당신은 단 한 번 설계했을 뿐이다. 이 단계들 중 그 어느 것에도 프롬프트(Prompt)를 입력하지 않았다"는 점입니다. 아침의 기동부터 트리아지(Triage), 병렬 수정, 검증, PR·알림, 그리고 다음 날 아침으로의 인수인계까지가 자신이 설계한 루프로서 자동으로 진행됩니다. OpenAI Codex의 공식 문서에서도 Automations(자동화)의 용도 예시로 데일리 이슈 트리아지·알림 모니터링·CI/CD 자동화·커밋 브리핑 등이 언급되어 있습니다.

💡 이러한 '야간·무인으로 돌아가는 루프'의 원조로 자주 언급되는 것이 Geoffrey Huntley 씨가 고안한 통칭 "Ralph Wiggum 루프"입니다.

while true bash 루프에서 PROMPT.md를 매번 새로운 세션에 입력하고, 진행 상황 파일에 상태를 다시 쓰는 것뿐인 소박한 장치였습니다. 이것이 바이럴(Viral)화되었고, Anthropic은 이후 ralph-wiggum을 Claude Code의 공식 플러그인으로 통합했습니다.

동일한 5가지 부품이 두 가지 주요 도구에 각각 마련되어 있습니다. 다음은 2026년 6월 시점에서 공식 문서를 바탕으로 확인한 내용입니다 (일부 블로그 기술만 있고 공식 확인되지 않은 것은 주석을 답니다).

특히 루프 운영의 중심이 될 법한 두 가지 명령어는 공식 문서에서 실재함을 확인했습니다.

• : 프롬프트를 일정 간격으로 반복합니다. 프롬프트를 생략하면 미완료 작업의 계속·PR 리뷰 대응·CI 실패 대응·버그 정리와 같은 "내장 유지보수 동작" 또는 /loop [간격] [프롬프트]를 실행합니다. - : 완료 조건을 하나 설정하면, 달성할 때까지 턴을 넘나들며 자율적으로 작업을 계속합니다. 주목할 점은 /goal`

각 턴이 끝난 후 다른 소형·고속 모델(기본값은 Haiku)이 대화 트랜스크립트(transcript)를 평가하고, 달성하지 못했다면 다음 턴을 자동으로 시작하는 구조로 되어 있다는 점입니다. 검증을 별도의 모델에 맡기는 설계가 커맨드(command) 안에 이미 포함되어 있는 것입니다.

💡 보충하자면, Osmani 씨의 블로그는 Claude Code와 Codex 모두에 /goal을 언급하고 있지만, 본 기사의 조사 결과 OpenAI의 공식 문서상에서 Codex의 /goal은 확인할 수 없었습니다 (Claude Code의 /goal은 공식적으로 확인되었습니다). Codex 측의 /goal을 인용할 때는 "공식 미확인"이라고 덧붙이는 것이 안전합니다. 한편, Codex의 Automations, worktree, 서브 에이전트(sub-agent, TOML), Skills, MCP는 모두 공식적으로 확인되었습니다.

파일 충돌을 피하는 git worktree가 병행 실행에서 유용하게 쓰이는 이유는, "어느 한 세션의 편집이 다른 세션의 파일에 전혀 영향을 주지 않는" 상태를 만들 수 있기 때문입니다. 하나의 트리(tree)에서 기능 개발을 진행하면서, 동시에 다른 트리에서 버그 수정을 실행하는 식의 활용이 가능합니다.

루프를 무인으로 돌릴 수 있게 되었음에도, Osmani 씨는 분명하게 경고를 남겼습니다. "검증은 여전히 당신의 일이다". 무인의 루프는 무인의 실수도 낳습니다. 그리고 "완료했습니다"는 어디까지나 주장일 뿐, 증명이 아닙니다.

여기서 핵심이 되는 인상적인 구절이 있습니다.

"The model that wrote the code is way too nice grading its own homework."

(코드를 작성한 모델은 자신의 숙제를 채점하기에는 너무 친절하다.)

이러한 "자기 채점은 관대해지는" 경향은 Osmani 씨의 다른 기사에서도 "모델은 자신의 성과를 채점할 때 신뢰할 수 없을 정도로 일관되게 긍정적으로 편향된다"라고 지적된 바 있습니다. 그렇기에 루프에서는 만드는 서브 에이전트와 검증하는 서브 에이전트를 분리하는 것이 정석이 됩니다.

이 그림의 포인트는 검증자를 "새로운 컨텍스트를 가진 독립된 서브 에이전트"로 만드는 것입니다. 생성과 동일한 모델, 동일한 문맥에서 자기 비판을 하게 하면, 사각지대를 공유한 채로 간과하는 일이 발생하기 쉽습니다. Anthropic이 병렬 Claude로 C 컴파일러를 만든 사례에서도, "태스크의 검증기(verifier)는 거의 완벽해야 한다. 그렇지 않으면 Claude는 '틀린 문제'를 풀어버린다", "테스트가 통과하는 것을 보고 완료되었다고 착각하기 쉽지만, 실제로는 완료되지 않은 경우가 많다"라며 검증의 질이 루프 전체의 질을 결정한다고 보고했습니다.

검증을 강화하기 위해서는 검증자에게 강력한(신뢰할 수 있는) 모델을 할당하거나, 적대적인 관점(모든 결함을 찾아내는 역할)으로 여러 번 리뷰하게 하는 등의 방안이 제시됩니다.

루프는 강력하지만, Osmani 씨를 비롯한 다른 논자들도 몇 가지 함정을 명확히 꼽고 있습니다.

뒷받침되는 데이터도 있습니다. Google의 DORA 리포트 2025는 AI 채택이 진행됨에 따라 "AI는 팀을 고치는 것이 아니라, 기존 상태를 증폭한다 (AI as amplifier)"라고 정리하며, 리뷰를 거치지 않고 머지(merge)되는 변경 사항의 증가를 지적했습니다. METR가 경험이 풍부한 OSS 개발자를 대상으로 실시한 2025년 상반기 실험에서는, AI 도구 사용 시 태스크가 오히려 19% 느려졌음에도 개발자 본인은 "빨라졌다"고 느끼고 있었다는 인지 격차가 보고되었습니다 (METR 스스로 "2025년 상반기의 단면일 뿐 일반화하지는 않는다"라고 명확히 주석을 달았습니다).

💡 일본의 사례에서도 "Claude Code가 43개의 커밋을 생성했지만, PR의 취지에서 벗어나 거의 전량 반려되었다"는 루프 폭주의 실패 사례가 공유되고 있습니다. 명확한 완료 조건, 검증 방법, 가드레일(guardrail)이 없는 루프는 활발하게 움직이는 것처럼 보이지만 성과로 이어지지 않는다는 교훈입니다.

Osmani 씨는 처방전을 다음과 같이 적었습니다.

"Build the loop. But build it like someone who intends to stay the engineer."

（루프를 만들어라. 단, 엔지니어로 남고자 하는 사람으로서 만들어라.）

이 글에서 가장 전달하고 싶은 것이 바로 Osmani 씨의 마무리 메시지입니다.

"두 사람이 정확히 똑같은 루프를 만들어도 결과는 완전히 정반대가 될 수 있습니다. 한 사람은 자신이 깊이 이해하고 있는 작업을 더 빠르게 진행하기 위해 루프를 사용하지만, 다른 한 사람은 작업을 전혀 이해하지 않으려는 목적으로 사용합니다. 루프는 그 차이를 알지 못합니다. 당신은 알고 있습니다."

（두 사람이 완전히 똑같은 루프를 만들어도 결과는 정반대가 될 수 있다. 한쪽은 깊이 이해하고 있는 업무를 빠르게 진행하기 위해 사용하고, 다른 한쪽은 업무를 이해하는 것 자체를 피하기 위해 사용한다. 루프는 그 차이를 모른다. 당신은 알고 있다.）

이것은 단순한 정신론이 아니라 데이터에 근거한 사실입니다. Anthropic이 2026년 1월에 공개한 주니어 엔지니어 52명을 대상으로 한 실험에서, AI를 사용한 그룹은 이해도 퀴즈에서 수기(hand-written) 그룹보다 17% 낮은 점수를 기록했습니다. 하지만 중요한 것은 결론입니다. "모든 AI 의존이 동일한 것은 아니다 (not all AI-reliance is the same)"라고 명시되어 있습니다.

• 점수가 낮았던 사람들의 경향: 코드를 통째로 맡겨버림 / 처음에는 질문하지만 점차 모든 권한을 위임함 / 이해를 쌓지 않고 AI를 디버깅을 위한 목발로 사용함
• 점수가 높았던 사람들의 경향: 생성한 후에 추가 질문을 통해 이해함 / 코드 생성과 설명을 세트로 요구함 / 개념적인 질문은 자신의 이해에 의존함

이 그림의 핵심은 루프라는 도구 자체는 중립적이며, 사용자의 관여 방식이 결과를 가른다는 점입니다. 시니어 엔지니어일수록 AI의 출력을 평가, 수정, 방향 설정할 수 있기 때문에, AI는 격차를 메우기는커녕 오히려 격차를 벌린다(증폭시킨다)는 관점도 여러 소스에서 나타나고 있습니다. Osmani 씨의 주장을 바꿔 말하자면, 루프를 설계하는 것은 판단력을 가지고 실행하면 치료제가 되지만, 생각하기를 피하기 위해 실행하면 촉진제가 된다는 뜻입니다.

Loop Engineering의 요점을 3가지로 압축하겠습니다.

글을 읽으며 느낀 점은, Loop Engineering은 "도구의 사용법"이라기보다 "엔지니어의 업무 중심이 어디로 이동했는가"에 대한 이야기라는 것입니다. 레버리지가 발생하는 지점이 개별 프롬프트에서 루프의 설계와 검증으로 이동했습니다. 그렇기에 Osmani 씨는 "엔지니어로 남고자 하는 사람으로서 루프를 만들어라"라고 거듭 강조하고 있는 것이라고 생각합니다.

• Loop Engineering (Addy Osmani) — 본 기사의 핵심 축. 루프의 5가지 구성 요소, 하루의 루프, 함정, 마무리 메시지에 대한 1차 정보.
• Long-Running Agents (Addy Osmani / O'Reilly Radar) — 장기 실행 에이전트 (Long-Running Agents)의 흐름, 자기 채점 편향 (Self-scoring bias), 비용 및 검증 과제.
• Comprehension Debt: The Hidden Cost of AI-Generated Code (O'Reilly Radar) — 이해의 부채 (Comprehension Debt)의 정의와 검토되지 않은 코드 공개의 리스크.
• How AI assistance impacts the formation of coding skills (Anthropic Research) — "모든 AI 의존이 동일하지는 않다"는 실증 (주니어 52명 대상).
• Building a C compiler with a team of parallel Claudes (Anthropic Engineering) — 병렬 에이전트의 분산 설계와 "검증기 (Verifier)는 거의 완벽해야 한다".
• Measuring the Impact of Early-2025 AI on Experienced OSS Developer Productivity (METR) — 19% 지연 및 인지 격차 (주석이 포함된 RCT).
• State of AI-assisted Software Development 2025 (DORA) — "AI는 증폭기", "검토되지 않은 머지 (Unreviewed merge)의 증가".
• Context engineering (Simon Willison) — 컨텍스트 엔지니어링 (Context engineering) 용어 정리 (Lütke / Karpathy의 트윗 포함).
• Run prompts on a schedule (Claude Code 공식) / Keep Claude working toward a goal (/goal) — /loop, /goal의 공식 사양.
• Automations (OpenAI Codex 공식) — Codex의 자동 실행 공식 사양.