루프 엔지니어링(Loop Engineering) — 에이전트를 프롬프트하는 시스템 설계

안녕하세요. 앱 개발 팀 피터 입니다.

이번 포스팅에서는 요즘 AI 개발 진영에서 가장 뜨거운 키워드 중 하나인 루프 엔지니어링(Loop Engineering)에 대해 다뤄보려고 합니다. 단순한 유행어인지, 아니면 프롬프트 엔지니어링 다음의 진짜 추상화 계층인지, 그 개념과 철학을 차근차근 살펴보겠습니다.

1. 한 문장이 일으킨 소동

2026년 6월 7일, Peter Steinberger가 X(트위터)에 짧은 문장을 하나 올립니다. 그는 오픈소스 AI 에이전트 프로젝트 OpenClaw의 창시자이자, GitHub 역사상 가장 빠르게 별(star)을 받은 신규 저장소를 만든 인물입니다.

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."— 더 이상 코딩 에이전트에 프롬프트하지 마라. 에이전트를 프롬프트하는 루프를 설계하라.

이 게시물은 며칠 만에 수백만 조회수를 넘겼고, 답글은 "이게 도대체 무슨 뜻이냐"를 두고 벌어진 난투극이 되었습니다. 흥미로운 점은, 거의 아무도 '루프'가 정확히 무엇인지 정의하지 못했다는 것입니다.

그보다 이틀 앞서, Anthropic에서 Claude Code를 만든 Boris Cherny가 무대 위에서 같은 이야기를 더 직설적으로 했습니다.

"I don't prompt Claude anymore. I have loops that are running. They're the ones prompting Claude and figuring out what to do. My job is to write loops."— 나는 더 이상 Claude에 프롬프트하지 않는다. 루프가 돌아간다. 루프가 Claude에 프롬프트하고 무엇을 할지 정한다. 내 일은 루프를 작성하는 것이다.

Cherny는 루프를 두고 "10년 뒤에 가장 자랑스러워할 기능"이라고까지 표현했다고 전해집니다. 두 사람의 발언, 수백만 조회수, 그리고 혼란의 물결. 이 글은 그 혼란을 정리하기 위해 쓰였습니다.

이 개념을 가장 명료하게 정리한 사람은 구글의 엔지니어 Addy Osmani입니다. 그는 자신의 블로그 글 「Loop Engineering」에서 이렇게 정의했습니다.

"루프 엔지니어링은 에이전트에 프롬프트하는 사람의 자리를 자기 자신에서 시스템으로 대체하는 것이다. 그 일을 대신하는 시스템을 직접 설계한다. 여기서 루프란 목적을 정의하면 AI가 완료될 때까지 반복하는 재귀적 목표(recursive goal)로 생각할 수 있다."— Addy Osmani

2. 지난 2년 동안 우리가 일하던 방식

루프가 무엇인지 이해하려면, 먼저 우리가 무엇을 떠나보내는지를 봐야 합니다.

지난 약 2년간 코딩 에이전트에서 무언가를 얻어내는 방식은 단순했습니다. 좋은 프롬프트를 쓰고, 충분한 컨텍스트를 줍니다. 한 줄을 입력하고, 돌아온 결과를 읽고, 다음 줄을 입력합니다. 에이전트는 도구였고, 여러분은 그 도구를 처음부터 끝까지 손에 쥐고 있었습니다. 한 턴, 또 한 턴.

지시를 만들고, 기다리고, 돌아온 것을 훑어보고, 조정해서 다음 지시를 보냅니다. 여러분의 주의력이 곧 엔진이었습니다. 키보드에서 손을 떼는 순간 에이전트는 중간에 얼어붙었죠.

그 자세가 끝나가고 있습니다. 적어도 일부는 그렇게 보고 있습니다. 이제는 작업을 찾아내고, 분배하고, 검증하고, 무엇이 끝났는지 기록하고, 다음에 할 일을 결정하는 작은 시스템을 만듭니다. 그리고 그 시스템이 여러분 대신 에이전트를 찌르게 합니다. 여러분은 타이핑하는 대신 지켜봅니다.

Osmani는 이 개념의 사촌격인 두 가지를 언급합니다. 하나는 에이전트 하네스 엔지니어링(agent harness engineering) — 단일 에이전트 하나가 그 안에서 도는 환경을 만드는 일. 다른 하나는 팩토리 모델(factory model) — 소프트웨어를 만드는 시스템 그 자체. 루프 엔지니어링은 하네스의 한 층 위에 있습니다. 타이머로 실행되고, 작은 헬퍼들을 생성하며, 스스로에게 먹이를 주는 하네스입니다.

