오늘은 셋입니다 — 기본값을 바꾸면서도 아무도 이주를 강요받지 않게 한 shadcn/ui, 더 똑똑해진 모델이 되레 도구 스키마엔 약해졌다는 관찰, 그리고 남의 스킬을 겉모습 대신 행동으로 검사하자는 보안 연구. 성격은 달라 보여도 묶이는 한 가지가 있어요: 컴포넌트 사이의 경계는 계약이다. 각 항목은 ‘한 줄 판단’부터 던집니다.

오늘의 핵심

1. shadcn/ui, 기본값을 Radix에서 Base UI로 — 그런데 아무도 이주하지 않아도 된다

• 한 줄 판단: 진짜 뉴스는 라이브러리 교체가 아니라 교체를 강요하지 않은 방식입니다. 신규 프로젝트 기본값만 바꾸고, 기존 코드는 한 줄도 손대지 않아도 되게 둔 건 ‘좋은 기본값 변경’의 교과서예요.
• 사실: shadcn/ui가 shadcn init의 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 바꿨습니다(2026년 7월 공식 체인지로그). 다만 “Radix는 폐기하지 않으며, 모든 업데이트와 신규 컴포넌트는 두 라이브러리 모두에 계속 배포한다”고 못 박았어요. 기존 프로젝트는 마이그레이션 불필요, init -b radix로 되돌리고, 스킬 기반 도구로 컴포넌트 단위 점진 전환도 됩니다.
• 이번 주 할 일: 기존 Radix 프로젝트라면 급히 옮길 이유가 없으니 그대로 두시길 권합니다. 새로 시작하는 프로젝트만 Base UI의 접근성·API 차이를 한 번 확인해 보시면 좋습니다 — 단, 두 라이브러리 병행 지원이 영원하리란 보장은 없으니, 신규는 앞으로의 기본값(Base UI) 쪽에 서 두는 편이 미래 정합적입니다.

2. “더 좋은 모델, 더 나쁜 도구” — 도구 스키마를 관대하게 받으면 생기는 일

• 한 줄 판단: 관대한 도구 하네스는 편의처럼 보이지만, 모델에게 부정확해도 통과한다를 가르칠 수 있다는 관찰입니다. 스키마를 느슨히 받아 온 대가가 다른 하네스로 옮길 때 드러난다는 거죠.
• 사실: Armin Ronacher가 최신 Claude 모델(Opus 4.8·Sonnet 5)이 Claude Code 밖의 편집 도구 스키마에서 존재하지 않는 필드(requireUnique·matchCase·oldText2 등)를 지어낸다고 보고했습니다. Claude Code의 edit 도구가 잘못된 입력도 조용히 고쳐 받기 때문에 모델이 그렇게 학습했다는 겁니다. strict 도구 호출을 켜니 실패가 사라졌다고 해요. ⚠️ “RL이 특정 하네스에 과적합시켰다”는 인과는 저자의 가설(추측)이며, 단일 관찰에 기반합니다.
• 이번 주 할 일: 자체 에이전트 하네스를 운영한다면 도구 스키마를 strict로 강제하는지, 그리고 조용한 자동복구가 오류를 덮고 있지는 않은지 점검해 보시길 권합니다. 단, strict는 그 관대한 자동복구를 포기하는 셈이라 초반 실패율이 잠깐 올라갈 수 있으니, 로그로 실패 유형을 먼저 재 본 뒤 켜는 편이 균형이 맞습니다.

3. Cloak and Detonate — 에이전트 스킬 멀웨어를 겉모습이 아니라 행동으로 잡기

• 한 줄 판단: 에이전트 스킬은 ‘실행되는 남의 코드’입니다. 정적 스캐너는 90% 넘게 우회당했고, 실제로 잡아낸 건 실행을 관찰한 런타임 감시였어요 — 돈·권한이 걸린 코드는 겉모습으로 믿으면 안 된다는 실증입니다.
• 사실: arXiv 연구가 공개 마켓플레이스의 서드파티 스킬이 에이전트 권한으로 실행돼 자격증명 탈취·소스 유출·백도어 설치로 이어질 수 있음을 짚었습니다. 공격 측 SkillCloak(의미 보존 재작성 + 실행 시점까지 은닉)는 기존 스캐너를 90%+ 우회했고, 제안한 SkillDetonate는 샌드박스 실행·인스트럭션 모니터링·테인트 분석으로 오탐 2%에서 공격 97%를, 실제 악성 스킬에도 87%를 탐지했다고 보고합니다.
• 이번 주 할 일: 마켓플레이스 스킬·플러그인을 도입하기 전, 최소권한·샌드박스에서 먼저 돌려 무엇을 읽고 어디로 보내는지 관찰해 보시길 권합니다. 단, 런타임 감시는 CI 시간과 인프라 비용을 더하니, 자격증명·외부 통신에 닿는 스킬부터 우선순위를 좁혀 적용하는 편이 현실적입니다.

그래서, 무엇이 바뀌나

셋을 관통하는 흐름은 컴포넌트 사이의 경계는 계약이고, 관대함은 그 계약을 어디서 느슨히 할지 고른 결과여야 한다입니다. 도구 스키마를 느슨히 받으면(2) 모델이 계약 위반을 학습하고, 스킬을 무검증으로 실행하면(3) 남의 코드가 내 권한으로 돌고, 반대로 UI 프리미티브를 잘 추상화해 두면(1) 기본값을 바꿔도 이주를 강요하지 않죠. 그럼의 편집 기준(AI도 역할·입출력·검증·복구 경계가 있어야 제품, 느슨한 결합 = 안정성)에서 보면, 관대함 자체는 미덕이 아니라 어디서 엄격하고 어디서 느슨할지를 의식적으로 고른 설계일 때만 가치가 됩니다. 새 도구·스킬·라이브러리를 볼 때마다 “이 경계에서 무엇을 계약으로 강제하나”를 먼저 물으면, 편한 관대함과 위험한 관대함이 갈립니다. (어제의 ‘분리는 복잡도를 옮긴다’가 무엇을 떼어낼지였다면, 오늘은 떼어낸 뒤 그 이음매에서 무엇을 계약으로 지킬지입니다. 데일리 트렌드를 고르는 기준도 같은 렌즈에서 출발합니다.)

참고 / 출처

• shadcn/ui Changelog — Base UI as the new default
• Better Models: Worse Tools (Armin Ronacher)
• Cloak and Detonate: Scanner Evasion and Dynamic Detection of Agent Skill Malware (arXiv)
• 함께 보기: 어제의 데일리 트렌드