세 에이전트에서의 루프 엔지니어링: yetone의 Magpie 워크플로가 말해주는 Claude Opus 5.5 무인 운영법

yetone의 설정에서 가장 흥미로운 점은 모델이 아니다. 바로 숫자 3이다. 코딩 에이전트가 원하는 모델을 무엇으로 지정하든 그 모델에 맞춰 실행할 수 있게 해주는 로컬 게이트웨이 Magpie의 메인테이너는 2026-10-13 X에서 자신의 유지보수 워크플로를 설명했다: A​nthropic의 Claude Opus 5.5가 구동하는 Claude Code로, 동시에 세 개의 /loop 작업을 돌리며, 각 작업은 서로 다른 표면 — GitHub 이슈와 풀 리퀘스트, Discord 커뮤니티, X로 들어오는 피드백 — 을 지켜보고 발견한 것을 고친다. 턴 단위로 프롬프트를 넣는 대신 에이전트를 계속 순환시키는 관행인 루프 엔지니어링은 올해 많은 화제가 되었다. 이 사례를 읽을 가치가 있게 만드는 것은 여기에 조직도가 딸려 온다는 점이다.

Claude Opus 5.5는 새로운 것이 아니다. Anthropic은 3주 전인 2026-09-22에 이를 출시했으며, 가격은 입력 토큰 100만 개당 $4, 출력 토큰 100만 개당 $20이다. 이것은 출시 이야기가 아니다. 이것은 3개 에이전트 유지보수 루프를 따라 하려는 사람에게 모델의 기본값이 무엇을 의미하는지, 그리고 그 루프의 어느 부분이 튜토리얼에서 언급하지 않는 방식으로 깨지는지에 관한 이야기다.

워크플로우 안에 실제로 무엇이 있나요

신호는 짧다. 그래서 무엇이 주장되고 무엇은 주장되지 않는지 정확히 짚고 넘어갈 가치가 있다. yetone은 Claude Code에서 Opus 5.5로 세 개의 동시 /loop 작업을 실행한다. 하나는 저장소를 지켜본다 — 이슈와 풀 리퀘스트를. 하나는 Discord를 지켜본다. 하나는 X를 지켜본다. 에이전트는 고칠 가치가 있다고 판단한 것을, 루프 안에서, 사람이 매 턴 지시하지 않고도 고친다. 그가 자동화한 패턴은 대부분의 메인테이너가 서투르게 처리하는 바로 그것이다: 트리아지. 코딩이 아니다. 하루에 한 시간을 잡아먹는 읽기, 분류, 중복 제거, 응답하기다.

루프 엔지니어링이라는 표현은 여기서 결정적이다. 루프는 작업을 수행하는 에이전트가 아니다. 루프는 자신이 선택한 일정에 따라 어떤 작업으로 계속 되돌아오는 세션이며, 직전 반복의 상태가 여전히 그 앞에 놓여 있는 세션이다. 그 차이가 바로 대부분의 자체 제작 버전이 무너지는 지점이고, 지난 6주 동안 툴링이 움직여 온 바로 그 지점이다.

Claude Code의 /loop가 2026년 10월에 실제로 하는 일

현재 문서를 읽지 않았다면, 기억하고 있는 버전은 아마 틀렸을 것입니다. 왜냐하면 /loop가 루프 엔지니어링이 유행하던 시기에 형태를 바꾸었기 때문입니다.

이제 그냥 /loop는 더 이상 간격을 지정하도록 요구하지 않습니다. 생략하면 Claude가 이전 반복에서 관찰한 내용을 바탕으로 1분에서 1시간 사이의 값을 동적으로 선택합니다. 빌드가 마무리 중이거나 풀 리퀘스트가 진행 중일 때는 잠깐 기다리고, 대기 중인 작업이 없을 때는 훨씬 오래 기다립니다. 선택된 지연 시간과 그 이유는 각 반복이 끝날 때 출력되므로, 루프가 자신의 주기를 어떻게 판단하는지 확인할 수 있습니다. 대신 간격을 지정하면 — /loop 5m check the deploy — 고정된 cron 일정을 얻게 됩니다.

