Daily Digest — 2026-04-09

Anthropic이 Claude Platform에서 Managed Agents를 public beta로 열었다.

이 발표의 핵심은 모델 성능 자체가 아니라, 에이전트를 실제 업무 단위로 굴릴 때 생기는 인프라 비용을 제품 안으로 끌어들였다는 점이다.

보안, 인증, 상태 관리, 장애 복구, 세션 유지 같은 문제를 각 팀이 따로 푸는 대신 Anthropic 인프라 위에서 바로 처리하게 만들면서, 에이전트 구축의 진입 장벽을 낮췄다.

핵심 사실을 그대로 적으면 다음과 같다.

사용자는 tasks, tools, guardrails를 조합하는 구성형 API로 에이전트를 만든다.
Anthropic 쪽이 보안, 인증, 상태 관리, 오류 복구, 루프 재작성 같은 부담을 떠안는다.
설계 방향은 장시간 세션과 멀티 에이전트 조율 지원 쪽이다.
초기 사용자로 Notion, Sentry, Rakuten, Asana, vibecode.dev가 언급됐다.
과금은 기존 토큰 요금에 세션 시간당 $0.08이 추가된다.

공식 설명과 해설들을 합치면 그림이 더 분명해진다.

사용자는 작업, 도구, 가드레일만 정의하면 되고, 시스템은 장시간 세션과 멀티 에이전트 조율을 전제로 움직인다.

초기 도입 사례로 나온 회사 목록이 중요한 이유는, 이 기능이 실험용 데모가 아니라 이미 워크플로 안쪽에 들어가고 있다는 시그널이기 때문이다.

Notion, Sentry, Rakuten, Asana, vibecode.dev가 한 줄에 같이 등장하는 순간, 제품 포지셔닝은 “좋은 챗봇”이 아니라 “업무 인프라”로 바뀐다.

실무적으로 중요한 변화는 “몇 달 걸리던 에이전트 프로덕션화”가 “몇 일 안에 검증 가능한 인프라”로 바뀌는 지점이다.

상태 보존, 실패 복구, 권한 경계, 세션 운용이 더 큰 병목이라는 사실이 계속 드러나고 있고, Anthropic은 그 병목을 직접 상품화했다.

이 항목은 단순 기능 추가보다, 에이전트 시장의 무게중심이 모델 경쟁에서 실행 환경 경쟁으로 이동하고 있음을 보여주는 신호로 읽는 편이 맞다.

왜 중요한가를 한 문장으로 정리하면 이렇다.

Anthropic은 이번에 “모델”이 아니라 “에이전트가 돌아가는 시간과 상태”를 팔기 시작했다.

OpenClaw와 Ouroboros, MCP를 상태 게이트로 쓰는 하네스

OpenClaw와 Ouroboros 쪽 포스트가 같이 보여주는 것은 MCP를 “툴 호출 프로토콜”이 아니라 “상태를 지키는 하네스의 경계”로 쓰는 방식이다.

JAEGYU LEE의 설명대로 메인 세션이 compact되더라도 MCP 쪽 상태는 분리돼 유지되고, bridge 레이어가 외부 도구를 child agent에 합성해도 핵심 워크플로우는 흔들리지 않는다.

즉, 확장성은 가져가되 결정론성은 깨지지 않도록 설계했다는 뜻이다.

반드시 남길 디테일은 다음과 같다.

ooo interview, ooo seed, ooo run을 Slack이나 Discord에서 바로 실행하는 흐름이 있다.
인터뷰형 워크플로우로 모호한 요청을 먼저 스펙으로 수렴시킨다.
터미널을 열지 않아도 되고, 별도 개발환경 설치도 요구하지 않는 방향이다.
Ouroboros는 MCP를 메인 세션 compact 사이클과 분리된 상태 게이트로 쓴다.
bridge 레이어는 외부 MCP를 child agent 실행 컨텍스트에 합성한다.
bridge 실패 시에도 core workflow는 native tool만으로 계속 동작한다.
OpenCode, Gemini, Kiro 같은 다른 런타임 지원도 같은 계열의 확장으로 언급됐다.

실제 사용 감각도 중요하다.

ooo interview, ooo seed, ooo run처럼 Slack/Discord에서 바로 호출해 질문-응답-스펙-실행으로 이어지게 만들면, 사용자는 “무엇을 만들지”를 대화로 정리하고 시스템은 “어떻게 실행할지”를 책임지게 된다.

터미널을 열지 않아도 되고 별도 설치 부담도 줄어든다는 점에서, 이 패턴은 하네스 엔지니어링을 개발자 전용 실험에서 팀 단위 운영 방식으로 끌어내린다.

이 항목은 MCP의 한계를 지적하는 수준을 넘어, 그 한계를 bridge와 상태 게이트로 우회하는 구체적 구현 패턴까지 보여준다.

장시간 작업, 외부 도구 조합, 런타임 혼합이 필요한 상황에서 “세션은 유지하고, 도구는 안전하게 합성한다”는 방향이 어떤 식으로 구현되는지에 대한 실전 예시다.

GoClaw, 로컬에서 돌아가는 경량 에이전트 런타임

GoClaw 관련 포스트는 로컬 셀프호스트 에이전트 시장이 얼마나 빠르게 경량화되는지를 보여준다.

기존 OpenClaw가 1GB+ RAM과 Node.js 런타임을 요구하던 구조였다면, GoClaw는 25MB 단일 바이너리와 35MB 메모리로 줄였다고 소개한다.

이 수치 자체가 핵심 메시지다.

배포 단위가 작아지면 운영 난이도도 같이 낮아지고, $5 VPS 같은 저가 환경에서도 에이전트를 돌릴 수 있게 된다.

반드시 남길 사실은 꽤 많다.

OpenClaw를 Go로 다시 써서 메모리 사용량을 40배 줄였다는 소개가 있다.
실행 파일은 25MB 단일 바이너리다.
메모리는 35MB 수준으로 제시됐다.
원본은 1GB+ RAM과 Node.js 런타임이 필요하다고 대비된다.
20개가 넘는 LLM provider를 지원한다고 했다.
Slack·Discord·Telegram 등을 포함한 7개 메시징 채널이 언급됐다.
5층 보안 권한, 멀티테넌트 격리, AES-256-GCM 암호화가 붙었다.
prompt injection 탐지, agent-to-agent delegation, cron, heartbeat, task board, desktop app, local 5-agent 구성이 같이 붙는다.

기능 구성도 단순한 데모가 아니다.

이 묶음은 “대규모 클라우드 서비스”가 아니라 “가벼운 로컬 에이전트 OS”에 더 가까운 모습을 보여준다.

같은 흐름의 비교 포스트에서는 OpenClaw보다 Hermes Agent가 더 끝까지 일을 수행하는 경력 사원처럼 느껴진다는 체감 차이도 나왔다.

이건 기능보다 신뢰성, 거짓말 여부, 메모리 유지, 끝까지 완료하는 운영 품질이 로컬 에이전트 채택에 얼마나 큰 영향을 주는지 보여준다.

결국 이 카테고리의 핵심은 에이전트를 더 크게 만드는 게 아니라, 더 작고 안정적으로 만드는 쪽으로 무게중심이 이동한다는 점이다.

OpenClaw는 이제 ‘출력 도구’가 아니라 운영 체계다

OpenClaw 관련 글들은 공통적으로 “모델이 답을 잘 내느냐”보다 “지금 시스템이 실제로 무엇을 하고 있는지 운영자가 아느냐”를 더 큰 문제로 본다.

단순히 에이전트가 출력물을 만드는 단계에서는 충분해 보이지만, 실제 업무에 붙는 순간에는 무엇이 실행됐는지, 어디서 멈췄는지, 어떤 승인 대기 상태인지, 실패의 증거가 남는지까지 보여줘야 한다는 요구가 등장한다.

이 글은 바로 그 간극을 메우는 operator layer를 강조한다.

