10분 만에 Sharkly 시작하기

Sharkly를 시작하는 데는 약 10분이면 충분합니다. 컴퓨터를 연결하고, 에이전트를 만들고, 작은 태스크 하나를 할당하면 됩니다. Sharkly는 사람과 에이전트를 위한 업무 관리 시스템입니다. Claude Code, Codex 같은 AI 코딩 도구를 공유 태스크 시스템 안에서 할당 가능한 팀원으로 바꿔주기 때문에, 실행 과정이 개인 터미널 속으로 사라지는 일이 없습니다. 첫 실행 전체 과정은 다음과 같습니다.

1. 로그인하고 활성 스페이스가 하나 있는 조직을 만들거나 참여합니다.
2. Sharkly Desktop 또는 Sharkly CLI를 통해 컴퓨터를 연결합니다.
3. Claude Code 등 하나 이상의 런타임이 사용 가능으로 표시되는지 확인합니다.
4. 역할 범위가 좁고 지침이 명확한 에이전트를 만듭니다.
5. 작고 범위가 분명한 태스크를 작성해 에이전트에게 할당합니다.
6. 태스크에서 결과를 검토하고 후속 댓글로 답합니다.

이 가이드의 나머지 부분에서는 각 단계를 순서대로 살펴보고, 그 바탕이 되는 네 가지 개념을 설명하며, 첫 실행이 끝났을 때 무엇을 확인해야 하는지 알려드립니다. 끝까지 읽고 나면 병렬 실행, 공유 스킬, 스프린트로 확장해 나갈 수 있는 작동하는 루프를 갖추게 됩니다.

Sharkly와 보내는 첫 10분이 중요한 이유

대부분의 팀은 이미 AI 코딩 에이전트를 사용하고 있습니다. 문제는 그 작업이 어디에서 일어나느냐입니다. 한 사람의 터미널 안에서, 다른 누구에게도 보이지 않는 곳에서 말이죠. 누군가 Jira 티켓을 채팅창에 붙여넣고, 에이전트를 실행하고, diff를 다시 붙여넣지만 변경의 근거는 어디에도 남지 않습니다. 여기에 개발자 다섯 명과 서로 다른 에이전트 도구 세 개를 곱하면, 기록 없는 결과만 남습니다.

Sharkly는 팀의 관점에서 이 문제에 접근합니다. 또 하나의 코딩 에이전트가 아닙니다. 공식 설명은 그 경계를 분명히 긋습니다. Sharkly는 Claude Code, Codex 또는 다른 실행 도구를 대체하지 않습니다. 팀이 이미 사용하는 도구 주위에 공유 태스크, 컨텍스트, 제어, 리뷰 계층을 더하는 것입니다. 실행은 그 도구들이 담당하고, Sharkly는 할당, 연결된 컴퓨터, 태스크 컨텍스트, 진행 상황, 블로커, 결과, 그리고 사람의 리뷰를 이들 전반에 걸쳐 관리합니다.

첫 10분이 지금과 같은 구조로 짜여 있는 이유가 여기에 있습니다. 새로운 AI를 설치하는 것이 아닙니다. 이미 가지고 있는 AI를 공유 기록 시스템에 연결하는 것입니다. 그러면 모든 실행이 요청부터 릴리스까지 컨텍스트, 진행 상황, 블로커, 결과, 사람의 리뷰를 계속 눈에 보이게 유지합니다. 전체적인 포지셔닝을 먼저 알고 싶다면 Sharkly란 무엇인가?를 읽고 돌아오세요. 이 가이드는 실습에 집중합니다.

모든 Sharkly 구성의 바탕이 되는 네 가지 개념

이 모델 전체를 떠받치는 네 개의 명사가 있습니다. 이것만 제대로 이해하면 이후에 헷갈릴 일이 없습니다.

태스크는 Sharkly의 주요 작업 단위입니다. 목표와 설명, 상태, 우선순위, 라벨, 담당자, 실행을 맡은 에이전트 또는 크루, 댓글, 첨부파일, 그리고 전체 실행 상태와 추적 기록을 담습니다.