프롬프트도 생략하면, 매 반복마다 세 가지를 순서대로 처리하는 내장 유지보수 프롬프트를 얻게 됩니다:

• 대화에서 완료되지 않은 작업이 있으면 계속 진행하세요.

• 현재 브랜치의 풀 리퀘스트를 처리하세요 — 리뷰 코멘트, 실패한 CI 실행, 병합 충돌.

• 다른 대기 중인 작업이 없을 때는 버그 사냥이나 단순화 같은 정리 작업을 수행하세요.

그 기본값을 자신만의 지침으로 바꾸려면 loop.md를 작성하면 됩니다. .claude/loop.md는 프로젝트용이고, ~/.claude/loop.md는 자체 파일을 정의하지 않는 모든 프로젝트용입니다. 편집은 다음 반복에서 적용되므로, 실행 중인 루프의 지침을 다시 시작하지 않고도 다듬을 수 있습니다. 파일은 25,000바이트를 초과하면 잘리며, 이는 분류 규칙을 담기에 충분히 넉넉한 공간입니다.

그 메커니즘은 3중 루프 설정에서 핵심을 지탱하는 부분이며, 워크플로 다이어그램이 보통 빠뜨리는 바로 그 부분입니다. 일반적인 내장 유지보수 프롬프트는 트리아지 정책이 아닙니다. 프로젝트가 GitHub 이슈를 읽는 방식대로 루프가 GitHub 이슈를 읽게 하려면 — 무엇이 중복으로 간주되는지, 무엇이 답글 대신 레이블을 받는지, 무엇이 결코 답글을 받지 않는지 — 정책은 다음 위치에 있어야 합니다: loop.md, 세션을 시작할 때 입력한 프롬프트가 아니라.

셋이 숫자인지 슬로건인지를 결정하는 한계

세 개의 동시 루프부터는 제약이 슬슬 발목을 잡기 시작하는 지점이라, 누군가의 설정을 그대로 따라 하기 전에 이 제약들을 한번 나열해 볼 만하다.

• 동시성 상한 — 한 세션은 한 번에 최대 50개의 예약된 작업을 유지할 수 있으므로, 세 개의 루프는 한도에 훨씬 못 미칩니다. 실제로 제약이 되는 것은 작업 수가 아니라 주의력입니다. 세 개의 루프란 같은 세션을 두고 경쟁하는 세 갈래의 도구 호출 스트림을 뜻합니다.

• 만료 — 반복 작업은 생성된 지 7일 후 스스로 삭제되며, 삭제되는 순간 한 번 더 실행됩니다. 8일차에 조용히 멈춰 버린 유지보수 루프가 단연 가장 흔한 실패 모드이며, 이는 소리 없이 실패합니다.

• 비대칭 복원 — 세션을 재개하세요. --resume 또는 --continue를 사용하면 cron 예약 작업이 돌아옵니다. 단, 만료된 반복 작업은 제외됩니다. 자율 진행 루프는 전혀 복원되지 않으며, 다시 시작해야 합니다.

• 바쁜 세션 동작 — 작업은 턴 사이에 발동되며, 응답 도중에는 절대 발동되지 않습니다. 루프가 도래했을 때 긴 에이전트 턴이 실행 중이라면 발동은 대기합니다. 놓친 간격은 쌓이지 않고 하나의 발동으로 합쳐집니다.

• 지터 — 반복 작업은 의도적으로 늦게 실행됩니다. 다음 실행까지의 간격의 최대 절반, 최대 30분까지 지연되어, 여러 세션이 같은 초에 몰리지 않습니다. 10분마다 실행되는 작업은 정시부터 5분 지연 사이 어디에서나 시작합니다. 5분 지연인 경우는 예외입니다: Claude Code는 각 실행을 프롬프트 캐시 창 안에 유지하기 위해 15초 일찍 이동시킵니다.

