😗: 최근 Anthropic의 Boris나 OpenAI로 간 Openclaw 개발자 Peter 모두 Loop 에 관한 이야기를 하고 있다. Harness engineering 이후의 새로운 유행어인가? 둘은 무엇을 말하고 있지? 2025년의 Ralph loop와는 뭐가 다른가?

🤖: 네, 새 유행어는 맞습니다. 다만 완전히 새 개념이라기보다는 Ralph loop → harness engineering → loop engineering으로 추상화 수준이 올라간 것에 가깝습니다.

핵심은 이겁니다. 예전에는 사람이 “다음 프롬프트”를 썼고, harness engineering은 에이전트가 잘 일하도록 도구·테스트·관측성·권한·문서·워크트리 같은 실행 환경을 만들었습니다. OpenAI의 harness engineering 글도 인간의 일이 “코드를 쓰는 것”에서 “환경을 설계하고, 의도를 명세하고, Codex가 신뢰성 있게 일하게 하는 피드백 루프를 만드는 것”으로 옮겨갔다고 설명합니다. (OpenAI)

Loop engineering은 그 위층입니다. Addy Osmani의 정리는 꽤 정확한데, “사람이 에이전트를 프롬프트하는 역할을 대체하고, 그 일을 하는 시스템을 설계하는 것”입니다. 그는 이걸 harness보다 한 층 위, 즉 “harness가 타이머로 돌고, 작은 헬퍼들을 띄우고, 자기 자신에게 먹이를 주는 것”이라고 표현합니다. (Addy Osmani)

Boris가 말하는 것은 **“나는 Claude를 직접 프롬프트하지 않고, Claude를 프롬프트하는 루프를 쓴다”**입니다. WorkOS의 Acquired Unplugged 요약에 따르면 그는 IDE에서 직접 코딩하던 단계, 여러 Claude 세션을 병렬로 프롬프트하던 단계를 지나, 이제는 “무엇을 할지 판단하고 Claude를 호출하는 자동 워크플로”를 작성하는 쪽으로 역할이 이동했다고 설명합니다. (WorkOS) Anthropic 쪽 제품 맥락에서는 이것이 /loop, /schedule, 워크트리, 서브에이전트, 검증, 메모리, MCP 같은 Claude Code의 운영 프리미티브와 붙어 있습니다. Claude의 공식 power-user 문서도 /loop는 최대 3일 동안 로컬 반복 작업을 예약하고, /schedule은 클라우드에서 노트북이 닫혀도 계속 돌 수 있다고 설명합니다. (Claude Help Center)

Peter Steinberger 쪽은 표현이 더 실용적입니다. “coding agents를 프롬프트하지 말고, agents를 프롬프트하는 loops를 설계하라”는 말은, 사람이 매번 “다음에 뭐 해”를 치는 대신 PR babysit, CI green 만들기, 리뷰 반영, refactor, issue triage, 자동 merge 같은 반복 업무를 시스템화하라는 뜻입니다. Peter는 OpenClaw를 만든 뒤 OpenAI에 합류했고, OpenClaw는 독립·오픈소스로 유지하겠다고 밝혔습니다. 그의 글에서 목표는 “엄마도 쓸 수 있는 agent”를 만드는 것이고, 이를 위해 안전성과 최신 모델/연구 접근이 필요하다고 말합니다. (Steipete) 그의 다른 글에서도 fancy agent framework보다 CLI, tmux, 테스트, PR 명령, 짧은 반복, 실제 피드백 루프를 중시하는 태도가 보입니다. (Steipete)

2025년 Ralph loop와의 차이는 “원리”가 아니라 “스케일과 제품화”입니다. Ralph의 원형은 Geoff Huntley가 2025년 7월 설명한 매우 단순한 패턴입니다: while :; do cat PROMPT.md | claude-code ; done. 같은 프롬프트를 반복 실행하고, 코드베이스·fix_plan.md·AGENT.md·git history가 기억 역할을 합니다. (Geoffrey Huntley) Ralph의 중요한 규칙은 “한 루프에 한 가지 일”, “새 context window”, “파일시스템을 메모리로 사용”, “테스트/빌드로 backpressure를 걸기”입니다. Huntley 본인도 Ralph는 기존 코드베이스보다 greenfield 부트스트래핑에 더 적합하다고 못박습니다. (Geoffrey Huntley)

요약하면:

그래서 “Harness engineering 다음 유행어냐?”에 대한 제 답은: 맞다. 하지만 harness를 대체하는 게 아니라 harness를 반복 호출하는 운영 레이어다. Harness engineering이 “에이전트 한 번의 실행을 신뢰할 수 있게 만드는 기술”이라면, loop engineering은 “무슨 일을 언제 찾아서, 어떤 에이전트들에게 나눠 주고, 무엇으로 검증하고, 언제 사람에게 올릴지 설계하는 기술”입니다.

Ralph가 “어이없게 단순한데 작동하는 원형”이었다면, Boris/Peter가 말하는 loop는 그 아이디어가 제품 기능, 팀 운영, PR/CI/관측성, 다중 에이전트 orchestration으로 올라간 버전이라고 보면 됩니다.