여러분의 이슈는 이미 GitHub에 있습니다. 코드도, 풀 리퀘스트 리뷰도, 팀이 한 분기 동안 합의해 정한 브랜치 규칙도 마찬가지죠. 아무도 첫 번째 보드와 동기화할 두 번째 보드를 원하지 않습니다. 빠진 것은 그 이슈 중 하나를 코딩 에이전트에게 넘기고, 원래 있던 저장소를 떠나지 않고도 리뷰 가능한 풀 리퀘스트를 돌려받는 방법입니다.
GitHub를 Sharkly에 연결하면 바로 이걸 할 수 있습니다. Sharkly는 올인원 에이전트 명령 및 관리 플랫폼으로, GitHub 이슈를 할당 가능한 Task로 바꾸고, 코딩 에이전트(Claude Code, Codex, Gemini, 또는 팀에서 사용하는 Runtime)에게 라우팅하며, 격리된 worktree 안의 Computer에서 작업을 실행한 뒤, 평소처럼 리뷰할 수 있는 풀 리퀘스트로 결과를 돌려줍니다. 여기서 가장 중요한 두 가지는 누가 실제로 저장소를 건드릴 수 있는가, 그리고 사람이 여전히 승인해야 하는 지점이 어디인가입니다.
한 문장으로 정리한 루프
GitHub를 연결하고 저장소를 Space에 링크하면 새 이슈가 Task가 됩니다. 이를 Agent에 할당하면 Sharkly 어디에서나 동일한 계약이 적용됩니다. Agent는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 diff를 리뷰하고 무엇을 배포할지 결정합니다.
두 가지 연결, 그리고 왜 서로 다른 것인가
GitHub 통합에는 두 개의 계층이 있으며, 이 둘을 혼동하면 누가 무엇을 볼 수 있는지 헷갈리기 십상입니다.
첫 번째 계층은 조직 연결입니다. Organization Owner 또는 Admin이 Integrations를 열고 GitHub를 찾아, 해당 저장소를 볼 수 있도록 GitHub App을 설치합니다. 이 연결이 있어야 풀 리퀘스트 링크와 링크백 댓글이 가능합니다. 멤버가 개인 GitHub 계정을 연결할 수도 있지만, 이는 동기화된 댓글에 누구의 신원이 표시되는지만 바뀔 뿐, 조직 연결이 이미 하는 일을 바꾸지는 않습니다.
두 번째 계층은 그 저장소 중 하나를 Space에 링크하는 것입니다. 이렇게 하면 새 GitHub 이슈가 Task로 나타나기 시작합니다. 기존 이슈는 가져오지 않습니다. 저장소는 Space에 단방향(이슈 변경이 유입되기만 하고 되돌아가지 않음) 또는 양방향(이슈와 Task가 양방향으로 동기화됨)으로 연결할 수 있으며, 하나의 Space에는 한 번에 하나의 양방향 저장소만 연결되므로 신중하게 선택하세요.
사람들이 자주 걸리는 경계가 바로 여기입니다. 이 중 어느 것도 Agent가 여러분의 코드를 클론할 권한을 얻는 방식이 아닙니다. GitHub 통합은 풀 리퀘스트 링크, 이슈 동기화, 링크백 댓글을 담당합니다. 어떤 Agent에게도 저장소에 대한 읽기 또는 쓰기 권한을 부여하지 않습니다.
Agent에게 코드 접근 권한을 별도로 부여하기
코드 접근은 별도의 설정으로, GitHub 연결이 아니라 Agent 또는 Space에서 지정합니다. 자체 저장소가 없는 Agent는 해당 Task의 Space에 설정된 저장소를 따릅니다. Space가 참조하는 여러 코드베이스 중 하나만 건드려야 할 때는 Agent 자체에서 그 목록을 좁히면 됩니다.
어느 쪽이든, 실행에는 Computer 자체에서 작동하는 Git 접근이 여전히 필요합니다. SSH 키, HTTPS 토큰, 또는 이미 설정된 호스트 자격 증명이죠. 조직 연결이 이런 것들을 제공하거나 대체하지는 않습니다. 실행이 클론할 수 없다면, 그건 GitHub App 설정 문제가 아니라 Computer 문제입니다.
이슈를 Agent에 할당하기
저장소가 링크되면 새 GitHub 이슈가 Task로 들어옵니다(Issue, Bug, Feature, Ticket은 모두 유효한 task 유형이며, Space에서 사용하는 것을 따릅니다). 이를 Agent에 할당하는 방식은 팀원에게 할당하는 것과 같습니다. Assignee 컨트롤을 열고 Agent를 선택하면 됩니다.
Agent는 일회성 프롬프트가 아니라 저장된 작업 구성입니다. 그 지시사항, Runtime, 저장소, 실행 설정이 작업을 형성한다는 점은, 역할 기술서가 신입 사원의 업무를 규정하는 것과 같습니다. Task가 Backlog에 들어가면 아직 아무것도 실행되지 않습니다. 일종의 대기 장소죠. 이를 작업 중 상태로 옮기면 Computer와 Runtime이 준비되는 대로 Sharkly가 실행을 디스패치합니다.
두 Agent가 같은 저장소를 건드릴 때
팀이 가장 걱정하는 부분입니다. 기본 모드는 Temporary로, 각 Task마다 격리된 디렉터리를 받고 저장소 기반 실행은 새 worktree를 준비합니다. 같은 저장소의 서로 다른 이슈를 처리하는 두 Agent는 각자 자신의 체크아웃을 받으며, 공유하지 않습니다. 따라서 같은 Computer에서도 서로의 파일을 덮어쓰거나 브랜치를 두고 다툴 수 없습니다. 이는 AI 코딩 에이전트와 함께 git worktrees 사용하기를 수동으로 할 때와 같은 원칙을, 그저 자동화한 것입니다.
동시성에는 자체적인 상한이 있습니다. Temporary 실행은 기본적으로 Computer 전체 한도의 약 절반으로 설정됩니다. 수동으로 높이면, 값이 사용 가능한 디렉터리 용량을 초과하는 순간 제품이 경고를 표시합니다. 실제로 충돌이 시작되는 지점이죠. Specified 모드도 존재하는데, 이는 Agent가 새 worktree 대신 하나의 고정된 디렉터리를 재사용하는 방식입니다. 다만 한 번에 하나의 실행만 처리하므로, 여러 Agent가 동시에 접근하는 저장소에는 덜 적합합니다.
돌아오는 것: 풀 리퀘스트
Agent가 풀 리퀘스트를 열면, 브랜치 이름, 제목, 또는 본문에 Task ID를 적어 Task와 연결합니다. 세 가지 중 하나만 있으면 충분합니다. SH-312처럼 ID만 적어도 Fixes SH-312와 동일하게 작동합니다. fixes, closes, skip 같은 단어에 대한 특별한 처리가 없기 때문입니다. 공개 저장소에서는 신뢰할 수 있는 작성자, 즉 소유자, 멤버, 또는 협력자만 링크되므로, 낯선 사람의 풀 리퀘스트가 여러분의 Task에 속임수로 올라올 수 없습니다.
링크된 풀 리퀘스트는 Task를 가리키는 링크백 댓글도 받을 수 있습니다. 이는 비공개 저장소에서는 기본적으로 켜져 있고 공개 저장소에서는 기본적으로 꺼져 있으며, 이 스위치는 GitHub 설정에 있고 Space 자체의 공개/비공개 여부와는 별개입니다.
리뷰 게이트: 판단이 머무는 곳
풀 리퀘스트를 병합해도 Task의 상태는 바뀌지 않으며, 절대 자동으로 일어나지 않습니다. 이는 의도된 것입니다. Task 상태와 Agent의 작업 상태는 별도로 추적되므로, Started Task가 Working, Waiting for human reply, Waiting for human review, 또는 Error를 함께 표시할 수 있고, 이런 신호는 책임이 있는 사람을 위해 Inbox에 나타납니다. 기반이 되는 GitHub 이슈를 닫거나 다시 열면 양방향 Task의 상태가 바뀔 수 있지만, 풀 리퀘스트를 병합하는 것은 그렇지 않습니다.
Agent는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 원래 이슈와 대조해 diff를 읽고, 변경을 요청하거나 수락하며, 병합과 릴리스 결정을 직접 내립니다. 이 분업은 끝까지 유지되며, GitHub에서도 Sharkly의 다른 모든 곳과 마찬가지입니다. 자동화는 팀의 판단이 필요한 바로 그 지점에서 멈춥니다. 더 깊은 작동 방식은 Sharkly의 human-in-the-loop 리뷰 워크플로에서 직접 다룹니다.
GitHub 자체의 에이전트 허브로 충분할 때
팀이 GitHub에 올인했다면, 소스, CI, 리뷰, 유료 Copilot 시트까지 모두 GitHub에서 처리한다면, GitHub 자체의 Agent HQ가 그 생태계 안에서 에이전트를 잘 조율해 주므로 다른 게 필요 없을 수도 있습니다. Sharkly가 필요해지는 시점은 작업이 Jira를 거치기 시작할 때, Agent가 GitHub 클라우드 밖의 Computer에서 실행될 때, 또는 팀이 Runtime을 섞어 쓰면서 최고의 Runtime이 바뀔 때마다 워크플로를 다시 만들고 싶지 않을 때입니다. Jira가 그 조합에 포함된다면, Jira 티켓을 AI Agent에 할당하기에서 같은 루프를 그쪽 관점에서 설명합니다.
실제 이슈 하나로 시험해 보려면, Sharkly의 GitHub, Jira, Slack 통합을 열고, GitHub 조직을 연결한 뒤, 트래픽이 적은 저장소 하나를 Space에 링크하고, 다음번 작은 이슈를 자기 자신 대신 Agent에 할당해 보세요.
자주 묻는 질문
GitHub 조직을 연결하면 Agent가 내 코드에 접근할 수 있나요? 아닙니다. 조직 연결은 풀 리퀘스트 링크, 이슈 동기화, 링크백 댓글을 담당합니다. 코드 접근은 Agent 또는 Space에서 별도로 구성하며, 실행에는 여전히 Computer 자체의 Git 자격 증명이 필요합니다.
같은 저장소에서 작업하는 두 Agent가 충돌할 수 있나요? 기본 Temporary 모드에서는 아닙니다. 각 실행이 자체 격리된 worktree를 받으므로, 동시 실행 중인 Agent들은 같은 Computer에서도 작업 사본을 공유하지 않습니다.
풀 리퀘스트를 병합하면 GitHub 이슈나 Task가 닫히나요? 병합만으로는 Task의 상태가 바뀌지 않습니다. 양방향 동기화 저장소에서는 기반 GitHub 이슈를 닫으면 바뀔 수 있지만, 이는 PR 병합과는 별개의 작업입니다.
Agent의 풀 리퀘스트는 실제로 무엇을 대상으로 하나요? Sharkly는 브랜치, 제목, 또는 본문에 있는 Task ID로 풀 리퀘스트를 링크하며, 이는 Runtime이 작성하는 위치를 따릅니다. 브랜치 전략을 규정하지는 않으므로, 테스트 이슈보다 위험 부담이 큰 작업을 할당하기 전에 Runtime의 기본 base 브랜치 동작을 확인하세요.
새 이슈뿐 아니라 기존 GitHub 이슈도 유지할 수 있나요? 저장소를 링크하면 이후 생성되는 새 이슈가 동기화됩니다. 기존 이슈는 자동으로 가져오지 않습니다.
