예전의 백로그는 나와 몇몇 동료가 꺼내 쓰는 목록이었다. 맨 위 항목을 읽고, 이해하고, 처리하면 끝이었다. "누가 시간이 있나?"만 따지면 됐으니 트리아지도 금방이었다. 그런데 이제는 그중 일부 항목을 사람 대신 코딩 에이전트가 가져갈 수 있고, 평온하던 대기열은 작지만 값비싼 실수의 근원으로 바뀐다. 아무도 다 쓰지 않은 작업을 에이전트가 시작하고, 두 에이전트가 겹치는 작업을 동시에 집어가고, "완료" 칼럼에는 아무도 요청하지 않은 결과물이 쌓인다.
문제는 에이전트가 아니다. 사람을 위해 만들어진 백로그가 조용히 역할을 바꾼 것이다. 더 이상 할 일 목록이 아니라, 실행을 촉발할 수 있는 디스패치 큐가 되었다. 항목 하나가 실제 작업을 시작할 수 있게 되는 순간, 작업을 옮기는 행위와 담당자를 정하는 행위는 예전에는 없던 결과를 낳는다.
Sharkly가 자리 잡은 지점이 바로 이 층이다. 코딩 에이전트는 이미 가지고 있을 테고, Sharkly는 백로그에 공통된 의미를 부여해 그들을 하나의 팀으로 만든다. Task는 작업의 기본 단위이고, Backlog는 아직 커밋되지 않은 작업이 기다리는 곳이며, Triage는 들어온 항목이 누군가 결정을 내릴 때까지 머무는 전용 인테이크 큐다. 이 글에서는 사람과 에이전트가 섞인 백로그를 큐가 혼돈으로 변하지 않도록 트리아지하는 방법을 살펴보고, 오늘 바로 실행할 수 있는 체크리스트로 마무리한다.
에이전트가 작업을 처리할 수 있게 되면 백로그와 트리아지의 의미는 어떻게 달라질까
여기서는 두 가지 정의가 거의 모든 것을 좌우하니, 정확히 짚고 넘어가자.
백로그는 아직 커밋되지 않은 작업의 집합, 즉 존재하지만 아직 아무도 시작하기로 결정하지 않은 작업들이다. 트리아지는 새로 들어왔거나 불분명한 항목에 내리는 인테이크 결정으로, 수락하거나, 거절하거나, 중복으로 표시하거나, 나중으로 미루는 것이다. 사람은 늘 이 두 가지를 비공식적으로 해왔다. 달라진 점은 사람-에이전트 팀에서 트리아지의 결과에 "어떤 에이전트가 이걸 실행할까"가 포함된다는 것이고, 작업을 커밋하는 행위가 실행을 시작시킬 수 있다는 것이다.
가장 먼저 사람들을 넘어지게 하는 경계가 있다. Backlog에서 작업에 Agent를 배정해도 실행은 시작되지 않는다. Backlog는 실행 전에 작업을 준비하는 주차장이다. 실행은 작업이 Backlog를 떠나 작업 가능한 상태로 넘어가고, Computer와 Runtime이 확보되었을 때만 시작된다. 즉 "에이전트 배정"과 "에이전트 시작"은 별개의 두 사건이며, 그 사이에 백로그 상태가 게이트 역할을 하고 있다.
한 가지 경계는 분명히 짚고 넘어갈 만하다. 에이전트는 개인 백로그를 두지 않는다. Agent가 혼자 처리하는 숨은 큐 같은 건 없다. Agent가 손댈 모든 항목은 공유 보드에 존재하며, 그래서 트리아지가 추측이 아니라 가능한 일이 된다.
직접 구축한 방식이 확장을 멈추는 지점
스프레드시트에 칸반 보드, 터미널 몇 개면 한 사람과 에이전트 두 개까지는 잘 돌아간다. 하지만 예측 가능한 지점에서 확장이 멈추고, 그때마다 구체적인 실패로 드러난다.
상태 칼럼은 에이전트에게 아무 의미가 없다. 수동 보드에서 카드를 "In Progress"로 옮기는 건 동료에게 남기는 메모일 뿐, 아무것도 실행되지 않는다. 그래서 보드와 실제 작업은 서로 어긋난다. 카드는 "In Progress"라고 하는데 에이전트는 한 시간 전에 끝냈거나, 누군가 터미널에서 실행을 걸어둔 탓에 에이전트가 이미 커밋 세 개를 쌓았는데 카드는 "To Do"로 남아 있다. 아무도 보드를 믿지 않으니, 아무도 보드를 쓰지 않는다.
트리아지 결정이 한 사람의 머릿속에만 있다. 들어오는 요청을 받아내는 그 사람은 어떤 버그가 이미 보고되었는지, 어떤 기능이 지난 분기에 거절되었는지, 어떤 작업이 디자인 검토를 먼저 거쳐야 하는지를 기억한다. 그 사람이 자리를 비우면 중복이 생기고, 인테이크 단계에서 거절됐어야 할 작업을 에이전트가 시작한다. 큐에는 기억이 없다.
배정과 범위가 같은 급한 순간에 결정된다. 사람이 작업을 집어 들고 질문을 던질 때는 범위가 모호해도 견딜 만하다. 에이전트는 멈춰서 묻지 않는다. 주어진 대로 실행하고, 자신감 넘치는 잘못된 결과를 돌려준다. 빈약한 트리아지의 비용은 "동료가 잠깐 헷갈린다"에서 "에이전트가 엉뚱한 일에 실행 한 번과 리뷰 주기 하나를 태웠다"로 옮겨갔다.
사람과 에이전트가 섞인 백로그, 단계별 트리아지
사람-에이전트 백로그를 제대로 유지하는 순서는 이렇다. 각 단계마다 어떤 실패를 막는지 짚어본다.
1. 백로그를 건드리기 전에 인테이크 큐를 비운다. 새 요청은 백로그로 곧장 들어가지 않고 Triage에 도착한다. 각 항목을 네 가지 결정 중 하나로 처리한다. 수락, 거절, 중복 표시, 나중으로 미루기. Triage는 인테이크 큐이지 저장된 필터도, 폼 빌더도 아니다. 그래서 결정이 명시적으로 남고 기록된다. 막는 실패: 거절되거나 중복인 작업이 조용히 실제 태스크가 되어 나중에 에이전트가 집어가는 것.
2. 에이전트가 맡을 자격을 갖추기 전에 작업을 다듬는다. 수락된 항목은 Task가 되지만, 인수 기준을 쓰고 저장소를 연결하고 제약 조건을 적는 동안에는 Backlog에 그대로 남는다. 시간에 쫓길 때 사람들이 건너뛰는 단계다. 막는 실패: 한 줄짜리 제목만 보고 에이전트가 실행에 들어가, 문구에는 기술적으로 맞지만 의도는 놓친 결과물을 내놓는 것.
3. 담당자를 정하되, "어떤 에이전트"를 진짜 선택으로 다룬다. 사람이 해야 할 작업도 있다. 에이전트가 해야 할 작업도 있고, 에이전트 중에서도 무엇이 맞는지는 작업에 따라 다르다. 리팩터링, 테스트 작성, 문서 업데이트는 같은 일이 아니다. 놀고 있는 에이전트에게 습관처럼 맡기지 말고 의도적으로 라우팅한다. 코딩 에이전트 라우팅 가이드에서 그 판단을 어떻게 내리는지 다룬다. 막는 실패: 잘 맞지도 않는 작업을 엉뚱한 런타임이 붙들고 씨름하는 것.
4. 진짜 준비될 때까지 Backlog에 둔다. 여기가 게이트다. 작업은 담당자까지 다 지정된 상태로도 Backlog에 앉아 실행이 시작되지 않을 수 있다. 이걸 활용하자. 범위가 정해지고 실제로 작업을 시작하고 싶어지기 전까지는 꺼내지 않는다. 막는 실패: 누군가 칼럼을 잘못 끌어다 놓아서 절반만 쓰인 작업이 실행을 시작하는 것.
5. 커밋하고 실행을 시작하게 둔다. 작업을 준비 완료 상태로 옮기거나 Sprint로 끌어온다. 준비된 Agent가 달린 작업이 Backlog를 떠나고 Computer와 Runtime이 확보되면 실행이 시작된다. 이제 상태 변경과 작업 시작이 같은 사건이 된다. 바로 그게 핵심이다.
주기적으로 사이클을 돌리는 팀이라면, 사람-에이전트 팀을 위한 스프린트 계획 글에서 같은 커밋 단계가 단일 작업 대신 타임박스의 범위를 정하는 방식을 확인할 수 있다.
백로그 상태가 실행 게이트가 된다
사고의 전환은 이렇다. 사람만 쓰는 보드에서 상태는 현실을 서술하는 라벨이다. 사람-에이전트 보드에서 상태는 현실을 바꾸는 지렛대다. 작업을 Backlog 밖으로 옮기는 행위가 곧 에이전트를 시작시키는 행동이므로, 트리아지 규율이 이제는 안전장치가 된다.
이 게이트는 사람-에이전트 간 계약이 자리할 곳이기도 하다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고한다. 사람은 무엇이 백로그에 들어오고, 무엇이 커밋되고, 무엇이 출시되는지를 결정한다. 팀의 판단이 필요한 지점에서 자동화는 멈춘다. Plan 뷰는 Backlog, Sprints, Projects를 한곳에 모아 커밋 결정이 터미널에 묻히지 않고 눈에 보이게 하고, 실행과 블로커, 결과, 리뷰가 사적인 세션에 흩어지지 않고 모두 Task로 돌아오게 한다.
그래서 에이전트를 쓸 때 백로그 위생이 더 중요해지는 것이지, 덜 중요해지는 게 아니다. 사람만 쓰는 지저분한 백로그는 그냥 어수선한 목록이다. 에이전트가 있는 지저분한 백로그는 이따금 스스로 실행되는 어수선한 목록이다. 보드는 인테이크부터 릴리스까지 맥락, 소유권, 진행 상황, 결과, 사람의 리뷰를 눈에 보이게 유지한다. 그것이 당신이 관리하는 큐와 당신을 관리하는 큐의 차이다. 인테이크가 아니라 리뷰가 쌓인다면 그건 다른 병목이며, 사람 리뷰가 진짜 제약이라는 글에서 다룬다.
들어오는 양이 적다면 스프레드시트와 수동 규율로도 운영할 수 있다. 이미 꾸준히 요청이 들어오고 여러 에이전트를 돌리고 있다면, Sharkly가 Triage 큐와 Backlog 게이트, 하나의 공유 보드를 제공해 그런 결정들이 더 이상 머릿속에만 머물지 않게 해준다. 같은 워크플로를 더 넓게 보고 싶다면 AI 에이전트 작업 관리 가이드와 Triage와 개인 Inbox의 차이를 다룬 글을 참고하자.
오늘 바로 돌려볼 수 있는 트리아지 체크리스트
지금 쓰는 보드에 이걸 적용해 보자. "아니오"가 나오는 곳마다 에이전트가 당신을 놀라게 할 지점이다.
- 새 요청이 백로그 전에 어딘가에 먼저 도착하는가? 인테이크가 곧바로 "To Do"로 간다면 수락/거절/중복 단계가 없는 것이고, 중복은 피할 수 없다.
- 모든 백로그 작업의 범위가 낯선 사람에게 넘겨도 될 만큼 충분한가? 신입에게 맡기기에 부족하다면 에이전트에게도 부족하다.
- 작업을 옮기면 실제로 뭔가가 시작되는가? 상태 변경이 그저 라벨이라면 보드와 실제 작업은 어긋나게 된다.
- 배정이 진짜 결정인가, 어떤 에이전트인지까지 포함해서? 놀고 있는 에이전트로 기본값을 정하는 건 라우팅이 아니다.
- 지금 이 순간 각 에이전트가 무엇을 하고 있고 무엇이 리뷰를 기다리는지 말할 수 있는가? 그 답이 누군가의 기억이나 터미널 스크롤백에 있다면 트리아지에는 공유된 단일 진실 공급원이 없는 것이다.
- 끝난 작업이 사적인 세션이 아니라 작업으로 돌아오는가? 결과, 블로커, diff는 공유 기록에 남아야 리뷰가 뭔가를 가지고 움직일 수 있다.
에이전트 수를 늘리기 전에 처음 두 가지부터 고치자. 깔끔한 인테이크 단계와 솔직한 작업 범위만으로도 값비싼 실패 대부분을 막을 수 있다. 나머지는 이미 의미를 지닌 백로그 위에 얹는 다듬질일 뿐이다.
