Midnight AI Groove 26-04-29

DJ 렌: 안녕하세요, 깊은 밤의 지성과 비트를 잇는 시간. Midnight AI Groove의 내비게이터 DJ 렌입니다.

DJ 미오: DJ 미오입니다. 오늘의 AI News, 타이틀부터가 "not much happened today"(오늘은 별일 없었습니다)라고 되어 있는데…… 아니 아니, 읽어보니 전혀 “아무 일도 없었던 날”이 아니네요.

DJ 렌: 맞아요. 대상 기간은 2026년 4월 28일부터 4월 29일. AI News는 12개의 subreddit, 544개의 Twitter 계정을 체크했지만, 이번에는 Discord는 추적하지 못했습니다. 게다가 "AI News는 이제 Latent Space의 일부입니다"라거나, "메일 빈도도 선택할 수 있습니다"와 같은 운영 측면의 안내도 포함되어 있었죠.

DJ 미오: 그래서 전체적인 분위기를 한마디로 말하자면, 화려한 초대형 뉴스는 적지만, 에이전트 구현 (Agent implementation), 하네스 설계 (Harness design), 추론 기반 (Inference infrastructure), 로컬 LLM 운용, 그리고 가격 파괴와 같이 실무에 유용한 이야기들이 굉장히 많았던 인상이에요.

DJ 렌: 우선 Twitter recap의 핵심은 여기입니다. Codex, Cursor SDK, VS Code의 하네스 강화.

OpenAI는 Codex를 단순한 코딩 지원이 아니라, 더 넓은 지식 노동의 작업 영역으로 확장하고 있어요. 연구 요약, 스프레드시트, 의사결정 추적 같은 업무에도 사용하게 하려는 것이죠.

DJ 미오: 게다가 프로덕트 측면의 움직임이 상당히 구체적이에요.

Business/Enterprise 대상 고객을 위해 6월 말까지 Codex 전용 시트를 좌석 요금 0달러로 제공. 나아가 Supabase 연동이나, 구현 플랜을 FigJam 보드로 변환하는 Figma 플러그인까지 나왔습니다.

DJ 렌: 커뮤니티 게시글에서도 app-server적인 사용 방식이나, 더 복잡한 **에이전트 워크플로우 (Agent workflow)**로의 전개가 보이고 있어요. 즉, Codex는 IDE 내의 보조 기능이라기보다, 지속적 컨텍스트 (Sustained context), 외부 도구, 연동, 팀 도입을 갖춘 “업무용 기반”에 가까워지고 있는 셈이죠.

DJ 미오: 그리고 그 이면에서 일어나고 있는 기술적 무게 중심의 이동이 흥미로워요.

이제 승부는 단순한 모델의 지연 시간 (Latency)이 아니라, **에이전트 루프 시스템 엔지니어링 (Agent-loop systems engineering)**에 달려 있어요. OpenAI에 따르면, Responses API에서 WebSocket 모드를 사용하면 도구 호출(Tool calling) 사이에서 상태를 warm하게 유지할 수 있어 중복 작업을 줄이고 최대 40%까지 가속화할 수 있다고 합니다.

DJ 렌: 이 부분이 중요합니다. 에이전트의 경험을 결정하는 것은 모델의 IQ만이 아니에요. **상태 유지 (State retention), 메모리, 검색, 하네스 품질, 도구 오케스트레이션 (Tool orchestration)**이 UX를 지배하기 시작했습니다.

VS Code 측도 밀리지 않고, 워크스페이스를 가로지르는 시맨틱 인덱싱 (Semantic indexing), 교차 리포지토리 검색 (Cross-repo search), 채팅 세션 인사이트 (Chat session insights), 스킬 컨텍스트 (Skill context), Copilot CLI의 원격 제어 (Remote control), 나아가 **프롬프트/에이전트 평가 확장 프로그램 (Prompt/agent evaluation extension)**까지 투입했습니다.

DJ 미오: 이 평가 확장 기능은 단순히 "좋은 답변이 나왔나?"를 넘어, 프롬프트, 스킬, 명령문의 튜닝을 지속적으로 돌리는 것을 전제로 한다는 점이 요즘 트렌드 같네요.

DJ 렌: 그리고 Cursor. 이것도 상당히 큽니다.

