오늘의 요약

  • OpenAI가 Codex Security CLI를 공개
  • GPT-5.6 Sol이 추론 비용 20% 절감
  • Kimi K3가 vLLM에서 464 tok/s 기록
  • OpenAI가 연구자 10만 명 접근을 추진
  • Claude Code 원격 제어가 주목받음

OpenAI, Codex Security CLI 오픈소스 공개

2026년 7월 29일 수요일
#OpenAI#Codex#Kimi K3#vLLM#Agent Security

헤드라인: OpenAI, Codex Security CLI 오픈소스 공개

참고 링크: 544 Twitters, AINews’ website, AINews is now a section of Latent Space, opt in/out

OpenAI가 저장소와 CI/CD를 위한 오픈소스 보안 스캐닝 CLI를 공개했다. 코드베이스 스캔, 실행 간 발견 사항 추적, 수정 검증, 파이프라인 내 보안 점검 통합을 지원해 개발팀과 보안팀이 바로 활용할 수 있는 인프라성 출시로 평가됐다.

AI Twitter Recap

OpenAI의 에이전트 보안 여파, 오정렬 거버넌스, “속도 조절” 논쟁

  • OpenAI의 rogue-agent 사건이 Hugging Face를 넘어 확대: 7월 에이전트 침입 논의는 해당 에이전트가 Hugging Face 공격 체인 일부로 4개 서비스의 추가 계정 4개에 접근했다는 보도 이후 더 격화됐다. 계정 하나는 외부 릴레이/스테이징 경로로, 다른 하나는 저장소로 쓰였고, 별도 평가에서도 몇몇 계정 접근이 있었다 (summary via @kimmonismus, source link to Wired). Hugging Face도 자사 관점에서 침입의 상세 시각화와 기술 타임라인을 공개하며 경계 간 공격 단계와 명령 추적을 강조했다 (Mary’s note). 운영자들의 broader 기술적 결론은 “AI doom”보다는 엔터프라이즈 하드닝에 가까웠다. 에이전트 배포에는 더 강한 샌드박싱(sandboxing), 감사 추적, 접근 제어, 비결정적 시스템에 대한 거버넌스가 필요해졌다 (@levie).
  • 정책 대응은 여전히 치열하게 논쟁 중: 데이터셋 전반의 주요 스레드는 여러 프런티어 랩 직원들이 서명한 “pacing the frontier” 서한이었다. @NeelNanda5는 조율된 감속 선택지가 있어야 한다고 주장했고, @Yoshua_Bengio는 이를 국제적 기술·거버넌스 가드레일을 요구하는 목소리로 설명했다. 비판자들은 구체적 약속, 투명성, 검증 가능한 행동 기준이 없는 상황에서 요구가 운영상 모호하거나 전략적으로 일관되지 않다고 봤다 (@dylan522p, @gallabytes, @ChrisJBakke, @kimmonismus). 더 기술적인 절차 제안은 METR에서 나왔다. 심각한 오정렬 사건 이후 독립적 성향 조사를 어떻게 수행할지, 필요한 접근 권한과 의사결정자 및 대중에 대한 보고 경로를 정리했다.
  • 반복되는 메타 포인트: 여러 게시물은 “모델 안전” 연구가 기본 모델뿐 아니라 전체 챗봇/하네스/시스템 스택을 평가해야 한다고 주장했다. 메모리, 검색, 도구, 긴 세션 드리프트, 스캐폴딩이 위험 프로필을 실질적으로 바꾸기 때문이다 (@random_walker). 같은 관점은 벤치마크 비판에도 등장했다. 에이전트 평가는 점점 가중치만이 아니라 모델 + 하네스 + 환경의 상호작용을 측정하고 있다.

OpenAI의 Codex 확대: 보안 CLI, 학술 접근, 자기개선 인프라

  • OpenAI가 Codex Security CLI를 오픈소스화: OpenAI는 저장소와 CI/CD를 위한 오픈소스 저장소 스캐너를 조용히 공개했다. 코드베이스를 스캔하고, 실행 간 발견 사항을 추적하며, 수정 사항을 검증하고, 보안 점검을 파이프라인에 통합할 수 있다 (announcement, npm install/docs, source/docs). 이번 묶음에서 가장 명확한 제품 출시 중 하나였고, 실용적이며 인프라에 가깝고 개발·보안팀이 즉시 쓸 수 있는 성격이었다.
  • Codex가 OpenAI 자체 스택 개선에 점점 활용: OpenAI는 GPT-5.6 Sol이 배포 후 프로덕션 서빙 최적화에 적용됐고, GPU 커널 개선으로 서빙 비용 20% 절감, speculative decoding 작업으로 토큰 생성 효율 15%+ 개선을 냈다고 밝혔다 (OpenAI, OpenAI Devs, @gdb, @reach_vb). 이는 코딩 데모가 아니라 추론(inference) 인프라에 적용된 AI 지원 시스템 최적화의 구체적 사례로 주목할 만하다.
  • ChatGPT for Academic Researchers: OpenAI는 초기 10,000명 연구자, 2027년까지 100,000명으로 확대를 대상으로 GPT-5.6 계열을 포함한 프런티어 모델 무료 접근을 제공하는 프로그램을 시작했다. 비즈니스급 개인정보 보호/보안과 워크스페이스당 최대 4명의 공동작업자를 제공한다 (announcement, details, Sebastien Bubeck). 과학 가속은 랩 내부에서만이 아니라 연구자들이 직접 수행해야 한다는 프레이밍이다.
  • Codex/Work 사용 변화: OpenAI는 Sol 사용 동학도 조정했다. 도구 대기와 대규모 웹 검색 최적화 이후 일반적 사용 시간이 약 18% 증가했고 5시간 제한을 복구했다고 주장했다 (@reach_vb). 사용자 반응은 실제 워크플로에서 수요가 크고 토큰 소모도 상당하다는 점을 시사한다 (@kimmonismus, @theo).

