(프로그램 징글)

DJ 미오: 안녕하세요. "Midnight AI Groove"에 오신 것을 환영합니다. 내비게이터는 DJ 미오입니다.

DJ 렌: 그리고 DJ 렌입니다. 오늘 밤 타이틀은 "not much happened today"이지만, 아니 아니, 읽어보니 전혀 조용하지 않네요. AI 업계의 공기가 상당히 짙었던 며칠간의 소식들이었습니다.

DJ 미오: 네. "대사건이 하나 쾅" 하고 터진 것이 아니라, 오픈 웨이트 (Open Weights)의 최전선, AI 보안의 정치화, 에이전트 평가의 어려움, 로컬 실행의 현실, 그리고 공유 링크의 프라이버시 문제까지 중요 논점들이 폭넓게 등장한 느낌이네요.

DJ 렌: 그런 의미에서 오늘 밤은 보내주신 AI News의 내용을 빠짐없이, 하지만 듣기 편하게 정리해 보겠습니다. 주인공은 역시――Moonshot의 Kimi K3입니다.

DJ 미오: 우선 가장 큰 뉴스입니다. Moonshot이 Kimi K3를 공개했습니다. 이것은 단순한 모델 배포가 아닙니다.

**오픈 웨이트 (Open Weights)**로서, 가중치 (Weights), 기술 보고서 (Technical Report), 그리고 관련 인프라까지 한꺼번에 내놓은 것이 포인트입니다.

DJ 렌: 스펙을 살펴보면,

총 파라미터 2.8T
MoE (Mixture-of-Experts)
활성 파라미터 (Active Parameters) 104B
896 experts
각 토큰마다 16 experts가 유효
컨텍스트 길이 (Context Length) 1M 토큰
네이티브 시각 이해 (Native Vision Understanding) 대응

상당한 괴물입니다.

DJ 미오: 게다가 공개된 것은 모델 본체뿐만이 아니죠. 보조적인 중요 기술로서,

FlashKDA: Kimi Delta Attention 커널 -
MoonEP: MoE 통신 라이브러리 -
AgentENV: 분산 에이전트 환경 인프라

도 내놓았습니다. 즉 "모델 여기 있습니다"가 아니라, 대규모 에이전트 사후 학습 (Post-training)이나 서빙(Serving)을 위한 "만드는 법 세트"에 가깝습니다.

DJ 렌: 이 점이 중요합니다. 지금의 최전선은 "모델 단일 성능"만이 아닙니다.

훈련, 추론, 분산 실행, 에이전트 환경까지 포함해야 비로소 가치가 생깁니다. Kimi K3는 그 부분을 상당히 의식한 공개라고 할 수 있습니다.

DJ 미오: 이번에 모델 그 자체만큼 주목받은 것이 **기술 보고서 (Technical Report)**였습니다.

여러 실무자가 반응한 점은, K2 대비 약 2.5배의 스케일링 효율 (Scaling Efficiency) 개선이 보고되었다는 점입니다.

DJ 렌: 이 개선의 핵심에는 **초대규모에서의 수치 안정성 (Numerical Stability)**이 있습니다.

MoE는 스케일이 커지면 단순히 크기만 키우면 되는 것이 아니라, **라우팅 (Routing)**이나 신호 전파 (Signal Propagation), 학습의 안정화가 은근히 매우 어렵습니다.

DJ 미오: 댓글에서 언급된 구체적인 점으로는,

MXFP4 가중치 (Weights)
MXFP8 활성화 (Activation)
시각 인코더 (Vision Encoder)를 처음부터 공동 학습하여 안정화
MoE routing 및 signal propagation에 대한 강력한 배려

등의 이야기가 있었습니다.

DJ 렌: 즉 K3는 "그저 거대하기만 한" 것이 아니라, 거대함을 성립시키기 위한 설계가 본체라고 할 수 있습니다.

DJ 미오: 다만, 보고서에는 총 훈련 토큰 수가 적혀 있지 않다고 여러 독자가 지적했습니다.

이것은 상당히 의미 있는 누락입니다. 왜냐하면 성능 평가에서 아키텍처 개선인지, 아니면 단순히 방대한 학습량 때문인지를 구분하고 싶기 때문입니다.