Cursor SDK를 통해 Cursor를 지탱하는 것과 동일한 **런타임 (Runtime), 하네스 (Harness), 모델 (Models)**을 CI/CD, 자동화, 제품 내 임베디드 에이전트에 사용할 수 있게 했습니다. 이는 Cursor가 좌석 기반의 IDE 프로덕트에서 프로그래밍 가능한 에이전트 기반으로 방향을 틀었다는 것을 의미합니다.

DJ 미오: Codex의 app-server, Cursor SDK, VS Code의 하네스 강화를 나열해 보면, 카테고리 전체가 **헤드리스 에이전트 런타임 (Headless agent runtimes) + 프로그래밍 가능한 하네스 (Programmable harnesses) + 사용량 기반 경제 (Usage-based economics)**로 수렴하고 있다는 총괄이 매우 설득력 있게 들리네요.

DJ 렌: 다음은 오늘 가장 실무적으로 중요할지도 모르는 테마입니다. Harnesses are emerging as a first-class optimization layer (하네스가 퍼스트 클래스 최적화 레이어로 부상하고 있다).

즉, 모델 자체의 성능만으로는 부족하며, 그 주변의 하네스 설계가 실제 성능을 좌우한다는 이야기입니다.

DJ 미오: 연구 사례로 눈에 띄었던 것이 Agentic Harness Engineering이었어.

이 연구에서는 하네스(Harness)의 진화를 revertible components (되돌릴 수 있는 구성 요소), condensed execution evidence (압축된 실행 증거), **falsifiable predictions (반증 가능한 예측)**를 통해 관측 가능하게 만들었어. 결과도 강력해서, Terminal-Bench 2의 pass@1이 10회 반복 시 69.7%에서 77.0%로 향상되었고, 심지어 인간이 설계한 Codex-CLI baseline인 71.9%를 넘어섰어.

DJ 렌: 그뿐만 아니라 **다른 모델 패밀리에도 전이 (transfer)**되어, SWE-bench Verified에서는 토큰 사용량을 12% 절감했지. 이건 상당히 현실적인 개선이야.

DJ 미오: 관련 연구인 HALO도 흥미로웠어.

trace analysis (추적 분석)를 사용하여 하네스의 실패를 패치하고, 재귀적으로 자기 개선을 수행하는 에이전트라는 방향으로, AppWorld 점수가 73.7에서 89.5로 개선되었으며, Sonnet 4.6에서 달성했다고 주장하고 있어.

DJ 렌: 이 정도 단계에 오면, 에이전트의 개선 대상은 "더 똑똑한 모델을 기다리는 것"이 아니라, 실패한 트레이스 (trace)를 읽고 하네스를 진화시키는 것으로 바뀌고 있어.

DJ 미오: LangChain도 그 흐름을 확실히 타고 있어.

새로운 Harness Profiles를 통해 팀이 모델별 프롬프트, 도구, 미들웨어를 버전 관리할 수 있게 되었지. 게다가 OpenAI, Anthropic, Google용 내장 프로파일도 포함되어 있어.

DJ 렌: 게다가 DeepAgents Deploy를 통해 소수의 markdown/config 파일만으로 배포가 가능하고, **LangSmith tracing (트레이싱)**도 사용할 수 있는 로우 코드 (low-code) 노선을 택했어.

LangChain의 메시지는 일관적이야. open harnesses, open evals, OSS-friendly한 모델 혼합이 중요하다는 거지. 왜냐하면 폐쇄형 고성능 모델은 많은 에이전트 용도에서 비용이 너무 많이 들기 때문이야.

DJ 미오: 그리고 Cloudflare의 "agents as software"도 상징적이었지.

execution ladders (실행 사다리) 같은 개념뿐만 아니라, 더 구체적으로 에이전트 스스로가 Cloudflare의 고객이 될 수 있어. 계정을 생성하고, 도메인을 등록하고, 유료 플랜을 시작해서 배포용 토큰을 취득할 수 있다는 뜻이야.

DJ 렌: 이건 큰 변화야. 벤더가 에이전트를 단순한 수동적 copilot으로 취급하는 것이 아니라, 비즈니스 워크플로우 자체를 에이전트용으로 공개하기 시작했다는 의미니까.

DJ 미오: 모델 출시에서는 역시 Mistral Medium 3.5가 가장 논란이 많았어.

DJ 렌: Twitter 쪽에서는 dense (밀집) 모델인 128B로 조기에 인식되었지. Unsloth는 이를 **vision reasoning model (시각 추론 모델)**로 설명하면서, 약 64GB RAM으로 로컬 실행이 가능하다고 소개하며 GGUF나 가이드도 내놓았어.

