오늘 네 가지 소식은 층은 다르지만 한 문장으로 모입니다 — “에이전트 스택이 통째 제품에서 부품 시장으로 쪼개지고 있다.” 프론티어급을 겨냥한 오픈웨이트 모델, 에이전트의 기억을 파는 도구, 에이전트가 쓸 컴퓨터를 시간당 몇 센트에 빌려주는 API, 그리고 봇 백엔드를 플랫폼 안으로 흡수하는 서버리스까지. 각 항목은 사실을 짧게 밝히고, 한 줄 판단과 이번 주 확인할 일을 남깁니다.

오늘의 핵심

1. Inkling — Thinking Machines의 975B 오픈웨이트 승부수

• 사실: Thinking Machines Lab이 7월 15일 오픈웨이트 모델 Inkling을 공개했습니다. 총 975B·활성 41B의 MoE(Mixture-of-Experts) 구조에 컨텍스트 최대 100만 토큰, 텍스트·이미지·오디오·비디오 45조 토큰으로 학습한 멀티모달이며, 가중치는 Hugging Face에 풀리고 자사 Tinker 플랫폼에서 파인튜닝을 지원합니다. 총 276B·활성 12B의 Inkling-Small도 프리뷰로 함께 나왔습니다. AIME 2026 97.1%, SWE-bench Verified 77.6% 등 벤치마크와 “동급 성능을 1/3 토큰으로” 같은 효율 주장이 실렸는데, ⚠️ 모두 자사 평가 수치로 독립 검증은 아직 없습니다.
• 한 줄 판단: “가중치가 공짜”와 “운영이 가능하다”는 전혀 다른 문장입니다. 활성 파라미터는 41B지만 975B 전체를 메모리에 올려야 서빙이 시작되죠 — 규모는 곧 난이도라는 그럼의 편집 기준에서, 이 모델의 실사용자는 대부분 셀프호스터가 아니라 호스팅 사업자일 거라고 봅니다. 오픈웨이트가 프론티어 ‘반 발 뒤’가 아니라 프론티어 자체를 겨냥하기 시작했다는 방향은 신호가 맞고, 수치는 어제 정리한 “그 신뢰, 무엇으로 검증됐나”의 기준대로 독립 벤치마크 전까지 보류가 맞습니다.
• 이번 주 할 일: 오픈웨이트 도입을 검토 중인 팀이라면 975B 본체보다 Inkling-Small(활성 12B)을 실제 워크로드 하나로 먼저 견줘 보시길 권합니다. 단, 셀프호스팅은 API 대비 모델 세대교체 속도를 포기하는 선택이라 컴플라이언스·데이터 주권 요구가 없다면 서두를 이유는 없습니다.

2. Telegram Serverless — 봇 백엔드가 플랫폼 안으로 들어간다

• 사실: Telegram이 봇·미니앱의 백엔드 코드를 자사 인프라의 V8 샌드박스에서 직접 실행하는 서버리스를 공식 문서로 공개했습니다. 로컬에서 JavaScript 모듈을 쓰고 npx tgcloud push 한 번으로 배포하며, Bot API 호출·SQLite 기반 DB·아웃바운드 HTTP가 기본 제공됩니다. 제약도 뚜렷합니다 — npm 패키지 사용 불가(SDK만), 파일 업로드·다운로드 미지원, SQLite 외래키 비활성, 응답은 텍스트 32MB까지. 가격은 문서에 아직 없습니다.
• 한 줄 판단: 배포 마찰을 없애 주는 대가로 락인을 최대치로 받는 구조이니, 편해질수록 경계를 그어 둬야 합니다. 이건 2010년대 위챗 미니프로그램이 보여준 것과 같은 수순이죠 — 플랫폼이 유통에 이어 실행 환경까지 흡수하면 개발은 쉬워지고 이탈은 어려워집니다. 느슨한 결합이 안정성이라는 기준에서 보면, 도메인 로직을 핸들러 밖 공유 모듈에 두고 플랫폼 API를 얇은 어댑터로 감싸는 게 이 편의를 안전하게 쓰는 방법입니다.
• 이번 주 할 일: 봇을 따로 서버 띄워 운영 중이라면 알림·프로토타입류 가벼운 것부터 옮겨 보며 제약(파일·패키지·DB)이 실제로 걸리는지 확인해 보시면 좋습니다. 단, 옮기는 만큼 관측·백업·버전 관리 같은 운영 도구를 플랫폼이 주는 것만 쓰게 되는 제약도 함께 받아들이는 셈입니다.

3. deja-vu — 코딩 에이전트의 세션 로그가 ‘기억’이 된다

