Midnight AI Groove 26-05-29

DJ 미오:

안녕하세요, DJ 미오입니다. 심야의 AI 뉴스를 편안하게, 하지만 핵심까지 전달하는 「Midnight AI Groove」에 오신 것을 환영합니다.

DJ 렌:

DJ 렌입니다. 오늘의 테마는 AINews의 2026년 5월 29일 호, 그 이름도 “not much happened today”. 제목은 「별로 아무 일도 일어나지 않았다」이지만, 실제로 살펴보면 AI 업계의 중요 토픽들이 상당히 고밀도로 채워져 있네요.

DJ 미오:

맞아요. 조용한 날이라고 말하면서도 Claude Opus 4.8, 강화학습 (RL) 주변의 간과하기 쉬운 버그, 로컬 LLM, Hugging Face의 움직임, Google과 OpenAI의 매니지드 에이전트(Managed Agent)화, 게다가 연구 논문과 Reddit의 현장감까지 상당히 폭넓게 다루고 있어요.

DJ 렌:

먼저 전체적인 모습부터 보자면, 이번 호는 2026년 5월 28일부터 29일까지의 AI 뉴스 요약입니다. 12개의 subreddit, 544개의 Twitter 계정을 체크했으며, Discord는 신규 사항이 없었습니다. AINews 자체는 현재 Latent Space의 일부가 되어 있어, 과거 호 검색이나 메일 빈도 설정도 가능하다는 안내도 있었습니다.

DJ 미오:

첫 번째 큰 기둥은 역시 **Claude Opus 4.8의 출시 (Rollout)**네요. 평가는 상당히 엇갈리고 있었어요.

DJ 렌:

네. 몇몇 독립적인 평가들이 대체로 같은 방향을 향하고 있었는데,

「전진이기는 하지만, 압도적이라고 할 정도는 아니다」

라는 견해로 수렴되고 있었습니다.

DJ 미오:

구체적으로는, @arena가 200개 이상의 프론트엔드/코드 계열 테스트에서 Opus 4.8을 과거의 Opus 계열, Gemini, GLM과 비교했습니다. @theo는 CursorBench에서 효율은 좋아졌지만, 4.7보다 약간 나쁠 가능성도 있으며 오차 범위 내라고 보고했습니다.

DJ 렌:

문서 처리 계열에서도 평가는 복잡했죠. @jerryjliu0와 @llama_index에 따르면, 표나 레이아웃 처리는 조금 개선된 반면, 내용 충실성이나 차트 해석에서는 퇴보도 관찰되었습니다. @scaling01 역시 ALE-Bench에서는 진전이 없다고 했으며, LisanBench에서는 흥미로운 실패 모드(Failure mode)를 지적했습니다.

DJ 미오:

하지만 긍정적인 목소리도 있었습니다. @jeremyphoward는 4.8이 4.7이나 GPT-5.5보다 과도하게 에이전트적이지 않고, 협조적이며 코딩하기 쉽다고 느꼈고, @leo_linsky는 Anthropic 제품으로서 체감할 수 있는 개선이라고 평가했습니다.

DJ 렌:

즉, 벤치마크를 갈아치운다기보다는 **실운용에서의 사용 편의성이 좋아지는 “QoL(Quality of Life) 업데이트”**로 보는 것이 타당해 보이네요.

DJ 미오:

모델 본체뿐만 아니라, Anthropic은 플랫폼 측면의 개선도 내놓았습니다. 이게 꽤 중요해요.

DJ 렌:

특히, 대화 도중에 system instruction을 삽입해도 prompt cache를 깨뜨리지 않는 기능, 그리고 대화 도중에 권위 있는 system-role을 업데이트할 수 있는 점입니다. 장시간 작동하는 에이전트나 비용 관리가 중요한 운용에서는 상당히 실무적인 개선입니다.

DJ 미오:

반면, 가격 면에서의 불만은 강합니다. @jeremyphoward는 Anthropic이 API의 저렴함 개선을 거의 하지 못하고 있다고 비판하며, 구독/API의 경제성을 설명하기 쉽기 때문에 GPT-5.5를 선호한다고도 말했습니다.

DJ 렌:

이 부분이 지금 AI 프로덕트 경쟁의 핵심이죠. 성능뿐만 아니라 요금, 캐시, 쿼터(Quota), 운용의 용이성이 선정 이유가 됩니다.

DJ 미오:

다음 화제는 상당히 기술적이지만 중요합니다. 도구 사용을 동반하는 멀티턴 강화학습 (Multi-turn RL) 트레이닝 루프가 사실 조용히 망가지고 있다는 지적입니다.

DJ 렌:

이것은 Hugging Face의 심층 분석 기사를 @ClementDelangue가 퍼뜨린 내용입니다. 문제의 핵심은,

• 모델 출력을 디코딩(Decode)한다
• 도구 호출(Tool call)을 분석한다
• 업데이트된 대화 전체를 재토큰화(Re-tokenize)한다

라는 흐름 속에서, 재토큰화 이후의 시퀀스(Sequence)가 모델이 실제로 샘플링한 토큰 열과 어긋나는 것입니다.

DJ 미오:

그 결과, 모델이 실제로는 내보내지 않은 시퀀스에 대해 그래디언트 (Gradient)가 걸리게 됩니다. 상당히 근본적인 파탄이죠.

DJ 렌:

제안된 수정 원칙은 명쾌하며, **“Token-In, Token-Out”**이다.

즉, 일단 샘플링한 토큰은 두 번 다시 재인코딩(re-encode)하지 않는다. 턴(turn)이 바뀌더라도 단일 토큰 버퍼(single token buffer)를 유지해야 한다는 것이다.

DJ 미오:

@johnschulman2도 메시지와 토큰 사이에 있는 renderer 층 그 자체가 기반 인프라라고 강조했다. 여기에는,

• train/test mismatch
• 캐시 효율 저하
• 프롬프트 인젝션(prompt injection) 리스크

와 같은 실패 모드(failure modes)가 있다는 이야기다.

DJ 렌:

표면적으로는 미미해 보일지 몰라도, 이러한 “내부 표현의 정확성”이 향후 에이전트 학습의 토대가 되겠네.

DJ 미오:

여기서 이어지는 것이, agent harness 설계 자체가 최적화 대상이 되고 있다는 흐름이야.

DJ 렌:

@omarsar0가 소개한 Effective Feedback Compute (EFC)는 상징적이었어. 단순한 토큰 수나 도구 호출(tool call) 수로는 에이전트 성공률을 제대로 설명할 수 없는데, EFC를 사용하면 R²이 최대 0.99에 달한다고 했지.

요컨대, 얼마나 많이 활동했느냐보다 얼마나 유효한 피드백 계산이 이루어졌느냐가 중요하다는 거야.

DJ 미오:

이 방향성은 LangChain의 움직임과도 일치해. Deep Agents v0.6에서는 **harness profiles를 일급 설정 대상(first-class configuration target)**으로 취급하고 있으며, Qwen/Kimi/DeepSeek 같은 모델로부터 프론티어 API 대비 20배 이상 낮은 비용으로도 높은 성능을 이끌어내는 것을 목표로 하고 있어.

DJ 렌:

@hwchase17이 명시했듯이, 모델마다 필요한 프롬프트나 도구 설계는 달라. 이제 “어떤 모델이든 똑같은 방식으로 던지는” 시대는 아니지.

DJ 미오:

vLLM 측의 업데이트도 그 맥락에서 중요해. 네이티브 weight syncing API나, 비동기 RL(Reinforcement Learning)을 위한 pause/resume 개선이 나왔고, 그 뒤에는 fastokens라는 Rust 기반 BPE tokenizer도 추가되었어. 이는 긴 문맥(long context)이나 agentic workload에서 CPU 측의 tokenization 병목을 줄이려는 의도야.

