Sharkly란 무엇인가?

이미 AI 코딩 에이전트 하나에 실제 작업을 맡길 수 있습니다. 원하는 변경 사항을 설명하면 에이전트가 파일을 수정하고, 테스트를 실행하고, diff를 돌려줍니다. 첫 번째 에이전트가 생각하는 동안 두 번째 에이전트도 함께 일하게 하고 싶어지는 순간까지만 해도 이 워크플로는 아주 깔끔하게 느껴집니다. 그 순간부터는 터미널 두 개, 헷갈리지 않게 관리해야 할 브랜치 두 개가 생기고, 누가 무엇을 하고 있는지 공유하는 기록은 사라집니다. 여기에 세 번째 에이전트와 돕고 싶어 하는 동료까지 합류하면, 모든 것이 다른 사람은 볼 수 없는 개인 프롬프트와 터미널 세션으로 변해버립니다. 에이전트 자체는 문제가 없습니다. 빠진 것은 에이전트를 둘러싼 시스템입니다.

Sharkly가 바로 그 시스템입니다. 팀원에게 업무를 할당하듯 AI 코딩 에이전트에게 작업을 할당할 수 있습니다. 담당자, 컨텍스트, 결과가 돌아올 곳, 그리고 머지 전 리뷰 단계를 갖춘 작업 말입니다. 코딩은 여전히 에이전트가 합니다. Sharkly는 팀이 이미 사용하는 도구 주위에 공유 작업, 컴퓨터, 컨텍스트, 제어, 리뷰 계층을 더합니다.

TL;DR

Sharkly는 올인원 Agent 명령 및 관리 플랫폼입니다. Claude Code, Codex, Gemini 같은 AI 코딩 에이전트를 실제 작업 시스템 안에서 할당하고 추적할 수 있는 팀원으로 바꿔줍니다. Task를 할당하고, 여러 Agent를 자신의 컴퓨터에서 병렬로 실행하며, 요청부터 릴리스까지 컨텍스트, 진행 상황, 블로커, 결과, 사람의 리뷰를 모두 확인할 수 있게 유지합니다. 이 코딩 도구들을 대체하는 것이 아니라, 그 주위를 감싸는 협업 계층입니다.

Sharkly란 무엇인가?

Sharkly는 사람과 여러 AI 코딩 Agent를 하나의 공유 작업 시스템에서 조율하는 플랫폼입니다. Task를 할당하면 Agent가 격리된 워크스페이스에서 조사하고 실행하며, 결과는 그 Task로 돌아와 사람이 검토하고 승인합니다. 코드 실행은 여전히 코딩 도구가 담당하고, Sharkly는 이 모든 도구에 걸친 할당, 컨텍스트, 병렬 실행, 리뷰를 관리합니다.

Sharkly의 위치를 가장 명확하게 보여주는 방법은 Sharkly가 하지 않는 일을 보는 것입니다. 제품 자체 FAQ에서 인용합니다.

Sharkly는 Claude Code, Codex 또는 다른 실행 도구를 대체하지 않습니다. 팀이 이미 사용하는 도구 주위에 공유 작업, 컴퓨터, 컨텍스트, 제어, 리뷰 계층을 더합니다.

역할 분담은 명확합니다. Claude Code, Codex 및 유사한 도구는 실행을 담당합니다. Sharkly는 팀 차원의 할당, 연결된 컴퓨터, 작업 컨텍스트, 진행 상황, 블로커, 결과, 그리고 이 도구들 전반에 걸친 사람의 리뷰를 관리합니다. AI 에이전트 오케스트레이션이 무엇인지 이미 알고 있다면, Sharkly는 직접 시스템을 구축하지 않고도 그것을 구현하는 하나의 구체적인 방법입니다.

이 경계가 중요한 이유는, 이 범주의 도구에 대해 가장 흔히 하는 잘못된 가정이 바로 '당신의 에이전트와 경쟁한다'는 것이기 때문입니다. 그렇지 않습니다. Claude Code 설정, Codex 구성, 구독과 API 키를 그대로 유지합니다. Sharkly는 그 위에 자리 잡아 실행을 할당 가능하고 추적 가능하게 만듭니다.

구독은 직접 가져오세요

