Gemini CLI 세션 하나는 하나의 디렉터리에서 동작하는 단일 에이전트입니다. 리팩터링이 돌아가는 동안 버그를 고치고, 기능이 배포되는 동안 테스트를 작성하는 식으로 두 번째 작업을 동시에 진행하고 싶어지는 순간, 터미널을 하나 더 열게 됩니다. 그러다 세 번째도 열게 되죠. 한 시간이 지나면 탭 네 개, 작업 디렉터리 네 개가 생기지만, "어떤 에이전트가 무엇을 하고 있고, 방금 내가 수정하려던 파일을 건드린 건 누구인가"라는 단순한 질문에 명쾌하게 답할 방법이 없습니다.
여러 Gemini 작업을 나란히 실행하는 것은 시작하기는 어렵지 않습니다. 어려운 건 상황을 정리해 파악하는 것입니다. 각 인스턴스 자체는 빠릅니다. 비용은 조정(coordination)에서 발생하는데, 바로 그 조정을 터미널은 결코 제공해 주지 않습니다.
이 글에서는 병렬 Gemini CLI 에이전트를 위한 수동 설정 과정을 살펴보고, 각 단계마다 도사리고 있는 실패 유형을 짚은 뒤, 태스크 보드가 어디서부터 그 역할을 대신하는지 보여 드립니다. 그 태스크 보드가 바로 올인원 Agent 명령 및 관리 플랫폼인 Sharkly입니다. Sharkly는 Gemini CLI를 대체하는 도구가 아닙니다. 팀이 이미 사용 중인 런타임 주위에 공유 Task, Computer, 컨텍스트, 리뷰 계층을 더해 주어, 병렬 실행이 여러 탭에 흩어지지 않고 할당 가능하고 추적 가능한 상태로 유지되도록 합니다.
Gemini CLI에서 "병렬 에이전트"란 무엇인가
Gemini CLI는 프로세스당 하나의 에이전트를 실행합니다. 현재 디렉터리를 읽고, GEMINI.md 컨텍스트 파일이 있으면 로드한 뒤, 그 하나의 작업 트리 안에서 프롬프트를 처리합니다. 하나의 목표를 여러 하위 에이전트로 분산시키고 그 결과를 다시 병합해 주는 내장 디스패처는 없습니다.
따라서 "병렬 Gemini 에이전트"는 실질적으로 한 가지를 의미합니다. 각자 격리된 환경에서 자기 작업을 수행하는 여러 gemini 프로세스가 동시에 실행되는 것입니다. Gemini CLI는 오픈 소스이고 개인 Google 계정으로 무료로 실행할 수 있어서, 사람들이 한 번에 네 개씩 띄우는 겁니다. 병목은 애초에 이들을 시작하는 데 있지 않았습니다. 네 개의 독립적인 실행이 같은 저장소에서 충돌하지 않게 관리하고, 한 시간 뒤에 각각이 무엇을 만들어냈는지 아는 것이 진짜 문제입니다.
이것은 Claude Code나 Codex에서 마주치는 것과 똑같은 조정 문제입니다. 런타임은 바뀌어도 혼란은 그대로입니다.
단계별 수동 설정
다음은 병렬 Gemini CLI의 가장 작은 동작 버전이며, 각 단계에서 깨지는 지점도 함께 짚었습니다.
1단계: 각 에이전트에 자체 작업 트리를 부여하세요. 같은 폴더에서 두 에이전트를 실행하지 마세요. 작업마다 git worktree를 사용해 각 체크아웃이 물리적으로 분리되게 하세요:
git worktree add ../repo-auth feature/auth
git worktree add ../repo-tests chore/tests
git worktree add ../repo-bugfix fix/login-redirect
건너뛸 경우의 실패 유형: 하나의 체크아웃을 편집하는 두 에이전트가 실행 도중 서로를 덮어씁니다. 한쪽이 다른 쪽이 절반쯤 작업한 파일을 재포맷하고, 결국 둘 다 의도하지 않은 상태로 트리를 남깁니다. 워크트리는 각 에이전트에 깨끗한 브랜치와 깨끗한 디렉터리를 제공합니다. 이 내용은 AI 코딩 에이전트를 위한 git worktrees에서 더 자세히 다룹니다.
2단계: 워크트리마다 Gemini CLI 하나씩 시작하세요. 각 디렉터리에서 터미널을 열고 세션을 실행하세요:
cd ../repo-auth && gemini
무인 실행의 경우 비대화형 모드를 사용하면 에이전트가 단일 프롬프트를 받고 종료합니다:
cd ../repo-tests && gemini -p "Add unit tests for the session module. Run the suite before finishing."
실패 유형: 대화형 세션은 첫 번째 권한 프롬프트에서 멈춰 대기합니다. 20분 뒤 돌아와 보면 "예" 한 번이 필요해서 아무것도 하지 않은 에이전트를 마주하게 됩니다. 어떤 실행을 대화형으로, 어떤 실행을 헤드리스로 할지 미리 정하고, 헤드리스 실행에는 자체 검증 단계가 포함된 프롬프트를 주세요.
3단계: 작업별로 컨텍스트를 격리하세요. 각 워크트리는 해당 작업의 규칙—무엇을 건드리고, 무엇을 그대로 두고, 테스트를 어떻게 실행할지—을 담은 자체 GEMINI.md를 가질 수 있습니다.
실패 유형: 모든 에이전트가 하나의 컨텍스트 파일을 공유하면 인증 작업을 위한 지시가 테스트 작업으로 새어 들어갑니다. 컨텍스트는 그것이 속한 트리에만 적용되도록 범위를 한정하세요.
4단계: 할당량을 주시하세요. 실행 중인 모든 인스턴스가 동일한 계정 한도를 소모합니다. 네 에이전트가 큰 리팩터링을 처리하면 한 에이전트보다 훨씬 빨리 속도 제한에 걸리고, 제한된 에이전트는 보고 있지 않은 탭에서 조용히 실패합니다.
실패 유형: 할당량 오류로 실행이 멈추는데, 그 탭을 확인하기 전까지는 알아차리지 못합니다. 에이전트가 멈췄다는 걸 알려 주는 공유 뷰가 없습니다. 더 무거운 작업에 적합한 모델을 매칭하는 방법은 어떤 코딩 작업에 어떤 모델을 쓸까에서 그 트레이드오프를 다룹니다.
작업이 서너 개일 때는 이 방식이 통합니다. 진짜 브랜치, 진짜 격리, 진짜 병렬성이며 추가 도구도 필요 없습니다.
직접 구축한 설정이 확장되지 못하는 지점
수동 설정이 무너지는 건 실행 자체가 아니라 그 주변의 모든 것에서입니다. 작업 수가 늘어나면 무슨 일이 벌어지는지 보세요.
전체 지도를 잃습니다. 터미널 네 개라면 머릿속으로 파악할 수 있습니다. 하지만 두 개의 저장소에 걸쳐 여덟 개가 되면 불가능합니다. 어느 탭이 인증 에이전트인가? 테스트 실행이 끝난 건가, 아니면 할당량 오류로 죽은 건가? 병렬로 실행되는 코딩 에이전트 모니터링은 터미널이 애초에 하도록 만들어진 일이 아닙니다.
결과가 흩어집니다. 각 에이전트는 작업을 브랜치 위의 diff와, 곧 닫아 버릴 탭 속 스크롤백 더미로 남깁니다. 각 실행이 무엇을 왜 바꿨는지, 자체 테스트를 통과했는지에 대한 공유 기록이 없습니다. 동료가 로그인 수정이 무엇을 했는지 물으면, 그 답은 이미 사라진 터미널 안에 있습니다.
리뷰에는 안식처가 없습니다. 병렬 에이전트는 병렬 diff를 만들어 내고, 그중 하나하나 여전히 사람이 승인해야 합니다. 요약도, 검증 결과도, 컨텍스트도 없이 브랜치 네 개를 읽는 데는 에이전트가 작업을 끝낸 시간보다 더 오래 걸립니다. 실행에서 얻은 속도를 리뷰에서 그대로 반납하는 셈입니다.
여기 솔직한 판단 기준 두 가지가 있습니다. 가끔 Gemini 작업을 서너 개 돌린다면 위의 워크트리 설정을 그대로 유지하세요. 단순하고 잘 동작하며, 태스크 보드는 오히려 불필요한 부담이 됩니다. 병렬 실행이 일상이 될 때 도입하세요. 에이전트 여러 개, 저장소 두 개 이상, 진행 상황을 봐야 하는 사람이 둘 이상, 그리고 기억이 아니라 추적 가능해야 하는 리뷰가 필요한 경우입니다. 그 시점이라면 병렬 에이전트를 관리하는 도구 비교를 해볼 만합니다.
태스크 보드가 더해 주는 것
태스크 보드는 작업의 단위를 "터미널 탭"에서 "Task"로 바꿉니다. 바로 이 한 가지 전환이 직접 구축한 설정에 빠져 있는 부분입니다.
Sharkly에서는 Gemini CLI를 기반으로 하는 Agent에 Task를 할당합니다. Agent가 Task를 가져가 격리된 워크트리에서 작업하고, 실행, 블로커, 결과, 후속 논의가 개인 터미널 속으로 사라지는 대신 Task 타임라인으로 돌아옵니다. 여러 개를 동시에 실행해도 각각이 찾아 헤매야 하는 탭이 아니라 눈에 보이는 행이 됩니다. 코딩은 여전히 Gemini CLI가 담당하고, Sharkly는 할당, 연결된 Computer, 컨텍스트, 그리고 모든 실행에 걸친 리뷰를 관리합니다.
역할 분담은 명확하게 유지됩니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. 자동화는 팀의 판단이 필요한 지점에서 멈추고, 각 실행은 변경 요약과 자체 검증 결과를 함께 가져오므로, diff를 승인할지 거부할지 판단하는 데 고고학적 발굴이 아니라 한 번의 눈길이면 충분합니다. 컨텍스트, 진행 상황, 블로커, 결과, 사람의 리뷰가 요청부터 릴리스까지 계속 눈에 보입니다.
이미 가진 것은 그대로 유지됩니다. Sharkly는 Gemini CLI를 떠나라고 하지도, 특정 런타임에 전념하라고 하지도 않습니다. 제공자 중립적이기 때문에 같은 태스크 보드에서 Gemini 에이전트 옆에 Claude Code와 Codex 에이전트를 함께 실행할 수 있어, 다음 최고의 에이전트가 무엇이든 여러분의 워크플로는 살아남습니다. 바로 그 중립성이 핵심입니다. 새로운 에이전트가 나올 때마다 생태계를 갈아타는 게 아니라, 한곳에서 여러분의 에이전트를 관리하는 것입니다.
오늘 바로 실행할 수 있는 체크리스트
다음번 병렬 Gemini 작업 묶음을 시작하기 전에 이 체크리스트를 확인하세요:
- [ ] 작업당 git worktree 하나, 절대 하나의 체크아웃에 두 에이전트를 두지 않는다.
- [ ] 모든 작업이 공유하는 파일 하나가 아니라, 각 작업에 범위가 한정된
GEMINI.md를 둔다. - [ ] 헤드리스 실행은
gemini -p를 사용하고 자체 검증 단계를 포함해 프롬프트에서 멈추지 않게 한다. - [ ] 공유 할당량 때문에 보이지 않는 실행이 제한되지 않도록 동시 인스턴스 수의 상한을 정해 둔다.
- [ ] 모든 탭을 열지 않고도 "어떤 에이전트가 무엇을 맡고 있고, 무엇이 끝났는지"에 답해 주는 단일 창구를 둔다.
- [ ] 완료된 모든 실행이 브랜치 위의 diff만이 아니라 사람이 리뷰할 수 있는 변경 요약과 테스트 결과를 남긴다.
앞의 네 가지는 오늘 밤 워크트리와 터미널만으로 할 수 있습니다. 마지막 두 가지야말로 수동 설정이 한계에 부딪히는 부분입니다. 이미 여러 Gemini CLI 에이전트를 동시에 실행하고 있다면, Sharkly는 그들의 작업을 할당하고 진행 상황을 지켜보고 결과를 리뷰할 수 있는 한곳을 제공합니다. 조정 계층을 직접 구축할 수도 있고, 기존 코딩 에이전트를 Sharkly로 실행해 확장되는 부분으로 곧장 건너뛸 수도 있습니다.