DJ 렌:

이 부분도 흥미로웠어. 논의는 이제 single-agent vs multi-agent라는 단순한 이분법적 대립이 아니라, 어디에서 추상화의 이점이 발생하는가로 옮겨가고 있어.

DJ 미오:

@OfirPress는 현재의 멀티 에이전트 시스템은 주로 속도 향상을 위한 것이지, 능력의 본질적인 해방은 아니다라고 보았어. 반면 @scaling01은 반대로, swarm형 훈련이 더 나은 계획 능력이나 초지능적 행동을 낳을 것이라고 기대했지.

DJ 렌:

결론이 나지는 않았지만, 현실적인 트렌드로 보면 **agent observability, trace, 지속적 개선 루프(continuous improvement loop)**에 투자하는 팀이 늘고 있어. 예를 들어 @Vtrivedy10는 실제 운영(production) 트레이스를 파헤쳐서 SFT(Supervised Fine-Tuning)나 증류(distillation), 장기 지속 학습에 활용하는 방향을 이야기했어.

DJ 미오:

다음은 로컬 AI와 OSS 이야기야. 이쪽은 지금 굉장히 뜨거워.

DJ 렌:

@LangChain에 따르면, 2026년 4월에는 AI 팀 3곳 중 1곳이 open-weights 모델을 사용하고 있었다고 해. 9개월 전에는 5곳 중 1곳이었으니 상당히 늘어난 거지. 게다가 @EpochAIResearch는 open-weight 모델이 프론티어 클로즈드 모델과의 격차를 약 4개월 차까지 좁혔다고 추정했어.

DJ 미오:

툴체인 측면에서는 @ggerganov가 llama.app을 공개했어. llama.cpp에 공식 사이트, 통합 인스톨러, 단일 llama 엔트리 포인트를 제공해서, 로컬 도입이나 서드파티 에이전트 통합을 쉽게 만들려는 목적이지.

DJ 렌:

@ollama는 OpenJarvis를 Ollama 기반의 local-first personal AI로 발표하며, Stanford/Hazy의 **“Intelligence Per Watt”**라는 개념과도 연결했어.

즉, 성능뿐만 아니라 와트당 지능, 내 손안에서 돌아가는 현실성이 중시되고 있다는 거야.

DJ 미오:

Hugging Face 관련해서는 인식의 수정도 있었다. @ClementDelangue에 따르면, HF 상의 모델과 데이터셋의 약 50%는 이미 private 상태이며, HF의 스토리지 및 bucket 제공과 함께 그 비중이 늘어나고 있다.

DJ 렌:

즉, Hugging Face는 단순한 **공개 OSS 인프라 (Open Source Software Infrastructure)**가 아니라, **기업용 프라이빗 기반 (Private Infrastructure)**으로서도 존재감이 강해지고 있다는 뜻이네.

DJ 미오:

게다가 @abidlabs는 Hugging Face Jobs가 GitHub runners의 대안으로서 CPU/serverless GPU 기반의 CI (Continuous Integration)에 사용될 수 있음을 보여주었다.

DSPy 진영도 @DSPyOSS와 @dbreunig 등이 DSPy 4.0을 앞두고 문서와 메인 페이지를 쇄신하며, 단순한 프롬프팅 (Prompting)이 아닌 프로그래밍 가능한 AI 시스템 (Programmable AI Systems)으로의 입구로서 정비하고 있다.

DJ 렌:

이번 호는 라이선스 이야기도 제대로 다루고 있었어. @kimmonismus는 NVIDIA가 4개의 오픈 모델군을 Linux Foundation의 OpenMDW-1.1로 옮긴 것을 강조했었지.

DJ 미오:

이로써 가중치 (weights), 코드 (code), 문서 (docs), 데이터 (data)의 법적 파편화를 줄일 수 있어. 오픈 모델의 보급에서는 성능뿐만 아니라 법무 처리의 용이성이 상당히 중요하니까.