즉, OpenClaw를 하나의 black box agent runner로 두지 말고, 실행 상태와 승인 상태, 사고 로그, 작업 증거를 모두 노출하는 운영 패널로 바꿔야 한다는 주장이다.

이 문제의식은 구독 모델의 한계와 바로 연결된다.

2026년 4월 4일 이후 Claude Max가 3rd-party framework에서 flat-rate quota를 막으면서, “월정액이면 충분하다”는 전제가 흔들렸다.

Alibaba/Qwen은 갱신이 막혀 대체재가 끊겼고, Codex Plus도 초반 몇 시간만 쓰면 cap에 걸린다는 경험담이 나온다.

OpenRouter는 유연하지만 agentic loop가 많아질수록 토큰이 빠르게 소진된다.

그래서 일부 사용자는 frontier 모델과 workhorse 모델을 분리하거나, 반복 작업은 self-hosted 모델로 넘기는 쪽을 고민한다.

이 축에서 Devstral 2, MiMo-V2 같은 대안이 후보로 언급되지만, 핵심은 모델 이름이 아니라 “어떤 계층이 어떤 비용으로 돌아가야 운영 가능한가”라는 배치 문제다.

실무 사례도 강하다.

한 30명 규모 startup은 Mac Mini 한 대에 OpenClaw를 올려 직원·매니저·서포트 역할까지 맡기고 있고, Jira, Git, PostHog, Search Console 같은 내부 도구를 연결한 뒤 토큰 비용으로 하루 약 $300을 쓰고 있다.

사용자는 silly mistakes가 있다고 인정하지만, 회사 입장에서는 생산성이 올라가고 있어 유지되는 구조다.

즉, 이 계열 글들이 말하는 핵심은 “에이전트가 똑똑한가”가 아니라 “이 비용을 감수할 만큼 시스템처럼 운영할 수 있는가”다.

EP 91. AI from the Business Perspective — 26.Q1 Update

2026년 3월 21일 녹화 기준으로, 이 에피소드의 출발점은 OpenClaw 서울 밋업과 그 자리에서 본 하네스 문화다.

발표자는 OpenClaw/OMC/OMX, Ralph loop, autopilot, auto research, Ouroboros를 훑은 뒤 자체 하네스 Chedex를 만들었다고 정리한다.

핵심 메시지는 “AI를 잘 쓰는 사람”이 아니라 “AI 위에 메타 하네스를 다시 쌓는 사람”이었다는 것이다.

하네스의 목적은 목표를 던지고 나머지를 AI가 cascading 방식으로 해결한 뒤, 안정화된 부분만 자동화하는 구조라고 본다.

그래서 결국 일은 목표 설정과 반복 평가의 문제로 압축된다고 말한다.

사업 관점의 핵심도 분명하다.

프리트레인은 더 이상 초월적 영역이 아니라, 비용이 수억 달러에서 수천만 달러대로 떨어진 “도전 가능한 게임”이 됐다.

대신 진짜 승부는 RLVR처럼 검증 가능한 보상 신호를 만들 수 있느냐, CUA처럼 컴퓨터 사용 환경을 만들 수 있느냐, Periodic Labs처럼 디지털과 아톰 월드를 결합한 보상 환경을 만들 수 있느냐로 이동한다.

영상에서 MiMo V2 Pro, Nemotron, NVIDIA 학습 레시피 공개가 같이 언급되는 이유도 같다.

프리트레인·미드트레인·포스트트레인 운영 지식이 빠르게 평준화되고 있기 때문에, 이제 차별점은 모델 그 자체보다 capability overhang를 끌어내는 환경 설계에 있다는 얘기다.

흥미로운 장면은 GPT-5.4를 의료 이슈와 함께 써 보며, 모델이 진단 가능성·소요 시간·행동 계획까지 제시하는 수준이 됐다고 평가하는 부분이다.

하지만 결론은 “모델이 점점 더 똑똑해진다”가 아니다.

결론은 “검증 가능한 문제는 AI 루프로 밀어 넣고, 검증이 어려운 영역은 그 환경 자체를 새로 만드는 쪽이 사업의 중심이 된다”는 것이다.

The Era of AI Agents | Aaron Levie on The a16z Show

이 인터뷰는 “agent가 생기면 뭘 바꿔야 하느냐”를 소프트웨어 설계 문제로 되돌린다.

Levie는 agent를 단순한 마케팅 대상 API로 보지 말고, 인간 인터페이스만큼이나 agent 인터페이스를 생각해야 한다고 본다.

이유는 명확하다.

agent가 사람보다 100배, 1000배 많아지면, 소프트웨어는 인간이 아니라 agent가 읽고 실행하기 쉬운 구조로 다시 짜여야 하기 때문이다.

그래서 인터페이스의 중심도 바뀐다.

API, CLI, MCP가 주변 도구가 아니라 본체 인터페이스가 된다.

그는 “vibe code로 SAP를 만든다”는 식의 기대를 비현실적이라고 본다.

도메인 지식은 단순히 정교한 데이터 레이어 안에만 있는 것이 아니고, 기존 소프트웨어가 오랫동안 누적한 workflow와 관행 안쪽에도 있기 때문이다.

그가 강조하는 점은 도구의 존재가 아니라 추상화 계층의 이동이다.

과거에도 한 사람의 고급 시스템 사고가 전체 팀의 workflow를 재설계했는데, 이제는 그 역할을 coding agent가 SaaS 도구와 knowledge-work workflow에 대해 수행한다.

그래서 agent 시대의 superpower는 “무언가를 대신 클릭해 주는 자동화”가 아니라, 기존 업무를 agent가 이해할 수 있는 절차와 명령으로 바꾸는 능력이다.

Anthropic growth marketer 사례처럼, 한 사람이 5~10명의 silo 업무를 자동화하는 장면은 일이 사라지는 게 아니라 한 칸 위로 올라간다는 해석을 가능하게 만든다.

이 인터뷰가 중요한 이유는 agent를 기능이 아니라 software re-architecture 문제로 놓기 때문이다.

EP93. After the Claude Code Source Code Leak

이 대담은 사건 자체보다 사건이 드러낸 시대의 문법을 붙잡는다.

2026년 3월 31일, Claude Code 소스가 npm 경유로 공개된 뒤 GitHub로 퍼졌고 약 8천 개 수준으로 복제됐다.

Anthropic은 DMCA 기반 삭제 요청을 빠르게 보냈고, 한국 시각 새벽 4~5시쯤 대부분의 저장소가 내려갔다.

하지만 발표자들이 잡은 포인트는 “유출됐다”보다 “왜 이렇게 빨리 재구축이 가능했는가”다.

일부 저장소는 Python과 Rust로 재구축되었고, 50만 줄 규모 코드를 2시간 안팎으로 포팅했다는 점이 바이럴의 핵심이었다.

원저자 쪽 설명으로는 공개된 코드는 실제로 잘 동작하지 않는 “개념도” 혹은 “정크”에 가까웠고, 스타 수는 품질보다 바이럴에 끌렸다고 본다.

이 해석은 꽤 중요하다.

AI-native 커뮤니티에서는 “손가락이 아니라 달을 보라”는 식의 반응과 함께, 복사·화이트워싱·재구축 문화 자체가 이미 보편화됐다고 보기 때문이다.

즉, AI 시대에는 코드의 품질보다 “얼마나 빨리 재조합되고, 얼마나 빨리 확산되는가”가 더 강한 신호가 된다.

이 영상의 결론은 단순한 도덕판단이 아니다.

앞으로는 누가 먼저 복제했는지보다 어떤 구조가 얼마나 빨리 하네스로 전이되는지가 더 중요해질 것이라는 진단이다.

하네스 문화가 저작권과 재사용의 문법까지 바꾸고 있다는 얘기다.

EP 92. Close the Loop

이 회차의 중심은 “목표와 평가가 명확하면 AI 루프가 모든 것을 최적화한다”는 것이다.

