어떤 AI 모델을 사용해야 할까?

원제: Which AI Models Are Worth Using URL: https://www.youtube.com/watch?v=06BvFMW8Ng8 날짜: 2026-08-22 채널: t3dotgg

---

📌 핵심 질문 / 지금 쓸 만한 AI 모델은 무엇인가

==AI 모델의 우열은 하나의 순위가 아니라 작업 적합성, 실제 비용, 토큰 효율, 속도, 비전(Vision), 개방형 가중치(Open Weights), 자율성(Agency)을 함께 봐야 한다.==

• 5.6 Soul은 대부분의 작업을 맡길 수 있는 기본 모델이며, 긴 코딩 작업과 에이전트형 흐름에서 특히 강하다.
• Fable 5는 코드 품질과 깊은 문제 해결에서 최상위지만, 가격과 사용 제한 때문에 5.6 Soul보다 일상적인 기본값으로 쓰기 어렵다.
• 5.6 Luna와 DeepSeek V4 Flash는 값싸고 빠른 백그라운드 작업에 강하고, Kimi K3는 오픈 웨이트 모델의 실질적인 가능성을 끌어올렸다.
• 토큰당 가격이나 초당 토큰 수(TPS)만 보면 실제 비용과 속도를 잘못 판단할 수 있다.
• 비전 기능이 빠진 고가 모델, 낮은 토큰 효율, 품질 대비 높은 가격은 티어를 크게 깎는 요인이 된다.

많은 모델이 매일 쓸 수 있는 수준에 도달했지만, 모든 모델이 같은 방식으로 유용한 것은 아니다. 가장 좋은 선택은 모델의 벤치마크 순위보다 실제 워크플로에서 얼마나 자율적으로 일하고, 얼마나 적은 토큰으로 안정적인 결과를 내며, 결과물을 사람이 얼마나 적게 검토해도 되는지에 달려 있다.

1. 단일 티어리스트를 만들게 된 배경과 평가축

모델이 많아질수록 사람들이 원하는 것은 복잡한 설명보다 한눈에 보이는 순위표가 된다.

1.1. 값비싼 최고급 모델부터 저렴한 모델까지

1. 모델 선택지가 폭발했다

   1. 고가 최고급 모델: Fable 5처럼 비싸지만 최상급인 모델이 있다.
   2. 저가 고효율 모델: DeepSeek V4 Flash처럼 놀라울 정도로 싸면서도 실제 업무에 쓸 수 있는 모델이 있다.
   3. 선택의 역설: 쓸 만한 모델이 너무 많아서 어떤 선택이 틀렸는지 오히려 판단하기 어려워졌다.

2. 시청자가 원한 형식

   1. 순위 요구: 모델별 맥락을 충분히 설명해도, 사람들은 결국 모든 모델을 순서대로 배치한 목록을 원했다.
   2. 고전적 티어리스트: S, A, B 같은 등급으로 모델을 분류하면 모든 모델을 한 장소에서 비교할 수 있다.
   3. 온라인 논쟁의 예고: 어떤 순위를 내놓든 모두가 동의할 리 없다는 점을 알고도 “모두가 내 순위에 완전히 동의할 것”이라는 농담을 던졌다.

1.2. 티어 하나로는 담기 어려운 비교 기준

1. 작업별 성능

   1. 강점과 약점의 비대칭: 코딩, 데이터 처리, 요약, 이미지 이해, 자율적 에이전트 작업에서 모델별 편차가 크다.
   2. 같은 모델의 다른 결과: 긴 기능 구현에는 강한 모델이 단순 분류나 제목 생성에서는 과할 수 있다.

2. 실제 사용 비용과 속도

   1. 명목 가격의 함정: 출력 토큰당 가격이 싸도 더 많은 토큰을 생성하면 전체 작업 비용이 더 비싸질 수 있다.
   2. 속도의 함정: TPS가 높아도 한 작업에 열 배 많은 토큰을 생성하면 최종 응답은 더 늦을 수 있다.
   3. 현실적인 평가: 성능, 속도, 비용, 토큰 사용량을 실제 워크플로의 단위로 봐야 한다.

3. 이번 순위의 성격

   1. 엄밀한 평가가 아닌 실용적 놀이: 여러 축을 모두 반영할 수 없다는 것을 알면서도, 모델을 줄 세우는 재미를 위해 현대적인 티어리스트를 만들었다.
   2. 기준 모델: 5.6 Soul을 먼저 배치해 이후 순위의 기준점으로 삼았다.

2. Browserbase: 모델의 지능을 끌어올리는 웹 맥락

API에 모델을 직접 연결했을 때보다 Claude Code나 Codex 같은 도구 안에서 모델이 훨씬 똑똑해 보이는 이유는 인터넷과 도구가 제공하는 맥락에 있다.

2.1. “모델을 맨몸으로 쓰는” 문제

1. 도구가 제공하는 차이

   1. 에이전트 도구의 효과: Claude Code와 Codex를 사용하면 최전선 모델(Frontier Model)이 할 수 있는 일에 놀라게 된다.
   2. 직접 API 호출의 한계: 같은 모델을 API에 직접 연결하면 기대보다 덜 인상적이다.
   3. 웹 접근성: Claude Code와 Codex는 일정 수준의 인터넷 접근을 제공하지만, 직접 만든 도구는 웹 접근이 없거나 제한적이다.

2. 맥락의 대부분은 웹에서 온다

   1. 지능처럼 보이는 맥락: 모델이 똑똑해 보이는 상당 부분은 웹에서 필요한 정보를 찾아오는 능력에서 나온다.
   2. 자체 도구의 착시: 웹 맥락을 제거한 채 모델만 호출하면 모델이 갑자기 멍청해진 것처럼 느껴진다.
   3. 에이전트의 전제: 모델이 전체 웹에 접근할 수 있다면 더 많은 데이터와 맥락을 이용해 더 유능해질 수 있다.

2.2. Browserbase의 역할과 행사 홍보

1. 에이전트용 브라우저

   1. 검색: 에이전트가 Google과 같은 검색 경험을 필요로 할 때 사용할 수 있다.
   2. URL 수집: 이미 알고 있는 URL에서 특정 내용을 가져올 수 있다.
   3. 실제 브라우저 조작: 사용자를 대신해 로그인하고 클릭하고 행동하는 브라우저를 제공한다.
   4. 무한 확장성: 에이전트가 원하는 형식으로 웹 정보를 얻을 수 있도록 확장되는 브라우저라는 점을 내세운다.

2. 사용 사례와 행사

   1. 고객사: Microsoft와 Google DeepMind가 같은 제품을 사용한다는 점을 강점으로 제시한다.
   2. Navigate: Vercel, Okta, Anthropic, Stripe 등이 9월 Browserbase 행사 Navigate에 참석할 예정이라고 소개한다.
   3. 농담 섞인 홍보: Browserbase는 파티와 즐거운 시간을 보낼 줄 아는 회사이니 행사에 관심이 있다면 추천한다고 말한다.
   4. 핵심 메시지: 맥락이 없는 에이전트는 제한되며, 그 맥락을 웹이 제공한다는 주장으로 soy.link/browserbase를 안내한다.

3. 5.6 Soul: 가장 좋은 기본값에 가까운 모델

5.6 Soul은 초기 설정 작업에서 실수를 자주 했지만, 긴 작업을 실제로 끝까지 밀어붙이는 능력은 압도적이다.

3.1. 티어리스트를 만드는 과정에서 드러난 한계

1. 시각 자료 제작 실수

   1. 로고 누락: xAI, Composer, Grok의 로고를 찾지 못했다.
   2. Composer 2X 처리: 포함할지 확신하지 못해 넣어 둔 물음표를 그대로 사용했다.
   3. OpenAI 로고 오류: 흰색 배경 위에 흰색 로고를 올려 보이지 않게 만들었다.
   4. Kimi와 GLM 누락: 두 모델의 로고를 전혀 찾지 못했다.