여기에는 토큰 재판매가 없습니다. 모델 사용은 연결한 코딩 도구에 설정된 구독이나 API 키를 통해 계속 이뤄집니다. 모델 할당량은 Sharkly가 아니라 팀이 연결한 AI 코딩 도구, 플랜, API 계정에 따라 달라집니다. 이런 구조 덕분에 이 계층은 정직합니다. Sharkly는 당신과 모델 사이에 끼어 있어서가 아니라, 조율을 통해 제자리를 얻습니다.

Sharkly가 해결하는 문제: 에이전트는 확장되지만 협업은 그렇지 않다

에이전트 하나에게는 좋은 프롬프트면 충분합니다. 에이전트 여러 개에게는 관리자가 필요합니다. 팀이 문제에 빠지는 지점이 바로 이 전환점이며, 에이전트가 유용하다는 것이 증명되면 순식간에 찾아옵니다.

에이전트 하나를 실행할 때는 터미널 하나면 충분합니다. 지켜보고, diff를 검토하고, 머지하고, 다음으로 넘어갑니다. 세 개를 실행하면 거의 동시에 세 가지 실패 유형이 나타납니다.

• 충돌. 두 에이전트가 같은 저장소를 편집하면 서로의 작업을 덮어씁니다. 커밋되지 않은 작업은 사라지고 git 상태는 엉킵니다.
• 사각지대. 에이전트가 터미널 탭 여섯 개에 흩어져 있으면 어떤 작업이 끝났는지, 어떤 것이 막혀 있는지, 어떤 것이 조용히 잘못된 접근으로 작업하고 있는지 알 수 없습니다.
• 잃어버린 컨텍스트. 각 실행의 목표, diff, 논의, 리뷰가 모두 개별 비공개 세션에 흩어져 있습니다. 공유된 것이 없으니 동료가 당신이 멈춘 지점에서 이어받을 수 없습니다.

이 중 어느 것도 에이전트 품질의 문제가 아닙니다. 각 에이전트는 꼼꼼하게 작업하고 있을 수 있습니다. 실패의 원인은 조율이며, 이는 작업 시스템이 사람 팀에서 해결해 주는 바로 그 실패입니다. Sharkly는 같은 아이디어를 Agent에 적용합니다. 모든 실행에 담당자, 공유 기록, 리뷰 게이트를 부여해, 실행이 개인 터미널 속으로 사라지는 대신 팀 계획의 일부가 되도록 합니다.

이 문제를 특정 런타임 관점에서 다룬 글로는, 여러 Claude Code 에이전트를 병렬로 실행하기 가이드에서 터미널 쪽에서 같은 벽에 부딪히는 과정을 살펴봅니다.

핵심 개념 정리

Sharkly의 용어는 간결하고 각 단어는 하나의 의미만 갖습니다. 이 다섯 가지만 익히면 나머지 제품은 명확하게 읽힙니다.

• Task는 Sharkly의 핵심 작업 단위입니다. 목표, 담당자, 컨텍스트, 실행, 결과, 리뷰를 담고 있습니다. 모든 것이 여기로 돌아옵니다.
• Agent는 작업을 어떻게 처리할지 정의합니다. 지침, Skills, 코딩 도구가 여기에 해당합니다. 사람에게 티켓을 할당하듯 Agent에게 Task를 할당합니다.
• Computer는 Agent 세션이 실행되는 호스트와 로컬 리소스를 제공합니다. Sharkly Desktop을 통한 로컬이든 Sharkly CLI를 통한 원격이든 자신의 머신을 연결해, 코드가 통제 가능한 곳에서 실행되게 합니다.
• Runtime은 실제 에이전트 세션을 수행합니다. Claude Code, Codex, Gemini 및 기타 명령줄 런타임이 여기에 연결됩니다.
• Crew는 하나의 리더 Agent가 조율하는, 재사용 가능한 사람과 Agent의 그룹입니다.

이 분리가 핵심입니다. Agent는 작업 처리 방식을 정의하고, Computer는 호스트와 로컬 리소스를 제공하며, Runtime은 실제 세션을 수행하고, Task는 팀을 위한 공유 기록으로 남습니다. 각 부분이 하나의 역할만 맡기 때문에, 병렬 Agent로 가득한 상황에서도 전체가 명확하게 파악됩니다.

단일 Agent를 써야 할 때와 Crew를 써야 할 때