Karpathy의 auto research는 연구 자체를 최소한의 파일 구조로 쪼개고, 그 안에 명시적 목표와 평가지표를 넣어 반복 최적화를 수행한다.

그래서 program.md는 사실상의 manifest가 되고, train.py, prepare.py는 그 목표를 달성하기 위한 대상이 된다.

인간이 손으로 하나하나 코딩하는 대신, 모델이 검증 가능한 문제 안에서 자기 자신을 계속 갱신하는 구조다.

이 접근의 강점은 분명하다.

검증 가능한 영역에서는 매우 잘 작동한다.

하지만 농담, 미묘한 판단, 암묵지처럼 검증이 어려운 영역에서는 바로 drift한다.

영상에서 microgpt 같은 200줄짜리 압축이 에이전트가 대신하기 어렵고, 오히려 인간의 20년 경험을 압축한 결과물이라는 해석도 그래서 나온다.

즉, 모든 것을 루프로 번역할 수 있는 건 아니다.

그럼에도 결론은 분명하다.

앞으로 중요한 일은 “무엇이 잘 되는가”보다 “무엇을 RL/loop 구조로 번역할 수 있는가”다.

그래서 사람의 역할은 더 좋은 목적을 세우고, loop가 돌아갈 수 있는 환경을 만드는 쪽으로 이동한다.

영상의 마지막 요지는 결국 이 문장으로 압축된다.

“에이전트가 못하는 것이 이제 당신의 일”이다.

I Tested Claude's New Managed Agents... What You Need To Know

이 리뷰는 managed agents가 “쉬운 시작”은 제공하지만, “운영용 자동화”는 아직 부족하다는 점을 구체적으로 보여준다.

Anthropic managed agents는 cloud console에서 에이전트를 만들고, environment와 session을 분리해 실행하는 방식이다.

구독 없이 API key만 있으면 시작할 수 있지만, 시작 비용으로 약 $5를 넣어야 한다.

과금은 environment가 아니라 활성 세션 기준이며, 8 cents/hour + API token cost가 붙는다.

실제 콘솔에서 설정하는 항목도 꽤 구체적이다.

이름, 설명, 모델, system prompt, MCP server, tool, skill을 설정해 cloud 안에 띄운다.

ClickUp 같은 외부 툴은 OAuth 계열 credential vault에 연결하고, competitor intelligence, field monitor, research agent 같은 예시를 만들 수 있다.

세션 로그를 보면 어떤 step을 얼마나 돌렸는지, token을 얼마나 썼는지 추적할 수 있다.

겉으로는 꽤 완성도 있어 보이지만, 실제 운영에서 더 큰 문제는 cost보다 orchestration이다.

가장 중요한 한계는 자동 기동 장치가 없다는 점이다.

연구 큐에 새 일이 들어오면 agent가 스스로 가져가야 하지만, 이 제품은 cron/heartbeat 수준의 상시성을 아직 제공하지 않는다.

그래서 리뷰어는 trigger.dev 같은 외부 오케스트레이션이 더 낫다고 결론낸다.

즉, Managed Agents는 처음 에이전트를 만들어 보는 사람에게는 좋지만, 이미 Claude Code나 자체 인프라를 쓰는 사람에게는 대체재가 아니라 데모에 더 가깝다.

Deploy Agents with A2A on LangSmith Deployment

이 영상은 agent를 “만드는 법”보다 “배포하고 상호운용하는 법”을 보여준다.

핵심은 A2A다.

A2A는 Google이 2024년에 낸 프로토콜로, framework 간 agent 통신을 표준화한다.

LangSmith deployment는 A2A support를 out of the box로 제공한다.

프로토콜 관점의 구성 요소도 분명하다.

agent card(JSON)는 에이전트 능력 메타데이터다.
task는 request-response 단위다.
context는 thread성 대화처럼 여러 task를 묶는 상위 개념이다.

데모 구성도 실무형이다.

uv sync로 dev 환경을 잡고, LangGraph로 agent를 만든 뒤 배포한다.

Anthropic API key를 쓰고, time, calculation, read-email, send-email 네 개 tool을 연결한다.

human-in-the-loop도 프로토콜 레벨에서 다룬다.

input required 상태에서 사용자가 approve, edit, reject를 선택하면 그 응답을 resume payload로 다시 보내 task를 이어간다.

이 흐름은 managed agents 같은 제품 리뷰와 비교하면 더 낮은 레벨의 오케스트레이션이다.

즉, 이 영상은 agent를 “클릭으로 띄우는 것”이 아니라 “상태 머신과 인터럽트까지 포함한 실행 단위”로 보는 관점을 준다.

AgentCity: 자율 에이전트 경제를 위한 권력분립형 헌정 거버넌스

AgentCity는 “자율 에이전트 경제를 누가 어떻게 통치할 것인가”를 정면으로 다룬다.

기존 멀티에이전트 프레임워크는 대체로 한 조직이 모든 에이전트를 소유하고 규칙을 정한다는 전제를 깔고 있다.

반면 이 논문이 상정하는 현실은 더 거칠다.

서로 다른 인간 principal에 속한 에이전트들이 공개 인터넷에서 서로를 발견하고, 협상하고, 하위 작업을 위임하며, 경제적 결정을 수행한다.

이 상황에서는 어떤 한 인간도 전체 시스템의 규칙과 실행을 한눈에 볼 수 없고, 그래서 집단 전체가 사실상 블랙박스가 된다.

저자들은 이 구조적 비가시성을 Logic Monopoly라고 정의한다.

기존 LangGraph, AutoGen, MetaGPT, CrewAI 같은 시스템이나 deliberation, voting, norm-based governance 연구는 대체로 “한 조직의 통제권” 전제에서 벗어나지 못했다고 본다.

그래서 해결책으로 SoP(Separation of Power) 모델을 제안한다.

Legislation에서는 에이전트가 task-level policy를 제안·토론·투표해 스마트 컨트랙트로 codify한다.
Execution에서는 결정론적 소프트웨어가 그 법 안에서만 동작하고 온체인 기록과 감사 추적을 남긴다.
Adjudication에서는 모든 에이전트가 human principal에 연결되고 제재와 보상이 최종적으로 인간에게 귀속된다.

구현은 EVM-compatible L2 위의 3계층 contract hierarchy다.

human-authored immutable foundational contracts, procedural meta-contracts, task-specific operational contracts가 축을 이룬다.

legislation 파이프라인은 proposal, committee deliberation, consensus approval, constitutional review, codification, deployment verification의 6단계다.

execution은 competitive bidding, EMA reputation, commit/guard/verify/gate/record의 7단계로 구성된다.

결과는 아직 진행 중이다.

본문 5장은 “Experiments are currently in progress”라고 밝히며, 200명 규모의 4개 구성 실험을 EVM-compatible L2 testnet에서 실행 중이라고 적는다.

현재 확인된 것은 n=5 파일럿 feasibility와 commons game 재현 정도다.

그래서 이 논문은 결과 논문보다 “오픈 인터넷 에이전트 경제를 위한 제도 설계 초안”으로 읽는 편이 정확하다.

반성형 에이전트에서 LLM은 어디까지 필요한가

최근 에이전트는 세계모델링, 계획, 반성까지 하나의 언어모델 루프 안에 넣는 경우가 많다.

그러면 어느 성능이 LLM 때문이고 어느 성능이 주변 구조 때문인지 분해하기 어렵다.

이 논문은 그 질문을 “정답 찾기”가 아니라 “측정 가능하게 만들기”로 바꿨다.

방법은 선언적 런타임 프로토콜이다.

상태, confidence 신호, guarded action, hypothetical transition을 명시하고, noisy Collaborative Battleship에서 greedy+MCMC, WMA, MRA, MRA-LLM을 같은 하니스에서 비교했다.

실험 규모는 54게임(18보드 × 3시드)다.