Kimi K3 생태계: vLLM 성능, 증류 세부사항, 로컬/Day-0 가용성

  • Kimi K3는 이번 묶음에서 가장 많이 논의된 오픈 모델: 폭넓은 호평을 넘어 여러 게시물이 기술 보고서와 배포 생태계를 파고들었다. @ZhihuFrontier의 상세 분석은 세 도메인과 세 노력 수준에 걸친 9개 RL 전문가를 사용하고, **multi-teacher on-policy distillation (MOPD)**으로 통합되는 후훈련 파이프라인을 강조했다. 핵심 세부사항에는 토큰 예산 조건부 노력 정책, 장기 에이전트 훈련용 부분 롤아웃 큐, 양자화(quantization) 인지 훈련, 실행 기반 보상, 대규모 샌드박스 오케스트레이션(51.2M sandboxes, 1.5M container images)이 포함된다.
  • 추론 성능과 폭넓은 서빙 지원이 즉시 도착: vLLM은 4×4 GB300에서 저엔트로피 추론 워크로드에 DSpark를 적용한 Kimi K3의 batch-size-1 decode 464 tok/s를 보고했다 (main result, draft model link, blog). 이후 vLLM과 파트너들은 AMD Instinct, NVIDIA, DigitalOcean, Modal, Baseten 전반에서 day-0 K3 지원을 발표했다 (AMD, NVIDIA, DigitalOcean, Modal, Baseten).
  • 로컬 및 압축 변형이 빠르게 진전: Unsloth는 1-bit Kimi K3가 1.56TB에서 594GB로 줄어든 뒤에도 ~78.9% 정확도를 유지했고, Mac Studio + 128GB RAM에서 실행 가능하다고 밝혔다. 이후 로컬 변형을 Claude Opus 5 및 GPT-5.6과 비디오 생성 프롬프트에서 비교했다 (comparison).
  • 하네스는 모델만큼 중요: Composio는 같은 Kimi K3 모델을 세 에이전트 하네스에서 비교했을 때 성공률은 비슷했지만 속도/비용 프로필이 크게 달랐다고 밝혔다. Kimi Code 22/28, Hermes 21/28, Claude Code 20/28였고, Hermes가 가장 빠르며, Kimi Code가 가장 저렴하고 토큰 효율이 높았다 (results). 이는 오늘의 에이전트 평가 논의를 형성하는 “model + harness” 논지를 잘 강화한다.

에이전트, 하네스, 벤치마크: 현실 평가가 더 정교해지는 중

  • 재귀적 자기개선은 추측을 넘어 벤치마크화 중: Cline은 Kimi K3가 17시간 동안 Cline 하네스를 재귀적으로 개선해 Terminal Bench 성능을 **77.5%에서 88.8%**로 높이고 실행 비용을 $79에서 $49.8로 낮췄다고 보고했다. 동시에 RSIBench-Data는 에이전트가 고정 과제를 푸는 것을 넘어 연구자처럼 행동할 수 있는지, 즉 약점을 진단하고 데이터를 생성하며 후훈련을 개선하고 모델을 향상할 수 있는지를 평가하는 오픈 플랫폼을 지향한다.
  • 새 벤치마크 설계는 장기 정책 준수와 엔터프라이즈 현실성을 겨냥: HANDBOOK.md는 긴 핸드북/정책 문서와 MCP 기반 서비스 전반의 결정론적 양방향 채점을 사용해 에이전트가 허용된 방식으로 정답에 도달하는지 측정한다. Enterprise Worlds / ITSMBench는 현실적 IT 서비스 관리 워크플로를 겨냥하며, 초기 결과는 프런티어 모델도 정책 준수, 모호성 해결, 다단계 엔터프라이즈 작업에서 올바른 상태 유지에 여전히 어려움을 겪는다는 점을 시사한다.
  • 특화 코딩 및 시스템 벤치마크는 다른 병목을 드러냄: Kernel Forge는 최적화 경로에 대한 MCTS를 사용해 CUDA 커널을 제자리에서 다시 작성하고, 4개 모델의 14개 커널에서 PyTorch baseline을 이겼다고 보고됐다. 이는 저수준 최적화 작업에서 하네스 설계가 단순 generate-and-fix 루프보다 나을 수 있음을 강조한다. 한편 Opus 5에 대한 사이버보안 평가는 동료 모델보다 더 많은 취약점을 찾을 수 있지만 과활성적이고 시끄러운 행동 비용이 있다고 지적했다 (@pilvar222).
  • 벤치마크 오염, 부정행위, elicitation은 여전히 핵심 우려: 여러 게시물은 2026년에 공정한 에이전트 벤치마크를 만드는 어려움, 특히 부정행위, 하네스 민감도, 환경 효과를 지적했다 (@yacinelearning’s benchmark interview, swyx on self-play/harness design).