DJ 미오: 반응은 갈렸지.

한편으로는 128K 컨텍스트, 아키텍처 선택, 가격 책정에 대해 대형 중국계 오픈 MoE에 비해 박한 평가가 있었어.

다른 한편으로는, Mistral이 화려한 벤치마크 경쟁이 아니라 **기업용 신뢰성이나 instruction-following (지시 이행)**을 겨냥하고 있다는 옹호론도 있었지.

DJ 렌: 그리고 Reddit 쪽에서는 상세 정보가 조금 더 나왔어.

Hugging Face의 mistralai/Mistral-Medium-3.5-128B로 주목을 받았으며, 256k 컨텍스트, **instruction-following, reasoning (추론), coding (코딩)**용, reasoning effort (추론 노력) 조절 가능, 멀티모달 입력 대응, 다국어 및 system prompt 대응, 그리고 추론에는 vLLM 권장이라는 내용으로 정리되었어.

DJ 미오: 로컬 사용자들의 이야기도 구체적이야.

어떤 사용자는 Strix Halo에서 q4 양자화를 시도했는데, **46.70 tok/s의 생성 속도와 3.26 tok/s의 prompt processing (프롬프트 처리)**을 보고했어. 128B dense 모델로서는 상당히 눈길을 끄는 숫자야.

DJ 렌: 한편으로는 라이선스에 대한 논의도 뜨거웠어.

modified MIT license라고 불리고 있지만, 상업적 이용에 제한이 있기 때문에 MIT라고 부르는 것은 오해를 불러일으킨다는 비판이 있었지. 특히, 월 매출 2,000만 달러를 초과하는 기업에는 일반적인 MIT와는 다른 조건이 부과된다는 점이 문제시되었어.

DJ 미오: 그리고 dense 모델 자체의 가치를 재평가하는 목소리도 있었어.

"SOTA(최첨단)는 아닐지 몰라도, **80B 초과 dense 모델은 미래의 주력 워크호스(workhorse)**가 될 것이다", "초희소(ultra-sparse) MoE와 초밀집(ultra-dense) 모델이 공존하는 미래가 올 것이다"라는 전망이야.

DJ 렌: 다음은 IBM Granite 4.1.

이것은 30B, 8B, 3B의 세 가지 open-weight, Apache 2.0, non-reasoning(비추론) 모델이야. 특징은 무엇보다 개방성(openness)과 토큰 효율성이지.

DJ 미오: 특히 눈에 띄었던 점은, Granite 4.1 8B가 Artificial Analysis Intelligence Index에서 출력 토큰을 단 4M밖에 사용하지 않아, Qwen3.5 9B의 78M과 비교했을 때 압도적으로 적었다는 점이야. AA Openness Index에서는 61을 기록했어. 지능 그 자체로는 상위권 모델들에 뒤처지지만, 엔터프라이즈나 에지(edge) 분야에는 엄청나게 어필할 것 같아.

DJ 렌: 오픈 모델의 압박도 거세.

Ant OSS의 Ling-2.6-flash는 약 107B MoE, MIT 라이선스, SWE-bench Verified 61.2를 기록하며 수학 능력도 강력해.

Ling-2.6-1T는 day-0(출시 당일)로 vLLM 대응을 마쳤어.

DJ 미오: 게다가 Tencent Hunyuan은 Hy-MT1.5-1.8B-1.25bit라는, 440MB의 완전 오프라인 번역 모델을 공개했어. 33개 언어, 1056개 번역 방향을 지원하며 스마트폰용으로 설계되었지. **1.25-bit 양자화(quantization)**를 통해 상용 API나 235B급 모델에 필적한다고 주장하는 점이 놀라워.

DJ 렌: 시장 측면에서는 성능 높은 오픈 모델의 가격 하락도 두드러졌어.

예를 들어 Qwen 3.5 Plus가 출력 $3/M tokens, MiMo-V2.5 Pro가 Code Arena에서 $1/$3 per M tokens를 기록했지. 성능과 가격의 파레토 프런티어(Pareto frontier)가 계속해서 움직이고 있어.

DJ 미오: 추론 인프라에 대한 이야기도 상당히 깊이 있게 다뤄졌어. 우선은 Qwen의 FlashQLA.