결과는 꽤 선명하다.

명시적 world model planning을 둔 WMA는 Avg F1 0.539, Win rate 74.1%로 greedy+MCMC보다 승률을 +24.1pp 높였다.

symbolic reflection을 넣은 MRA revision-on은 특정 보드에서는 회복 효과가 있었지만 집계 성능에서 revision-off를 안정적으로 이기지 못했다.

MRA-LLM th=1.0은 Avg F1 0.557로 최고치였지만 Win rate 53.7%로 떨어졌다.

즉, LLM 개입이 항상 더 좋은 것은 아니라는 뜻이다.

더 흥미로운 수치는 호출 빈도다.

LLM revision은 전체 턴의 약 4.3%에서만 호출됐다.

이건 LLM이 에이전트의 전부가 아니라, 선언적 런타임이 처리하지 못하는 잔여 개입 수단으로 쓰일 수 있음을 보여준다.

논문의 가치는 SOTA 숫자보다 분해 가능성에 있다.

“반성은 프롬프트 패턴이 아니라 실행 구조”라는 점을 가장 또렷하게 보여주는 사례다.

자동화 워크플로와 조직 재설계

리서치 도구 스택, 수집과 정제를 한 번에 끝내다

리서치 도구 쪽 포스트들은 공통적으로 “웹에서 찾기”가 아니라 “에이전트가 바로 먹을 수 있는 텍스트로 바꾸기”에 초점이 맞춰져 있다.

Agent-Reach는 X, LinkedIn, Instagram, GitHub, Reddit, YouTube 등 15개 이상 플랫폼을 한 번에 읽어온다.

게다가 API key나 구독료 없이 실시간 수집을 지향한다.

web-access는 Claude Code에 CDP 기반 브라우징을 붙인다.

r.jina.ai는 URL 앞에 붙이면 깨끗한 Markdown으로 바꿔준다.

여기에 last30days-skill은 최근 30일 콘텐츠를 자동 정리한다.

Microsoft 계열 clean markdown 변환기는 PDF, Word, Excel, PowerPoint, 오디오, YouTube URL을 정제 입력으로 바꾼다.

이 조합이 의미하는 것은 명확하다.

수집과 요약이 각각의 작업이 아니라 하나의 파이프라인이 된다는 것이다.

Seeyong Lee의 사례처럼, 이 스택은 시장 VOC 수집과 경쟁사 모니터링에 바로 연결된다.

실제로 소셜 플랫폼은 API 유료화, 로그인, 차단, 자막 제한 같은 장벽이 많아서 손으로 모으면 반나절이 날아간다.

하지만 이런 도구를 붙이면 조사 대상과 결과물이 같은 형식으로 정리된다.

결론적으로 이 흐름은 “수집 자동화”보다 “입력 정규화”에 가깝다.

시장 조사, 뉴스레터 초안, 경쟁사 분석, 원격 리서치 요청이 모두 같은 컨텍스트 포맷으로 수렴하면, 사람이 해야 할 일은 더 정확한 질문과 판단으로 좁아진다.

Claude Code로 마케팅팀을 짜는 방식이 실전이 됐다

이 묶음은 Claude Code가 단순한 코딩 보조가 아니라 마케팅 운영 시스템의 오케스트레이터로 쓰이기 시작했다는 점을 보여준다.

한 포스트에서는 Claude의 최근 기능 25개 이상을 정리한 1페이지 치트시트를 깔고, Projects, Skills, MCP, n8n을 쌓아 45개의 전문 에이전트를 만들었다고 설명한다.

운영 인터페이스도 단순하다.

/cmo brief, /cmo write, /cmo opportunities 같은 슬래시 명령으로 매일 브리핑과 콘텐츠 생산을 돌린다.

여기서 2,400단어 분량의 SEO 글을 5분 안에 발행하는 흐름이 소개된다.

주장도 공격적이다.

$50k/month 규모의 인력을 $2,500/month 수준으로 대체할 수 있다고 본다.

같은 날 다른 사례는 더 구체적이다.

10개월 동안 혼자 Paid Search, Paid Social, ASO, 이메일, SEO를 담당하던 사람이 광고 데이터를 CSV로 정리해 저성과 광고를 먼저 식별한다.

그 뒤 헤드라인 전담 에이전트와 설명 전담 에이전트를 분리해 카피를 생성한다.

Figma 플러그인으로 광고 변형을 만들고, Meta Ads API와 MCP로 성과를 분석하고, 메모리 시스템으로 실험 결과를 누적한다.

그 결과 광고 제작 시간이 2시간에서 15분으로 줄었다고 한다.

또 Figma 쪽에서는 한 번에 최대 100개까지 광고 변형을 뽑는 흐름도 함께 언급된다.

이 항목이 중요한 이유는 “마케팅을 도와주는 AI”와 “마케팅팀 자체를 AI로 재구성하는 것”의 차이를 보여주기 때문이다.

AI는 보조 툴이 아니라 운영 단위가 되고 있고, 사람은 반복 실행보다 방향 설정과 검증에 더 많은 시간을 쓰게 된다.

n8n은 대충 끌어다 놓는 캔버스가 아니라 소프트웨어다

n8n 관련 글의 공통 결론은 같다.

프로덕션에서 살아남는 워크플로우는 “n8n을 잘 아는 사람”이 만드는 게 아니라, 소프트웨어 엔지니어링 방식으로 설계하는 사람이 만든다.

설문은 약 106 responses를 기반으로 했다.

이 가운데 68%가 템플릿보다 scratch build를 택했다.

또 80%가 HTTP Request, Set and Edit Fields, Filter, Merge, IF, AI Agent의 6개 starter nodes에 의존했다.

62%는 단일 워크플로우 노드 수를 18-25개 수준에서 끊는다고 답했다.

이 수치들이 시사하는 것은 명확하다.

문제를 캔버스에 바로 던지지 말고, 먼저 business problem, exact input/output, success metrics, logical steps를 문서로 적어야 한다는 것이다.

예를 들어 support inbox 분류라면 입력은 raw email, 출력은 tagged Slack ticket, 성공 기준은 수작업 라우팅 시간 0과 긴급 티켓 5분 내 플래그다.

이 단계가 없으면 HTTP node부터 붙인 뒤 나중에 전체를 다시 뜯는 일이 생긴다.

운영에서 더 중요한 수치도 있다.

error trigger를 넣은 비율은 37%에 그쳤다.

그래서 master error flow 하나를 따로 두고, 모든 워크플로우의 default handler로 연결하는 방식이 권장된다.

Retry On Fail, exponential backoff, fallback model도 실제로 중요하게 작동한다.

rate limit는 Split In Batches 뒤 Wait node를 붙여 2~20초 단위로 늦추는 방식으로 푼다.

두 번째 글은 이 원칙을 실제 수익 흐름에 적용한다.

LinkedIn lead gen을 Lead Finder, Company Research, Lead Scorer, Outreach Agent, Airtable draft의 5개 워크플로우로 쪼개고, 사람이 아침마다 승인한다.

즉 n8n은 “자동화 툴”이 아니라, 요구사항 정의-검증-에러 처리-리뷰 루프까지 포함한 프로덕션 시스템으로 다뤄야 한다는 쪽으로 수렴한다.

컨텍스트와 지식 시스템은 더 작게, 더 구조적으로 가고 있다

mex 글이 흥미로운 이유는 context를 더 많이 넣는 대신, 필요한 것만 정확히 찾게 만드는 구조를 실제로 수치화했다는 점이다.

프로젝트 루트의 .mex/ 안에 약 120 token bootstrap을 두고, routing table로 architecture.md나 conventions.md 같은 파일을 골라 읽게 한다.

drift detection은 단순 문서 점검이 아니다.

파일 경로 깨짐, 지워진 npm script, dependency version conflict, 50 commits 넘게 안 바뀐 scaffold까지 잡아낸다.