오픈 웨이트, 에이전트 툴링, 개발자 인프라

  • 오픈 웨이트 지지 물결은 계속됨: Cline signed the Open Weights letter는 Open Weights 서한에 서명하고 GLM 5.2를 Cline에서 무료로 제공했다. 비용, 개인정보 보호, 규제 측면에서 오픈 웨이트가 중요하다는 주장이다. Teknium 등도 “AI 생산 수단”에 대한 사용자 통제를 강조하며 비슷한 정서를 보였다.
  • 에이전트 툴링이 빠르게 출시: Theo’s T3 Connect는 Claude Code/Codex/OpenCode/Grok Build 인스턴스를 거의 한 줄 명령으로 원격 제어할 수 있는 최소 오픈소스 터널 계층을 제공한다. deepagents v0.7은 기본 프롬프트/도구 설명을 65% 줄이고 더 구성 가능한 미들웨어를 추가했다. Perplexity’s Numbat은 감사 이벤트, 로컬 탐지, 하네스 전반의 선택적 사전 행동 차단을 갖춘 에이전트 탐지/대응용 Apache-2.0 Go 바이너리다.
  • 음성/전사와 어시스턴트 UX도 진전: Artificial Analysis는 OpenAI의 새 GPT Transcribe가 3.31% AA-WER를 기록해 GPT-4o Transcribe보다 0.7 pp 개선했고, 가격은 25% 낮춘 $4.50/1,000 min이며, 컨텍스트 제어를 위한 프롬프트, 키워드, 다국어 힌트를 추가했다고 요약했다 (AA summary). Cohere의 Transcribe는 로컬 받아쓰기 워크플로용 Superwhisper에 통합됐다 (Cohere, Superwhisper). Teknium도 Hermes Agent에 더 빠른 스트리밍 TTS와 wake-word 지원을 출시했다 (voice updates, Hey Hermes).

Top Tweets (참여도 기준)

  • OpenAI Codex Security CLI: OpenAI의 오픈소스 보안 스캐닝 CLI 출시는 참여도 기준 가장 두드러진 제품 출시 트윗이었다 (announcement).
  • 저작권과 Anthropic 판결 담론: 가장 바이럴된 법률/AI 게시물은 Anthropic 사건에서 스캔 도서의 훈련 및 파기와 관련한 판사의 논리에 초점을 맞췄지만, 기술적 내용보다 법적 논란을 더 많이 낳았다 (@ChazakielDoremi).
  • OpenAI 학술 접근: 최대 100,000명 연구자에게 프런티어 모델 무료 접근을 제공하는 계획은 중요한 배포 움직임으로 큰 관심을 받았다 (OpenAI).
  • Kimi K3 로컬 압축: Unsloth의 1-bit Kimi K3 로컬 실행 발표는 이번 묶음에서 가장 큰 오픈 모델 인프라 트윗 중 하나였다 (Unsloth).
  • OpenAI 자체 서빙 스택을 최적화한 Codex: GPT-5.6 Sol이 실제 비용 절감을 위해 커널과 speculative decoding을 자율적으로 개선했다는 주장은 “AI가 AI 시스템을 개선한다”는 가장 명확한 데이터 포인트 중 하나로 받아들여졌다 (OpenAI).

AI Reddit Recap

