티켓·칸반으로 AI 에이전트 군단 지휘하기

핵심

에이전트가 두셋을 넘어가면 관리의 병목은 모델의 성능만이 아닙니다. 진짜 병목은 추적입니다. 어떤 에이전트가 어떤 파일을 만지고 있는지, 지금 멈춘 이유가 의존성인지 판단 부족인지, 결과물을 사람이 검수했는지, 다음 에이전트가 이어받아도 되는지 같은 질문이 빠르게 늘어납니다. 채팅창 여러 개를 열어 둔 방식으로는 이 상태를 안정적으로 유지하기 어렵습니다.

마블로가 택하는 해법은 단순합니다. 일을 티켓으로 정의하고, 그 티켓의 상태를 칸반 보드로 비춥니다. 사람 팀이 오래전부터 사용해 온 방식과 같습니다. 큰 목표를 작은 티켓으로 나누고, 각 티켓에 담당·범위·완료 조건·진행 기록을 남긴 뒤, TODO → IN_PROGRESS → REVIEW → DONE 흐름을 따라 이동시킵니다. 여러 AI 에이전트가 동시에 움직여도 사람은 보드 하나에서 전체 그림을 봅니다.

티켓은 에이전트에게 주는 프롬프트보다 넓은 개념입니다. 프롬프트가 "지금 무엇을 하라"는 지시라면, 티켓은 "왜 이 일을 하는지, 어디까지 해야 하는지, 끝났다고 판단하는 기준은 무엇인지, 누가 이어받을 수 있는지"를 담는 작업 단위입니다. 에이전트 군단을 지휘하려면 개별 대화보다 이 작업 단위가 먼저 안정되어야 합니다.

왜 티켓인가

AI 에이전트에게 자연어로 일을 시킬 수 있다는 점은 강력합니다. 하지만 자연어 지시는 쉽게 흩어집니다. 처음에는 "설정 페이지를 다듬어 줘"라고 말했지만, 중간에 "다크 모드도 봐 줘", "타입 에러가 있으면 고쳐 줘", "테스트는 나중에" 같은 보충 지시가 붙습니다. 한 명과 대화할 때는 이 정도가 감당됩니다. 세 명, 다섯 명, 열 명의 에이전트가 병렬로 움직이면 사정이 달라집니다.

티켓은 이 흩어짐을 줄입니다. 좋은 티켓은 최소한 네 가지를 고정합니다. 첫째, 문제입니다. 왜 이 작업이 필요한지 적습니다. 둘째, 범위입니다. 어떤 파일과 화면을 만질 수 있고 어떤 영역은 건드리지 말아야 하는지 적습니다. 셋째, 완료 기준입니다. 빌드가 통과해야 하는지, 화면 캡처를 확인해야 하는지, 특정 상태 전이가 동작해야 하는지 명시합니다. 넷째, 검토 기준입니다. 사람이 REVIEW에서 무엇을 확인해야 하는지 남깁니다.

이 네 가지가 고정되면 에이전트는 더 독립적으로 움직일 수 있습니다. 작업 도중에 대화가 길어져도 티켓이 기준점 역할을 합니다. 다른 에이전트가 이어받아야 할 때도 "지금까지 무슨 이야기를 했는지"를 채팅 로그 전체에서 추적할 필요가 줄어듭니다. 티켓의 설명과 활동 기록을 읽으면 현재 상태를 복원할 수 있습니다.

또 하나의 중요한 이유는 감사 가능성입니다. 여러 에이전트가 코드를 바꿀 때 가장 위험한 질문은 "왜 이렇게 됐지?"입니다. 티켓에는 작업의 시작 조건, 담당 에이전트, 중간 판단, 검증 결과, 리뷰 요청이 남습니다. 이 이력(provenance)은 버그를 되짚을 때도, 팀원이 결과를 승인할 때도, 나중에 비슷한 일을 자동화할 때도 근거가 됩니다.

칸반은 단순한 보드가 아니다

칸반 보드는 예쁜 목록이 아니라 상태 기계입니다. 마블로에서 작업은 TODO → IN_PROGRESS → REVIEW → DONE 흐름을 탑니다. 이 흐름이 중요한 이유는 에이전트가 "작업했다"는 사실과 사람이 "받아들였다"는 사실을 분리하기 때문입니다. 에이전트가 코드를 고치고 자체 검증을 마쳤더라도, 바로 DONE이 아니라 REVIEW로 이동해야 합니다. 사람은 거기서 변경 범위, 테스트 결과, 제품 판단을 확인합니다.

