에이전트 하나를 돌릴 때는 안 보이는 문제
에이전트가 하나면 화면을 보고 있으면 됩니다. 여러 개를 동시에 돌리는 순간 "지금 몇 번이 일하는 중인가"를 프로그램이 판단해야 하고, 여기서 거의 모두가 같은 구현을 먼저 시도합니다.
PTY 에서 바이트가 나왔다 → 일하는 중
일정 시간 아무것도 안 나왔다 → 놀고 있음
직관적이고, 틀렸습니다. 문제는 양쪽 방향으로 동시에 틀린다는 것입니다. 그래서 한쪽을 고치면 다른 쪽이 나빠지고, 원인을 찾기가 어렵습니다.
방향 1 — 끝난 에이전트가 바쁘게 보인다
에이전트 CLI 가 작업을 마치고 프롬프트에서 대기하면, 커서와 스피너를 계속 다시 그립니다. 그 리페인트 하나하나가 PTY 바이트입니다.
출력 기반 판정은 그때마다 상태를 "일하는 중"으로 되돌립니다. 놀고 있는 에이전트가 영원히 바쁜 것으로 남습니다.
여기서 흔히 쓰는 대응이 settle window 입니다 — "마지막 출력 이후 N 초가 지나야 idle 로 본다". 이건 오분류를 없애는 게 아니라 N 초만큼 미루는 것입니다. 스피너는 N 초보다 자주 그려집니다.
방향 2 — 일하는 에이전트가 놀고 있는 것처럼 보인다
이쪽이 더 위험합니다.
추론 중인 에이전트는 PTY 출력이 아예 없습니다. 모델이 긴 응답을 생성하는 동안, 도구 호출 결과를 기다리는 동안, 터미널은 완전히 조용합니다.
그러면 어떤 비활성 타임아웃을 걸어도 언젠가는 실제로 일하고 있는 에이전트를 idle 로 표시합니다. 그 다음이 진짜 문제입니다 — 오케스트레이터가 그 에이전트에 새 작업을 밀어넣거나, 작업 중인 것을 회수해 버립니다.
규칙 — 소음이 아니라 경계로 정의한다
턴은 시작과 끝으로 정의합니다. 제출된 입력에서 시작하고, 명시적인 완료 보고에서 끝납니다. 출력은 힌트일 뿐 상태가 아닙니다.
구현할 때 놓치기 쉬운 두 가지가 있습니다.
사람이 친 입력도 턴을 연다. 프로그램이 넣은 입력만 턴을 여는 구조로 만들면, 사람이 에이전트 터미널에 직접 타이핑한 세션은 영원히 idle 에 갇힙니다. 어느 경로에서 왔든 캐리지 리턴에 턴을 엽니다. 개별 키 입력은 세지 않습니다 — 한글 입력기 조합 중일 수 있습니다.
턴 시작 이벤트는 입력이 수락될 때 쏜다. 플러시될 때가 아닙니다. 쓰기 경로가 큐잉되거나 비동기면, 플러시 시점 이벤트는 그 상태를 읽는 코드보다 늦게 도착합니다.
같이 나온 버그 — 증거를 스스로 지우는 패턴
생존 신호를 고치다가 더 일반적인 버그를 하나 만났습니다. 에이전트와 무관하게 반복되는 모양이라 이름을 붙여둘 가치가 있습니다.
회수(reclamation) 로직은 에이전트가 작업 ID 에 묶여 있어야 회수 대상으로 봤습니다. 그리고 완료 핸들러는 가장 먼저 그 작업 ID 를 지웠습니다.
정리 대상이 되게 만드는 사건이, 정리에 필요한 증거를 없앴습니다.
결과가 뒤집혀 있었습니다. 깨끗하게 끝난 에이전트가 영구히 회수 불가가 되고, 지저분하게 죽은 것만 수거됐습니다. 12코어 머신에서 좀비 에이전트 11개가 쌓여 로드 애버리지가 44 까지 올라가는 동안, 정리 도구는 "회수 가능한 에이전트 없음"을 보고하고 있었습니다.
정리 게이트가 상태 X 에 의존한다면, 정상적으로 끝나는 경로가 X 를 지우는지 확인하십시오. 지운다면 unbind 시점에 별도 키로 증거를 남겨야 합니다.
그리고 하면 안 되는 대응
이 문제를 만나면 이런 규칙이 떠오릅니다 — "묶인 작업이 없고 오래 idle 이면 회수한다".
하지 마십시오. 아직 부팅 중인 에이전트와, 바인딩이 기록되지 않은 에이전트는 그 규칙 아래에서 끝난 에이전트와 구별되지 않습니다.
증거가 없는 것은 완료의 증거가 아닙니다. 의심 대상으로 보고할 수는 있어도 수거해서는 안 됩니다.
정리
| 흔한 구현 | 실제 결과 |
|---|---|
| PTY 출력 = 일하는 중 | 끝난 에이전트가 스피너로 영원히 바쁨 |
| 비활성 타임아웃 = 놀고 있음 | 추론 중인 에이전트를 회수 |
| settle window | 오분류를 없애지 않고 미룸 |
| 입력 제출 → 완료 보고 | 경계가 상태를 정의한다 |
이 판정을 직접 구현하는 대신, 보드에서 상태를 보는 쪽이 빠릅니다. Marblo 는 티켓 상태를 TODO → IN PROGRESS → REVIEW → DONE 로 명시적으로 관리하고, 각 에이전트가 어떤 티켓에 묶여 있는지를 보드에 표시합니다.
이 글의 내용은 저희가 이종 에이전트 CLI 를 운영하며 측정한 것이고, 전문은 공식 리포지토리의 Fleet Operations 지식팩에 공개돼 있습니다. 계정 없이 바로 읽으실 수 있습니다.
같은 운영에서 나온 다른 글
- resume 플래그는 하네스마다 다르고, 틀리면 프로세스가 죽는다 — 세션 재개 계약 실측 표
- 비용 테이블이 비었는데 파서도 라우팅도 멀쩡하다 — 비용 귀속이 조용히 깨지는 자리