3. 이건 이제 '도구'의 문제가 아니다

Osmani가 가장 놀랐던 지점은, 이것이 더 이상 도구의 문제가 아니라는 사실이었습니다.

1년 전만 해도 루프를 원하면 bash 스크립트 더미를 직접 작성해야 했습니다. 그리고 그 더미를 영원히 직접 유지보수해야 했죠. 오로지 여러분만 이해하는 코드였습니다.

이제는 그 구성 요소들이 제품 안에 그대로 탑재되어 출시됩니다. Steinberger가 나열한 "루프에 필요한 것들"의 목록이 OpenAI의 Codex 앱과 거의 정확히 일치하고, Anthropic의 Claude Code와도 거의 동일합니다.

이 사실이 함의하는 바는 중요합니다. 일단 그 형태(shape)가 어느 도구에서나 같다는 것을 알아차리면, "어느 에이전트가 최고인가"를 두고 다투기를 멈추게 됩니다. 대신 어느 쪽에 앉아 있든 동작하는 루프를 설계하기 시작합니다. 루프의 형태는 점점 도구 비종속적(tool-agnostic)이 되어가고 있습니다.

4. 잠깐, 이 모든 건 어디서 왔나 — Ralph 루프

루프 엔지니어링이라는 깔끔한 용어가 2026년 6월에 자리 잡았지만, 그 밑바탕에 깔린 아이디어는 그보다 1년 가까이 앞섭니다.

독립 소프트웨어 엔지니어 Geoffrey Huntley는 2025년 7월(원형은 더 일찍), 거칠지만 효과적인 반복 기법에 "Ralph Wiggum"이라는 이름을 붙였습니다. 심슨 가족의 그 캐릭터 — 문틀에 머리를 박으면서 "나 돕고 있어!"를 외치는 — 에서 따온 이름입니다. 동시에 'Ralph'는 영어 속어로 '구토하다'라는 뜻이기도 한데, Huntley는 자율 코드 생성이 이렇게까지 싸졌다는 사실을 깨닫고 토할 것 같았다고 말했습니다. 그래서 캐릭터 Ralph와 동사 Ralph, 둘 다 들어맞습니다.

Huntley의 정의는 단순함 그 자체였습니다. "Ralph는 bash 루프다." 가장 순수한 형태로는, AI 에이전트에게 같은 프롬프트 파일을 완료될 때까지 반복해서 먹이는 while 루프일 뿐입니다.

그런데 이 "멍청하고 끈질긴" 루프가 놀랍도록 효과적이었습니다. Huntley는 이 기법으로 CURSED라는 완전한 프로그래밍 언어를 거의 전적으로 AI만으로, 3개월간의 자율 운영을 통해 만들어냈습니다.

note2145d8c9

왜 매 반복마다 새 컨텍스트로 시작하는가?

이것은 부작용이 아니라 바로 그 목적입니다. LLM은 컨텍스트가 차오를수록 성능이 떨어집니다. 모델에 따라 대략 10만~15만 토큰을 넘어서면 품질이 측정 가능할 만큼 저하됩니다. 실무자들은 이를 "멍청해지는 구간(Dumb Zone)"이라 부릅니다. 긴 에이전트 세션은 필연적으로 그곳으로 흘러가고, 자동 컨텍스트 압축(compaction)은 손실이 큽니다.

Ralph의 해법은 우아합니다. 에이전트는 잊어버립니다. 하지만 저장소(repo)는 잊지 않습니다. 상태는 대화 기록이 아니라 코드베이스, TODO 파일, git 히스토리를 통해 반복 사이에 살아남습니다.

Huntley의 또 다른 통찰 하나. 주 컨텍스트 윈도우는 직접 일하지 말고 스케줄러처럼 작동해야 한다는 것입니다. 비싼 할당 작업 — 테스트 스위트가 통과했는지 요약하는 것 같은 — 은 서브에이전트를 생성해 맡깁니다. 이 패턴이 나중에 루프 엔지니어링의 핵심 구조 중 하나가 됩니다.