대부분 이 결정을 거꾸로 내립니다. 대부분의 작업에는 Crew가 필요하지 않습니다. 작고 명확하게 정의된 작업이라면 Task를 하나의 Agent에 바로 할당하고 변수를 최소화하세요. 리더 Agent가 포괄적인 목표를 해석하고, 다른 Agent 멤버를 참여시키고, 그 결과를 하나의 Task로 모아야 할 때 Crew를 사용하세요. 먼저 단순한 도구를 선택하고, 단일 Agent가 정말로 전체 목표를 감당할 수 없을 때 Crew로 넘어가세요. 첫 번째 실제 Task는 하나의 Agent에 맡기는 것이 좋으며, 이는 첫 작업 워크스루에서 다루는 내용 그대로입니다.

워크플로: 요청부터 릴리스까지 네 단계

Sharkly는 제품 작업을 네 단계로 구성합니다. 이것이 플랫폼 전체의 척추이며, 팀이 이미 제품을 출시하는 방식과 깔끔하게 맞아떨어집니다.

1단계: 설명과 리서치

사람이 자연어로 필요 사항을 설명합니다. Agent는 제품, 코드베이스, 과거 작업, 팀 규칙을 조사한 뒤 범위와 인수 기준을 완성하고 실행 가능한 Task를 만듭니다. 사람은 의도를 밝히고, Agent는 그것을 실제로 착수 가능한 작업으로 바꿉니다.

여기서부터 이 계층이 빛을 발합니다. 매번 모호한 요청을 정교한 프롬프트로 번역할 필요 없이, Agent가 형태를 잡아 다른 사람이 볼 수 있는 Task로 기록합니다. Sharkly의 작업은 SH-312처럼 실제 티켓 형태이며, 흘러가 버리는 채팅 메시지가 아닙니다.

2단계: 자동 병렬 개발

Agent는 준비된 Task를 가져가 격리된 git 워크트리에서 작업합니다. 프런트엔드, 백엔드, 버그 수정, 테스트 커버리지가 각자 자신의 컴퓨터에 있는 워크스페이스에서 동시에 진행됩니다. 병렬 작업을 안전하게 만드는 것이 바로 워크트리입니다. 하나의 저장소 이력을 공유하면서도 고유한 브랜치와 파일을 유지하는 연결된 작업 디렉터리입니다. Agent 다섯 개, 워크트리 다섯 개, 브랜치 다섯 개, 충돌은 없습니다.

실행이 직접 연결한 컴퓨터에서 이뤄지기 때문에, 잘못된 변경은 해당 브랜치와 머신 안에 머뭅니다. 실수로 메인 브랜치를 건드리는 일은 없습니다. 이 작동 원리를 더 깊이 알고 싶다면 AI 코딩 에이전트를 위한 git worktrees 가이드를 참고하세요.

3단계: 테스트와 사람의 승인

Agent는 타입 체크, 테스트, 빌드를 실행한 뒤 변경 요약, 검증 결과, 알려진 한계를 Task에 첨부합니다. 사람은 승인하거나, 변경을 요청하거나, 머지 및 릴리스 단계를 결정합니다. 실행, 블로커, 결과, 후속 논의가 Task 타임라인으로 돌아오므로, 리뷰는 빈약한 diff가 아니라 완전한 컨텍스트를 바탕으로 이뤄집니다.

여러 Agent를 무모하지 않고 안전하게 운영하게 해주는 단계가 바로 이 단계입니다. 점검 지점 없는 속도는 예전에 하나를 출시하던 시간에 버그 다섯 개를 출시하는 방법입니다. 승인 게이트는 처리량을 유지하면서 정말 중요한 한 순간에 사람을 다시 루프 안으로 불러들입니다. 최종 승인과 릴리스 결정은 사람에게 맡기세요.

4단계: 프로젝트와 스프린트

팀은 공유 계획에서 완료 여부, 담당자, 의존성, 범위 변경, 블로커를 추적합니다. Agent의 작업은 사람의 작업과 같은 Projects와 Sprints에 존재하므로, 관리자는 터미널 여섯 개와 채팅 스레드를 짜맞출 필요 없이 하나의 보드만 보면 됩니다. 변경 사항과 진행 상황은 계속해서 Task로 돌아옵니다.

사람과 에이전트의 계약