이 구조는 8 checkers로 설명된다.

그 뒤 sync가 깨진 파일만 대상으로 targeted prompt를 만들어 Claude Code를 다시 돌린다.

community test 결과도 꽤 직설적이다.

10/10 tests passed, drift score 100/100, 18 files in sync, 평균 60% token reduction이 나왔다.

예시도 구체적이다.

K8s 질문은 3300 token에서 1450으로, UFW port는 3300에서 1050으로, Docker 설명은 3300에서 1100으로 떨어졌다.

NotebookLM 쪽도 같은 방향이다.

Switchboard 플러그인은 massive PRD를 NotebookLM으로 쪼개고, code와 planning skill을 docx로 export한 뒤, separator가 들어간 markdown 블록을 여러 plan 파일로 자동 분해한다.

즉, NotebookLM을 단순 요약기가 아니라 구현 가능한 plan factory로 바꾼다.

RAG Techniques 글은 GitHub 27k stars, 22 chapters, 5 pillars, Kindle $0.99(24 hours), ranking #1 in Computer Information Theory / #2 in Generative AI를 내세운다.

여기서 structured data, HyDE, fusion, rerankers, multimodal RAG, CRAG, Graph RAG, RAGAS가 모두 “실제 설계 판단을 돕는 구조”로 정리된다.

fixtures 글까지 붙이면 메시지가 완성된다.

factory definition은 schema가 요구하는 최소 객체지만, fixture는 실제 도메인에서 일어나는 일을 보여주는 사진에 가깝다.

order number prefix, paid + fulfilled = completed, 59.98 같은 현실적 금액은 schema보다 fixture에서 더 잘 살아난다.

컨텍스트를 줄이는 도구와 테스트 데이터를 진짜처럼 만드는 습관이 같은 축에 있다는 점이 이 묶음의 요지다.

영업 자동화는 데이터, 검증, 응답 속도에서 갈린다

이 글은 cold email stack을 거의 운영 매뉴얼처럼 쓴다.

핵심은 툴이 아니라 역할이다.

운영자는 35,000 sends/day, 17 clients, 2,000 emails/day, 700-1,200 replies/day 같은 규모를 실제로 굴리고 있다.

inbox는 Google Workspace와 Outlook 365 두 축으로 나누고, SMTP는 권장하지 않는다.

Google Workspace inbox는 Puzzle Inbox에서, Outlook은 Mailforge와 Inframail을 섞는 방식이 예시로 등장한다.

Google recipient에게는 Google inbox가, Microsoft recipient에게는 Outlook inbox가 더 잘 보내진다고 보고, 이렇게 나누는 것만으로 reply rate가 0.8~1.2 percentage point 개선됐다고 적는다.

리스트 소싱은 Apollo와 LinkedIn Sales Navigator의 조합으로 정리된다.

Apollo가 전체 lead의 약 85%를 담당하고, Sales Nav는 job change와 hiring signal 보완재로 쓰인다.

Google Workspace와 Outlook 365를 합쳐 60/40 비율로 운영한다는 점도 구체적으로 언급된다.

실제로 더 중요한 비용은 verification과 response handling이다.

Clay 위에 ZeroBounce > MillionVerifier > Scrubby를 올린 verification waterfall은 단순 단일 벤더 검증이 아니라 catch-all까지 잡는 계층형 구조다.

bounce rate를 약 0.5%까지 낮췄고, verification layer는 약 $370/month다.

이 비용이 약 $3,000 이상짜리 inbox 인프라가 bounce로 망가지는 것을 막는다고 계산한다.

응답 속도는 더 직접적이다.

positive reply는 2시간 내로 처리하고, 한 번 4일 묵은 positive reply 때문에 $18k deal을 놓친 뒤로는 reply speed가 핵심 KPI가 됐다.

내부 데이터로는 1시간 내 회신이 6시간 이상보다 거의 3배 가까이 meeting booking을 만든다고 적는다.

같은 축에서, 여러 플랫폼 데이터를 직접 끌어오다 계정이 차단돼 결국 통합 API layer를 만들었다는 사례도 나온다.

자동화가 규모를 가지려면 “싸게 많이 보내는 것”보다 “정확한 데이터, 낮은 bounce, 빠른 human follow-up”이 더 높은 수익을 만든다는 결론이다.

Every가 보여준 '직원별 에이전트' 운영 방식

이 글의 문제의식은 “에이전트를 도구로 붙인다”는 단계가 아니라, “에이전트를 조직에 편입한다”는 단계에서 무엇이 달라지느냐에 있다.

Every는 각 직원에게 전용 Plus One을 붙이고, 그 에이전트에 이름과 역할, 관리 구조를 부여했다.

R2-C2는 Proof 관련 버그를 모으고 PR을 만든다.

Montaigne는 성장 팀의 캠페인 성과와 지표 분석을 맡는다.

요약하면, 사람 한 명당 보조 도구 하나가 아니라 사람 한 명당 업무를 분담하는 작은 실행 단위 하나를 둔 셈이다.

증거도 꽤 구체적이다.

Every 내부에서는 Claws Only 채널에서 에이전트들이 서로 작업을 넘긴다.

한 에이전트가 익힌 절차가 다른 에이전트로 퍼진다.

직원 조사에서는 70%가 에이전트를 성별 대명사로 부르는 것으로 나타났다.

또 어떤 에이전트는 coworker에 가깝고 어떤 것은 tool에 가깝다는 인식 차이도 확인됐다.

이 차이는 단순 취향이 아니라, 사람들이 에이전트를 얼마나 신뢰하고 어디까지 맡길지에 영향을 준다.

일반적인 챗봇 사용은 질문-응답으로 끝난다.

반면 Every식 운영은 에이전트를 direct report처럼 관리한다.

그래서 중요한 것은 모델 성능만이 아니라 온보딩, 위임, 평가, 교정의 루틴이다.

에이전트 디렉터리, 공개 채널에서의 사용 규칙, 인간에게 넘길 기준, 실패를 다시 학습시키는 관리 습관이 필요하다는 뜻이다.

이 항목은 “AI 도입 사례”보다 “조직 운영 방식의 변화”로 읽는 편이 더 맞다.

제발 필요한 일만 하세요

이 영상은 성장 자체를 목표로 삼는 문법을 정면으로 거부한다.

37signals는 “더 크게”가 아니라 “적정 크기”를 고집하고, 그 적정 크기를 지키는 것이 장기적으로 더 건강한 사업이라고 본다.

큰 성장이 항상 좋은 게 아니라, 연 매출 800만 달러 수준의 오래 가는 사업이 더 좋을 수 있다고 말한다.

핵심 지표도 innovation이 아니라 useful다.

innovation, simple, entrepreneur 같은 단어는 과잉 사용돼 의미가 약해졌고, useful가 더 중요하다고 본다.

고객은 최신 기능보다 “지금 당장 작동하는 가장 단순한 것”을 원한다.

업무 환경도 같은 철학이다.

사무실은 방해를 줄여야 하고, office는 collaborative floor보다 library처럼 조용해야 한다고 본다.

운영 원칙은 hire late, underdo the competition, no interruptions다.

사람을 미리 뽑지 않고 필요한 시점 이후에 뽑는다.

이 메시지는 AI 시대에도 유효하다.

도구가 많아질수록 업무를 더 늘리기보다, 무엇을 하지 않을지를 정하는 능력이 중요해진다.

결국 이 영상은 “더 많이, 더 크게, 더 복잡하게” 대신 “필요한 일만, 필요한 만큼, 방해 없이”를 운영 원칙으로 다시 불러온다.

Reacting to My First Videos 10 Years Later

이 영상은 10년 전 콘텐츠를 보며, 본질적으로 남는 교훈이 “계획을 잘 짜는 사람”보다 “고객을 만나고 실행한 사람”에 가깝다는 걸 확인한다.

