랠프 위검 루프 · 하네스 엔지니어링 · 루프 엔지니어링 — 공통점과 차이
들어가며
에이전틱 코딩 담론에서 최근 함께 언급되는 세 용어가 있음. 랠프 위검 루프(Ralph Wiggum Loop), 하네스 엔지니어링(Harness Engineering), 루프 엔지니어링(Loop Engineering)임. 경쟁하는 유행어처럼 소비되지만 실제로는 추상화 층위가 다른 중첩 구조에 가까움. 두 개의 정리 영상(개념 전반을 다룬 영상과 하네스 실전 예제를 다룬 영상)을 바탕으로, 세 개념이 무엇을 공유하고 어디서 갈라지는지 정리함. 출처와 수치는 원문으로 교차 확인함.
세 개념의 지도
한 문장씩 먼저 잡고 감.
- 랠프 위검 루프 — 가장 원시적인 형태. 같은 프롬프트 파일을 새 컨텍스트에서 무한 반복 실행하는 bash 루프임.
- 하네스 엔지니어링 — 모델을 제외한 나머지 전부. 에이전트 하나가 도는 환경을 설계하는 일임.
- 루프 엔지니어링 — 나를 대체하는 시스템. 하네스 위에서 여러 에이전트를 자동으로 굴리는 상위 층임.
셋은 대체 관계가 아니라 포함 관계임. 랠프 루프는 하네스 안에 부품으로 들어가고, 하네스는 루프 엔지니어링이 굴리는 단위가 됨.
1. 랠프 위검 루프
Geoffrey Huntley가 2025년 7월에 제시한 기법임. 이름은 심슨 가족의 랠프 위검에서 따옴. 형태는 문자 그대로 한 줄임.
while :; do cat PROMPT.md | claude-code ; done
롱러닝 에이전트라는 개념이 자리 잡기 전, 컨텍스트가 길어질수록 지시가 흐려지는 문제(context rot)를 우회하려고 나온 방식임. 작업을 잘게 쪼개고, 매 반복마다 상태를 디스크(fix_plan.md 같은 파일)와 git에 남긴 뒤, 새 컨텍스트에서 다시 시작함.
원칙은 세 가지임. 단일 에이전트 순차 실행, 상태는 디스크에, 매 턴 새 컨텍스트. 목표는 완성도가 아니라 진행률임. “루프가 주인공이지 모델이 주인공이 아니다”, “루프 안에 있지 말고 루프 위에 있어라”는 표현이 이 철학을 요약함.
흔한 오해 하나 짚고 감. 랠프 루프는 출력을 자기 입력으로 되먹이는 재귀가 아님. 매번 동일한 정적 프롬프트 파일을 새 컨텍스트에서 다시 실행할 뿐이고, 진행 상황은 대화 이력이 아니라 디스크와 git에 축적됨. 모델은 매 회차 잊지만 저장소는 잊지 않음.
2. 하네스 엔지니어링
핵심 공식은 에이전트 = 모델 + 하네스임. 하네스는 모델(LLM)을 제외한 나머지 전부를 가리킴.
이 용어가 정착한 계기는 OpenAI가 Codex 운용 방식을 공개한 글(Ryan Lopopolo, 2026년 초)이고, 여기서 나온 통찰을 Mitchell Hashimoto가 위 공식으로 압축함. 이후 Thoughtworks의 Birgitta Böckeler가 Martin Fowler 사이트에 정리한 가이드/센서(guides & sensors) 분류가 사실상 표준 어휘가 됨. 두 용어는 제어이론(사이버네틱스)에서 빌려온 것임.
- 가이드(피드포워드) — 행동 이전에 미리 조준하는 장치. CLAUDE.md·AGENTS.md, 시스템 프롬프트, 제약 문서, 툴 정의.
- 센서(피드백) — 행동 이후 결과를 관찰해 스스로 고치게 하는 장치. 린트, 테스트, 로그, 평가(eval).
두 축은 어느 하나만으로는 부족함. 피드백만 있으면 같은 실수를 반복하고, 피드포워드만 있으면 규칙은 있어도 검증이 안 됨. 둘이 맞물려야 사람이 실패를 관찰해 하네스를 고치는 조종 루프가 성립함.
사람의 역할은 코드 작성에서 환경 설계 · 의도 명시 · 피드백 루프 구축으로 이동함. 결과물을 직접 고치는 대신, 그 결과물을 만든 하네스를 고침.
OpenAI 내부 사례가 자주 인용됨. 엔지니어 3명이 5개월 동안 사람이 직접 작성한 코드 0줄로 약 100만 줄을 Codex가 생성하게 하고, 1,500건의 PR을 머지했다는 내용임. 그리고 이 Codex가 여러 리뷰어 에이전트를 만족시킬 때까지 도는 구조 자체가 “사실상 랠프 위검 루프”라는 지적이 붙음. 하네스 안에 랠프 루프가 부품처럼 들어간다는 뜻임.
참고: 원 영상 슬라이드에서 “1,500 별점”으로 읽었던 항목은 원문 기준 1,500건 PR 머지이고, “3”은 참여 엔지니어 3명임. 수치를 바로잡아 옮김.
3. 루프 엔지니어링
Addy Osmani(Google)가 2026년 6월에 이름 붙인 개념임. 정의는 “나를 대체하는 시스템”임. 즉 에이전트에게 프롬프트를 넣는 사람이 나 자신이었다면, 그 일을 대신하는 시스템을 설계하는 쪽으로 옮겨가는 것임.
동작은 act(행동) → observe(관찰) → decide(결정) → repeat(반복)의 피드백 사이클임. 하네스가 에이전트 하나가 도는 환경이라면, 루프 엔지니어링은 그 위에서 여러 하네스를 돌리는 “공장”임. Claude Code를 만든 Boris Cherny의 “내 일은 루프를 짜는 것”이라는 말이 자주 인용되지만, 이건 초대형 프로젝트 맥락이라는 점은 유의해야 함. Peter Steinberger의 “이제 에이전트에 프롬프트를 넣지 말고, 에이전트에 프롬프트를 넣는 루프를 설계하라”도 같은 맥락임.
여기서도 오해를 정정할 필요가 있음. 프롬프트 자체가 사라지는 게 아님. 결과를 보고 다시 개선을 요청하는 두 번째·세 번째·n번째 프롬프트를 시스템이 대신 넣게 만들어 줄이는 것임.
실제 데모(고양이 그림을 목표 이미지에 맞춰가는 루프)에서는 유사도 90%를 기준으로, 매 회차마다 이전 최고본을 비평 반영해 수정(act)하고, 헤드리스 렌더링으로 관찰(observe)하고, target.png와 비교해 0–100 점수와 비평을 review.json에 기록(decide)한 뒤 state.json을 갱신하고 반복(repeat)하는 과정을 23회차까지 보여줌. 다만 SVG처럼 원래 한 번에 만들 수 있는 대상이라면 이 방식 자체가 낭비라는 단서도 함께 달림.
공통점 — 세 개념이 합의하는 것
층위는 달라도 아래 다섯 가지는 공유함. 두 영상 모두 같은 방향을 가리킴.
- 모델이 아니라 그 주변 구조가 성패를 가름. 랠프의 “루프가 주인공”, 하네스의 “에이전트 = 모델 + 하네스”, 실전 영상의 “모델 성능이 아니라 하네스 설계 능력”이 전부 같은 명제임.
- 상태는 디스크에 남김. 모델은 매 실행 사이에 잊으므로 기억을 컨텍스트가 아니라 파일 시스템에 둠. 랠프는
fix_plan.md와 git, 실전 하네스는 EXEC_PLAN·로그·worktree 레지스트리로 같은 일을 함. - 검증 루프(센서/피드백)가 중심임. 린트·테스트·평가든,
verify-task.sh의 단위테스트·린트·빌드·아키텍처 검사·E2E든, 결과물을 직접 고치지 않고 결과물을 만든 장치를 고친다는 태도는 동일함. - 사람의 역할이 이동함. 코드를 쓰는 사람에서, 환경과 피드백 루프를 설계하는 사람으로 옮겨감.
- 출처가 겹침. 개념 영상이 인용한 OpenAI Codex 사례와, 실전 영상이 화면에 띄워 직접 읽은 OpenAI harness-engineering 블로그 글은 같은 뿌리임.
차이점 — 어디서 갈라지나
차이는 대부분 “추상화 층위”와 “단위”의 문제임.
| 개념 | 원저자 | 한 줄 정의 | 단위 | 초점 |
|---|---|---|---|---|
| 랠프 위검 루프 | Geoffrey Huntley (2025.07) | 같은 프롬프트를 새 컨텍스트에서 무한 반복 | 에이전트 1개, 순차 | 진행률 |
| 하네스 엔지니어링 | OpenAI · Böckeler/Fowler (2026 상반기) | 모델을 제외한 나머지 전부 | 에이전트 1개의 환경 | 가이드 + 센서 |
| 루프 엔지니어링 | Addy Osmani (2026.06) | 나를 대체하는 시스템 | 여러 하네스 = 공장 | act·observe·decide·repeat |
정리하면 랠프는 “가장 단순한 반복”, 하네스는 “그 반복을 감싸는 통제 환경”, 루프 엔지니어링은 “그 환경 여러 개를 자동으로 굴리는 상위 시스템”임. 새로운 개념이 계속 나오는 게 아니라, 같은 아이디어의 추상화 층위가 한 칸씩 올라갈 뿐임.
하네스를 무엇으로 쪼개는가 — 두 가지 공식 분해
하네스의 구성 요소를 어떻게 나누는지는 공식 문서마다 결이 조금 다름. 대표적인 두 갈래가 있음.
첫째, Thoughtworks의 Birgitta Böckeler가 Martin Fowler 사이트에 정리한 가이드/센서(guides & sensors) 분류임.
- 가이드(feedforward) — 행동 이전에 방향을 잡아주는 통제. 시스템 프롬프트, AGENTS.md, 제약 문서 등.
- 센서(feedback) — 행동 이후 결과를 관찰·검증하는 통제. 테스트, 린트, eval, 출력 파서 등.
두 용어는 제어이론(사이버네틱스)에서 빌려온 것이고, 각각을 다시 결정론적(computational: 테스트·린터·타입체커)과 추론적(inferential: AI 코드리뷰·LLM-as-judge)으로 나눠 2×2 행렬로 쓰기도 함. 정의는 원문 Harness engineering for coding agent users에 있음.
둘째, OpenAI가 Codex 운용 경험을 공개한 원문의 분해임. 이 글은 엔지니어의 역할을 “환경을 설계하고(design environments), 의도를 명시하고(specify intent), 피드백 루프를 구축하는(build feedback loops)” 세 가지로 정리함. 실제 구현으로는 앱을 에이전트가 직접 읽을 수 있게 만드는 관찰가능성(로그·메트릭·트레이스, Chrome DevTools 연동), 저장소 지식을 유일 근거로 삼는 컨텍스트(docs/ 디렉터리 + 목차 역할의 AGENTS.md), 아키텍처를 기계적으로 강제하는 제약(자동 검사·구조 테스트)으로 나타남. 원문은 Harness engineering: leveraging Codex in an agent-first world(Ryan Lopopolo, 2026.02)임. 이 글은 Codex가 여러 리뷰어를 만족시킬 때까지 도는 루프를 스스로 “사실상 Ralph Wiggum Loop”라고 부르며 Huntley의 원문으로 링크함.
두 분해는 용어만 다를 뿐 같은 곳으로 수렴함. 행동 전에 미리 조준하는 장치(가이드 · 컨텍스트 · 제약)와, 행동 후에 관찰·검증하는 장치(센서 · 관찰가능성 · 피드백 루프), 이 두 성질로 정리됨. 앞서 본 verify-task.sh나 훅·문서 같은 실전 요소도 결국 이 두 범주 중 하나에 속함.
하네스는 실제로 어떻게 생겼나 — 실전 예제
실전 영상은 하네스를 맨땅에서 설계하지 않음. OpenAI harness-engineering 블로그(한국어 번역본)를 화면에 띄워 정독한 뒤, 그 원문을 ChatGPT에 넣어 “이 글을 참고해 하네스 시스템을 만들어 줄 프롬프트를 만들어 달라”고 요청해 마스터 프롬프트를 뽑고, 그것을 Claude Code에 입력해 골격을 세움. 원문 정독 → 마스터 프롬프트 생성 → Claude Code로 구축, 3단계 흐름임.
구축된 하네스의 CLAUDE.md는 5단계 규칙으로 작업을 강제함.
- EXEC_PLAN 생성 —
scripts/start-task.sh <task-name> <type>실행 시 실행 계획·워크트리·포트·로그 디렉터리가 한 번에 생성됨. 계획 없이 코드 작성 금지. - 워크트리에서 구현 — 생성된 워크트리로 이동해 AGENTS.md → ARCHITECTURE.md → 관련 문서 순으로 읽고, master 브랜치 직접 수정 금지.
- 테스트 작성(필수) — Vitest + React Testing Library로 단위 테스트 작성.
npm test미통과 시 pre-commit 훅이 커밋을 차단함. - 검증 실행(필수) — 커밋 전
scripts/verify-task.sh실행. 단위 테스트, 린트, 빌드, 파일 크기 제한, 아키텍처 의존성, 문서 가드닝까지 전체 검사. 미통과 시 커밋 금지. - 커밋 → 머지 → 완료 — Conventional Commits 형식으로 커밋하고 master 머지 후
scripts/complete-task.sh <task-id>실행.
여기서 앞의 개념들이 코드로 어떻게 나타나는지 보임. 가이드는 CLAUDE.md·AGENTS.md·ARCHITECTURE.md라는 문서로, 센서는 verify-task.sh가 순서대로 도는 검사(단위테스트 → ESLint → 빌드 → 파일 크기 → 아키텍처 방향 → E2E/스크린샷)로, 상태 저장은 EXEC_PLAN(active/completed 이동)과 로그 아카이브로 구현됨. 데모에서는 “작성자 필드 추가” 기능이 계획 수립 → 구현 → 검증 통과 → git merge --no-ff 머지 → EXEC_PLAN active→completed 이동 → 로그 아카이브까지 전 라이프사이클을 한 바퀴 돎.
즉 실전 영상은 개념 영상이 말한 “가이드 + 센서 + 디스크 상태”를 스크립트와 훅으로 물성화한 사례임.
언제 무엇을 쓰나
기법은 작업 규모에 맞춰 고르는 것임.
- 초대형 프로젝트 — 새 기능이 기존 기능을 깨뜨리지 않는지 끝까지 검증해야 하므로 루프 엔지니어링이 사실상 필수임.
- 사이드 프로젝트 · MVP · PMF 탐색 — 프론티어 모델 성능만으로 충분한 경우가 많고, 무리하게 루프를 돌리면 오히려 시간과 토큰 낭비임.
앞의 고양이 데모가 좋은 반례임. 한 번에 만들 수 있는 산출물에 루프를 씌우는 건 낭비임. 규모와 본인 실력에 맞는 기법을 고르는 판단이 먼저임.
나선형으로 돌아온다 — 함대(fleet)
마지막 층이 하나 더 있음. Gautham Pai와 Peter Steinberger의 대화가 이를 보여줌. “하네스 엔지니어링은 작년 유행, 이제는 루프 엔지니어링”이라는 농담에, Steinberger는 “3개월 지나면 결국 함대(fleets)가 너희 루프를 설계하는 이야기를 하게 될 것”이라고 답함.
여러 에이전트를 함대처럼 운영하는 순간, 그 함대 전체를 설계·통제하는 상위 문제로 돌아감. 그리고 그 상위 문제는 다시 하네스 엔지니어링임. 층위가 올라가도 구조는 반복됨. 완전히 새로운 개념이 계속 등장하는 게 아니라, 같은 문제가 한 단계 위에서 다시 나타나는 나선형 순환임.
정리
- 랠프 위검 루프 · 하네스 엔지니어링 · 루프 엔지니어링은 경쟁 개념이 아니라 중첩된 층임. 랠프 ⊂ 하네스 ⊂ 루프 엔지니어링.
- 셋 다 “모델이 아니라 주변 구조가 성패를 가른다”, “상태는 디스크에”, “검증 루프가 중심”, “사람은 코드가 아니라 환경을 설계한다”는 데 합의함.
- 차이는 대부분 단위와 층위임. 반복 하나 → 그 반복을 감싼 환경 → 그 환경 여러 개를 굴리는 공장.
- 함대까지 올라가면 다시 하네스 설계 문제로 돌아오는 나선 구조가 전체의 결론임.
핵심은 하나임. 규모와 실력에 맞는 층위를 고르는 것. 작은 프로젝트에 함대를 씌우는 건, 고양이 한 장에 23회차 루프를 도는 것과 같음.
참고
- Geoffrey Huntley, Ralph Wiggum as a “software engineer” — ghuntley.com/ralph
- OpenAI (Ryan Lopopolo), Harness engineering: leveraging Codex in an agent-first world — openai.com/index/harness-engineering
- Birgitta Böckeler / Martin Fowler, Harness engineering for coding agent users — martinfowler.com
- Addy Osmani, Loop Engineering — addyosmani.com/blog/loop-engineering
Comments