리브의 아침 브리핑

01새로운 MCP 로드맵 - 앞으로 집중할 5가지 영역

다음 명세 릴리스와 그 이후 수개월 동안 MCP가 힘을 쏟을 곳을 다섯 개로 좁혔습니다. 이전 로드맵에서 장기 과제로 미뤄 뒀던 서버 주도 이벤트, Result Type 개선, Agent Identity가 구체화되면서 이번에는 핵심 우선순위로 올라왔습니다. Core Maintainer와 커뮤니티 Maintainer, Working Group이 함께 정리한 방향입니다.

• 작업이 오래 돌고 실행 중에 사람이 방향을 바꿔야 하는 상황이 늘어난 만큼, 이미 들어간 Tasks·subscriptions/listen·Progress Notification이 일관되게 맞물리도록 정리하고 클라이언트가 계속 Polling하지 않도록 Webhook·Channel 기반 서버 주도 이벤트를 추가합니다.
• 현재 Authorization은 사람이 브라우저에서 승인하는 대화형 사용을 전제로 설계돼 있어, 자체 신원을 가진 클라우드 에이전트와 더 좁은 권한을 위임받는 Subagent까지 담도록 DPoP·Workload Identity Federation·Token Exchange 같은 기존 표준 위에 Agent Identity를 정의합니다.
• 서버가 Tool 100개를 제공하면 사용자가 질문하기도 전에 모델이 전체 정의를 읽어야 하므로, 작은 진입점만 먼저 내주고 대화 범위가 좁아질수록 Tool Catalog를 추가로 공개하는 Progressive Discovery와 명확한 Tool Result 계약을 도입합니다.

blog.modelcontextprotocol.io · 관심사 최상 · 추천 상위 45.2%

02소프트웨어가 더 이상 느릴 이유는 없다

LLM이 느리고 비대한 코드를 만든다는 걱정과 달리, 지금 벌어지는 일은 원하는 성능 수준을 고를 수 있게 된 쪽에 가깝습니다. 과거에는 희소한 전문 기술을 가진 개인이나 팀이 필요했던 최적화를 이제 몇 문장의 지시로 시도할 수 있습니다. 모든 것을 어셈블리로 다시 쓸 단계는 아니지만, 대규모 고수익 프로젝트에만 타당했던 작업의 문턱이 내려갔습니다.

• FRE에 네이티브 AOT 컴파일을 붙이자 단순한 장시간 검색은 2-4배, AOT를 켤 만한 대표 홀드아웃 쿼리는 약 7% 빨라졌고, 여기에 들어간 사람의 시간은 몇 분에 불과했습니다.
• 게임 AI 지식 없이 만든 Azul AI가 기존 2위 대비 약 두 자릿수 배수로 적은 시간을 쓰고도 세계 최강 수준에 올랐는데, 승부를 가른 것은 AI 기법이 아니라 멀티스레딩 같은 구현 최적화였고 속도가 2배가 될 때마다 약 100 Elo를 얻었습니다.
• 다만 현재 모델은 실험 설계가 약해 벤치마크 환경은 사람이 마련해야 하고, ripgrep 개인 기록에 맞춘 최적화는 한 패스로 홀드아웃 2% 향상을 냈지만 데이터 분포가 바뀌면 과적합이 드러날 수 있습니다.

danluu.com · 관심사 상 · 추천 상위 50.9%

03Show GN: 중2개발자가 만든 한국어 LLM

파이썬 기본 문법과 Pandas·Matplotlib 정도를 공부하고 있는 중학교 2학년입니다. 개인 컴퓨터에서 이론상 돌아갈 만한 1.09B 파라미터 한국어 LLM 학습 파이프라인을 짜 봤습니다. 유료 툴이나 복잡한 에이전트 기능 없이 Claude·GPT·Gemini 무료 웹 창 세 개를 컨텍스트 제한이 걸릴 때마다 번갈아 쓰면서 만들었습니다.

