이 기사는 AI(Claude)를 활용하여 작성되었습니다.

다음 사항에 주의해 주세요:

정보의 최신성: 기사 작성 시점(2026년 7월 26일)의 정보입니다. 이 분야는 변화가 매우 빨라 내용이 오래될 가능성이 있습니다 -
동작 확인: 본 기사에서 다루는 명령어 및 기능 명칭은 각 도구의 공식 문서에서 최신 사양을 반드시 확인해 주세요 -
출처 확인: 중요한 판단은 본문 중의 참고 링크나 1차 정보(Primary Information)를 통해 반드시 확인해 주시기 바랍니다 -
오류 가능성: AI 생성 콘텐츠에는 오류가 포함될 수 있습니다. 잘못된 점을 발견하시면 댓글로 지적해 주세요

코딩 에이전트(Coding Agent)를 매일 사용하다 보면, 다음과 같은 사이클에 빠져 있지 않으신가요?

"이것 좀 해줘" → 결과 확인 → "이 부분을 고쳐줘" → 다시 확인 → "한 번 더 시도해줘"……

이러한 프롬프트(Prompt)의 왕복 자체를 시스템이 대신하게 만들려는 사고방식이 2026년 6월에 급격히 확산된 "루프 엔지니어링 (Loop Engineering)"입니다. 이 기사에서는 이 개념의 유래, 구성 요소, 기존 도구에서의 구현 대응, 그리고 제창자 본인이 지적하는 한계까지를 1차 정보에 기반하여 정리합니다.

루프 엔지니어링은 Google에서 엔지니어링/데벨로퍼 릴레이션즈(Engineering/Developer Relations)를 이끄는 Addy Osmani 씨가 2026년 6월 7일 자신의 블로그에서 명명한 개념입니다1[^2]. 이후 O'Reilly Radar에도 저자 본인의 허가를 받아 전재되었습니다1.

그 핵심이 되는 사고방식은 개발자가 에이전트에게 한 단계씩 지시를 내리는 역할을 시스템 그 자체로 대체하는 것입니다. 인간이 달성하고자 하는 목표(Goal)를 하나 정의하면, 완료 조건을 충족할 때까지 AI가 시도를 반복하는 "재귀적인 목표 (Recursive Goal)"라는 발상이 베이스가 되어 있습니다1.

이 용어가 확산되는 계기로는, Peter Steinberger 씨의 "코딩 에이전트에게 일일이 프롬프트를 입력하는 것이 아니라, 에이전트에게 프롬프트를 계속해서 보내는 루프를 설계해야 한다"라는 취지의 발언과, Anthropic에서 Claude Code를 이끄는 Boris Cherny 씨의 "나는 이제 Claude에게 직접 프롬프트를 입력하지 않는다. 루프가 Claude에게 프롬프트를 보내고 판단도 수행한다. 나의 일은 루프를 작성하는 것이다"라는 취지의 발언이 Osmani 씨의 기사 내에서 소개되고 있습니다1[^3].

Osmani 씨 자신도 이 개념을 "아직 초기 단계이며, 나 자신도 회의적인 부분이 있다", "특히 토큰 비용(Token Cost)에는 주의가 필요하다"라고 유보적인 입장을 밝힌 점도 기사 내에서 명시되어 있습니다1.

국내의 해설 기사에서는 AI 주도 개발(AI-driven development)의 진화를 다음과 같은 세대로 정리하고 있는 것이 있습니다[^4].

Osmani 씨 자신도 이전에 "에이전트 하네스 엔지니어링 (Agent Harness Engineering)"(하나의 에이전트가 작동하는 환경의 설계)에 대해 쓴 적이 있으며, 루프 엔지니어링은 그보다 한 단계 더 높은 추상도에 위치한다고 말하고 있습니다1. 루프는 말하자면 타이머로 작동하며, 작은 헬퍼(Helper)를 생성하고, 자기 자신에게 피드백을 계속해서 주는 하네스(Harness)라는 설명입니다1.

Osmani 씨의 기사에서는 루프에 다음 5가지 요소와, 그 상태를 기억해 두기 위한 메커니즘이 필요하다고 합니다1.

오토메이션 (Automations): 스케줄에 따라 발견과 트리아지(Triage)를 자율적으로 수행하는 메커니즘 -
워크트리 (Worktrees): 여러 에이전트가 병렬로 작업해도 서로의 파일을 망가뜨리지 않기 위한 분리 환경 -
스킬 (Skills): 에이전트가 본래라면 추측에 의존해야 할 프로젝트 고유의 지식을 기록해 둔 것 -
플러그인/커넥터 (Plugins and connectors): MCP (Model Context Protocol)를 통해 기존 도구에 에이전트를 연결하는 메커니즘 -
서브 에이전트 (Subagents): 아이디어를 내는 에이전트와 그 성과를 검증하는 별도의 에이전트를 나누는 메커니즘

