구현체 선택은 결국 속도와 가격 사이의 저울질이었다

에르메스단에서는 어떤 모델과 구현체를 쓸지를 놓고 실용적인 비교가 이어졌다. 한 참가자는 이것저것 다 비교해본 결과 opencode go가 가장 낫다고 정리했고, 커맨드 코드는 특정 모델만 쓸 수 있다는 취지로 아쉬움을 짚었다.

"이거저거 다 비교해보니까"

"opencode go가 젤낫네요"

"command code도 특정모델만싸고"

속도를 둘러싼 실측도 공유됐다. 한 참가자가 여러 provider 인증을 cliproxy로 중앙화하면 tps(초당 토큰 처리량)도 느려지는지 묻자, 다른 참가자는 오픈코덱스를 프록시로 우회하는 구성으로 쓰니 160 tps 정도로 다소 떨어진 듯하다고 답했다. 다른 곳에서는 딥식(DeepSeek)이 200 ~ 300 tps까지 나온다는 말도 있었지만, 워낙 빨라서 체감 차이는 크지 않다고 덧붙였다.

"cliproxy 사용해서 여러 provider 인증 중앙화하면 tps도 느려지나요?"

"오픈코덱스 우회해서 쓰니까 160 tps 정도 나오던데 좀 떨어진듯해요"

"다른곳에서는 200-300 나온다던뎀 딥식"

"워낙 빨라서 큰 차이는 못느끼겠어요"

가격 앞에서는 셈법이 더 단순해졌다. 한 참가자가 딥식 4.1 flash max와 grok 4.6 high 중 무엇을 구현체로 쓰면 좋을지 묻자, 다른 참가자는 짧고 명료하게 싼 쪽을 택하라고 답했다. 속도·품질 비교가 길어질수록 결국 비용이 결정을 가르는 마지막 기준이 되는 모습이었다.

"딥식 4.1 flash max vs grok 4.6 high . 뭘구현체로 쓰면좋을까요"

"싼거요"

새 모델 소식도 곁들여졌다. 한 참가자는 솔라(Solar) 4 미니(35b a3b) 프리뷰가 나왔다는 소식을 전했고, 다른 참가자는 35b 규모라는 점에 말끝을 흐리며 반응했다. 구현체를 고르는 대화는 결국 속도·호환성·가격을 하나씩 저울질하는 실전 정보 교환으로 흘렀다.

"Solar 4 mini(35b a3b ) 프리뷰 하네요"

"35b면 .."

이날 오간 tps 숫자들은 절대적인 성능 지표라기보다 저마다의 구현 환경에서 얻은 경험치에 가깝다. cliproxy로 인증을 중앙화하면 우회 경로가 하나 늘어나는 만큼 속도가 다소 떨어지는 것은 자연스러운 트레이드오프이고, 딥식처럼 애초에 응답이 빠른 모델은 그 손실을 체감하기 어렵게 만든다. 참가자들이 공유한 수치는 '이 구현체가 저 구현체보다 빠르다'는 절대 비교가 아니라, 중앙화가 주는 편의와 속도 손실을 어디까지 감수할 수 있는지를 각자 계산한 결과에 가까웠다.

가격이 마지막 기준으로 등장하는 패턴도 낯설지 않다. 속도·품질 차이가 근소해질수록 결정은 결국 비용으로 수렴하는데, 이는 선택지가 많아진 지금 국면에서 더 두드러진다. Solar 4 미니 같은 소형 모델이 계속 나오는 것도, 모든 작업에 최상위 모델이 필요하지는 않다는 인식이 자리 잡고 있음을 보여준다.