Sharkly를 하나의 아이디어로 압축하면 이렇습니다. Agent는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. 자동화는 팀의 판단이 필요한 지점에서 멈추고, 완전한 컨텍스트와 검증 가능한 근거를 갖춘 결과물을 돌려줍니다.

이 문장이 곧 전체 안전 모델입니다. 에이전트 플랫폼이 코드베이스를 기계에 넘기고 물러난다는 우려에 대한 정직한 답이기도 합니다. 그렇지 않습니다. 아니, 그리 해서는 안 됩니다. 가치 있는 방식은 판단이 필요한 양 끝, 즉 시작의 방향 설정과 끝의 승인에 사람을 남겨두고, 기계적인 중간 과정은 Agent가 맡게 하는 것입니다. Sharkly는 완전한 자율성이라는 환상이 아니라 이런 형태를 중심으로 만들어졌습니다.

팀의 강점은 어디에서 나오는가

제품 전체에 조용히 깔린 주장이 하나 있는데, 분명히 짚을 가치가 있습니다. 팀의 레버리지는 AI 채팅을 더 많이 여는 데서 나오지 않습니다. 역할, 규칙, 컨텍스트, 워크플로를 공유하는 데서 나옵니다.

한 개발자의 정교한 프롬프트 노하우가 Agent 프로필과 재사용 가능한 Skills로 담기면, 팀 전체가 할당할 수 있는 자산이 됩니다. 하나의 좋은 설정을 팀이 재사용하는 개발 역량으로 바꾸는 것입니다. 열 명이 각자 에이전트를 다루는 방법을 다시 터득하는 것과, 모두가 작업을 거쳐 보내는 하나의 공유 구성을 갖는 것의 차이가 바로 여기에 있습니다. Agent는 단순히 질문에 답하지 않습니다. 현재 상태에서 작업을 다듬고, 앞으로 나아가게 하고, 모든 결과를 팀에 돌려줍니다.

기존 프로세스를 다시 만들 필요는 없습니다

Sharkly 도입은 마이그레이션 프로젝트가 아닙니다. 실행을 할당 가능하고 추적 가능하게 만들면서 팀이 이미 사용하는 도구는 그대로 유지하세요. 컴퓨터를 연결하고, Agent를 구성하고, 팀이 이미 이해하고 있는 프로세스를 다시 만들지 않고도 작업을 분배하기 시작할 수 있습니다.

Jira를 주로 쓴다면 팀이 이미 익숙한 프로젝트, 작업, 상태, 워크플로를 그대로 유지하세요. Sharkly를 연결하면 기존 시스템은 그대로 둔 채 Agent 실행이 그 안에서 작업을 진전시킵니다. 목표는 현재 환경에 가시적이고 검토 가능한 실행을 더하는 것이지, 모두가 다시 배워야 하는 새 시스템으로 교체하는 것이 아닙니다.

Sharkly와 직접 구축한 환경 비교

많은 팀이 자체 스크립트로 에이전트를 오케스트레이션합니다. 셸 래퍼 폴더, tmux 창 몇 개, 브랜치 명명 규칙 같은 것입니다. 이 방식도 통하며, 작업량이 적은 1인 개발자에게는 올바른 선택일 수 있습니다. 이 방식이 통하지 않게 되는 시점은 예측 가능합니다.

솔직히 말하면, 혼자 에이전트 한두 개를 돌리고 작업을 다른 사람에게 넘길 일이 없다면 직접 구축한 환경이 유지 비용이 더 적습니다. 하지만 여러 개를 돌리거나 다른 사람이 작업을 봐야 한다면, 직접 만들어야 했을 협업 기능이 바로 Sharkly라는 제품입니다. 다른 오케스트레이션 계층과의 비교는 별도로 다룰 주제이며, 트레이드오프에 대해서는 오케스트레이션 가이드에서 더 깊이 다룹니다.

Sharkly는 누구를 위한 것인가

이 제품은 이미 AI 코딩 도구를 사용하면서 작업을 분배하고, 여러 실행을 조율하고, 진행 상황과 결과를 하나의 공유 워크플로에서 검토하고 싶은 제품 및 엔지니어링 팀을 대상으로 합니다. 구체적으로 잘 맞는 경우는 다음과 같습니다.