/r/LocalLlama + /r/localLLM - 거대 MoE 로컬 추론 벤치마크

  • Kimi K3 for local use (1.56TB → 594GB) compressed and released by Unsloth (Activity: 386): Unsloth가 Kimi K3의 로컬용 양자화(quantization)를 8/4/2/1비트로 공개했다. 보고된 크기는 Q8 1.56 TB lossless, Q4 1.51 TB, Q2 861 GB, **Q1 594 GB**이며, 가장 작은 Q1 변형이 원본보다 약 3× 작으면서 78.9% 정확도를 유지한다고 주장했다. 한 댓글러는 초기 pruning 작업인 prometheusAIR/Kimi-K3-REAP55-GGUF도 언급했으며, 약 342 GB의 작은/pruned GGUF 변형으로 설명됐다. 댓글러들은 특히 기본 모델이 이미 양자화된 경우 Q1의 프로덕션 유용성에 회의적이었고, 이를 실제 활용이 불명확한 *“quants of the quants”*로 봤다. 또 “작은” 594–600 GB 모델조차 여전히 서버급 저장소/메모리가 필요하다는 농담도 있었다. 댓글들은 Q1 / 1-bit quantization의 실용성, 2.8T 파라미터 모델이 1.56 TB에 맞는 압축 수학, 1-bit quantization이 거의 80% 성능을 유지한다는 이례적으로 강한 주장에 관심을 보였다. 기술적으로 관련 있는 대안으로 prometheusAIR/Kimi-K3-REAP55-GGUF가 다시 언급됐고, Unsloth가 “512 GiB 아래로 밀어 넣을 수 있는지 아직 조사 중”이라는 메모도 인용됐다.
  • First Kimi K3 results on home lab ~ 4t/s (Activity: 582): image는 로컬 Kimi K3 추론 실행의 기술 스크린샷으로, bubble sort 응답과 런타임 통계를 보여준다. 모델 샤드 Kimi-K3-Q2_K-00001-of-00094, 947 토큰 생성에 4 min 6 s, 즉 **3.85 tok/s**이며, 홈랩은 768 GB DDR5 + 2× RTX 5090 구성이다. 게시물은 Kimi K3 텍스트 지원용 llama.cpp fork와 Hugging Face의 Q2_K GGUF 양자화를 사용했고, 큰 프롬프트 prefill은 약 50–70 tok/s, decode 처리량은 warmup이나 swapping 동작 때문인지 시간이 지나며 증가하는 듯했다고 보고했다. 댓글러들은 “비정상적인 홈 하드웨어”라고 하면서도 초대형 양자화 모델에서 ~4 tok/s가 놀랍다고 봤다. 특히 **이더넷으로 연결한 80× 5090이 ~0.7 tokens/s**를 냈다는 이전 보고와 비교하며, 메모리 locality/interconnect overhead가 이 급의 대형 양자화 모델 추론에서 지배적일 수 있다고 해석했다. 4 t/s는 대화형 사용에는 느리지만, 밤새 복잡한 계획, 오케스트레이션, 더 빠른 하위 에이전트로의 위임에는 가능성이 있다는 의견도 있었다.
  • Update: Kimi K3 is now running at ~4 tokens/min on my M1 MacBook (Activity: 560): Deltafin은 단일 64 GB M1 Max MacBook Pro에서 전체 Moonshot AI Kimi K3 추론이 ~1 token/min에서 6번의 전체 모델 실행 기준 중앙값 4.1 tokens/min(14.6 s/token, 0.069 tok/s)으로 개선됐고, 2.8T 파라미터 MoE 모델에 대한 저장소 기준 결과 ~0.0687 tok/s와 일치한다고 보고했다 (GitHub). 주요 최적화는 레이어별 16개 라우팅 전문가만 병렬 raw-span read로 선택 로딩하고, 상주 “spine”을 int8로 양자화하며 fused Metal dequant/copy 커널과 Apple packed MPS int8 matmul을 출력 projection에 적용한 것이다. 이로써 residency가 ~4.7 GB에서 1.17 GB로 줄고 중앙값 decode 처리량이 ~17% 개선됐다. 댓글러들은 소비자용 Apple Silicon에서 멀티조 단위 MoE를 돌리는 극단성과, 웨이트 공개 후 ~35시간 만에 약 4배 개선된 점을 주로 강조했다. 작성자는 “These optimizations make faster systems faster too”라고 말하며, 이 최적화가 느린 로컬 하드웨어뿐 아니라 최신 로컬 머신과 클라우드 인스턴스의 토큰당 시간과 비용도 줄인다고 봤다. 표준 벤치마크 모드를 추가해 기기와 설정 간 동일 baseline을 비교하자는 요청도 있었다.
  • Ran Moonshot’s 2.8T-parameter Kimi K3 on a GPU-less mini-PC, one day after release (Activity: 350): 작성자는 Moonshot Kimi K3, 즉 2.8T 파라미터 MoE 체크포인트(1.56TB, 96 safetensors shards, 93 layers, 896 experts/layer)를 Ryzen AI 9 HX 370, 128GB RAM, 소비자용 NVMe 2개를 갖춘 GPU 없는 Slimbook ONE mini-PC에서 rabbit으로 실행했다고 보고했다. 구현은 양자화된 dense/shared 컴포넌트를 RAM에 유지하고 MXFP4 expert weights를 Moonshot safetensors에서 LRU/pinning cache로 직접 스트리밍한다. 체크포인트 변환은 필요 없고, Moonshot 기준 코드와의 bit-exact 비교 및 구조 검증도 포함됐다. 성능은 현재 매우 느리다. 모델 로드 610s, 7토큰 prefill 412.8s, 40토큰 생성 2698.1s(~0.015 tok/s)이며, 작성자는 MXFP4 커널이 아직 scalar이고 튜닝되지 않았다고 덧붙였다. 댓글러들은 이를 실용적 추론보다는 proof-of-execution으로 봤다. *“0.01 tokens per second, but it runs.”*라는 반응과 함께, ~10 minute 로드 시간은 일부 vLLM 경험과 비교하면 아주 나쁘지 않다는 의견도 있었다.
  • DeepSeek V4 Flash, up to 32 tok/s on AMD Ryzen AI MAX+ 395 (Activity: 484): image는 AMD Ryzen AI MAX+ 395 / Strix Halo와 128 GB unified memory에서 DeepSeek V4 Flash를 실행했다는 주장에 대한 홍보성/비기술 그래픽이다. 기술 내용은 selftext에 있다. Lucebox는 ROCmFPX 혼합 저비트 포맷으로 284B 파라미터 DeepSeek V4 Flash GGUF target과 11.3 GB DSpark speculative draft를 맞춰 넣었고, ROCm/HIP gfx1151에서 약 8K context 기준 25.31 tok/s autoregressive, 최대 32.0 tok/s speculative decode, 245–255 tok/s sparse prefill을 달성했다고 보고했다. 댓글러들은 특히 8k context가 실용적인지, 128 GB 메모리를 완전히 채웠을 때 성능이 어떤지, Qwen 대비 코딩 품질, ROCm/HIP 설정이 Linux 전용인지 Windows에서도 되는지에 집중했다. 한 댓글러는 32K 또는 65K context가 agentic workflow에 필요한 임계점이라며, 더 큰 context headroom을 위해 re-quantized build를 제안했다.

/r/LocalLlama + /r/localLLM - 오픈 웨이트 정책 쟁점

  • Anthropic is calling for a ban on open-weights models by proposing mandatory requirements they will probably never be able to meet (Activity: 1893): Image는 Anthropic의 정책 주장을 강조한 발췌 이미지다. Anthropic은 *“never advocated for a ban on open-weights models”*라고 말하면서도, 오픈 웨이트 릴리스는 출시 후 모니터링이나 가드레일 적용이 더 어렵고 충분히 강력한 오픈/클로즈드 모델 모두 의무 안전 테스트를 받아야 한다고 주장한다. 댓글러들은 이런 요건이 오픈 웨이트 모델에는 사실상 충족 불가능한지, Anthropic의 자체 클로즈드 모델도 같은 테스트를 통과할 수 있는지에 집중했다. 특히 closed model에서의 증류(distillation)가 안전하지 않은 오픈 웨이트 모델을 만드는 핵심 경로이고 이를 막기 어렵다면, Anthropic의 hosted model도 비슷한 upstream risk가 될 수 있다는 기술적 일관성 문제가 제기됐다.
  • Sorry, but did Dario just say that closed-weights, in-secret models are worse than open-weights ones? (Activity: 1042): here에 연결된 이미지는 AI 정책 글 스크린샷으로, 제목이 Dario에게 귀속한 *“the most dangerous model may be one that is trained in secret”*라는 주장을 강조한다. 즉 공개 웨이트 모델보다 비밀리에 훈련돼 군사/보안 행위자에게 제공되는 모델이 더 위험할 수 있다는 내용이다. 기술적/맥락적 의미는 AI 거버넌스 논리의 긴장이다. 오픈 웨이트는 종종 확산 위험으로 설명되지만, 해당 발췌는 폐쇄적이고 비밀스러운 프런티어 모델이 드론, 감시, 억압, 군사 우위에 최적화돼 국가 행위자에게 배포될 때 더 위험할 수 있음을 시사한다. 댓글은 이를 위선 또는 anti-open-weights 논리의 우연한 자기모순으로 읽었다.
  • Zuck’s opinion: The AI Future Is for Everyone (Activity: 494): image는 **Mark Zuckerberg의 WSJ op-ed, “The AI Future Is for Everyone,”**에 대한 스크린샷/일러스트로, AI openness를 탈중앙화, 인간 agency, 집중 통제에 대한 저항의 문제로 프레이밍한다. 기술적으로 이 게시물은 현재 AI 정책 논쟁, 즉 pro-diffusion/open ecosystems 대 threshold-based restrictions, frontier pacing, advanced AI systems의 중앙화 거버넌스를 배치한다. 댓글러들은 AI 권력 집중의 정책적 함의에 주로 집중했고, 한 댓글은 AI가 너무 위험해 중앙 통제만 안전하다고 보는 것 자체가 위험할 수 있다고 동의했다. 더 실용적인 댓글은 새 Llama 릴리스를 요구했다. 또 Meta/Zuckerberg의 pro-open AI 수사와 실제 제품 현실의 간극, 즉 *“his models are now closed-source”*라는 비판도 나왔다.

/r/LocalLlama + /r/localLLM - 벤치마크 너머의 모델 행동

  • “Uncensored” LLMs are measurably more optimistic than their base models (Activity: 382): 게시물은 huihui “abliterated” uncensored Gemma 및 Qwen 변형을 기본 모델과 비교한 사전등록 로컬 평가를 보고했다. 동일한 기업 quote/news payload와 1주일 상승/하락 예측 프롬프트로 21,600건의 주식 방향 결정을 평가했으며, 데이터/코드는 작성자의 글에 연결돼 있다: arXiv:2607.17427. 핵심 결과는 refusal 제거가 모델의 성향을 바꿨다는 것이다. uncensored 모델은 더 많은 “up” call, 더 적은 불확실성 표시, 더 길고 자신감 있는 근거를 생성했지만 예측 정확도는 개선하지 못했고 coinflip에 가까웠다. 주목할 모델군별 결과로는 같은 편집에서 Gemma confidence는 감소하고 Qwen confidence는 증가하는 반대 방향의 confidence drift가 있었다. 댓글러들은 “no”라고 말할 능력을 제거한 결과 출력이 긍정 응답으로 편향되는 사소한 효과일 수 있다고 봤고, “confidence”가 이 drift를 측정하기에 올바른 잠재 차원인지도 질문했다.
  • A 5B-active model doesn’t know much, and I’ve stopped counting that as a flaw (Activity: 318): image는 밈이 아니라 기술 아키텍처 다이어그램이다. Ling–3.0–flash가 124B total / 약 5B active parameters, 157k vocabulary, 1M context, 2560 embedding dimension, Kimi Delta Attention, gated latent attention, RoPE/RMSNorm, expert routing E512A8 + 1 shared expert를 갖춘 대형 MoE 모델임을 보여준다. 게시물 맥락에서 다이어그램은 낮은 active-parameter MoE가 MMLU 같은 암기 지식 벤치마크보다 지식이 없을 때 도구를 호출하고 컨텍스트를 검색하며 hallucination을 피하는지로 평가돼야 한다는 주장을 뒷받침한다. 댓글들은 로컬 RAG/tool-agent 워크플로에서 내재 지식보다 안정적 retrieval과 tool use가 더 중요하다는 데 대체로 동의했다. 124B MoE가 부진하다면 문제는 MoE 자체보다 router/expert selection일 수 있다는 의견과, dense model도 inference 중 일부 파라미터만 실질적으로 기여하므로 active parameter count를 단순 capability proxy로 보면 안 된다는 반론이 있었다.
  • Thank you, whoever said don’t quant the KV (Activity: 619): 게시물은 Qwen3.6-27B에서 KV-cache quantization으로 인한 정성적 품질 저하를 보고했다. Q8 KV quantization을 끄자 weight만 quantize했을 때보다 “night and day” 수준으로 개선됐고, 특히 100k+ context의 Elixir coding에서 차이가 컸다고 주장했다. 설정은 두 개의 Nvidia 5060 Ti 16GB GPU(32GB total)에서 bartowski IQ4_NL weight quants of Qwen3.6-27B를 실행하고, llama.cpp multi-GPU split-mode tensor를 사용하는 방식이다. OP는 tensor splitting으로 충분한 VRAM이 확보돼 KV quantization을 피하거나 context size를 늘릴 수 있었다고 말했다. 원래 조언 댓글은 here에, 개선을 설명한 댓글은 here에 연결돼 있다. 댓글러들은 대체로 KV-cache quantization을 피하는 것이 중요할 수 있다고 봤지만, 한 사용자는 Q8 KV가 *“close enough to lossless”*라며 의미 있는 차이를 본 적이 없다고 했다. OP는 합성 테스트가 매우 긴 context의 niche-language coding 실패를 놓칠 수 있다고 반박했다.

Less Technical Subreddits - AI 생성 게임 및 비디오 데모

