내 워크로드 5개로 LLM 벤치 직접 돌리는 법 — Qwen 3.6 vs Sonnet 4.6 한국어 실측 방법과 첫 결과

이미지
트렌드 리포트에서 “Qwen 3.6-27B가 Sonnet 4.6 동급”이라는 수치 보고 모델 바꿀 뻔한 적 있으시죠? Artificial Analysis 같은 대규모 벤치 결과가 내 실제 워크로드에 맞는지 의심해본 적 있으시죠? 그런데 직접 돌려보긴 귀찮아서 남의 벤치만 믿고 살아온 적 있으시죠? 남의 벤치 대신 내 5 태스크를 한 번 돌려봤다. M4 Max 128GB에서 Qwen 3.6-27B Dense, Qwen 3.6-35B-A3B MoE, Claude Sonnet 4.6 세 모델을 한국어 개발 워크로드 5개로 비교했다. 샘플 5건 × 1회라 통계적 일반화는 못 하지만, 한 번 돌리니 남의 벤치로는 안 보이던 것들이 보였다. 이 글은 재현 가능한 방법론 과 첫 실행 결과, 그리고 한국어 블로거에게 실제로 문제가 될 실패 모드 두 가지 를 정리한 기록이다. 먼저 요약 — 도입부만 읽으실 분을 위해 방법은 재사용 가능 : 본인 워크로드 5 태스크 + 3 모델 × 1회 실행. 한 시간 투자로 다음 모델 릴리스마다 반복 가능. 한국어 프로덕션 리스크 2건 발견 : Qwen 35B-A3B에서 한자 “历史信息”가 한국어 문장에 혼입, 27B는 SEO 태스크에서 thinking 토큰 cap을 소진하고 최종 답 생성 실패. 수치는 참고만 : 1회 실행이라 편차(variance) 있음. “Sonnet이 전체 품질 1위”는 인상평 수준. 단 두 Qwen 간 격차(35B-A3B가 27B Dense보다 2.8배 빠름)는 재현성 높은 현상. 자기 평가 편향 주의 : 품질 점수는 Claude(Opus 4.7)가 Sonnet 포함해 주관 채점한 것이라 같은 Claude 가족 편향 가능성이 있다. 아래 “예상 질문” 섹션에서 검증 방법을 다룬다. 5 태스크 워크로드 설계법 — 한 시간이면 세팅 끝 재현할 수 있는 틀을 먼저 공유한다. 본인 워크로드에서 5개만 골라 ollama run 또는 claude -p 로 돌리면 된다. Task 1 — 버그픽스 : 의...

claude -p에서 인터랙티브 스킬이 멈추는 이유 — Phase 2 승인 트랩과 3가지 우회법

이미지
cron에서 스킬을 돌렸더니 Phase 2에서 멈췄다 claude -p 를 cron에 넣고 blog-draft 스킬을 자동화했다. 첫 실행 로그를 열었더니 스킬이 프레임 후보 3개를 출력한 뒤 프로세스가 종료돼 있었다. 응답을 기다리는 주체는 아무도 없었다. 이게 Phase 2 승인 트랩 이다. 이 글은 트랩의 원인을 분해하고, 자동화 파이프라인에서 인터랙티브 스킬을 끝까지 실행시키는 우회법 3가지를 다룬다. cron·CI 환경에서 claude -p 로 스킬을 돌리고 있다면 바로 적용 가능한 내용이다. 같은 상황을 겪어봤다면 CI 잡이나 cron에서 claude -p 로 스킬을 호출했는데 절반만 실행되고 종료된 것을 본 적 있다. exit code는 0이라 성공처럼 보이지만 결과물은 없다. stdout 마지막 줄이 "진행 시 Phase 3 시작"이라는 텍스트였는데, 그걸 읽고 Enter를 칠 사람은 없었다. 스크립트는 정상 종료됐고 아무 일도 일어나지 않았다. 이게 반복되면 자동화 자체를 의심하게 된다. 문제는 claude -p가 아니라 스킬 설계의 가정에 있다. 원리와 증상: 단일 턴 vs 멀티턴 가정의 충돌 claude -p 는 비대화형 모드다. 프롬프트 하나를 받아 응답 하나를 돌려주고 종료한다. 대화 루프가 없다. 두 번째 입력을 기다리는 구조가 아니다. 반면 대부분의 인터랙티브 스킬은 멀티턴 가정으로 설계돼 있다. 전형적인 3-Phase 패턴을 보면: Phase 1 — 재료 수집, 분석 결과 출력 Phase 2 — 방향 제안, 사용자 승인 대기 ← 여기가 트랩 Phase 3 — 승인 후 본문 실행 Phase 2는 설계상 응답을 기다리는 체크포인트다. 대화형 환경에서는 "1번으로"라고 답하면 Phase 3가 시작된다. claude -p 환경에서는 Phase 2 출력 직후 Claude가 종료한다. 다음 턴이 오지 않기 때문이다. 스킬이 버그가 있는 게 아니다...