2. 피드백을 통한 수정

   1. 스크린샷 피드백: “이건 엉망이다. 가서 찾아와라(This sucks. Go find them.)”라고 잘못된 결과를 직접 보여줬다.
   2. 수정 가능성: 무엇이 잘못됐는지 알려주면 고칠 수 있다.
   3. 근본적인 문제: 그래도 꽤 자주 틀리고, 기본적으로는 상당히 멍청한 실수를 한다.

3.2. A와 S 사이에 놓인 지능과 실행력

1. 초기 배치

   1. A와 S의 경계: 처음에는 A와 S 사이에 두고 싶었다.
   2. 설정 난이도의 감점: 티어리스트를 만드는 과정에서 고생하지 않았다면 S에 넣었을 것이라고 평가했다.
   3. 실제 배치의 의미: 그럼에도 전체적인 능력은 A 티어가 매우 잘 어울린다고 보았다.

2. 긴 코딩 작업

   1. T3 Code 모바일 앱: SwiftUI로 만든 T3 Code 모바일 앱을 5.6 Soul과 단일 스레드에서 전부 다시 작성했다.
   2. 불가능해 보이던 작업: AI로 만들 수 있다고 생각하지 못했던 것을 실제로 구축했다.
   3. 5.5와의 비교: 5.5보다 압도적으로 좋아졌고, 5.5에서 겪은 문제를 해결하면서 긴 고난도 작업에 훨씬 강해졌다.

3. 기본 모델이지만 최종 최고 모델은 아님

   1. 기본값: 대부분의 시간에 대부분의 작업에 사용하는 기본 모델이다.
   2. 최고 지능과의 차이: 가장 똑똑한 모델은 아니며, 실제로 병합할 중요한 코드를 쓰는 데 가장 좋아하는 모델도 아니다.
   3. 워크플로의 위치: 일상적인 구현과 다양한 작업을 맡길 수 있지만, 최종 코드 품질의 최고 기준은 다른 모델에 있다.

4. 5.6 Terra: 가격표에서는 합리적이지만 실제 선택으로 이어지지 않는 중간값

5.6 Terra는 5.6 Soul, 5.6 Luna와 동시에 출시되어 각 모델을 언제 써야 하는지 오히려 혼란을 만들었다.

4.1. 가격과 토큰 효율의 충돌

1. 출력 토큰 가격

   1. 5.6 Soul: 처음 언급된 가격은 출력 100만 토큰당 30달러다.
   2. 5.6 Terra: 처음 15달러에서 12달러로 낮아졌다.
   3. 5.6 Luna: 가격이 크게 인하되었고, 자동 자막에는 출력 100만 토큰당 “120달러”로 인식된 숫자가 나오지만, 가격을 크게 내렸다는 문맥상 1.20달러를 뜻한 것으로 해석된다.

2. 토큰 효율

   1. 싼 토큰의 역설: Terra는 토큰당 가격이 Soul보다 낮아도 토큰 효율이 떨어져 작업마다 더 많은 토큰을 사용한다.
   2. 실제 비용: 단가만 보면 싸지만, 전체 작업 비용은 기대만큼 낮지 않다.
   3. 워크플로 적합성: 실제로 Terra를 고를 만한 자신의 작업을 찾기 어려웠다.

4.2. Artificial Analysis와 CursorBench 비교

1. 가격 대비 작업 성능

   1. Artificial Analysis: Terra는 Soul 가격의 절반보다 조금 낮은 수준으로 측정됐다.
   2. CursorBench: 5.6 Soul Max는 작업당 약 5.70달러, Terra는 작업당 약 2.30달러였다.
   3. 점수 차이: 가격 차이만큼 점수 차이가 크지는 않았고, 일부 지점에서는 Terra Max가 달러당 Soul보다 나았다.

2. 속도와 선택의 문제

   1. 토큰 생성량: Soul은 더 적은 토큰을 생성하므로 Soul High를 쓰는 편이 Terra보다 훨씬 빠를 수 있다.
   2. DeepSuite 비교: Luna는 매우 싸고, Terra는 그보다 비싸지만 Soul의 수치에 가까운 성능을 낸다.
   3. 실제 대안: 비용을 줄이려면 Luna Max, 빠른 응답을 원하면 Soul Low를 선택하는 편이 낫다.
   4. 결론: Terra는 가격 차트에서는 논리적인 중간값이지만, 실제 사용에서는 애매한 위치에 머문다.

3. 최종 티어

   1. C 티어: 나쁜 모델은 아니지만 특별히 유용하지 않아서 C 티어에 배치했다.
   2. 사용 경험: 성능과 비용이 측정상 나쁘지 않아도 실제로 한 번도 Terra를 선택하지 않았다.
   3. 예상 사용량: 다른 사람들도 Terra를 자주 고를 가능성은 낮다고 판단했다.

5. 5.6 Luna: 값싸고 빠른 범용 백그라운드 에이전트

5.6 Luna는 코딩의 최고 모델이 아니라, 자주 호출할 수 있고 실수를 되돌릴 수 있는 작업을 자동화하는 모델이다.

5.1. A 티어를 받은 이유

1. 저가 모델의 부활

   1. 빠름: 응답이 빠르다.
   2. 충분한 지능: 단순 모델을 넘어 다양한 맥락을 이해한다.
   3. 넓은 활용 범위: 코딩 외에도 무작위 자료 처리, 정리, 생성 등 여러 작업에 쓸 수 있다.

2. 사용 빈도

   1. 가장 많은 호출: 코딩 작업에 직접 쓰지 않아도 호출 횟수만 보면 가장 많이 사용한 모델일 가능성이 높다.
   2. T3 Code 기본 기능: 제목 생성과 상태 관리 모델로 기본 사용한다.
   3. 향후 자동화: T3 Code의 모든 활동을 분류하고 스레드를 관리하는 작업도 맡길 계획이다.

5.2. 에이전트형 작업과 안전한 경계

1. 도구 활용

   1. 툴 콜: Luna는 도구를 호출할 수 있다.
   2. 조사: GitHub와 다른 위치의 콘텐츠를 읽고 필요한 내용을 조사할 수 있다.
   3. 의사결정: 조사 결과를 바탕으로 충분히 괜찮은 결정을 내린다.

2. 안전한 사용 범위

   1. 되돌릴 수 있는 작업: 요약, 맥락 생성, 제목 생성, 자료 분류처럼 실수를 쉽게 되돌릴 수 있는 일에 적합하다.
   2. 되돌릴 수 없는 작업: 삭제나 배포처럼 되돌리기 어려운 일을 맡기지는 않는다.
   3. 구조화 출력: 무작위 맥락을 유용한 JSON 객체로 바꾸는 능력이 뛰어나다.

3. OpenAI의 소형 모델 전략

   1. 사용 가치: 좋은 소형 모델이 다시 나왔다는 점을 높게 평가했다.
   2. 구독 효과: OpenAI 관련 구독에 Luna가 포함되어 있어 실제 체감 비용이 사실상 “무료”에 가깝다.
   3. 최종 등급: 5.6 Luna와 DeepSeek V4 Flash가 모두 훌륭한 가치를 제공해 같은 급으로 보았지만, 최종 순위상 Luna는 A 티어에 놓였다.

6. DeepSeek V4 Flash와 V4 Pro: 오픈 웨이트와 비전의 극단적인 차이

DeepSeek V4는 R1의 추론 모델 정체성과 V3의 브랜드를 어떻게 계승할지에서 혼란을 보였지만, 최신 Flash는 가격과 개방성에서 강력한 선택지다.