• 컴퓨터 켜짐 필수 — 루프는 Claude Code가 실행 중이고 유휴 상태일 때만 작동합니다. 노트북을 닫으면 중단됩니다. 자리를 비운 시간 동안 밀린 작업을 따라잡아 주지 않습니다.

마지막 것이 이 워크플로가 플랫폼 팀의 셋업이 아니라 메인테이너의 셋업인 이유다. 한 머신에서, 한 세션 안에서 루프 세 개를 돌리는 것은 다른 일을 하면서 바쁜 오픈소스 프로젝트를 계속 돌아가게 하는 방법이다; 그것은 서비스가 아니다.

왜 이 워크플로가 단지 '에이전트'가 아니라 Claude Opus 5.5에 특화되어 있는가

큰 컨텍스트 윈도가 없는 모델을 상대로 세 에이전트 루프를 돌리면, 루프는 하루 종일 같은 내용을 다시 읽는 데 시간을 쓴다. 각 반복마다 이슈 스레드, PR diff, Discord 기록을 다시 집어넣는다. 윈도가 작으면 그 기록은 요약되어 사라지고, 세션이 길어질수록 루프의 판단은 조용히 나빠진다. Claude Opus 5.5는 128K 토큰의 출력과 함께 1M 토큰 컨텍스트 윈도를 갖추고 있어, 트리아지 루프가 실제 이슈 백로그와 대화, 그리고 최근 몇 번의 반복을 한 번에 유지할 수 있게 해준다. 또한 백만 토큰당 $4 / $20로 책정되어 있고, 캐시 읽기는 백만 토큰당 $0.20 — 입력 가격의 5분의 1 — 인데, 이는 여기서 평소보다 더 중요하다. 루프는 존재하는 워크로드 중 가장 캐시 친화적인 워크로드이기 때문이다. 같은 시스템 프롬프트, 같은 도구 정의, 같은 저장소 컨텍스트가 계속 반복된다.

두 번째 맞춤은 사고 기본값이고, 각 루프가 무엇을 하는지에 따라 정반대로 작용합니다. Claude Opus 5.5는 적응형 사고를 항상 켜 놓고 실행하며, 노력은 기본적으로 중간으로 설정됩니다 — Claude Opus 5의 기본값보다 한 단계 낮습니다. 노력은 품질만 바꾸는 것이 아니라 도구 호출량도 바꿉니다. 이슈를 분류하는 루프와 코드를 편집하는 루프는 서로 다른 설정을 원하며, 가장 낮은 노력 설정은 그 자체로 스케줄링 문제이기도 합니다. 스스로 속도를 정하는 루프에서는 모델이 다음 깨어날 지연 시간을 스스로 선택하므로, 낮은 노력의 분류 루프와 높은 노력의 수정 루프는 같은 저장소에 대해 서로 다르게 속도를 맞춥니다. 둘을 일치시키는 설정은 없습니다. 핵심은 어느 쪽이 어느 쪽인지 아는 것이며, 속도 차이가 가장 먼저 보게 될 것이기 때문입니다.

루프와 fixer를 서로 다른 벤더의 모델에 대해 실행하고 싶다면 — 트리아지는 저렴한 것으로, 수정은 Claude Opus 5.5로 — 그것은 Claude Code의 결정이 아니라 라우팅 결정이며, 세션 앞에 게이트웨이가 놓이는 이유입니다.

프로덕션을 걸지 않고 이걸 시도해 보는 중

세 개의 루프 구성에 대한 합리적인 반대 의견은 첫날 오후에 자율 에이전트를 사용자 이슈 앞에 배치한다는 점입니다. 루프는 댓글을 달 것입니다. 이슈를 닫을 것입니다. 이를 도입하는 정직한 방법은 일주일 동안 읽기 전용 GitHub 토큰을 사용해 하나의 루프를 드라이런 모드로 실행하여 그 트리아지 판단이 직접 내린 판단과 일치하는지 확인하는 것입니다 — 그리고 별도로, 도입을 확정하기 전에 모델 자체를 측정할 수 있는 곳으로 라우팅하는 것입니다.