• 사실: Claude Code·Codex CLI·opencode의 세션 로그를 로컬 역인덱스로 만들어 검색·재사용하게 하는 오픈소스 CLI deja-vu(MIT, Go)가 공개됐습니다. MCP recall 도구로 에이전트가 과거 해결 내역을 스스로 찾아 쓰고, 세션 시작 훅으로 관련 기억을 자동 주입할 수도 있습니다. 인덱싱 시점에 API 키·JWT 같은 시크릿을 제거하고, 네트워크 없이 완전 로컬로 돌며 SSH로 머신 간 동기화합니다. 3.3GB 로그 기준 검색 7~9ms를 제시합니다.
• 한 줄 판단: 버려지던 세션 로그가 자산으로 승격되는 건 맞는 방향이지만, 기억의 주입은 입력 경계에 새 검증 문제를 만듭니다. AI도 역할·입출력·검증·복구 경계가 있어야 제품이라는 기준에서, “그때 통했던 해법”이 지금은 틀린 해법일 수 있는데 자동 주입은 그걸 물을 기회 없이 컨텍스트에 밀어 넣죠. 시크릿 제거를 공유 시점이 아니라 인덱싱 시점에 하는 설계는 올바른 위치라고 봅니다 — 경계는 데이터가 태어나는 곳에 긋는 게 싸게 먹힙니다.
• 이번 주 할 일: 코딩 에이전트를 매일 쓰신다면 개인 머신에 설치해 일주일치 recall 품질을 겪어 보시길 권합니다. 단, 자동 컨텍스트 주입까지 켜면 토큰 비용과 낡은 해법이 끼어드는 오염 리스크를 같이 사는 것이니, 처음엔 수동 검색부터가 무난합니다.

4. Coasty — computer-use가 ‘스텝당 과금’ 인프라 상품이 되다

• 사실: YC S26의 Coasty가 computer-use 에이전트용 API를 공개했습니다. Linux·Windows VM을 자동 프로비저닝해 시간당 $0.05~0.09에 빌려주고, 자율 태스크는 스텝당 $0.05로 과금합니다. JSON DSL로 분기·루프·승인 게이트를 넣은 워크플로를 짤 수 있고, 기본 모델은 Claude Sonnet 4.6에 자체 키(BYOK)도 지원합니다. 눈에 띄는 건 결제 설계입니다 — 주요 작업 18개가 멱등키(Idempotency-Key)를 받고, 결제 불확실 시 환불 여부를 응답 헤더로 알립니다.
• 한 줄 판단: 이 API의 진짜 신호는 VM이 아니라 멱등키와 승인 게이트가 1급 기능이라는 점입니다. 자율 에이전트에 스텝 과금을 붙이면 청구서가 비결정적이 되는데, 돈이 오가는 시스템은 작은 실수도 불허한다는 편집 기준에서 이건 결제 시스템이 수십 년 전 겪은 문제의 재방송이죠 — 중복 실행 방지와 사람 승인 지점을 먼저 설계한 쪽이 살아남았습니다. computer-use가 데모에서 과금되는 인프라 상품으로 넘어가는 장면으로 읽습니다.
• 이번 주 할 일: 이런 관리형 에이전트 실행을 검토한다면 기능보다 예산 상한·승인 게이트·멱등 처리부터 표로 비교해 보시길 권합니다. 단, 관리형은 시작이 빠른 대신 사용량이 커지면 스텝 과금이 자체 인프라보다 비싸지는 지점이 오니 손익분기 계산은 미리 해 두는 편이 좋습니다.

그래서, 무엇이 바뀌나

네 소식을 관통하는 흐름은 에이전트 스택의 수직 분해입니다. 모델(오픈웨이트), 기억(로컬 인덱스), 실행 환경(관리형 VM), 배포 표면(플랫폼 서버리스)이 각각 따로 사고팔 수 있는 부품이 됐습니다. 공개된 기술사에서 반복된 패턴이죠 — 통합 제품이 지배하던 시장이 LAMP 스택처럼 계층별 부품으로 쪼개지면, 경쟁력은 부품 자체가 아니라 부품을 잇는 경계 설계로 옮겨갑니다. 에이전트도 마찬가지입니다. 어떤 모델이든 갈아 끼울 수 있게, 기억은 검증을 거쳐 주입되게, 실행은 예산과 승인 안에서 돌게 — 역할·입출력·검증·복구의 경계를 먼저 그린 팀이 이 부품 시장의 수혜자가 될 것으로 봅니다.

참고 / 출처

• Introducing Inkling (Thinking Machines Lab 공식, ⚠️ 벤치마크는 자체 평가)
• Telegram Serverless (Telegram 공식 문서)
• deja-vu — memory for coding agents (GitHub)
• Coasty API Documentation (공식 문서)