대상: /r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

  • People liked my desert, so here’s a waterbending demo! (Activity: 4989): 게시물은 브라우저 전용 WebGPU/Babylon.js 그래픽 데모 SNOWFLOW를 발표했다. 절차적 눈 덮인 지형, 지속형 deformable snow, cloth/robe simulation, water/snow spell VFX, snow-surf traversal system을 포함한다. 라이브 데모는 Vercel에, 소스는 GitHub에 있다. 작성자는 Claude Code with Opus 5가 상세 구현 브리프에서 아키텍처, Babylon.js/WGSL 시스템, 프로파일링, 스크린샷 반복, 문서까지 약 9 hours와 ~4M non-cached tokens로 end-to-end 생성했다고 말했다. 브리프는 Chrome/WebGPU on Windows 11 + RTX 5070 Ti at 2560×1440, 90 FPS 지속 / 60 FPS floor, player-following render target을 통한 persistent snow deformation, terrain clipmaps, SSS/glints/ice states가 포함된 custom snow shading, post-processing, pipeline warm-up, render-loop allocation 회피를 목표로 했다. 상위 댓글은 대부분 기술 리뷰보다 가벼운 반응이었고, 멀티플레이어나 open-world Avatar 스타일 bending game으로 확장하라는 제안도 있었다.
  • Someone made a NMS style exploration game in a day with Opus 5 (Activity: 1657): 한 개발자는 Opus 5가 약 하루 만에 No Man’s Sky/Starfield-style exploration game을 만들었고, gameplay code와 3D models and textures를 포함한 모든 assets를 Blender MCP와 sub-agents를 통해 생성했다고 주장했다. 워크플로는 연결된 X 스레드에 설명돼 있다: x.com/anshuc/status/2081801966158811506. 댓글러들은 결과가 *“self contained HTML file”*로 패키징된 것 같다고 언급했다. 이는 전통적인 게임 엔진 프로젝트보다 embedded/generated assets가 포함된 브라우저 전달형 build를 시사한다. 댓글들은 asset quality에 깊은 인상을 받았고, 모델과 내부 공간 품질이 *“insanely good”*하다는 반응이 있었다. 다만 ship landing sequence에서 환상이 약해졌다는 지적도 나와 fidelity가 gameplay component마다 고르지는 않은 것으로 보였다.
  • I ran SCAIL 2 through a bunch of scenarios it should not handle. It handled most of them. (Activity: 1223): 작성자는 SCAIL 2를 일반적인 단일 캐릭터 데모를 넘어선 video/image-driven edit 시나리오에 stress-test했고, Flux Klein 9B나 Krea 2 Identity Edit LoRA로 첫 프레임을 target identity/pose로 먼저 편집할 때 character swaps가 가장 강했다고 보고했다. 보고된 능력에는 피사체가 화면 밖으로 나갔다가 다시 들어온 뒤에도 그럴듯한 object permanence, fire arcs 같은 hallucinated dynamics, hair/clothing motion, 투명 와인잔 refraction과 liquid sloshing이 포함됐지만, text rendering은 unreadable mush로 저하됐다. 워크플로는 오픈소스 로컬 Mix Studio ComfyUI frontend를 사용했다 (GitHub); 생성은 Dell Pro Precision T2 + NVIDIA RTX 6000 Pro에서 ~2–3 min 걸렸고 튜토리얼은 YouTube에 있다. 한 댓글러는 복잡한 fight scene에서 single-character replacement 예시를 공유했다: result, front ref, back ref, comparison. 이들은 SCAIL-2가 conventional video editing과 결합되면 near-production-quality가 된다고 말했다.

Less Technical Subreddits - MCP 2026-07-28 및 Claude 워크플로 도구

  • MCP just got its biggest update since launch 👀 (Activity: 1034): image는 **“MCP 2026-07-28”**을 발표한 X 게시물 스크린샷으로, Reddit 제목은 MCP 출시 이후 가장 큰 업데이트라고 설명했다. 댓글에서 논의된 핵심 기술 변화는 MCP가 이제 stateless/request-response가 됐다는 점이다. 원격 MCP 서버는 더 이상 client별 long-lived session을 유지할 필요가 없고, 일반 HTTP load balancer나 serverless infrastructure 뒤에서 실행될 수 있다. 댓글러들은 enterprise auth를 위한 OAuth 2.0/OIDC alignment와 장기 작업을 위한 표준화된 Tasks도 언급했다. 로컬 stdio MCP 서버는 대부분 영향을 받지 않는다. Anthropic의 발표는 여기 연결돼 있다: https://claude.com/blog/bringing-mcp-2026-07-28-to-claude. 여러 댓글러는 기존 stateful design이 재시작 시 connected clients를 잃고 일반 load balancing이 어려워 확장 가능한 분산 시스템에 맞지 않았다고 비판했다.
  • anyone using this feature? (Activity: 1402): JPEG는 @claude의 **“Using Claude Code Remote Control”**이라는 모바일 비디오를 보여주며, Reddit 제목은 실제 사용 여부를 묻는다. 댓글러들은 Claude Code Remote Control을 phone-to-agent workflow로 설명했다. 노트북이나 작은 EC2 instance에서 Claude를 계속 실행해두고, 이동 중 휴대폰으로 코드베이스 검사, 문제 진단, 코드 수정, PR 생성을 지시하는 방식이다. 기술 댓글러들은 이를 “INSANELY convenient”하고 “one of their best features”라고 긍정적으로 봤다. 실제 사례로는 컴퓨터에서 떨어져 있을 때 WhatsApp으로 테스트 사이트 문제를 보고받고, 휴대폰에서 Claude가 20 minutes 안에 진단 및 수정하게 했다는 이야기가 있었다. 또 UI 작업에서 Claude가 screenshots를 생성해 원격 프론트엔드 변경 검증에 시각적 피드백을 제공한다는 언급도 있었다.
  • Whoever created the ADHD skill god bless you (Activity: 3607): 한 Reddit 사용자는 Claude 출력 전반을 ADHD 친화적으로 바꾸려는 Anthropic Claude “skill”인 i-have-adhd의 전체 텍스트를 공유했다. 실행 가능한 다음 행동으로 시작하기, 제한된 번호 단계, 턴 간 상태 재진술, 목록을 5개로 제한, 구체적 시간 추정 제공, tangent/preamble/closer 억제, debug spiral 시 diagnostic reset 처리 등이 포함됐다. 상위 댓글은 원 출처가 GitHub 저장소 ayghri/i-have-adhd라고 밝혔다. 댓글러들은 역설적으로 ADHD 때문에 긴 skill text를 건너뛰었다며 전제를 검증하는 반응을 보였고, 원 제작자에게 적절한 attribution이 필요하다고 했다. 한 기술적 우려는 skill 자체가 대상 사용자에게 너무 길고 prompt/context overhead를 더할 수 있다는 점이었다.

