최고의 코딩 에이전트를 고르려고 하고 있다. 리더보드를 읽고, 릴리스 포스트를 보고, 같은 프롬프트를 Claude Code와 Codex, Gemini CLI에 돌려보며 어느 쪽이 더 예리한지 확인한다. 그런데 새 모델이 나오고 순위가 뒤바뀌면서, 지난달에 표준으로 정했던 에이전트가 갑자기 중위권으로 밀린다. 그래서 또 갈아탄다.
불편한 진실은 이렇다. 당신이 어떤 에이전트를 고르든, 그것이 당신의 한 주를 바꾸는 정도는 생각보다 크지 않다. 실제로 얼마나 많은 작업을 끝내는지를 결정하는 것은 에이전트 주변에서 벌어지는 일이다. 어떤 에이전트가 어떤 작업을 맡고 있는지, 무엇이 끝났고 무엇이 실패했으며 무엇이 당신의 리뷰를 기다리고 있는지. 대부분의 개발자는 순위가 잡아당기는 힘을 느끼지만, 그 순위가 애초에 병목이 아니었다는 사실은 알아채지 못한다.
Sharkly는 이 관찰에서 출발했다. Sharkly는 올인원 Agent 명령 및 관리 플랫폼이다. 자신의 Computer를 연결하고, 이미 사용 중인 어떤 Agent에든 Task를 배정하면, 모든 실행이 자신의 diff와 테스트 출력, 리뷰를 한곳으로 반환한다. Sharkly는 에이전트 옆이 아니라 그 위에 위치한다. 이 글에서는 왜 모델보다 관리 레이어가 당신의 성과를 더 크게 좌우하는지, 그리고 다음 리더보드를 쫓는 대신 이번 분기에 무엇을 해야 하는지를 살펴본다.
최고의 에이전트는 움직이는 표적이다
코딩 에이전트 리더보드는 특정 시점에 고정된 공통 문제 집합을 측정한다. 이 두 가지 사실 모두 시간이 지나면 무의미해진다. 그 문제 집합은 당신의 코드베이스가 아니고, 그 시점은 다음 달이 아니다.
속도를 보라. Anthropic, OpenAI, Google은 지난 한 해 동안 각각 코딩 에이전트를 지원하는 모델 업데이트를 여러 차례 내놓았고, 이들 사이의 상대적 순위는 한 번 이상 뒤집혔다 [VERIFY: 정확한 릴리스 주기와 현재 순위는 매달 바뀌므로 구체적인 내용을 인용하기 전에 확인할 것]. "최고의 에이전트를 쓰자"를 결정으로 삼는다면, 연구소가 새 모델을 낼 때마다 그 결정을 다시 내리겠다는 뜻이다. 갈아탈 때마다 비용이 따른다. 새로운 설정, 새로운 컨텍스트 파일, 새로운 습관, 그리고 팀이 새로 익혀야 하는 새로운 실패 유형들이다.
하나의 예측을 제시하겠다. 최상위 코딩 에이전트들 사이의 격차는 벌어지는 것이 아니라 계속 좁혀질 것이다. 세 에이전트가 모두 당신의 저장소에서 같은 버그를 해결한다면, 질문은 "어느 것이 최고인가"에서 "이 특정 작업을 어느 것에 맡기고, 그 결과를 어떻게 확인할 것인가"로 바뀐다. 차별화 요소가 모델에서 워크플로로 옮겨가는 것이다. 이런 변화는 팀들이 에이전트를 이야기하는 방식에서 이미 드러난다. 그리고 그것은 예외가 되기 전에 기본적인 업무 방식이 될 것이다.
움직이는 표적에 맞서는 방어는 더 나은 조준이 아니다. 표적이 움직여도 살아남는 워크플로다. 자신의 코드베이스에서 에이전트를 비교하기는 오늘 어떤 에이전트를 돌릴 가치가 있는지 알려주지만, 내일도 그 답에 묶어두지는 않는다.
실제로 당신의 성과를 결정하는 것
작업이 시간을 어디에 쓰는지 계산해 보라. 에이전트는 몇 분 만에 diff를 만들어낸다. 나머지 전부, 즉 어떤 에이전트가 그 작업을 맡을지 정하고, 그 변경 사항을 다른 네 에이전트로부터 격리하고, 빌드 단계에서 멈춰 있다는 사실을 알아내고, 결과물을 읽고, 수락하거나 거부하는 일이 하루를 잡아먹는다. 이 중 어느 것도 모델의 속성이 아니다.
이것이 관리 문제이며, 에이전트를 둘 이상 돌리는 순간 나타난다. 어떤 에이전트가 무엇을 하고 있는가? 다음 작업은 어느 에이전트가 받아야 하는가? 무엇이 끝났고, 무엇이 실패했고, 무엇이 사람의 확인을 필요로 하는가? 세 에이전트가 하나의 저장소를 편집할 때 같은 파일을 건드리지 않게 하려면 어떻게 해야 하는가? 개별 에이전트의 성능이 좋아질수록 더 많은 에이전트를 동시에 돌리게 되고, 이 질문들은 더욱 날카로워진다.
Sharkly는 이 질문들에 도구가 아니라 레이어로서 답한다. Task는 작업의 기본 단위다. Task를 Agent에 배정하면, Agent는 연결된 Computer의 격리된 worktree에서 실행되고, 실행 상황과 블로커, 결과, 후속 조치가 모두 Task로 돌아온다. 작업을 수행한 에이전트는 전체 설정의 아키텍처가 아니라 Task의 설정값이다. 다음 작업에서 Claude Code를 Codex로 바꿔도 프로세스의 다른 것은 아무것도 변하지 않는다. 이것이 프로바이더 중립성이 주는 것이다. 즉 현재 어떤 에이전트가 이기고 있든 당신의 워크플로는 그보다 오래간다.
리뷰 역량이 진짜 한계다
"완료"를 출력한 에이전트는 아직 아무것도 배포하지 않았다. 사람이 여전히 diff를 읽고, 테스트를 확인하고, 결정을 내려야 한다. 코드 생성이 아니라 이 리뷰 단계가 거의 모든 팀이 가장 먼저 부딪히는 제약이다.
계산은 냉정하다. 에이전트 하나가 하루치 리뷰 작업을 20분 만에 만들어낸다면, 에이전트 다섯은 같은 20분에 닷새치 리뷰를 만들어내는데, 눈은 여전히 한 쌍뿐이다. 더 빠르고 더 똑똑한 에이전트는 상황을 낫게 하기는커녕 더 악화시킨다. 대기열을 더 빨리 채우기 때문이다. 최고의 에이전트를 고르는 것은 애초에 병목이 아니었던 단계를 최적화하면서 정작 진짜 병목은 그대로 두는 일이다. 리뷰 역량은 팀이 감당할 수 있는 병렬 에이전트 작업량의 진짜 한계이며, 어떤 모델 업그레이드도 이 산수를 바꾸지 못한다.
그래서 중요한 결정의 짝은 "Claude Code냐 Codex냐"가 아니다. 이것이다. 제약이 변경 사항의 초안을 생성하는 것이라면 더 빠른 에이전트를 사용하라. 제약이 변경이 올바른지 판단하는 것이라면 리뷰 워크플로에 투자하라. 에이전트를 병렬로 돌리는 대부분의 팀에게는 두 번째 제약이 첫 번째보다 훨씬 먼저 발목을 잡는다. 해법은 모든 실행을 태스크 수준의 근거와 함께 리뷰 가능하게 만드는 것이다. 즉 diff, 타입체크와 테스트 출력, 변경 요약, 그리고 에이전트가 인정한 한계까지, 여러 터미널에 흩어져 있는 대신 한곳에 모으는 것이다.
여기서 인간-에이전트 계약이 빛을 발한다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고한다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 수용한다. 자동화는 팀의 판단이 필요한 지점에서 멈춘다. 더 나은 에이전트는 첫 번째 문장의 일을 더 많이 할 뿐, 두 번째 문장의 일은 전혀 하지 않는다. 한계는 그 경계의 당신 쪽에 있다.
에이전트 선택을 아키텍처가 아닌 설정으로 만들라
아무도 잘못 짐작하지 않도록 경계를 분명히 밝히겠다. Sharkly는 코딩 에이전트가 아니며 Claude Code, Codex 또는 어떤 런타임의 대체재도 아니다. 그들보다 더 나은 코드를 작성하지 않는다. 팀이 이미 사용하는 도구 주위에 공유된 Task, Computer, 컨텍스트, 리뷰 레이어를 더할 뿐이다.
이 구분이 핵심이다. 에이전트 선택이 설정일 때, 새 에이전트를 시험하는 비용은 마이그레이션이 아니라 작업 하나다. 런타임을 연결하고, 실제 요구 사항을 배정하고, 어제 사용한 에이전트의 결과 옆에서 돌아온 결과를 읽으면 된다. 에이전트 선택이 아키텍처에 박혀 있으면, 모든 실험은 비싸지고 모든 리더보드 순위 변동은 위협이 된다.
이것이 필요 없는 경우를 솔직히 인정하자. 코딩 에이전트를 하나만 쓰고 단일 터미널에서 행복하게 산다면, 자체 worktree에서 잘 튜닝된 Claude Code 세션으로 충분하며 관리 레이어는 건너뛰어도 되는 부담이다. 방정식은 에이전트를 둘 이상, 하나 이상의 작업이나 저장소에 걸쳐 돌리기 시작하고, 결과를 팀 동료가 당신의 스크롤백을 설명 듣지 않고도 읽을 수 있는 형태로 받고 싶어지는 순간 달라진다. 그 지점이 코딩 에이전트 관리가 좋은 아이디어를 넘어 실제로 필요한 레이어가 되는 임계점이다.
이번 분기에 다르게 해야 할 일
순위를 쫓느라 한 주를 보내지 마라. 순위를 사소한 문제로 만들어주는 레이어를 쌓는 데 그 시간을 써라.
구체적인 세 가지 행동. 첫째, 에이전트는 지루한 방식으로 고르라. 백로그에서 가져온 실제 작업에 둘을 돌려보고 당신의 코드에서 더 잘 읽히는 쪽을 택하되, 다시 검토할 것임을 알고 있으라. 둘째, 리뷰 처리량을 솔직하게 측정하라. 에이전트가 당신이 결과를 수락할 수 있는 속도보다 빨리 끝내고 있다면, 다음 에이전트 업그레이드는 도움이 되지 않을 것이고 더 나은 리뷰 흐름은 도움이 될 것이다. 셋째, 하나의 에이전트를 프로세스에 하드코딩하는 것을 그만두라. 에이전트를 교체 가능한 것으로 취급하는 레이어를 통해 작업을 라우팅하면, 다음 모델 릴리스는 두려운 재구축이 아니라 시도해볼 옵션이 된다. 각 에이전트에 어떤 모델을 붙일지 아직 고민 중이라면, 에이전트 역할에 모델을 매칭하는 것이 리더보드를 새로고침하는 것보다 오후 시간을 더 잘 쓰는 방법이다.
하나의 생태계에 전념하는 대신 여러 코딩 에이전트를 계속 사용하고 싶다면, 그것이 바로 Sharkly가 겨냥해 설계된 문제다. Sharkly 다운로드하고, Computer 하나를 연결한 뒤, 같은 실제 작업을 두 에이전트에 배정하라. 최고의 에이전트는 바뀔 것이다. 하지만 당신이 그것들을 관리하는 방식은 바뀔 필요가 없다.