흥미로운 후일담으로, Anthropic은 나중에 이 기법을 Claude Code의 "Ralph Wiggum" 플러그인으로 공식 패키징했습니다. Huntley는 이에 대해 복잡한 심경을 내비쳤습니다. 플러그인 방식이 단일 세션 안에서 돌면서 Ralph의 핵심인 '항상 새로운 컨텍스트'를 놓친다는 점을 우려한 것이죠.

정리하면 — 루프 엔지니어링은 이 Ralph의 정신(새로운 컨텍스트, 디스크에 저장된 상태, 끈질긴 반복) 위에서, 제품에 내장된 구성 요소들로 더 정교하게 조립된 형태라고 볼 수 있습니다.

5. 루프를 이루는 5가지 구성 요소 + 메모리

Osmani의 정리에 따르면, 하나의 루프에는 다섯 가지가 필요하고, 거기에 상태를 기억할 한 곳이 추가됩니다. 두 제품(Claude Code, Codex) 모두 현재 이 다섯 가지를 전부 보유하고 있습니다. 이름만 조금씩 다를 뿐 능력은 동일합니다.

1. Automations — 루프의 심장 박동

Automations는 루프를 '한 번 실행한 것'이 아니라 실제 '루프'로 만드는 요소입니다. 스케줄에 따라 스스로 발동해 발견(discovery)과 분류(triage)를 수행합니다.

Codex 앱에서는 Automations 탭에서 만듭니다. 무언가를 발견한 실행은 Triage 인박스로 가고, 아무것도 못 찾은 실행은 스스로 아카이브됩니다. Claude Code는 스케줄링과 hooks로 같은 지점에 도달합니다. /loop으로 일정 간격마다 실행하고, cron 작업을 스케줄링하고, hooks로 셸 명령을 발사합니다.

여기서 이 글의 핵심에 가장 가까운 프리미티브가 등장합니다. /loop이 정해진 주기마다 재실행하는 것이라면, /goal은 여러분이 작성한 조건이 실제로 참이 될 때까지 계속합니다. 그리고 매 턴이 끝날 때마다 별도의 작은 모델이 완료 여부를 검사합니다 — 코드를 쓴 에이전트가 채점자가 되지 않도록 말이죠.

"크론잡 리브랜딩 아니냐"는 비판에 대하여 — 한 회의적 트윗은 "크론잡이 요즘 재밌게 리브랜딩되고 있다"고 꼬집었습니다. 절반은 맞는 말입니다. 2026년 루프의 스케줄링 레이어는 실제로 cron이거든요. 하지만 cron이 단 한 번도 가져본 적 없는 것이 있습니다. 바로 그 가운데에 있는 의사결정 로직입니다. cron 작업은 매번 같은 스크립트를 실행하지만, 루프는 현재 상태를 보고 무엇을 할지 결정하고 행동하고 확인하고 계속할지 멈출지를 결정하는 모델을 실행합니다. 정직한 표현은 이것입니다 — 루프는 'cron + 본문에 들어간 의사결정자'입니다.

2. Worktrees — 병렬이 혼돈이 되지 않도록

에이전트를 둘 이상 돌리는 순간, 파일이 충돌하기 시작합니다. 두 에이전트가 같은 파일을 쓰는 것은, 두 엔지니어가 서로 한 마디도 안 하고 같은 줄을 커밋하는 것과 똑같은 두통입니다.

git worktree가 이를 해결합니다. 같은 repo 히스토리를 공유하면서 각자의 브랜치 위에 있는 별도의 작업 디렉터리라, 한 에이전트의 편집이 다른 쪽의 체크아웃에 물리적으로 닿을 수 없습니다.

3. Skills — 매번 프로젝트를 다시 설명하지 않도록

Skill은 매 세션마다 금붕어처럼 같은 프로젝트 컨텍스트를 다시 설명하는 일을 멈추는 방법입니다. 두 도구 모두 같은 포맷을 씁니다 — 지시문과 메타데이터를 담은 SKILL.md 파일이 든 폴더, 그리고 선택적인 스크립트·참조·에셋.

여기서 핵심 개념이 나옵니다. 의도(intent)가 반복 비용이 되지 않게 하는 곳이 바로 skill입니다. 에이전트는 매 세션을 차가운 상태로 시작하고, 의도의 빈틈을 자신만만한 추측으로 메웁니다(Osmani는 이를 "의도 부채, intent debt"라 부릅니다). Skill은 그 의도를 외부에 적어둔 것입니다. "그 사건 때문에 우리는 이렇게는 안 한다" 같은 것을 한 번 적어두면 에이전트가 매 실행마다 읽습니다.

