에이전트 팀의 작업 큐는 왜 작아야 하나 — 컨텍스트와 비용을 같이 관리하는 법

AI 에이전트 팀을 쓰기 시작하면 가장 먼저 생기는 유혹은 작업을 많이 쌓는 일이에요. 사람 혼자 처리하던 일을 여러 에이전트에게 나눌 수 있으니, 미뤄둔 문서와 QA, 리서치, 구현 검토를 한꺼번에 올리고 싶어져요. 실제로 병렬 처리량은 늘어나요. 하지만 작업 큐가 커질수록 다른 비용도 같이 커져요.

KoalStudio에서는 큐를 “할 일 목록”이라기보다 동시에 살아 있는 판단의 수로 봐요. 아직 닫히지 않은 작업은 컨텍스트를 요구하고, 상태 확인을 만들고, 결과를 검토해야 해요. 에이전트가 일을 대신해도 사람이 마지막 결정을 내리는 구조라면, 큐의 크기는 곧 사람의 판단 대기열이 됩니다.

그래서 목표는 가능한 한 많은 작업을 여는 것이 아니에요. 지금 열려 있는 작업이 서로를 흐리지 않게 하고, 닫을 수 있는 단위로 유지하는 것이 먼저예요.

큐가 커지면 컨텍스트가 먼저 흐려져요

작업 하나는 단순한 제목이 아니에요. 왜 하는지, 어떤 문서를 봐야 하는지, 어느 제품의 정본을 따라야 하는지, 어디까지 하면 끝나는지가 함께 붙어 있어야 해요. 큐가 작을 때는 이 맥락을 담당자가 머릿속과 작업 로그로 따라갈 수 있어요. 큐가 커지면 비슷한 말들이 서로 섞이기 시작해요.

예를 들어 “검증 기준 정리”라는 작업은 WineDuck, Called Up, Project Whisper에서 모두 나올 수 있어요. 하지만 세 제품에서 검증한다는 말은 같은 뜻이 아니에요. WineDuck에서는 데이터 신뢰와 미매핑 처리일 수 있고, Called Up에서는 같은 입력이 같은 커리어를 재현하는지일 수 있고, Project Whisper에서는 저장된 세계 상태가 진행을 되돌리지 않는지일 수 있어요.

큐에 작업이 많이 열려 있으면 에이전트는 제목이 비슷한 작업들을 넓게 참고하려고 해요. 그러면 답은 풍부해 보이지만 실제 제품의 기준에서 멀어질 수 있어요. 그래서 작업을 열 때는 제품, 기준 문서, 종료 조건을 짧게 붙여요. “검증 기준 정리”가 아니라 “Called Up 재실행 검증 기준을 현재 정본 기준으로 1페이지 요약”처럼 적는 편이 낫습니다.

컨텍스트를 아끼는 가장 쉬운 방법은 좋은 압축이 아니라 작은 작업이에요. 한 작업이 한 제품, 한 판단, 한 산출물로 닫히면 에이전트가 읽어야 할 자료도 줄고 검토자가 확인해야 할 범위도 줄어요.

병렬성은 무료가 아니에요

에이전트가 여러 명이면 작업을 동시에 시작할 수 있어요. 하지만 동시에 시작한 작업이 모두 동시에 끝나는 것은 아니에요. 어떤 작업은 외부 상태를 기다리고, 어떤 작업은 검토에서 막히고, 어떤 작업은 결과가 너무 커서 다시 쪼개야 해요. 이때 큐가 크면 완료된 일보다 열린 상태가 더 빨리 늘어나요.

열린 상태는 비용을 만듭니다. 상태를 다시 물어야 하고, 중간 결과를 읽어야 하고, 오래된 초안을 최신 기준과 비교해야 해요. 특히 에이전트 작업은 결과물이 빠르게 나오기 때문에 검토 병목이 늦게 보이는 편이에요. “많이 시켰다”는 감각은 바로 오지만 “많이 검토해야 한다”는 부담은 결과가 쌓인 뒤에 와요.

그래서 KoalStudio에서는 병렬 작업을 시작하기 전에 먼저 세 가지를 봐요.

질문	큐에 넣어도 되는 조건
바로 닫을 수 있나	산출물이 한 화면이나 한 문서 단위로 끝나요
검토자가 정해졌나	결과를 읽고 승인할 사람이 보여요
다른 작업을 막지 않나	완료 순서가 꼬여도 되거나 의존성이 명확해요

이 셋 중 하나라도 모호하면 작업을 더 크게 열지 않아요. 먼저 질문을 줄이거나, 선행 작업 하나만 열어요. 병렬성은 시작 수가 아니라 닫히는 수로 평가해야 해요.

작업 큐에는 예산이 필요해요

작업 예산은 돈만 뜻하지 않아요. 토큰, 시간, 검토 집중력, 배포 리스크가 모두 예산이에요. 작은 블로그 글 하나도 초안 작성, 사실 확인, 링크 검증, 빌드, 배포 확인을 거치면 여러 종류의 예산을 씁니다. 구현 작업이라면 테스트와 롤백 가능성까지 붙어요.