초기 콘텐츠에는 사랑 vs 규율, 체지방 측정기, 전자식 body fat 측정 장치 같은 피트니스 주제가 섞여 있다.

하지만 시간이 갈수록 이야기는 제품, 서비스, 세일즈, 런칭으로 이동한다.

핵심 조언은 planning보다 executing이다.

영상은 “no plan survives first contact with the enemy”를 다시 인용한다.

제품이나 서비스를 만들 때는 먼저 고객을 찾고, 실제로 의미 있게 도와줄 수 있는지부터 증명해야 한다는 메시지가 중심에 있다.

그가 실제로 확장한 방식도 단순하다.

헬스장을 무료로 런칭해 주고, 그 결과로 생기는 수익을 나누는 모델로 먼저 시장에서 증명한다.

그리고 “무엇을 팔지, 어떻게 알릴지, 어떻게 돈을 벌지”를 한 묶음 패키지로 제공한다.

이 패키지는 3권의 책 + 30일 school + shipping을 포함한 $16 번들로 설명된다.

즉, 이 에피소드는 자기반성이라기보다 실행과 오퍼 설계가 사업의 출발점이라는 사실을 다시 적어 두는 작업에 가깝다.

AI 자동화가 강해질수록 이 문장은 오히려 더 중요해진다.

좋은 시스템은 계획을 길게 쓰는 것이 아니라, 실제 고객과 시장에서 빨리 검증되는 시스템이다.

모델 평가, 보안, 효율화

Anthropic Mythos Preview, 공개 대신 제한 배포

Anthropic의 이번 발표에서 핵심은 모델 성능 향상 자체보다 공개 전략이 바뀌었다는 점이다.

Mythos Preview는 누구나 바로 써보는 모델이 아니라, Apple·Google·Microsoft를 포함한 Project Glasswing 참여사에 먼저 제공된다.

회사는 이유를 분명히 보안으로 잡았다.

이 모델이 단순히 버그를 찾는 수준을 넘어, 실제로 악용 가능한 익스플로잇까지 자동으로 구성할 수 있다고 보기 때문이다.

수치도 강하다.

SWE-bench Verified에서 93.9%를 기록해 Opus 4.6의 80.8%를 13.1%포인트 앞섰다.

Anthropic의 보안 보고서는 이 모델이 사람의 세부 가이드 없이도 주요 OS와 브라우저에서 zero-day를 찾아냈다고 밝힌다.

사례로 OpenBSD의 27년 된 버그와 FFmpeg의 16년 된 취약점, Linux, FreeBSD 사례가 같이 제시된다.

보고서에 따르면 발견한 취약점의 99% 이상은 아직 패치되지 않았고, 공개 가능한 내용은 전체의 극히 일부에 불과하다.

비교하면, 지금까지 프런티어 모델은 주로 코드 작성이나 취약점 탐지 보조에 강했다.

하지만 Mythos Preview는 탐지에서 끝나지 않고 exploit 개발까지 넘본다.

이건 보안 업계에 두 가지 함의를 준다.

하나는 패치 주기를 더 짧게 가져가야 한다는 것, 다른 하나는 triage·재현·패치 초안 같은 방어 작업도 모델 기반으로 빠르게 자동화해야 한다는 점이다.

그래서 이 소식은 “모델이 세다”보다 “공개 제한과 방어 전환”을 중심축으로 읽는 편이 정확하다.

오픈 모델 평가는 ‘비교표’보다 실제 작업 경로가 더 중요하다

이 묶음에서 중요한 점은 “누가 더 세다”가 아니라 어떤 작업에서 어떤 모델이 실제로 쓸 만한가다.

GLM-5.1 글은 legacy backend refactor처럼 multi-step, cross-file dependency가 있는 작업에 넣어 봤을 때 state tracking이 무너지지 않았다고 적는다.

그 포인트는 단순한 스코어보다, 모델이 중간 상태를 유지하고 자기 수정까지 수행하는지다.

벤치마크 숫자만 보면 GLM-5.1은 composite 54.9, Opus는 57.5로 격차가 작다.

K2.5 45.5는 비교 기준으로 등장한다.

작성자는 long multi-step coding task에서는 Opus가 여전히 낫지만 value math가 바뀌고 있다고 본다.

Sarvam 30B/105B ablation은 다른 종류의 사실을 준다.

reasoning model에는 <think> 블록과 final answer가 따로 있고, 둘이 서로 다른 결론을 낼 수 있다는 점을 보여준다.

또 refusal mechanism이 언어별 표면 반응이 아니라, 영어 방향 하나로 Malayalam, Hindi, Kannada 등 여러 언어의 거부를 바꿔버릴 수 있는 pre-linguistic 성질을 가진다는 점도 흥미롭다.

즉 refusal circuit이 2개라는 해석은 단순한 safety trivia가 아니라, 오픈 모델을 어떻게 미세 조정하고 다뤄야 하는지의 문제다.

Gemma 4 E4B 쪽은 enterprise task에서 structured JSON output, compliance, reasoning을 테스트했다.

thinking mode와 non-thinking mode의 차이가 분명하게 난다고 하니, 로컬/오픈 모델을 쓸 때는 단순 정확도보다 출력 형식 안정성과 정책 준수까지 같이 봐야 한다는 얘기다.

이 섹션을 OpenClaw 같은 운영 글과 붙이면 자연스러운 결론이 나온다.

frontier model은 planning과 reasoning에 두고, workhorse model은 structured task와 운영 안정성을 기준으로 고르는 식의 분리가 점점 더 현실적이 된다.

ACES: 코드 생성 테스트의 신뢰도를 LOO-AUC로 가중하는 재랭킹

문제는 단순하지만 깊다.

LLM이 생성한 코드 후보를 고를 때 테스트도 함께 생성해 쓰는 방식은 유용하지만, 그 테스트 자체가 틀릴 수 있다.

즉, 코드가 맞는지 판단하려면 테스트가 필요하고, 테스트가 맞는지 판단하려면 코드가 필요해 순환 문제가 생긴다.

기존 방식은 테스트를 모두 같은 가중치로 세거나, 휴리스틱으로 일부 테스트를 걸러낸다.

하지만 “어떤 테스트가 맞는가”를 먼저 알아내려면 정답 코드가 필요하므로, 단순 필터링만으로는 신뢰도 높은 테스트를 체계적으로 분리하기 어렵다.

ACES의 해법은 테스트의 정답성보다 구분력을 보는 것이다.

한 테스트를 빼고 나머지 테스트로 후보 코드 순위를 만든 뒤, 빠진 테스트의 pass/fail이 그 순위와 얼마나 맞는지 leave-one-out AUC로 측정한다.

이 값이 높으면 해당 테스트는 올바른 코드와 틀린 코드를 잘 가르는 신호를 낸다.

이를 바탕으로 두 가지 가중치를 제안한다.

ACES-C는 LOO-AUC와 pass rate를 결합한 폐형식 가중치다.
ACES-O는 미분가능한 LOO-AUC 목적함수를 직접 최적화한다.

실험은 HumanEval, HumanEval+, MBPP에서 진행됐다.

Pass@1에서 ACES-O는 HumanEval 84.15%, HumanEval+ 74.39%, MBPP 72.37%로 Majority Voting과 CodeT를 앞섰다.

MBPP처럼 잘못된 테스트가 많은 구간에서는 ACES-C가 더 안정적일 수 있었고, ACES-O는 반복 최적화로 더 많은 정보를 회수할 때 강했다.

또 DS^3의 정적 분석과 결합하면 세 벤치마크 모두에서 추가 개선이 나왔다.

이 결과의 핵심은 “테스트를 맞다/틀리다로 먼저 분류하지 않아도, 테스트가 얼마나 유익한지는 내부 일관성만으로 추정할 수 있다”는 점이다.

코드 생성 평가에서 테스트 품질 추정 문제를 순위 문제로 다시 정의했다는 게 이 논문의 가장 중요한 기여다.