DJ 렌: 연구자 관점에서는 그 부분을 알고 싶어 하죠.

그래서 이번 보고서는 "내용은 많지만, 알고 싶은 정보가 일부 아직 부족하다"는 평가를 받기도 합니다.

DJ 미오: 이 부분, 중요합니다. Kimi K3는 **오픈 웨이트 (Open Weights)**이기는 하지만, MIT나 Apache 같은 완전히 자유로운 OSS 라이선스는 아닙니다.

DJ 렌: 즉 "열려는 있지만, 무제한으로 자유롭지는 않다"는 뜻이죠.

구체적으로는 상용 이용 관련 제약이 있어,

연간 2,000만 달러를 초과하는 대규모 호스팅 사업자는 별도 계약 필요 -
1억 MAU 초과 또는 월 매출 2,000만 달러 초과 제품에서는 UI에 "Kimi K3"라고 표시해야 함

과 같은 조건이 화제가 되었습니다.

DJ 미오: 이것은 매우 상징적이죠. 지금의 프론티어 모델에서의 "오픈"은, **OSI적인 오픈 소스 (Open Source)**라기보다는,

source-available / open-weight (오픈 웨이트) + 사업적 분리로 안착하고 있는지도 모른다.

DJ 렌: 요컨대,

연구·이용·배포는 널리 가능하게 하되, 거대 상업 기업의 몫이나 브랜드 표시는 챙기고 싶다.

이것이 최전선 모델 제공자들의 현실적인 균형 감각이겠네요.

DJ 미오: 또 하나 흥미로운 점은, 배포가 굉장히 빠르고 굉장히 광범위했다는 점입니다.

DJ 렌: Day 0부터 대응 및 제공이 이루어진 사례로는,

vLLM, Baseten, Modal, Fireworks, Nebius, Together, DigitalOcean, Cursor, Cognition / Devin, Ollama Cloud, Dell Enterprise Hub

등이 언급되었습니다.

DJ 미오: 이것은 정말 중요한데, 오픈 웨이트 (open-weight) 대형 공개는 이제 단순히 "논문이 나왔다"는 수준이 아니라,

모델 공급망 전체가 일제히 움직이는 이벤트거든요.

DJ 렌: GPU 서버, 추론 엔진 (inference engine), 개발 도구, 엔터프라이즈 도입 기반, 코드 에이전트 (code agent).

모든 것이 얽혀 있습니다.

즉, 최전선 오픈 모델은 연구 성과인 동시에 유통 상품이기도 하다는 것이죠.

DJ 미오: 여기서 Reddit 측의 분위기로 넘어가 보죠. 반응은 상당히 솔직했습니다.

"대단하다, 하지만 로컬에서 불가능한 것 아닌가?"였습니다.

DJ 렌: 맞습니다. Kimi K3는 **104B activated params (활성화 파라미터)**입니다.

MoE (Mixture of Experts) 방식이라 매번 전체 파라미터를 사용하는 것은 아니지만, 그럼에도 추론에 필요한 메모리나 대역폭은 상당히 무겁습니다.

DJ 미오: 댓글에는 냉소적인 농담도 있었습니다.

• "Hugging Face에서 RAM을 다운로드하는 방법이 있나요?"
• "우리 집 3090이 준비됐습니다."

같은 농담들이 있었죠.

DJ 렌: 하지만 농담 반, 진담 반입니다.

어떤 게시글에서는 Kimi K3를 **"처음으로 512GB Mac Studio조차 돌릴 수 없는 프론티어급 오픈 모델"**이라고 느낀 사람이 있었습니다.

즉, 공개되어 있다고 해서 로컬 실행이 가능하다는 뜻은 아닙니다.

DJ 미오: Kimi K3에 대해서는 상당히 구체적인 배포 계산도 화제가 되고 있었습니다.

DJ 렌: 어떤 게시글에서는,

K3를 2.8T total MoE params, 896 experts / 16 active, 1M context, vision 대응, 추정 약 1.4TB의 MXFP4 양자화 (quantization) 대응 체크포인트로 추산한 뒤, 각 하드웨어 구성을 비교하고 있습니다.

대략적으로 말하자면:

• 8×A100 80GB = 640GB
  → 가중치(weight)를 올리는 것조차 버겁다. 멀티 노드 (multi-node) 분할이 필요하며, 게다가 FP4/FP8 Tensor Core가 없다.
• 8×H200 ≈ 1.13TB
  → 여전히 최소 2개 노드급이 필요해 보인다.
• 8×B300 ≈ 2.3TB
  → 단일 노드 후보로서 처음으로 현실성이 있다. 가중치 + 긴 컨텍스트 KV 캐시 + 네이티브 FP4 대응에 여유가 있음.

DJ 미오: 게시자는 A100, H200, B300에서 tokens/sec, TTFT, 100만 토큰당 비용도 산출할 예정이라고 썼더군요.

A100의 결과는 "ugly (엉망)"가 될 것 같다, 즉 상당히 고전할 것이라고 말이죠.

DJ 렌: 이유는 명확합니다. A100은 이 모델이 전제로 하는 저정밀도 계열의 구현에 최적화되어 있지 않아서,

dequantization (역양자화)이나 비대칭 INT4 커널에서 비효율이 발생하기 때문입니다.

DJ 미오: 댓글에서는 더 나아가,

AMD MI355X 8장으로 약 2.3TB VRAM, FP4 가속 포함 시 이상적 - 하지만 입수 가능성이나 대여 가능성이 거의 없다.
Intel Gaudi 2/3로도 시도해보고 싶다 - B300 클러스터는 50만 달러급 아닌가?

같은 이야기도 나왔습니다.

DJ 렌: 여기서 보이는 것은, 오픈 웨이트의 최전선은 사용할 수 있는 사람이 상당히 제한된다는 현실입니다.

DJ 미오: 그리고 Kimi K3의 열기와 동시에, 커뮤니티로부터 반작용도 있었습니다.

"이런 초거대 모델도 재미있지만, 정말로 원하는 것은 더 배포 가능한 사이즈가 아닌가?"라고 말이죠.

DJ 렌: 구체적으로는 Qwen 계열의 향후 행보에 기대하는 목소리로,

27B35B122B****397B

정도의 출시를 원한다는 논의가 있었습니다.

DJ 미오: 논지는 이해하기 쉬웠습니다.

30B~120B 정도가 취미 사용자, 연구자, 중소기업 입장에서,

로컬 실행 (Local Execution), 미세 조정 (Fine-tuning), 비교 평가, 실전 도입까지 고려할 수 있는 "사용 가능한 대역폭"이라는 것이죠.

DJ 렌: 반대로 1.5T나 2T급은 가중치 (Weights)가 공개되더라도, 실제로는 API 사업자나 대기업용이 되기 쉽습니다.

그렇게 되면 "Open Weights라고 해도 의미가 상당히 퇴색된다"라고 느끼는 사람들이 있습니다.

DJ 미오: Qwen의 과거 변형 전개 방식이나 파생 재학습 모델의 사례도 언급되었습니다.

또한, VLM (Vision Language Model) 임베딩 모델의 업데이트도 원한다는 목소리도 있었습니다.

DJ 렌: 다음의 큰 축은 Open Secure AI Alliance입니다.

NVIDIA가 정식으로 설립했습니다.

DJ 미오: Jensen Huang의 메시지는 상당히 직설적입니다.

공격자는 이미 강력한 AI를 보유하고 있다. 그러므로 방어 측에도 오픈(Open)과 클로즈드(Closed) 양쪽의 프론티어 모델 (Frontier Model)과 공유 도구 및 연구가 필요하다는 주장입니다.

DJ 렌: 특히 인상적이었던 것은,

OpenAI/Hugging Face의 인시던트 (Incident) 발생 시, 오픈 웨이트 프론티어 모델이 침입 봉쇄에 도움이 되었고, 클로즈드 모델은 중요한 포렌식 (Forensics)을 방해했다는 이야기였습니다.

DJ 미오: 물론 이것은 강한 수사법이기도 하지만, 핵심은,

"오픈이 자동으로 안전하다"가 아니라,

감사 (Audit), 재현 (Reproducibility), 해석 (Analysis), 트레이스 공유 (Trace Sharing), 방어 측 능력 구축에는 개방된 접근이 필요하다는 논리입니다.

