작업 끝나면 폰으로, 한도 닿기 전엔 스스로 멈추게 — 감시·스케줄링·전담 헤드까지 여러 갈래 답이 나왔다

자정을 9분 넘긴 시각, 한 참여자가 질문 하나를 올렸다. 에이전트에게 긴 작업을 맡겨 두고 자리를 비우는 이용자라면 한 번쯤 떠올렸을 법한 물음이었다.

클로드 코드, 코덱스 작업끝나면 핸드폰으로 알람오는 기능, 한도 임박하면 작업 중단하고 중간 보고서로 만드는 기능 만들려면 어떻게 해야되요?

요구는 두 가지였다. 일이 끝나면 알려 줄 것, 그리고 한도가 바닥나기 전에 스스로 멈추고 그때까지의 결과를 보고서로 남길 것이다. 이 주제에는 6명이 43건의 발화를 보탰다.

여러 갈래로 나온 답

5분 뒤 다른 참여자는 PC 사양이 받쳐 준다면 로컬 LLM에 감시를 맡겨 알림과 중간 보고, 작업 재시작까지 한 번에 엮어 보라고 권했다. 사람이 지켜보던 자리를 작은 모델 하나가 대신 지키게 하자는 발상이다.

이어 훅으로 남은 사용량을 재고, 그 값에 따라 API를 쏘는 방식이 제안됐다. 에이전트가 도는 도중에 끼어드는 지점을 만들어 두고, 그 지점에서 한도를 읽는 구조로 보인다.

비슷한 무렵 또 다른 참여자는 클로드 코드와 코덱스의 작업 한도를 실측해 두었다가, 5시간 한도에 닿으면 다음 자연 리셋 시각에 이어서 작업하도록 걸어 두는 방법을 짚었다. 멈춘 뒤 다시 시작하게 해 달라는 질문자의 요구에 가장 직접 닿은 답이었다.

또 하나의 답은 결이 달랐다. 여러 에이전트 세션 가운데 메인 세션(헤드) 하나를 일을 나눠 주고 검토·보고만 하는 오케스트레이션 역할로 묶어 두자는 제안이었고, 그 헤드에 줄 지시문이 그대로 올라왔다.

넌 무조건 오케스트레이션 헤드 역할만 수행한다. 검토, 보고, 작업 라우팅의 역할만 맞는다.

직접 일을 하지 않는 헤드가 작업을 나눠 주고 결과를 받아 보고하다가, 주간한도 95% 부근에 이르면 스냅샷을 찍고 핸드오프하게 하자는 흐름이다. 같은 참여자는 "대충 주간한도 95% 부근에 해놓으면 됨"이라고 선을 제시했다.

도구보다 역할 나누기

답들을 나란히 놓으면 도구 이름보다 누가 지켜보고 누가 멈추게 하느냐가 축이었다. 알림과 중단을 별도 기능으로 붙이기보다, 감시와 판단을 맡는 층을 따로 두는 쪽으로 대화가 흘렀다는 점이 눈에 띈다.

같은 밤 이 방에서는 코덱스 사용량 리셋을 기다리던 참가자가 여럿이었고, 참가자들이 확인한 바로는 리셋이 새벽 1시 58분께 풀렸다. 한도에 막히는 경험이 잦을수록, 끊기기 전에 멈추고 넘겨주는 설계에 관심이 모이는 것으로 보인다.

눈여겨볼 대목은 질문이 멈춤 자체보다 멈춘 뒤를 함께 요구했다는 점이다. 한도에 닿아 작업이 그냥 끊기면 어디까지 했는지부터 다시 확인해야 하지만, 중간 보고서가 남으면 다음 세션이 그 자리에서 이어받을 여지가 생긴다. 스냅샷과 핸드오프라는 답이 나온 것도 같은 요구에 대한 응답으로 읽힌다.

다만 한도를 아끼는 설계만 나온 것은 아니었다. 한 참여자가 초안을 만들 때는 한 주 한도를 날리더라도 가장 센 설정을 쓴다고 하자, 질문자도 맞장구쳤다.

걍 요즘 오퍼스 5.5 울트라 걸고 하는게 최고

한도를 아끼며 끊기지 않게 하는 설계와, 한도를 태워서라도 가장 강한 모델을 쓰려는 선호가 한 스레드 안에 함께 놓였다. 에이전트를 오래 돌리는 이용자들 사이에서 한도 관리가 개인의 요령을 넘어 작업 구조의 문제로 옮겨 가고 있음을 시사하는 장면이다.