• 여러 에이전트를 동시에 돌리는 백엔드 개발자로, 병렬 실행이 충돌하지 않도록 격리된 워크트리가 필요한 경우.
• 에이전트 작업을 다른 모든 작업과 같은 보드에서 보고, 머지 전 리뷰 단계를 필요로 하는 엔지니어링 매니저.
• 에이전트 활용에 대한 팀 표준을 구전 지식이 아니라 공유된 Agents와 Skills로 정립하고 싶은 테크 리드.
• 규모를 키우는 1인 개발자로, 라벨 없는 터미널 여섯 개의 혼란 없이 더 많은 처리량을 원하는 경우.

아직 이 중 어느 것도 자신에게 해당하지 않는다면, 그것도 충분히 유효한 답입니다. Sharkly는 협업이 병목일 때 제 가치를 합니다. 그 아래 단계에서는 에이전트 하나와 터미널 하나면 충분합니다.

시작하기

가장 작은 단위의 유용한 Sharkly 워크플로는 의도적으로 소박합니다. 컴퓨터 하나를 연결하고, Agent 하나를 만들고, 위험 부담이 낮은 Task 하나를 할당하세요. 전체 백로그를 다시 쓰는 것이 아니라 실제 요구 사항 하나로 Agent를 시작하게 하세요. Task 하나가 네 단계를 거치는 모습을 지켜보고 직접 결과를 승인하면, 어떤 설명보다도 이 계층을 잘 이해하게 될 것입니다.

그다음에는 두 번째 Agent를 추가해 무언가를 병렬로 실행하고, 이후 동료를 보드에 초대하세요. 각 단계마다 직접 손으로 하던 협업이 하나씩 더해집니다.

시작하려면 Sharkly를 다운로드하고, 컴퓨터를 연결하고, 첫 Task를 분배하세요. 각 개념에 대한 자세한 내용은 docs.sharkly.ai 문서에서 확인할 수 있습니다.

자주 묻는 질문

Sharkly를 한 문장으로 설명하면? Sharkly는 AI 코딩 에이전트를 할당하고 추적할 수 있는 팀원으로 바꿔주는 올인원 Agent 명령 및 관리 플랫폼으로, Task를 할당하고 여러 Agent를 병렬로 실행하며 요청부터 릴리스까지 컨텍스트, 진행 상황, 결과, 사람의 리뷰를 모두 확인할 수 있게 유지합니다.

Sharkly가 Claude Code나 Codex를 대체하나요? 아닙니다. Sharkly는 Claude Code, Codex 또는 다른 실행 도구를 대체하지 않습니다. 그 도구들이 실행을 담당하고, Sharkly는 그 주위에 공유 작업, 컴퓨터, 컨텍스트, 제어, 리뷰 계층을 더합니다.

Sharkly를 통해 모델 비용을 따로 내야 하나요? 아닙니다. 모델 사용은 연결한 코딩 도구에 설정된 구독이나 API 키를 통해 계속 이뤄집니다. 모델 할당량은 팀이 이미 보유한 플랜과 API 계정에 따라 달라집니다.

에이전트의 코드는 실제로 어디에서 실행되나요? 직접 연결한 컴퓨터에서 실행되며, Sharkly Desktop을 통한 로컬 또는 Sharkly CLI를 통한 원격 방식입니다. 각 실행에는 격리된 git 워크트리가 부여되므로 병렬 Agent가 충돌하지 않고, 승인하기 전까지 변경 사항이 격리된 상태로 유지됩니다.

단일 Agent 대신 Crew를 언제 사용해야 하나요? 작고 명확하게 정의된 작업이라면 Task를 하나의 Agent에 할당하세요. 리더 Agent가 포괄적인 목표를 해석하고, 다른 Agent 멤버를 참여시키고, 그 결과를 하나의 Task로 모아야 할 때 Crew를 사용하세요. 단순하게 시작하세요. 단일 Agent 경로는 첫 작업 가이드에서 확인할 수 있습니다.

이것은 완전한 자율성인가요? 에이전트가 스스로 머지하나요? 아닙니다. Agent는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. 최종 승인과 릴리스 결정은 사람이 담당합니다.

Jira를 계속 사용할 수 있나요? 네. 팀이 이미 사용하는 프로젝트, 작업, 상태, 워크플로를 그대로 유지하고 Sharkly를 연결하면, Agent 실행이 이미 익숙한 시스템 안에서 작업을 진전시킵니다.