그리고 여섯 번째 요소로서, Markdown 파일이나 과제 관리 보드와 같은 "대화 외부에 존재하는 상태 (External State)"가 꼽히고 있습니다. 모델은 실행할 때마다 문맥을 잊어버리기 때문에, 이 기억은 대화 내부가 아니라 디스크 상에 두어야 한다는 설명입니다1.

Osmani 씨의 기사에서는 Codex (OpenAI)와 Claude Code (Anthropic) 모두 기사 작성 시점을 기준으로 이 5가지 요소를 모두 갖추고 있다고 정리되어 있습니다1.

※ 위 내용은 2026년 6월 시점의 기사 내용을 바탕으로 합니다. 두 도구의 기능명 및 사양은 변경될 가능성이 있으므로, 반드시 각사의 공식 문서에서 최신 정보를 확인하시기 바랍니다.

오토메이션은 루프를 '단발성 실행'이 아닌 '진정한 루프'로 만드는 부분입니다. Codex app의 Automations 탭에서는 대상 프로젝트, 실행할 프롬프트, 실행 빈도, 로컬 또는 백그라운드 워크트리 여부를 설정할 수 있으며, 무언가를 발견한 실행 결과는 트리아지용 수신함으로 보내지고, 아무것도 발견하지 못한 실행은 자동으로 아카이브된다고 합니다1. OpenAI 내부에서는 일일 과제 트리아지, CI 실패 요약, 커밋 개요 작성, 최근 버그 찾기 등, 사소하지만 반복이 많은 작업에 사용되고 있다고 합니다1.

Claude Code 측에서는 /loop를 통한 일정 간격의 재실행이나, cron 태스크 스케줄링, 에이전트 라이프사이클의 특정 타이밍에 쉘 명령어를 발화시키는 훅 (Hook), GitHub Actions로의 위임 등의 형태로 유사한 메커니즘이 구현되어 있습니다1.

세션 내의 프리미티브 (Primitive)로서, /loop가 일정 간격으로 재실행하는 것과 달리, /goal은 미리 작성한 조건이 충족될 때까지 실행을 계속하며, 각 턴이 끝난 후 다른 작은 모델이 완료 여부를 판정합니다. 즉, 작업한 에이전트 스스로가 채점하게 하지 않는 설계라는 점이 소개되어 있습니다1. Codex에도 동일한 이름의 /goal이 있으며, 검증 가능한 정지 조건이 충족될 때까지 여러 턴에 걸쳐 동작을 지속하며, 일시 정지, 재개, 완료가 가능하다고 합니다1.

여러 에이전트를 동시에 구동하는 순간, 파일 충돌이 가장 큰 문제가 됩니다. Git의 워크트리 (Worktree)는 동일한 리포지토리의 히스토리를 공유하면서도 별도의 브랜치에서 독립된 작업 디렉토리를 가질 수 있는 메커니즘으로, 이를 통해 한쪽 에이전트의 편집이 다른 쪽의 체크아웃에 물리적으로 영향을 주지 않게 됩니다1.

Codex는 이 워크트리 기능을 내장하여 제공하며, Claude Code는 git worktree나 --worktree 플래그, 서브 에이전트에 부여하는 isolation: worktree 설정 등을 통해 유사한 분리를 실현하고 있다고 합니다1. 다만, 워크트리가 해결하는 것은 기계적인 충돌일 뿐이며, 실제로 병렬로 돌릴 수 있는 수의 상한선은 인간 측의 리뷰 가능량이 결정한다는 지적도 기사 내에 언급되어 있습니다1.

스킬은 SKILL.md

SKILL.md라는 파일에 프로젝트 고유의 규약이나 빌드 절차, 과거의 인시던트(incident)를 바탕으로 한 '왜 이렇게 하지 않는가'와 같은 지식을 기록해 두는 메커니즘으로, Codex와 Claude Code 모두 동일한 포맷을 채택하고 있다고 합니다1. 스킬(skill)이 없다면 루프(loop)는 사이클마다 프로젝트를 처음부터 다시 추측해야 하지만, 스킬이 있다면 그 지식이 쌓여간다는 설명이 덧붙여져 있습니다1.

또한, 개별 스킬을 다른 리포지토리(repository)에서 공유하거나 여러 개를 묶어서 배포하는 단위가 '플러그인(plugin)'이며, 스킬 자체는 작성 포맷이고 플러그인은 그 배포 수단이라는 식으로 정리되어 있습니다1.

파일 시스템만 볼 수 있는 루프는 아주 작은 가치밖에 가지지 못합니다. MCP를 기반으로 하는 커넥터(connector)를 통해, 에이전트(agent)는 이슈 관리 도구를 읽거나, 데이터베이스에 질의하거나, 스테이징 환경의 API를 호출하거나, Slack에 메시지를 보낼 수 있게 됩니다1. Codex와 Claude Code는 모두 MCP에 대응하고 있기 때문에, 한쪽을 위해 작성한 커넥터가 다른 쪽에서도 그대로 동작하는 경우가 많다고 합니다1.