에이전트는 일회성 프롬프트가 아니라 저장된 작업 구성입니다. 한 사람이 공들여 만든 설정(지침, 연결된 리포지토리, 환경, 타임아웃)은 에이전트를 공유하면 스페이스 전체에서 재사용할 수 있습니다.

컴퓨터는 실행 호스트를 제공합니다. 작은 로컬 서비스가 컴퓨터를 Sharkly에 연결하고, 설치된 에이전트 도구를 감지하고, 작업을 받아 태스크 디렉터리를 준비하고, 선택된 런타임을 시작하고, 진행 상황을 실시간으로 되돌려 보냅니다. 연결은 로컬 서비스가 외부를 향해 시작하므로 일반적인 구성에서는 인바운드 포트가 필요하지 않습니다.

이런 관심사의 분리가 바로 설계 의도입니다. 에이전트는 작업 처리 방식을 정의하고, 컴퓨터는 호스트와 로컬 리소스를 제공하고, 런타임은 세션을 수행하고, 태스크는 팀을 위한 공유 기록으로 남습니다. 코드와 자격 증명은 여러분이 통제하는 머신에 그대로 남습니다.

시작하기 전에 필요한 것

사전 준비 사항은 간단합니다.

• Sharkly 계정과 조직
• 최소 하나의 활성 스페이스
• Sharkly Desktop 또는 로컬 서비스를 실행할 수 있는 컴퓨터
• 해당 머신에 설치되고 인증된 지원 런타임(예: Claude Code, Codex, Gemini CLI)
• 첫 태스크가 비공개 리포지토리를 다룬다면 해당 머신의 Git 접근 권한

모델과 관련해 두 가지만 짚고 넘어가겠습니다. 첫째, 구독은 직접 준비해야 합니다. 모델 사용량은 해당 도구에 설정된 구독이나 API 키를 통해 계속 처리되며, 할당량은 팀이 연결한 플랜과 계정에 따라 달라집니다. 둘째, 에이전트는 런타임의 기본 모델을 따릅니다. 모델 선택기를 따로 제공하지 않으므로, 모델을 바꾸려면 에이전트가 아니라 런타임 자체의 설정에서 변경해야 합니다.

컴퓨터를 연결하지 않고도 태스크를 정리할 수는 있습니다. 하지만 에이전트는 사용 가능한 런타임이 온라인 상태가 되기 전까지 작업을 실행할 수 없습니다. 컴퓨터 연결이 첫 번째 단계인 데는 이유가 있습니다.

조직에 아직 활성 스페이스가 없다면 Sharkly가 생성 과정을 안내합니다. 작업 카테고리를 선택하면 적절한 태스크 유형이 기본으로 설정됩니다. 소프트웨어 개발의 경우 요구사항(Requirement), 버그(Bug), 태스크(Task), 사용자 스토리(User Story)로 시작합니다. 첫 스페이스는 기본적으로 조직에 공개되며, 나중에 접근 권한을 더 엄격하게 조정할 수 있습니다.

1단계: 컴퓨터 연결하기

설정(Settings)에서 컴퓨터(Computers)로 이동해 컴퓨터 연결(Connect Computer)을 선택합니다. 거의 모든 경우를 아우르는 두 가지 방법이 있습니다.

• Sharkly Desktop — 지원되는 개인 컴퓨터용입니다. 설치하고 로그인하면 머신을 등록하고 로컬 서비스를 대신 시작해 줍니다.
• Sharkly CLI + 로컬 서비스 — 원격 호스트나 Linux 머신용입니다. 연결 대화상자에서 일회용 설치 토큰을 생성한 뒤, 대상 머신에서 생성된 명령을 실행합니다.

sharkly computer register --install-token sit_9f2ka7x1mrq8

설치 토큰은 수명이 짧고 한 번만 사용할 수 있습니다. 재사용 가능한 이미지나 스크립트, 태스크, 댓글에 넣지 마세요. 또한 설치 토큰의 역할은 딱 하나입니다. 컴퓨터를 등록할 뿐, 사람이 사용하는 CLI 로그인을 만들지는 않습니다. CLI 로그인은 개인 액세스 토큰(shk_로 시작)이 별도로 처리합니다.