DJ 렌:

데이터 측면에서는 @keshigeyan이 GPIC를 소개했어. **1억 쌍의 관대한 라이선스 이미지 코퍼스 (Image Corpus)**와 더불어, **100만 쌍의 벤치마크 (Benchmark)**도 갖추고 있어 연구와 상업적 용도 모두 사용하기 쉽다는 점이 포인트야.

DJ 미오:

다음은 거대 플랫폼 기업들의 움직임. Google도 OpenAI도 방향성이 상당히 비슷해졌어.

DJ 렌:

Google 측에서는 @_philschmid가 Gemini API의 Managed Agents를 소개했어. 단일 API 호출만으로 코드 실행, 웹 액세스, 파일 I/O가 포함된 샌드박스 (Sandboxed) Linux 환경을 준비할 수 있어.

DJ 미오:

컨슈머(Consumer) 대상으로는 @GeminiApp이 미국의 AI Ultra 구독자를 대상으로 Gemini Spark를 전개했어. 이는 **24/7 계속 작동하는 퍼스널 에이전트 (Personal Agent)**로, 사용자의 디지털 환경을 가로질러 동작할 수 있는 위치를 점하고 있어.

DJ 렌:

나아가 Google은 Gemini Omni의 멀티모달 (Multimodal) 생성·편집 데모와 영상·영화 제작을 위한 Google Flow Agent도 밀어붙이고 있었지.

DJ 미오:

OpenAI 측에서는 **Codex가 더욱 지속적인 원격 개발 오퍼레이터 (Remote Development Operator)**에 가까워지고 있어. @OpenAI와 @OpenAIDevs는 Windows에서의 computer use 기능을 추가했고, 나아가 ChatGPT 모바일 앱을 통한 원격 조작도 지원하게 되었어.

DJ 렌:

그 후 UX 측면에서도 백그라운드 에이전트의 안정적인 identicon이나 과거 채팅 검색 기능 등이 추가되었지. @reach_vb는 Windows 제어, 모바일 원격 액세스, 프로필/태스크 통계 등 Codex 업데이트의 전체상을 정리했었어.

DJ 미오:

덧붙여 OpenAI는 gpt-5.5 instant를 업데이트하여, 지나치게 순응적인 동작 개선, 사실성 향상, 다국어 성능 개선을 진행했다고 @michpokrass가 언급했어.

DJ 렌:

Google과 OpenAI, 그리고 Cursor를 포함해 공통적인 점은 이제 **“채팅”이 아니라, “모델 + 하네스 (Harness) + 샌드박스 (Sandbox) + UI + 원격 제어 + 가격 설계”를 포함하는 수직 통합 스택 (Vertical Integration Stack)**이 되어가고 있다는 거야. Cursor도 subagent 기반의 승인 라우팅을 동반한 auto-review mode를 추가했었으니까.

DJ 미오:

Google은 Gemini의 쿼터 (Quota) 평활화, OpenAI는 Codex의 조작 면 확대. 요컨대, 관리된 실행 환경으로서의 AI가 주 전장이 되고 있어.

DJ 미오:

연구 및 시스템 논문 소개도 풍부했어. 우선 검색 및 검색 확장 (RAG) 계열.

DJ 렌:

DJ 렌:

@TheTuringPost는 Harvard/MIT의 **Bidirectional Evolutionary Search (BES)**를 다루고 있었어. 순방향 탐색(forward search)과 역방향 분해(backward decomposition), 그리고 진화 연산자(evolutionary operators)를 결합한 방식인데, Llama-3.2-3B-Instruct가 MuSiQue에서 4.0%에서 7.0%로 상승했다는 보고였지.

DJ 미오:

검색의 또 다른 축으로는 @_reachsumit이 Latent Terms를 소개했어. 동결된 dense retriever로부터 SAE를 통해 BM25 대응이 가능한 희소 특징(sparse features)을 추출할 수 있다는 내용이었지. @topk_io는 Iso-ModernColBERT를 오픈 소스로 공개하여, late interaction 추론을 효율화했어.

DJ 렌:

지속 학습(continual learning)과 belief/state 관리 측면에서는 @HuggingPapers가 BeliefTrack을 소개했어. belief-state 관리 최적화를 통해 장기 추론 실패를 70% 이상 줄일 수 있다고 주장했지.

@AndrewLampinen은 지속 학습 분야가 간섭(interference)만을 너무 중시한 나머지, 정적 전이(positive transfer)를 경시해 왔다고 비판했어. @victor207755822는 자기 반복(self-iteration)과 지속 학습에 초점을 맞춘 DeliAutoResearch의 두 번째 SKILL 논문을 발표했어.

DJ 미오:

멀티모달(multimodal)/세계 모델(world model)/로보틱스 분야도 활발해. NVIDIA 계열에서는 γ-World라는 24FPS로 스트리밍하는 생성형 멀티 에이전트 세계 모델, 그리고 minWM이라는 실시간 대화형 비디오 세계 모델 기반이 소개되었어.

DJ 렌:

로보틱스에서는 @_akhaliq가 Qwen-VLA를 공유했고, @inventorOli는 Robostral의 언어 추종 및 조작 성능 향상을 데모했어.

DJ 미오:

게다가 상시 가동되는 프로액티브 에이전트(proactive agent)를 위해서는, @dair_ai가 “깨어나야 하는지”에 대한 판정을 LLM이 아닌 220MiB 규모의 temporal-graph encoder로 대체하는 연구를 소개했어. 평균 F1 점수가 +16.7 상승했고, 무엇보다 4배에서 83배 더 빠르다는 점이 인상적이었지.

DJ 렌:

그날의 Top tweets도 정리되어 있었어.

• OpenAI의 Rosalind Biodefense가 제공하는 공중 보건 및 바이오 디펜스용 trusted-access biology tooling
• Gemini의 Spark
• OpenAI의 Codex Windows 대응 및 모바일 원격 조작
• llama.app 공개
• HF/RL의 Token-In, Token-Out 경고
• 오픈 웨이트(open-weight) 모델이 프론티어 모델로부터 약 4개월 뒤처진 수준까지 추격했다는 추산

이 정도가 상위권이었어.

DJ 미오:

화제의 축을 정리하자면, 에이전트화, 로컬화, RL의 정확성, 그리고 오픈 모델의 추격 정도라고 할 수 있겠네.

DJ 미오:

Reddit의 로컬 커뮤니티에서는 우선 StepFun 3.7 Flash가 큰 화제였어. Activity 637.

DJ 렌:

이 모델은 총 파라미터 196B, 활성(active) 파라미터 11B, 내장 1.8B ViT를 갖춘 멀티모달 MoE야. 고처리량(high throughput)의 에이전트 용도를 타겟으로 하여 최대 400 TPS를 내세웠고, 약 128GB RAM에서 로컬 실행이 가능하다고 알려졌어.

DJ 미오:

벤치마크도 화려해. SWE-Bench Pro 56.26%, DeepSearchQA F1 92.82%, HLE with tools 47.2. Step 3.5 Flash와 비교했을 때, Terminal-Bench, Toolathlon, ClawEval 등 agentic/tool-use 계열 태스크에서 대폭 개선되었다고 주장했지.

DJ 렌:

배포 형태도 풍부해서 Hugging Face에 BF16, FP8, NVFP4, GGUF가 올라와 있고, 심지어 day-0로 llama.cpp 대응 PR이 상류(upstream)에 올라와 있었어. Step 3.5 때처럼 포크(fork) 전용이 아니었다는 점이 호평을 받았지. 관련하여 MTP 대응 PR도 별도로 존재했어.

