에이전틱 엔지니어링에 Jira 활용
에이전틱 엔지니어링은 Jira에서 실행됩니다. 엔지니어링의 중심이 코드 작성에서 AI 에이전트 제어로 옮겨가면서 중요한 업무도 변화하고 있습니다 개발자는 이미 업무 시간의 약 16%만 코드 작성에 할애하고 있습니다. 에이전트가 빌드 작업을 더 많이 수행함에 따라 이제 어려운 업무는 에이전트에게 컨텍스트를 제공하고 오케스트레이션하고 산출물을 검토하고 관리하는 등 그 주변의 업무가 됩니다.
이것이 바로 Jira가 항상 관리해 온 업무이며, 이제는 에이전트까지 그 범위가 확장되었습니다. Jira와 Teamwork Graph는 이를 위한 기록 시스템이며 팀이 확장함에 따라 AI 활동을 실질적인 생산성 향상으로 전환하는 데 필요한 계층입니다.
이 가이드에서는 Jira가 에이전틱 엔지니어링을 지원하는 방법, Jira를 다른 도구와 함께 활용하는 방법 및 시작하는 방법을 다룹니다. 간단히 말해 Jira는 코딩 에이전트만으로는 제공할 수 없는 다음 세 가지를 제공합니다.
에이전트가 정확하게 작업할 수 있도록 올바른 컨텍스트 제공
일상적인 업무를 자동화된 권한 인식 흐름에 위임
Teamwork Graph 내에 책임 소재를 확인할 수 있는 기록 유지
에이전틱 엔지니어링이란 무엇입니까?
에이전틱 엔지니어링은 사용자가 모든 코드를 직접 작성하는 대신 목표를 설정하고 결과를 평가하며 여러 단계의 업무를 계획하고 실행하는 AI 에이전트에게 지시하여 소프트웨어를 만드는 방식입니다.
이에 따라 노력의 초점도 코드 작성에서 에이전트가 작업하는 시스템을 설계하는 것으로 바뀝니다. 무엇을 만들지 지정하고 에이전트에게 컨텍스트를 제공하며 에이전트가 작업하는 동안 방향을 조정하고 산출물이 기준을 충족하는지 결정합니다. AI 자동 완성이 다음 줄을 제안하는 수준이라면 하나의 에이전트는 설명된 결과를 바탕으로 풀리퀘스트까지 만들 수 있습니다. 에이전틱 엔지니어링은 그보다 상위의 계층으로, 여러 에이전트를 규모에 맞게 오케스트레이션하고 에이전트의 업무를 조정하며 제공 항목을 관리합니다.
따라서 에이전틱 엔지니어링은 단순한 코딩 분야가 아니라 조정과 판단이 이루어지는 분야입니다. 에이전트가 코딩 또는 작업 실행을 맡게 되면 에이전트의 액세스, 작업 및 산출물은 팀이 이미 신뢰하는 제어 범위 내에 있어야 합니다. 여기서 제기되는 질문은 코딩 관련 질문보다는 업무 관리 질문에 가까우며 그렇기 때문에 Jira와 같은 기록 시스템에 의존하게 됩니다.
Jira는 에이전틱 엔지니어링을 위해 구축되었습니까?
Jira는 AI 에이전트 전반의 업무를 계획, 오케스트레이션 및 확장하는 방식인 AI 네이티브 소프트웨어 개발을 위해 구축되었습니다. Jira가 에이전틱 엔지니어링을 '지원'하는지 묻는다면 질문의 핵심은 Jira가 에이전트 업무에 컨텍스트를 제공하고 해당 업무를 조정, 검토 및 관리하는 계층이 될 수 있는지 여부입니다. 바로 이것이 Jira의 역할이며 코딩 에이전트만으로는 할 수 없는 일입니다.
코딩 에이전트는 변경 사항을 작성할 수는 있지만 무엇을 빌드해야 할지 결정하거나 결과가 기준을 충족하는지 판단하거나 업무가 진행 중인 다른 모든 업무와 어떻게 연결되는지 파악할 수는 없습니다. 이것은 업무 관리 및 팀의 의사 결정입니다. 한 사용자의 컴퓨터에서 실행되는 코딩 에이전트는 해당 사용자만을 위해 작동하지만 사용자와 에이전트로 구성된 팀에는 공유된 조정, 가시성 및 단일 정보 출처가 필요합니다. Jira가 이 계층을 담당합니다. 계획을 유지하고 적절한 에이전트에게 업무를 라우팅하며 담당자가 제공 항목을 제어하도록 지원하고 발생한 상황을 지속적인 컨텍스트로 기록하여 향후 업무에 참고할 수 있도록 합니다. 이것은 개발자가 수행해야 하는 추가 단계가 아니라 업무가 Jira에서 진행되는 과정에서 이루어집니다.
코딩 에이전트만으로는 제공할 수 없는 Jira의 이점은 무엇입니까?
코딩 에이전트에게 실제 사양을 제공해도 여전히 방향을 벗어날 수 있습니다. 기존 결정을 잊어버리고 완료한 업무를 다시 수행하며 컨텍스트 창의 한계에 부딪힙니다. 이 문제는 계획을 Markdown 파일로 저장한다고 해서 해결되지는 않으며 성능이 더 좋은 에이전트를 사용한다고 해서 해결되는 것도 아닙니다. 해결 방법은 사양 및 상태를 에이전트의 메모리 외부에 유지하는 시스템입니다. 이 문제는 팀 전체에 누적되기 때문에 에이전틱 엔지니어링은 본질적으로 코딩 도구의 문제가 아니라 기록 시스템 선택의 문제입니다. Jira는 바로 그런 시스템이기 때문에 아래 기능을 제공할 수 있습니다.
커넥터는 도구 체인을 Teamwork Graph로 연동합니다. MCP는 팀이 이미 사용 중인 모든 AI에 이러한 조직 차원의 메모리를 푸시합니다.
사용자과 에이전트 업무 전반에 걸친 단일 기록 시스템입니다. 에이전트가 작업하는 동안 Teamwork Graph 전반에서 읽고 쓰며 작업과 관련된 모든 결정 및 기록을 업데이트하므로 로컬 세션에서 컨텍스트가 손실되지 않습니다.
거버넌스는 기존 엔터프라이즈 제어를 상속합니다. 에이전트 액세스는 엔터프라이즈가 이미 신뢰하는 권한 모델을 따르므로 기존 제어가 에이전트 업무에 자동으로 확장되며 관리해야 할 새로운 대상이 되지 않습니다.
어떤 에이전트든, 어떤 모델이든, 하나의 화면에 표시합니다. Claude, Cursor, Codex, GitHub Copilot 또는 네이티브 Jira 코딩 에이전트에 업무를 할당하고 한곳에서 오케스트레이션합니다. 에이전트가 기존 워크플로 내에서 업무를 수행하므로 에이전트가 변경되더라도 프로세스는 변경되지 않습니다. 단일 코딩 에이전트만 사용하면 하나의 공급업체에 종속되지만 Jira는 에이전트에 구애받지 않습니다.
단순히 티켓뿐만 아니라 전체 스택을 활용한 컨텍스트 엔지니어링입니다.Teamwork Graph는 에이전트가 Jira, Confluence, 코드 및 Slack과 Teams와 같이 실제로 업무를 논의하는 도구 전반의 업무 항목, 의사 결정 및 기록을 바탕으로 작동하도록 하므로 에이전트가 빈 프롬프트가 아닌 실제 의도에 따라 작업할 수 있습니다. 이를 통해 Jira는 에이전트를 위한 컨텍스트 계층이 됩니다.
에이전트 업무를 위한 단일 컨트롤 플레인을 제공합니다. 코딩 에이전트는 자체 세션에서 실행되며, 계획 및 팀의 다른 업무와 분리되어 있습니다. Jira는 개발자의 일상 업무에 별도로 단계를 추가할 필요 없이 에이전트가 처리할 작업을 결정하고 올바른 컨텍스트를 제공하며 각 코딩 세션을 그 결과물인 업무와 다시 연결하는 계층을 추가합니다. 기록 시스템이 발생한 일을 기록하는 반면 컨트롤 플레인은 백그라운드에서 에이전트 업무를 지시하고 연결하는 역할을 합니다.
AI 네이티브 소프트웨어 개발 수명 주기 전반에서 Jira의 역할
Jira는 계획, 오케스트레이션, 검토 및 확장의 4가지 단계에 걸쳐 에이전트 업무를 지원합니다. 업무를 에이전트가 처리할 수 있는 항목으로 계획하고 에이전트가 이것을 수행하도록 오케스트레이션하며 에이전트가 생성한 산출물을 검토 및 테스트하고 안전을 유지하는 거버넌스 및 권한을 통해 이 패턴을 조직 전체로 확장합니다. 각 단계에서 Jira가 수행하는 작업은 다음과 같습니다.
계획: 어떻게 업무를 에이전트가 처리할 수 있도록 준비합니까?
클릭 한 번으로 계획 및 설명서를 제안된 업무 항목으로 전환한 다음, 수락하기 전에 필요에 따라 검토하고 조정합니다.
계획은 의도를 에이전트가 처리할 수 있는 업무로 전환하는 단계로, 명확한 요구 사항과 수용 기준을 갖춘 실제 사양 및 에이전트가 시작하기 전에 필요한 컨텍스트가 여기에 포함됩니다.
업무가 어디서 시작하든 기록하세요. 요청은 Slack 스레드, Confluence 페이지, Loom 녹화, 미팅 등 어디서나 들어옵니다. @Jira를 멘션하거나 Rovo를 사용하여 해당 위치에서 바로 업무 항목으로 전환하세요. 입력은 단순히 다시 입력하는 수고만 덜어주는 것이 아니라 대화로 시작된 모호한 요청이라도 팀의 업무와 어떻게 연결되는지에 대한 Teamwork Graph의 컨텍스트를 담은 업무 항목으로 전환합니다.
에이전트에게 단순한 프롬프트가 아닌 명확하게 정의된 사양을 제공합니다. 사양 기반 개발에서 사양은 핵심 입력입니다. 에이전트는 세션 이후에 사라지는 일회성 프롬프트가 아니라 사양을 바탕으로 업무 항목을 처리합니다. 이 사양은 코드베이스, 팀 표준 및 프로젝트 기록과 함께 작동하므로 에이전트는 팀 표준에 맞는 코드를 작성하는 데 필요한 컨텍스트를 확보하게 됩니다. Jira Planner가 Teamwork Graph, 코드베이스 및 Confluence 기록을 사용하여 사양 초안을 작성한 후 사용자가 이것을 구체화하고 수용 기준을 추가하면 이 사양은 에이전트가 빌드 및 검토에 사용하는 기준이 됩니다.
에이전트에게 축적되는 컨텍스트를 제공합니다. 컨텍스트는 에이전트 품질을 좌우하는 실질적인 제약 조건입니다. Jira는 Teamwork Graph를 활용하여 에이전트가 단순히 티켓뿐만 아니라 여러 도구에 걸친 목표, 의사 결정 및 기록을 기반으로 작업하도록 지원합니다. 모든 MCP 에이전트와 함께 작동하며 컨텍스트는 계속 축적됩니다. 시스템을 통해 실행하는 업무가 많아질수록 에이전트가 활용할 수 있는 컨텍스트도 늘어나 결과가 더 향상됩니다.
오케스트레이션: 에이전트에게 업무를 어떻게 할당하고 지시합니까?
한곳에서 네이티브 Jira 코딩 에이전트등의 에이전트에게 업무를 할당합니다.
팀이 이미 업무를 추적 중인 곳에서 가장 적합한 에이전트에게 업무를 할당한 다음 해당 에이전트가 수행하는 작업을 지시하고 감독할 수 있습니다.
한곳에서 모든 에이전트에게 업무를 할당합니다. Claude, Cursor, Codex, GitHub Copilot 또는 네이티브 Jira 코딩 에이전트에 업무 항목을 할당한 다음 웹, IDE 및 터미널 세션 전반에서 에이전트가 수행한 작업과 내린 결정을 확인하여 흐름을 끊지 않고도 에이전트의 방향 이탈을 조기에 파악하고 수정할 수 있습니다.
이미 작업하고 있는 곳에서 에이전트를 활용합니다. 팀이 사용하는 환경을 통해 오케스트레이션합니다. Slack에서 @Jira를 멘션하여 업무 항목을 만들고 수정 루프를 시작하거나, Cursor, Claude Desktop 또는 MCP 클라이언트를 Jira 컨텍스트에 연결하거나, 에이전트에게 CLI/터미널 액세스 권한을 부여하여 컨텍스트를 작업으로 전환할 수 있습니다.
일상적인 업무를 자동화합니다.자동화 규칙 또는 워크플로 전환을 통해 에이전트를 트리거하거나 보드 열에 에이전트를 추가하면 상태가 변경됨에 따라 에이전트가 자동으로 업무를 수행하고 동일한 워크플로를 통해 산출물을 다시 라우팅합니다. 일상적이고 반복적인 업무부터 시작하는 것이 가장 좋습니다.
에이전트 활동을 업무와 연결하여 가시성을 유지합니다. 에이전트가 업무를 수행하는 동안 해당 활동과 에이전트가 연 풀리퀘스트가 업무 항목에 연결된 상태를 유지하여 진행률이 별도의 도구에 묻히지 않고 업무가 진행되는 곳에 표시됩니다. 각 에이전트가 맡은 업무 항목, 생성한 산출물 및 검토 대기 중인 항목을 모두 한곳에서 볼 수 있습니다.
검토: 에이전트 산출물의 유효성을 어떻게 검사합니까?
에이전트 산출물 검토에는 사람이 개입하는 단계를 포함해야 합니다.
에이전트 산출물은 완성된 것처럼 보여도 여전히 오류가 있을 수 있으므로 담당자가 검토하고 테스트하여 승인하기 전에는 제공해서는 안 됩니다.
테스트 및 유효성 검사를 수행합니다. 에이전트 산출물도 일반적인 검사를 통과해야 합니다. 이 검사는 CI 파이프라인에서 실행되고 그 상태가 업무 항목에 표시되므로 업무가 확인되기 전까지 검토 단계에서 완료로 전환하는 것을 보류할 수 있습니다. 에이전트가 자체 산출물을 검사하고 모든 검사를 통과할 때까지 계속 반복한 후 사용자에게 전달하는 방식으로 이 과정 일부를 자동화할 수 있습니다.
사람이 개입하는 검토를 워크플로에 통합합니다. 사람이 주도하는 검토를 필수로 설정하세요. 산출물이 업무 항목에 표시되며 담당자가 승인할 때까지 완료로 전환할 수 없습니다. 풀리퀘스트와 검토 상태가 업무 항목의 개발 패널에 표시되므로 업무를 추적한 위치에서 바로 검토할 수 있습니다.
제공한 내용을 병합하고 기록합니다. 검토를 통과하면 변경 사항이 병합되고 업무 항목이 완료 상태로 전환됩니다. 연결된 도구에서 병합 및 배포가 실행되며 Jira에 기록이 유지됩니다.
확장: 시간이 지남에 따라 여러 팀에 걸쳐 에이전트를 안전하게 운영하려면 어떻게 해야 합니까?
단일 System of Work는 조직 전체로 확장할 때 더 큰 성공으로 이어집니다.
에이전트 업무를 확장하는 것은 조직 수준의 변화입니다. 도전 과제는 한 개발자가 더 많은 에이전트를 실행하는 것이 아니라 에이전트 업무가 여러 팀으로 확산되더라도 품질, 신뢰 및 가시성을 안정적으로 유지하는 것입니다.
일상적인 업무를 위임합니다. 에이전트는 백그라운드에서 범위가 명확한 반복 업무를 처리하고 준비가 완료되면 풀리퀘스트가 표시됩니다. 사용자는 공유 권한 및 보안 표준을 통해 계속 제어할 수 있습니다.
반복합니다. 에이전틱 엔지니어링은 일방향 프로세스가 아니라 반복되는 루프입니다. 결과는 다음 사양에 입력되며 업무는 수명 주기로 다시 들어갑니다. Jira는 피드백을 캡처하여 향후 업무를 개선하는 곳입니다.
거버넌스 및 감사를 수행합니다. 가드레일은 정책 문서가 아니라 워크플로에 적용되며 모든 작업은 Jira의 자체 권한으로 제어되는 감사 가능한 기록을 업무 항목에 남깁니다.
영향을 측정합니다. 사이클 타임 및 풀리퀘스트 처리량과 같은 제공 데이터를 사용하여 AI를 통해 팀의 제공 방식이 어떻게 변화하고 있는지 추적하면 활동보다는 성과를 측정하고 중요한 곳에 투자할 수 있습니다.
Jira는 나머지 AI 스택과 어떻게 함께 작동합니까?
Jira는 코딩 에이전트, IDE 또는 사용자가 실행하는 모델을 대체하지 않습니다. Jira는 이 도구를 아우르는 조정 및 기록 계층이므로 어떤 도구로 구축하든 관계없이 업무를 계속 확인하고 관리할 수 있습니다. 이 계층은 규모가 커질수록 선택 사항이 아닙니다. 공유 기록 시스템이 없으면 에이전트 업무가 여러 도구로 파편화되어 생산성을 온전히 발휘할 수 없습니다.
토픽 | Jira가 수행하는 작업(조정 및 기록 계층) | Jira가 수행하지 않는 작업(스택의 다른 곳에서 처리) |
계획 | 에이전트를 위한 업무 계획, 세분화 및 우선순위 지정(Jira Planner) | 목표 설정(담당자가 무엇을 왜 할지 결정하며 Jira는 이것을 계획으로 전환) |
컨텍스트 | 에이전트가 업무 항목 및 Teamwork Graph의 컨텍스트를 기반으로 작업하도록 지원 | 별도의 컨텍스트 저장소 또는 벡터 데이터베이스 필요(Teamwork Graph가 관리되는 컨텍스트 계층임) |
오케스트레이션 | 자동화, 워크플로 전환 및 할당을 통해 적절한 에이전트에게 업무를 라우팅하고 에이전트를 지시 및 감독 | 에이전트가 실제로 실행되는 환경 제공(에이전트 자체 플랫폼에서 제공하며 Jira 코딩 에이전트의 경우 Atlassian 샌드박스) |
모델 | 모델에 구애받지 않고 한곳에서 지원되는 모든 에이전트를 지시(모델은 Atlassian의 AI 게이트웨이를 통해 관리됨) | 모델 호스팅(Atlassian의 AI 게이트웨이가 Atlassian 호스팅 모델, 공급업체 모델 또는 BYOK(Bring-Your-Own-Key) 모델로 라우팅) |
검토 및 품질 | 산출물을 검토 및 승인 과정으로 라우팅하며 감사 가능하고 권한으로 제어되는 추적 기록을 남김 | 산출물의 정확성 보장 또는 코드 직접 작성(사용자가 검토 및 테스트) |
팀 조정 | 하나의 공유 시스템에서 전체 팀 업무를 조정하여 사용자와 에이전트가 동일한 정보 출처를 기반으로 작업하도록 하고 제공 데이터(사이클 타임, 처리량)를 통해 영향을 측정 | 개별 코딩 업무 수행(코딩 에이전트 및 IDE에서 수행) |
종속성 | 에이전트가 제공 전에 변경 사항의 영향을 확인할 수 있도록 팀과 서비스 전반의 업무 연결 관계를 매핑 | 코드베이스의 기술적 종속성 분석(IDE 및 빌드 도구가 이 작업 수행) |
Jira에서 에이전틱 엔지니어링을 시작하는 방법
에이전트가 수행한 작업 및 결정한 사항을 확인합니다. 전체 세션 기록을 검토하여 이탈을 조기에 파악하고 필요한 경우 수정합니다.
처음부터 전체 롤아웃을 할 필요는 없습니다. 가장 빠르게 첫 성과를 거두는 방법은 하나의 업무 항목에서 코딩 에이전트를 연결하고 작은 작업 하나를 할당한 다음 에이전트가 연 풀리퀘스트를 검토하는 것입니다.
일상적이고 범위가 명확한 작업 하나를 선택합니다. 불안정한 테스트, 종속성 업데이트 또는 작은 버그 수정부터 시작하는 것이 가장 안전합니다.
업무 항목으로 기록합니다. Confluence 페이지, Slack 스레드 또는 짧은 프롬프트를 요약과 설명이 포함된 업무 항목으로 변환합니다.
에이전트에게 할당합니다. Git 리포지토리를 연결한 다음, 에이전트 패널에서 Jira 코딩 에이전트에 업무 항목을 할당합니다.
풀리퀘스트를 검토합니다. 에이전트가 업무 항목과 연결된 풀리퀘스트를 열어 주므로, 계획한 곳과 동일한 위치에서 검토할 수 있습니다.
자동화합니다. 첫 실행 후, 반복해서 수행하는 작업을 찾아 자동화 규칙으로 만듭니다. 반복적인 업무는 가장 효과가 크고 위험도가 낮은 시작점입니다.
빠르게 시작하고 싶으십니까? 한 번만 구성하면 에이전틱 엔지니어링 템플릿이 워크플로, 상태 및 에이전트 단계를 갖춘 에이전트 기반 스페이스를 구축하므로, 빈 프로젝트 대신 작동하는 루프에서 시작할 수 있습니다. 효과적으로 작동하는 스페이스에서 이미 에이전틱 워크플로를 실행 중이십니까? 유료 고객은 이것을 사용자 지정 템플릿으로 저장하여 팀이 동일한 에이전트와 워크플로가 내장된 새 스페이스를 빠르게 만들 수 있습니다.
에이전틱 엔지니어링에 대해 자주 묻는 질문
에이전틱 엔지니어링에서 엔지니어는 어떤 역할을 합니까?
에이전틱 엔지니어는 AI 에이전트가 다단계 업무를 수행하도록 안내하는 목표, 컨텍스트 및 가드레일을 정의한 다음, 결과를 검토하고 승인합니다. Jira와 같은 기록 시스템이 이것을 조율하고 책임 소재를 명확히 관리합니다.
프롬프트 엔지니어링과 에이전틱 엔지니어링의 차이점은 무엇입니까?
프롬프트 엔지니어링은 좋은 모델 응답을 얻기 위한 하나의 지시 사항을 작성하며, 에이전틱 엔지니어링은 전체 작업에 걸쳐 계획하고 실행하며 반복 작업을 수행하는 에이전트를 조율합니다. 업무 단위가 프롬프트에서 목표로 전환됩니다.
코딩 에이전트만으로는 제공할 수 없는 Jira의 이점은 무엇입니까?
코딩 에이전트는 코드를 작성하지만, Jira는 단일 기록 시스템으로서 업무를 정의하고 우선 순위를 지정하며 오케스트레이션하고 검토 및 관리하는 곳입니다. Jira는 각 업무 항목과 연결된 감사 추적을 유지하면서 모든 에이전트를 조정합니다.
AI 에이전트는 Jira에서 어떻게 컨텍스트를 가져옵니까?
에이전트는 업무 항목 자체(요구 사항 및 수용 기준)와 관련 업무, 문서 및 코드를 연결하는 Teamwork Graph에서 컨텍스트를 가져옵니다. 따라서 에이전트가 프롬프트뿐만 아니라 이 컨텍스트를 바탕으로 작업을 수행할 수 있습니다.
AI가 코드를 작성하더라도 여전히 Jira가 필요합니까?
예, 오히려 더 필요합니다. 에이전트가 더 많은 코드를 더 빠르게 생성함에 따라, 제약은 업무를 조정하고 검토하며 관리하는 쪽으로 옮겨갑니다. Jira는 에이전트 산출물을 가시적으로 유지하고 책임 소재를 명확히 하며 원래 수행하려던 업무와 연결해 주는 컨트롤 플레인입니다.