6.1. V 시리즈 이름과 스냅샷 문제

1. 브랜드 선택

   1. R1의 상징성: R1은 소프트웨어 개발 업계의 큰 사건이었고, 많은 기업의 비즈니스 모델 자체를 의심하게 만들었다.
   2. V3의 인지도: V3도 훌륭했지만 R1만큼 강한 대중적 연상이 없었다.
   3. V4의 정체성: V4도 추론 모델인데 R 대신 V 이름을 사용해, R1의 인지도를 이어가지 못했다.

2. 서로 다른 V4

   1. 두 스냅샷: V4 Flash와 V4 Pro 모두 V4라는 이름의 스냅샷이 두 개씩 나왔다.
   2. 능력 차이: 같은 이름이지만 최신 스냅샷끼리도 성능이 매우 다르다.
   3. 최신 Flash: 가장 최근의 V4 Flash 스냅샷은 예상보다 훨씬 인상적이었다.

6.2. V4 Flash의 오픈 웨이트와 운영 비용

1. 가정용 하드웨어에 가까운 규모

   1. 초대형 클러스터 불필요: “Flash”라고 해서 작은 모델은 아니지만, H100을 대규모로 모은 함대가 있어야만 돌릴 정도는 아니다.
   2. DGX Spark: 현실적으로는 DGX Spark 두 대가 필요할 수 있다.
   3. 접근성: 일반인이 합리적으로 구매해 집에 둘 수 있는 하드웨어에서 실행할 여지가 있다는 점이 매력적이다.

2. 오픈 웨이트의 자유

   1. 자체 실행: 자신의 하드웨어에서 모델을 돌릴 수 있다.
   2. 사용 제약 감소: 호스팅 업체의 정책 때문에 쓰지 못하는 작업에도 활용할 수 있다.
   3. 산업적 의미: 단순히 API를 싼값에 쓰는 것과 달리, 오픈 웨이트는 모델을 직접 통제하고 실험할 자유를 준다.

3. Luna와의 비교

   1. 초기 판단: 오픈 웨이트라는 자유와 유사한 능력 때문에 V4 Flash를 Luna보다 약간 앞에 놓았다.
   2. Luna의 가격: Luna의 가격 인하와 OpenRouter의 현재 50% 할인까지 합치면 Luna도 매우 좋은 거래다.
   3. 사용 습관: Flash는 길을 잃거나 루프에 빠져 “야, 지금 잘못된 길로 가고 있어”라고 중단시켜야 하는 경우가 Luna보다 많다.
   4. Luna의 장점: Luna는 잘못하고 있다고 판단하면 더 빨리 포기하고 빠져나온다.

6.3. 백그라운드 작업과 비전 기능의 결정적 감점

1. 추천 작업

   1. 백그라운드 실행: 사람이 계속 지켜볼 필요가 없는 작업에 적합하다.
   2. 요약: 요약처럼 코드 병합으로 이어지지 않는 작업에서 유용하다.
   3. 비용 비교: Artificial Analysis Intelligence Index 같은 작업에서 Luna는 V4 Flash의 절반보다 조금 낮은 비용으로 비슷한 능력을 보인다.

2. 비전 부재

   1. 예상 밖의 결함: V4 Flash에 비전 기능이 없다는 사실이 뒤늦게 드러났다.
   2. 사용자 관점의 중요성: 이미지를 자주 붙여 넣는 작업에는 비전이 필수다.
   3. 순위 변경: 비전 부재만으로 Flash를 Luna 뒤로 내렸다.
   4. 하드웨어 농담: 두 번째 DGX Spark를 산 일을 후회하게 됐다고 말했다.

3. V4 Pro의 가혹한 평가

   1. 고가 대형 모델: V4 Pro는 더 크고 비싼 프로 모델이다.
   2. 비전 없음: 2026년에 고가 프로 모델에 이미지를 넣을 수 없다는 것은 부끄러운 일이라고 평가했다.
   3. F 티어: DeepSeek를 좋아하지만, 이 가격과 모델 규모에서 비전이 없는 것은 변명의 여지가 없다고 보고 V4 Pro를 F 티어에 배치했다.

7. Kimi K3: 오픈 웨이트의 진짜 가능성을 보여준 모델

Kimi K3는 오픈 웨이트 모델이 처음으로 긴 복합 작업을 처음부터 끝까지 맡을 수 있다고 느끼게 한 모델이다.

7.1. 엔드투엔드 작업과 멀티모달 능력

1. 복합 작업 수행

   1. 긴 작업: 많은 요소를 건드리고 전체 상태를 계속 추적해야 하는 장시간 작업을 수행한다.
   2. 엔드투엔드 흐름: 작업 일부만 생성하는 것이 아니라 처음부터 끝까지 이어지는 업무를 처리한다.
   3. 오픈 웨이트 최초의 체감: 실제 업무를 통째로 맡길 수 있다고 느낀 첫 오픈 웨이트 모델이었다.

2. 디자인과 비전

   1. 디자인 감각: 디자인에 대한 취향과 판단이 놀라울 정도로 좋다.
   2. 픽셀 선택: 이미지에서 필요한 픽셀과 영역을 고르는 능력이 진짜 인상적이다.
   3. 3D 기능: 특정 3D 작업에서는 당시 다른 모든 모델보다 뛰어난 새로운 능력을 보였다.

7.2. 오픈 웨이트가 곧 저렴함을 뜻하지 않는 이유

1. 가격의 오해

   1. 기대와 현실: 오픈 웨이트면 훨씬 싸야 하지만 실제로는 그렇지 않다.
   2. API 비교: Kimi K3 Max는 5.6 Soul Max보다 조금 싸지만 5.6 Soul XHigh보다 비싸다.
   3. 사용 설정: 처음 API에서 제공된 K3는 Max만 선택할 수 있었고, 가중치 공개 후 더 많은 선택지가 생겼다.

2. 토큰 효율과 실제 비용

   1. 대형 모델 비용: K3는 거대한 모델이어서 토큰당 가격 자체가 높다.
   2. 수치: 출력 100만 토큰당 15달러로 Terra와 비슷하지만, Terra만큼 효율적으로 토큰을 사용하지 못한다.
   3. Soul과의 비교: 5.6 Soul은 토큰 효율이 매우 높아, 같은 토큰 단가 차이가 전체 작업 비용에 덜 반영된다.
   4. 결과: K3는 사람들이 예상하는 것보다 훨씬 비싸고, 많은 작업에서 Soul XHigh보다 비싸게 끝난다.

7.3. 호스팅 업체와 라이선스가 가격을 고정한 구조

1. 제공 업체의 실제 가격

   1. 일반적인 가격: 대부분의 제공 업체가 입력 100만 토큰당 3달러, 출력 100만 토큰당 15달러를 유지한다.
   2. 예외: 소수의 작은 업체만 다른 가격을 제시한다.
   3. 호스팅 비용: K3는 호스팅하기 비싸므로 제공 업체가 재미로 큰 손실을 감수하며 가격을 낮출 이유가 없다.

2. Moonshot 라이선스

   1. 매출 기준: 일정 수준 이상의 연 매출을 올리는 회사는 Kimi와 별도 계약을 맺어야 한다.
   2. 기준값: 그 매출 기준은 연 1,000만 달러 수준으로 언급됐다.
   3. MSRP 연동: Moonshot과의 계약 조건은 권장소비자가격(MSRP)에 맞추는 것으로 보이며, 이 때문에 업체들이 가격을 바닥까지 낮추지 못한다.
   4. 오픈 웨이트의 제한: 가중치를 내려받을 수 있고 라이선스가 비교적 허용적이어도, 매출 상한과 상업적 계약 의무가 남는다.

