실전 루프 엔지니어링

저는 보통 다섯에서 열 개 정도의 에이전트를 동시에 병렬로 돌립니다. 종료 조건과 제약 사항을 명확히 정의해 두었다면 에이전트에게 완전히 맡겨도 되는 작업이 있는 반면, 에이전트가 하는 작업을 더 가까이 지켜보면서 코드를 직접 리뷰해야 하는 작업도 있습니다.

이쯤에서 루프 엔지니어링(loop engineering)에 대해 들어본 분들도 있을 겁니다. 몇 달 전 이 주제로 긴 블로그 글을 쓴 적이 있습니다.

루프란 AI 에이전트가 특정 목표를 달성할 때까지 반복적으로 행동하고, 결과를 검증하고, 접근 방식을 수정하는 자율적이고 자기 교정적인 피드백 사이클이다

이제 핵심 프리미티브는 크게 두 가지입니다. Claude Code에는 goal 프리미티브가 있습니다. 측정 가능한 완료 기준이 충족될 때까지 단일 범위의 작업을 진행시키는 역할을 합니다. 그리고 loop은 타이머나 고정 주기로 반복 실행되므로, 변경 사항을 일종의 스케줄로 관리하는 데 활용할 수 있습니다.

프리미티브가 생기기 전에는

Claude Code와 Codex에 프리미티브가 내장되기 전에는 루프 엔지니어링이 대부분 bash 루프를 직접 작성하는 방식이었습니다. 저도 그렇게 했고요. 기억하시는 분도 있겠지만, 올해 초에는 Geoff Huntley가 만든 Ralph 루프를 가지고 여럿이 함께 실험해 보기도 했습니다. 어떤 방식이 잘 되고 어떤 건 안 되는지 서로 워크플로를 공유하며 탐색했는데, 대부분 개인 프로젝트에서 시도했기 때문에 막히더라도 크게 잃을 게 없었습니다.

루프 엔지니어링에서 어떤 패턴이 실제로 안정적으로 자리잡았는지 확인해 오면서, 이제는 이를 어떻게 감독해야 하는지 훨씬 명확해졌습니다. Claude Code와 Codex의 프리미티브 결과물도 이제는 상당 부분 믿고 쓸 수 있습니다. 분명 많이 발전했죠. 그러나 동시에 굉장히 신중해야 합니다. 목표나 제약 조건을 제대로 정의하지 않은 채 루프를 그냥 혼자 돌아가게 두면 문제가 생길 수 있습니다. 사용자도 없고 역사적 복잡성도 적은 새 코드베이스에 쓸 때와, 레거시가 잔뜩 쌓인 은행 코드베이스처럼 기존 시스템에 적용할 때는 접근 방식에 분명한 차이가 있어야 하는 이유가 바로 이것입니다.

Claude Code 팀이 루프를 바라보는 방식

Claude Code 팀은 네 가지 루프 유형에 대한 견해를 공개했는데, 제가 프리미티브를 사용하는 방식과도 잘 맞아떨어집니다(팀의 원문). 본론에 앞서 제가 간략히 정리해 드리겠습니다.

Claude Code 팀에서는 루프를 "종료 조건이 충족될 때까지 에이전트가 작업 사이클을 반복하는 것"으로 정의합니다. 루프는 트리거 방식, 종료 방식, 사용하는 Claude Code 프리미티브, 각 유형에 적합한 작업의 종류에 따라 분류됩니다. 모든 작업에 복잡한 루프가 필요한 것은 아닙니다. 가장 단순한 해결책에서 출발하여 필요한 경우에만 이 패턴을 선택적으로 활용하세요.

프롬프트를 보낼 때마다 여러분이 직접 매 턴을 이끄는 수동 루프가 시작됩니다. Claude는 컨텍스트를 수집하고, 행동을 취하고, 결과를 확인하고, 필요하면 반복한 뒤 응답합니다. 이것이 바로 에이전트 루프입니다. 예를 들어 '좋아요 버튼을 만들어 달라'고 요청하면, Claude는 코드를 읽고, 수정하고, 테스트를 실행한 뒤 제대로 작동한다고 판단되는 결과물을 돌려줍니다. 이후 여러분이 직접 결과물을 확인하고 다음 프롬프트를 작성합니다.

각 단계에 대한 자세한 내용은 팀의 원문에서 확인할 수 있습니다.

목표 기반 루프에 대해:

특히 복잡한 작업의 경우, 단일 턴으로는 충분하지 않을 때가 많습니다. 에이전트는 반복할 수 있을 때 더 좋은 결과를 냅니다. /goal로 완료 기준을 정의하면 Claude가 반복을 지속하는 시간을 늘릴 수 있습니다. 성공 기준을 명시해 두면 Claude가 스스로 "이 정도면 충분하다"고 판단해 루프를 조기에 종료하는 일이 없어집니다. Claude가 멈추려 할 때마다 평가자 모델이 조건을 확인하고, 목표가 충족되거나 정해진 턴 수에 도달할 때까지 다시 작업으로 돌려보냅니다. 테스트 통과 수나 특정 점수 임계값 초과 같은 결정론적 기준이 효과적인 이유가 바로 이것입니다. 예시: /goal 홈페이지 Lighthouse 점수를 90 이상으로 올리기, 최대 5회 시도.

시간 기반 루프에 대해:

일부 에이전트 작업은 반복적 성격을 띱니다. 작업 자체는 동일하고 입력값만 바뀌는 경우가 그렇습니다. 예를 들어 매일 아침 Slack 메시지를 요약하는 작업이 여기에 해당합니다. 또한 외부 시스템에 의존하는 작업도 있는데, 이 경우 일정 주기로 상태를 확인하고 변경 사항에 반응하는 방식이 간단하고 효과적입니다. 코드 리뷰를 받거나 CI가 실패할 수 있는 PR이 그 예입니다. 이런 경우에는 /loop를 사용해 프롬프트를 일정 주기로 반복 실행할 수 있습니다. 예시: /loop 5m PR을 확인하고, 리뷰 코멘트를 반영하고, 실패한 CI를 수정하기. /loop는 로컬 컴퓨터에서 실행되므로 컴퓨터를 끄면 루프도 멈춥니다. /schedule로 루틴을 생성하면 루프를 클라우드로 옮길 수 있습니다.

그리고 가장 높은 단계인 능동적 루프에 대해:

트리거: 이벤트 또는 스케줄, 실시간 사람 개입 없음. 종료 조건: 각 작업은 목표 달성 시 종료. 루틴 자체는 명시적으로 끄기 전까지 계속 실행. 적합한 작업: 버그 리포트, 이슈 분류, 마이그레이션, 의존성 업그레이드 등 정형화된 반복 작업 스트림. 사용량 관리: 루틴은 소형·고속 모델로 처리하고, 판단이 필요한 상황에서만 가장 성능 높은 모델을 활용.

팀의 검증 관련 조언은 그대로 인용할 만한 가치가 있습니다. 사람이 수동으로 하던 확인 작업을 Claude 스스로 수행하도록 전환하는 내용이기 때문입니다.

---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone.
Verify it the way a human reviewer would:
1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button, input,
   toggle): click it, confirm the expected state change, and screenshot
   before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit
   Core Web Vitals.
If any step fails, fix the issue and rerun from step 1 - do not hand
back partially verified work.

Goal

저는 goal을 특정 작업이 완료됐음을 입증할 수 있을 때까지 계속 진행해야 하는 경우에 사용합니다. 예를 들어 "이 화면이 5초 안에 로드될 때까지 계속 진행해"처럼 지정하면, 완료 기준 충족 여부를 독립적인 평가 검사를 통해 계속 확인하는 방식으로 동작합니다. 사용하는 도구를 더 구체적으로 명시할수록 결과가 더 좋습니다.

실제로 제가 활용했던 goal의 예를 몇 가지 들면, GitHub 이슈 처리에 쓴 경우가 있습니다. "최근 이슈 10개를 검토하고 닫아줘" 혹은 "최근 이슈 10개를 검토하고 진행 상태를 업데이트해줘" 같은 식으로요. 다소 열린 형태의 목표이기도 합니다. 아니면 "이 페이지 로드 속도를 50% 빠르게 만들어줘"처럼 쓰기도 했는데, 잘 될 때도 있고 아닐 때도 있습니다. 결국 실험이 핵심입니다.

Loop

루프는 스케줄러에 가깝습니다. 무언가를 주기적으로 확인하거나, 일정 간격으로 반복 실행하는 패턴입니다. 크론(cron)과 비슷하게 생각하면 됩니다. 로그를 폴링하거나 외부 상태를 모니터링하는 용도로 가장 잘 맞고, 주기적으로 반복해서 하는 작업이 있다면 루프가 꽤 유용합니다.

맡기는 것과 직접 보는 것

저는 매일 보통 다섯 개에서 열 개 정도의 에이전트를 사용하며, 동시에 돌리는 건 대개 다섯 개 정도가 최대입니다. 그중 일부는 비교적 안전한 작업들입니다. 예를 들어 "이 기능 구현했으니 문서 작성해줘"라거나 "테스트 커버리지가 충분한지 확인해줘" 같은 식입니다. 반면 더 복잡한 문제를 다루거나, 제가 나름 괜찮은 스펙과 종료 조건을 줬다고 생각해도 완벽하게 처리하지 못할 가능성이 있는 작업이라면 좀 더 가까이 지켜봅니다. 특정 시스템 접근 권한을 부여한 경우, 인증이나 보안, 금융 관련 기능에 닿는 경우라면 반드시 면밀히 살펴봅니다.

