AI 에이전트에게 일을 맡길 때, 자율성보다 중요한 것은 멈추는 조건이다

구글 크롬 팀 출신 개발자 애디 오스마니(Addy Osmani)가 8월 14일 자신의 뉴스레터 엘리베이트(Elevate)에 "실전 루프 엔지니어링(Practical Loop Engineering)"이라는 글을 올렸다. 그는 매일 5개에서 10개 사이의 에이전트를 동시에 돌리고, 보통 다섯 개 안팎에서 손을 멈춘다고 적었다. 이 정도 규모로 위임이 가능해진 이유를 그는 "완전히 맡길 작업일수록 멈추는 조건과 제약을 미리 분명히 정해 뒀기 때문"이라고 설명한다.

완전 위임 가능한 작업과 계속 지켜봐야 할 작업을 가르는 기준을 보여주는 표지 이미지 — 위임 기준: 문서 작성은 맡기고, 인증·보안·금전은 계속 지켜본다.

클로드 코드가 정의한 네 가지 루프

오스마니가 인용한 클로드 코드(Claude Code) 팀의 공식 설명에 따르면, 루프란 "에이전트가 멈춤 조건이 충족될 때까지 작업 주기를 반복하는 것"이다. 이 팀은 루프를 트리거 방식, 정지 기준, 사용하는 프리미티브, 적합한 작업 유형에 따라 네 갈래로 나눈다. 턴 기반 루프는 사용자 프롬프트로 시작해 클로드 스스로 "끝났다"고 판단하면 멈추며 짧고 일회성인 작업에 맞는다. 목표 기반 루프(/goal)는 사람이 완료 조건을 미리 정하고, 검증 가능한 종료 기준이 있는 작업에 쓴다. 시간 기반 루프(/loop, /schedule)는 정해진 주기마다 다시 실행되며 반복 작업이나 외부 시스템 확인에 적합하다. 사전 대응형 루프는 사람 개입 없이 이벤트나 일정으로 트리거되고, 버그 신고·이슈 분류·마이그레이션처럼 잘 정의된 반복 작업 흐름 전체를 맡긴다.

턴 기반, 목표 기반, 시간 기반, 사전 대응형 네 가지 루프가 자율성 수준에 따라 쌓인 구조도 — 클로드 코드가 나눈 네 가지 루프, 위로 갈수록 사람 개입이 줄어든다.

좋은 목표는 숫자로 끝난다

오스마니는 /goal을 "증명 가능하게 끝날 때까지" 특정 작업을 완성시키는 용도로 쓴다고 밝혔다. 그가 예로 든 명령은 이렇다. "Dashboard.tsx의 데이터 페칭 레이어를 Lighthouse 성능 점수 92 이상, LCP 1.8초 미만이 될 때까지 리팩터링하라. 훅의 공개 API는 바꾸지 마라. 매 턴 최소 하나의 지표를 개선해야 하고, 두 턴 연속 개선이 없으면 중단하라. 10턴 안에 멈춰라." 이 명령이 통하는 이유는 평가자 모델이 결과물의 좋고 나쁨을 판단하지 않기 때문이다. 평가자는 오직 대화 기록을 보고 사람이 못박은 규칙이 지켜졌는지만 확인하고, 규칙이 충족되지 않으면 다시 작업으로 돌려보낸다. 테스트 통과 개수나 점수 임계값처럼 결정적인 기준일수록 이 방식이 잘 작동한다.

사람이 정한 조건이 평가자 모델을 거쳐 정지 또는 재시도로 이어지는 /goal 명령의 흐름도 — /goal 한 줄에 담긴 입력 조건, 평가, 정지 판단의 구조.

맡길 일과 지켜볼 일을 가르는 기준

오스마니는 문서 작성이나 테스트 커버리지 확인처럼 상대적으로 안전한 작업은 편하게 위임하지만, 인증이나 보안, 금전과 관련된 기능은 진행 상황을 계속 들여다본다고 말한다. 그가 직접 겪은 사례가 이 기준의 이유를 보여준다. 그는 에이전트에게 경쟁 제품을 조사해 자신들이 놓친 기능이 있는지 찾아보라고 시켰고, 에이전트는 로컬에 PR 몇 개를 준비했다. 조사 내용만 읽고 구현은 자세히 보지 않은 채 그중 일부를 올릴 뻔했는데, 나중에 코드를 뜯어보니 사용자 입장에서 얻는 이득에 비해 복잡도만 크게 늘어나는 변경이었다. 그는 이 경험을 "작업은 위임했지만 판단까지 위임할 뻔했다"고 정리한다. 이 때문에 그가 지키는 또 다른 습관은 작업한 에이전트가 스스로 결과를 좋다고 선언하게 두지 않는 것이다. 한 서브에이전트가 변경을 만들면 별도의 서브에이전트가 그 결과를 검증한다. 검증자가 데스크톱 성능만 확인하고 모바일은 놓친 경우처럼, 작성자가 확신했던 지점에서 새 관점의 검증자가 허점을 잡아내는 경우가 실제로 있었다고 그는 적었다.

작성 서브에이전트와 검증 서브에이전트가 분리되어 서로 다른 관점에서 재확인하는 구조도 — 작업한 에이전트가 자기 결과를 승인하지 않도록 만든 이중 확인 구조.

루프에는 유효 기간이 있다

오스마니가 짚은 실무 디테일도 있다. 반복 루프는 만든 지 7일이 지나면 만료된다. 그는 이전에 3일이라고 잘못 안내했던 점을 이번 글에서 바로잡았다. 루프는 세션에 묶여 있어 새 대화를 시작하면 멈추지만, --resume이나 --continue로 같은 세션을 이어가면 7일 이내의 반복 작업은 그대로 살아난다. 세션을 넘어서까지 유지해야 하는 작업은 클라우드에서 도는 /schedule을 쓴다. 루프가 제자리에서 헛돌고 있다는 신호도 하나 알려준다. 같은 명령을 결과 변화 없이 세 번째로 반복하고 있다면, 그 시점이 멈춰야 할 때라는 것이다.

루프가 통하지 않는 일

오스마니는 루프가 안 맞는 경우도 분명히 짚는다. "이 UI 디자인이 좋아질 때까지 계속하라" 같은 목표는 실패하기 쉬운데, 좋다는 기준을 누가 어떻게 매길지가 정의되어 있지 않기 때문이다. 사람의 취향, 주관적 디자인 판단, 열려 있는 창작 탐색이 필요한 작업은 루프에 맞지 않는다고 그는 말한다. 반대로 끝난 상태가 무엇인지 분명할 때는 루프를 우선 검토할 만한 선택지가 된다.

출처: Addy Osmani, Elevate, "Practical Loop Engineering" (2026-08-16 확인)