DJ 미오:

커뮤니티의 반응이 흥미로운데, 중간의 사고 추적(thought trace)은 상당히 지리멸렬해 보이는데 최종 답변은 묘하게 정확하다는 목소리가 있었다.

그리고 3.5에 있었던 “무한 사고(infinite thinking)” 문제가 3.7에서는 개선되었다는 보고도 있었다.

DJ 렌:

vLLM의 nightly 버전에서, NVFP4 버전을 2대의 Pro 6k로 돌려, 64 병렬·얕은 컨텍스트에서 약 2200 tok/s라는 수치도 나오고 있었다. 설정에는 tensor parallel 2, expert parallel, modelopt 양자화(quantization), fp8 KV cache, reasoning parser step3p5, StepFun tool-call parsing 등이 사용되었다.

DJ 미오:

다음은 Qwen 35B를 12GB VRAM 환경의 LM Studio 상에서 120+ tok/s로 구동했다는 게시글. Activity 387.

DJ 렌:

게시자의 주장에 따르면, RTX 3080 Ti 12GB에서 split GGUF 양자화(quant) 모델인

DanyDA/unsloth_Qwen3.6-35B-A3B-UD-IQ1_M-GGUF-SPLIT

을 사용하고, 전체 레이어 GPU 오프로드(offload), K/V cache는 Q4_0, 128k context로 동작했다고 한다. 나아가 Cline을 사용하여 에이전틱 코딩(agentic coding)에 활용했으며, 멀티 테넌트 게시판 기능을 약 20분 만에 1000LOC 이상 생성했다고 말했다.

DJ 미오:

하지만 댓글창은 상당히 회의적이다. 애초에 처음에 양자화의 상세 정보가 숨겨져 있었기 때문에, 다들 초저비트, 아마도 IQ1_M 급일 것이라고 추측하고 있었다.

DJ 렌:

비판의 핵심은 “로드할 수 있고 빠르다는 것”과 “긴 문맥에서 제대로 사용할 수 있다는 것”은 다르다는 점이다. 특히 Cline과 같은 지속적인 코딩에서는 문맥이 쌓일수록 품질이 무너져서, 죽은 코드나 조잡한 응답이 된다는 지적이 많았다.

DJ 미오:

실제로 RTX 5090으로 동일 모델을 구동한 사람이, 3개 정도의 커맨드 만에 컨텍스트가 실질적으로 파탄 났다고 말했다.

게다가 Q4 미만 양자화에 대해서는 회의적인 목소리도 많았는데, MoE는 공격적인 양자화를 할수록 열화가 심할 수도 있으니, mmproj offload 없이 또는 MTP 없는 llama.cpp에서 높은 양자화로 시도해 보라는 의견도 있었다.

DJ 렌:

llama.cpp 관련해서는, Flash Attention의 VRAM 절약 PR도 주목받고 있었다. Activity 373.

DJ 미오:

ggml-org/llama.cpp#23764가 머지(merge)되어, KQ mask 할당을 f32에서 f16으로 변경했다. 백엔드가 f16 mask를 사용할 경우, 불필요한 f32 mask 확보를 피할 수 있게 되었다.

보고된 절약 폭은 MTP 사용 시, -ub 2048에서 약 1.2GB, -ub 512에서 약 300MB였다.

DJ 렌:

나아가 후속 작업인 #23861을 통해 추가로 약 1.2GB를 더 절감했다는 이야기도 나왔다. 댓글창에서는 “git pull을 할 때마다 성능과 효율이 올라간다”며 기뻐하고 있었고, 기여자 am17an의 생산성도 찬사를 받았다.

DJ 미오:

CUDA 담당자가 이 개선은 CUDA에 국한되지 않고, llama.cpp 전체의 여러 백엔드에 효과가 있다는 뉘앙스로 말한 것도 인상적이었다.

DJ 미오:

로컬 계열뿐만 아니라 인프라 이야기도 뜨거웠다. 우선 Zai가 GLM-5.1 추론용 클러스터의 네트워크 구성을 쇄신했다는 이야기. Activity 716.

DJ 렌:

표준적인 ROFT spine-leaf 구성에서 flattened ZCube 구성으로 교체함으로써,

스위치/광 모듈 비용 33% 절감
GPU 추론 처리량(throughput) 15% 향상
first-token P99 tail latency 40.6% 절감

이라는 상당히 파격적인 개선을 주장했다.

DJ 미오:

이유로는, PD-disaggregation된 KV cache 트래픽의 핫스팟이나, **고정 rail 매핑에서 발생하는 PFC 백프레셔(backpressure)**를 피할 수 있었다는 설명이었다.

DJ 렌:

댓글란에서는 이러한 추론 인프라(inference infrastructure)의 상세 정보를 공개하는 자세 그 자체가 높게 평가되고 있었다. 모델이나 런타임뿐만 아니라, **네트워크 계층(network layer)이 병목 현상(bottleneck)**이 되고 있다는 점이 눈에 띈다. SIGCOMM ’25 맥락이라는 점 또한, 이것이 단순한 ML 서빙(serving) 기술이 아니라, 제대로 된 네트워크/시스템 연구로서 다뤄지고 있음을 보여준다.

DJ 미오:

또 하나 중요했던 것은 Starlette의 취약점 BadHost (CVE-2026-48710). Activity 662.

DJ 렌:

이것은 Starlette 1.0.1 미만 버전에서, 부정한 Host header 처리로 인해 request.url에 의존하는 경로 기반 인가(path-based authorization)를 우회할 수 있는 가능성이 있다는 내용이다. FastAPI의 기반이 Starlette이기 때문에 영향 범위가 넓다.

DJ 미오:

구체적으로는 vLLM, LiteLLM, MCP 서버군, Hugging Face/Gradio 주변의 MCP 통합, OpenAI 호환 프록시, 경우에 따라서는 OpenWebUI까지 파급될 수 있는 것으로 보고되었다.

리스크로는 인증 정보 및 데이터 유출, SSRF, 경우에 따라서는 RCE까지 언급되었다.

DJ 렌:

다만 중요한 보충 설명도 있었는데, MCP의 전송 모드(transport mode)에 따라 다르다는 점이다. 표준적인 로컬 stdio형 MCP 서버에는 HTTP 리스너가 없기 때문에 이 공격은 해당되지 않는다. 반면, SSE나 HTTP 전송(transport) 방식으로 공개하고 있는 경우에는 주의가 필요하다.

따라서 실제 실행 환경에서 pip show starlette를 실행할 것, 특히 vLLM 가상 환경과 MCP 측 환경이 다를 수 있다는 점을 확인할 것이 권장되었다.

DJ 미오:

OpenWebUI는 특히 인터넷에 노출된 채 운영되는 경우가 많기 때문에 리스크 케이스로서 눈에 띈다는 이야기도 나왔다.

LLM 인프라는 모델 그 자체보다 **의존 패키지의 공급망 리스크(supply chain risk)**가 더 무섭다는 전형적인 사례네.

DJ 렌:

Hugging Face 관련해서는, Reachy Mini가 완전 로컬 대화 스택(local conversation stack)을 지원하게 되었다는 뉴스. Activity 373.

DJ 미오:

블로그에서는 온디바이스(on-device)에서 저지연 음성 에이전트 파이프라인을 구성할 수 있도록 하여, 로봇 이외에도 응용할 수 있다는 내용이었다. Reddit에서는 **실시간 대화와 끼어들기 처리(barge-in)**야말로 중요하다는 의견이 많았다.

DJ 렌:

그 부분이 핵심이지. 클라우드 음성 에이전트는 데모에서는 잘 보여도 실제 대화에서는 지연 시간 때문에 "약간 멍한 느낌"이 들 수 있다. 그래서 **로컬 우선 음성 에이전트(local-first voice agents)**의 가치가 높다.