전반적으로는 목표나 종료 조건이 충족됐는지 명확히 검증할 수 있는 방법이 갖춰진다면, 에이전트에게 더 많은 것을 맡기는 방향으로 흐름이 바뀔 것이라 봅니다. 다만 생성된 코드와 결과물이 기준을 충족하는지 직접 확인하는 과정은 여전히 필요합니다.

또 하나 중요한 습관이 있습니다. 작업을 수행한 에이전트가 스스로 작업 완료 여부를 판단하게 두지 않는 것입니다. 변경 사항은 하나의 서브 에이전트가 작성하고, 검증은 별도의 에이전트가 담당하게 해야 합니다.

에이전트가 특정 부분에 대해 자신 있게 판단한 경우에도, 검증 에이전트가 예상치 못한 문제를 잡아낼 때가 있습니다. 예를 들어 에이전트가 자신이 만든 화면의 성능이 기준 이상이라고 판단했더라도, 그게 데스크톱 기준으로만 평가된 것일 수 있습니다. 정작 중요한 건 모바일 경험이었는데도 말이죠. 즉, 에이전트가 문제의 한 차원에 대해서는 확신을 갖고 있어도, 다른 차원은 놓치고 있을 수 있습니다.

이건 저도 직접 겪으면서 배운 교훈입니다. 이슈 트래커나 댓글에서 직접적인 피드백을 받지 못한 부분 중 우리가 놓치고 있는 게 있는지 궁금했습니다. 그래서 에이전트에게 경쟁 서비스들을 살펴보고, 그 격차를 해소할 방법을 정리하고, 실제로 push는 하지 않은 로컬 PR을 몇 개 만들어보라고 했습니다. 그리고 그 변경 사항을 거의 push할 뻔했습니다. 에이전트가 정리한 리서치 내용은 읽었는데, 구현 내용은 충분히 꼼꼼하게 들여다보지 않았던 거죠. 작업은 위임했는데, 판단까지 위임할 뻔한 상황이었습니다. 나중에 실제로 변경 사항을 살펴보니, 그 내용이 사용자에게 상당한 복잡성을 추가하는 반면 실제 이득은 크지 않다는 걸 알게 됐습니다. 에이전트에게 취향이나 판단을 맡기지 않도록 스스로를 점검해야 한다고 느꼈습니다. 작업은 위임하되, 그 결과가 내 기준에 부합하는지는 반드시 직접 확인해야 합니다.

덧붙이자면, goal 뒤에서 동작하는 평가자 모델은 그런 검증을 수행하지 않습니다. 결과물의 내용이 좋고 나쁨을 판단하는 것이 아니라, 단지 대화 기록을 검토해 여러분이 지정한 규칙이 충족됐는지 여부만 확인합니다.

/goal Refactor the data-fetching layer in Dashboard.tsx until Lighthouse performance score is >= 92 and LCP is under 1.8s as shown by the Lighthouse CLI output. Do not change the public API of any hooks. Each turn must improve at least one reported metric; abort if two consecutive turns show no improvement. Stop after 10 turns.

매일 실행하는 워크플로

제가 매일 활용하는 워크플로가 있습니다. 저는 Agent Skills라는 인기 오픈 소스 저장소를 운영하고 있는데, 별이 8만 개가 넘고 한때는 하루에 PR이 80~90개까지 쏟아지기도 했습니다. 매일 시간을 들여 이걸 일일이 확인해야 했는데, 이제는 루프를 활용해 "24시간 또는 12시간마다 GitHub 저장소에서 새로 등록된 이슈를 확인하고 긴급도 요약 또는 1차 리뷰를 남겨줘" 같은 식으로 처리할 수 있습니다.

/loop every 1h "Check the GitHub repository for any new open issues. Provide a bulleted summary of their urgency."

루프와 goal 조합하기

루프와 goal을 함께 쓸 수도 있습니다. 루프로 주기적인 확인을 스케줄링하고, goal로 문제를 해결하는 방식입니다. 예를 들어 "24시간마다 GitHub에서 bug 라벨이 붙은 이슈를 확인하고, 이슈가 있으면 로컬 테스트가 모두 통과될 때까지 goal을 사용해 수정 후 브랜치를 push해"처럼 구성할 수 있습니다.

/loop every 24h "Check GitHub for issues labeled 'bug'. If one exists, use /goal to implement a fix until all local tests pass and push the branch."

다만 goal에 너무 많은 내용을 한꺼번에 넣으면 한계가 생길 수 있다는 점도 염두에 두세요.