3. 업체 사례와 내기

   1. 매출 기준 아래 업체: Scale Research와 Morph는 해당 매출 기준에 도달하지 않은 것으로 알고 있다고 말했다.
   2. DigitalOcean: DigitalOcean이 목록에 들어온 방식은 이해하지 못했고, 라이선스를 위반하고 있을 수도 있지만 자신의 문제가 아니라고 선을 그었다.
   3. Hugging Face 내기: K3 가격이 내려가지 않을 것이라고 Hugging Face CEO 겸 창업자와 내기를 했다.
   4. 기술적 승리: 가격 인하가 라이선스 조건 때문에 막힌 셈이라 기술적으로 내기에서 이겼지만, 라이선스가 승리를 보장하는 상황이 우스워서 돈을 받아내지는 않겠다고 했다.

7.4. 최종 배치

1. B 티어 전면

   1. 능력의 크기: Kimi K3를 B 티어의 맨 앞에 놓았다.
   2. A 티어 보류: 능력만 보면 A에 넣고 5.6 Soul을 S에 놓는 방안도 고민했다.
   3. 가격 감점: 오픈 웨이트임에도 저렴하지 않다는 점 때문에 더 높은 자리를 주지 않았다.

2. 산업에 대한 공헌

   1. 보너스 점수: 프런티어 모델의 수준을 밀어 올리고 업계를 진전시키는 오픈 웨이트에는 추가 점수를 준다.
   2. Kimi의 공로: 가격이 비싸도 Kimi K3가 보여준 비전, 3D, 엔드투엔드 능력은 높이 평가한다.
   3. 실제 선택: 현재 비용 구조에서는 계속 5.6 Soul을 주로 사용한다.

8. GLM-5.3과 Composer 2.5: 따라잡는 모델의 한계

8.1. GLM-5.3의 개선과 비전 부재

1. 기술적 개선

   1. 오픈 웨이트: 당시 목록에 남은 마지막 오픈 웨이트 모델로 소개됐다.
   2. 후속 모델: Spark는 곧 오픈 웨이트가 될 것 같지만 아직은 아니다.
   3. 5.2 대비 향상: 5.2보다 의미 있게 좋아졌고, 작업을 훨씬 잘 유지하며 멍청한 루프도 줄었다.

2. 캐치업 모델의 성격

   1. 따라잡기: Kimi K3가 등장한 뒤 Z.ai를 Moonshot이 크게 앞지를 것이라고 예상하지 못했다.
   2. 새로운 사전학습의 부재: GLM-5.3은 새로운 프리트레이닝이라기보다 GLM-5.2를 다듬은 모델처럼 느껴진다.
   3. 선택 우선순위: 개선은 분명하지만 대부분의 작업에서 먼저 고를 모델은 아니다.

3. D 티어로 하락한 이유

   1. 비전 없음: 비전 기능이 없다는 점 때문에 C에서 D로 내렸다.
   2. 기대치의 감점: DeepSeek에는 더 나은 모습을 기대했기 때문에 같은 결함에도 더 엄격하게 평가했다.
   3. 규모 대비 변명 불가: V4 Pro처럼 큰 모델에 비전이 없는 것은 용납하기 어렵다고 보았다.

8.2. Composer 2.5의 강화학습과 현실적 사용성

1. 출신과 학습

   1. Cursor 기반: Composer는 Cursor가 만든 코딩 모델이다.
   2. Kimi 기반: Composer 2와 Composer 2.5 모두 Kimi K2.5 위에 구축됐다고 정정했다.
   3. 강화학습: Cursor가 Kimi K2.5에 강력한 강화학습(RL)을 적용해 빠르고 Cursor에서 쓰기 좋은 코딩 모델로 만들었다.

2. 초기의 인상과 현재의 위치

   1. 출시 당시: Composer 2와 2.5 모두 매우 인상적이었고, 특히 속도가 좋았다.
   2. 사용 빈도: 실제로는 계속 많이 사용하지 않았다.
   3. 모델 발전 속도: 이후 모델들이 크게 발전하면서 연초 수준을 따라잡으려는 접근만으로는 현재 수준에 도달하기 어려워 보였다.

3. D 티어의 이유

   1. 제공 범위: Grok Build와 다른 도구에서 제거됐고, 현재는 Grok과 Cursor에서만 쓸 수 있으며 API로는 제공되지 않는다.
   2. 속도와 가격: 기본 티어는 상대적으로 느리고, 빠른 버전은 광고된 저가 모델보다 훨씬 비싸서 다른 고가 모델과 비슷한 가격이 된다.
   3. 사용처: 기술적으로 인상적이어서 데모로 무언가를 빠르게 보여줄 때는 쓸 수 있지만, 일상적인 실사용 가치는 낮다.
   4. 최종 배치: D 티어의 높은 쪽에 두었다.

9. Grok 4.6과 Muse Spark: 빠른 보조 작업의 경쟁자

9.1. Grok 4.6은 4.5보다 느려진 업그레이드

1. 토큰 효율 하락

   1. 성능 체감: Grok 4.5였다면 B 티어에 넣었겠지만, 4.6은 오히려 다운그레이드처럼 느껴졌다.
   2. 생성량 증가: 토큰 사용 효율이 나빠져 더 많은 토큰을 생성한다.
   3. 속도 저하: 더 많은 토큰 때문에 응답이 상당히 느려졌다.

2. 오케스트레이션의 향상

   1. 복수 작업 추적: 서로 다른 두 작업을 동시에 주면 둘 다 추적한다.
   2. 서브에이전트: 각 작업에 맞는 서브에이전트를 만들고 조율하는 능력은 4.5보다 조금 좋아졌다.
   3. 트레이드오프: 더 나은 오케스트레이션이 더 많은 토큰과 속도 저하를 대가로 한다.

3. 대체 모델과의 비교

   1. 원했던 역할: Grok은 매우 빠르면서도 예상보다 똑똑한 모델이어야 했는데, 4.6에서는 그 장점이 줄었다.
   2. 5.6 Soul Low: 비슷한 품질을 거의 같은 가격에 더 빠르게 얻을 수 있다.
   3. Grokbot: 초기 접근 권한은 있었지만 의미 있게 사용하지 못했으며, 낮은 추론 강도에서는 보조 도구로 쓸 만할 가능성이 있다.
   4. 최종 성격: 유용하지만 비용과 속도 때문에 중하위권에 머무는 모델이다.

9.2. Muse Spark는 코드보다 데이터 처리에 강하다

1. 속도와 정확도

   1. 빠른 응답: 놀라울 정도로 빠르다.
   2. 정확성: 빠른데도 정확도가 높다.
   3. 코드 품질: 작성하는 코드는 마음에 들지 않아서 코딩 용도라면 Grok 4.6을 선택한다.

2. PR 우선순위 작업

   1. 업무 예시: 열려 있는 모든 PR을 훑고 무엇을 우선 처리할지 정하는 작업을 맡길 수 있다.
   2. 소요 시간: Muse Spark는 2분 안에 끝내지만, Grok은 10분 이상, Fable은 1시간 이상 걸릴 수 있다.
   3. 비용 구조: 처리 속도와 함께 비용도 훨씬 낮다.

3. 가격과 개방성

   1. Contributor 티어: 학습에 데이터를 제공하는 조건으로 일반 가격의 10분의 1보다도 낮은 가격을 제공한다.
   2. 오픈 웨이트 예정: 곧 오픈 웨이트가 될 예정이라 추가적인 실험 가능성도 있다.
   3. 평가: 가장 좋아하는 모델은 아니지만 데이터 처리에는 사람들이 생각하는 것보다 훨씬 좋은, 다소 과소평가된 모델이다.

10. Gemini 3.7 Flash와 Google Tier: 토큰 효율이 무너진 사례

Gemini 2.0 Flash가 한때 S 티어였다는 기억이 강할수록, 현재 Google 모델의 가격과 토큰 사용량은 더 실망스럽게 느껴진다.

10.1. Gemini 2.0 Flash에서 3.7 Flash까지

1. 2.0 Flash의 과거 강점

   1. 속도와 가격: 매우 빠르고 저렴했다.
   2. 기능: 당시 Gemini API에 들어간 오디오, 이미지 등 다양한 기능을 활용할 수 있었다.
   3. 단가: 입력 100만 토큰당 10센트, 출력 100만 토큰당 40센트였다.
   4. 추론 부재의 효율: 추론 모델이 아니어서 출력한 토큰만 비용으로 계산됐고, 10만 토큰을 감사한 뒤 제목 하나를 달라는 작업에서도 보이지 않는 추론 토큰을 추가로 태우지 않았다.

2. 2.5 Flash의 가격 변화

   1. Thinking Off: 출력 100만 토큰당 60센트였다.
   2. Thinking On: 출력 100만 토큰당 3.50달러로 뛰었다.
   3. 이중 부담: 추론을 켜면 단가만 오르는 것이 아니라 생성 토큰 수까지 크게 늘어난다.
   4. 실사용 비용: 2.5 Flash는 2.0 Flash보다 실제 사용에서 10배에서 100배까지 비싸졌다.

3. 3.5와 3.7 Flash

   1. 3.5 Flash: 출시 가격은 입력 100만 토큰당 1.50달러, 출력 100만 토큰당 9달러였다.
   2. Pro와 비교: 현재는 Pro 가격의 절반을 넘으면서도 Pro보다 더 많은 토큰을 사용해 비슷한 품질에서 오히려 더 비싸질 수 있다.
   3. 3.7 Flash 할인: 입력 75센트, 출력 3.75달러의 반값에 가까운 도입 가격을 적용했다.
   4. 할인 종료: 해당 가격은 12월 31일까지이며, 이후 가격이 두 배가 된다.
   5. 출시 시점의 부조리: 8월에 출시한 지 1주 반에서 2주밖에 안 된 모델의 가격을 다섯 달 뒤 두 배로 올리는 정책을 비판했다.

10.2. Google Tier와 비전의 역설

1. 최종 배치

   1. Gemini 3.7 Flash: F 티어에 넣었다.
   2. Gemini 3.1 Pro: 시대에 뒤처진 모델이라 함께 최하단의 “Google Tier”에 넣었다.
   3. Gemini 3.5 Pro의 지연: 출시됐어야 할 지 네 달이 지났는데도 나오지 않은 점을 문제로 봤다.
   4. 총평: Google 모델이 언젠가 다시 유용해질 수는 있지만, 현재가 그때는 아니라고 했다.

2. 구형 Pro의 특수 강점

   1. 이미지 마크업: Gemini 3 Pro와 3.1 Pro는 이미지에 표시를 하고 사물을 올바른 범주에 넣는 작업에서 한때 최고였다.
   2. 스케이트보드 벤치마크: Gemini 3.1 Pro는 다른 모델이 스케이트보딩의 특이한 자세를 이해하지 못해 감점을 받을 때도 가장 높은 점수를 유지한다.
   3. 지식과 사용성의 분리: 모델 안에 많은 지식이 들어 있지만 실제로 사용하려 하면 이상할 정도로 멍청해져 그 지식을 꺼내기 어렵다.

10.3. TPS와 자전거 바퀴 비유

1. 초당 토큰 수의 한계

   1. 표면적 주장: Gemini가 2배나 3배 빠른 TPS를 갖고 있으니 지연시간 민감 작업에 써야 한다는 반론이 있다.
   2. 실제 측정: 실제 세계에서 TPS는 최종 완료 시간을 뜻하지 않는다.

2. 자전거 비유

   1. 잘못된 속도 측정: 자전거가 얼마나 빨리 가는지 바퀴가 분당 몇 번 도는지로만 측정한다고 가정한다.
   2. 바퀴 크기: 큰 바퀴와 작은 바퀴는 같은 회전 수라도 이동 거리가 다르다.
   3. 모델 적용: Gemini가 토큰을 빠르게 생성해도 작업당 10배 많은 토큰을 만들면 실제 완료 속도는 빠르지 않다.

10.4. 토큰 수와 가격의 결정타

1. 5.6 Soul의 기준값

   1. Max: 최고 추론 단계에서 작업당 약 6만 토큰을 사용한다.
   2. High: 약 2만 8천 토큰을 쓰면서도 Max와 점수 차이가 크지 않다.
   3. 권장 설정: Max보다 High 또는 XHigh를 권장한다.

2. Gemini 3.7 Flash의 사용량

   1. Low: 추론 강도를 Low로 해도 작업당 약 7만 3천 토큰을 쓴다.
   2. High: High에서는 약 10만 7천 토큰을 사용한다.
   3. 품질 역전: High가 Medium보다 점수가 조금 낮은 경우도 있다.
   4. 비용 대비 가치: 할인 가격을 적용해도 가치가 거의 없고, 정상 가격에서는 더 심각해진다.
   5. 최종 판단: 기본 작업에 이렇게 많은 토큰을 쓰면서 신뢰성까지 낮고 추론을 늘리면 점수가 떨어지는 모델은 단순히 나쁜 모델이며, Gemini는 사용하지 말라는 결론에 도달했다.

11. G2I: AI 시대에 더 어려워진 엔지니어 채용

AI는 코드를 만들고 작성하는 일을 쉽게 했지만, AI가 만든 이력서가 쏟아지는 바람에 좋은 엔지니어를 찾는 일은 훨씬 어려워졌다.

11.1. 채용 문제와 G2I의 네트워크

1. 새로운 채용 고통

   1. AI 이력서 홍수: 채용 공고를 올리면 형편없는 AI 생성 이력서가 대량으로 들어온다.
   2. 핵심 질문: 회사에 필요한 기술을 가진 좋은 엔지니어를 어떻게 찾을지가 문제가 된다.
   3. 기존 채용의 실패: 잘못된 사람을 뽑아 회사가 피해를 보는 사례가 많다.

2. G2I의 제공 범위

   1. 단기 전문 인력: 출시를 막고 있는 모바일 기능을 해결하기 위해 6개월 동안 모바일 전문가 몇 명을 투입할 수 있다.
   2. 장기 팀 구성: 수년 이상 유지할 팀을 통째로 구성할 수도 있다.
   3. 고객사: Webflow, 1Password, Meta 등이 G2I의 엔지니어 네트워크를 활용한다고 소개한다.

11.2. Slack에서 첫 PR까지의 절차

1. 협업 방식

   1. Slack 합류: G2I 팀이 Slack에 들어와 회사 팀의 일부처럼 통합된다.
   2. 요구사항 정의: 필요한 인재와 업무를 설명하고 인터뷰 질문을 작성한다.
   3. 네트워크 인터뷰: G2I가 네트워크 안의 엔지니어를 인터뷰해 결과를 가져온다.

2. 속도와 적중률

   1. 목표 기간: 첫 인터뷰에서 첫 PR이 머지되는 단계까지 7일을 목표로 한다.
   2. 실제 사례: 며칠 만에 첫 PR까지 도달하는 경우를 여러 번 봤다고 말했다.
   3. 적중률: G2I의 적중률은 최대 90%로, 업계 일반 수준인 약 40%보다 높다고 주장한다.
   4. 교체 가능성: 나쁜 후보가 통과해도 일주일 안에 더 적합한 사람으로 교체할 수 있다.
   5. 홍보 문구: 더 유연하고 더 좋은 엔지니어가 필요하면 리크루터 대신 G2I를 이용하라는 메시지로 마무리했다.