Skill이 없으면 루프는 매 사이클마다 프로젝트 전체를 0에서 재유도합니다. Skill이 있으면 그것이 누적되어 복리처럼 쌓입니다. 표현을 빌리자면, 프롬프트는 태워 없어지고, skill은 복리로 쌓입니다.

4. Plugins·Connectors — 루프가 실제 도구에 닿게

파일시스템만 볼 수 있는 루프는 작은 루프입니다. MCP(Model Context Protocol) 기반의 connector가 에이전트로 하여금 이슈 트래커를 읽고, DB에 질의하고, 스테이징 API를 호출하고, Slack에 메시지를 떨어뜨리게 합니다.

이것이 "여기 수정안이 있습니다"라고 말하는 에이전트와, PR을 열고 Linear 티켓을 연결하고 CI가 green이 되면 채널에 핑을 보내는 루프의 차이입니다. Connector는 루프가 실제 환경 안에서 행동하게 만드는 이유입니다.

5. Sub-agents — 만드는 쪽과 검사하는 쪽을 분리

루프에서 가장 유용한 구조는, 단연코 코드를 쓰는 쪽과 검사하는 쪽을 분리하는 것입니다. 코드를 쓴 모델은 자기 숙제를 채점할 때 너무 관대합니다. 다른 지시문과, 때로는 다른 모델을 가진 두 번째 에이전트가 첫 번째가 스스로 납득해버린 것을 잡아냅니다.

두 도구의 통상적 분담은 한 에이전트가 탐색, 하나가 구현, 하나가 스펙 대비 검증입니다. 이것이 루프 안에서 특별히 중요한 이유가 있습니다. 루프는 여러분이 보지 않는 동안 돌기 때문에, 진짜 신뢰할 수 있는 검증자(verifier)가 있어야만 자리를 떠날 수 있습니다.

사실 Claude Code의 /goal이 내부적으로 하는 일이 바로 이것입니다. 만드는 자(maker)와 검사하는 자(checker)의 분리를, 정지 조건 그 자체에 적용한 것이죠.

＋메모리 — 잊는 모델을 보완하는 한 곳

여섯 번째는 메모리입니다. markdown 파일이든, Linear 보드든, 단일 대화 밖에 살면서 무엇이 끝났고 다음에 무엇을 할지를 보관하는 곳. 너무 단순해서 중요할 것 같지 않지만, 이것은 모든 장기 실행 에이전트가 의존하는 동일한 트릭입니다. 모델은 실행과 실행 사이에 모든 것을 잊으므로, 메모리는 컨텍스트가 아니라 디스크에 있어야 합니다.

6.하나의 루프는 실제로 어떻게 생겼나

이 구성 요소들을 합쳐 놓으면, 단일 스레드가 작은 제어판으로 바뀝니다. Osmani가 반복해서 쓴다는 한 가지 형태는 이렇습니다.

매일 아침, automation이 repo에서 실행됩니다. 그 프롬프트가 triage skill을 호출해 어제의 CI 실패, 열린 이슈, 최근 커밋을 읽고, 결과를 markdown 파일이나 Linear 보드에 기록합니다. 할 가치가 있는 각 항목마다, 스레드는 격리된 worktree를 열어 서브에이전트에게 수정 초안을 맡깁니다. 그리고 두 번째 서브에이전트가 그 초안을 프로젝트 skill과 기존 테스트에 비추어 리뷰합니다. Connector가 루프로 하여금 PR을 열고 티켓을 갱신하게 합니다. 그리고 상태 파일(state file)이 이 전체의 척추입니다 — 내일 아침의 실행이 오늘 멈춘 바로 그 지점에서 이어가게 하죠.

그리고 여기서 여러분이 실제로 무엇을 했는지 보세요. 여러분은 이것을 단 한 번 설계했습니다. 저 단계들 중 어느 것도 직접 프롬프트하지 않았습니다. 이것이 Steinberger의 요점이 현실이 된 모습이고, Codex든 Claude Code든 구성 요소가 같으므로 같은 루프입니다.

7. 그래서 '하네스'와는 뭐가 다른가?

여기서 한 가지 짚고 넘어가야 합니다. 앞에서 "루프는 하네스의 한 층 위에 있다"고만 했는데, 그럼 하네스(harness)와 루프는 구조적으로 정확히 무엇이 다를까요? 이걸 이해하면 루프 엔지니어링이 왜 새로운 이름을 가질 자격이 있는지가 분명해집니다.