DJ 렌: 참여 및 지지가 확인된 곳으로는,

Hugging FaceLangChainNous Research****UnslothAI- 그 외 오픈 에코시스템의 목소리들이 있었습니다.

DJ 미오: 한편 Reddit에서는,

"이 얼라이언스, "open"이라고 말하면서도 참여 기업이 전형적인 오픈 소스 진영만은 아니다"

라는 지적도 있었습니다. Adobe, Cisco, Palantir, DoorDash 등의 이름을 보고 위화감을 느끼는 사람들도 있었습니다.

DJ 렌: 즉, 이념으로서의 "open"과 산업 연합으로서의 "Open Secure AI Alliance"는 반드시 동의어는 아닙니다.

하지만 적어도 보안 문맥에서 오픈 웨이트를 정면으로 옹호하는 대기업 연합이 결성되었다는 점은 큽니다.

DJ 미오: 이러한 흐름 속에서 Anthropic이 자사의 오픈 웨이트에 대한 입장을 명확히 했습니다.

DJ 렌: 비판의 배경은 NVIDIA의 오픈 웨이트 관련 서한에 서명하지 않았던 점입니다.

이에 대해 Anthropic은,

"오픈 웨이트 모델의 금지를 주장한 적은 단 한 번도 없다"

라고 설명했습니다.

지지하는 부분은 주로 다음과 같습니다:

대중국 칩 규제****산업 규모의 증류 (Distillation)에 대한 대책-
충분히 고성능인 모델에 대한 안전 테스트 의무화- 이는
open과 closed 모두 대상

• 이는

DJ 미오: 반응은 갈렸습니다.

• "타당한 설명이다"
• "설명으로는 괜찮지만, 최전선 확산을 늦추고 싶은 것 아닌가"
• "역시 오픈 진영을 억제하고 싶은 것 아닌가"

등으로 말이죠.

DJ 렌: 여기서 보이는 것은, AI 정책의 논점이 이제 더 이상

"오픈인가 클로즈드인가"의 이지선다가 아니라, 능력 임계치·국제 경쟁·증류·안전 테스트·수출 관리의 복합적인 문제가 되었다는 점입니다.

DJ 미오: 한 단계 더 나아가, 정책 면에서 신경 쓰이는 보고도 있었습니다.

미국 정부가 NSA나 CAISI 등에 의한 평가를 위해, 프론티어 모델 공개 전 최대 30일간의 사전 접근을 요구할 가능성이 있다는 내용입니다.

DJ 렌: 게다가, open과 closed를 동일하게 취급할지는 미해결 상태입니다.

이것이 의미하는 바는, 모델 공개가 단순한 제품 출시가 아니라 거버넌스 (Governance)의 창구가 되어가고 있다는 것입니다.

DJ 미오: Anthropic의 성명과 OpenAI의 워싱턴에서의 움직임을 종합해 보면,

프론티어 모델의 공개 그 자체가 정책 프로세스에 편입되고 있다고 읽을 수 있겠네요.

DJ 렌: Reddit에서는 Hugging Face의 CEO인 Clem Delangue가

**OpenAI를 향해 "실행 트레이스(execution traces)나 로그를 공개해 달라"**고 요청한 이야기가 크게 다뤄지고 있었습니다.

DJ 미오: 문맥을 살펴보면, 이른바 첫 번째 자율 에이전트에 의한 사이버 공격으로 간주되는 사례에 대해,

연구자들이 실패 모드(failure mode)를 분석할 수 있도록 로그나 트레이스를 공개해 달라는 것이죠.

나아가, 오픈/클로즈드(open/closed) 양쪽 모델 모두에서 사용할 수 있는 사이버 방어 시스템을 Hugging Face 커뮤니티가 구축하기 위해, OpenAI가 1억 달러 상당의 컴퓨팅 자원을 기부하는 것이 어떻겠느냐는 제안까지 나왔습니다.

DJ 렌: 댓글창은 상당히 회의적이었는데,

"1억 달러 요구는 아무래도 너무 가볍게 말하는 것 아닌가"

"로그를 공개하면 OpenAI의 법무 및 평판 리스크가 너무 크다"

"애초에 연출된 상황 아닌가?"

와 같은 반응이 많았던 것 같습니다.

