현장에서 AI 도입이 막히는 지점은 모델 성능이 아니다. 누가 무엇을 맡았는지 모르는 순간이다. 사람은 Jira를 보고, 에이전트는 GitHub나 IDE에서 돌고, 결과물은 PR·문서·채팅 로그로 흩어진다. 관리자는 상태를 묻고, 담당자는 “에이전트가 작업 중”이라고 답한다. 그 말은 운영 언어가 아니다.
GitHub는 2026년 6월 Copilot for Jira를 GA로 내며 Jira 이슈에서 coding agent 진행 상태를 보고, 후속 지시를 같은 티켓에서 이어가게 했다. Atlassian도 Jira work item에서 Rovo agent와 third-party AI agent를 함께 배정하는 흐름을 공식화했다. 시장은 이미 “사람 보드”에서 “사람+에이전트 보드”로 이동했다. 문제는 툴 기능이 아니라 운영 모델이다. (github.blog)
티켓의 주체를 먼저 나눠야 한다
AI-Native work allocation board의 출발점은 간단하다. backlog를 하나로 유지하되 티켓의 실행 주체를 명시한다.
| 티켓 유형 | 맡길 일 | 필수 조건 | 책임자 |
|---|---|---|---|
| 사람 티켓 | 이해관계 조율, 예외 판단, 승인 | 의사결정 기준 | 담당자 |
| 에이전트 티켓 | 반복 구현, 문서 보강, 테스트 보완, 정리 | 충분한 context, 접근 권한, 검증 기준 | 사람 sponsor |
| 하이브리드 티켓 | 초안은 AI, 판단은 사람 | handoff 지점, review 기준 | 사람 owner |
여기서 핵심은 에이전트를 담당자로 보지 않는 것이다. 에이전트는 실행 주체다. 책임 주체는 사람이다. GitHub Copilot coding agent도 이슈를 배정받아 draft PR을 만들고 review를 요청하는 구조로 설명된다. 끝은 사람이 검토한다. (github.blog)
에이전트 티켓은 자동화 항목이 아니라, 사람이 책임지는 위임 항목이다.
보드에는 작업이 아니라 조건이 흘러야 한다
기존 backlog는 “할 일” 중심이다. AI-native board는 “맡겨도 되는 조건”을 같이 본다. 같은 버그 수정이라도 재현 경로와 테스트 기준이 있으면 에이전트 티켓이다. 고객 정책 해석이 필요하면 사람 티켓이다. 초안 생성 후 법무·품질 판단이 필요하면 하이브리드 티켓이다.
그래서 티켓에는 최소한 네 가지 필드가 들어간다.
- Execution type: human, agent, hybrid
- Context pack: 문서, 코드, 정책, 과거 티켓, 금지 조건
- Tool boundary: 읽기·쓰기 권한, 호출 가능한 MCP·API·저장소
- Review gate: 사람이 확인할 산출물과 통과 기준
Anthropic은 장기 실행 agent를 단순 프롬프트가 아니라 harness 문제로 다룬다. 초기 환경을 세팅하는 initializer, 다음 세션을 위한 명확한 artifact, incremental progress 같은 설계가 필요하다고 설명한다. work allocation board도 같은 원리다. 티켓이 곧 작은 harness가 된다. (anthropic.com)
하이브리드 티켓이 운영 성숙도를 가른다
많은 조직은 처음에 에이전트 티켓을 과하게 만든다. “AI에게 맡긴다”는 말이 “사람이 빠진다”는 뜻으로 오해된다. 실제 운영에서는 하이브리드 티켓이 더 많다.
하이브리드 티켓은 세 부분으로 쪼갠다. 에이전트가 조사·초안·수정안을 만든다. 사람이 판단·우선순위·승인을 한다. 다시 에이전트가 반영·정리·테스트를 한다. 이 흐름이 보드에 남아야 한다.
MCP의 2025년 11월 stable specification은 AI application이 외부 도구와 데이터를 연결하는 공통 방식을 다룬다. Anthropic은 2025년 12월 MCP를 Agentic AI Foundation에 기부했다. 연결 표준이 빨라질수록 조직의 병목은 더 기술 밖으로 이동한다. 어떤 agent가 어떤 권한으로 어느 티켓을 처리했는지 남기는 운영 설계가 핵심이다. (modelcontextprotocol.io)
참고
AI-Native work allocation board는 새 툴 이름이 아니다. 사람의 backlog에 AI 실행 단위를 억지로 끼워 넣는 것도 아니다. 같은 backlog 안에서 실행 주체, 위임 조건, 검토 책임을 분리하는 운영 체계다.
이 보드가 있어야 중간관리자는 일을 다시 배분할 수 있다. 현장 리더는 에이전트가 멈춘 이유를 볼 수 있다. 임원은 AI 사용량이 아니라 운영 전환 상태를 본다.
- GitHub, 2026, “GitHub Copilot for Jira is now generally available” — https://github.blog/changelog/2026-06-24-github-copilot-for-jira-is-now-generally-available/
- Atlassian Support, 2026, “Collaborate on work items with AI agents” — https://support.atlassian.com/jira-software-cloud/docs/collaborate-on-work-items-with-ai-agents/
- Anthropic Engineering, 2025, “Effective harnesses for long-running agents” — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
- Model Context Protocol, 2025, “Specification 2025-11-25” — https://modelcontextprotocol.io/specification/2025-11-25/basic
- Microsoft WorkLab, 2026, “Work Trend Index: Agents, human agency, and opportunity” — https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization
AX Ops는 이 보드를 파일럿 산출물이 아니라 운영 리듬으로 설계한다. 다음 단계는 티켓 분류표가 아니라 실제 backlog 전환이다. AX Ops 방법론 →