명령줄 에이전트가 일을 이어 가다가 사람의 판단이 필요할 때 알림을 보내는 도구인 Agent Autoloop이 첫 정식 버전으로 공개됐다. 개발자는 일정이나 이슈에 작업 규칙을 연결하고, 터미널을 계속 지키는 대신 알림 카드에서 질문에 답해 작업을 재개할 수 있다.

1. 사건을 받으면 규칙에 따라 에이전트가 일한다

Agent Autoloop은 일정, 새 이슈, 운영 경보 등을 사건으로 받아 정해 둔 에이전트와 작업 폴더로 보낸다. 같은 대상의 사건이 대기 중에 더 들어오면 한 차례의 작업으로 합친다. 에이전트는 처리 결과를 최종 메시지에 남기고 실행 중인 프로그램 단위인 프로세스를 종료한다.

사건을 받는 기능, 에이전트 연결, 알림 채널, 배포 과정은 플러그인, 기능을 갈아 끼우는 확장 요소로 교체할 수 있다. 예를 들어 이슈를 받아 코드를 고치는 에이전트를 실행하고 메신저로 판단을 요청하는 흐름을 구성할 수 있다. 작업을 찾는 수단과 실제로 일하는 도구를 따로 선택하는 구조다.

2. 설치 뒤 일정과 작업 폴더를 등록한다

macOS와 Linux에서 쓸 수 있으며 Node 24가 필요하다. Git과 curl, 로그인된 명령줄 에이전트도 준비해야 한다. 릴리스 노트에 실린 설치와 시험 실행 예시는 다음과 같다.

curl -fsSL https://raw.githubusercontent.com/KKKKhazix/agent-autoloop/main/install.sh | sh
agent-autoloop try

설치 명령은 특정 버전 태그 대신 main을 따라간다. 시험 실행에서는 에이전트가 질문을 남기고 종료한 뒤, 사용자가 답하면 원래 대화를 이어서 마치는 흐름을 확인할 수 있다.

실제 작업은 ~/.agent-autoloop/rules.json에 등록한다. README의 예시는 매일 오전 9시에 Codex가 노트 폴더의 전날 기록과 커밋, 저장소에 기록한 변경 묶음을 요약하도록 한다. 규칙에는 언제 실행하고 누구에게 맡기며 어느 폴더에서 작업할지를 적는다.

저장한 규칙은 몇 초 안에 반영되며 agent-autoloop check로 검사할 수 있다. 설정에 오류가 생기면 허브, 여러 작업과 알림을 중계하는 중심 프로그램은 이전의 유효한 규칙을 계속 사용하고 오류를 알린다.

3. 판단 요청과 배포 절차를 같은 흐름에 넣는다

에이전트는 질문이 필요할 때 최종 메시지에 정해진 응답 블록을 붙인다. 허브는 질문 제목과 설명, 선택지를 알림 카드로 전달한다. README는 데이터 삭제, 서비스 재시작, 비용 발생, 사람에게 연락하는 일을 판단 요청의 예로 든다.

사용자의 답은 원래 대화를 재개하는 입력이 된다. 에이전트가 스스로 처리할 수 있는 일은 마치거나 나중에 다시 확인하도록 예약할 수 있다. 응답 형식이 잘못되면 허브는 완료한 작업을 반복하는 대신 같은 세션, 이어지는 대화 기록 단위에서 최종 메시지만 다시 쓰도록 요청한다.

배포까지 이어 가는 전달 플러그인도 포함됐다. GitHub의 코드 변경 요청에 deliver 라벨, 변경 요청을 분류하는 꼬리표를 붙이면 검토, 자동 검사 대기, 병합, 배포 대기, 실제 서비스 버전 확인을 차례로 진행한다. README에 따르면 설정은 main에서만 읽으며 변경 요청의 코드를 작업 머신에 내려받아 실행하지 않는다.

4. 기다리는 비용은 줄이고 운영 설정은 사용자가 맡는다

사람의 답을 기다리는 동안 에이전트 프로세스는 종료되고 토큰 사용도 멈춘다. 대기 상태는 SQLite에 저장되며 가벼운 허브만 백그라운드에 남는다. 계속 실행되는 에이전트를 붙잡아 두는 대신, 기록을 보관했다가 답이 오면 대화를 잇는 방식이다.

이익은 터미널을 지켜보는 시간과 대기 중 에이전트 자원 사용을 줄이는 데 있다. 그 대신 사용자는 작업 규칙과 알림 경로를 설정하고 필요한 결정을 내려야 한다. 모델 사용료는 사용자의 계정으로 청구되므로, 대기 비용 절감과 실제 작업에 드는 모델 비용을 함께 살펴야 한다.

5. 벤치마크는 작업 허브의 부담을 보여 준다

프로젝트 README는 Apple M5 Pro, 메모리 24 GB, Node 24.21.0 환경의 측정치를 제시한다. 각 쓰기는 별도 요청이며 트랜잭션, 한 묶음으로 처리되는 데이터 작업이 디스크에 확정된 뒤 응답한 결과다. 아래 수치는 에이전트의 개발 성과보다 작업을 받아 넘기는 허브의 기동 시간과 자원 사용을 보여 준다.

표: Agent Autoloop 1.0.0 허브 벤치마크

조건: Apple M5 Pro, 24 GB, Node 24.21.0. 각 쓰기는 별도 요청이며 트랜잭션이 디스크에 확정된 뒤 응답

단위: 기동·전달 지연은 ms, 메모리는 MB RSS, 쓰기 처리량은 events/s

작업 전달 지연의 p99는 1.82 ms로, 측정값의 99%가 해당 시간 이하였다는 뜻이다.

기록 110만 건에서 일반 기동은 99.8 ms였지만, 같은 README는 형식 변경 뒤 로그에서 상태를 다시 만드는 첫 기동에는 같은 기록 수에서 43.1초가 걸렸다고 적었다. 일반 기동과 달리 로그 재구성이 필요한 조건이므로, 업데이트 운영을 계획할 때 구분해 살필 지표다.

검증 항목에는 장애와 중복 요청을 포함한 20만 단계 시뮬레이션, 가상 상황에서 동작을 시험하는 절차, 프로세스 종료 1,000회 시험이 제시됐다.

명령줄 출력과 기본 알림은 현재 중국어다. Feishu는 실전송과 버튼 응답을 시험했지만 네 가지 Webhook, 서비스 간 자동 알림을 보내는 연결 방식 템플릿은 로컬 모의 서버에서만 확인됐으며, 해당 텍스트 채널에서 답하려면 기기에서 허브의 공개 주소에 접속할 수 있어야 한다.

Agent Autoloop 1.0.0의 핵심은 에이전트에 일을 더 맡기면서도 사람이 결정할 순간을 작업 흐름 안에 남기는 데 있다.