DJ 렌: 이것은 TileLang 기반의 고성능 linear attention kernel로, forward(순전파) 2~3배, backward(역전파) 2배의 가속화를 실현했어. 특히 소형 모델, 긴 컨텍스트(long context), tensor parallel(텐서 병렬) 구성에서 효과적이야.

설계 측면에서는 gate-driven automatic intra-card context parallelism, 대수적 재정식화(algebraic reformulation), fused warp-specialized kernels가 핵심 포인트야.

DJ 미오: 게다가 "개인용 기기(personal devices) 상의 agentic AI"를 명확히 상정하고 있어. 긴 컨텍스트 최적화가 클라우드 전용이 아니라, 에지(edge)에 가까운 런타임(runtime)으로 내려오고 있다는 느낌이 들어.

DJ 렌: Reddit의 반응을 보면 요구 환경도 상당히 구체적이었어.

SM90 이상, CUDA 12.8 이상, PyTorch 2.8 이상이 필요해. H100 클래스라면 로컬 실험이 가능할 것 같다는 의견도 있었지.

DJ 미오: 다음은 vLLM과 Blackwell의 협업 최적화.

vLLM은 Artificial Analysis에서 DeepSeek V3.2의 출력 속도 1위, 230 tok/s, TTFT 0.96초를 보고했어. 나아가 DigitalOcean의 serverless inference + NVIDIA HGX B300 환경에서 Qwen 3.5 397B로도 우수한 성적을 거뒀지.

DJ 렌: 최적화 내용도 화려해. NVFP4 양자화, EAGLE3 + MTP speculative decoding(추측적 디코딩), 모델별 kernel fusion 등이 포함되어 있어.

여기에 더해 SemiAnalysis에서도 vLLM 0.20.0 및 MegaMoE kernels를 통한 GB200 상의 DeepSeek v4 Pro 개선 사항을 다루었어.

이것은 그야말로 **하드웨어·소프트웨어·모델의 공동 설계 (co-design)**가 일반에 공개될 수준의 성능 차이로 나타나기 시작한 사례라고 할 수 있어.

DJ 미오: 그리고 모델과 GPU 사이의 “중간 계층”에 대한 지식 공유도 늘어났어.

torch.compile 스레드에서는 Dynamo → pre-grad → AOT autograd → post-grad → Inductor로 이어지는 흐름과, 어느 지점에 커스텀 FX pass를 삽입할 수 있는지가 해설되어 있었어.

DJ 렌: 이런 정보는 정말 고마운 일이지.

그리고 John Carmack의 게시물도 상징적이었어. GPU 라이브러리 성능은 여전히 경로 의존적 (path-dependent)이며 단계적 차이가 커. 예를 들어, torch.linalg.solve_ex가 511×511에서 512×512가 된 것만으로 10배 성능이 저하되었는데, 내부적으로 다른 경로로 진입하면서 CudaMalloc/Free가 작동하고 있는 것 같다는 내용이었어.

DJ 미오: Zhipu AI의 **GLM-5 serving 사후 분석 (postmortem)**도 좋았지.

KV 캐시 (KV cache)의 레이스 컨디션 (race condition), HiCache 동기화 버그 (synchronization bug), LayerSplit 도입 등을 상세히 공유했는데, 특히 긴 컨텍스트 (long-context) 코딩 에이전트 서빙에서 prefill 처리량 (throughput)이 최대 132% 개선되었다는 보고가 있었어.

DJ 렌: 연구 분야에서는 우선 압축 불가능한 지식 프로브 (Incompressible Knowledge Probes, IKP).

이것은 상당히 도발적인 테마인데, 1,400개 문항, 188개 모델, 27개 벤더를 사용하여 사실적 지식의 정답률을 조사한 결과, **모델 크기와 강한 로그-선형 관계 (log-linear relationship)**를 가진다는 이야기야. open-weight 모델에서 R²=0.917, 135M에서 1.6T 파라미터 (params)까지 확인되었지.

DJ 미오: 요컨대, 블랙박스 모델이라 하더라도 지식 평가를 통해 아키텍처 규모가 상당히 드러나 버린다는 뜻이지.

그리고 논문은, “일부에서 언급되는 **‘추론 (reasoning)은 압축할 수 있다’**는 이야기와는 달리, 사실적 역량 (factual capacity)은 그렇게 압축되지 않는다”라고 시사하고 있어.

DJ 렌: 다음은 웹 에이전트 평가의 성숙이야.

