데일리 트렌드
· 약 5분 읽기
[데일리 트렌드] 폰에서 도는 27B·Cursor 0day 전체 공개·LLM 심판의 편향 — 오늘의 개발·AI 소식 4가지
오늘 네 가지 소식은 출처도 분야도 다르지만, 같은 질문 하나로 모입니다 — “그 신뢰, 무엇으로 검증됐나요?” 폰에 들어온 27B 모델의 자체 벤치마크, 저장소를 여는 순간 코드가 실행되는 IDE, 점수를 조작할 수 있는 LLM 심판, 그리고 무너진 오픈소스 스타 지표까지. 각 항목은 사실을 짧게 밝히고, 한 줄 판단과 이번 주 확인할 일을 남깁니다.
오늘의 핵심
1. Bonsai 27B — “27B급 모델이 아이폰에서 돈다”는 발표
- 사실: 스타트업 PrismML이 Qwen3.6 27B를 기반으로 한 멀티모달 모델 Bonsai 27B를 Apache 2.0으로 공개했습니다. 가중치를 {−1, 0, +1}로 누른 터너리 버전(유효 1.71비트/가중치, 5.9GB)과 {−1, +1} 1비트 버전(3.9GB) 두 변형이며, iPhone 17 Pro Max에서 구동되고 M5 Max에서 87 tok/s, RTX 5090에서 163 tok/s, 262K 컨텍스트를 낸다고 합니다. 자체 15개 벤치마크 기준 원본 대비 터너리 95%·1비트 90% 성능 유지를 주장합니다. ⚠️ 이 수치는 회사 자체 평가이며 독립 검증은 아직 없습니다.
- 한 줄 판단: 물어야 할 것은 “폰에서 도는가”가 아니라 “1.7비트로 눌렀을 때 무엇이 깨졌는가”입니다. 벤치마크 평균 95%는 특정 태스크의 95%를 보장하지 않죠 — 지난주 다룬 양자화의 착시와 정확히 같은 구조입니다. 다만 온디바이스 추론 자체는 프라이버시·통신 비용 면에서 구조적 흐름(신호)으로 보며, 흐름은 믿되 수치는 검증 전까지 보류하는 게 맞다고 봅니다.
- 이번 주 할 일: 로컬 추론 수요가 있는 팀이라면 Apache 2.0으로 풀렸으니 실제 워크로드 하나를 골라 원본 Qwen3.6 27B와 나란히 돌려 보시길 권합니다. 다만 당장 온디바이스가 필요 없다면, 직접 검증에 드는 시간 대신 독립 벤치마크가 나올 때까지 기다리는 편이 경제적입니다.
2. Cursor 0day 전체 공개 — 저장소를 여는 것만으로 코드 실행
- 사실: 보안업체 Mindgard가 Cursor의 미패치 취약점을 7월 14일 전체 공개(full disclosure)했습니다. Windows 환경에서 저장소 루트에 악성
git.exe를 심어 두면, 피해자가 그 프로젝트를 Cursor로 여는 것만으로 사용자 권한으로 실행됩니다 — 클릭도 확인창도 없이요. 2025년 12월 제보 후 HackerOne에서 재현까지 확인됐지만, 이후 7개월간 197개 이상 버전이 릴리스되는 동안 벤더 응답이 없었고 CVE도 미배정이라는 게 Mindgard의 설명입니다. ⚠️ 타임라인·무대응 서술은 공개자 측 주장이며, Cursor 측 반론은 아직 없습니다. - 한 줄 판단: ‘저장소를 클론해서 연다’는 행위를 이미 코드 실행으로 간주하고 경계를 긋는 게 맞습니다. 돈·물리가 걸리면 작은 실수도 불허한다는 그럼의 편집 기준에서, 수백만 명이 쓰는 IDE의 무상호작용 실행은 딱 그 급이죠. 조율된 공개가 무산되면 전체 공개가 남은 보호 수단이 된다는 논쟁도 2000년대 초 full disclosure 운동에서 반복된 패턴 그대로입니다. 지난 npm 공급망 침해와 잇대어 보면, 이제 ‘저장소 자체’가 공급망의 공격면입니다.
- 이번 주 할 일: Windows에서 Cursor를 쓰신다면 출처가 불분명한 저장소는 VM이나 Windows Sandbox에서 여는 습관을, 조직이라면 워크스페이스 디렉터리의 실행 파일을 차단하는 정책(AppLocker류) 검토를 권합니다. 단, 실행 차단 정책은 정상적인 빌드 도구까지 걸리기 쉬워 예외 목록을 관리하는 운영 비용이 따라옵니다.
3. LLM 심판은 왜 불공정한가 — 편향의 내부 구조를 연 논문
- 사실: arXiv에 올라온 논문 “Inside the Unfair Judge”(Xu 외 7인)가 LLM-as-Judge의 편향을 입출력이 아니라 은닉 상태 수준에서 분석했습니다. judge 모델 7종·편향 유형 7가지·벤치마크 9개를 대상으로, 편향을 유발하는 입력이 모델 내부의 저차원 부분공간을 활성화하며, 그 방향으로 은닉 상태를 스티어링하면 점수를 양방향으로 조작할 수 있음을 보였습니다. 이 부분공간에 대한 단순 선형 프로젝션이 텍스트 기반 방법보다 judge의 실패를 더 잘 예측했다고 합니다.
- 한 줄 판단: LLM 평가자는 ‘대체로 공정한 채점기’가 아니라, 측정 가능하고 조작 가능한 편향 구조를 가진 부품입니다. AI도 역할·입출력·검증·복구 경계가 있어야 제품이라는 기준에서, judge를 검증 경계 없이 파이프라인의 최종 게이트로 두는 설계는 다시 봐야 합니다 — 이 글을 발행하는 그럼 역시 독립 AI 리뷰를 게이트로 쓰는 구조라 남 얘기가 아니고요. 스티어링으로 점수가 움직인다는 건, 평가 파이프라인이 새로운 공격면이 된다는 2차 효과까지 시사합니다.
- 이번 주 할 일: LLM 평가를 CI나 품질 게이트에 쓰고 계시다면, 단일 judge의 단일 점수 대신 서로 다른 계열의 judge 교차나 표본 사람 검수를 섞는 구성을 검토해 보시면 좋습니다. 다만 교차 검증은 평가 비용과 지연이 그만큼 늘어나는 선택이라, 결과가 돈·배포에 직결되는 게이트부터 좁게 적용하는 편이 낫습니다.
4. “오픈소스는 공짜”라는 착시 — 에이전트 시대의 청구서
- 사실: Thoughtworks의 Chris Ford와 Richard Gall이 7월 9일 공개한 글입니다. AI가 만든 저품질 PR이 유지보수자를 압도해 프로젝트가 문을 닫는 사례, 커밋 이력이 거의 없는 라이브러리가 몇 주 만에 1만 스타를 얻는 지표 붕괴, 2020년대 초 대비 급증한 공급망 위협을 근거로, 의존성의 ‘수동 소비’에서 ‘능동 소유’로의 전환과 기여·후원 예산의 공식화를 제안합니다.
- 한 줄 판단: 코드 생성이 풀리면 병목은 리뷰와 신뢰로 옮겨갑니다 — 에이전트가 코드를 공짜로 퍼 올릴수록 비싸지는 건 유지보수 노동이죠. 스타·다운로드 수는 더 이상 신호가 아니니, 의존성 감사의 기준을 ‘인기 지표’에서 ‘커밋 이력과 유지보수 체계’로 바꿀 때입니다. 느슨한 결합이 안정성이라는 기준에서 보면, 의존성도 방치된 결합이 아니라 관리되는 결합이어야 합니다.
- 이번 주 할 일: 핵심 의존성 목록에서 ‘스타는 많은데 활동 중인 유지보수자는 한 명’인 패키지가 있는지 한 번 훑어보시길 권합니다. 다만 감사에 쓰는 시간은 기능 개발에서 빼 오는 시간이므로, 결제·인증·배포처럼 사고 비용이 큰 급소부터 좁게 시작하는 게 현실적입니다.
그래서, 무엇이 바뀌나
네 소식을 관통하는 흐름은 신뢰의 근거가 지표에서 검증으로 옮겨가고 있다는 것입니다. 자체 벤치마크 95%(회사 주장), ‘IDE는 열기만 하면 안전’(깨짐), LLM 심판의 점수(조작 가능), 오픈소스 스타 수(붕괴) — 모두 어제까지 통하던 신뢰 지표가 오늘 시험대에 올랐죠. 공개된 기술사가 반복해 보여준 패턴이기도 합니다: 새 계층이 생기면 그 계층의 신뢰 지표가 먼저 오염되고, 검증 체계가 뒤따라 정착합니다(초기 웹의 방문자 수 부풀리기가 감사 가능한 지표로 대체된 것처럼요). 각자의 파이프라인에서 “이 신뢰는 무엇으로 검증됐나”를 한 번 묻는 것으로 충분한 한 주입니다.