이전에는 계획을 키보드로 다시 입력해야 했습니다. 한 선임 엔지니어는 600단어 분량의 명세서로 티켓을 설명했고, 팀은 20분 회의를 통해 이를 분류(triage)했으며, 그 후 코드가 존재하기도 전에 누군가 이 대략적인 형태를 편집기(editor)에 다시 키보드로 입력해야 했습니다. Atlassian의 새로운 Jira용 AI 스위트는 이러한 인계 과정을 하나의 루프(loop)로 압축합니다: 티켓 → 명세서(spec) → 풀 리퀘스트(pull request)이며, 에이전트가 재입력 작업을 수행합니다. 이는 정말 큰 개선점이며, 다른 어떤 것보다 먼저 언급할 가치가 있습니다.
[[DIAGRAM: Jira 작업 항목을 코딩 에이전트(Claude Code, Cursor 또는 Copilot)에 할당 → 에이전트가 티켓을 가져와 내장된 Jira Coding Agent를 통해 PR 생성 → Jira Planner가 Jira + Confluence 기록을 끌어와 Confluence에 명세서 초안 작성 → Slack의 @Jira에서 스레드로부터 작업 항목 파일링 → 상태가 검토 및 분류(triage)를 위해 Jira로 동기화]]

Atlassian은 한 번의 업데이트로 네 가지 기능을 출시했으며, 이들은 깔끔하게 결합됩니다. 각 기능은 그 자체로 이해할 가치가 있습니다.

네 가지 구성 요소와 각각이 실제로 하는 일

코딩 에이전트 인계(Coding-agent handoff). Jira 작업 항목을 이제 Claude Code, Cursor 또는 GitHub Copilot에 직접 할당할 수 있습니다. OpenAI의 Codex 통합은 로드맵에 올라있습니다. 티켓이 프롬프트가 되고, 에이전트가 담당자가 됩니다. 이슈 트래커와 편집기 간의 복사-붙여넣기가 필요 없습니다.

내장 Jira 코딩 에이전트(built-in Jira Coding Agent). 모든 유료 Jira 플랜에서 사용할 수 있으며, 누군가 로컬 클론을 설정할 필요 없이 작업 항목을 풀 리퀘스트로 변환합니다. 루틴한 잡무—플래그 업데이트, 상수 교체, 피처(fixture) 재생성 등—가 이 에이전트의 전체 업무입니다. 노트북을 열어둘 필요조차 없습니다.

Jira Planner. Jira와 Confluence에서 기록된 데이터를 가져와 Confluence에 기술 명세서 초안을 작성합니다. Planner는 가장 주의 깊게 지켜볼 만한 부분입니다: 이 기능의 입력값—수개월 동안 승인된 티켓, 해결된 토론 내용, 이전 명세서—은 인간 PM(Product Manager)이 일주일 동안 모아야 할 입력값과 같습니다.

Slack에서 @Jira를 이용한 티켓 등록. Slack 스레드에 @Jira 태그를 달면 해당 대화 내용이 컨텍스트로 포함된 작업 항목(work item)이 자동으로 등록됩니다. 이는 모든 Slack 채널에 이미 존재하는

솔직히 말해서: PR(Pull Request) 사이클 시간의 최소 36% 감소는 에디터와 티켓 간 왕복 횟수가 줄어든다는 것을 의미하며, 이는 이 스위트가 압축하도록 설계된 정확한 부분입니다. 작업 완료 효율성에서 44% 증가라는 수치는 '작업(task)'에 대한 정의 없이는 설명하기 어렵습니다. 이 숫자는 신중하게 다루어야 합니다.

오늘 실제로 사용하는 방법

설정은 간단합니다. 유료 Jira 플랜을 사용한다면:

# 1. 관리자 패널에서 Jira Coding Agent 활성화
#    설정(Settings) → 앱(Apps) → AI 기능(AI features) → Jira Coding Agent 활성화.
#
...

Planner 측의 경로는 클릭 기반이라기보다는 데이터 형태를 띱니다:

# 프로젝트에 과거 Jira 이슈와 연결된 Confluence 페이지가 있는지 확인합니다. Planner는 둘 다 가져옵니다. 빈 프로젝트는 일반적인 초안을 얻고, 역사가 있는 프로젝트는 정교한 초안을 얻습니다.
#...

Slack 파일링은 가장 작은 단계입니다:

# 모든 Slack 채널에서: /invite @Jira
# 그런 다음 스레드에서: @Jira 이 내용을 버그로 파일합니다. 결제(payments)가 두 번 재시도됩니다.
# 인용된 대화 내용이 컨텍스트로 포함된 작업 항목이 생성됩니다.

각 기능을 활성화할 때 주의해야 할 두 가지 사항이 있습니다. 첫째, PR 개수가 아니라 PR 품질입니다. 엉성한 PR을 여는 빠른 에이전트는 더 빠른 팀이 아니라 더 빠른 백로그를 의미합니다. 둘째, 에이전트가 PR을 여는 위치입니다. 오래된 구성 요소나 이름이 변경된 파일에 대한 PR은 '빠른 루프, 잘못된 목표(fast loop, wrong target)' 실패 모드입니다. 대시보드에는 속도가 표시되지만 실제 작업은 배포되지 않습니다.

다음 단계와 곧 출시될 기능들

Codex 통합이 예정되어 있습니다. 이것이 도착하면 Jira 티켓 뒤에 있는 에이전트 선택기가 세 가지 옵션 드롭다운 메뉴가 아니라 실제 메뉴가 됩니다. 그 외에도 아키텍처는 명확한 다음 움직임을 유도합니다: 자체 검토자를 선택하는 에이전트, 사양이 확립된 ADR(Architecture Decision Record)와 모순되는 경우 플래그를 지정하는 Planner, 대화에서 참조된 실패 테스트를 포함하는 Slack 핸드오프 등이 있습니다. Atlassian은 이들 중 어느 것의 날짜도 명시하지 않았습니다. 이것들을 제공 시점이라기보다는 방향성으로 간주하십시오.

에이전트가 작동해도 변하지 않는 부분

Jira 스토리란 근본적으로 작업이 존재하는 장소에 대한 이야기입니다. 이전에는 에디터에 존재했지만, 이제는 티켓에 존재하며 에디터가 다운스트림 소비자 역할을 합니다. 이러한 변화는 긍정적이지만, 에이전트가 배포되는 표면(surface)들에 더 많은 압박을 가합니다. 오래된 컴포넌트에 대해 열리는 PR, 더 이상 존재하지 않는 버튼을 언급하는 Confluence 사양서, 사용 중단된 플래그에 대해 PR을 트리거하는 Slack 티켓 등 이 모든 것이 '드리프트(drift)'라는 불일치성에 기여합니다. 빠르고 강력한 에이전트의 비용은 코드베이스 내 모든 불일치성이 가속화되어 발생하는 비용입니다.

바로 이곳에서 지속 가능한 레이어(durable layer)가 그 가치를 입증합니다. 웹, iOS, Android에서 동일한 컴포넌트—하나의 API, 하나의 시각적 계약(visual contract), 하나의 접근성 트리(accessibility tree)—는 매일 바뀌는 코딩 에이전트와 상관없이 움직이지 않는 부분입니다. Planner가 '결제 양식에 저장된 카드 섹션이 필요하다'고 작성하고 에이전트가 PR을 열 때, 그 PR은 팀이 실제로 자체 디자인 시스템에서 찾을 수 있는 컴포넌트에 적용되며, 세 번의 릴리스 전으로 벗어난 직접 제작(hand-rolled) 복사본에는 적용되지 않습니다. 기반 구조(substrate)가 안정적이기 때문에 도구 변경 비용이 저렴해집니다. 이것이야말로 모든 에이전트 교체, 모든 모델 업그레이드, 그리고 계획의 재구성에도 살아남는 워크플로우의 부분입니다.

새로운 Jira AI 스위트를 사용하십시오. 이는 실제적인 DX(Developer Experience) 작업이며 컨텍스트 전환 비용을 의미 있게 줄여줍니다. 이것과 함께 결합할 가치가 있는 것은 바로 그 아래에 깔린 지속 가능한 레이어입니다.