클로드 페이블 토큰 소모와 오퍼스 재작업

오늘 새벽 1시를 넘기던 무렵, 에이전트코리아 대화창에 한 참가자가 급하게 글을 올렸다. 클로드 계열 새 모델인 페이블(Fable)이 너프를 시작했다는 것이었다. 근거로 든 것은 토큰, 곧 모델이 글을 읽고 쓸 때 세는 사용량 단위였다.

갑자기 토큰 주르륵 닳기 시작함

같은 참가자는 그 증상이 두 시간 전부터 이어졌다고 덧붙였다. 성과는 못 내고 쓸모 없는 결과물만 쏟아 낸다는 불평도 함께였다. 너프는 모델 성능이나 한도가 일부러 깎였다는 뜻으로 쓰이는 말인데, 이 대화에서 실제로 깎였는지 확인된 것은 없다. 어디까지나 이 참가자가 체감을 그렇게 해석한 것이다.

접기로 한 이유

한 시간 가까이 지난 뒤 같은 참가자는 이제 페이블을 쓰지 않겠다고 선언했다. 이유는 조건을 덧붙일수록 결과가 나아지기는커녕 멀어졌다는 데 있었다. 그 과정을 화살표로 이어 적은 한 줄이 대화에 남았다.

슬롭을 보완하기 위한 조건 추가 → 조건 추가 → 조건 추가 → 더 뭔가 할 수 있는게 없음 → 다른거 수정 → 다른거 수정 → 점점 멀어짐

슬롭은 AI가 뽑아낸 조잡한 결과물을 가리키는 말로 읽힌다(기사 설명). 이 참가자는 페이블의 상위 추론 설정이 과한 생각으로 단순한 병렬 작업을 오히려 망친다고도 주장했다. 다른 참가자는 토큰 소모량이 심했고, 자신이 쓰는 작업에서는 오퍼스와 큰 차이를 못 느꼈다고 말을 보탰다. 이 참가자 역시 저녁까지 페이블로 작업했고, 오케스트레이션을 다시 짰다고 했다.

코드를 열어 보니

더 구체적인 피해담은 그 뒤에 나왔다. 결과물이 자꾸 뽑히지 않아 코드 어딘가에 오류가 있는 줄 알고 한참을 뒤졌다는 얘기였다. 원인을 따라가던 끝에 나온 발견은 이랬다.

코드 다시 열어보니까 페이블 슬롭덩이로 짜져있는

이 참가자는 곧바로 오퍼스로 코드를 다시 짜는 중이라고 했고, 어떻게 사흘을 못 가느냐며 3시간 천하라고 탄식했다. 그는 페이블로 세션 맥락을 절반쯤 쓴 뒤 같은 세션에서 모델만 오퍼스로 바꿔 이어 갔는데, 오퍼스가 수습해 줘 고맙다고 했다. 다른 참가자는 페이블이 짠 오케스트레이션 구조를 오퍼스가 고쳐 주는 모습을 전했다. 글을 올린 참가자는 오퍼스가 더 똘똘하다고, 이 다른 참가자는 말도 더 잘한다고 평했다. 이 평가는 두 참가자의 체감일 뿐, 객관적 비교는 대화에 없다.

모델마다 맞춘 구성이 따로 필요하다는 풀이

세 번째 참가자는 사용량 상태를 지켜보는 감시 보드를 미리 박아 둔 덕에 페이블이 알아서 멈춘 것 같다고 했고, 오퍼스든 페이블이든 절대 신뢰하지 않는다는 태도를 밝혔다. 이어 오퍼스든 페이블이든 처음 단일 작업은 참 잘하는 것처럼 보인다는 관찰을 내놓았다.

각 모델에 맞게 깍인 도메인 오케스트레이션이 적용이 되야 하ㅡㄴ거 같음…

오케스트레이션은 여러 단계의 작업을 모델에게 나눠 맡기고 조율하는 구성을 뜻한다(기사 설명). 이 참가자는 오퍼스가 페이블 출시 전에 이미 깎이고 모델별로 맞춰져 있었기 때문에 지금은 더 잘하는 것일 수 있고, 페이블은 아직 맞춤 작업을 안 해서 그렇다는 가설도 달았다. 이 가설은 대화에서 검증되지 않았다.

이 새벽의 대화를 한 줄로 읽으면, 새 모델의 성능 평가가 모델 자체의 우열보다 그 모델에 맞춰 쌓은 작업 구성의 두께와 섞여 있을 수 있다는 점이다. 반응도 갈렸다. 한쪽은 오퍼스에게 고마워했고, 다른 쪽은 아직 페이블을 길들이지 못했을 뿐이라고 봤다. 어느 쪽이 맞는지는 이 대화만으로 가릴 수 없다.