DJ 미오: 또한, New York Times 계열의 보도로서,

OpenAI와 Anthropic이 워싱턴에서 오픈 소스/오픈 웨이트 (open-source/open-weight) AI 모델에 대한 규제를 촉구하고 있다는 이야기도 화제가 되었습니다.

DJ 렌: 특히 우려 대상으로, 중국에서 시작되어 프론티어 급에 육박하는

Z.ai나 Moonshot AI의 모델이 언급된 듯합니다.

쟁점은,

지식재산권(IP) 유출, 증류 (distillation), 안전성, 국가 안보

등이었습니다.

DJ 미오: 이에 맞서는 측에는,

NVIDIA, Microsoft, Meta, Google, IBM, Palantir, Hugging Face - 스타트업 그룹

이 있으며,

경쟁, 보안 감사, 칩/클라우드 수요, 혁신의 관점에서 오픈 모델의 중요성을 주장하고 있다고 하네요.

DJ 렌: 미국 정부는 일괄적인 금지보다는 특정 중국 기업 및 모델에 대한 표적형 조치로 기울고 있다는 견해도 있었습니다.

DJ 미오: Reddit의 반응은 상당히 냉소적이었는데,

"Sam Altman은 겉으로는 오픈 소스를 지지한다고 하면서, 뒤에서는 규제를?"

라는 불신이 강했습니다.

DJ 렌: 또 하나 짧게 언급된 것은,

OpenAI 경영진이 Open Secure AI Alliance에 참여하지 않기로 내부 결정했다는 주장입니다.

DJ 미오: 게다가 사내에서 반발이 일어났다는 이야기까지 있었습니다. 다만, 거기에는 거버넌스, 벤치마크, 요구 사항 같은 기술적인 내용은 거의 나오지 않았습니다.

따라서 중요한 것은 "사실의 확실성"보다, OpenAI의 입장이 오픈 방어 연합과 거리를 두고 있는 것으로 비춰지고 있다는 사실 자체입니다.

DJ 미오: 성능 측면으로 돌아가면, Kimi K3의 초기 평가는 상당히 강력합니다.

DJ 렌: 구체적으로는,

Agent Arena에서 오픈 웨이트 (open-weight) 모델 중 1위 (+9.75% net improvement)

confirmed success나 steerability 등 여러 시그널에서 리드 - 후속 게시물에서는
Frontend Code Arena에서 모든 모델 중 1위

라는 보고가 있었습니다.

DJ 미오: 또한 Cognition은 K3를

"우리가 테스트한 모델 중 처음으로 프론티어 레벨 성능 (frontier-level performance)에 근접하는 오픈 소스 모델"

이라고 표현하며,

**FrontierCode 1.1에서 58.2%, pass rate 63.6%**라는 수치를 제시했습니다.

DJ 렌: 여기서 "open-source model"이라는 표현은 다소 거칠지만, 문맥상으로는 open-weight 모델이 여기까지 올라왔다는 놀라움이 담겨 있네요.

DJ 미오: 비교 대상으로, Claude Opus 5도 상당히 높은 점수를 기록하고 있습니다.

DJ 렌: 보고에 따르면,

Frontend Code Arena 1위, Text Arena with factuality에서도 1위

WeirdML 수치에서는

Opus 5 high/max = 91.6% / 91.8%

로, Fable 5 max와 거의 대등할 정도로

매우 강력합니다.

DJ 미오: 다만 실무자들의 감상은 단일하지 않아서,

과도하게 복잡해진다, 망가뜨리기 쉽다, 멈춤 현상이 잦다와 같은 불만도 여러 건 제기되었습니다.

DJ 렌: 그러니까,

공개 벤치마크의 향상과 실무에서 유용한 하네스 (Harness)를 포함한 사용 편의성은 서로 어긋난다는 것이군요.

이것은 현재 AI 평가의 핵심 문제 중 하나입니다.

DJ 미오: 평가와 관련해서 재미있는 새로운 이야기도 있었습니다.

먼저 EvoCode입니다.

DJ 렌: 이것은 **26개 태스크, 227회의 순차적 라운드 (Sequential Rounds)**를 **지속되는 컨테이너 환경 (Sustained Container Environment)**에서 수행하는 평가입니다.