• Llama 3 구조를 따라 RMSNorm, SwiGLU 피드포워드, RoPE를 PyTorch 레이어로 구현했고, 9GB 단일 GPU에 맞추려고 BF16 혼합 정밀도와 bitsandbytes 8비트 AdamW, 그래디언트 체크포인팅·누적을 적용했습니다.
• 학습 루프와 UI 스레드를 비동기로 분리해 matplotlib과 tkinter로 실시간 채팅 테스트가 되게 했고, 데이터셋 로드는 standard에서 streaming, force_redownload로 이어지는 자동 재시도 루틴으로 막았습니다.
• 발열과 메모리 부족이 터져 250스텝마다 time.sleep(5)를 걸어 GPU를 강제로 쉬게 하는 꼼수를 넣었고, 시간과 인프라가 없어 실제 프리트레이닝 완주와 가중치 추출까지는 못 갔습니다.

github.com/seoan1024 · 관심사 중 · 추천 상위 56.0%

04GPT-5.6 Sol 가격 20% 인하

GPT-5.6 Sol의 API 가격을 입력 20%, 출력 33% 내려 100만 토큰당 입력 4달러, 출력 20달러가 됐습니다. Cached Input은 100만 토큰당 0.40달러이고, 이번 프로모션 가격은 최소 2026년 11월 21일까지 유지될 예정입니다. gpt-5.6 alias도 Sol로 연결되는, GPT-5.6 계열의 Frontier 모델입니다.

• Context Window는 최대 1,050,000 토큰, 최대 출력은 128K로 장시간 코딩·리서치를 겨냥하지만, 입력이 272K를 넘으면 요청 전체에 입력 2배·출력 1.5배가 적용돼 대형 컨텍스트 비용이 다시 올라갑니다.
• reasoning_effort는 none·low·medium·high·xhigh·max를 지원하고 기본값은 medium이며, Responses API에서 Web Search, Code Interpreter, Hosted Shell, Apply Patch, Skills, MCP, Tool Search 등을 쓸 수 있습니다.
• Fine-tuning은 지원하지 않고 Knowledge Cutoff는 2026년 2월 16일이며, Cache Write는 일반 입력 가격의 1.25배로 과금됩니다.

developers.openai.com · 관심사 상 · 추천 상위 61.9%

05Anthropic, Claude Code의 추론 노력 수준 축소를 A/B 테스트하는 것으로 보임

Claude Code 2.1.236 이상의 일부 Fable 5 세션에서 추론 노력 척도가 낮아지는 서버 측 실험이 도는 것으로 보입니다. 앱이 아니라 서버에서 대상과 동작이 바뀌므로 같은 설정에서도 사용자마다 경험이 갈립니다. 이전 Claude Code 버전과 Opus 5는 대상에서 빠져 있고, 클라이언트 버전이 실험 등록 조건으로 쓰이는 것으로 파악됩니다.

• high를 골랐는데도 응답에 system<reasoning_effort>medium</reasoning_effort>이 계속 붙거나, Fable Medium 세션이 low reasoning으로 실행된다는 표시를 봤다는 보고가 나왔습니다.
• 최근 10일간 품질이 나빠진 상태에서 토큰 비용 400달러를 썼다며 높은 비용을 받고 낮은 추론 수준을 주는 것 아니냐는 비판이 있고, 변경 로그에 관련 내용이 없어 유료 설정의 의미가 달라졌는지 확인하기 어렵다는 지적이 이어집니다.
• 댓글에는 Claude Code 팀의 Thariq가 등장해 API 제공 설정을 배포 전에 시험하기도 하며 현재 진행 중인 시험에서 추론 노력 수치의 매핑이 달라진다고 밝혔습니다.

twitter.com/argofowl · 관심사 최상 · 추천 상위 80.4%

06[팟캐스트] OAuth, 제대로 이해하고 쓰고 있나요?

OAuth가 왜 필요한지부터 시작해 사용자, 클라이언트, 인가 서버, 자원 서버가 각각 무엇을 맡는지 짚습니다. Authorization Code Grant의 동작 과정을 따라가며 인가 코드와 액세스 토큰을 왜 분리하는지, Redirect URI와 Front/Back Channel이 무슨 역할인지 설명합니다. OAuth 2.1에서 중요해진 PKCE까지 이어집니다.