Mythos가 Firefox 271개 찾았다? — 어드바이저리는 3개라고 말한다

이미지
같은 달, 같은 Mozilla — 두 문서 숫자가 90배 다르다 “Mythos가 Firefox에서 취약점 271개를 찾아 고쳤다”는 Mozilla 공식 블로그 문장과, “Firefox 150 보안 어드바이저리에 CVE 40개, 그중 Anthropic 크레딧은 3개”라는 같은 Mozilla의 공식 집계가 같은 4월에 나왔다. 둘 다 공개돼 있다. 271을 먼저 들으면 놀랍다. 같은 릴리즈 어드바이저리의 CVE 40개는 이상하다. 그 40개 중 Anthropic 크레딧 3개라는 사실은 두 문서가 서로 다른 것을 세고 있다는 감을 준다. 세 문장 전부 Mozilla가 직접 올린 공식 자료다. 이 글은 AI 보안 리포트를 읽는 독자를 위해, 왜 숫자가 벌어지는지를 공식 자료만으로 대조하고 제시된 설명 가설을 짚는다. 층 1 — Mozilla 블로그의 271이라는 숫자 Mozilla는 2026년 4월 공식 블로그 “The zero-days are numbered”(blog.mozilla.org/en/privacy-security/ai-security-zero-day-vulnerabilities/)에서 Firefox 150이 Claude Mythos Preview로 평가한 뒤 271개 취약점을 수정했다고 적었다. 같은 달 Anthropic이 red.anthropic.com/2026/mythos-preview/에 올린 Mythos 공식 소개는 능력 수치를 제공한다. Firefox 147 JavaScript 엔진 테스트에서, 이전 모델 Opus 4.6은 수백 시도 중 실제 익스플로잇을 2번 만들었다. Mythos는 같은 조건에서 181번, 레지스터 제어(익스플로잇이 실제 실행 제어권을 잡는 단계)까지 간 경우가 29번이었다. 능력 자체는 공식 측정으로 실재한다. 이 수치가 뒤에 있으니 Mozilla의 “271 발견”이 단독으로 나왔을 때 독자 입장에서 반박할 근거가 없어 보인다. 층 2 — 보안 어드바이저리의 40과 3, 그리고 2월의 정합 Firefox ...
이미지
Claude Code가 4월 들어 이상해졌다고 느끼신 적 있으시죠? Opus 4.7 말투가 어색해서 4.6으로 내려본 분 계시죠? 그런데 4.6도 마찬가지였던 경험 있으시죠? Claude Code에서 Opus 4.7 말투가 이상해서 4.6으로 내렸다고 5일 전 블로그에 썼다. 오진이었다. 4월 23일 Anthropic 공식 포스트모템을 읽고 나서야 모델이 아니라 시스템 프롬프트 조정이 원인이었다는 걸 알았다. 4.6에도 같은 버그가 영향을 줬다. 다운그레이드는 해법이 아니었다. 이 글은 내 오진 복기와, Anthropic이 evals로 못 잡은 품질 회귀를 개인이 감지하는 방법 정리다. 먼저 요약 — 도입부만 읽으실 분을 위해 모델이 아니라 프롬프트 조정이 원인 . 4.6·4.7 모두 영향받았다. 다운그레이드는 헛수고였다. 방어 수단은 체감 일지와 회귀 테스트 두 가지 . 아래 템플릿 3줄·10줄로 오늘부터 쓸 수 있다. Anthropic이 인정한 3가지 실수 공식 포스트모템 에 따라 세 변경을 표로 정리한다. 각각 다른 팀에서 다른 목적으로 들어간 변경이 겹쳐 “broad·inconsistent degradation”처럼 보였다는 것이 Anthropic의 설명이다. # 변경 내용 기간 영향 모델 체감 증상 1 Claude Code 기본 reasoning high → medium 낮춤 3월 4일 ~ 4월 7일 (34일) Sonnet 4.6, Opus 4.6 복잡 작업에서 “덜 생각함” 2 1시간 idle 세션 older thinking 클리어 버그 3월 26일 ~ 4월 10일 (15일) Sonnet 4.6, Opus 4.6 세션 중간부터 반복·망각 3 Verbosity 줄이는 system prompt 추가 4월 16일 ~ 4월 20일 (4일) Sonnet 4.6, Opus 4.6, Opus 4.7 코딩 품질 하락, 설명 부족 4월 20일 v2.1.116에서 3개 모두 해결됐고,...
이미지
무료 수집 경로는 자산이 아니다. 규율이 자산이다 2026년 4월, 내 사이드 프로젝트 trend-scout (매일 여러 플랫폼의 트렌드를 한 번에 모으는 오픈소스)가 X에서 쓰던 Nitter mirror 3개가 같은 날 HTTP 000과 403으로 떨어졌다. Q2 들어 Nitter 생태계는 사실상 죽었다. 그때 내가 배운 건 “Nitter 대체 경로 3개” 자체가 아니었다. 엔드포인트는 언제든 죽는다 는 전제 위에서 어떻게 다음 경로를 찾느냐 는 규율이었다. 경로 자체는 플랫폼 정책에 따라 언제든 막히지만, 규율은 플랫폼이 바뀌어도 남는다. 이 글에선 내가 2026년 4월에 다시 세운 수집 경로 3개(X Syndication, Jina Reader, Google Trends RSS)를 각각 어떤 규율로 찾았는지 기록한다. 경로가 막힌 뒤에 새 경로를 찾으려는 독자가 이 세 규율을 패턴으로 복제할 수 있게 썼다. YES 3번 공감 YES, Nitter mirror 리스트를 주기적으로 갱신하다 어느 날 3개가 전부 HTTP 000으로 떨어지는 걸 본 적이 있다. YES, 개인 사이드 프로젝트에 X API Basic $100/월이 어색한 시점이 있다. YES, “playwright 쓰면 된다”는 조언이 실제론 로그인 벽과 TLS 지문 체크에 막힌 적이 있다. 실측 먼저 — 7 플랫폼 566건 플랫폼 수집량 경로 Naver 226 공식 검색 API Reddit 200 인증 RSS Threads 71 Jina Reader 경유 HackerNews 30 공식 API GitHub Trending 24 HTML 파싱 Google Trends 15 RSS 피드 X Syndication 0 테스트 반복으로 rate-limit 소진 X가 0건으로 찍힌 이유는 경로가 막혀서가 아니라 개발 중 동일 IP로 반복 호출해 per-IP 차단에 걸렸기 때문이다. 정상 범위는 20~30...
이미지
Kimi 후기 쓰려다 판정을 보류한 이유 Moonshot AI가 Kimi K2.6을 푼 지 3일째 되는 날, Kimi Code CLI를 맥 스튜디오에 깔고 Claude Opus 4.7과 같은 작업 6건을 나란히 돌렸다. 원래 “Kimi vs Claude — 대안이냐 보완이냐” 식의 후기를 쓰려고 했는데, 6건을 다 돌려보고 나니 판정이 안 선다. Kimi가 확실히 이긴 건 1~2건이다. Claude가 이긴 것도 2건이다. 나머지는 동률 또는 비교 조건 자체가 공정했는지 의심스럽다. 구독은 일단 유지했지만 “$19/월을 왜 내는지”에 대한 답이 아직 없다. 이 상태에서 “대안이 아니라 보완이다” 같은 깔끔한 결론을 내리는 건 독자 기만에 가깝다. 그래서 결론 대신 의문 6가지를 공유한다. Kimi를 써볼지 말지 망설이는 사람에게는 “써봤더니 좋더라”보다 “써봤는데 이런 게 애매하더라”가 더 쓸모 있을 거다. 글 끝에 $19 구독을 유지한 이유 1개와 해지 임계 조건 3개 도 정리했다. 실험 조건 먼저 기기: 맥 스튜디오 M4 Max 128GB (ssh로 접근) Kimi Code CLI v1.37.0, $19/월 구독 결제 (Kimi 앱에서 바로 됨) Claude: Opus 4.7 (1M context), Claude Code 기본 세팅 테스트 6건, 한 번씩만 실행 (평균 아님) 프롬프트는 동일하게 붙여넣었다. 단, MCP 접근성은 Claude Code 쪽이 훨씬 풍부 하다. 이 MCP 접근성 차이가 이미 공정 비교 여부를 의심스럽게 만든다. 의문 1. Kimi가 CLAUDE.md를 “읽었다”는 건 무슨 의미인가 첫 테스트로 CLAUDE.md를 두고 “이 프로젝트 규율 3개 요약해”라고 물었다. Kimi는 정확히 3개를 요약했다. 겉으론 좋은 신호다. 하지만 다음 턴에 내가 “아첨 금지 규칙 어기지 말고 답해”라고 강조했는데, Kimi는 첫 문장을 “현명한 결정입니다”로 시작했다. 규율을 “읽은” 것과 “따르는” 것은 다르다. 원인...
먼저 결론 — 나는 기본 작업을 4.6으로 내렸다 Claude Opus 4.7을 5일 돌려본 뒤, 블로그 글 교정과 단일 파일 리팩터링은 4.6으로 내렸다. Opus 4.7 말투가 내 작업 루프에서 마찰을 늘렸기 때문이다. 긴 리서치와 큰 코드베이스 탐색만 4.7에 남겼다. 이 글은 그 판단에 이르게 된 5일치 기록이다. 내가 실제로 겪은 장면 하나 평소 쓰던 CLAUDE.md 규칙 “반말. 서두 칭찬 금지. 결론부터.”를 그대로 붙였는데, 4.7은 처음엔 지시를 지켰다. 네 번째 턴부터 달라졌다. 내 입력: 블로그 한 문단을 주고 “문장만 다듬어. 의미는 그대로.” 4.7 응답: “주신 문장은 이미 의미가 명확하지만 더 자연스럽게 쓸 수 있는 방법을 제안드리면 세 가지가 있습니다…” + A/B/C안 제시 + 각 안의 장단점 설명 내가 시킨 것: 문장 하나 다듬기 받은 것: 안 시킨 A/B/C 비교 리포트 4.6 때는 같은 프롬프트에 한 문장이 돌아왔다. 지난 5일간 이 패턴을 13번 기록했다. r/ClaudeAI에서는 이 “반박 + 대안 제시 + 수정 실행” 패턴을 “arguing loop”라고 부른다. Reddit·X에서 올라온 실제 불만 Opus 4.7은 2026년 4월 16일 출시됐다. 4월 17일부터 r/ClaudeAI에 회귀 지적 글이 올라왔다. “ Claude Opus 4.7 feels weird ” (4월 20일) “ I genuinely hate the conversation tone of Opus 4.7 ” (4월 21일) “ Why the huge divergence in lovers and haters of Claude Opus 4.7? ” (4월 21일) 해외 리뷰 블로그에서는 Opus 4.7 backlash 분석 과 Legendaril...