읽는 데 9분Cat

사람의 답을 기다릴 때는 종료해요, Agent Autoloop의 작업 이어가기

2026-11-06 IT AI 개발원리

“서비스를 재시작해도 될까요?” 에이전트가 물었는데 사람이 내일 답한다면, 그동안 에이전트는 무엇을 하고 있어야 할까요.

Agent Autoloop은 Claude Code·Codex 같은 명령줄 에이전트 바깥에 작업을 맡기고 이어 주는 허브를 두는 프로젝트예요. MIT 라이선스로 공개돼 있고 Windows, macOS, Linux에서 돌아가요. 여기서 눈에 띄는 선택은 사람을 기다릴 때 에이전트 실행을 끝낸다는 점이에요. 실제 에이전트 계정 없이 돌릴 수 있는 부분은 Linux 격리 컨테이너에서 직접 실행해 봤어요.

기다리는 동안 종료되는 것은 에이전트예요

프로젝트는 한 번의 실행과, 그보다 오래 지속되는 작업을 나눠요. 에이전트는 한 차례 일한 뒤 마지막 응답에 결과나 질문을 남기고 종료해요. 질문과 작업 상태는 허브가 SQLite 데이터베이스에 보관하고요.

답변이 오면 이를 새 이벤트로 받아 에이전트를 다시 실행해요. 가능하면 질문했던 원래 대화를 이어 쓰지만, 그 대화를 복구할 수 없다면 자료 파일을 바탕으로 새 대화에서 계속하도록 설계돼 있어요.

작업 실행, 질문 전달과 종료, 상태를 보관하며 답변 대기, 답변 후 재실행으로 이어지는 과정. 대기 중에도 허브는 남고 원래 대화 재개는 가능한 경우에만 이뤄져요. — 사람을 기다리는 동안 에이전트 프로세스는 끝나고, 허브가 작업과 질문을 보관해요.

그러니 “대기 중 프로세스도 비용도 없다”는 설명은 기다리는 에이전트 실행에 한정해서 읽어야 해요. 허브까지 사라지는 것은 아니고, 답변 뒤 모델을 다시 호출하면 그 실행의 사용량은 발생해요.

코드에서도 Claude Code 어댑터가 기존 세션 정보가 있을 때 --resume을 전달하고, 없을 때는 새 세션으로 시작하는 분기를 확인했어요. 상태 보관 코드에는 작업과 질문 카드, 이벤트를 데이터베이스에 기록하는 구조가 있어요.

질문은 마지막 응답에 남겨요

에이전트가 허브에 질문을 넘길 때는 마지막 응답에 ask 같은 구조화된 항목을 붙여요. 사람은 알림이나 명령줄에서 질문을 보고 답하고, 허브는 그 결정을 다음 실행에 전달해요.

공식 README에는 색을 고르는 시험 실행이 나와요. 제작자가 공개한 콘솔 출력을 짧게 번역하면 다음과 같아요.

[결정 대기] #1 시험: 색 고르기
1. 파랑
2. 초록
답변: agent-autoloop answer 1 <번호>

이 방식의 쓸모는 채팅창을 하나 더 만드는 데 있지 않아요. 질문한 실행은 끝내고도 무엇을 기다리는지와 다음에 할 일을 남겨 둔다는 데 있어요. 재시작 승인이나 로그인 복구처럼 사람 없이는 해결할 수 없는 일에서, 같은 실패를 계속 재시도하는 대신 답을 기다리는 상태로 바꿀 수 있는 거죠.

시작 조건은 Node.js 24 이상, Git, 이미 설치하고 로그인한 명령줄 에이전트예요. macOS와 Linux에서는 curl도 필요해요. Slack·Discord 등의 알림 템플릿도 있지만, README는 이들 Webhook 템플릿을 로컬 모의 서비스에서만 검증했다고 구분해요. 실제 운영 연동이 모두 검증됐다고 읽으면 안 돼요.

재개가 중복 실행을 없애 주지는 않아요

프로토콜 문서는 에이전트가 같은 일을 두 번 호출받을 수 있는 ‘적어도 한 번’ 처리 방식이라고 명시해요. 따라서 메시지를 보내거나 서비스를 바꾸는 작업은 다시 실행하기 전에 현재 상태를 확인해야 해요. 대화를 이어 쓴다는 것과, 외부 작업이 정확히 한 번만 일어난다는 것은 다른 보장이에요.

