루프 엔지니어링 입문: 반복보다 멈추는 조건을 설계하는 일

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops

Anthropic 에서 Claude Code 를 이끄는 Boris Cherny 가 남긴 말입니다. 더는 Claude 에게 직접 프롬프트를 쓰지 않고, 프롬프트를 대신 써 주는 루프를 짠다고 합니다. Addy Osmani 는 2026년 6월 이 흐름에 루프 엔지니어링이라는 이름을 붙였고, 그 뒤로 이 말이 빠르게 퍼졌습니다.

흔한 오해, 에이전트를 while 문에 넣는 기술

이름 때문에 루프 엔지니어링을 「에이전트를 끝날 때까지 계속 돌리는 기술」로 이해하기 쉽습니다. 반은 맞습니다. 실제로 가장 유명한 루프는 셸 한 줄짜리 while 문입니다. 그런데 이렇게 이해하면 같은 while 문이 어떤 때는 쓸 만한 코드를 내고 어떤 때는 토큰만 태우는 이유가 설명되지 않습니다.

저는 루프 엔지니어링의 무게가 반복 쪽이 아니라 반복을 끊는 쪽에 있다고 봅니다. 무엇을 보고 다음 일을 고르는지, 무엇으로 결과를 확인하는지, 언제 멈추고 언제 사람에게 넘기는지. 이 셋이 빠진 루프는 열심히 일하는 것처럼 보이면서 같은 자리를 돕니다.

프롬프트 대신 루프를 쓰는 엔지니어

Osmani 의 정의는 짧습니다.

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

에이전트에게 프롬프트를 넣는 사람 자리에서 내려오고, 그 일을 하는 시스템을 설계한다는 뜻입니다. 그는 루프를 「목적을 정하면 AI 가 끝날 때까지 반복하는 재귀적 목표」라고도 부릅니다. 같은 맥락에서 Peter Steinberger 는 「이제 코딩 에이전트에게 프롬프트를 쓰지 말고, 에이전트에게 프롬프트를 쓰는 루프를 설계하라」고 했습니다.

Osmani 가 루프의 부품으로 꼽은 것은 정해진 때에 일을 시작시키는 자동 실행, 작업마다 폴더를 갈라 주는 worktree, 반복해서 쓰는 지침인 스킬, 외부 도구를 붙이는 플러그인과 커넥터, 일을 나눠 맡는 서브에이전트입니다. 여기에 대화 바깥에 남는 기억을 하나 더 붙입니다. 마크다운 파일이든 이슈 보드든 상관없다고 하면서 이렇게 씁니다. 「에이전트는 잊지만, 저장소는 잊지 않는다.」

하네스, 오케스트레이션과 갈리는 층

비슷한 시기에 같이 쓰이는 말이 셋이라 헷갈립니다. 앞선 글에서 하네스와 오케스트레이션을 나눴는데, 루프 엔지니어링은 그 사이에 끼는 층입니다.

말	설계하는 것	묻는 질문
하네스	모델 하나를 둘러싼 환경	무슨 도구를 쓰고, 무엇을 허락받나
루프 엔지니어링	그 환경 안에서 도는 반복	무엇을 보고 다음 일을 고르고, 언제 멈추나
오케스트레이션	여러 모델과 세션 사이의 분업	누가 무엇을 맡고, 결과를 어떻게 합치나

작업장에 비유하면 하네스는 작업장과 연장, 루프는 그 안의 작업 순서, 오케스트레이션은 여러 작업장 사이의 분업입니다. 셋은 따로 놀지 않습니다. 루프는 하네스가 허락한 도구로만 돌고, 오케스트레이션은 여러 루프를 묶은 것으로 볼 수 있습니다.

가장 단순한 루프, Ralph

Geoffrey Huntley 가 2025년 7월에 공개한 Ralph는 루프 엔지니어링이라는 말보다 먼저 나온, 가장 단순한 루프입니다. 이름은 심슨 가족의 랄프 위검에서 왔습니다.

while :; do cat PROMPT.md | claude-code ; done

같은 프롬프트를 에이전트에 넣고, 끝나면 또 넣습니다. 매번 맥락은 새로 시작하고, 이어지는 상태는 전부 파일에 둡니다. 할 일 목록인 fix_plan.md, 빌드와 실행 방법을 적은 AGENT.md, 그리고 커밋입니다. 규칙은 「한 루프에 한 항목」입니다.

Huntley 는 이 방식을 「비결정적인 세계에서 결정적으로 나쁜」 기술이라고 부릅니다. 매번 나쁘게 굴더라도 같은 방식으로 나쁘니, 프롬프트를 고쳐 가며 길들일 수 있다는 뜻입니다. 길들이는 도구가 그가 말하는 배압(backpressure)입니다. 테스트, 타입 검사, 빌드처럼 틀린 코드를 되돌려 보내는 장치를 루프에 물리고, 기능을 고칠 때마다 해당 테스트를 돌리게 합니다. 그는 이 방식이 새로 시작하는 프로젝트에 가장 잘 맞고, 엔지니어는 여전히 필요하다고 덧붙입니다.

Ralph 를 보면 오해가 어디서 생기는지 보입니다. 눈에 띄는 것은 while 한 줄이지만, 실제로 일을 하는 것은 그 바깥의 할 일 목록과 테스트입니다.

루프의 성패를 가르는 종료 조건

루프를 멈추는 방식은 크게 둘입니다. 시간으로 멈추거나, 조건으로 멈춥니다.

