오픈코덱스와 키마키 — 서드파티 하네스로 토큰 분산

자정 무렵 한 참여자가 커뮤니티에서 만들어진 오픈코덱스(OpenCodex)를 소개하며 토큰 절약 후기를 올렸다. 원하는 모델을 서브에이전트로 붙여 쓸 수 있어서 토큰이 절약된다는 것이 소개의 핵심이었다. 도구 자체가 새로운 한도를 만들어 주는 것이 아니라, 이미 가지고 있는 여러 계정과 모델에 일을 나눠 얹는 방식이다. 커뮤니티 안에서 만들어진 도구를 같은 방 사람들이 곧바로 시험해 보는 흐름도 함께 읽힌다.

그 구성이 실제로 어떻게 쓰이는지는 오후에 구체화됐다. 또 다른 참여자가 오픈코덱스에서 코덱스의 서브에이전트로 GLM 계정 3개를 연동해 두니 토큰 절약이 많이 된다고 전한 것이다. 무거운 판단은 메인 모델이 맡고 반복적인 하위 작업은 값이 싼 쪽으로 흘려보내는 형태로, 한 모델에 몰려 있던 부하를 계정 단위로 흩어 놓는 셈이다.

저도 오픈코덱스에서 코덱스 서브에이전트로 glm 계정 3개 연동시켜 놓으니 토큰 절약이 많이되네요

오전에는 위험을 묻는 질문도 나왔다. 한 참여자가 오픈코덱스에서 클로드 계정을 OAuth로 연결해 쓰는 사람이 있는지, 예전에 밴이 된다는 이야기를 얼핏 들은 것 같다고 물었다.

opencodex 에서 claude Oauth로 연결해서 사용하시는분 있으신가요? 예전에 밴 된다 뭐 이렇게 얼핏 들었던것 같은데...

만든 쪽은 책임은 본인에게 있다는 단서를 달면서 자기 경험상으로는 그런 일이 없었다고 답했고, 다음 날 아침 또 다른 참여자도 밴은 없는 것 같다며 확인을 구했다. 정리하면 이날 방 안에 모인 근거는 실사용자 몇 명의 경험담이 전부이고, 정책상 문제가 없다는 확인이 나온 것은 아니다. 겪지 않았다는 진술은 위험이 없다는 뜻이 아니라 아직 관측되지 않았다는 뜻에 가깝다.

하나도 안당함

오후에는 다른 하네스가 화제로 올라왔다. 디스코드 스레드를 기반으로 동작하는 키마키가 채널과 스레드를 알아서 나눠 준다는 점에서 호평을 받은 것이다. 작업 단위를 사람이 손으로 정리하지 않아도 대화 공간이 저절로 갈라진다는 점이 편의로 받아들여졌다.

알아서 채널분리 스레드분리

두 도구가 같은 날 나란히 화제가 된 배경에는 공통된 문제의식이 있는 것으로 보인다. 한도가 부족하다고 느낄 때 선택지는 상위 요금제로 올라가거나 같은 일을 여러 곳에 나눠 얹는 것 둘 중 하나인데, 이날 방이 관심을 보인 쪽은 후자였다. 다만 이건 서드파티 도구 쪽 구성이지 벤더가 한도를 손댄 것은 아니라는 점은 분명히 해 둘 필요가 있다. 절약됐다는 토큰은 메인 모델 기준의 소비량이고, 서브로 붙은 계정 쪽 비용과 정책 위험은 사용자가 그대로 떠안는 구조이기 때문이다. 편의와 절약이 눈에 먼저 보이고 위험은 나중에 드러난다는 점에서, 이런 구성은 도입 시점보다 문제가 생긴 시점에 값이 매겨진다.