TODO는 아직 시작하지 않은 일입니다. 여기에는 준비된 티켓만 있어야 합니다. 설명이 모호하거나 의존성이 풀리지 않은 항목은 실제로는 TODO가 아니라 BLOCKED 후보입니다. IN_PROGRESS는 에이전트가 작업 중인 상태입니다. 이때 담당자가 분명해야 하고, 다른 에이전트가 같은 파일을 동시에 건드리는지 확인할 수 있어야 합니다. REVIEW는 에이전트의 산출물이 사람의 판단을 기다리는 상태입니다. DONE은 사람이 받아들인 상태입니다.

이 네 단계를 엄격하게 구분하면 병렬성이 안전해집니다. 에이전트가 많아질수록 "거의 끝남", "아마 됨", "확인 필요" 같은 애매한 상태가 가장 큰 비용을 만듭니다. 보드가 상태를 명확히 만들면 오케스트레이터는 다음 행동을 빠르게 결정할 수 있습니다. 새 에이전트를 투입할지, 리뷰를 먼저 할지, 막힌 티켓을 쪼갤지, 의존성을 다시 정리할지 판단할 수 있습니다.

티켓은 에이전트와 어떻게 묶이는가

티켓 기반 운영의 핵심은 "작업"과 "대화"를 분리하는 것입니다. 에이전트와의 대화는 실행 채널입니다. 티켓은 관리 채널입니다. 마블로에서는 오케스트레이터가 티켓을 만들고, 역할과 의존성을 보고 적절한 에이전트에 할당합니다. 에이전트는 티켓을 선점하고, 진행 상황을 활동 로그로 남기며, 검증 결과를 티켓에 붙여 REVIEW로 올립니다.

이 바인딩이 있으면 여러 가지 운영 문제가 단순해집니다. 한 에이전트가 실패하면 티켓은 사라지지 않습니다. 다른 에이전트가 같은 티켓을 이어받을 수 있습니다. 요구사항이 바뀌면 채팅창 어딘가의 문장을 고치는 대신 티켓의 새 활동으로 결정이 남습니다. 작업이 길어지면 티켓을 더 작은 티켓으로 나눌 수 있습니다. 범위를 벗어난 변경이 생기면 리뷰에서 티켓의 원래 범위와 비교할 수 있습니다.

또한 에이전트의 강점을 반영할 수 있습니다. 프론트엔드 컴포넌트 구현은 UI 맥락을 잘 읽는 에이전트에게, 타입·빌드 오류 정리는 빠르게 코드베이스를 훑는 에이전트에게, 회귀 테스트 설계는 검증 관점이 강한 에이전트에게 맡길 수 있습니다. 중요한 점은 모델 이름보다 티켓의 요구와 에이전트의 역할을 맞추는 것입니다. 티켓이 명확하면 어떤 에이전트가 가장 적합한지도 더 잘 보입니다.

좋은 티켓의 구성

좋은 티켓은 에이전트가 독립적으로 움직일 만큼 구체적이지만, 불필요하게 구현을 잠그지는 않습니다. "버튼 색을 파랗게 바꿔라"처럼 너무 작은 지시만 있으면 에이전트가 주변 맥락을 판단하기 어렵습니다. 반대로 "온보딩을 개선하라"처럼 큰 목표만 있으면 범위가 흐려집니다. 좋은 티켓은 목표와 경계를 함께 둡니다.

예를 들어 프론트엔드 티켓이라면 다음 요소가 유용합니다. 어떤 사용자가 어떤 화면에서 어떤 문제를 겪는지, 수정 가능한 컴포넌트와 수정 금지 영역은 어디인지, 상태 관리는 기존 스토어를 따라야 하는지, 반응형·다크 모드·접근성 기준은 무엇인지, 검증은 빌드인지 스크린샷인지 수동 동작 확인인지 적습니다. 백엔드 티켓이라면 데이터 모델, 마이그레이션 여부, API 호환성, 실패 시 롤백 기준이 필요합니다.

티켓이 길어지는 것이 항상 나쁜 것은 아닙니다. 여러 에이전트가 병렬로 움직이는 환경에서는 오히려 짧고 모호한 티켓이 더 비쌉니다. 다만 티켓은 문서가 아니라 실행 단위이므로, 읽는 사람이 바로 행동을 시작할 수 있어야 합니다. 배경 설명은 필요한 만큼만 두고, 완료 기준은 체크 가능한 문장으로 쓰는 편이 좋습니다.

활동 로그는 왜 필요한가

에이전트가 작업하는 동안 모든 판단이 코드 diff에만 남지는 않습니다. 어떤 접근을 시도했지만 버렸는지, 테스트가 왜 실패했는지, PM 피드백을 어떻게 반영했는지, 범위를 벗어난 요청을 왜 보류했는지는 diff만으로 알기 어렵습니다. 활동 로그는 이 중간 판단을 티켓에 붙입니다.

마블로의 활동 로그는 "작업 중"이라는 상태 표시보다 더 중요합니다. 다음 에이전트와 사람 리뷰어를 위한 압축된 인수인계입니다. 좋은 활동 로그는 짧지만 구체적입니다. "구현 완료"보다 "설정 패널의 저장 흐름을 Zustand store에 연결했고, Electron main 프로세스는 건드리지 않음"이 낫습니다. "검증 완료"보다 "Node 22로 Next build 통과, wc -m 기준 ko/en 7000자 이상 확인"이 낫습니다.

활동 로그가 쌓이면 티켓은 작은 의사결정 로그가 됩니다. 나중에 문제가 생겼을 때 특정 변경이 왜 들어갔는지 되짚을 수 있고, 오케스트레이터가 병렬 작업의 충돌을 파악할 수 있습니다. 사람 팀의 스탠드업과 코드 리뷰 메모가 섞인 형태라고 생각하면 이해하기 쉽습니다.

리뷰 루프를 설계해야 한다

많은 자동화 도구가 "작업을 끝냈다"는 신호를 너무 빨리 DONE으로 취급합니다. 하지만 에이전트 군단 운영에서 핵심은 리뷰 루프입니다. 에이전트는 구현하고 검증할 수 있지만, 제품의 방향과 위험 감수는 사람이 판단해야 합니다. REVIEW는 이 판단을 공식적으로 모으는 단계입니다.

리뷰 루프는 단순해야 합니다. 에이전트가 작업을 마치면 변경 요약과 검증 결과를 남기고 REVIEW로 제출합니다. 사람은 티켓의 완료 기준과 실제 diff를 비교합니다. 문제가 없으면 DONE으로 보냅니다. 수정이 필요하면 같은 티켓을 다시 IN_PROGRESS로 돌리거나, 더 작은 후속 티켓을 만듭니다. 이때 "무엇이 부족했는지"가 활동 로그에 남아야 다음 에이전트가 같은 실수를 반복하지 않습니다.

리뷰에서 확인할 것은 코드 스타일만이 아닙니다. 요구 범위를 넘었는지, 공유 파일을 불필요하게 건드렸는지, 검증이 실제로 완료 기준을 덮는지, 사용자에게 보이는 문구가 제품 사실과 맞는지, 접근성과 반응형이 깨지지 않는지도 봐야 합니다. 특히 여러 에이전트가 동시에 작업할 때는 서로의 변경을 덮어쓰지 않았는지 확인하는 절차가 중요합니다.

병렬 작업에서 충돌을 줄이는 법

티켓과 보드는 병렬 작업을 가능하게 하지만, 아무렇게나 병렬화해도 된다는 뜻은 아닙니다. 병렬성은 의존성 관리와 함께 있을 때만 생산성이 됩니다. 같은 파일을 두 에이전트가 동시에 고치거나, 데이터 모델 변경이 끝나기 전에 UI가 가짜 가정으로 구현되면 나중에 합치는 비용이 커집니다.

좋은 오케스트레이션은 티켓을 만들 때 충돌 가능성을 먼저 봅니다. 독립적인 화면, 독립적인 문서, 테스트 보강처럼 서로 영향을 거의 주지 않는 일은 병렬로 보냅니다. 공유 타입, 라우팅, 빌드 설정, 인증 흐름처럼 영향 범위가 넓은 일은 먼저 완료하거나 한 에이전트에게 집중시킵니다. 의존성이 있는 경우에는 선행 티켓이 DONE 또는 최소한 REVIEW에 도달한 뒤 후속 티켓을 시작하는 편이 안전합니다.

또한 범위 제한이 중요합니다. "이 티켓에서는 메인 프로세스를 수정하지 말 것", "page.tsx 같은 공유 라우트 파일은 건드리지 말 것", "frontmatter는 보존할 것" 같은 제약은 에이전트에게 매우 유용합니다. 사람 개발자에게는 당연해 보이는 경계도 에이전트에게는 명시해야 합니다. 경계가 명확할수록 리뷰 비용이 줄고, 여러 에이전트의 변경을 합치기 쉬워집니다.

검증을 티켓의 일부로 넣기

검증은 작업이 끝난 뒤 생각하는 부가 단계가 아닙니다. 티켓을 만들 때부터 검증 방법을 포함해야 합니다. "빌드 통과", "타입 체크 통과", "wc -m 7000자 이상", "정적 렌더 확인", "모바일 폭에서 텍스트 겹침 없음"처럼 구체적인 기준이 있으면 에이전트가 스스로 결과를 점검할 수 있습니다.

검증 기준은 작업 성격에 맞아야 합니다. 문서 작업이라면 글자 수, MDX 컴파일, 링크 유효성, 제품 사실 확인이 중요합니다. UI 작업이라면 스크린샷, 접근성, 반응형, 상태 전이가 중요합니다. 데이터 작업이라면 마이그레이션, 롤백, 기존 API 호환성이 중요합니다. "테스트하라"는 말만으로는 부족합니다. 어떤 실패를 잡고 싶은지 적어야 합니다.

마블로에서 티켓 활동 로그에 검증 결과를 남기는 이유도 여기에 있습니다. 리뷰어는 에이전트가 어떤 명령을 실행했는지, 어떤 기준을 확인했는지, 무엇을 확인하지 못했는지 빠르게 볼 수 있습니다. 검증하지 못한 항목을 솔직히 남기는 것도 중요합니다. 자동화된 확인이 불가능한 부분은 사람 리뷰의 체크리스트가 됩니다.

사람의 역할은 줄어드는 것이 아니라 바뀐다

티켓과 칸반으로 에이전트를 관리한다는 말은 사람이 빠진다는 뜻이 아닙니다. 오히려 사람의 역할은 더 선명해집니다. 사람은 모든 파일을 직접 고치는 대신, 목표를 쪼개고, 경계를 정하고, 우선순위를 판단하고, 결과를 받아들일지 결정합니다. 이는 개발자라기보다 작은 엔지니어링 팀의 리드에 가까운 역할입니다.

좋은 오케스트레이터는 에이전트에게 너무 많은 자유를 주지도 않고, 너무 작은 지시로 묶지도 않습니다. 티켓의 완료 기준은 분명히 하되, 구현 방식은 코드베이스의 패턴을 읽어 결정하게 둡니다. 중간에 막히면 새 지시를 흩뿌리는 대신 티켓 활동에 결정을 남깁니다. 리뷰에서는 취향보다 위험과 요구사항을 먼저 봅니다.

이 방식은 처음에는 느려 보일 수 있습니다. 티켓을 쓰고, 상태를 옮기고, 활동을 남기는 일이 추가되기 때문입니다. 하지만 에이전트 수가 늘어날수록 이 구조가 속도를 만듭니다. 매번 채팅 로그를 다시 읽지 않아도 되고, 누가 무엇을 했는지 찾지 않아도 되며, 리뷰 대기 중인 결과물을 한곳에서 처리할 수 있습니다.

마블로에서의 운영 원칙

마블로는 여러 AI 코딩 에이전트를 하나의 워크스페이스에서 동시에 오케스트레이션하는 데스크톱 앱입니다. 티켓은 작업의 단위이고, 칸반 보드는 상태의 단위이며, 활동 로그는 판단의 단위입니다. 이 세 가지가 결합될 때 에이전트 군단은 통제 가능한 시스템이 됩니다.

실무적으로는 다음 원칙이 도움이 됩니다. 큰 목표는 반드시 티켓으로 쪼갭니다. 각 티켓에는 결과물, 범위, 완료 기준, 검증 방법을 넣습니다. 에이전트는 한 번에 하나의 티켓을 맡습니다. 작업 중간에는 활동 로그로 진행과 판단을 남깁니다. REVIEW는 사람이 처리하고, DONE은 사람이 받아들인 뒤에만 사용합니다. 막힌 일은 숨기지 않고 BLOCKED나 후속 티켓으로 드러냅니다.

이 원칙은 에이전트를 믿지 않는 방식이 아닙니다. 오히려 에이전트가 더 많은 일을 맡을 수 있게 만드는 기반입니다. 업무가 티켓으로 정리되어 있고, 상태가 보드에 보이고, 판단이 로그에 남으면 사람은 더 큰 단위의 일을 병렬로 맡길 수 있습니다. AI 에이전트 군단을 지휘한다는 것은 결국 자동화와 통제 사이의 균형을 설계하는 일입니다.

티켓과 칸반은 그 균형의 가장 현실적인 출발점입니다. 복잡한 프로젝트일수록 "누가 무엇을 어디까지 했는가"라는 질문에 즉시 답할 수 있어야 합니다. 마블로는 그 답을 보드 위에 올리고, 각 티켓에 맥락을 남기며, 사람의 리뷰를 흐름의 중심에 둡니다. 그래서 많은 에이전트를 동시에 움직여도 작업은 흩어지지 않고, 하나의 제품 결정 과정으로 수렴합니다.