OrcaRouter에서는 anthropic/claude-opus-5.5가 Anthropic의 정가 그대로, 마크업 없이 제공됩니다. OpenAI 호환 형식과 Anthropic Messages 형식을 모두 구사하는 단일 엔드포인트에서 제공되므로, Claude Code 세션과 같은 모델에 요청을 보내는 스크립트가 두 개의 통합을 따로 가질 필요가 없습니다. Anthropic은 2026-09-22에 자체 $4 / $20 가격을 발표했습니다. 그 정가가 움직이면 패스스루 게이트웨이도 다음 결제 주기가 아니라 같은 날 함께 움직입니다. 몇 달 동안 돌아갈 수도 있는 루프의 규모를 산정할 때 원하는 게 바로 이 버전입니다. 제공자 간 자동 페일오버는 문서가 경고하지만 아무도 테스트하지 않는 상황을 커버합니다. 새벽 3시에 업스트림 하나가 429를 반환했다고 해서 루프가 멈추지는 않습니다. 모델 퓨전과 라우팅 DSL은 여기서는 덜 중요합니다. 트리아지 루프는 하나의 모델을 일관되게 원하기 때문입니다. 일관성이 있어야 그 판단을 검토할 수 있으니까요.

숫자 3을 어떻게 할까

루프 엔지니어링의 평판 문제는 올해 시연된 것의 대부분이 데모에서 하나의 좁은 작업을 실행하는 하나의 루프였다는 점입니다. yetone의 설정은 흥미로운데, 이는 세 가지 서로 다른 입력 — 저장소, 채팅 커뮤니티, 공개 타임라인 — 을 대상으로 하는 세 개의 루프이기 때문이며, 이는 유지 관리자가 시간을 낼 수 없는 실제 작업의 형태입니다. 또한 이는 위에서 언급한 모든 제약 — 만료, 지터, 복원, 페이싱, 그리고 루프가 기계가 켜져 있는 동안에만 실행된다는 사실 — 을 드러내는 형태이기도 합니다.

전이 가능한 부분은 개수가 아니다. 각 루프가 고유한 표면, loop.md에 있는 고유한 정책, 그리고 고유한 깨어날 이유를 가졌다는 점이다 — 그리고 그것을 운영하는 사람이 반복 로그를 통해 각 루프가 왜 그 지연을 선택했는지 알 수 있었다는 점이다. 그건 일주일 후에 실제로 감사할 수 있는 설정이다. 이 루프들이 모두 8일째에 만료된다는 점을 고려하면, 그것이 다시 만들지 여부를 결정할 수 있는 대략적인 시간이다.

분명히 말해 두자면, 이것은 한 실무자가 X에서 직접 설명한 자신의 설정이며, 벤더가 권장한 지침이 아닙니다. A​nthropic의 Claude Opus 5.5 및 Claude Code의 /loop 문서는 그 도구들이 무엇을 하는지 알려줍니다. 하지만 세 개가 적절한 숫자라고 알려주지는 않으며, 아직 다른 누구도 그렇게 말하지 않습니다.

트리아지 루프와 수정 루프가 서로 다른 모델을 원할 때: 루프와 픽서를 하나의 엔드포인트를 통해 실행하세요 단일 엔드포인트에서 Claude Opus 5.5를 Anthropic의 정가로 제공하며 OpenAI 호환 및 Anthropic Messages 형식을 모두 지원합니다.

이와 같은 모델 선택은 또한 실패 모드가 드러나는 지점이기도 합니다: 이 부류의 모델에서 발생한 문서화된 AI 사고와 에이전트 실패가 수집되는 곳은 OrcaRouter AI Incident Archive이며, 각 항목은 자체 출처, 심각도, 신뢰도 등급 및 이의 제기 플래그를 포함합니다.