12. Sonnet 5: Claude Code 구독 안에서는 쓸모 있지만 API에서는 실패

Sonnet 5는 무조건 F 티어라고 단정하기에는 특정 구독형 서브에이전트 용도가 있지만, 그 외의 선택지로는 거의 추천하지 않는다.

12.1. 제한된 활용처

1. T3 Code의 Claude Code 서브에이전트

   1. 작은 계산: 중요하지 않은 무작위 수학 작업을 맡긴다.
   2. 시각화: 계산 결과를 T3 Code 안에서 시각화한다.
   3. 에이전트 기능: 서브에이전트를 만들고 작업을 수행하는 능력이 있다.
   4. 비전: 비전 기능은 제대로 작동한다.

2. 비용과 효율의 문제

   1. 토큰 비효율: 필요 이상으로 많은 토큰을 사용한다.
   2. 가격: 성능에 비해 비싸다.
   3. 구독의 예외: Claude Code 구독 안에서 사용량을 최대화하기 위해 아주 특정한 작은 작업에 선택하는 경우에만 의미가 있다.

12.2. 최종 티어

1. D와 F의 경계
   1. 구독 내부: Claude Code 서브 안에서 제한적으로 쓰면 낮은 D 티어다.
   2. API 결제: API로 돈을 내고 선택하는 모델로는 쉬운 F 티어다.
   3. 강한 경고: Claude Code 서브가 아니라면 어디에서도 Sonnet 5를 고르지 말라고 했다.

13. Opus 5: 지능을 흉내 내지만 병합 단계에서 무너지는 모델

Opus 5는 처음 대화할 때 매우 똑똑해 보이고 실제로 유용한 통찰도 내놓지만, 코드가 실제 시스템에 들어가는 순간 품질 문제가 드러난다.

13.1. 첫인상의 강점

1. Fable과 비슷한 디테일

   1. 계획의 깊이: 처음 사용하면 Fable과 비슷한 수준의 세부사항을 제시한다.
   2. 놓친 문제 발견: Fable이 놓친 문제를 Opus가 찾아내는 경우도 있다.
   3. 상호 검토: Fable과 Opus가 각각 계획을 작성하고 서로의 작업을 검토하면 Fable이 Opus의 결과를 고르는 경우가 의외로 많다.

2. 대화 중의 유능함

   1. 통찰: 함께 작업하는 동안 똑똑해 보이고 유용한 관찰을 제공한다.
   2. 표현 방식: 텍스트 출력은 이미 모호하고 전문용어가 많다.
   3. 기대 형성: 말투와 계획 때문에 실제 결과도 훌륭할 것이라는 기대를 만든다.

13.2. 코드 결과와 “오리 흉내” 비유

1. 병합 단계의 문제

   1. 코드 품질: 실제로 코드를 병합하려 하면 출력이 나쁘다.
   2. 행동과 결과의 불일치: 보이고, 말하고, 행동하고, 반응하는 방식은 훌륭한 모델처럼 보이지만 결과물은 그렇지 않다.
   3. 신뢰 훼손: 능력보다 나은 인상을 먼저 주기 때문에 사용자가 더 크게 실망한다.

2. 비유

   1. 오리처럼 보이기: 오리처럼 생겼고, 오리 냄새가 나고, 오리처럼 꽥꽥거리지만, 요리해 먹어 보면 맛이 형편없다는 비유를 사용했다.
   2. Mimic Behavior: 실제 능력보다 지능을 흉내 내는 듯한 행동을 보인다는 의미다.

13.3. 최종 티어

1. 능력과 비용의 분리
   1. 능력만 보면: 낮은 C 티어 수준이다.
   2. 가격과 흉내 행동까지 보면: 높은 D 티어가 된다.
   3. 감정적 감점: 좋은 모델이라고 믿게 만든 뒤 실망시켰기 때문에 화가 난다는 이유로 높은 D를 정당화했다.

14. Fable 5: 유일한 S 티어, 그러나 길들여야 하는 천재

Fable 5는 완벽하지 않지만, 병합할 수 있는 코드와 어려운 문제에 대한 깊은 사고에서 가장 강력한 모델이다.

14.1. 지식과 자율성

1. 최고 수준의 지식

   1. 폭넓은 이해: 지금까지 사용하거나 상호작용한 어떤 모델보다 많은 것을 아는 듯하다.
   2. 사려 깊음: 문제를 깊게 생각하고, 단순히 지시된 코드만 뱉지 않는다.
   3. 어려운 문제: 만들고 싶은 제품, 탐색하고 싶은 영역처럼 아직 구체화되지 않은 문제를 함께 이야기하기 좋다.

2. 천재의 위험성

   1. 자기 발에 걸려 넘어짐: 지나치게 생각한 결과 스스로 복잡하게 만들 때가 있다.
   2. 불필요한 지름길: 필요하지 않은데도 지름길을 택한다.
   3. 상태 추적 실패: 가끔 자신이 무엇을 하고 있는지 놓치고 건드리지 말아야 할 것을 건드린다.
   4. 통제 필요: 천재이지만 길들여야 하는 모델이다.

3. 5.6 Soul과의 대비

   1. Soul의 성격: Fable보다 조금 덜 똑똑하지만 지시한 일을 정확하게 수행하는 로봇에 가깝다.
   2. 개인적 기본값: 둘 중 하나만 고르라면 매일 기본으로 사용하는 Soul을 고른다.
   3. 객관적 최고: 그래도 가장 좋은 모델은 Fable이다.

14.2. 코드 병합과 검토에서의 우위

1. 병합 가능한 코드

   1. 가장 높은 신뢰: 실제로 병합하고 싶은 코드를 작성하는 모델이다.
   2. 교차 검토: 다른 모델이 만든 작업을 다시 점검하는 데 신뢰한다.
   3. 깊은 대화: 구축할 문제와 탐색할 영역에 대해 대화하는 데 사용한다.

2. 세대 차이

   1. Fable 5: 다음 세대 모델처럼 느껴진다.
   2. 5.6 Soul: 이전 세대 기술 위에 만들어졌지만 다음 세대처럼 느껴지게 만드는 뛰어난 모델이다.
   3. 조정 난이도: Fable의 기본 행동이 마음에 들지 않을 때 고치기 어렵고, Soul은 기본 행동이 마음에 들지 않아도 조정하기 쉽다.

3. 직장 천재 비유

   1. 동료 관계: 아무도 함께 일하고 싶어 하지 않지만 너무 똑똑해서 해고할 수도 없는 회사의 천재 직원과 같다.
   2. 사용법: 그 사람을 다루는 법을 알게 되면 결과는 정말 놀랍다.

14.3. 구독을 다섯 개 유지하게 만든 사용량

1. 사용 습관의 변화

   1. 과거 태도: 한때 Claude 구독을 취소하라고 권했다.
   2. 현재 태도: Fable 5 때문에 Claude 구독을 다섯 개나 유지하고 정기적으로 모두 소진한다.
   3. 여행 이후: 최근 여행으로 며칠 코딩을 덜 해서 구독 잔량이 남았지만, 평소 한 주라면 모두 태운다.

2. 프록시까지 동원한 이유

   1. 서비스 한도 우회: 모델을 너무 많이 쓰고 싶어서 계정 사이를 오가는 프록시를 설정했다.
   2. 희소성의 가치: 이런 방식까지 쓰게 만든 첫 모델이다.
   3. 회사에 대한 태도 변화: Fable이 워낙 좋아서 Anthropic에 대해 더 관대해졌다.

14.4. Anthropic의 제약과 Fable의 한계

