TL;DR: 라우팅은 어떤 코딩 에이전트가 특정 작업을 처리할지 결정하는 일입니다. 지난주 리더보드가 아니라 작업 자체의 속성을 기준으로 라우팅하세요. 무엇을 바꾸는지, 되돌리기 쉬운지, 다른 에이전트가 건드리는 파일과 겹치는지, 얼마나 오래 무인으로 실행되는지, 어떤 구독으로 처리할지를 따져야 합니다. 그런 다음 그 속성들을 여러분의 코드베이스에서의 동작과 맞는 에이전트에게 매칭하세요. 에이전트가 하나나 둘일 때는 머릿속으로도 됩니다. 셋을 넘어가면 라우팅 결정이 공유될 공간이 필요합니다. 이 가이드는 규칙과 체크리스트를 제공합니다.
한 터미널에는 Claude Code가, 다른 터미널에는 Codex가, 어쩌면 세 번째에는 Gemini CLI가 떠 있습니다. 작업이 하나 들어옵니다. 불안정한 테스트를 고치고, 엔드포인트를 추가하고, 세 개의 다른 파일이 import하는 모듈을 리팩터링하는 일입니다. 어느 에이전트에게 맡겨야 할까요? 대부분은 습관대로, 혹은 이미 포커스가 잡혀 있는 창에 맡깁니다. 마이그레이션을 어느 에이전트에게 넘겼는지 기억나지 않거나, 두 에이전트가 같은 파일을 편집하기 전까지는 그렇게 해도 됩니다.
“최고의” 에이전트를 고르는 건 새 모델이 출시되는 날이면 낡아버리는 일회성 결정입니다. 이 작업을 어느 에이전트에게 맡길지 정하는 건 일주일에 수십 번 내리는 결정이며, 순위보다 작업에 훨씬 더 크게 좌우됩니다. 에이전트가 둘 이상이 되는 순간부터 라우팅이 여러분의 시간을 잡아먹습니다.
Sharkly는 바로 그 결정을 중심으로 만들어졌습니다. Sharkly는 올인원 에이전트 명령 및 관리 플랫폼입니다. 여러분의 컴퓨터를 연결하고, 에이전트를 런타임에 묶인 역할로 한 번 정의한 다음, 작업을 할당합니다. 이미 사용 중인 코딩 에이전트 옆에 있는 게 아니라 그 위에 자리합니다. 이 글에서는 작업을 잘 라우팅하는 방법을 다룹니다. 먼저 손으로 직접 적용하는 규칙으로 시작해, 라우팅 결정이 공유될 공간이 필요해지는 지점까지 살펴봅니다.
라우팅은 선호가 아니라 결정이다
명확한 정의부터 시작합시다. 라우팅은 작업을 실행해야 할 에이전트에 매칭하는 것입니다. 좋아하는 에이전트를 고르는 것과는 다르고, 모델을 고르는 것과도 다릅니다. 어떤 코딩 작업에 어떤 모델을 쓸지는 한 계층 아래에 있는 별개의 더 좁은 질문입니다. 여기서는 어떤 에이전트(Claude Code, Codex, Gemini CLI, OpenCode 등)가 작업을 받을지 결정합니다.
작업에는 역량이 개입하기 전에 그 경로를 결정하는 속성들이 있습니다.
- 무엇을 바꾸는가. 단일 파일 수정, 횡단 리팩터링, 신규 기능, 테스트, 문서. 각각 영향 범위가 다릅니다.
- 되돌리기 쉬운가. 오타 수정과 데이터베이스 마이그레이션은 둘 다 diff를 만들어냅니다. 하지만 에이전트가 잘못했을 때 오후를 망치는 건 하나뿐입니다.
- 파일 겹침. 지금 다른 에이전트가 편집 중인 파일을 건드리는가?
- 자율 실행 범위. 짧고 상호작용적인 편집인가, 아니면 계획하고 실행하고 스스로 검증해야 하는 장시간 무인 실행인가?
- 비용 상한. 어떤 구독이나 API 예산으로 처리할 것인가?
작업을 이 다섯 가지 속성으로 읽어보면 경로는 대개 스스로 정해집니다. 실수는 곧바로 “어떤 에이전트가 최고인가”로 건너뛰는 것입니다. 이 질문에는 정해진 답이 없고, 연구소가 새 모델을 내놓을 때마다 바뀝니다.
역량이 아니라 작업 형태로 먼저 라우팅하라
코딩 에이전트는 실제로 다릅니다. 하나는 긴 다단계 작업을 잘 계획할 수 있고, 다른 하나는 정밀한 편집에 더 날카롭거나 빠른 반복에 강할 수 있습니다. 하지만 솔직히 말하면, 그 차이는 여러분의 코드베이스에서 드러나며, 유일한 방법은 그들이 그 코드에서 작업하는 모습을 지켜보는 것입니다. 벤치마크는 고정된 시점의 고정된 문제 세트를 측정할 뿐, 여러분의 저장소도 다음 달도 아닙니다. 순위를 믿기 전에 자신의 코드베이스에서 에이전트를 비교하세요.
그러니 먼저 형태로 라우팅하세요. 기준이 될 결정 쌍 하나를 들어보면, 작업이 작고 범위가 명확하며 여러분이 지켜볼 때는 빠르고 상호작용적인 에이전트를 씁니다. 작업이 한 번 설명하고 각 단계를 지켜보기보다 결과를 검토하고 싶을 만큼 클 때는 더 자율적인 에이전트를 씁니다.
| 작업 형태 | 라우팅 대상 | 이유 |
|---|---|---|
| 작고 범위가 명확하며 지켜보는 경우 | 가장 빠른 상호작용형 에이전트 | 오버헤드가 낮고 반복이 빠름 |
| 크고 다단계이며 한 번에 설명하는 경우 | 가장 신뢰할 수 있는 자율형 에이전트 | 무인으로 계획하고 스스로 검증함 |
| 다른 에이전트가 열어둔 파일을 건드리는 경우 | 격리된 워크트리에서 아무 에이전트나 | 머지 충돌을 피함 |
| 위험도가 높거나 되돌릴 수 없는 경우 | 결과를 꼼꼼히 검토하는 에이전트, 좁은 권한 | 속도보다 영향 범위가 우선함 |
| 저렴하고 반복적인 경우 | 예산이 선호하는 에이전트 | 비용 상한이 결정함 |
여기엔 승자가 없습니다. 실제로 없으니까요. 작업과 에이전트의 관찰된 동작 사이의 적합성이 있을 뿐이고, 여러분은 그 적합성을 기준으로 라우팅합니다.
역량보다 먼저 라우팅을 결정하는 제약들
두 가지 제약은 언제나 역량을 앞지릅니다. 둘 다 실력이 아니라 조율에 관한 것입니다.
첫째는 파일 겹침입니다. 하나의 저장소에서 다섯 개의 에이전트가 편집한다니 효율적으로 들리지만, 둘이 같은 파일을 건드리고 여러분이 일부러 만든 머지 충돌을 해결하는 순간 그 효율은 사라집니다. 해결책은 격리입니다. 각 작업에 자체 체크아웃을 주어 에이전트가 충돌하지 않게 하는 것입니다. 코딩 에이전트 워크트리, 작업당 하나의 체크아웃에서 그 메커니즘을 다루고, 하나의 저장소에서 여러 에이전트 실행하기에서는 그것이 없을 때 무엇이 깨지는지 다룹니다. 두 작업이 같은 파일을 건드린다면 경로는 “더 나은 에이전트”가 아니라 “별도의 워크트리에서 아무 에이전트나”입니다.
둘째는 위험입니다. 데이터를 마이그레이션하거나, 인증을 바꾸거나, 핫 패스를 재작성하는 작업은 기술적으로 어느 에이전트가 가장 강하든 상관없이, 여러분의 검토가 가장 꼼꼼한 곳, 에이전트 권한이 가장 좁은 곳으로 라우팅해야 합니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 받아들입니다. 위험한 작업을 가장 빠른 에이전트에 라우팅하는 건 잘못된 변수를 최적화하는 것입니다.
머릿속 라우팅이 확장을 멈추는 지점
에이전트가 하나일 땐 라우팅 문제가 없습니다. 둘이면 그 표를 머릿속에 담아둘 수 있고 괜찮습니다. 문제는 에이전트 셋, 그리고 여러 개의 열린 작업쯤에서 시작됩니다. 라우팅 결정이 여러분의 단기 기억 외에는 머물 곳이 없어지기 때문입니다.
어느 에이전트가 마이그레이션을 맡았는지 기억나지 않습니다. 끝난 실행이 읽기도 전에 터미널 위쪽으로 스크롤되어 사라집니다. 한 번 내린 결정이라는 기록이 없으니 같은 경로를 세 번 다시 결정합니다. 다른 에이전트가 거기 있다는 걸 아무도 알려주지 않아 두 에이전트가 같은 파일을 편집합니다. 이 중 어느 것도 에이전트의 실패가 아닙니다. 터미널이 늘어나는 동안 라우팅 표를 머릿속에 두는 데 따르는 비용일 뿐입니다. 터미널이 너무 많다는 건 실질적인 비용이며, 라우팅은 그 비용이 가장 먼저 드러나는 곳입니다.
이때 작업 보드가 제 몫을 합니다. 라우팅 결정을 머릿속에서 꺼내 공유 기록으로 옮겨주기 때문입니다. Sharkly는 이를 세 가지 명사로 구현합니다. Task는 공유되는 작업 단위입니다. Agent는 런타임에 묶인 역할로, 한 번 정의해두면 라우팅 결정이 매 터미널마다 다시 만들어지는 게 아니라 재사용 가능해집니다. 여러분은 Task를 Agent에 할당하고, 실행, 블로커, 결과는 흘러 사라지는 대신 그 Task로 돌아옵니다. 창을 전환하지 않고도 어느 에이전트가 무엇을 하는지 볼 수 있고, diff와 테스트 출력은 한곳에서 검토를 기다립니다. 에이전트 작업 할당, 추적, 검토가 바로 이 기억 게임을 대체하는 것입니다.
에이전트 하나를 잘 굴리는 데 이런 게 전혀 필요하진 않습니다. 하나의 코드베이스에서 Claude Code와 Codex를 함께 실행하는 것도 손으로 할 수 있고, 에이전트 둘 정도면 그게 합리적입니다. 방정식은 라우팅 결정이 머릿속에 담을 수 있는 양을 넘어설 때 바뀝니다. 여러 에이전트, 여러 작업, 여러 저장소, 그리고 같은 보드를 봐야 하는 팀이 있을 때 말입니다.
오늘 바로 써볼 수 있는 라우팅 체크리스트
작업을 에이전트에 넘기기 전에 다음을 점검하세요.
- 작업의 형태를 이름 붙이세요. 단일 파일 수정, 리팩터링, 신규 기능, 테스트, 문서 중 무엇인가? 이것이 영향 범위를 정합니다.
- 되돌릴 수 있는지 확인하세요. 되돌리기 어렵다면 가장 빠른 에이전트가 아니라, 가장 꼼꼼한 검토와 가장 좁은 권한으로 라우팅하세요.
- 파일 겹침을 확인하세요. 다른 에이전트가 이미 이 파일들에 있나요? 그렇다면 먼저 이 작업을 자체 워크트리로 격리하세요.
- 자율 실행 범위를 맞추세요. 짧고 지켜보는 작업인가, 길고 무인인 작업인가? 여러분의 저장소에서 그 동작이 맞는 에이전트에게 라우팅하세요.
- 비용 상한을 정하세요. 어떤 구독이나 예산이 이 실행을 흡수할지 결정하세요.
- 경로를 어딘가 공유되는 곳에 기록하세요. 에이전트가 둘을 넘어가면 여러분과 팀이 볼 수 있는 곳에 적으세요. 닫아버릴 터미널이 아니라 Task에요.
- 결과를 한곳으로 되돌리세요. diff, 테스트 출력, 검토는 여러 창에 흩어지는 게 아니라 작업 기록으로 돌아와야 합니다.
순위가 아니라 작업으로 라우팅하세요. 어떤 작업에 가장 좋은 에이전트는 눈앞의 일에 그 형태가 맞는 에이전트이며, 라우팅 결정은 볼 수 있는 곳에 있을 때만 저렴하게 유지됩니다.
이미 여러 코딩 에이전트를 돌리고 있다면, Sharkly가 그들의 작업을 라우팅하고 결과를 읽는 한곳을 제공합니다. Sharkly를 다운로드하고 사용 중인 에이전트를 연결해보세요.
자주 묻는 질문
라우팅은 최고의 코딩 에이전트를 고르는 것과 같은 건가요? 아닙니다. 최고의 에이전트를 고르는 건 금방 낡아버리는 일회성 판단입니다. 라우팅은 각 작업의 형태, 위험, 파일 겹침, 자율 실행 범위를 기준으로 어느 에이전트가 처리할지 정하는 것입니다. 고르는 게 한 번일 때 라우팅은 수십 번입니다.
모델을 고르는 것과는 어떻게 다른가요? 모델 선택은 한 계층 아래, 에이전트 내부에서 일어납니다. 라우팅은 어느 에이전트가 작업을 받을지 정하고, 모델 질문은 그 에이전트의 세션 안에서 무엇이 실행될지 정합니다. 더 좁은 결정에 대해서는 어떤 코딩 작업에 어떤 모델을 쓸지를 참고하세요.
이걸 위한 도구가 실제로 언제 필요하죠? 라우팅 결정이 머릿속으로 추적할 수 있는 양을 넘어설 때입니다. 보통 에이전트 셋과 여러 열린 작업쯤이거나, 팀이 같은 결정을 봐야 할 때입니다. 에이전트 하나나 둘이면 머릿속 표와 분리된 터미널로 충분합니다.
Sharkly가 Claude Code나 Codex를 대체하나요? 아닙니다. Sharkly는 Claude Code, Codex, 또는 다른 실행 도구를 대체하는 게 아닙니다. 팀이 이미 사용 중인 코딩 에이전트 주위에 공유 작업, 컴퓨터, 컨텍스트, 검토 계층을 더해줍니다.