＝먼저, 하네스란 무엇인가

Osmani가 이전 글에서 제시한 유명한 공식이 있습니다.

Agent = Model + Harness에이전트 = 모델 + 하네스  |  "당신이 모델이 아니라면, 당신은 하네스다."

코딩 에이전트는 모델 그 자체가 아니라, 모델을 둘러싸고 여러분이 직접 만든 모든 것을 합친 것입니다. 프롬프트, 도구, 컨텍스트 정책, hooks, 샌드박스, 서브에이전트, 피드백 루프, 복구 경로 — 이 비계(scaffolding) 전체가 하네스입니다. Claude Code, Cursor, Codex, Aider, Cline... 이것들이 전부 하네스입니다. 그 아래 모델은 같을 때도 있지만, 여러분이 실제로 체감하는 동작은 하네스가 무엇을 하느냐가 지배합니다.

하네스 엔지니어링의 핵심 정신은 "래칫 원리(Ratchet Principle)"입니다. 에이전트가 실수를 할 때마다, 그 실수를 다시는 못 하도록 비계를 한 칸씩 조여나가는 것이죠. 에이전트가 컨벤션을 몰랐다 → AGENTS.md에 적는다. 에이전트가 위험한 명령을 실행했다 → hook으로 막는다. 즉 하네스는 "에이전트 한 번의 실행을 어떻게 잘 끝내게 만들까"에 답하는 분야입니다.

↻루프는 거기에 '시간'을 더한다

여기서 결정적 차이가 나옵니다. 하네스가 공간(에이전트가 일하는 환경)을 설계하는 것이라면, 루프는 거기에 시간 축 — 스케줄, 반복, 그리고 실행과 실행 사이를 잇는 상태 — 을 얹은 것입니다.

쉽게 공식으로 표현하면 이렇습니다.

하네스 = 모델 + 비계 → "에이전트 한 번을 잘 돌리는 환경"
루프 = 하네스 + (스케줄 · 반복 · 메모리) → "그 환경을 스스로 반복해서 돌리고 먹이를 주는 시스템"

Osmani 자신의 표현을 빌리면 이렇습니다. "하네스지만, 그것이 타이머 위에서 돌고, 작은 헬퍼들을 생성하며, 스스로에게 먹이를 준다(The harness but it runs on a timer, it spawns little helpers, and it feeds itself)." 즉 루프는 하네스를 부정하는 게 아니라, 하네스를 자기 자신을 호출하는 무언가로 감싼 것입니다.

⇄한눈에 보는 차이

둘의 차이를 표로 정리하면 다음과 같습니다.

🔍 5가지 구성 요소를 다시 보면앞서 본 루프의 다섯 요소를 이 관점에서 다시 분류하면 명확해집니다. Worktrees · Skills · Connectors · Sub-agents 이 네 가지는 사실 하네스에도 존재하던 요소입니다. 루프가 진짜로 새로 더한 것은 단 두 가지 — Automations(스케줄/반복)와 메모리(실행 사이의 상태)입니다. 바로 이 둘이 '한 번 도는 하네스'를 '스스로 도는 루프'로 바꾸는 결정적 부품입니다.

그래서 "루프는 그냥 크론잡 아니냐"는 비판이 절반만 맞는 이유도 여기 있습니다. 시간 축을 더한다는 점에서는 크론과 닮았지만, 루프가 반복적으로 호출하는 대상이 고정된 스크립트가 아니라 판단하는 하네스 전체라는 점이 다릅니다. 크론은 같은 스크립트를 반복하고, 루프는 매번 상황을 새로 판단하는 에이전트를 반복합니다.

8. 루프가 여전히 대신해 주지 않는 것

여기까지 들으면 마법처럼 들릴 수 있습니다. 하지만 루프는 일을 바꿀 뿐, 여러분을 그 일에서 지우지 않습니다. 오히려 세 가지 문제는 루프가 좋아질수록 더 쉬워지는 게 아니라 더 날카로워집니다.

1. 검증은 여전히 여러분 몫이다