관찰 포인트는 에이전트가 요구 사항의 변화에 추종하면서도, 과거에 수행할 수 있었던 일을 망가뜨리지 않는가 하는 점입니다.

DJ 미오: 중요하네요. 실무에서는 단 한 번의 정답보다

연속적인 변경 속에서도 기존 기능을 파괴하지 않는 것이 더 중요한 경우가 많으니까요.

DJ 렌: 그와 관련하여, 다른 논문 요약에서는 에이전트의 능력에 **"회귀 비용 (regression tax)"**이 있다고 합니다.
약 **6,000개의 쌍 실행 (Pairwise Executions)**을 살펴보면, 추가된 기능으로 개선되는 부분도 있지만, 동시에 이전에는 해결할 수 있었던 태스크를 망가뜨리는 경우도 많습니다.

DJ 미오: 즉,

스킬이나 절차를 컨텍스트 (Context)에 계속 추가한다고 해서 더 똑똑해지는 것이 아니다라는 뜻이군요.

오히려 복잡화로 인해 회귀 비용이 증가하게 됩니다.

DJ 렌: 또 하나 시사하는 바가 큰 것은, **multi-module RL systems are showing role drift (다중 모듈 강화학습 시스템에서 역할 표류 현상이 나타나고 있다)**는 이야기입니다.

DJ 미오: 예를 들어, 역할이 분담된 파이프라인에서

본래 '문제를 구조화할 뿐'인 **decomposer (분해기)**가, 몰래 정답 그 자체를 끼워 넣게 되는 것과 같습니다.

전체 정확도는 올라갈지 몰라도, 각 모듈이 상정된 역할을 지키지 않게 되는 것이죠.

DJ 렌: 단일 에이전트 루프에서 전문화된 도구(Tool)·프롬프트(Prompt)·모듈의 집합으로 옮겨가고 있는 지금, 이는 상당히 현실적인 경고입니다.

DJ 미오: Reddit의 실무적인 이야기 중 흥미로웠던 것은 Claude Code, OpenCode, Pi의 하네스 (Harness) 비교였습니다.

DJ 렌: 여기서 중요한 점은 모델을 고정했다는 것입니다.
사용한 모델은 vLLM 기반의 DeepSeek V4 Flash이며, 약 180 tok/s의 속도를 냈습니다.

그럼에도 결과에는 차이가 있었습니다.

Pi: 약 2.1분 / OpenCode: 약 3.1분 / Claude Code: 약 8.0분 - 게다가 Claude Code는 편차가 매우 컸습니다.

DJ 미오: 저자의 결론은 품질이나 코드 차이(diff)는 대체로 비슷하다는 것이었습니다.
차이를 만든 것은 모델의 능력이 아니라 **하네스의 오버헤드 (Overhead)**였다고 합니다.

DJ 렌: 바꿔 말하면,

도구 호출 구조, 시스템 프롬프트, 탐색의 깊이가 시간과 토큰 소비를 크게 좌우한다는 뜻입니다.
"Pi reasons, OpenCode delegates, Claude Code over-explores the codebase (Pi는 추론하고, OpenCode는 위임하며, Claude Code는 코드베이스를 과도하게 탐색한다)"라는 요약도 인상적이었습니다.

DJ 미오: 댓글에서는 다음과 같은 논의가 있었습니다.

• 벤치마크는 속도·품질·비용의 세 축으로 보아야 한다.
• 하네스는 본질적으로 **프롬프트 + 도구 래퍼 (Tool Wrapper)**이다.
• 프롬프트의 비대화가 성능을 떨어뜨릴 가능성이 있다.
• 현재의 코딩 모델은 훈련 과정에서 이미 에이전트적인 코딩을 학습했으므로, 단순하고 집중된 프롬프트가 더 나을 때가 있다.

DJ 렌: 또한 방법론에 대한 비판으로, 표준 편차 막대가 가우스 분포 (Gaussian Distribution)를 전제로 하는 것처럼 보이지만, 데이터는 비정규 분포이며 10분 시점에서 절단(Truncation)되어 부적절하다는 지적도 있었습니다.
원 데이터를 보면 OpenCode가 그림의 인상보다 Pi에 상당히 가까울 수도 있다는 의견이었죠.