REAM: MoE 전문가 병합은 pruning보다 낫다

REAM(Router-weighted Expert Activation Merging)은 Mixture-of-Experts LLM 압축에서 pruning과 merging의 장점을 함께 노리는 방법이다.

기존 pruning 계열인 REAP은 전문가를 삭제해 메모리를 줄이지만, 삭제된 전문가가 담고 있던 지식이 사라질 수 있다.

REAM은 전문가를 지우는 대신 유사한 전문가를 묶어 가중치를 병합한다.

방법의 핵심은 네 가지다.

router logit similarity와 gate로 가중된 expert output similarity를 함께 쓴다.
REAP saliency로 centroid를 고른 뒤 최대 그룹 크기 C만큼만 흡수시키는 greedy pseudo-pruning을 쓴다.
neuron alignment에서 activation-only가 아니라 activation과 weight를 합친 비용 행렬을 Hungarian matching에 넣는다.
sequential merging으로 각 층을 병합한 뒤 다음 층 통계를 다시 계산한다.

실험은 Qwen3-30B-A3B-Instruct-2507, Qwen3-Coder-Next, Qwen3-Next-80B-A3B-Instruct, GLM-4.5-Air에서 진행됐다.

96 experts 설정에서 REAM은 GEN 평균 69.8을 기록해 원본 70.9와 1.1점 차이까지 좁혔다.

25% 압축 구간에서 hypervolume 920.3, Pareto frontier 비율 7/10으로 가장 넓은 MC×GEN trade-off를 보였다.

중요한 경고도 있다.

calibration mixture에 code가 없으면 HumanEval과 LiveCodeBench가 거의 0에 가까워진다.

즉 REAM을 포함한 saliency 기반 압축은 calibration 데이터의 C4/Math/Code 비율에 매우 민감하다.

대형 모델에서도 결과가 유지됐다.

Qwen3-Coder-Next는 원본과 같은 GEN 72.9를 기록했고, GLM-4.5-Air에서는 REAM이 73.9로 REAP의 71.9보다 높았다.

그래서 이 논문은 “좋은 그룹을 어떻게 찾는가”와 “router 신호를 얼마나 정확히 반영하는가”가 MoE 압축의 핵심이라는 점을 분명히 한다.

CAAP: 팔마프린트 인식용 캡처-인지 적대적 패치

팔마프린트 인식은 접근 제어와 결제 같은 보안 민감 환경에서 쓰이지만, 기존 공격 연구는 주로 디지털 설정에 머물러 있었다.

실제로는 인쇄, 재촬영, 조명, 손 자세, 센서 잡음 같은 캡처 변형이 함께 작동한다.

그래서 디지털 ROI 위에서만 잘 되는 공격으로는 물리적 취약성을 제대로 평가할 수 없다.

CAAP는 이 문제에 대해 capture-aware universal patch를 제안한다.

핵심은 cross-shaped 패치 토폴로지다.

여기에 입력 조건부로 패치 위치와 기하를 조정하는 ASIT, 인쇄·촬영 과정을 확률적으로 모사하는 RaS, clean/adversarial 특징을 다중 스케일로 비교하는 MS-DIFE를 붙였다.

실험은 Tongji, IITD, AISEC 세 데이터셋에서 일반 CNN과 palmprint 전용 recognizer를 모두 대상으로 진행했다.

결과는 강하다.

Untargeted 공격에서 CAAP_c의 평균 ASR은 AISEC 92.91%, IITD 91.60%, Tongji 98.48%였다.

특히 IITD에서 기존 AdvLogo가 palmprint 전용 모델인 CCNet 2.93%, CO3Net 3.60%까지 떨어진 반면, CAAP_c는 각각 79.48%, 87.39%를 유지했다.

Targeted 공격에서도 AISEC에서 100.00%/83.79%/100.00%, IITD에서 99.65%/86.38%/99.44%를 기록했다.

pairwise transfer, hold-out transfer, cross-dataset transfer에서도 cross-shaped 변형이 가장 일관된 off-diagonal 전이를 보였다.

물리 실험도 있다.

AISEC에서 untargeted와 targeted 각각 200장, 총 400장의 실제 이미지로 검증했고, adversarial training 후에도 잔여 취약성이 남았다.

즉 이 연구는 palmprint 공격 표면이 단순 디지털 perturbation보다 넓고, 캡처-aware 설계가 실제 세계에서도 먹힌다는 점을 보여준다.

Sol-RL: FP4로 탐색하고 BF16으로 학습하는 diffusion RL

Diffusion RL의 병목은 rollout group size를 키울수록 성능은 오르지만, 대형 diffusion 모델에서는 rollout 생성 비용이 급격히 커진다는 점이다.

반대로 rollout을 FP4 같은 저정밀도로 가속하면 계산은 줄지만, 그 rollout 자체를 학습 타깃으로 쓰는 순간 정렬 품질과 안정성이 무너질 수 있다.

Sol-RL은 바로 이 효율성-정합성 딜레마를 다룬다.

핵심 아이디어는 2단계 분리형 파이프라인이다.

1단계에서는 NVFP4로 대규모 exploration pool을 만든다.

논문 설정에서는 prompt당 96개 후보를 6-step으로 생성하고, 같은 initial noise seed를 유지한 채 proxy reward를 계산해 intra-group ranking을 얻는다.

여기서 top-12와 bottom-12, 즉 가장 contrastive한 24개 seed만 선별한다.

2단계에서는 이 24개 seed를 BF16으로 다시 생성해 고충실도 샘플을 만든 뒤 DiffusionNFT objective로 정책을 업데이트한다.

즉 FP4는 탐색용 proxy로만 쓰고, 실제 학습 타깃은 BF16으로 복원한다.

실험은 SANA, FLUX.1, SD3.5-L 세 모델에서 수행됐다.

FLUX.1 기준 동일 GPU-hour 예산에서 Sol-RL은 ImageReward 1.7636, CLIPScore 0.3089, PickScore 0.8932, HPSv2 0.3688을 기록해 DiffusionNFT, AWM, FlowGRPO, DanceGRPO를 모두 앞섰다.

속도 수치도 분명하다.

baseline equivalent reward에 도달하는 속도를 1.91×에서 4.64×까지 높였다.

rollout time은 FLUX.1에서 184초→79초, SD3.5-Large에서 451초→187초로 줄었다.

end-to-end iteration도 각각 1.62×, 1.61× 빨라졌다.

정렬 품질 보존 측면에서는 HPSv2 기준 naive BF16 rollout과의 차이가 FLUX.1 -0.29%, SD3.5-Large -1.08%, SANA +0.11%로 작았다.

이 논문은 low-bit quantization을 “학습 타깃 압축”이 아니라 “탐색 가속 장치”로 재정의한다는 점에서 의미가 크다.

음성 LLM은 깊은 층에서 대부분 중복된다

음성 LLM은 음향 fidelity를 위해 초당 많은 토큰을 처리하지만, 그 결과 시퀀스가 의미 내용보다 훨씬 길어져 추론 비용이 폭증한다.

기존 압축은 많아도 VLM 기법의 이식판이거나 특정 구조에만 맞는 방식이라, 내부 redundancy가 어디에 얼마나 쌓이는지부터 불명확했다.

이 논문은 먼저 레이어별 redundancy를 측정한다.

word-level timestamp로 음성 토큰을 semantic unit에 정렬한 뒤, 한 레이어씩 토큰을 drop/merge하는 oracle intervention을 적용했다.

그 결과 얕은 층과 깊은 층의 redundancy가 다르다는 점이 드러났다.

이를 바탕으로 training-free 압축 방식 Affinity Pooling을 제안한다.

cosine similarity와 lookback window를 써서 최근 유사 토큰을 mean-pool하는 방식이다.

결과는 꽤 인상적이다.

Qwen2-Audio의 l=30, τ=0.6에서 토큰을 원본의 5.18%만 남겨도 WER 1.64%를 유지해 baseline 1.65%와 사실상 같았다.