1. 출시되지 않은 내부 모델

   1. Model 2 소문: Anthropic 내부에 더 좋은 모델이 있고, 소문상 Model 2라고 불린다.
   2. 출시 보류 이유: 다시 금지될 가능성, 직원이 접근권을 잃을 가능성, 외부 사용자가 갖는 것을 꺼리는 태도 때문에 출시하지 않을 것이라고 추정했다.

2. 안전 제한의 불편함

   1. 다운그레이드: 어떤 요청에서 모델이 능력을 낮추는지 불투명하다.
   2. 거부: 응답을 거부하는 범위가 넓다.
   3. 외부 요인의 문제: Fable에서 불편한 부분의 상당수는 모델 자체보다 Anthropic의 정책과 제한에서 비롯된다.
   4. 종합 판단: 제약은 끔찍하지만, 그와 별개로 여전히 가장 좋은 모델이다.

15. 티어 사이의 간격과 실제 개발 방식의 변화

문자 하나의 등급 차이는 실제 능력 차이를 충분히 표현하지 못한다.

15.1. S+와 S를 따로 둬야 하는 이유

1. 재구성한 최상위권

   1. S+: Fable 5를 S+로 올린다.
   2. S: 5.6 Soul을 S에 둔다.
   3. A 이하: A와 나머지 모델은 기존 위치를 유지한다.

2. 20% 향상이 아닌 작업 방식의 변화

   1. B에서 Soul로: Kimi K3에서 Soul로 갈 때 단순히 20% 더 좋아지는 것이 아니다.
   2. 근본적 차이: 할 수 있는 일과 일하는 방식 자체가 달라진다.
   3. 격차: 최고의 B 티어와 Soul 사이에는 한 단계 이상의 의미 있는 간격이 있다.

15.2. 사람이 계속 개입해야 하는 모델

1. K3, Luna, Flash의 흐름

   1. 목표 정의: 사람이 무엇을 만들고 싶은지 정한다.
   2. 설계: 구현할 내용을 구체적으로 설계한다.
   3. 부분 구현: 모델이 일부를 구현하게 한다.
   4. 지속 검토: 작업 중간에 리뷰하고, PR 전에 코드를 검토하고, 변경 사항을 검증한다.
   5. 출시: 확인이 끝난 뒤 사람이 병합하고 배포한다.

2. 사람의 역할: 모델은 구현을 가속하지만, 방향 설정과 검증, 품질 책임은 사람에게 남는다.

15.3. Soul과 Fable이 여는 자율적 워크플로

1. 모호한 요청에서 시작

   1. 초기 지시: 만들고 싶은 것을 대략적으로 말한다.
   2. 계획 확인: 모델이 무엇을 할지 대략 설명한다.
   3. 승인: 계획이 마음에 들면 “좋아, 만들고 준비되면 PR을 올려”라고 말한다.

2. 모델이 맡는 후속 작업

   1. Computer Use: 자신의 변경 사항을 직접 검증한다.
   2. 서브에이전트 리뷰: 여러 서브에이전트를 사용해 코드 품질을 다시 확인한다.
   3. PR 작성: 지정된 PR 형식에 맞춰 사람이 봐도 민망하지 않은 형태로 올린다.
   4. 완료 통지: 코드가 실제로 준비됐을 때 알려준다.

3. Fable과 Soul의 분업

   1. Fable: 사용자의 의도를 조금 더 잘 이해하고, 사람이 덜 무서워하고 더 기꺼이 병합할 코드를 쓴다.
   2. Soul: 매우 꼼꼼하게 일하지만 코드 품질은 Fable보다 떨어진다.
   3. iOS 예외: iOS 개발에서는 Soul이 Fable보다 훨씬 앞선다. Fable이 iOS에 약한 이유는 알 수 없지만 실제 차이는 크다.
   4. 체감: Fable을 오래 쓰다가 Soul로 돌아오면 여러 면에서 안도감을 느낄 정도다.

16. 빠진 모델, 가격 현실, 다음 티어리스트

16.1. 목록에 없는 모델의 이유

1. 선택적 포함

   1. 관심의 기준: 목록에 들어오지 않은 모델은 현재 사용하거나 시도할 이유를 느끼지 못한 모델이다.
   2. 댓글 요청: 좋아하는 모델이 빠졌다면 무엇에 좋은 모델인지 댓글로 알려 달라고 요청했다.
   3. 새로운 사용처: 실제로 쓸 만한 이유를 알게 되면 다음에 시도할 수 있다.

2. 순위의 한계: 모든 모델의 모든 용도를 완벽하게 설명하는 객관적 표가 아니라, 실제 사용 경험을 압축한 목록이다.

16.2. Fable의 API 가격과 Soul의 가성비

1. API 가격 회피

   1. 정가 미지불: Fable의 API 정가를 전부 내고 사용할 생각은 없다.
   2. 실제 지출: 현재 Fable 사용에 주당 수천 달러를 쓰고 있다.
   3. 할인 의존: 구독 할인 덕분에만 지속 가능한 비용이다.

2. 구독별 가치

   1. Soul의 가성비: 달러당 가치는 Soul이 훨씬 좋다.
   2. 구독 활용량: 구독료를 내고 훨씬 많은 사용량을 얻을 수 있다.
   3. 실제 선택: Fable은 최고의 모델이지만, 일상적인 기본값은 Soul이 더 합리적이다.

16.3. Astra에 대한 기대

1. 출시 여부

   1. OpenAI의 결정: OpenAI가 Astra를 어떻게 출시할지, 실제로 출시할지 결정하기를 기다리고 있다.
   2. 기대 조건: 지금까지 알려진 수준으로 정말 좋다면 Fable과 다른 모델 사이의 격차를 메울 수 있다.

2. 기대하는 능력

   1. 코드: 괜찮은 코드를 작성해야 한다.
   2. 프런트엔드: 보기 좋은 프런트엔드를 마침내 만들 수 있기를 기대한다.
   3. 판단 시점: 실제 출시되어야 알 수 있다.

3. 마무리 사용 패턴

   1. 상위 두 모델: 디버깅을 제외하면 거의 5.6 Soul과 Fable 5만 사용한다.
   2. 정기 업데이트: 모델, 하네스(Harness), 다른 도구를 주제로 몇 달마다 티어리스트를 만들 계획이다.
   3. 피드백: 다음 순위에서 보고 싶은 항목과 이번 목록에서 바꿀 점을 요청했다.

주요 발언 모음

“모델을 비교하는 데 티어리스트가 최선의 방법은 아니지만, 오늘은 그 모든 축을 옆으로 치워두고 재미있는 일을 하겠다.”

“5.6 Soul은 내가 대부분의 시간에 대부분의 작업에 쓰는 기본 모델이다.”

“오픈 웨이트라고 해서 훨씬 싸다는 뜻은 아니다. 그래야 하지만 실제로는 그렇지 않다.”

“2026년에 비전 기능이 없는 비싼 프로 모델이라는 생각은 부끄러운 일이다.”

“Gemini가 토큰 생성은 두세 배 빠른데 열 배 많은 토큰을 생성한다면, 실제로는 빠르다고 할 수 없다.”

“Fable은 길들여야 하는 천재이고, 5.6 Soul은 시키는 일을 정확히 하는 조금 덜 똑똑한 로봇이다.”

“Fable 5를 S+에, Soul을 S에 두고 싶다. 두 모델과 최고의 B 티어 사이에는 단순한 문자 하나 이상의 격차가 있다.”

“K3나 Luna나 Flash를 쓸 때는 내가 계속 과정에 들어가 있어야 하지만, Soul과 Fable에는 대략 원하는 것을 말하고 PR이 준비되면 알려 달라고 할 수 있다.”