루프 안에서 구조적으로 가장 효과가 큰 것은, 코드를 작성하는 에이전트와 그것을 검증하는 에이전트를 분리하는 것입니다. 자신이 작성한 코드를 스스로 채점하는 것은 아무래도 관대해지기 쉽다는 이유 때문입니다1.

Codex는 .codex/agents/에 TOML 형식으로 서브 에이전트(sub-agent)를 정의하며, 이름·설명·지시·사용 모델·추론 강도 등을 개별적으로 설정할 수 있습니다. Claude Code도 .claude/agents/의 서브 에이전트나 에이전트 팀(agent team)이라는 형태로 유사한 메커니즘을 제공하고 있다고 합니다1. 전형적인 역할 분담은 1대가 조사하고, 1대가 구현하며, 1대가 사양(specification)과 대조하여 검증하는 3분할 방식입니다1.

Osmani 씨가 기사 내에서 제시한 예를 요약하면 다음과 같은 흐름이 됩니다1.

• 자동화(automation)가 매일 아침 리포지토리에 대해 실행된다.
• 해당 프롬프트가 트리아지(triage)용 스킬을 호출하여, 전날의 CI 실패·열려 있는 이슈·최근 커밋을 읽어 들인 뒤, 상태를 기록하는 Markdown 파일이나 이슈 관리 보드에 작성한다.
• 대응할 가치가 있는 항목별로 독립된 워크트리(worktree)를 열고, 1대의 서브 에이전트가 수정안을 작성한다.
• 다른 서브 에이전트가 해당 프로젝트의 스킬과 기존 테스트를 바탕으로 수정안을 리뷰한다.
• 커넥터를 통해 PR(Pull Request)을 열고 티켓을 업데이트한다.
• 루프가 처리하지 못한 것은 트리아지 수신함에 남는다.
• 상태 파일이 '무엇을 시도했고, 무엇이 통과되었으며, 무엇이 미결 상태인지'를 계속 기록하며, 다음 날 아침의 실행은 거기서부터 재개된다.

여기서 핵심은 인간은 이 일련의 절차를 단 한 번 설계했을 뿐이며, 개별 단계를 일일이 프롬프트한 것이 아니라는 점입니다1.

Osmani 씨는 루프가 뛰어날수록 역설적으로 선명해지는 과제로 다음 3가지를 꼽았습니다1.

• 검증은 여전히 인간의 영역이다: 무인으로 돌아가는 루프는 무인으로 실수도 저지른다. 서브 에이전트에 의한 검증을 분리하는 것도 루프의 '완료'라는 판정에 의미를 부여하기 위함이며, 그럼에도 '완료'는 어디까지나 주장일 뿐 증명은 아니라는 지적입니다.
• 이해의 부채(comprehension debt)가 확대된다: 자신이 작성하지 않은 코드가 빠르게 출하될수록, 실제로 존재하는 코드와 자신이 파악하고 있는 내용 사이의 격차가 벌어진다.
• '인지적 굴복(cognitive surrender)'의 위험: 루프가 자율적으로 돌아가게 되면, 자신의 의견을 갖는 것을 포기하고 나온 결과물을 그대로 받아들이고 싶어지는 유혹이 강해진다.

또한, 국내 해설 기사에서도 생성이 자동화되더라도 리뷰와 책임은 자동화할 수 없다는 구조적인 제약이 지적되고 있으며, 토큰(token) 비용이 단발 이용보다 몇 배에서 수십 배로 불어날 가능성이나, 판단을 동반하는 태스크(task) 또는 일회성 태스크에는 적합하지 않다는 등의 한계가 정리되어 있습니다[^5].

• 루프 엔지니어링 (Loop Engineering)은 Addy Osmani 씨가 2026년 6월 7일에 명명한 것으로, AI 에이전트에게 매번 프롬프트를 입력하는 대신 「프롬프트를 계속해서 보내는 루프 (Loop)」를 설계한다는 사고방식
• 루프는 ① 자동화 (Automation), ② 워크트리 (Worktree), ③ 스킬 (Skill), ④ 플러그인/커넥터 (Plugin/Connector), ⑤ 서브 에이전트 (Sub-agent), ⑥ 외부 상태 (External State)라는 5가지 요소 + 1개의 기억 장치로 구성됨
• Codex와 Claude Code는 명칭은 다르지만 이 5가지 요소를 모두 이미 갖추고 있다고 여겨짐
• 제창자 스스로도 아직 초기 단계이며 회의적인 부분도 있다고 명시하였으며, 검증 (Verification), 이해 부채 (Understanding Debt), 인지적 항복 (Cognitive Surrender)이라는 세 가지 과제는 자동화되지 않음
• 「루프를 만든다. 단, 고(Go) 버튼만 누르는 인간이 아니라, 엔지니어로 남을 생각으로 만든다」가 제창자의 맺음말입니다
  1