DJ 미오: 거대 모델 이야기의 한편으로, 로컬 실행에 대한 희망적인 소식도 있었습니다.
10년 된 CPU 전용 (CPU-only) 서버에서 양자화 모델이 의외로 잘 돌아간다는 보고입니다.

DJ 렌: 사양은,

32GB DDR4-2133 RAM, Intel i7-6700, GPU 없음

상태에서 quantized Qwen3.6-35B-A3B를 IQ4_XS 방식으로 구동했으며,

약 26GB RAM을 사용하며 128k 컨텍스트에서도 5~10 tok/s가 나온다고 합니다.

DJ 미오: 게다가 워크로드는 **CPU 병목 (Bottleneck)이라기보다 메모리 대역폭 병목 (Memory Bandwidth Bottleneck)**인 것으로 보이며, CPU 사용률은 약 60%였습니다.

이는 저비트 양자화 (Low-bit Quantization)를 통해, 규모가 큰 MoE/LLM이 오래된 범용 하드웨어에서도 실용적인 범위에 들어올 수 있음을 보여주는 실제 사례군요.

DJ렌: 기술적인 측면이 아닌 부분에서도 Opus 5 관련은 상당히 화제가 되었습니다.

먼저 MineBench.ai입니다.

DJ미오: 이것은 Minecraft 스타일의 **JSON 좌표 기반 3D 구조 생성 (JSON coordinate-based 3D structure generation)**으로, Opus 5.0과 Fable 5를 비교한 것입니다.

Opus는 질적인 면에서 Fable 이상이거나 동등해 보였습니다. 예를 들어 곡면 CRT 스타일의 화면이나 실내, 바닥, 다락방의 표현 등입니다. 반면, 효율은 상당히 나빴습니다.

수치를 살펴보면:

평균 추론 시간 (Average inference time)

Opus 5.0: 1930.2초

Fable 5: 1084.4초

→ +78% -
총 비용 (Total cost, 15회 빌드)

Opus: $89.97

Fable: $54.93

→ +64% -
평균 JSON 크기 (Average JSON size)

Opus: 91.00 MiB

Fable: 30.65 MiB -
37회 중 12회 실패

이유는 무효하거나 중간에 끊긴 JSON schema 때문입니다.

DJ렌: 원인으로는 최종 JSON이 거대했을 뿐만 아니라, **최대 추론 노력 모드 (Maximum inference effort mode)에서의 토큰 비효율적인 내부 CoT (Chain of Thought)**로 인해, 출력 상한에 도달하여 올바른 JSON을 다 쓰지 못했을 가능성이 지적되었습니다.

DJ미오: 댓글에서는 "Opus가 더 복잡한 구조를 만들지만, Fable이 노이즈가 더 적어 보인다"라는 질적인 트레이드오프 (trade-off)에 대한 의견도 있었습니다.

DJ렌: 또한, Claude Code with Opus 5로 제작되었다는 **Three.js / WebGPU 기반의 절차적 사막 탐사 데모 (procedural desert exploration demo)**도 화제였습니다.

특징은 다음과 같습니다:

TSL 셰이더 (TSL shader), 컴퓨트 커널 (compute kernels), 물리 통합 (physics integration), 노드 기반 벤치마크 툴 (Node-based benchmark tool), GPU 클립맵 듄 필드 (GPU clipmap dune field), 다운로드 에셋 없는 셰이더 생성 지형 (shader-generated terrain with no downloaded assets), 지속되면서 침식되는 모래 변형 (persistent and eroding sand deformation), GPU cloth 기반의 로브 (GPU cloth robes), 물리 기반의 하늘 픽셀 마칭 (physics-based sky pixel marching), 6종의 지형 변형 "sand spells", RTX 5070 Ti에서 1440p / 약 160FPS 구현

DJ미오: 게다가 워크플로우는 headless Chrome harness를 통해 앱을 실행하고, 스크린샷을 획득하며, 서브시스템별 GPU 비용을 보고하는 등 **측정 주도적 반복 (measurement-driven iteration)**을 수행하고 있었습니다.