외부 Issue의 제목과 본문은 지시문에 직접 합치지 않고 자료 파일로 분리하고, 어떤 에이전트가 어느 폴더에서 어떤 권한으로 일할지는 로컬 규칙이 정해요. 다만 보안 문서도 이것이 모든 프롬프트 주입을 막지는 못한다고 밝혀요. 자료를 읽는 모델은 여전히 외부의 말을 보니까요. 보안 문서는 별도 운영체제 사용자나 컨테이너 같은 격리를 따로 두라고 해요.

계정 없이 돌려 볼 수 있는 부분

README의 실측 수치는 Apple M5 Pro에서 낸 것이에요. 그래서 node:24 공식 이미지(Node 24.22.2)의 Linux 격리 컨테이너에서 11월 6일 main을 받아 모델 없이 도는 시험만 돌려 봤어요.

돌린 것	결과
`node sim/crash.ts 1000 12648430`(README의 강제 종료 시험)	SIGKILL 1000번, 확인 응답을 받은 기록 8,870건이 모두 남음, 데이터베이스 무결성 검사 통과
`node sim/random.ts 24301 20000`(README 값의 10분의 1 규모)	유실 2,303번, 중복 1,646번, 재시작 1,679번 등 장애를 섞은 2만 단계 완료
세션 이어가기·`try`·강제 종료·외부 질문 시험 4개 파일	24개 모두 통과

강제 종료 시험은 기록을 쓰는 프로세스를 1~10ms 안에 무작위로 죽인 뒤 데이터베이스를 다시 열어 봐요. 확인 응답이 나간 기록이 하나라도 없으면 실패해요. 반대로 데이터베이스에는 남았지만 확인 응답은 나가지 않은 기록이 2건 있었어요. 잃어버리지는 않지만, 보낸 쪽은 성공 여부를 모르는 상태예요.

try 시험은 처음에 실패했어요. 컨테이너의 /tmp가 실행 금지로 연결돼 있어 가짜 에이전트 스크립트를 실행하지 못했거든요. 임시 폴더를 작업 폴더로 옮기자 통과했어요. 프로젝트 문제가 아니라 시험 환경 조건이에요.

코드와 README를 맞춰 보면 이어가기의 조건도 하나 더 보여요. README는 Claude Code와 Codex, ACP는 여러 차례 질문과 프로세스를 넘는 대화 이어가기까지 확인했다고 적었어요. 반면 한 줄 설정으로 붙이는 범용 명령 어댑터는 "세션이 없다"고 적었고, 실제로 이 어댑터 코드에는 세션이나 resume 처리가 없어요. 이 경로로 붙인 에이전트는 답변 뒤 원래 대화가 아니라 자료 파일만 들고 새로 시작한다고 보는 편이 맞아요. 같은 주제의 새 이벤트도 기본은 새 대화이고, 규칙에 "resume": true를 적어야 이전 대화를 이어 써요.

이 프로젝트에서 가져올 만한 설계 질문은 단순해요. 작업이 오래 살아야 한다고, 그 작업을 처리하는 에이전트 프로세스도 오래 살아야 할까요? Agent Autoloop은 질문·답변·작업 상태를 에이전트 밖에 남겨 둘 수 있음을 구체적인 프로토콜로 보여 줘요.

확인한 범위

기준일: 2026-11-06.
직접 한 것: 11월 6일 main(a1e619c)을 node:24 격리 컨테이너에서 받아 강제 종료 시뮬레이션(1000회), 장애 시뮬레이션(2만 단계), 세션 이어가기 관련 시험 4개 파일(24개)을 돌렸어요. Claude Code 어댑터와 범용 명령 어댑터 코드를 README 설명과 대조했어요.
읽은 것: README, 통신 프로토콜과 보안 문서, Claude Code 어댑터·에이전트 타입·상태 보관 코드.
확인하지 못한 것: 실제 Claude Code·Codex 계정으로 질문하고 답한 뒤 세션이 복구되는지, 외부 알림 연동, Windows와 macOS에서의 동작. 시험은 모두 프로젝트가 제공한 시뮬레이션과 가짜 에이전트로 돌렸어요.