루프 엔지니어링의 구성 요소와 운영 제약

이번에 공개된 루프 엔지니어링의 핵심은 에이전트가 '행동 → 결과 테스트 → 접근 방식 수정'의 피드백 사이클을 자율적으로 반복하게 만드는 것이다. Claude Code는 이를 위해 목적과 실행 방식에 따라 세 가지 도구를 구분해 제공한다. 특정 작업이 증명 가능한 완료 상태에 도달할 때까지 반복하는 `/goal`, cron처럼 일정 주기마다 동일한 프롬프트를 실행하는 `/loop`, 그리고 로컬 컴퓨터의 전원 상태와 무관하게 클라우드에서 지속 실행되는 `/schedule`이 그 대상이다.

`/loop` 기능을 사용할 때는 세션 범위(session-scoped)라는 운영 제약을 고려해야 한다. 새 대화를 시작하면 기존 루프는 중단되며, `--resume`이나 `--continue` 명령어로 기존 세션을 재개해야만 다시 활성화된다. 또한 생성 후 7일이 지나면 루프가 만료된다. 구체적인 실행 예시로는 `/loop 5m check my PR, address review comments, and fix failing CI`와 같이 실행 간격과 수행 작업을 명시하는 방식을 사용한다.

자율적 피드백 사이클과 검증 메커니즘

목표 기반 루프인 `/goal`의 작동 방식은 생성 모델과 별도의 evaluator(평가자) 모델을 분리하는 구조에 있다. 에이전트가 작업을 수행하고 종료를 시도할 때마다 evaluator 모델이 사용자가 정의한 명시적 규칙의 충족 여부만 검사한다. 이때 evaluator는 코드의 미적 품질이나 디자인의 적절성을 판단하는 '심사자'가 아니라, 설정된 제약 조건의 준수 여부를 확인하는 '검증기'로 작동한다.

검증의 효율성은 결정론적 기준의 유무에 따라 갈린다. 'Lighthouse 성능 점수 92 이상', 'LCP 1.8초 미만', '테스트 통과 개수'와 같이 수치로 측정 가능한 지표는 루프 엔지니어링에 적합하다. 반면 'UI가 좋아질 때까지'와 같은 주관적 취향이나 인간의 판단이 필요한 영역은 evaluator가 처리할 수 없어 루프에 적합하지 않다. 특히 작업 수행 에이전트와 검증 에이전트를 분리함으로써, 수행 에이전트가 자신의 결과물에 대해 갖는 과잉 확신(confirmation bias)을 방지하고 모바일 성능 등 놓치기 쉬운 조건을 별도로 체크하게 한다.

이러한 메커니즘은 `/loop`와 `/goal`의 결합으로 확장된다. `/loop`가 일정 주기마다 버그 라벨이 붙은 이슈를 탐색해 문제를 발견하면, `/goal`이 로컬 테스트를 모두 통과할 때까지 수정을 반복하고 브랜치를 푸시하는 파이프라인 구성이 가능하다.

작업 위임 범위와 실무 적용 기준

실제 적용 사례에서는 규칙이 명확한 단순 반복 업무부터 자동화 대상이 된다. 80,000개 이상의 스타를 보유한 Agent Skills 저장소의 경우, 매시간 새 이슈를 확인해 긴급도를 요약하거나, 프로젝트 가이드라인에 어긋나는 번역 PR을 자동으로 닫는 작업에 루프를 활용해 관리 비용을 낮췄다. 또한 개발 서버 실행, 브라우저 요소 조작, 콘솔 오류 확인, Chrome DevTools MCP를 통한 Core Web Vitals 감사 등의 절차를 '스킬'로 명문화해 검증 과정 자체를 자동화 루프에 포함시켰다.

다만 작업(task)의 위임이 판단(judgment)의 위임으로 이어져서는 안 된다. 에이전트가 경쟁 제품 조사부터 로컬 PR 생성까지의 구현 작업은 수행할 수 있지만, 그 결과가 사용자 경험에 추가적인 복잡성을 만드는지, 혹은 실제 비즈니스 가치가 있는지는 사람이 최종 결정해야 한다. 특히 시스템 접근 권한이 필요하거나 인증, 보안, 금융과 관련된 민감한 로직은 에이전트의 검증 결과와 상관없이 사람이 직접 코드를 면밀히 검토해야 한다.

개발자와 실무자는 매일 아침 수동으로 확인하는 PR 더미나 CI 상태 체크 같은 단순 반복 작업부터 `/loop`로 전환하되, 보안 및 금융 관련 핵심 로직의 최종 승인 단계에서는 에이전트의 자율성을 완전히 배제하고 수동 검토 프로세스를 유지해야 한다.