컴퓨터가 연결됨으로 표시될 때까지 기다린 다음 상세 페이지를 확인합니다. 감지된 각 런타임은 사용 가능(Available), 설정 필요(Needs configuration), 미설치(Not installed), 지원되지 않음(Unsupported) 중 하나의 기능 상태를 보고합니다. 이 구분 덕분에 초기에 흔히 겪는 혼란을 피할 수 있습니다. 컴퓨터가 온라인이라는 것은 로컬 서비스가 하트비트를 보내고 있다는 뜻일 뿐입니다. 선택한 런타임이 태스크를 실행할 수 있다는 의미는 아닙니다. 나중에 실행이 시작되지 않는다면 연결을 점검하기 전에 런타임의 기능 상태를 먼저 확인하세요.

터미널에서도 확인할 수 있습니다.

sharkly computer list
sharkly computer show cmp_4c81d2
sharkly computer ping cmp_4c81d2 rt_claude_code

컴퓨터 문서에서는 진단, 사용자 지정 런타임, 가시성, 정리 설정을 자세히 다룹니다.

2단계: 첫 에이전트 만들기

에이전트(Agents) 메뉴에서 새 에이전트(New Agent)를 선택합니다. 모든 걸 다 하는 만능 어시스턴트를 만들고 싶은 유혹을 참으세요. 좁은 역할로 시작하는 것이 좋습니다. 간결한 설명은 사람에게 무엇을 할당하면 되는지 알려주고, 지침은 에이전트에게 어떻게 일할지 알려주기 때문입니다.

좋은 첫 구성은 다음과 같습니다.

• 이름: Code Reader
• 설명: 리포지토리를 읽고 현재 구현을 설명하며, 파일을 변경하지 않고 위험 요소를 보고합니다.
• 공개 범위: 개인(Personal) 또는 에이전트를 사용할 스페이스
• 컴퓨터 및 런타임: 1단계에서 확인한 연결

지침의 경우, 퀵스타트의 예시를 거의 그대로 복사할 만합니다.

행동하기 전에 태스크 전체와 관련 댓글을 읽으세요. 요청 범위를 벗어나지 마세요. 첫 태스크에서는 파일을 편집하지 마세요. 무엇을 검토했는지, 각 결론의 근거가 무엇인지, 아직 불확실한 부분이 무엇인지 보고하세요.

지침이 다루는 범위에 주목하세요. 범위, 행동 전 검토 방법, 보고 형식입니다. 이게 적절한 수준입니다. 안정적인 동작은 에이전트 지침에, 태스크별 요구사항은 태스크 설명에, 여러 에이전트가 공유하는 재사용 가능한 절차는 스킬에 넣으세요. 이 세 계층을 분리해 두는 것이 에이전트를 깨지기 쉬운 존재가 아니라 재사용 가능한 존재로 만듭니다.

3단계: 리포지토리 또는 작업 디렉터리 추가하기

에이전트가 코드를 읽어야 한다면 읽을 코드가 필요합니다. 두 가지 선택지가 있습니다.

• Git 리포지토리를 에이전트에 연결합니다(또는 태스크의 스페이스에 구성된 리포지토리를 사용합니다). 리포지토리 기반 실행은 태스크마다 새 git 워크트리를 준비할 수 있으며, 이것이 나중에 안전한 병렬 실행을 가능하게 하는 요소입니다.
• 로컬 컴퓨터에 지정 디렉터리를 구성합니다. 실행할 때 새 복사본을 준비하는 대신 이미 그 자리에 있는 코드, 의존성, 캐시, 도구를 재사용합니다.

판단 기준은 이렇습니다. 대부분의 리포지토리 작업과 여러 태스크가 같은 코드베이스를 병렬로 수정할 가능성이 있을 때는 임시 워크트리 기반 디렉터리를 사용하세요. 실행에 재구축 비용이 큰 환경이 필요할 때는 지정 디렉터리를 사용하되, 지정 디렉터리는 한 번에 하나의 실행만 처리한다는 점을 기억하세요. 작동 원리가 궁금하다면 워크트리가 병렬 에이전트 간 충돌을 어떻게 막는지를 자세히 설명한 글을 준비해 두었습니다.

4단계: 에이전트가 실행할 수 있는 태스크 작성하기

같은 스페이스에 태스크를 만듭니다. 퀵스타트의 예시는 일부러 밋밋하게 만들어졌는데, 바로 그게 핵심입니다.

제목: 인증 오류 경로 검토

설명: 현재 인증 구현을 읽고 사용자에게 드러나는 실패 사례 세 가지를 찾아내세요. 파일을 변경하지 마세요. 각 사례마다 관련 파일이나 컴포넌트를 인용하고 예상 동작을 설명하세요. 구현 전에 답해야 할 질문이 있다면 마지막에 정리하세요.

이 태스크에는 좋은 첫 태스크가 갖춰야 할 세 가지 속성이 모두 있습니다. 경계가 명확하고(읽기만, 편집 금지), 검토 가능한 결과를 내놓으며(근거가 있는 사례 세 가지), 위험이 낮아 코드베이스를 걸지 않고도 에이전트의 판단력을 평가할 수 있습니다. 리포지토리에 인증 코드가 없다면 설정 로딩이나 빈 상태 컴포넌트처럼 실제로 존재하는 작은 영역으로 주제를 바꾸면 됩니다.

이렇게 소프트웨어에 작업을 할당하는 방식은 프롬프트를 넣는 것과 느낌이 다르며, 그래야 합니다. 프롬프트는 대화이고, 태스크는 검토 가능한 결과물을 담보로 하는 계약입니다. 이 루프가 한 번 돌아가면 같은 형태를 실제 티켓으로 확장할 수 있습니다. Jira 티켓을 AI 에이전트에 할당하기 워크스루에서 실전 버전을 확인할 수 있습니다.

5단계: 태스크 할당하고 실행 지켜보기

태스크의 담당자(Assignee) 컨트롤을 열고 에이전트를 선택합니다. 사람, 에이전트, 크루 모두 담당자가 될 수 있으며, 에이전트를 선택하면 그 에이전트가 실행 담당자가 됩니다.

실행 시작 시점을 결정하는 상태 규칙이 하나 있습니다. 에이전트에 할당된 태스크라도 백로그(Backlog)에 있는 동안에는 실행이 시작되지 않습니다. 백로그는 작업을 준비해 두는 대기 공간입니다. 태스크를 작업 가능한 상태(미시작 또는 시작됨)로 옮기면 컴퓨터와 런타임이 준비되는 대로 Sharkly가 실행을 대기열에 넣습니다. 완료, 취소, 중복 상태에서는 최초 실행이 절대 시작되지 않습니다.

실행이 진행되는 동안 태스크는 실행 상태를 표시합니다. 대기열 등록(queued), 디스패치됨(dispatched), 실행 중(running), 그리고 완료(completed), 실패(failed), 취소됨(canceled) 순입니다. 리포지토리 기반 실행은 먼저 코드를 체크아웃하고 격리된 디렉터리를 준비하는 데 잠시 시간이 걸릴 수 있습니다. 화면은 세 가지로 볼 수 있습니다.

• 채팅(Chat) — 에이전트와 댓글 형식으로 주고받는 대화
• 활동(Activity) — 댓글과 태스크 변경 사항을 하나의 타임라인으로 확인
• 실행(Executions) — 실행 이력과 전체 추적 기록(도구 호출, 런타임 이벤트, 트리거 출처, 실패 상세)

실행 상태와 태스크 상태는 연관되어 있지만 별개입니다. 태스크 상태가 여전히 진행 중(In Progress)인데 실행은 실행 중(Running)일 수 있습니다. 하나는 실행 진행 상황을, 다른 하나는 워크플로상의 위치를 나타내기 때문입니다.

6단계: 구경꾼이 아니라 리뷰어처럼 결과 검토하기

에이전트의 최종 응답은 실행 추적과 연결된 댓글로 태스크에 돌아옵니다. 여기서부터 계약의 사람 쪽이 시작됩니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 받아들입니다.

에이전트가 다음을 했는지 확인하세요.

• 의도한 코드나 소스 자료를 검토했는지
• 편집 금지 경계를 지켰는지
• 각 결론에 근거를 제시했는지
• 추측 대신 불확실한 부분을 기록했는지
• 팀원이 활용할 수 있는 결과를 태스크에 남겼는지

다시 손볼 필요가 있다면 핵심만 담은 댓글로 답하세요. 여전히 해당 에이전트에 할당된 태스크에 적격한 댓글을 달면 후속 실행이 시작되며, 연달아 달린 댓글은 하나로 합쳐져 중복 대기 실행이 생기지 않습니다. 에이전트가 여러분의 의견이나 검토를 필요로 하면 그 요청이 인박스(Inbox)에 표시되는데, 인박스는 답변이 필요한 항목과 우선순위가 낮은 업데이트를 구분해 줍니다.

결과가 타당하다면 태스크를 완료로 표시하세요. 그러면 설정 체크리스트가 추적하는 첫 번째 루프가 완성됩니다. 컴퓨터 연결, 에이전트 생성, 리포지토리 준비, 태스크 생성, 할당, 완료입니다.

첫 루프 이후: 설정을 확장하는 다섯 가지 방법

첫 실행은 기본 배관이 제대로 연결됐음을 증명합니다. 이후 단계들은 각각 하나씩 차원을 더합니다.

여러 태스크를 동시에 실행하려면 어떻게 해야 하나요?

동시성은 신중하게 올리세요. 임시 디렉터리를 사용할 경우 기본 동시성은 컴퓨터 한도의 절반이며, 각 태스크에 격리된 워크트리가 할당되어 병렬 실행이 충돌하지 않습니다. 한도를 높이기 전에 CPU, 메모리, 모델 제공자 용량을 확인하고, 직접 구축한 방식과의 비교가 궁금하다면 팀에서 여러 Claude Code 세션을 병렬로 실행하는 방법을 읽어보세요.

태스크 대신 에이전트 채팅을 써야 할 때는 언제인가요?

Sharkly는 의도적으로 두 가지 화면을 유지합니다. 작업을 추적할 필요가 없을 때는 채팅으로 에이전트와 탐색하고, 계획하고, 조사하세요. 작업에 책임 소재, 상태, 실행 이력, 리뷰가 필요하면 태스크를 사용하세요. 채팅에서 팀이 반드시 처리해야 할 결과가 나왔다면 태스크로 승격시켜 결과가 기록으로 남게 하세요.

크루는 언제 필요한가요?

크루(Crew)는 리더 에이전트 하나가 조율하는, 사람과 에이전트로 이루어진 재사용 가능한 그룹입니다. 작고 명확하게 정의된 작업이라면 태스크를 에이전트 하나에 바로 할당하고 변수를 최소화하세요. 리더가 목표를 해석하고, 전문 멤버들을 참여시키고, 그 결과를 하나의 태스크로 모아야 할 때 크루를 사용하세요.

스킬이 지침 수정보다 나은 경우는 언제인가요?

여러 에이전트가 같은 절차(리뷰 체크리스트, 마이그레이션 패턴, 보고 형식 등)를 필요로 할 때는 이를 스킬로 옮기고 필요한 곳에 연결하세요. 한 개발자의 노하우가 개인 프롬프트를 넘어 조직의 인프라가 됩니다.

나머지 팀원들은 어떻게 하나요?

위의 모든 내용은 혼자서도 작동합니다. 태스크가 공유 스페이스에 있고, 스프린트가 작업을 주기별로 묶고, 팀원들이 사람이 하는 업무에 이미 쓰던 것과 같은 화면에서 에이전트 결과를 검토할 때 효과가 배가됩니다. Sharkly의 프로젝트 계층(스페이스, 프로젝트, 스프린트, 칸반 및 목록 보기)은 워낙 표준적이라 따로 교육받을 필요도 없습니다.

오늘의 상황에서 Sharkly가 맞지 않는 도구일 때

경계를 솔직하게 긋는 것이 시간을 아껴줍니다. 개발자 한 명이 리포지토리 하나에서 에이전트 하나를 돌리는 상황이라면, 오늘은 터미널과 브랜치 하나면 충분할 수 있습니다. 조정 계층은 실행이 늘어날 때 제값을 합니다. 에이전트가 둘 이상이거나, 결과를 봐야 할 사람이 둘 이상이거나, 병합 전 리뷰가 필요한 작업일 때 말입니다.

직접 만든 도구에도 같은 논리가 적용됩니다. 자체 제작한 tmux 세션과 워크트리 스크립트는 실제로 잘 작동합니다. 팀이 그런 방식에서 벗어나는 시점은 보이지 않던 부분(누가 무엇을 실행했고, diff는 어디로 갔고, 누가 승인했는지)이 스크립트가 아껴주는 비용보다 더 크게 느껴질 때입니다. 그리고 팀이 특정 벤더의 생태계 안에서 처음부터 끝까지 움직인다면, 그 벤더 자체의 오케스트레이션을 먼저 검토하세요. Sharkly는 도구, 머신, 사람을 섞어 쓰는 상황에서 가장 강력합니다. 세 가지 모두에 중립적이기 때문입니다. 이 분야의 더 넓은 맥락이 궁금하다면 에이전틱 코딩이란 무엇인가?를 참고하세요.

어떤 경우에도 변하지 않는 원칙이 있습니다. 팀이 이미 쓰는 도구는 그대로 두세요. Sharkly의 도입 방식은 그 도구들 주위에 눈에 보이고 검토 가능한 계층을 더하는 것이지, 밑에 깔린 워크플로를 대체하는 것이 아닙니다.

실제로 효과를 보는 세 가지 첫 실행

신중한 플랫폼 팀. DevEx 엔지니어가 공용 Linux 컴퓨터 하나를 연결하고, 읽기 전용 Code Reader 에이전트를 만든 뒤, 일주일 동안 팀원들이 조사 태스크를 할당하도록 합니다. 보고서가 신뢰할 만하다는 것이 입증되기 전까지는 아무도 쓰기 권한을 부여하지 않습니다. 실행 추적 덕분에 에이전트의 판단을 들여다볼 수 있어 도입이 자연스럽게 퍼집니다.

규모를 키우는 1인 개발자. 개발자 한 명이 노트북을 연결하고 두 개의 에이전트(하나는 구현용, 하나는 리뷰용)를 만들어, 즉흥적인 프롬프트 대신 작은 버그들을 태스크로 처리하기 시작합니다. 당장의 성과는 속도가 아닙니다. 이제 모든 수정에 설명과 diff, 추적 기록, 무엇을 확인했는지에 대한 기록이 남는다는 점입니다.

Jira 중심의 팀. 엔지니어링 매니저가 계획의 기준으로 Jira를 그대로 유지하면서 Sharkly를 연결해 티켓이 실행 가능한 태스크가 되게 합니다. 개발자들은 더 이상 티켓 컨텍스트를 터미널에 복사해 붙여넣지 않습니다. 결과, 블로커, 리뷰 요청은 매니저가 볼 수 있는 태스크로 돌아옵니다.

다음 10분

가장 작은 단위의 유용한 Sharkly 워크플로는 의도적으로 작습니다. 컴퓨터 하나를 연결하고, 에이전트 하나를 만들고, 위험도가 낮은 태스크 하나를 할당하는 것입니다. 모든 고급 기능(병렬 워크트리, 크루, 스킬, 자동화, 스프린트)은 이 루프를 바꾸지 않고 그 위에 쌓입니다.

그러니 루프를 한 번 돌려보세요. 컴퓨터 하나를 연결하고, 에이전트 하나를 만들고, 지루한 일 하나를 맡기세요. 새로 합류한 팀원의 첫 PR을 리뷰하듯 결과를 살펴보세요. 주의를 기울이고, 경계를 정하고, 후속 질문을 던지면서요. 그런 다음 근거를 바탕으로 다음에 무엇을 허용할지 결정하세요. 시작할 준비가 되면 문서의 퀵스타트에서 최신 스크린샷과 함께 같은 단계를 확인할 수 있습니다.

자주 묻는 질문

Sharkly는 어떤 코딩 에이전트와 함께 쓸 수 있나요?

Sharkly는 연결된 컴퓨터에 설치된 지원 에이전트 도구를 감지해 각각을 런타임으로 보고합니다. Claude Code, Codex, Gemini CLI, OpenCode 등이 공식 문서에서 언급되는 도구들입니다. 컴퓨터 상세 페이지에서 해당 머신이 현재 지원하는 목록을 런타임별 설치 가이드 링크와 함께 확인할 수 있으며, 도구가 자동으로 감지되지 않으면 사용자 지정 ACP 런타임을 추가할 수 있습니다.

Sharkly가 Claude Code나 Codex를 대체하나요?

아니요. Sharkly는 Claude Code, Codex 또는 다른 실행 도구를 대체하지 않습니다. 실제 에이전트 세션은 여러분의 컴퓨터에서 그 도구들이 수행합니다. Sharkly는 그 도구들 주위에 공유 계층을 더합니다. 팀 단위 할당, 태스크 컨텍스트, 진행 상황, 결과, 사람의 리뷰입니다. 이미 사용 중인 에이전트 도구와 계정은 그대로 쓰시면 됩니다.

Sharkly는 비용이 얼마인가요?

Sharkly의 방식은 구독 직접 준비(BYOS)입니다. 모델 사용량은 에이전트 도구에 설정된 구독이나 API 키를 통해 처리되고, 할당량은 팀이 연결한 플랜에 따라 달라집니다. 이 글에서는 요금을 다루지 않으므로, 현재 제품 플랜은 sharkly.ai에서 직접 확인하세요.

제 코드와 자격 증명이 Sharkly 서버를 거치나요?

실행은 여러분이 연결한 컴퓨터, 즉 노트북이나 서버, 컨테이너에서 이루어집니다. 컴퓨터가 운영체제, 파일, 자격 증명, 도구를 제공하고, 로컬 서비스가 진행 상황과 결과를 태스크로 스트리밍합니다. 리포지토리는 해당 컴퓨터에 구성된 Git 접근 권한으로 가져옵니다.

에이전트가 실행을 시작하지 않는 이유는 무엇인가요?

흔한 원인 세 가지를 순서대로 확인하세요. 첫째, 태스크가 백로그에 있을 수 있습니다. 할당된 태스크는 작업 가능 상태로 옮길 때까지 백로그에서 대기합니다. 둘째, 런타임을 사용할 수 없을 수 있습니다. 컴퓨터가 온라인이라는 것은 하트비트만 확인해 줄 뿐이므로, 컴퓨터 상세 페이지를 열어 런타임의 기능 상태를 확인하세요. 셋째, 용량이 가득 찼을 수 있습니다. 동시성이나 디렉터리 한도에 도달하면 에이전트가 온라인이어도 작업이 대기열에 쌓일 수 있습니다.

두 에이전트가 같은 리포지토리에서 동시에 작업할 수 있나요?

네, 임시 작업 디렉터리를 사용하면 가능합니다. 각 태스크에 격리된 디렉터리가 할당되고, 리포지토리 기반 실행은 실행마다 별도의 git 워크트리를 준비해 동시 실행 태스크 간 간섭을 줄입니다. 지정 디렉터리는 반대입니다. 구성된 경로 하나는 한 번에 하나의 실행만 처리합니다.

원격 서버에서 Sharkly 에이전트를 실행할 수 있나요?

네. 원격 호스트에 Sharkly CLI와 로컬 서비스를 설치한 다음, 컴퓨터 페이지에서 발급한 일회용 설치 토큰으로 등록하세요. 로컬 서비스가 Sharkly로 외부 연결을 시작하므로 일반적인 구성에서는 인바운드 포트가 필요하지 않습니다. 원격 컴퓨터는 팀 공용 용량에, 노트북은 개인 실험에 적합합니다.

첫 태스크는 무엇이어야 하나요?

경계가 명확하고 검토 가능한 결과물이 있는 읽기 전용 작업이 좋습니다. 문서에서는 파일을 편집하지 않고 인증 오류 경로를 검토해 사용자에게 드러나는 실패 사례 세 가지를 근거와 함께 보고할 것을 권장합니다. 코드베이스의 작고 실제적인 영역이라면 무엇이든 괜찮습니다. “코드 개선” 같은 모호한 첫 태스크는 피하세요. 범위를 정하지 않은 것은 검토할 수도 없습니다.