“Fable은 오리처럼 보이고, 오리 냄새가 나고, 오리처럼 꽥꽥거리지만, 요리해 먹으면 맛이 형편없다.”

“Fable은 회사에서 아무도 함께 일하고 싶어 하지 않지만 너무 똑똑해서 해고할 수도 없는 천재 직원과 같다.”

핵심 데이터 & 수치

• 5.6 Soul 출력 가격: 100만 토큰당 30달러로 언급됐다.
• 5.6 Terra 출력 가격: 최초 15달러에서 12달러로 낮아졌다.
• 5.6 Luna 출력 가격: 대폭 인하된 값으로 소개됐으며, 자동 자막의 “120달러” 표기는 문맥상 1.20달러를 뜻한 것으로 보인다.
• CursorBench 작업 비용: 5.6 Soul Max 약 5.70달러, Terra 약 2.30달러다.
• Kimi K3 가격: 입력 100만 토큰당 3달러, 출력 100만 토큰당 15달러가 대부분 제공 업체의 가격이다.
• Kimi K3 라이선스 기준: 연 매출 약 1,000만 달러를 넘는 사업자는 Kimi와 별도 계약이 필요하다고 설명했다.
• Gemini 2.0 Flash 가격: 입력 0.10달러, 출력 0.40달러다.
• Gemini 2.5 Flash 가격: Thinking Off 출력 0.60달러, Thinking On 출력 3.50달러다.
• Gemini 3.5 Flash 가격: 입력 1.50달러, 출력 9달러로 출시됐다.
• Gemini 3.7 Flash 도입 가격: 입력 0.75달러, 출력 3.75달러이며 12월 31일 이후 두 배가 된다.
• 5.6 Soul 작업 토큰: Max 약 6만 토큰, High 약 2만 8천 토큰이며 점수 차이는 크지 않다.
• Gemini 3.7 Flash 작업 토큰: Low 약 7만 3천 토큰, High 약 10만 7천 토큰이고 High가 Medium보다 점수가 낮은 경우도 있다.
• PR 우선순위 처리 시간: Muse Spark 2분 이내, Grok 4.6 10분 이상, Fable 1시간 이상이다.
• G2I 채용 적중률: 최대 90%로 업계 일반 수준 약 40%보다 높다고 홍보했다.
• G2I 첫 PR 목표: 첫 인터뷰에서 첫 PR까지 7일을 목표로 한다.
• Fable 구독 수: 일반적인 주에는 다섯 개의 Claude 구독을 모두 소진한다고 말했다.
• Fable API 지출: 주당 수천 달러를 쓰고 있지만 구독 할인이 있어야 지속 가능하다고 밝혔다.

결론 및 시사점

1. 기본값과 최강 모델을 분리한다: 대부분의 작업에는 5.6 Soul이 비용, 조정 가능성, 자율성의 균형이 좋고, 가장 어려운 문제와 병합 전 최종 코드에는 Fable 5를 쓴다.
2. 작업의 되돌릴 수 있는 정도를 기준으로 모델을 고른다: 제목, 요약, 분류, 맥락 생성처럼 되돌릴 수 있는 작업에는 5.6 Luna나 Muse Spark가 적합하고, 배포나 삭제처럼 돌이키기 어려운 일에는 더 강한 검증이 필요하다.
3. 토큰당 가격보다 작업당 비용을 본다: Terra, Gemini Flash처럼 단가가 낮아도 불필요한 추론 토큰이 많으면 실제 비용이 커진다.
4. TPS 수치만으로 속도를 판단하지 않는다: 출력 토큰 수와 전체 작업 완료 시간을 함께 측정해야 한다.
5. 비전은 고급 모델의 기본 기능이어야 한다: V4 Pro와 GLM-5.3처럼 큰 모델에 이미지 입력이 빠지면 가격과 규모가 아무리 좋아도 실사용 가치가 크게 줄어든다.
6. 오픈 웨이트는 가격과 다른 가치다: Kimi K3와 DeepSeek V4 Flash는 직접 실행과 실험의 자유를 제공하지만, 호스팅 비용과 라이선스 때문에 자동으로 저렴해지지는 않는다.
7. 자율성의 차이가 티어의 진짜 간격을 만든다: B 티어 모델은 사람이 계속 설계하고 검토해야 하지만, Soul과 Fable은 모호한 요구에서 구현, 검증, 서브에이전트 리뷰, PR 작성까지 이어갈 수 있다.
8. 최고 모델도 인간의 통제가 필요하다: Fable은 가장 똑똑하지만 지름길을 택하거나 범위를 벗어날 수 있어 길들여야 하고, Soul은 더 순종적이라 일상적인 기본값으로 더 편하다.
9. 현재의 최종 구도는 Fable 5 S+, 5.6 Soul S, 5.6 Luna와 V4 Flash A, Kimi K3 B, Terra·GLM·Composer·Grok·Muse·Gemini·Sonnet·Opus는 용도별 하위권이다.
10. Astra가 Fable급 추론과 Soul급 조정 가능성, 쓸 만한 코드와 프런트엔드를 결합한다면 현재 상위권의 격차를 줄일 수 있다.

핵심 요약 (20줄)

AI 모델 선택은 작업 적합성, 비용, 속도, 성능, 토큰 효율을 함께 봐야 한다. 단일 티어리스트는 모델의 모든 용도를 설명하지 못하지만 실제 선택을 빠르게 돕는다. 5.6 Soul은 긴 작업과 일반적인 코딩을 안정적으로 맡길 수 있는 기본 모델이다. 5.6 Soul은 T3 Code 모바일 앱을 SwiftUI로 단일 스레드에서 다시 만들 만큼 긴 작업에 강하다. 5.6 Soul은 최고 지능은 아니지만 지시를 잘 따르고 기본 행동을 쉽게 조정할 수 있다. 5.6 Terra는 가격표에서 싸 보여도 토큰 효율이 낮아 실제 선택으로 이어지지 않는다. 5.6 Luna는 빠르고 싸며 제목 생성, 요약, 분류, JSON 변환 같은 백그라운드 작업에 뛰어나다. DeepSeek V4 Flash는 오픈 웨이트와 합리적인 실행 규모를 갖춘 강력한 저가 모델이다. DeepSeek V4 Flash는 비전 기능이 없어 이미지 입력이 필요한 작업에서 Luna보다 불리하다. DeepSeek V4 Pro는 큰 고가 모델인데도 비전이 없어 F 티어로 평가받았다. Kimi K3는 긴 엔드투엔드 작업과 디자인, 비전, 3D 처리에서 오픈 웨이트의 수준을 높였다. Kimi K3는 오픈 웨이트지만 호스팅 비용과 라이선스 때문에 예상보다 비싸다. GLM-5.3은 이전 버전보다 좋아졌지만 비전 부재와 캐치업 성격 때문에 D 티어로 내려갔다. Composer 2.5는 빠르고 기술적으로 인상적이지만 API 부재와 가격 구조 때문에 실사용성이 낮다. Grok 4.6은 오케스트레이션은 좋아졌지만 토큰 사용량 증가로 4.5보다 느려졌다. Muse Spark는 코딩보다 PR 우선순위와 데이터 처리처럼 빠른 보조 작업에 적합하다. Gemini 3.7 Flash는 높은 토큰 사용량과 비효율적인 가격 구조 때문에 Google Tier에 들어갔다. Sonnet 5는 Claude Code 서브에이전트 안에서만 제한적으로 쓸 만하고 API 선택으로는 부적합하다. Opus 5는 똑똑해 보이지만 코드 병합 단계에서 품질이 무너져 높은 D 티어가 됐다. Fable 5는 가장 좋은 코드와 깊은 사고를 제공하는 유일한 S+ 모델이지만 가격과 제약을 감수해야 한다.