루프 엔지니어링 완벽 정리 — 클로드 코드 자율 코딩 에이전트의 장단점과 해결책

핵심 메시지

• 오픈클로(OpenClaw)의 피터 스타인버거, 클로드 코드의 보리스 처니 같은 인물들은 이제 에이전트에 일일이 프롬프트하지 않고 '반복문(루프)'을 설계해 코딩 에이전트가 스스로 일하게 한다.
• 클로드 코드와 코덱스의 /loop, /goal, /routine 기능이 루프 엔지니어링의 기본 재료이며, 오케스트레이터가 작업을 잘게 나눠 워커에게 맡기는 구조다.
• 루프 엔지니어링은 강력하지만 토큰 소모가 극심하고(간단한 앱에도 100만 토큰 이상), 한 세션이 계속 이어지면 컨텍스트가 부풀어 신뢰성이 떨어진다.
• 발표자는 아르콘(Arkon) 하네스로 단계마다 별도 세션을 돌리고, 단계별로 다른 모델·공급자를 섞어 비용을 낮추며, 상태를 외부 데이터베이스에 저장해 내구성을 확보한다.
• 사람이 개입할 지점(휴먼 인 더 루프)과 관찰 가능한 대시보드가 있어야 자율 루프가 무너지지 않고 실제 업무에 쓸 수 있다.

쉽게 이해하기

'루프 엔지니어링'은 최근 AI 코딩 커뮤니티에서 떠오른 유행어다. 핵심은 코딩 에이전트에게 매번 지시를 내리는 대신, 에이전트가 반복적으로 스스로 깨어나 작업을 처리하는 루프를 설계하는 것이다. 클로드 코드의 /loop는 예컨대 5분마다 깨어나 지정된 저장소의 새 깃허브 이슈를 확인하고 처리하도록 설정할 수 있고, /goal은 완료 기준을 정해두고 끝날 때까지 계속 돌리며, /routine은 예약된 작업을 수행한다. 발표자는 이를 두고 굳이 별도 용어로 부를 만큼 복잡한 개념은 아니라고 선을 긋는다.

동작 방식은 오케스트레이터-워커 구조다. 사용자가 개략적인 사양만 넘기면 메인 오케스트레이터 에이전트가 스스로 루프를 세팅하고, 매 주기마다 확인되지 않은 작업 하나를 수행·검증한 뒤 다음 반복으로 넘어간다. 발표자는 클로드 코드에 루프 스킬을 불러오라고 지시하는 것만으로 계획 문서를 한 작업씩 순회하는 시스템이 자동으로 구성되는 과정을 시연한다.

그러나 세 가지 단점이 분명하다. 첫째, 이것이 최선의 결과를 낸다고 보긴 어렵다. 둘째, 비용이 매우 크다. 오케스트레이터가 워커 수와 반복 횟수를 계산하고 컨텍스트를 계속 주고받기 때문에 단 한 번 실행에 100만 토큰을 넘기기도 한다. 셋째, 많은 설정이 실제로는 동일한 세션 안에서만 반복되어 LLM 컨텍스트가 부풀고, 하루 방치하면 결과가 엉망이 되는 경우가 잦다.

발표자의 해법은 아르콘이라는 하네스다. 계획→구현→검토처럼 각 단계를 독립된 코딩 에이전트 세션에서 돌리고 마크다운 문서로 작업을 인계한다. 노드마다 모델을 직접 고를 수 있어 분류에는 하이쿠나 키미 K2 같은 작은 모델을, 구현에는 클로드 코드를, 검토에는 코덱스를 쓰는 식으로 비용을 최적화한다. 모든 로그와 상태는 Neon(PostgreSQL)에 저장해 컴퓨터가 꺼져도 중단 지점부터 재개할 수 있고, 워크트리로 병렬 세션이 서로 충돌하지 않게 격리한다.

마지막으로 그는 순수한 형태의 루프 엔지니어링을 위해 오픈소스 대시보드를 직접 만들었다. 라즈베리 파이에서 키미 K2로 워크플로를 돌리고, 상태를 외부 DB에서 관리하며, 어떤 결정이 내려지는지 관찰할 수 있게 했다. 이 대시보드는 Retool로 손쉽게 배포해 팀과 공유하거나 승인·재개 같은 휴먼 인 더 루프 제어를 붙일 수 있다.

주요 인사이트

• '에이전트에 프롬프트하지 않는다'는 말은 프롬프트를 없앤다는 뜻이 아니라, 사람이 매번 개입하는 대신 반복 구조 자체를 설계한다는 의미다.
• 자율성이 높아질수록 비용과 신뢰성이 최대 병목이 되며, 무제한 예산이 없다면 루프는 신중하게 통제해야 한다.
• 단계마다 별도 세션과 서로 다른 모델을 배치하면, 추론이 꼭 필요한 순간에만 비싼 모델을 써서 비용을 크게 줄일 수 있다.
• 상태를 외부 데이터베이스에 저장하는 '내구성' 설계가 있어야 장시간 작업을 중단·재개할 수 있다.
• 관찰 가능한 대시보드와 사람이 끼어들 지점이 없으면 자율 루프는 데모 수준을 넘기 어렵다.

자주 묻는 질문

관련 AI 소식