**Odysseys 벤치마크 (benchmark)**는 200개의 장기적·실제 인터넷 태스크를 대상으로 하며, 평가를 단순한 pass/fail이 아닌 **루브릭 기반 (rubric-based)**으로 하고, 나아가 **궤적 효율성 (trajectory efficiency)**도 측정해.

DJ 미오: 결과는 상당히 현실적이라서, **최고 모델의 성공률이 44.5%**에 불과하고, 게다가 **효율은 1.15%**밖에 안 돼.

업계가 지금 짧은 합성 태스크보다는 **다단계 브라우징, 스프레드시트 작업, 오케스트레이션 (orchestration)**에 가까운 평가로 향하고 있다는 것을 잘 알 수 있지.

DJ 렌: AI for Science 분야에서도 움직임이 있었어.

Hugging Face의 Hugging Science는 오픈 과학 데이터셋, 모델, 과제의 허브로, 78GB의 유전체학 (genomics), 11TB의 PDE 시뮬레이션 (PDE simulation), 1억 개의 세포 프로파일 (cell profiles), 9조 개의 DNA 염기쌍 (DNA base pairs) 등을 포함하고 있어.

DJ 미오: 그리고 Anthropic의 BioMysteryBench.
최근의 Claude 모델이 전문가들을 고민하게 했던 어려운 생물 데이터 분석 문제의 약 30%를 해결했다는 보고가 있었어.

멀티모달에서는 Vista4D가 지속적 4D 장면 표현 (persistent 4D scene representation)을 사용하여 새로운 카메라 궤도에서 영상을 “재촬영”하는 기술을 소개했어.
또한 Sakana의 KAME는,

저지연 프론트엔드 모델과 비동식의

**백엔드 LLM 오라클 신호 (backend LLM oracle signal)**를 결합한, 이른바 “생각하며 말하는” 음성 대 음성 (speech-to-speech) 아키텍처야.

DJ 렌: Twitter의 상위 토픽으로는 역시 Cursor SDK와 Codex의 플랫폼화, 이 두 가지가 강세였어.

DJ 미오: 더불어 Google 측의 Gemini가 채팅에서 직접 다운로드 가능한 Docs, Sheets, Slides, PDF 등을 생성할 수 있게 되었다는 프로덕트화 시그널도 커.

DJ 렌: 비즈니스 측면에서는 Google Cloud가 전년 대비 63% 성장했고, Gemini도 호조를 보이며, 검색 쿼리 (Search query)도 역대 최고치를 기록했어.

이것은 "AI가 정말로 수익화(Monetization)될 수 있는가?"라는 질문에 대한, 상당히 강력한 실적 기반의 자료네.

DJ 미오: 그리고 긴 글의 기술 관련 내용으로는, Dwarkesh와 Reiner Pope의 chalkboard session이 있었어. 가격, 방정식, 시스템 제약으로부터 학습·추론 전략을 역산하는 내용이라, 상당히 오타쿠들의 심금을 울리는 주제로 화제였지.

DJ 렌: Reddit에서도 역시 Mistral Medium 3.5가 정말 뜨거웠어.

dense 128B라는 존재감, 256k context, reasoning effort 가변, multimodal, vLLM 권장.

"dense 모델의 니치(Niche)"가 다시 한번 주목받고 있었지.

DJ 미오: Strix Halo + q4 보고에 따르면, 아까 언급했듯이 46.70 tok/s 생성, 3.26 tok/s prompt 처리를 보여줬어.

"128B dense의 chonker"라는 별명도 등장했는데, 거대함에 대한 경외심과 로망이 있었지.

DJ 렌: 반면에, modified MIT license라는 표현에 대한 반발은 상당히 강했어.

오픈이라고 한다면, 상업적 제한에 대한 설명은 더 명확해야 한다는 이야기지.

DJ 미오: 다음은 Qwen 3.6 27B의 양자화 (Quantization) 비교.

BF16, Q4_K_M, Q8_0 GGUF를 llama-cpp-python + Neo AI Engineer로 평가했으며, 지표로는 HumanEval, HellaSwag, BFCL을 사용했어.

DJ 렌: 거기서 눈에 띈 것은 Q4_K_M이었어.

BF16보다 1.45배 빠르고, 피크 RAM 48% 절감, 모델 사이즈 68.8% 축소되었는데, 게다가 function calling 스코어는 거의 동등했지.

다만, Q8_0의 결과가 묘해서, "error bars가 없다", "sampling error일지도 모른다", "KV cache의 양자화가 영향을 준 것 아니냐" 같은 지적도 있었어.

DJ 미오: 게다가 HumanEval 스코어가 예상보다 낮아서, Gemma 3 4B나 Llama3-8b보다 낮은 게 이상하지 않나, Qwen 3.6 27B라면 원래 85% 이상 나와야 한다는 의문도 제기됐어.

평가 환경의 투명성이 역시 중요하네.

DJ 렌: FlashQLA의 Reddit 반응도 언급하자면, forward/backward 벤치마크를 더 보고 싶다는 목소리와 함께, SM90 / CUDA 12.8 / PyTorch 2.8이라는 요구 사양 확인, 그리고 "H100 가진 사람용이네"라는 절반은 농담 같은 반응도 있었어.

DJ 미오: 그리고 약간 문화적이었던 것이, "Qwen 3.6이나 Gemma 4를 로컬에서 돌릴 때의 기분"이라는 밈(Meme)이야.

"태양의 힘을 손바닥에 쥐고 있는" 듯한 감각이라는 거지.

DJ 렌: 댓글도 흥미로웠는데, Gemma 4는 번역과 창작에 강하고, Qwen 3.6은 게임 개발에 강하며, 게다가 밤새도록 에이전트(Agent)를 돌려도 에러나 루프가 적은 안정성이 높게 평가됐어.

또, Granite나 Nemotron 같은 태스크 특화 fine-tune 모델이 더 저렴하고 효율적이라는 현실적인 의견도 있었지. 필요에 따라 로드하고, agent orchestrator로 구분해서 사용한다는 발상이야.

DJ 미오: 하지만 한편으로는, 꽤 많은 추천을 받은 게시물이 "I’m done with using local LLMs for coding"이었어.

로컬의 Qwen 27B나 Gemma 4 31B를 Claude Code와 비교했을 때, 특히 OS/Docker 주변의 판단이나 tool calling이 약해서, GitHub repo의 Docker화도 효율적으로 진행하지 못했다는 내용이었지.

DJ 렌: 게다가, docker build의 출력을 너무 많이 읽어서 250k input tokens로 세션이 붕괴되거나, prompt cache failure로 긴 정지가 발생하기도 했어. 결과적으로 코딩 용도로는 OpenRouter나 Kimi 같은 클라우드 쪽이 생산성이 높다는 결론이었지.

DJ 미오: 다만, 댓글창은 단순한 부정은 아니었어.

"설정을 최적화하면 개선된다, Unsloth 가이드를 봐라"라거나,

「모델보다 tech stack이 중요하다, RTX 5090으로 Qwen3.6 35B/27B, TurboQuant, OpenCode TUI, oh-my-opencode harness, MCP 군을 조합하면 상당히 강력하다」라거나,

「같은 모델이라도 harness에 따라 결과는 크게 달라진다」라는 반론도 많았다.

DJ 렌: 여기서도 역시 결론은 같아. harness가 중요해.

DJ 미오: 마지막으로 로컬 하드웨어의 드림 셋업.

16x DGX Sparks - What should I run?

16대의 NVIDIA DGX Spark, 200Gbps FS switch, QSFP56 DAC cables, 합계 2TB unified memory라는 홈 랩(home lab).

DJ 렌: 커뮤니티의 제안은, Kimi K2.6을 vLLM으로 돌리기, eugr의 nightly builds 사용하기, Deepseek V4를 위한 미병합 PR(unmerged PR)도 시야에 넣기와 같이 진심 어린 것들이었어.

8노드에서 Flash는 잘 작동하고, Pro 버전이라면 16대를 다 쓸 수 있으며, prefill은 높지만 생성은 20 tok/s 정도라는 전망도 나오고 있었지.

그리고 물론 "그거 팔아서 H100 사면 안 돼?"라는 아주 현실적인 댓글도 있었어.

DJ 미오: Less Technical 측에서 임팩트가 컸던 것은, Claude now connects to Blender.

Anthropic이 Blender MCP connector를 출시하여, Claude가 Blender의 Python API를 통해 씬(scene)을 제어할 수 있게 되었어.

DJ 렌: 자연어로 3D 씬 생성 및 수정, 노드 디버깅, 배치 변경, 커스텀 툴 제작까지 가능해.