그래서 작업 카드에는 “얼마나 쓸 수 있는가”도 들어가야 해요. 예산이 없으면 에이전트는 더 좋은 답을 위해 계속 확장하려고 해요. 관련 문서를 더 찾고, 대안을 더 만들고, 구조를 더 일반화해요. 때로는 그게 필요하지만 모든 작업이 그렇게 커질 수는 없어요.

실무에서는 아래처럼 제한을 두는 편이 가장 잘 맞았어요.

예산 종류	작업에 적는 방식
시간	30분 안에 초안, 2시간 안에 PR처럼 상한을 둬요
범위	한 파일, 한 정책, 한 화면처럼 표면을 제한해요
근거	정본 1개와 원문 2개처럼 확인할 자료를 정해요
검토	오류만 볼지, 구조까지 볼지 검토 깊이를 정해요
외부 영향	게시, 배포, 전송 여부를 별도로 분리해요

예산은 에이전트를 덜 일하게 만드는 장치가 아니에요. 에이전트가 어디까지 충분히 일했는지 판단하게 만드는 장치예요. 제한이 있어야 결과도 닫힙니다.

완료 기준이 없으면 큐는 기록 저장소가 돼요

작업 큐가 망가질 때 가장 흔한 모습은 닫히지 않은 카드가 오래 남는 거예요. 내용은 많고, 댓글도 있고, 중간 결과도 있지만 완료 여부가 분명하지 않아요. 이런 카드는 다시 열 때마다 새 작업처럼 비용을 써요. 지난 맥락을 읽고, 무엇이 남았는지 추정하고, 최신 기준과 맞는지 다시 확인해야 하니까요.

완료 기준은 거창할 필요가 없어요. “문서 초안 작성”보다 “공개 가능한 Markdown 글 1개 생성, 빌드 통과, URL 200 확인”이 좋아요. “리서치”보다 “후보 3개 비교 후 추천 1개와 리스크 3개 정리”가 좋아요. 결과물이 닫히는 모양을 먼저 적으면, 에이전트도 중간에 어디서 멈춰야 하는지 알 수 있어요.

완료 기준은 검토자의 부담도 줄여요. 검토자는 전체 사고 과정을 다시 평가하지 않고, 요청한 산출물이 기준을 만족하는지만 볼 수 있어요. 문제가 있으면 작업을 다시 무한히 열지 않고, 새 기준으로 다음 작은 작업을 만듭니다.

큐를 작게 유지하는 운영 규칙

KoalStudio에서 작업 큐를 다룰 때 쓰는 규칙은 단순해요.

한 작업은 한 산출물로 닫아요.
제품과 지식존을 먼저 적어요.
담당자와 검토자를 분리해요.
외부 행동은 작업 완료와 분리해요.
오래 열린 작업은 이어서 하지 말고 다시 쪼개요.

이 규칙은 속도를 늦추기 위한 것이 아니에요. 오히려 속도를 유지하기 위한 장치예요. 열린 작업이 적으면 상태 보고가 줄고, 검토가 빨라지고, 결과가 정본으로 승격될지 폐기될지 판단하기 쉬워져요.

작업 큐가 작다고 해서 할 일이 적은 것은 아니에요. 큐 밖에는 아이디어와 후보, 나중에 할 일이 많을 수 있어요. 다만 지금 시스템 안에서 살아 움직이는 작업만 작게 유지해요. 백로그는 넓어도 되고, 활성 큐는 좁아야 해요.

에이전트 팀의 처리량은 시작량이 아니라 회수율이에요

사람이 하나의 팀을 운영할 때 중요한 숫자는 에이전트가 몇 개를 시작했는지가 아니에요. 끝까지 검토되어 의사결정에 반영된 결과가 몇 개인지가 더 중요해요. 시작한 작업이 많아도 결과가 흩어지고 검토가 밀리면 실제 처리량은 낮아요.

그래서 큐의 크기를 볼 때는 “열린 작업 수”와 “닫힌 결과 수”를 같이 봐야 해요. 열린 작업이 계속 늘고 닫힌 결과가 따라오지 못하면 병렬성이 아니라 체증이에요. 반대로 열린 작업은 적어도 매일 공개 글, 검증 문서, 작은 수정처럼 닫힌 결과가 쌓이면 시스템은 건강하게 움직이고 있어요.

이 관점은 다중 에이전트 팀의 말하기 규칙과도 연결돼요. 담당자가 결과를 회수하고, 검토자는 차이만 남기고, 관찰자는 필요한 때만 끼어들어야 큐가 작게 유지돼요. 지식존과 정본의 경계도 같은 이유로 필요해요. 작업이 작아도 참조하는 기억이 섞이면 검토 비용은 다시 커집니다.

에이전트 팀은 일을 많이 시작하게 해주는 도구이기도 하지만, 더 중요한 역할은 일을 작은 단위로 닫게 해주는 운영면이에요. 큐를 작게 유지하면 팀은 덜 바빠 보일 수 있어요. 대신 결과는 더 자주 닫히고, 사람은 더 적은 판단으로 더 많은 결정을 내릴 수 있어요.