터미널 창 하나를 열어 Claude Code를 띄우고, 또 다른 창에는 Codex를, 어쩌면 세 번째 창에는 Gemini CLI를 실행해 둡니다. 각 에이전트는 저마다 코드를 훌륭하게 작성합니다. 하지만 어떤 에이전트가 무슨 작업을 맡고 있는지, 회의하는 동안 무엇이 끝났고 무엇이 조용히 실패했는지, 혹은 사람이 검토해 주기만을 기다리며 브랜치에 방치된 코드가 무엇인지는 그 누구도 알려주지 못합니다. 이 빈틈을 채우는 영역이 바로 코딩 에이전트 관리(Coding Agent Management)이며, 이번 글에서 다루고자 하는 핵심 문제입니다.
이러한 한계는 금세 드러납니다. 두 번째 터미널에서 첫 번째 추가 에이전트를 돌릴 때만 해도 생산성이 마냥 늘어나는 것처럼 느껴집니다. 하지만 다섯 번째 에이전트에 이를 때쯤이면, 어떤 에이전트가 뭘 하고 있었는지 기억해 내려고 창을 이리저리 전환하고, 워크트리(worktree)를 일일이 수작업으로 정리하며, 이미 검토했던 diff를 다시 들여다보게 됩니다. 실행 도구는 실행 자체에 특화되어 있을 뿐, 서로를 조율하도록 설계된 적이 없기 때문입니다.
Sharkly는 바로 이 조율 레이어(coordination layer)를 위해 만들어졌으며, 이번 글에서 실제 워크플로 예시로 살펴볼 도구이기도 합니다. Sharkly는 코드를 직접 작성하지 않으며, 현재 사용 중인 에이전트를 대체하지도 않습니다. 에이전트 상위 레이어에 위치하여 사용자가 Claude Code와 Codex를 그대로 활용할 수 있게 하면서, 그 주변의 작업(Task), 컨텍스트, 진행 상황, 차단 요소(blocker), 결과물, 그리고 인간의 리뷰 과정을 총괄 관리합니다. 본문에서는 이 수준에서의 '관리'가 구체적으로 무엇을 의미하는지, 그리고 지금 내 환경에 이것이 필요한지 판단하는 기준을 살펴봅니다.
코딩 에이전트 관리의 진정한 의미
코딩 에이전트 관리란 에이전트마다 터미널을 따로 띄우는 대신, 하나의 통합된 공간에서 여러 AI 코딩 에이전트의 작업을 할당하고, 추적하고, 격리하며, 검토하는 프랙티스를 말합니다. 이는 하위 에이전트들과 경쟁하는 도구가 아니라, 그 위를 아우르는 하나의 독립된 레이어입니다.
이 스택 구조는 위에서 아래 순서로 살펴보면 훨씬 쉽게 이해할 수 있습니다.
Models Claude / GPT / Gemini (reason and generate)
Coding agents Claude Code / Codex / Gemini CLI (execute tasks)
Management layer Sharkly (assign, track, isolate, review)
Team you and other developers (set direction, accept results)
각 계층은 단 하나의 명확한 역할을 수행합니다. 모델은 추론합니다. 코딩 에이전트는 요청을 파일 수정, 명령 실행, diff 생성으로 변환합니다. 관리 레이어는 어떤 에이전트가 어떤 작업을 맡을지 결정하고, 변경 사항끼리 충돌하지 않도록 방지하며, 모두가 함께 검토할 수 있는 단일 기록을 유지합니다. 그리고 개발자는 방향을 설정하고 최종 결과를 승인합니다. 사람들이 에이전트를 단순한 자동 완성이 아니라 '함께 일하는 작업자'로 바라볼 때 머릿속에 그리는 조직도가 바로 이것이며, 관리 레이어야말로 지금까지 대부분의 환경에서 빠져 있던 핵심 퍼즐 조각입니다.
이 레이어가 별도로 존재해야 하는 이유는 분명합니다. 개별 코딩 에이전트는 다른 에이전트의 상태를 알지 못하는 상태 비보존(stateless) 구조이기 때문입니다. Claude Code는 두 디렉터리 떨어진 곳에서 Codex가 동일한 파일을 수정 중이라는 사실을 전혀 알 수 없습니다. 이를 조율하는 것은 개별 에이전트의 역할이 아니며, 한 에이전트에게 다른 에이전트를 감독하라고 맡겨봤자 혼란의 위치만 바뀔 뿐입니다.
하위 도구들이 해결해 주지 못하는 문제
서너 개의 에이전트를 동시에 돌리는 분주한 오후의 작업 현황을 솔직하게 점검해 보십시오. 지금 어떤 에이전트가 무슨 작업을 하고 있는지, 다음 작업은 누구에게 맡겨야 하는지, 어떤 작업이 끝났고 무엇이 실패했는지, 머지하기 전에 사람의 확인이 필요한 작업은 무엇인지 바로 파악할 수 있습니까? 그 이면의 작업 환경을 더해 보면 상황은 더 복잡해집니다. 여러 개의 터미널, 복잡한 워크트리, 수많은 브랜치와 저장소, 그리고 백그라운드에서 각기 청구되는 여러 구독 요금제까지 얽혀 있습니다.
이는 Claude Code나 Codex 자체의 결함이 아닙니다. 에이전트들을 통솔할 상위 레이어 없이, 뛰어난 실행 도구 여럿을 동시에 운영할 때 필연적으로 발생하는 비용입니다. 실제 작업이 병렬로 진행되고 있음에도, 그 과정은 전혀 가시화되지 않습니다. 에이전트가 엉뚱한 방향으로 작업을 진행했다는 사실을 문제가 발생한 즉시가 아니라, 한참 뒤에 해당 터미널 창으로 전환하고 나서야 뒤늦게 알아차리게 됩니다.
여기서 우리가 경계해야 할 진짜 문제는 경쟁 제품이 아니라 바로 '에이전트가 초래하는 무질서(agent chaos)'입니다. 닫기가 두려울 정도로 수많은 터미널 창이 화면을 가득 채우기 시작하는 순간, 이미 에이전트를 하나씩 순차적으로 실행하던 단계를 넘어선 것입니다. 대다수 개발자는 여러 개의 Claude Code 에이전트를 실행하거나 단일 코드베이스에서 Claude Code와 Codex를 함께 운영하려 할 때 이러한 문제에 직면하게 되며, 생산성 향상을 체감하기도 전에 관리 문제가 먼저 고개를 들게 됩니다.
관리 레이어가 담당하는 네 가지 핵심 역할
관리 레이어의 역할을 본질만 남겨 요약하면 할당(Assignment), 격리(Isolation), 가시성(Visibility), 검토(Review)의 네 가지로 압축됩니다. 이 네 가지를 제대로 구현하는 것이 곧 실무에서 말하는 AI 에이전트 오케스트레이션의 핵심입니다.
할당(Assignment). 작업은 '태스크(Task)' 단위로 구조화됩니다. 에이전트에 전달하는 것은 현재 포커스된 터미널 창에 붙여넣는 단순한 프롬프트가 아니라 바로 이 태스크입니다. 태스크에는 목표, 컨텍스트, 인수 기준(acceptance criteria)이 담겨 있으므로, 에이전트는 빈 대화창이 아니라 작업의 현재 상태를 온전히 파악한 상태에서 시작합니다.
격리(Isolation). 두 에이전트가 단일 저장소를 수정하는 것은 서로 같은 파일을 건드리기 전까지만 안전합니다. 해결책은 태스크마다 워크트리(worktree)를 배정하는 것입니다. 각 에이전트가 독립된 체크아웃을 갖게 되어 작업 도중에 변경 사항이 충돌하지 않습니다. Git을 통해 직접 구성할 수도 있지만, 관리 레이어의 역할은 이러한 격리된 워크트리를 자동으로 생성, 추적, 정리하여 개발자가 수작업으로 처리하지 않도록 해주는 것입니다.
가시성(Visibility). 실행 내역, 차단 요소, 결과물, 그리고 후속 논의 내용은 이미 닫혀버린 터미널 창 너머로 흘러가 버리는 대신 태스크 타임라인에 차곡차곡 기록됩니다. "지금 각 에이전트가 무엇을 하고 있는가?"라는 질문에 한곳에서 답을 제공하며, 이는 에이전트 대시보드가 보여주어야 할 본질과 정확히 일치합니다.
검토(Review). 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 설정하고, 권한을 부여하며, 최종 결과를 승인합니다. 관리 레이어가 지켜야 하는 가장 중요한 경계는 바로 팀의 판단이 필요한 지점에서 자동화가 멈춰야 한다는 점입니다. 에이전트가 코드 변경을 준비하고, 테스트를 돌리고, 검증 결과를 첨부할 수는 있지만 머지 여부를 최종 결정하는 것은 사람이어야 합니다. 이러한 인간 참여형(human-in-the-loop) 체크포인트는 속도를 늦추는 걸림돌이 아니라 안전을 보장하는 핵심 기능입니다.
판단을 위한 명확한 기준은 다음과 같습니다. 코딩 에이전트를 하나만 사용하고, 단일 터미널에서 작업하며, 하나의 작업이 완전히 끝난 뒤 다음 작업을 시작한다면 관리 레이어는 필요하지 않습니다. 오히려 불필요한 오버헤드만 늘어날 뿐입니다. 하지만 둘 이상의 에이전트를 실행하여 여러 태스크, 워크트리, 혹은 여러 저장소에 걸쳐 작업하거나, 동료 개발자가 에이전트의 작업 내용을 함께 확인해야 하는 순간 상황은 완전히 달라집니다. 바로 그 지점부터 관리 레이어는 들이는 수고 이상의 가치를 발휘하기 시작합니다.
Sharkly를 활용한 코딩 에이전트 관리
이번 예시에서는 Sharkly를 관리 레이어로 다루고 있으므로, 구체적으로 어떤 방식으로 동작하는지 살펴보겠습니다.
먼저 에이전트 세션이 실행될 머신인 컴퓨터(Computer)를 연결합니다. 개발용 노트북이든 서버든 상관없으며 둘 다 연결할 수도 있습니다. 그런 다음 새로운 모델이 아닌, 작업 처리 방식을 정의한 재사용 가능한 설정 단위인 에이전트(Agent)를 구성합니다. 모델 구독은 기존 방식을 그대로 유지(BYO)합니다. 즉, 이미 비용을 지불하고 있는 Claude Code, Codex, Gemini 계정을 통해 모델 사용량이 처리됩니다. Sharkly는 조율 역할만 수행할 뿐 모델 추론을 재판매하지 않습니다.
그다음 태스크를 할당합니다. 예를 들어 SH-312 태스크가 "불안정한(flaky) 결제 테스트 수정 및 테스트 커버리지 추가"라고 가정해 보겠습니다. 이 태스크를 Claude Code 기반의 에이전트에 넘기거나, 규모가 큰 목표인 경우 크루(Crew)로 나누어 리더 에이전트가 범위를 해석하고 다른 에이전트들의 작업 결과를 하나의 태스크로 취합하도록 할 수 있습니다. 태스크는 연결된 컴퓨터상의 독립된 워크트리에서 실행됩니다. 작업이 실행되는 동안 진행 상황, 차단 요소, diff가 태스크 타임라인에 실시간으로 기록됩니다. 작업이 완료되면 에이전트는 변경 요약, 테스트 결과, 확인된 한계점을 첨부하고 태스크는 검토 대기 상태로 전환됩니다. 개발자는 이를 확인하고 추가 수정을 요청하거나 최종 머지를 승인하면 됩니다.
이 과정에서 Claude Code나 Codex의 사용을 중단할 필요는 전혀 없습니다. 이미 사용 중인 에이전트들을 단일 작업 공간으로 연결함으로써, 개인 터미널마다 파편화되어 있던 작업들을 명확하게 할당하고 추적할 수 있도록 전환하는 것입니다. 이와 관련된 다양한 도구의 전체 지형을 파악하고 싶다면, 모든 환경에 단 하나의 방식만 옳다고 강요하기보다는 다양한 대안을 비교 정리한 병렬 AI 코딩 에이전트 관리 도구 비교 글을 참고하시기 바랍니다.
어떤 에이전트가 승리하느냐보다 레이어가 더 중요한 이유
한 가지 예측을 조심스럽게 전해드립니다. '최고의 코딩 에이전트'는 끊임없이 바뀔 것이며, 현재 1위인 도구 하나에 전체 워크플로를 거는 것은 매우 취약한 선택입니다. Claude Code, Codex, Gemini, 그리고 앞으로 새롭게 등장할 도구들은 태스크 유형에 따라, 그리고 분기마다 서로 엎치락뒤치락하며 선두를 다툴 것입니다. 특정 도구 하나만을 중심으로 전체 프로세스를 구축한다는 것은, 순위가 바뀔 때마다 프로세스를 매번 처음부터 다시 뜯어고쳐야 함을 의미합니다.
관리 레이어는 이러한 도구의 변화와 부침 속에서도 변함없이 살아남는 영역입니다. 태스크, 컨텍스트, 격리 환경, 리뷰 체계가 에이전트 상위에 구축되어 있다면, 팀의 작업 할당 방식이나 코드 리뷰 프로세스를 전혀 건드리지 않고도 특정 태스크를 수행할 에이전트만 유연하게 교체할 수 있습니다. 특정 벤더에 종속되지 않는 공급자 중립성(Provider neutrality)은 단순한 부가 기능 체크박스가 아니라, 몇 달마다 판도가 뒤바뀌는 시장에서 팀을 지켜주는 가장 확실한 보험입니다.
이 글은 Sharkly가 자신이 관리하는 에이전트들보다 코드를 더 잘 작성한다고 주장하는 것이 아닙니다. 실제로 그렇지도 않습니다. 에이전트는 실행하고, 레이어는 조율합니다. 이번 분기에 걸어볼 만한 가치 있는 베팅은 개별 에이전트 하나가 아니라 이들 모두를 아우르는 워크플로입니다. 어차피 병렬로 실행해야 할 작업들을 선별하고, 터미널 창이 감당할 수 없을 정도로 늘어나기 전에 그 상위에 제대로 된 관리 레이어를 도입해 보십시오.
이미 여러 코딩 에이전트를 운영하고 있다면, Sharkly를 통해 태스크 할당, 작업 환경 격리, 결과물 검토를 한곳에서 처리할 수 있습니다. 워크트리와 개발 원칙을 활용해 이 구조를 직접 구축할 수도 있고, 기존에 쓰던 코딩 에이전트를 Sharkly에 연결하여 레이어가 번거로운 조율을 대신 처리하도록 맡길 수도 있습니다.