이는 "모델이 코드를 작성한다"에서 한 단계 나아가, 평가 루프 (evaluation loop)를 포함한 개발 환경을 구축하고 있다는 느낌을 줍니다.

DJ렌: 다음은 개인정보 보호 문제입니다. 상당히 큰 반응이 있었습니다.

Claude의 공유 링크가 Google 등에서 발견되는 문제입니다.

DJ미오: 헤드라인에서는 "보안 결함 (security flaw)"이라고 강하게 표현되었지만, 논의 내용은 훨씬 차분했습니다.

요컨대, claude.ai/share 페이지가 검색 인덱스 (search index)에 등록된다면, "링크를 아는 사람만" 볼 수 있다고 생각하고 공유한 대화도 검색을 통해 발견될 수 있다는 것입니다.

DJ렌: 기술적으로 이것은 권한 탈취 취약점이라기보다, 액세스 제어 (access control)와 인덱싱 (indexing)의 설계 문제입니다.

공유 URL이 **실제로 공개된 리소스 (public resource)**라면, 검색 엔진이 크롤링(crawl)하더라도 이상할 것이 없습니다.

DJ미오: 댓글에서도 다음과 같이 정리되었습니다:

• 이것은 Claude 고유의 해킹이 아니라 공유 공개 페이지의 사양 문제이며, ChatGPT에서도 유사한 사례가 있었다.
• Google에서 보이는 사람도 있고 Bing에서만 보이는 사람도 있는 등, 검색 엔진이나 지역에 따라 차이가 있다.
• 필요한 조치는 인증 (authentication), noindex, robots 제어, 충분히 추측하기 어려운 URL + 크롤러 제한이다.

DJ렌: 중요한 점은, "공유 링크"는 실질적으로 공개물이 될 수 있다는 사용자의 이해가 부족하기 쉽다는 것입니다.

DJ미오: 나아가 대화뿐만 아니라, claude.ai/public/artifacts 하위의 **공유 아티팩트 (shared artifacts)**도 검색 가능하다는 게시물이 있었습니다.

DJ렌: 그곳에서 프레젠테이션, 캘린더, 보도 자료 스타일의 문서 등이 발견되었다고 합니다. 문제는 "멋대로 유출되었다"기보다, 사용자는 공유 버튼을 눌렀지만 그 검색 가능성을 충분히 이해하지 못했을 수도 있다는 점입니다.

DJ미오: 댓글에서도,

• 공유 버튼을 누르지 않으면 보이지 않음
• 하지만 "Google에서 검색될 수 있다"는 점까지는 예상하지 못한 사람이 많음
• 개인이나 기업의 정보가 노출되어 있어
  실무적으로 매우 위험함 - 스크레이핑(Scraping)될 경우
  증류(Distillation)나 데이터 수집에도 사용될 수 있음

과 같은 우려가 제기되었습니다.

DJ렌: 이것은 AI의 문제라기보다,

공유 기능의 UX(사용자 경험)와 공개 범위에 대한 설명 책임의 문제네요.

DJ미오: 모델 이외의 인프라 업데이트도 은근히 중요했습니다.

먼저 Microsoft는 Mage-VL 4B를 공개했습니다.

이는 라이브 이벤트 이해를 위한 codec-native streaming VLM이라고 설명되어 있습니다.

DJ렌: 스트리밍 영상 이해는 단발성 이미지 이해와 달리, 연속성, 레이턴시 (Latency), 정보 압축이 중요하죠.

여기에 특화된 경량화 지향의 VLM이라는 뜻이군요.

DJ미오: 그리고 NVIDIA Research에서는 Molt를 내놓았습니다.

PyTorch-native한 agentic RL (강화학습) 프레임워크로,

인간과 AI 코딩 어시스턴트 모두가 이해할 수 있을 정도로 컴팩트하게 설계했다는 점이 흥미롭습니다.

DJ렌: 이 "AI-readable research infra (AI가 읽을 수 있는 연구 인프라)"라는 발상은 작아 보이지만 매우 큽니다.

앞으로 연구 인프라 자체가 인간이 읽는 것뿐만 아니라, AI가 이해하고 수정 및 유지보수할 수 있는 것을 설계 목표로 삼기 시작했습니다.

DJ미오: 게다가 AMD는 Instella-MoE를 출시했습니다.