대부분의 에이전트 플랫폼은 사용자와 모델 제공자 사이에 자기 자신을 끼워 넣고, 오가는 모든 토큰에 마크업을 붙입니다. Sharkly는 그렇지 않습니다. 모델 사용은 키 직접 가져오기(BYOK) 방식입니다. 즉, 실행 비용은 해당 실행을 수행하는 Runtime에 이미 연결된 Claude Code, Codex 또는 API 요금제로 청구될 뿐, Sharkly가 판매하는 토큰 잔액에 대해 청구되지 않습니다. 이는 들리는 것보다 소박한 주장이며, 이것이 중요한지 판단하기 전에 절약해 주는 것만큼이나 치러야 할 비용도 솔직하게 짚어볼 필요가 있습니다.
리셀러 모델이 인센티브 구조에 미치는 영향
토큰을 실제로 판매하는 플랫폼부터 살펴보겠습니다. 이 업계의 기본값이 그렇고, 얼버무리기보다 분명히 짚고 넘어갈 가치가 있기 때문입니다.
플랫폼이 모델 접근 권한을 재판매할 때, 그 수익은 여러분의 에이전트가 토큰을 얼마나 많이 태우는지에 달려 있습니다. 이는 숨겨진 결함이 아니라 설계대로 작동하는 비즈니스 모델이며, 예측 가능한 인센티브를 만들어냅니다. 즉, 플랫폼이 실행을 더 저렴하게 만들 이유가 없습니다. 더 효율적인 프롬프트, 더 작은 컨텍스트 윈도, 더 적은 토큰으로 끝나는 Runtime — 이 모든 것이 여러분의 계정에서 발생하는 플랫폼 수익을 줄입니다. 기반 모델 벤더가 단행한 가격 인하를 토큰 리셀러가 전달하도록 강제하는 것도 없고, 여러분이 덜 쓰도록 돕는 데 보상을 주는 것도 없습니다. 여러분은 조정(coordination)에 대한 대가로 마크업을 지불하고 있지만, 그 마크업은 플랫폼이 여러분이 더 많이 소비하기를 바라는 화폐로 표시되어 있습니다.
두 번째 비용은 더 조용하고 나중에 나타납니다. 여러분의 팀이 이미 Claude Code나 Codex 요금제를 보유하고 있거나 제공자와 약정 API 지출을 맺고 있다면, 아마 그에 대한 가격을 협상해 두었을 것입니다. 구독 등급, 볼륨 할인, 약정 사용 요율 같은 것들 말입니다. 그 사용량을 대신 리셀러를 통해 라우팅하면, 같은 레버리지에 두 번 비용을 내는 셈입니다. 한 번은 접근 권한에 대한 대가로 리셀러에게 내고, 이미 직접 확보해 둔 요율의 혜택은 잃게 됩니다. 이제는 리셀러의 요율이 적용되기 때문입니다. 모델 벤더와 구축한 가격 관계는 자체 계정으로 토큰을 재판매하는 플랫폼 안으로 여러분과 함께 따라오지 않습니다.
대략 숫자로 따져봅시다. 리셀러를 통해 소수의 에이전트를 돌리는 팀이, 모델 벤더와 직접 맺은 약정 지출 위에 적은 토큰당 마크업만 붙더라도 같은 토큰에 두 번 비용을 내는 셈입니다. 한 번은 더 이상 쓸 수 없는 협상 요율로, 한 번은 리셀러가 정한 요율로 말입니다. 이를 단일 Task가 아니라 한 Sprint 분량의 실행 전체로 확대하면, 그 격차는 리셀러가 바라는 방향으로 정확히 복리처럼 커집니다.
이 중 어느 것도 토큰 재판매를 부정직하게 만들지는 않습니다. 다만 플랫폼의 이익과 여러분의 비용 이익이 서로 다른 방향을 가리키는 모델이 된다는 뜻이며, 벤더에게 여러분의 실행을 맡기기 전에 알아둘 가치가 있습니다.
BYOK가 실제로 치르게 하는 비용
이 분리는 Sharkly 쪽에서도 공짜가 아닙니다. 키 직접 가져오기의 장점만 나열하는 글은 트레이드오프를 솔직하게 설명하기보다 마케팅처럼 읽힐 것입니다. 비용을 분명히 말해 보겠습니다.
키와 할당량은 여러분이 직접 관리합니다. 조정 레이어의 누구도 여러분을 대신해 Claude Code 요금제의 레이트 리밋이나 API 계정의 남은 크레딧을 지켜보지 않습니다. 팀에서 하나의 Anthropic API 키로 다섯 개의 에이전트를 돌리는데 그 키가 레이트 리밋에 걸린다면, 그 제약을 알아차리고 대비하는 것은 여러분의 몫입니다. 팀원이 터미널에서 직접 호출하는 경우와 다를 바 없습니다.
실행은 Sharkly와 아무 관련 없는 이유로 실패할 수 있습니다. Runtime에 연결된 Claude Code 요금제가 레이트 리밋에 걸리거나, 이를 뒷받침하는 API 계정의 크레딧이 바닥나면 실행이 중단되며, 이 실패는 Sharkly 장애가 아니라 모델 제공자로부터 오는 토큰 또는 인증 오류로 나타납니다. 이를 디버깅하려면 하나가 아니라 두 시스템을 확인해야 합니다. Task가 멈춘 이유가 Sharkly 쪽 문제인지, 아니면 기반 요금제가 고갈된 것인지 말입니다. 이는 실제로 존재하는 이음새이며, 플랫폼이 관리하는 토큰 풀로 이를 매끄럽게 덮지 않기 때문에 치르는 직접적인 대가입니다.
지출 가시성은 두 곳에 나뉘어 있습니다. Sharkly의 사용 대시보드는 에이전트별 소비량을 보여주지만, 청구서 자체는 Claude Code, Codex 또는 API 제공자 인보이스에 나타나며 Sharkly의 단일 항목으로 표시되지 않습니다. 재무팀이 “이번 달 AI 코딩에 얼마를 썼는가”에 대한 하나의 숫자를 원한다면, 하나의 요약을 읽는 대신 두 출처를 대사(reconcile)해야 하며, 그 대사는 누군가 실제로 해야 하는 수작업입니다.
온보딩 비용도 있습니다. 없는 셈 치기보다 짚고 넘어갈 가치가 있습니다. 연결하는 모든 Runtime은 자체 키나 요금제를 설정해야 하고, 팀 내 누군가는 그 자격 증명을 갱신하고 교체하는 일을 맡아야 하며, 에이전트를 돌리려는 신입 사원은 Sharkly 초대장만이 아니라 기반 제공자 계정에 대한 접근 권한도 필요합니다. 리셀러 플랫폼은 이 모든 것을 단일 가입 뒤에 숨길 수 있습니다. BYOK는 설계상 그렇지 않으며, Sharkly를 검토하는 팀은 Runtime당 실제 한두 시간의 설정 시간을 예산에 넣어야지, 0이라고 기대해서는 안 됩니다.
이 중 어느 것도 BYOK를 피할 이유는 아닙니다. 토큰 마크업을 내지 않는 대가로 무엇을 떠안게 되는지 솔직하게 정리한 목록이며, 팀은 장애가 터졌을 때가 아니라 시작 전에 이를 알고 있어야 합니다.
관리 레이어가 여전히 값을 하는 지점
Sharkly가 토큰을 판매하지도, 제공자의 레이트 리밋을 매끄럽게 넘겨주지도 않는다면, 조정 레이어가 실제로 무엇을 하는지 묻는 것은 당연합니다. 구체적으로 세 가지입니다.
실행이 어느 Computer에서 수행될지 결정합니다. 에이전트의 Runtime에는 Task가 필요로 하는 리포지토리와 리소스를 갖춘 호스트(로컬 또는 클라우드)가 필요하며, 그 배정은 실행이 소비하는 토큰을 누가 지불하든 Sharkly의 몫입니다. 토큰 청구와 실행 배치는 별개의 문제이며, BYOK는 첫 번째 문제에서 플랫폼을 제거할 뿐입니다.
승인 경로에 사람을 남겨둡니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 받아들입니다. Task가 병합되거나 종료되기 전에 누가 승인하는지를 정하는 그 검토 단계는, 그 아래에서 모델 호출 비용을 누가 지불하는지에 달려 있지 않습니다. 리셀러 마크업이 싸다고 해서 더 나은 검토 프로세스를 얻는 것도 아니고, BYOK 모델이라고 해서 그것을 잃는 것도 아닙니다.
그리고 토큰 자체는 다른 곳에서 청구되더라도 에이전트별 소비량을 보여주는 사용 대시보드를 제공합니다. 한 Sprint에서 어떤 에이전트가 가장 많이 소모했는지, 어떤 Task 유형이 자동화하기에 비싼지, 어느 Runtime이 과부하 상태인지를 볼 수 있으며, 이 가시성을 확보하기 위해 Sharkly가 자기가 보고하는 토큰을 직접 청구하는 주체가 될 필요는 없습니다. 대시보드의 유용성은 Sharkly가 청구서를 쥐고 있는지에 달려 있지 않습니다.
이것이 이 분리의 실제 모습입니다. Sharkly는 작업이 어디서 실행되는지, 누가 검토하는지, 실행에 얼마가 드는지를 관리하면서도, 측정 대상 자체를 판매하는 벤더가 될 필요는 없습니다.
이 트레이드오프가 가치가 있는지 판단하기
팀이 작고, Runtime이 하나뿐이며, 레이트 리밋에 거의 부딪히지 않는다면, 리셀러냐 BYOK냐 하는 문제는 어느 쪽이든 일상에 큰 변화를 주지 않을 것입니다. 트레이드오프가 실질적으로 중요해지는 시점은 같은 기반 요금제로 여러 에이전트를 돌리거나, 둘 이상의 Computer에 걸쳐 Crews를 조정하거나, 둘 이상의 팀을 위해 “이번 Sprint에 AI 코딩에 실제로 얼마가 들었나”에 답하려 할 때입니다. 그 시점에서, 토큰 지출을 높게 유지하려는 숨은 인센티브를 가진 플랫폼은 온전히 보이지 않는 비용이며, 여러분이 쓴 만큼을 알려주되 그것을 파는 주체는 아닌 플랫폼이라면 대시보드가 두 개인 번거로움을 감수할 가치가 있습니다.
Sharkly의 판단은 과금(metering) 문제가 아니라 조정(coordination) 문제야말로 비용을 받을 가치가 있다는 것입니다. Sharkly는 여러분이 이미 돌리는 에이전트 위의 레이어이지, 여러분과 그들이 소비하는 토큰 사이에 끼는 두 번째 벤더가 아닙니다. 이미 Claude Code나 Codex에 직접 비용을 지불하고 있고, 토큰 위에 마크업이 얹히지 않은 채로 실행을 배정하고, 검토하고, 확인할 수 있기를 원한다면, 바로 그 레이어가 Sharkly가 되고자 하는 것입니다. 그중 시트(seat) 쪽이 정확히 어떤 모습인지는 현재 가격에서 확인해 보세요.