Claude Code 의 /loop 은 시간 쪽입니다. 간격을 주면 그 간격을 cron 표현으로 바꿔 프롬프트를 되풀이합니다. 간격을 비우면 1분에서 1시간 사이에서 Claude 가 다음 실행 시점을 스스로 고릅니다. 반복 작업은 만든 지 7일이 지나면 마지막으로 한 번 돌고 스스로 지워집니다. 루프가 잊힌 채 영원히 도는 것을 구조로 막아 둔 셈입니다.

/goal 은 조건 쪽입니다. Osmani 는 이걸 「직접 써 둔 조건이 실제로 참이 될 때까지 계속 가는 것」이라고 설명하고, 「test/auth 의 테스트가 모두 통과하고 lint 가 깨끗할 것」을 예로 듭니다. 매 턴이 끝날 때마다 작은 모델이 조건을 만족했는지 따로 확인합니다.

저는 여기서 두 번째 방식이 루프 엔지니어링의 핵심이라고 봅니다. 조건을 「다 되면」으로 쓰면 에이전트가 다 됐다고 말하는 순간 루프가 끝납니다. Osmani 의 표현으로는 「'다 됐다'는 주장일 뿐 증명이 아닙니다.」 조건은 에이전트의 말이 아니라 명령의 결과로 확인할 수 있게 써야 합니다. 테스트 통과, 빌드 성공, 특정 파일의 존재처럼요. 확인하는 쪽도 일하는 쪽과 갈라 두는 편이 낫습니다. 만든 사람이 검사까지 하면 같은 착각을 두 번 하기 때문입니다.

사람에게 넘기는 조건도 종료 조건의 하나입니다. 되돌리기 어려운 행동을 앞두었을 때, 같은 실패가 몇 번 되풀이될 때 루프는 멈추고 사람을 불러야 합니다. 이 조건이 없는 루프는 밤새 같은 오류를 고치려다 아침에 비용 청구서만 남깁니다.

반복 사이를 잇는 기억

루프는 매 회차 맥락을 새로 시작하거나, 길어진 맥락을 압축합니다. 어느 쪽이든 앞 회차에서 알아낸 것은 대화 바깥에 적어 두지 않으면 사라집니다.

Ralph 는 할 일 목록과 AGENT.md 에, Osmani 는 마크다운 파일이나 이슈 보드에 둡니다. 형식보다 중요한 것은 두 가지입니다. 루프가 매 회차 시작할 때 반드시 그 기억을 먼저 읽게 하는 것, 그리고 무엇을 고칠 수 있는지 좁혀 두는 것입니다. 할 일 목록을 에이전트가 마음대로 지울 수 있으면, 남은 일을 지워서 일을 끝내는 루프가 나옵니다.

루프가 비싸지는 순간

루프는 사람 대신 프롬프트를 쓰니 사람이 지치지 않습니다. 대신 돈과 이해가 닳습니다.

돈은 단순합니다. 오래 도는 루프와 서브에이전트는 토큰을 많이 씁니다. Osmani 도 토큰 비용을 「정말 조심해야 한다」고 적었습니다. 시간 간격 루프는 할 일이 없어도 깨어나 맥락을 읽으니, 간격을 짧게 잡을수록 빈 회차의 비용이 쌓입니다.

이해가 닳는 쪽이 더 무섭습니다. Osmani 는 이해 부채(comprehension debt)를 경고합니다. 루프가 만든 코드를 아무도 읽지 않으면, 코드는 늘어나는데 그 코드를 이해하는 사람은 줄어듭니다. 그는 루프 설계가 판단과 함께 쓰면 처방이지만, 생각하기 싫어서 쓰면 가속제가 된다고 씁니다. 글의 마지막 문장이 이 글의 결론과 같습니다. 「루프를 만들되, 엔지니어로 남으라.」

ReAct 에서 달라진 것과 같은 것

루프라는 생각 자체는 새롭지 않습니다. 2022년 Shunyu Yao 등의 ReAct 논문은 언어 모델이 추론과 행동을 번갈아 내놓게 하는 방식을 제안했고, 지금 에이전트들의 생각, 행동, 관찰 반복이 여기서 왔습니다. 그래서 루프 엔지니어링을 ReAct 의 새 이름으로 보는 사람도 있습니다.

저는 층이 다르다고 봅니다. ReAct 의 루프는 에이전트 한 번의 실행 안쪽, 한 작업을 푸는 동안의 반복입니다. 루프 엔지니어링이 다루는 것은 그 바깥, 에이전트를 언제 깨우고 무엇을 맡기고 어떤 조건에서 재우는지입니다. 안쪽 루프는 모델과 하네스가 이미 꽤 잘 돌립니다. 사람이 설계할 몫이 남은 곳은 바깥쪽입니다.

용어보다 오래 남을 질문

루프 엔지니어링은 생긴 지 몇 달 된 말이고, 정의가 아직 굳지 않았습니다. 관련 글 상당수가 도구를 파는 쪽에서 나왔고, 이름을 붙인 Osmani 도 글의 소개란에 Anthropic 에서 Claude Code 일을 한다고 밝히고 있습니다. 용어가 얼마나 오래갈지는 저도 모르겠습니다.

다만 이름과 상관없이 남을 질문은 분명합니다. 무엇을 보고 다음 일을 고르는가, 결과를 무엇으로 확인하는가, 언제 멈추고 언제 사람을 부르는가. 루프를 하나 만들기 전에 이 세 줄을 먼저 적어 보는 것을 권합니다. 세 번째 줄이 비어 있다면 아직 루프를 돌릴 때가 아닙니다.

참고: Loop Engineering · Ralph Wiggum as a "software engineer" · Claude Code 예약 작업 문서 · ReAct: Synergizing Reasoning and Acting in Language Models