티켓은 이미 작성되어 있습니다. 제목, 설명, 인수 조건, 스프린트 내 위치까지 다 갖췄죠. 티켓과 실제 코드 변경 사이에 놓인 단 하나의 장벽은 터미널을 열고, 티켓을 코딩 에이전트에 붙여넣고, 실행 과정을 지켜본 뒤, 결과를 다시 Jira에 손으로 복사해 넣는 사람입니다. 작업과 작업의 기록이 서로 다른 창에 존재하고, 이 둘을 동기화하는 일이 누군가의 오후를 통째로 잡아먹습니다.
Jira 티켓을 AI 에이전트에 할당한다는 것은 바로 그 간극을 메우는 일입니다. 이슈가 에이전트가 집어 들어 여러분의 저장소를 대상으로 실행하고, 리뷰 가능한 변경 사항으로 돌려줄 수 있는 작업 단위가 되며, 팀이 이미 사용 중인 트래커를 벗어날 필요도 없습니다. 팀을 Jira에서 옮겨갈 필요는 없습니다. 티켓을 실제로 작업할 수 있는 레이어를 추가하는 것뿐입니다.
그 레이어가 바로 Sharkly입니다. 에이전트 명령과 관리를 하나로 통합한 플랫폼이죠. Sharkly는 Jira에 연결해 이슈를 할당 가능한 Task로 바꾸고, 여러분의 코딩 에이전트(Claude Code, Codex, Gemini 및 기타 명령줄 도구)로 라우팅하며, 각각을 격리된 환경에서 실행하고 결과를 Task로 돌려줍니다. 이 가이드에서는 전체 흐름을 따라갑니다. 티켓 투입, Agent 할당, 격리된 워크트리에서의 작업, 그리고 기록 위로 되돌아오는 풀 리퀘스트와 논의까지.
한 문장으로 보는 전체 흐름
Sharkly Task는 하나의 작업을 위한 공유 기록이며, Jira를 연결하면 각 Jira 이슈가 그런 Task 중 하나가 됩니다. 여기서 규칙은 단순합니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. 이 글의 나머지는 그 한 문장이 작동하는 방식에 불과합니다.
Jira는 그대로 두고, 실행 레이어를 더하세요
Sharkly는 Jira를 대체하지 않습니다. 팀이 이미 사용하는 트래커 주위에 공유 Task, 연결된 Computer, 실행 및 리뷰 레이어를 더해줍니다. 시작하기 위해 새로운 보드를 배우거나 백로그를 마이그레이션할 필요가 없습니다.
둘은 동기화 링크로 연결합니다. Jira 통합을 열고 계정을 연결한 다음(Jira Cloud는 *.atlassian.net 호스트, 계정 이메일, Atlassian API 토큰을 사용하고, Server와 Data Center는 기본 URL, 사용자 이름, 개인 액세스 토큰을 사용합니다), 하나의 Jira 프로젝트를 하나의 Sharkly Space와 페어링합니다. 핵심 매핑은 예상하시는 그대로입니다.
- Jira 이슈는 Sharkly Task가 됩니다
- Jira 에픽은 Sharkly Project가 됩니다
- 담당자, 상태, 댓글, 첨부 파일이 그대로 전달됩니다
여기서 솔직하게 갈리는 두 가지 선택지가 있습니다. 진행 중인 프로젝트를 계속 연결된 상태로 두고 싶다면 sync를 사용하세요. 그러면 이후로 Jira와 Sharkly 사이에서 변경 사항이 오갑니다. 통제된 마이그레이션을 위해 과거 이슈를 복사해 오고 싶다면 import를 사용하세요. sync만으로는 프로젝트의 과거 이력을 채워 넣지 못합니다. 이제 막 시작하는 대부분의 팀에게 필요한 것은 활성 프로젝트 하나에 걸린 양방향 동기화 링크, 그 이상도 이하도 아닙니다. Jira 관리자가 한 번만 처리하면 되는 웹훅 단계를 포함한 전체 설정 방법은 Sharkly 문서에서 확인할 수 있습니다.
티켓을 Agent에 할당하기
프로젝트가 연결되면 이슈가 Space에 Task로 나타납니다. Agent에 할당하는 방식은 동료에게 할당하는 것과 같습니다. 사람 대신 Agent를 고르면 됩니다.
Agent는 단순한 모델 선택 이상입니다. Agent의 지침, Runtime, 저장소, 실행 설정이 작업 처리 방식을 규정한다는 점에서, 직무 기술서가 신입 사원의 업무를 규정하는 것과 같습니다. Runtime은 그 아래를 받치는 엔진으로, Claude Code, Codex 또는 팀이 이미 사용 중인 CLI 에이전트라면 무엇이든 됩니다. 모델 사용은 해당 도구에 설정된 구독이나 API 키를 통해 그대로 이어지므로, 에이전트 접근 권한과 코드는 여러분의 하드웨어에 그대로 남습니다. Sharkly는 할당을 조율할 뿐, 여러분의 자격 증명을 보관하지 않습니다.
처음 실행하는 것이라면 범위는 작게, 경계는 명확하게 유지하세요. 에이전트가 실제로 실행할 수 있는 작업을 작성하는 것도 그 자체로 하나의 기술이며, 중요한 무언가에 Agent를 투입하기 전에 제대로 익혀둘 가치가 있습니다. 완료 기준이 명확한 탄탄한 티켓은 탄탄한 diff를 만들어내고, 모호한 티켓은 모호한 결과를 낳습니다.
격리된 워크트리에서의 실행
Agent가 시작되면 실행은 연결된 Computer에서 자체적으로 격리된 워크트리 안에서 이루어집니다. 바로 이 격리 덕분에 반복해도 안전합니다. 실행마다 새로운 작업 디렉터리가 주어지므로, 동일한 저장소를 대상으로 두 개의 티켓을 처리하는 두 Agent가 서로의 파일을 덮어쓰거나 브랜치를 두고 다툴 일이 없습니다. AI 코딩 에이전트를 위한 git worktree를 직접 다룰 때 쓰는 것과 같은 원칙을, 자동으로 처리하고 모든 Task에서 반복 가능하게 만든 것입니다.
이 점 덕분에 워크플로가 티켓 하나를 넘어 확장될 수 있습니다. 격리가 자동화되는 순간, 여러 에이전트를 병렬로 실행하는 일은 더 이상 곡예가 아니게 됩니다. 보통 문제를 일으키는 원인(디스크의 공유 상태)이 설계 단계에서 제거되었기 때문입니다. 이 모델 전체가 처음이라면, Jira를 연동하기 전에 AI 에이전트에 첫 작업을 할당하기부터 시작하는 편이 더 완만한 진입로입니다.
PR을 다시 기록 위로 가져오기
Agent의 작업은 Task로 돌아옵니다. 대화, 실행 로그, 장애 요소, 그리고 그 결과로 생긴 변경 사항이 터미널과 채팅 스레드에 흩어지지 않고 한곳에 모입니다. Agent가 풀 리퀘스트를 열면, 브랜치 이름이나 PR 제목, PR 본문에 Task ID를 적어 Task와 연결합니다. Sharkly의 GitHub 통합이 이 ID를 인식해 풀 리퀘스트를 Task에 연결하고, 링크백 댓글을 남겨 티켓을 보는 누구나 바로 코드로 이동할 수 있게 해줍니다.
Jira 동기화 링크는 양방향이므로, 이런 활동은 원래 이슈 쪽으로도 계속 흘러갑니다. 티켓을 등록한 사람은 터미널을 한 번도 열지 않고도 작업이 진행되는 모습을 볼 수 있습니다. 이것이 비공개 프롬프트 대신 공유 Task를 통해 작업을 라우팅할 때 얻는 성과입니다. 맥락, 진행 상황, 장애 요소, 결과, 리뷰가 요청부터 릴리스까지 모두 눈에 보이는 상태로 유지됩니다.
솔직한 경계: 승인은 사람이 합니다
그 무엇도 스스로 병합되지 않습니다. 이는 의도된 설계이며, 독자가 다르게 짐작할 수 있으므로 분명히 짚고 넘어갈 가치가 있습니다. 풀 리퀘스트를 병합해도 Task 상태는 바뀌지 않으며, 자동으로 병합되는 일은 결코 없습니다. 자동화는 팀의 판단이 필요한 지점에서 멈춥니다.
이 역할 분담은 끝까지 유지됩니다. Agent는 작업을 실행하고, PR을 열고, 무엇을 했는지, 무엇을 검증했는지, 어디가 불확실한지 보고합니다. 사람은 원래의 인수 조건에 비추어 diff를 읽고, 변경을 요청하거나 승인하며, 병합과 릴리스 여부를 결정합니다. 에이전트는 침묵을 주도권으로 채우는 것을 서슴지 않으므로, 리뷰 단계는 형식적인 절차가 아닙니다. 자동화된 부분을 믿을 수 있게 만들어주는 통제 장치입니다. 최종 승인과 릴리스 결정은 사람의 몫으로 남습니다.
이것이 전체 흐름입니다. Jira 티켓이 들어가면 Agent가 이를 집어 들고, 작업이 격리된 환경에서 실행되어 읽을 수 있는 풀 리퀘스트로 기록에 돌아오면, 출시 여부는 여러분이 결정합니다. 단일 실행이 아니라 에이전트 팀에 이것이 어떻게 들어맞는지 더 넓게 살펴보고 싶다면 개발 팀에게 AI 에이전트 오케스트레이션이란 무엇인지를, 플랫폼 전체가 궁금하다면 Sharkly 개요를 참고하세요.
실제 티켓 하나로 시험해보려면 Sharkly를 다운로드하고, app.sharkly.ai에서 로그인한 뒤, Computer를 연결하고, 위험도가 낮은 Jira 프로젝트 하나를 연결해보세요.
자주 묻는 질문
Sharkly가 Jira를 대체하나요? 아닙니다. Sharkly는 Jira 주위에 실행 및 리뷰 레이어를 더합니다. 이슈, 에픽, 상태, 워크플로는 있던 자리에 그대로 있고, 동기화 링크가 이들을 연결된 상태로 유지하면서 Agent가 작업을 앞으로 나아가게 합니다.
어떤 Jira 버전이 지원되나요? 둘 다 됩니다. Jira Cloud는 호스트, 계정 이메일, Atlassian API 토큰으로 연결합니다. Jira Server와 Data Center는 기본 URL, 사용자 이름, 개인 액세스 토큰으로 연결합니다.
백로그를 먼저 마이그레이션해야 하나요? 아닙니다. 동기화 링크는 진행 중인 프로젝트를 연결하고, 이력을 가져오지 않고도 향후 변경 사항을 계속 흘려보냅니다. 과거 이슈를 복사해 오고 싶을 때만 별도로 import를 실행하면 됩니다.
풀 리퀘스트를 병합하면 티켓이 닫히나요? 아닙니다. PR을 병합해도 설계상 Task 상태는 바뀌지 않습니다. 사람이 결과를 승인하고 병합 및 릴리스 단계를 결정합니다. 리뷰 흐름이 어떻게 작동하는지는 AI 에이전트에 첫 작업을 할당하기에서 확인하세요.
코드와 모델 접근 권한은 어디에 있나요? 여러분의 하드웨어에 있습니다. Agent는 직접 연결한 Computer에서 실행되며, 코딩 도구에 이미 설정된 구독이나 API 키를 사용합니다. Sharkly는 할당, 맥락, 리뷰를 조율할 뿐, 저장소나 모델 할당량을 호스팅하지 않습니다.