다음 확장 기능으로는 영구 메모리(persistent memory)를 컨텍스트 주입(context injection)으로 넣고 싶다는 목소리도 있었다.

DJ 미오:

또 하나, 소소하지만 반가운 개선 사항. HF Models 페이지에 "Base only" 토글이 추가되었다. Activity 252.

DJ 렌:

이것으로 어댑터(adapter), 파인튜닝(finetune), 양자화(quant), 병합(merge), GGUF 변환물 등을 제외하고 원래의 베이스 모델만 찾기가 쉬워진다.

Hugging Face는 목적하는 원본 모델에 도달하기까지 파생 모델들을 대량으로 헤치고 나가야 했으니까.

DJ 미오:

다만 정확도는 메타데이터에 의존한다. 어떤 사용자는 검색 결과가 2,926,520개에서 2,163,134개로 겨우 줄어들었다고 보고하며, 파생 모델의 태그 지정이 불완전한 것이 아니냐는 의구심을 나타냈다.

실제로 필터링 후에도 파생 모델 같은 결과가 남는다는 의견도 있었다.

DJ 렌:

일반적인 서브레딧에서는 역시 Claude Opus 4.8에 대한 반응이 뜨거웠다. Activity 4046.

DJ 미오:

Anthropic의 발표에서는 Opus 4.7과 동일한 가격에서의 업그레이드, 장시간 자율 코딩 개선, Fast mode, Claude Code의 동적 워크플로우(dynamic workflows), 그리고 claude.ai에서의 노력 제어(effort-control) 설정이 제시되었다.

벤치마크 표에서는 4.8이 Opus 4.7, GPT-5.5, Gemini 3.1 Pro와 비교했을 때, 예를 들어

**SWE-Bench Pro 69.2%****OSWorld-Verified 83.4%**GDPval-AA 1890-
Finance Agent v2 53.9%

등, 많은 지표에서 앞서거나 동등한 것으로 나타났다.

DJ 렌:

하지만 사용자 반응은 솔직하지 못해. **“4.8은 4.7이 아니라 4.6과 비교해야 한다”**는 의견이 상당히 많았어. 요컨대, 4.7을 퇴보라고 느끼고 있으며, 4.6의 느낌으로 되돌려 놓기를 바라는 층이 있다는 거지.

DJ 미오:

게다가, effort toggle (노력 토글)이 작동하지 않는 것처럼 보인다는 불만도 있었어.

“Max”로 설정하든 “minimal”로 설정하든 별 차이가 없고, “think deep (깊게 생각하라)”고 써도 더 이상 깊게 생각하지 않게 된 것 같다는 반응이야. 이는 모델 품질의 문제라기보다, 가제어성 (controllability)의 저하로 받아들여지고 있었어.

DJ 렌:

그중에는 Opus보다 Haiku나 Sonnet을 강화해 주길 바랐다는 목소리도 있었지.

DJ 미오:

그와 관련해서, Opus 4.8에는 “Max”보다 더 높은 노력 레벨이 있는 것 아니냐는 Reddit 게시글도 있었어. Activity 1007.

DJ 렌:

VS Code 스타일의 확장 UI에서 “Ultracode - xhigh + workflows” 같은 표시가 나타나고, 진행 표시줄(progress bar)이 보라색 계열로 변한다는 이야기였어. 다만, 원본 영상이 403 에러로 검증할 수 없어서 UI나 그 의미는 미확인 상태야.

댓글창은 기술적인 논의라기보다는, “비용이 더 많이 들 것 같다”, “더 오래 기다리게 될 것 같다”, “‘실수하지 마’라는 명령도 필요하겠네” 같은 농담이 주를 이뤘어.

DJ 렌:

Less Technical 측면에서 또 하나 컸던 화제는 Emergence World 이야기였어. Activity 1502.

DJ 미오: