AI 작업 관리자: 에이전트 업무 할당·추적·검토

한 터미널에서는 Claude Code가, 다른 터미널에서는 Codex가 돌아가고 있고, 한 시간 전에 시작해서 까맣게 잊고 있던 Gemini CLI 세션도 하나 있습니다. 셋 다 열심히 일하고 있죠. 그런데 어느 것도 나머지 둘이 뭘 하는지 알려주지 못합니다. 창을 하나씩 확인하다 보면 첫 번째 녀석이 뭘 하고 있었는지도 놓치게 되고, 정작 가장 중요한 질문—무엇이 끝났고, 무엇이 병합되기 전에 내 눈을 거쳐야 하는가—에는 여전히 답할 수 없습니다.

이건 코딩 문제가 아닙니다. 에이전트들은 코드를 잘 짭니다. 이건 작업 관리 문제이고, 에이전트를 두 개 이상 돌리는 순간부터 드러납니다. AI 태스크 매니저는 요청을 배정 가능한 작업 단위로 바꾸고, 코딩 에이전트에게 라우팅하며, 사람이 결과를 검토할 때까지 그 작업의 진행 상황과 병목, 결과를 눈에 보이게 유지해 주는 계층입니다. 에이전트는 실행하고, 태스크 매니저는 그 실행을 읽을 수 있게 만듭니다.

Sharkly도 그런 계층 중 하나입니다. 이미 코딩 에이전트는 갖고 있으니, Sharkly는 지금 쓰고 있는 도구들 주위에 공유 Task, Computer, 컨텍스트, 리뷰 계층을 더해 에이전트들을 하나의 팀으로 만들어 줍니다. 유일한 선택지도 아니고, 모든 환경에 맞는 정답도 아닙니다. 이 글에서는 현실적인 선택지들을 각 도구가 가장 강한 지점에서 비교하고, 에이전트를 위한 태스크 매니저가 반드시 갖춰야 할 다섯 가지 기준으로 살펴봅니다.

AI 태스크 매니저가 해야 할 일

마케팅 문구를 걷어내면 결국 다섯 가지 역량으로 정리됩니다. 어떤 도구든 이 기준으로 먼저 판단하세요.

• 병렬 실행. 여러 에이전트를 동시에 돌리면서도 변경 사항이 서로 충돌하지 않게 할 수 있는가? 보통은 격리된 워크트리가 답입니다.
• 팀 가시성. 여러 사람이 모든 에이전트의 작업, 막힌 부분, 완료된 부분을 흩어진 터미널이 아닌 한 곳에서 볼 수 있는가?
• 리뷰 흐름. 사람이 수락하거나, 수정을 요청하거나, 병합 여부를 결정하는 명시적인 단계가 있는가? 아니면 아무도 지켜보지 않는 사이에 작업이 프로덕션으로 흘러가는가?
• 자체 장비 실행. 에이전트가 내 하드웨어에서, 내 환경과 시크릿을 그대로 써서 돌아갈 수 있는가? 아니면 벤더의 클라우드에서만 가능한가?
• 통합. 팀이 이미 쓰는 도구와 연결되는가? 아니면 새 보금자리로 옮기라고 요구하는가?

모든 항목에서 1등인 도구는 없습니다. 흥미로운 차이는 트레이드오프에 있습니다.

각 도구의 최강 모습

여기서는 각 선택지를 허수아비가 아닌, 가장 강한 형태를 기준으로 평가합니다.

Cursor 백그라운드 에이전트는 팀 전체가 하나의 에디터에서 작업할 때 강력합니다. 에이전트가 클라우드에서 병렬로 실행되며, 다른 PR처럼 리뷰할 수 있는 풀 리퀘스트를 열어 줍니다. Cursor가 Sharkly와 달리 잘하는 점은, Cursor가 그 자체로 일급 코드 에디터라서 에이전트와 내 손이 같은 화면을 공유한다는 것입니다. 대가는 생태계 중력입니다. 워크플로가 Cursor를 전제로 하고, 에이전트는 내 장비가 아닌 Cursor 클라우드에서 돌아갑니다. 자세한 내용은 Cursor 백그라운드 에이전트 설명을 참고하세요.

GitHub Agent HQ는 코드, CI, 리뷰가 이미 GitHub에 있는 팀이라면 자연스러운 선택입니다. 이미 신뢰하는 풀 리퀘스트와 체크 옆에 에이전트를 위한 컨트롤 화면을 제공한다는 점은, GitHub의 홈그라운드에서는 Sharkly가 따라올 수 없는 진짜 강점입니다. 다만 설계 자체가 GitHub 중심이라, 가치는 리포지토리와 Actions가 있는 곳에 집중됩니다. GitHub Agent HQ 분석에서 현재 제공하는 기능을 다룹니다.

Conductor와 Claude Squad는 가벼운 로컬 옵션입니다. 내 장비의 격리된 git 워크트리에서 여러 Claude Code 세션을 거의 절차 없이 띄워 줍니다. Sharkly와 달리 잘하는 점은, 작고 단일 사용자에 머무르며 로그인할 것도 없다는 것입니다. 대신 팀 가시성과 공유 리뷰 흐름이 없어서, 작업을 볼 수 있는 사람은 나뿐입니다. Claude Squad, Conductor, tmux 비교에서 로컬 방식을 자세히 다룹니다.