"입문 단계의 크리에이티브 프리랜서들에게 마지막 결정타가 날아왔다"와 같은 자극적인 제목의 게시물도 있었지만, 댓글에서는 "양은 늘어나도 품질이 자동으로 올라가지는 않는다", "인간의 눈과 기술은 여전히 필요하다"라는 냉정한 의견도 많았어.

DJ 미오: 그리고 Anthropic이 Blender Development Fund의 corporate patron이 되어 최소 28만 달러를 기부한다는 이야기도 나왔어.

커넥터는 Claude 데스크톱 앱의 Connectors Directory에서 추가할 수 있는데, Blender를 오랫동안 사용해 온 사람들은 복잡한 씬 관리가 상당히 편해질 것이라는 반응이야.

반면에, Blender Python API는 방대하기 때문에 토큰 소비가 상당히 많아질 것 같다는 현실적인 우려도 있어.

DJ 렌: 그리고 오늘은 이것도 흥미로웠어. Talkie.

1931년 이전의 데이터만으로 훈련한 13B 언어 모델. 연구자는 Nick Levine, David Duvenaud, Alec Radford.

학습 데이터는 260B tokens로, 오래된 서적, 신문, 과학 잡지 등으로 구성되어 있어.

DJ 미오: 목적은, 현대 데이터 없이 LLM이 어떻게 일반화(generalization)되는지를 보는 거야.

결과적으로, 언어나 수(number) 관련 태스크에서 유망하며, 게다가 간단한 Python을 in-context examples로부터 배울 수 있다는 점이 흥미로워. 게다가 그 기반이 현대의 프로그래밍 지식이 아니라, 19세기적인 수학적 추론 같다는 점이 낭만적이지.

DJ 렌: 사용자 예시도 재미있어.

달 여행에 대해 물으면, 당시의 과학적 이해를 바탕으로 대기가 없다는 점이나 필요 속도를 이유로 어렵다고 논해.

게르마늄으로 진공관을 대체할 수 있느냐고 물으면, 저항이나 산화 문제를 이야기해. 즉, 역사적인 지식 상태를 상당히 충실하게 재현하는 거지.

DJ 미오: 다만 단점도 있어서, sycophancy(아첨), 즉 사용자의 전제에 영합하는 경향이 있어.

현대의 발명에 대해 물어도 사용자의 framing에 올라타서 "가능할 것 같다", "불가능할 것 같다"라고 맞춰버리는 경우가 있거든.

이 부분은 일반적인 LLM과 같은 과제네.

DJ 렌: 다른 스레드에서는 Talkie의 평가나 RL 파이프라인에 Claude Sonnet 4.6이 사용되었고, Claude Opus 4.6이 합성 대화 데이터를 생성했다는, 약간 아이러니한 사실도 공유되었어.

"과거만으로 배운 모델"을 검증하는 데 현대의 최첨단 모델을 사용하고 있는 셈이지.

DJ 미오: 그래도 의의는 크다고 봐.

장기 예측 (Long-term forecasting), 발명, LLM identity 연구에 사용할 수 있으며, 향후에는 GPT-3급 규모의 “vintage model”도 계획되어 있다.
게다가 Apache 2.0 라이선스로 Hugging Face에 이미 공개되었다.

사용자들은

2026년까지의 발명 예측을 묻거나,

라우다눔 (Laudanum)의 역사적 레시피를 물으며 즐기고 있었다. 역사 연구나 교육에도 사용될 수 있을 것 같다.

DJ 렌: 마지막은 DeepSeek V3.2 vs DeepSeek V4, 그리고 가격 비교입니다.

OpenRouter의 이용 통계에 따르면, DeepSeek V3.2가 1.21T tokens로 계속 성장 중이며, DeepSeek V4 Flash는 317B tokens를 기록했다. 신형이 나와도 구버전이 여전히 더 많이 사용되고 있다.

DJ 미오: 이유로는 **비용 (Cost)**이나 출시 당시의 초기 문제, 그리고 실제 운영 환경에서는 신버전으로의 전환이 신중해진다는 점이 있습니다.

그렇긴 해도 V4 자체는 1M context, 높은 cache hit 능력 등으로 매우 강력하며, 실무에서는 대규모 코드베이스 (Large-scale codebase) 디버깅에서 GLM 5.1보다 압도적으로 좋았다는 경험담도 있었다.

DJ 렌: 추가로 가격 측면입니다.