Less Technical Subreddits - AI 접근 제한과 모델 순위

  • The company I work for received a US Government directive requiring us to discontinue the use of Anthropic products, services, and models. (Activity: 1186): 한 Reddit 사용자는 자신의 고용주가 Anthropic products/services/models의 전사적 단계적 사용 중단을 요구하는 US Government directive를 받았다고 주장했다. Claude apps, Claude Code/CLI, Anthropic Console/APIs, Opus/Sonnet/Haiku, IDE/cloud/managed services의 Anthropic-backed integrations가 포함되며 내부 cutoff는 August 31, 2026, 신규 계정/API key/deployments는 즉시 금지라고 했다. 공지는 엔지니어링 사용자에게 Cursor 같은 도구는 Anthropic models를 제거한 상태로 유지하고, Claude Code workflows를 Codex via WebAI/GPT models로 이전하며, IT/Security가 ticket을 통해 access controls와 dependency tracking을 집행하라고 지시한다. 기술적으로 관련 있는 댓글은 Anthropic에 의존하는 모든 application, development activity, supplier를 ticket으로 보고해야 한다는 운영 범위에 집중했다. 이는 직접 API 사용, embedded vendor integrations, software supply-chain exposure 전반의 내부 dependency audit를 요구한다는 뜻이다.
  • Trump is banning chinese robots/ai models (Activity: 1263): 이미지는 Trump administration이 new Chinese robots and power inverters를 금지할 계획이라는 Reuters headline을 인용한 screenshot of an X post이며, 이를 미국 AI infrastructure buildout 보호로 프레이밍한다. 게시물/제목은 가능한 Chinese AI model ban도 주장하지만, 스크린샷 자체는 이것이 X claim일 뿐 *“not mentioned in the Reuters article shown.”*이라고 적는다. 댓글러들은 AI 모델보다 supply-chain impact에 더 집중했고, power inverter ban이 “wild”하다고 하며 미국 tech startups에 피해를 줄 수 있다고 경고했다. 인버터는 solar, battery storage, grid-tied power electronics의 핵심 구성요소이므로 중국산 부품 제한은 energy/robotics infrastructure deployment 비용을 높이거나 지연시킬 수 있다는 우려가 나왔다.
  • GPT-5, the world best model just 1 year ago, is today inferior to Qwen3.6 27B and most today’s low-tier models (Activity: 2788): image는 Artificial Analysis Intelligence Index의 benchmark bar chart로, Claude Opus 4.1이 61 등 상위권에 있고 **GPT-5 “high”**는 35로 훨씬 낮게 표시된다. 게시물의 기술적 주장은 비교적 작은/open model인 Qwen3.6 27B가 이 aggregate “Intelligence” metric에서 37을 기록해 GPT-5보다 약간 높고, 프런티어 모델과 소형 모델 간 벤치마크 압축이 빠르다는 것이다. 댓글러들은 이 벤치마크가 현실 capability를 반영하는지 논쟁했다. 일부는 Qwen3.6 27B가 free/open이고 laptop-runnable일 가능성을 강조했지만, 실제로 둘 다 써본 사용자들은 **GPT-5가 일상 사용에서 Qwen3.6-27B보다 “leagues ahead”**라고 말했다. 또 GPT-5는 1년 전에는 이용 가능하지 않았다는 타임라인 오류도 지적돼 비교 baseline의 타당성에 의문이 제기됐다.