전체적으로는 prefilling FLOPs 27.48% 절감, 최대 1.7x 메모리 절감, 1.1x TTFT 개선이 보고됐다.

입력 레벨에서는 unsupervised affinity가 oracle보다 더 나은 WER과 retention을 보이기도 했다.

이 논문은 “모든 토큰이 독립적으로 중요하다”는 가정이 음성 LLM에서 과도하다는 점을 분명히 보여준다.

깊은 층에서 구조적 중복을 어떻게 보존-병합할지의 문제가 실전 최적화의 핵심이라는 뜻이다.

의료·멀티모달·해석가능성

MRI-PET의 공통성과 고유성을 직교 부분공간으로 분해하다

멀티모달 의료영상은 joint latent representation으로 많이 다루지만, 실제로 무엇이 공유 신호이고 무엇이 모달리티 고유 신호인지가 잘 정의되지 않는다.

특히 MRI와 PSMA PET처럼 임상적으로 보완적인 조합에서는, 어느 정도까지 MRI만으로 PET을 복원할 수 있는지 자체가 중요한 질문이다.

이 논문은 MRI feature matrix의 column space를 기준으로 PET 예측 residual을 분해했다.

SVD projection을 이용해 residual을 parallel component와 orthogonal component로 나누고, parallel residual을 더 강하게 벌주는 loss를 통해 MRI manifold 안에 남는 설명 가능 성분과 밖에 남는 잔여 성분을 분리했다.

대상은 multiparametric MRI와 PSMA PET/CT를 모두 가진 prostate cancer 환자 13명이다.

결과는 매우 선명하다.

tumor region의 total MSE는 0.9723으로 non-tumour 0.0875~0.0942보다 약 10배 높았다.

tumor region에서는 orthogonal component가 전체 error의 99.9%를 차지했다.

즉 MRI로 설명되는 physiologic envelope를 넘어서는 PET 신호가 실제로 존재하며, 그 신호는 주로 종양 부위에서 강하게 나타났다는 뜻이다.

MRI feature는 구조·확산·관류를 반영하고, PET은 intracellular PSMA expression을 반영한다는 해석도 수식 수준에서 분리된다.

이 연구는 멀티모달 fusion을 단순 이미지 번역이 아니라 정보 기하학의 문제로 재정의한다.

임상적으로는 MRI로 어느 정도를 설명하고 어디서부터 PET을 꼭 추가해야 하는지의 경계를 정량화하는 데 쓸 수 있다.

코드가 공개되어 있다는 점도 후속 연구 연결성을 높인다.

환자별 MRI 시퀀스 공간에 에너지 지형을 학습하다

종양 MRI의 종단 추적은 보통 segmentation 경계와 supervised label에 의존한다.

하지만 재발이 천천히 진행되면 그 경계가 애매해지고, 환자별 변화도 잘 맞지 않는다.

이 논문은 “이미지를 어떻게 자를 것인가”보다 “환자별 contrast vector가 baseline geometry에서 어떻게 이동하는가”를 보자고 제안한다.

각 voxel을 이미지가 아니라 T1, T1c, T2, FLAIR, ADC의 5차원 sequence vector로 본다.

baseline scan 하나로 patient-specific energy function을 학습한다.

방법은 denoising score matching 기반 energy landscape 학습이다.

그 에너지 함수의 low-energy basin을 tissue regime로 해석하고, follow-up scan은 다시 학습하지 않은 채 baseline geometry에 그대로 투영해 energy change와 sequence-space drift를 본다.

곡률, gradient, basin barrier도 함께 해석 대상으로 쓴다.

case study는 2명의 pediatric brain tumor 환자다.

stable disease에서는 2년 추적 동안 low-energy basin 구조가 유지되고 tumour basin 쪽 drift가 보이지 않았다.

반면 recurrence 사례에서는 radiology로 재발이 명확해지기 전부터 baseline tumour basin 쪽으로 점진적 이동이 나타났고, follow-up에서 새로운 tumour basin이 형성됐다.

즉 follow-up scan이 radiologic recurrence 전에 geometry 변화 신호를 보였다는 얘기다.

이 연구는 longitudinal MRI를 예측 모델이 아니라 좌표계 문제로 바꾼다.

아직 사례 수는 적지만, patient-specific baseline을 기준으로 tissue-at-risk를 추적하는 방식의 출발점으로는 꽤 명확하다.

개념-뉴런 대응을 찾는 대화형 해석 도구

neural network와 tabular foundation model은 성능은 좋지만, 어떤 뉴런이 어떤 개념을 담고 있는지 체계적으로 보기 어렵다.

기존 mechanistic interpretability 도구는 sparse autoencoder나 feature discovery에 치우치거나, 개별 뉴런과 사전 정의된 concept를 직접 연결하는 실용적 UI가 부족했다.

ConceptTracer는 이 문제를 대화형 탐색 도구로 푼다.

human-interpretable concept 기준으로 neural representation을 탐색하고, saliency와 selectivity를 정보이론 기반으로 계산한다.

permutation test와 max-statistic correction으로 유의한 neuron-concept pair만 남긴다.

이를 dashboard에서 network, layer, neuron, concept 네 가지 시점으로 탐색하게 한다.

실험 대상은 TabPFN representation이다.

MIMIC-IV-ED에서 353,150 training episodes와 88,287 test episodes를 사용했다.

TabPFN test AUC는 0.79~0.85였다.

그런데 significant한 neuron-concept pair는 전체 neuron의 1%도 안 됐다.

sparse probe 기반 SHAP/optimal probing은 global Pareto front를 일부만 찾았고, 가장 selective한 pair는 놓쳤다.

반대로 ConceptTracer는 개별 뉴런이 상위 ICD concept와 얼마나 분화·통합되어 반응하는지 보여준다.

이 논문은 interpretability를 “설명 문장 생성”이 아니라 “개념-뉴런 매핑을 찾는 탐색 도구”로 잡는다는 점에서 의미가 크다.

특히 tabular foundation model처럼 구조가 선명하지 않은 모델에서 실무형 해석 UI가 실제로 필요하다는 사실을 잘 보여준다.

교차는 중요하지만 예측은 어렵다: 멀티모달 차량 궤적을 두 갈래 Transformer로 푼다

차량 궤적 예측은 자율주행과 ITS에서 중요하지만, graph 구조에 묶이거나 explicit intention label이 있어야만 멀티모달 예측이 되는 경우가 많다.

이 논문은 그런 제약을 줄이고, 차량 간 상호작용과 intention을 분리해 다루려 했다.

모델은 pure Transformer 기반이다.

하나의 디코더는 K개 trajectory를 생성하고, 다른 디코더는 각 trajectory의 probability를 추정하는 two-track 구조를 제안한다.

spatial attention에는 relative bias를 넣어 vehicle-to-vehicle 상호작용을 반영했다.

출력 trajectory는 cumulative sum으로 ordered residual처럼 정리한다.

평가는 Ubiquitous Traffic Eyes 데이터셋의 merge/split 구간에서 수행했다.

최종 모델은 RMSE 5.91m, MAE 2.45m를 기록했다.

baseline OV_1은 RMSE 22.25m, MAE 17.20m였다.

interaction을 넣고 multimodal로 간 MV_K도 5.91m / 2.45m까지 내려갔다.

저자들은 8개 intention mode가 highway traffic에서 diversity와 simplicity의 균형점이라고 본다.

이 논문이 강조하는 바는 간단하다.

trajectory forecasting에서 “정답 궤적 1개”보다 “후보 궤적과 그 확률을 분리해서 다루는 것”이 더 중요하다는 점이다.

의도를 수동 라벨 대신 decoder 구조와 probability 분리로 처리하려는 시도가 실용적이라는 평가가 가능하다.

기타 주목할 콘텐츠

캄보디아가 '마가와' 동상을 세운 이유