사람을 위해 작성된 작업은 세 단어면 충분합니다. "로그인 버그 고쳐"라고만 적어도 상대가 무슨 뜻인지 되물어 줄 테니 통합니다. 하지만 에이전트를 위해 작성된 작업은 그런 대화에 기댈 수 없고, 그 차이는 낭비된 실행, 아무도 검토하지 않는 결과물, 그리고 상태 컬럼이 더 이상 사람들이 생각하는 의미를 갖지 못하는 보드로 나타납니다.
AI 에이전트 작업 관리는 에이전트가 실행하고 사람이 승인하는 업무를 작성하고, 할당하고, 종료하는 규율입니다. 이 가이드는 그것이 제대로 굴러가느냐를 좌우하는 세 가지를 다룹니다. 에이전트가 바로 처리할 수 있는 작업에는 무엇이 담겨야 하는지, 할당이 사람과 에이전트 사이에서 어떻게 나뉘는지, 그리고 실행이 개입된 뒤 상태와 검토가 실제로 어떻게 작동하는지입니다. 예시는 Sharkly가 이를 구현한 방식을 따르지만, 에이전트를 실행자로 취급하는 어떤 시스템에도 같은 규칙이 적용됩니다.
핵심 요약
에이전트가 바로 처리할 수 있는 작업은 결과, 범위, 맥락, 그리고 완료 여부를 어떻게 검토할지를 명시합니다. 할당에는 두 개의 자리가 있습니다. 사람은 책임을 맡고, 하나의 에이전트 또는 크루가 실행을 맡습니다. 상태 카테고리가 실행을 좌우하므로, 보류된 백로그 상태에서는 실행이 시작되지 않고, 그곳에서 벗어나면 실행이 시작될 수 있으며, 취소됨이나 중복 상태는 진행 중인 실행을 중단시키지만 완료됨은 그렇지 않습니다. 작업 상태와 에이전트 실행 상태는 별개이며, 검토는 나중에 하겠다는 마음가짐이 아니라 반드시 사람에게 도달해야 하는 명시적인 상태입니다.
에이전트가 바로 처리할 수 있는 작업에 담겨야 할 것
설명이 곧 인터페이스입니다. 에이전트가 여러분의 의도를 아는 방법은 설명과, 작업이 필드에 담고 있는 정보뿐입니다.
쓸모 있는 작업은 주제가 아니라 결과를 명시하고, 설명에는 새로운 사람이나 에이전트가 진행하는 데 필요한 내용을 덧붙입니다.
- 이 작업이 왜 중요한지;
- 무엇이 범위 안이고 무엇이 범위 밖인지;
- 관련 파일, 링크, 예시 또는 관찰된 동작;
- 제약 사항과 이미 내려진 결정;
- 완료 여부를 어떻게 검토할지.
마지막 항목은 나머지를 다 합친 것보다 더 많은 일을 합니다. 2분 만에 승인할 수 있는 결과와 처음부터 되짚어봐야 하는 결과를 가르는 지점입니다. 작게 시작하고 작업을 파악해 나가면서 다듬으세요. 작업 설명은 개선되어도 됩니다.
나머지는 필드가 담당합니다. 유형, 상태, 우선순위, 날짜, 레이블, 그리고 계획 맥락을 위한 프로젝트나 스프린트입니다. 에이전트를 위해 조립되는 실행에는 제목과 설명, 현재 상태와 우선순위, 스페이스와 스프린트 맥락, 실행을 트리거한 댓글을 포함한 최근 댓글, 에이전트의 지침과 스킬, 저장소, 환경, 실행 설정이 포함될 수 있습니다. 빈약한 설명은 좋은 모델로도 메울 수 없습니다.
할당: 하나가 아닌 두 개의 자리
에이전트 작업 관리에서 가장 흔한 설계 실수는 담당자 필드를 하나만 두는 것입니다.
둘을 분리해서 유지하세요. 사람은 책임을 위해 할당되며, 스페이스는 한 명 또는 여러 명을 허용할 수 있습니다. 에이전트나 크루는 실행 자리에 할당되며, 이 자리는 단일 선택으로 유지됩니다. 하나의 작업이 둘 다 가질 수 있고, 사람 집합을 바꿔도 실행자는 바뀌지 않으며, 에이전트를 할당해도 사람이 대체되지 않습니다.
이렇게 하면 어떤 작업도 봇이 소유하는 일이 없다는 게 장점입니다. 결과에 대한 결정이 필요할 때 붙어 있는 이름이 있습니다. 에이전트가 잘못했을 때 검토 대화에는 참여자가 있습니다. Claude Code 프로젝트 관리에 대한 저희 해설에서도 이슈부터 병합까지 단일 작업에서 같은 분리를 보여줍니다.
크루도 같은 실행 자리에 들어가며, 실행은 리더 우선입니다. 리더 에이전트가 시작해서 맥락을 읽고, 필요에 따라 멤버를 참여시킵니다. 잘 정의된 작업에는 에이전트 하나를 사용하고, 조율이 필요한 작업에는 크루를 사용하세요.
상태: 실행을 통제하는 부분
에이전트가 개입되면 상태는 장식이 아닙니다. 눈에 보이는 각 상태는 카테고리에 속하고, 그 카테고리가 시스템적 의미를 지닙니다.
| 상태 카테고리 | 의미 | 에이전트 실행에 미치는 영향 |
|---|---|---|
| 백로그 | 보류됨, 준비되지 않음 | 여기서 생성하거나 할당해도 실행이 시작되지 않음 |
| 미시작 | 준비됨, 시작되지 않음 | 백로그에서 여기로 이동하면 할당된 에이전트가 시작될 수 있음 |
| 시작됨 | 진행 중 | 실행이 진행됨; 여러 상태가 이 카테고리를 공유할 수 있음 |
| 완료됨 | 완료, 종료 상태 | 종료 상태이지만, 이미 진행 중인 실행을 취소하지는 않음 |
| 취소됨 | 계속하지 않음 | 해당 작업을 위해 시작된 실행을 중단시킴 |
| 중복 | 다른 곳에서 다뤄짐 | 해당 작업을 위해 시작된 실행을 중단시킴 |
두 가지 결과는 꼭 새겨둘 만합니다. 백로그는 실질적인 대기 공간입니다. 작업을 준비하고 에이전트를 붙여도, 작업을 옮기기 전까지는 아무 일도 일어나지 않습니다. 그리고 어떤 것을 완료로 표시하는 것은 그것을 중단시키는 것과 다르므로, 정말로 멈추고 싶은 실행은 취소하세요.
두 번째 규칙은 수명 주기 상태와 에이전트 작업 상태가 별개라는 점입니다. 작업은 시작됨 상태에 머물러 있으면서 에이전트가 작업 중이거나, 사람의 답변을 기다리거나, 사람의 검토를 기다리거나, 오류를 보고하고 있을 수 있습니다. 대기 중(queued), 디스패치됨(dispatched), 실행 중(running), 완료됨(completed), 실패(failed), 취소됨(canceled) 같은 실행 상태는 실행 진행 상황을 설명할 뿐이며 작업을 자동으로 이동시키지 않습니다. 둘을 혼동해서 읽는 것이 바로 보드는 건강해 보이는데 결과 세 개가 읽히지 않은 채 쌓여 있는 이유입니다.
검토: 인수인계를 명시적으로 만들기
에이전트는 실행을 두 가지 유용한 지점에서 끝냅니다. 결과를 내놓거나, 질문을 남기거나. 둘 다 사람에게 도달해야 합니다.
사람의 답변 대기, 검토 대기, 그리고 실패하거나 막힌 작업은 주의 신호입니다. 이들은 개인 큐로 흘러가며, Sharkly에서는 이것이 에이전트 인박스입니다. 여기서 책임자가 작업을 열고, 맥락에 맞게 답하고, 결과를 검토하고, 재시도하거나 작업을 재할당할지 결정할 수 있습니다.
댓글은 작업에 남는 지속적인 대화입니다. 새 맥락, 검토 결과, 결정 사항에 댓글을 사용하고, 안정적인 목표와 승인 기준은 설명에 남겨 두어 현재의 요구 사항을 쉽게 찾을 수 있게 하세요. 에이전트 담당자가 준비된 작업에 멤버가 댓글을 달면 또 다른 실행이 대기열에 들어갈 수 있으며, 그래서 검토 피드백이 두 번째 프로세스를 시작하는 게 아니라 작업을 이어가게 만듭니다. 멘션은 이를 바꿉니다. 사람을 멘션하거나 전체 멘션을 사용하는 것만으로는 에이전트 실행이 시작되지 않고, 담당자를 제외한 다른 대상을 멘션하는 댓글은 기본 실행을 억제합니다.
승인하기 전에 diff만 보지 말고 근거를 읽으세요. 실행 로그는 실행이 왜 대기열에 들어갔는지, 언제 시작하고 끝났는지, 도구 호출과 런타임 이벤트, 트리거 출처, 실패 세부 정보를 보여줍니다. 승인은 결과가 옳다고 사람이 결정하는 것이며, 어떤 실행 상태도 대신해 줄 수 없습니다. 이런 상태들을 손으로 조립하는 대신 서로 연결된 형태로 쓰고 싶다면 Sharkly를 다운로드하세요.
그대로 따라 쓸 만한 작업 템플릿
에이전트 작업을 잘 작성하는 팀은 대개 같은 뼈대로 수렴합니다. 스니펫에 넣어 두고 채우세요. 전체 과정에 3분쯤 걸리고, 낭비되는 실행 하나를 아낄 수 있습니다.
Outcome: <what is true when this is done>
Context:
- Why this matters now
- Observed behavior, with the exact error or reproduction steps
- Files, links, or examples that are relevant
Scope:
- In: <the change you want>
- Out: <adjacent work the agent should not touch>
Constraints:
- Decisions already made, conventions to follow, things not to change
Review:
- How completion will be checked, and by whom
범위 밖 항목은 가장 빠르게 제 몫을 합니다. 좁은 목표만 주고 경계를 주지 않은 에이전트는 요청하지도 않은 것들을 개선하는 경향이 있고, 그 개선 하나하나가 검토 시간을 잡아먹습니다. 건드리지 말아야 할 것을 명시하는 편이, 건드린 것을 검토하는 것보다 훨씬 저렴합니다.
피할 만한 다섯 가지 실수
- 담당자 필드가 하나뿐인 경우. 책임과 실행이 뒤섞여 소유권이 사라집니다.
- 완료된 실행을 완료된 결과로 착각하는 경우. 실행이 끝났다는 사실은 그 변경이 옳았는지에 대해 아무것도 말해주지 않습니다.
- 실패한 실행을 습관적으로 재시도하는 경우. 먼저 로그를 여세요. 비슷해 보이는 벤더 오류도 정반대의 해결책이 필요한 경우가 많습니다.
- 검토를 쌓아 두는 경우. 검토되지 않은 에이전트 결과는 병합되지 않은 풀 리퀘스트보다 빠르게 불어나는 부채입니다.
- 이미 다 아는 사람을 위해 작업을 작성하는 경우. 승인 기준이 머릿속에만 있다면 에이전트는 추측하고 있는 것입니다.
자주 묻는 질문
에이전트가 작업 상태를 바꿀 수 있나요? 제한된 범위 내에서 가능합니다. 작업 유형의 워크플로가 사용 가능한 상태를 제한하므로, 에이전트는 그 워크플로가 허용하는 상태만 선택할 수 있습니다.
실행이 진행 중일 때 댓글을 달면 어떻게 되나요? 조건에 맞는 댓글은 병렬 중복 실행을 시작하는 대신 다음 실행 주기를 위해 대기열에 들어갈 수 있고, 빠르게 이어지는 댓글은 하나로 합쳐져 중복 대기 실행이 생기지 않습니다.
에이전트 작업을 위해 별도의 작업 유형이 필요한가요? 대개는 필요하지 않습니다. 작업에 의미 있게 다른 필드 집합이나 워크플로가 필요할 때는 별도 유형을 쓰고, 가벼운 분류만 필요할 때는 레이블을 사용하세요.
일반적인 프로젝트 관리와 무엇이 다른가요? 기본 요소는 같지만 엄격함은 다릅니다. AI 에이전트 프로젝트 관리 가이드에서 실행자가 복도에서 명확히 하는 질문을 할 수 없을 때 각 기본 요소가 어떻게 달라지는지 다룹니다.