팀의 원문에는 이 모든 것이 어디로 향하는지 보여주는 조합 예시도 담겨 있습니다.

위에서 소개한 프리미티브들과 자동 모드(auto mode), 동적 워크플로(dynamic workflow, 리서치 프리뷰) 같은 Claude Code 기능을 조합하면 장시간 실행되는 루프를 구성할 수 있습니다. 예를 들어 수신되는 피드백을 처리하려면 다음과 같이 구성할 수 있습니다: /schedule (리서치 프리뷰)로 새 리포트를 확인하는 루틴 실행, /goal로 완료 기준 정의, 검증 방법을 문서화하는 스킬 활용. 동적 워크플로로 각 리포트를 분류하고, 수정하고, 수정 내용을 검토하는 에이전트 오케스트레이션. 루틴이 허가를 구하지 않고 실행되도록 자동 모드 적용. 모두 합치면 이런 프롬프트가 됩니다: /schedule 매 시간: project-feedback 채널에서 버그 리포트를 확인한다. /goal: 이번 실행에서 발견된 모든 리포트가 분류, 조치, 응답 완료될 때까지 멈추지 않는다. 버그를 수정할 때는 워크플로를 사용해 병렬 worktree에서 세 가지 해결책을 탐색하고, 판사 에이전트가 이를 대립적으로 검토하도록 한다.

트리아지 시스템이 실제로 하는 일

루프와 goal이 함께 작동하는 PR 트리아지 시스템 덕분에, 매일 새롭게 올라오는 PR과 이슈를 놓치지 않고 처리할 수 있게 됐습니다. 특히 교차 참조가 가능해진 점이 큰 도움이 됐습니다. 시스템의 특정 부분을 재설계하는 작업을 진행 중이라면, 해당 부분과 관련된 이슈가 이번 재작업으로 자동으로 닫히는지, 혹은 다른 작업과 충돌하지는 않는지 조건을 명확히 정의해서 관리할 수 있습니다.

예약된 작업은 새로 올라온 PR을 정기적으로 검토하고, 명백히 맞지 않는 것들을 자동으로 닫는 데 특히 유용합니다. 좋은 종료 조건의 예를 들면, 저희는 기여 가이드라인을 별도로 두고 있는데 여기에는 "현재 번역 기여는 받지 않는다"는 내용이 포함돼 있습니다.

관심이 없어서가 아니라, 모든 언어를 다룰 수 있는 상황이 아니기 때문에 유지 관리가 어렵습니다. 그래서 해당 기여 가이드라인에 해당하는 이슈나 PR은 자동으로 닫도록 설정해 두면, 정기적인 스케줄 위에서 꽤 잘 작동합니다. 결과적으로 직접 검토해야 할 항목의 수가 줄어듭니다.

루프가 해결해 주지 못하는 것

루프 엔지니어링이 잘 맞지 않는 경우가 뭔지 자주 묻습니다. 일반적으로는 완료 상태나 "잘 됐다"는 기준이 명확하지 않으면 적합한 패턴이 아닙니다. 예를 들어 "이 UI 디자인이 좋아질 때까지 계속 진행해"는 너무 막연한 목표입니다. 누가 봤을 때 좋다는 건지, 어떻게 평가하는 건지 기준이 없으니까요. 사람의 감각과 취향, 주관적인 디자인 판단, 열린 형태의 창의적 탐색이 필요한 작업에는 맞지 않습니다. 반면 목표가 분명할 때는 루프가 충분히 고려할 만한 좋은 선택지입니다.

주의사항

루프가 제자리를 맴돌고 있다는 가장 전형적인 신호는, 같은 명령이 결과 변화 없이 계속 반복되는 것입니다. 두 번째 시도와 달라진 게 없는 채로 세 번째 시도가 나온다면, 그때는 루프를 멈출 시점입니다.

알아두면 좋은 세부 사항도 있습니다. 반복 루프는 생성 후 7일이 지나면 만료됩니다. 예전에 3일이라고 말하고 다닌 적이 있는데, 정확히는 7일입니다. 그리고 루프는 세션 범위로 동작하기 때문에 새 대화를 시작하면 멈춥니다. 다만 --resume 또는 --continue로 해당 세션을 재개하면, 7일 유효 기간이 남아 있는 반복 작업이 다시 살아납니다. 세션이 종료돼도 계속 실행되어야 한다면 /schedule로 클라우드에서 실행하면 됩니다.

매일 아침 손으로 직접 하는 점검 작업이 있다면, 그것이 바로 첫 번째 루프 후보입니다. 저한테는 쌓여가는 PR 더미가 그 첫 번째였습니다.

이 글은 제 Substack에 처음 게재한 글입니다.