무인으로 도는 루프는 곧 무인으로 실수하는 루프이기도 합니다. 검증자 서브에이전트를 분리하는 이유는 루프의 "끝났다(done)"에 의미를 부여하기 위함이지만, 그래도 "done"은 증명이 아니라 주장입니다. 한 트윗이 정곡을 찔렀습니다 — "루프를 설계하는 건 절반이다. 나머지 절반은 루프 안에 '아니오'라고 말할 수 있는 무언가를 넣는 것이다. 테스트, 타입 체크, 진짜 에러." 약한 테스트를 주면, 루프는 약한 테스트를 통과시킬 뿐입니다.

2. 이해는 방치하면 썩는다

루프가 여러분이 직접 쓰지 않은 코드를 빨리 출하할수록, 존재하는 것과 여러분이 실제로 이해하는 것 사이의 간극이 커집니다. Osmani는 이를 이해 부채(comprehension debt)라 부릅니다. 매끄러운 루프는, 여러분이 그것이 만든 것을 읽지 않는 한, 그 간극을 더 빨리 키웁니다.

3. 편안한 자세가 가장 위험한 자세다

루프가 스스로 돌면, 의견 갖기를 멈추고 돌려받은 것을 그대로 받아들이기 쉽습니다. Osmani는 이를 인지적 항복(cognitive surrender)이라 부릅니다. 루프 설계는 판단을 갖고 하면 치료제이고, 사고를 피하려고 하면 가속제입니다. 같은 행동, 정반대의 결과.

한 개발자는 가장 근본적인 질문을 던졌습니다. 그는 SEO 감사 에이전트를 만들어 24시간 토큰을 태울 수 있었지만 그러지 않았습니다. 돈 때문이 아니라, "그게 실제로 뭘 하고 있을 건데?"라는 기본적인 질문에 답할 수 없었기 때문이죠. 그의 한 줄이 인상적입니다."끝에 고객이 없다면, 루프를 설계하는 것은 더 나은 자세로 하는 미루기일 뿐이다."

9. 마치며 — 루프를 만들되, 엔지니어로 남아라

Osmani 본인의 결론은 신중합니다. "나는 이것이 우리 일이 진화하는 방식의 예고편이라고 생각한다. 그렇긴 하지만, 만약 내가 코드를 직접 리뷰하지 않거나 자동 루프에만 전적으로 의존했다면, 내 제품의 품질은 떨어졌을 것이다. 아마 점점 더 깊은 구멍을 파면서 하향 나선에 갇혔을 것이다."

그러니 루프를 설정하세요. 하지만 에이전트에 직접 프롬프트하는 것도 여전히 효과적이라는 사실을 잊지 마세요. 핵심은 적절한 균형을 찾는 것입니다.

가장 날카로운 통찰은 마지막에 있습니다. 같은 루프를 만든 두 사람이 정반대의 결과를 얻을 수 있습니다. 한 명은 깊이 이해하는 일을 더 빨리 하기 위해 루프를 씁니다. 다른 한 명은 일을 아예 이해하지 않으려고 루프를 씁니다. 루프는 그 차이를 모릅니다. 여러분은 압니다.

이것이 루프 설계를 프롬프트 엔지니어링보다 쉽게가 아니라 더 어렵게 만드는 이유입니다. Cherny의 요점은 일이 쉬워졌다는 게 아닙니다. 레버리지 지점이 옮겨갔다는 것입니다. 루프는 여러분이 루브릭과 skill과 검증 단계에 넣은 판단을 — 그것이 무엇이든 — 증폭시킵니다. 그 세 가지가 진짜 안목(taste)을 담고 있어야 합니다.

루프를 만들어라. 하지만 그저 시작 버튼을 누르는 사람이 아니라, 엔지니어로 남을 작정인 사람처럼 만들어라.Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.

---

참고 자료

• Addy Osmani, "Loop Engineering" (2026년 6월, http://addyosmani.com / Elevate)

• Peter Steinberger (), OpenClaw 창시자 — 2026년 6월 7일 게시물

• Boris Cherny (), Anthropic Claude Code 책임자 — 무대 발언

• Geoffrey Huntley (http://ghuntley.com ), "Ralph" 기법의 창시자 (2025년 7월)

• 기타 커뮤니티 논의(Firecrawl, Lushbinary, explainx 등) 및 Claude Code / OpenAI Codex 공식 문서

이 글은 위 자료들을 바탕으로 루프 엔지니어링의 철학과 개념을 소개하기 위해 정리한 것입니다. 도구의 구체적 명령어와 기능은 빠르게 바뀌므로, 실제 사용 전에는 각 벤더의 최신 문서를 확인하시길 권합니다.