Devin과 Factory는 다른 형태의 제품을 팝니다. 스스로 계획하고 실행하는 자율 엔지니어죠. 전체 루프를 벤더가 책임지길 원한다면, 이는 Sharkly도 다른 도구들도 제공하지 않는 것입니다. Sharkly의 모델은 새 에이전트를 도입하는 게 아니라 이미 쓰는 에이전트를 가져오는 것이니까요. 대가는 벤더 종속과, 그들의 에이전트와 함께 그들의 클라우드 안에서 돌아간다는 점입니다.

Jira와 Linear가 여기 포함되는 이유는 바로 에이전트를 실행하지 않기 때문입니다. 이 목록의 어떤 도구보다도 깊은 프로젝트 관리 기능과 가장 넓은 통합 생태계를 갖추고 있고, 사람의 리뷰를 위해 만들어졌습니다. Sharkly와 달리 잘하는 점은, 십 년간 다듬어진 완성도로 조직 전체의 비(非)에이전트 업무를 관리한다는 것입니다. 못하는 것은 작업을 실행하는 일이죠. 그래서 Jira 티켓을 AI 에이전트에게 배정하려면 그 아래에 실행 계층이 필요합니다.

Sharkly의 자리

Sharkly가 리뷰 항목에 내놓는 답은 분명히 짚고 넘어갈 만합니다. 흩어진 에이전트가 가장 아프게 작용하는 지점이니까요. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 수락합니다. 팀의 판단이 필요한 곳에서 자동화는 멈춥니다.

실제로는 실행, 병목, 결과가 개인 터미널 세션 속으로 사라지지 않고 Task 타임라인으로 돌아옵니다. 한 사람이 Task를 배정하면, 에이전트가 이를 가져가 격리된 워크트리에서 작업하고, 변경 요약과 검증 결과가 같은 Task에 붙습니다. 그러면 사람이 수락하거나 수정을 요청한 뒤에야 병합이 이뤄집니다. 요청부터 릴리스까지 전체 흐름에서 컨텍스트, 진행 상황, 병목, 결과, 사람의 리뷰가 모두 눈에 보입니다.

자체 장비 항목도 또 하나의 실질적인 차이입니다. Sharkly는 연결한 Computer에서 에이전트를 실행하므로, 작업이 벤더의 샌드박스가 아니라 내 환경과 내 시크릿 아래에서 이뤄집니다. 또한 에이전트를 대체하는 게 아니라 그 위에 얹히기 때문에, 공급자 중립이라는 베팅이 유효합니다. 내년에 더 나은 코딩 에이전트가 나와도 워크플로를 다시 짤 필요 없이 그쪽으로 작업을 라우팅하면 됩니다. 이 논지를 더 자세히 풀어낸 글이 AI 코딩 에이전트 대시보드에서 실제로 봐야 할 것입니다.

오해가 없도록 선을 하나 그으면, Sharkly는 Claude Code나 Codex 같은 실행 도구를 대체하는 것이 아니며, AI 태스크 매니저가 코드를 작성하지도 않습니다. 코드는 에이전트가 씁니다. 매니저는 에이전트의 작업을 배정 가능하고, 추적 가능하고, 리뷰 가능하게 유지할 뿐입니다.

팀 규모별로 무엇을 고를까

솔직하게 시작해 봅시다. Claude Code만 쓰고 터미널 우선 워크플로를 원한다면, 태스크 매니저가 아예 필요 없을 수도 있습니다. 에이전트 하나, 워크트리 하나, PR 하나면 충분히 괜찮은 구성입니다. 방정식이 달라지는 건 여러 태스크와 리포지토리에 걸쳐 여러 에이전트를 돌리면서, 그 결과물을 리뷰하는 일이 병목이 될 때입니다.

작업이 혼자 감당할 만큼 작고 내 것뿐이라면 가벼운 로컬 도구를 쓰세요. 여러 사람이 작업을 봐야 하고, 에이전트가 런타임과 리포지토리에 걸쳐 있으며, 코드가 나가기 전에 누군가 승인해야 한다면 Sharkly를 쓰세요. 하나의 생태계에 전념하는 대신 여러 코딩 에이전트를 계속 쓰고 싶다면, 그게 바로 Sharkly가 겨냥해 설계된 문제입니다.

자주 묻는 질문

AI 태스크 매니저는 로봇용 Jira인가요? 아닙니다. Jira와 Linear는 사람이 할 일을 추적합니다. AI 태스크 매니저는 여기에 더해 작업을 코딩 에이전트에게 배정하고, 결과를 다시 끌어와 리뷰할 수 있게 합니다. 둘을 연결할 수도 있습니다. Jira는 시스템 오브 레코드로 두고, 실행은 에이전트를 돌리는 계층을 통해 라우팅하는 거죠. AI 코딩 에이전트가 완료한 작업을 추적하는 방법을 참고하세요.

이걸 쓰려면 Claude Code나 Codex를 포기해야 하나요? 아닙니다. 공급자 중립 계층의 핵심은 이미 쓰는 에이전트를 그대로 유지한다는 것입니다. Sharkly는 에이전트를 대체하는 게 아니라 그 주위에서 배정, 컨텍스트, 리뷰를 관리합니다.

내가 보지 못한 코드를 에이전트가 병합하지 못하게 하려면 어떻게 할까요? 명시적인 수락 단계가 있는 도구를 고르고, 사람을 루프 안에 두세요. 에이전트는 제안하고, 사람이 병합을 결정합니다. 이 패턴은 휴먼 인 더 루프 코딩 에이전트에서 다룹니다.

코딩이 아니라 리뷰가 어려워지는 순간, 지금 쓰는 코딩 에이전트를 Sharkly를 통해 실행해 보세요.