• 복잡해 보이는 절차마다 뒤에 숨은 보안적 이유가 따로 있다는 관점으로 흐름을 풀어 갑니다.
• 인가 코드와 액세스 토큰의 분리, Front Channel과 Back Channel의 구분이 설명의 축입니다.
• 댓글은 아직 없는 신규 에피소드입니다.

dalejule.com · 관심사 중 · 추천 상위 93.5%

07로컬 27B 모델에 리버스 엔지니어링을 맡겨 봤다

I gave Qwen 3.8 27B a reverse-engineering job and it finished in 30 minutes

Qwen 3.8 27B에 리버스 엔지니어링 작업을 던졌더니 30분 만에 끝냈다는 실사용 기록입니다. 프런티어 모델이 아니어도 이 정도 작업은 처리한다는 쪽에 무게가 실려 있습니다. 로컬에서 돌린 결과라는 점이 이 글의 값입니다.

• 키 복구 첫 시도는 서명 검증을 통과하는 키를 만들어 냈지만 바이너리가 계산하는 무결성 해시가 어긋났는데, 대부분의 모델이라면 여기서 완료로 선언했을 자리에서 불일치를 스스로 짚고 되짚어 갔다는 대목이 반응에서 가장 많이 인용됐습니다.
• 댓글에서는 어떤 도구를 썼고 하네스를 어떻게 구성했는지 더 알고 싶다는 요청이 이어졌고, 듀얼 Arc Pro B70에서 22 t/s 정도가 나온다는 실측 공유도 붙었습니다.
• 프런티어 모델이 로컬 모델용 입력과 스킬을 만들어 주고 실제 문제는 로컬 모델이 푸는 구도가 앞으로의 그림 아니겠냐는 의견도 나왔는데, 이건 기사 주장이 아니라 독자 쪽 전망입니다.

xda-developers.com · 관심사 최상 · 프런트 상위 35.8%

08프런티어 모델 18종에 nanoGPT 최적화를 시켜 봤다

NanoGPT Speedrun Frontier

프런티어 모델 18종으로 nanoGPT 옵티마이저 스피드런을 153회 자율 실행했습니다. 모델이 연구를 얼마나 수행할 수 있는지 재는 것이 목적이라고 밝히고 있습니다. 그래프는 모델별 최고 검증 결과를 보여 줍니다.

• 옵티마이저 스피드런이라는 과제가 '연구를 잘한다'와 어떻게 연결되는지 본문에서 충분히 설명되지 않는다는 불만이 댓글의 주된 갈래입니다.
• 비교 대상으로 Anthropic의 사내 자동 AI R&D 평가를 언급하는데, 그러면 그쪽을 따로 찾아봐야 하냐는 반응이 붙었습니다.
• 모델별로 최고 결과만 표시돼 있어 같은 모델의 실행 간 편차가 얼마나 되는지 궁금하다는 지적도 나왔습니다.

primeintellect.ai · 관심사 상 · 프런트 상위 44.2%

09하네스란 무엇인가

What Is a Harness?

LLM을 둘러싸고 실제 일을 하게 만드는 층을 하네스라고 부르는데, 그게 정확히 무엇인지 정리한 글입니다. 비전공자에게도 넘길 만큼 쉽게 썼다는 평이 먼저 붙었습니다. 2025년의 '에이전트'에 이어 2026년에 자리를 차지한 단어이기도 합니다.

• LLM이 전기라면 하네스는 전자기기라는 비유로, 모델 경쟁이 정리되고 나면 실제 값을 만드는 쪽은 하네스라는 의견이 반응 중 가장 많이 읽혔습니다.
• 확장 시스템의 완성도로 하네스를 고른다는 사용기가 붙었는데, 다른 하네스의 코드베이스를 파서 그 기능을 자기 하네스의 확장으로 옮겨 오게 시킨다는 사용 방식까지 나왔습니다.
• 에이전트로 마케팅되던 것 중 상당수가 실은 결정론적 소프트웨어였듯, 하네스도 같은 길을 갈 수 있다는 냉소도 함께 있습니다.

earendil.com · 관심사 최상 · 프런트 상위 87.8%