AI 코딩 에이전트는 이제 관리 레이어의 문제다

조수 하나에서 작업 슬롯 여러 개로

AI 코딩을 처음 쓸 때의 관심은 보통 “어떤 에이전트가 코드를 더 잘 짜는가”에 붙는다. 그런데 Claude Code, Codex CLI, Gemini CLI 같은 도구를 병렬로 띄우기 시작하면 병목은 조금 다른 곳으로 옮겨간다. 한 에이전트의 답변 품질보다, 여러 작업이 동시에 굴러갈 때 사람이 무엇을 믿고 합칠 수 있는지가 더 큰 문제가 된다.

내가 관심을 두는 단위도 그래서 프롬프트 하나가 아니라 격리된 작업 슬롯 하나다. 슬롯은 목표·작업 디렉터리·브랜치·상태·결과물을 함께 묶는다. 즉, 병렬 AI 코딩의 실제 운영 단위는 “대화창”이 아니라 “검토 가능한 작은 작업장”에 가깝다.

worktree는 격리이지 운영 체계가 아니다

git worktree는 이 변화의 좋은 기반이다. Augment Code 글의 설명처럼 각 에이전트에 독립 작업 디렉터리와 git index를 주면 파일 충돌·컨텍스트 오염·락 경합을 줄일 수 있다. 같은 리포를 여러 방향으로 동시에 파는 데 필요한 기술적 격리는 여기서 나온다.

다만 worktree만으로 충분하다고 보기는 어렵다.

• 목표 추적: 어떤 에이전트가 어떤 의도로 시작됐는지 터미널 탭 이름만으로는 금방 흐려진다.
• 상태 판단: 실행 중인지, 막혔는지, 테스트만 남았는지 한 화면에서 보기 어렵다.
• 결과 비교: 여러 브랜치가 비슷한 파일을 건드렸을 때 무엇을 살릴지 사람이 다시 정리해야 한다.
• 병합 전 검토: 격리는 충돌을 늦출 뿐, 최종 판단을 대신하지 않는다.

격리와 관리는 다르다. worktree가 “서로 밟지 않게 한다”면, 관리 레이어는 “무엇이 끝났고 무엇을 합칠지 보이게 한다”.

새 카테고리의 신호

최근 병렬 AI 코딩 에이전트 관리 도구를 비교하는 글들이 보이는 것도 이 빈칸을 가리키는 신호로 읽힌다. 여기서 조심할 점은 있다. 비교 글 몇 개와 도구 하나만으로 “카테고리가 확정됐다”고 말할 수는 없다. 더 정확한 표현은 카테고리화 신호가 보인다는 정도다.

Parallel Code는 그 신호를 설명하기 좋은 사례다. EveryDev.ai 소개는 이 도구를 여러 AI 코딩 에이전트를 동시에 실행하고, 각 에이전트를 별도 git branch와 worktree에 격리하는 무료 MIT 라이선스 데스크톱 앱으로 설명한다. GitHub 설명도 Claude Code, Codex CLI, Gemini CLI, Copilot CLI 등을 한 인터페이스에서 다루는 흐름을 전면에 둔다.

이 사례가 보여주는 축은 단순하다.

축	기존 관심	관리 레이어의 관심
실행	에이전트에게 프롬프트를 준다	작업 슬롯을 만들고 격리한다
관찰	터미널 로그를 본다	상태판에서 진행·정지·완료를 본다
결과	코드가 생성된다	브랜치와 변경분을 비교한다
통제	에이전트가 알아서 한다	사람이 승인하고 병합한다

Taskery가 잡을 수 있는 언어

Taskery를 이 흐름 위에 놓으면 포지셔닝이 조금 선명해진다. “AI가 코드를 짜게 하는 도구”라고 말하면 이미 강한 CLI 에이전트들과 정면으로 겹친다. 반대로 “여러 AI 작업을 사람이 통제 가능한 단위로 운영하는 레이어”라고 말하면 역할이 달라진다.

여기서 Taskery의 핵심 언어는 태스크 관리와 실행 슬롯의 연결이다.

• 태스크: 사람이 의도와 완료 조건을 적는 단위다.
• 슬롯: 에이전트가 격리된 환경에서 실제로 움직이는 단위다.
• 리뷰: 결과물을 사람이 확인하고 살릴지 버릴지 결정하는 단위다.

⇒ Taskery는 에이전트를 대체하는 제품이 아니라, 여러 에이전트 작업을 승인 가능한 흐름으로 묶는 제품으로 설명할 때 힘이 생긴다.

물론 이 말은 Taskery가 이미 그런 기능을 제공한다는 뜻이 아니다. 지금 단계에서는 제품 방향의 언어화에 가깝다. 하지만 방향은 분명하다. 앞으로의 경쟁력은 더 똑똑한 에이전트 하나를 고르는 데서만 나오지 않는다. 여러 에이전트를 덜 위험하게 굴리고, 사람이 마지막 결정을 놓치지 않게 만드는 운영 체계에서 나온다.