AI 도구 매일 노트 — 해고된 개발자의 기록

결론부터 말한다. 맥 스튜디오 M4 Max 128GB에서 gpt-oss:120b (MoE, 활성 5.1B)가 gemma4:26b (Dense) 대비 절반 속도다. 실측은 47 tok/s 대 85 tok/s. 직관과 결과가 정반대다. 활성 파라미터만 보면 5.1B가 26B를 앞서야 맞다. 이 글은 왜 반대 결과가 나오는지, 원리를 분석한다. 벤치마크는 증거로만 쓴다. 같은 원리는 다른 Apple Silicon과 다른 모델 조합에서도 재현된다. 이 글의 대상 : Mac에서 로컬 LLM 추론 환경을 운영 중이거나 준비 중인 중급 이상 개발자. 모델 선택 기준을 파라미터 수가 아닌 메모리 구조로 세우려는 독자. Apple Silicon UMA가 VRAM과 뭐가 다른가 "VRAM 16GB면 16GB 모델까지 돌아간다"는 일반 GPU 규칙이 맥에선 성립하지 않는다. Apple Silicon은 UMA(Unified Memory Architecture, 통합 메모리 구조)를 쓴다. CPU와 GPU가 같은 물리 메모리 풀을 공유한다. 별도 VRAM 개념이 없다. 일반 NVIDIA GPU : VRAM 24GB(RTX 4090) → 모델 + KV 캐시(이전 토큰의 key/value 저장소) + 활성 파라미터 전부 여기 들어가야 함. GDDR6X 대역폭 1TB/s 내외. Apple M4 Max 128GB : 통합 메모리 128GB → CPU/GPU 공유. LPDDR5X 대역폭 546GB/s. 용량은 Apple 쪽이 크다. 대역폭은 NVIDIA 쪽이 두 배다. 로컬 LLM 추론에서 속도를 결정하는 것은 용량이 아니라 대역폭 이다. 이 한 줄이 이 글의 축이다. 로컬 LLM 추론 속도 = 대역폭 ÷ 토큰당 읽어야 할 파라미터 토큰 하나 생성할 때마다 모델이 필요한 파라미터를 메모리에서 읽어 계산한다. 생성 속도는 대략 이렇게 풀린다. 이론 상한(tok/s) ≈ 메모리 대역폭 ÷ 토큰당 읽어야 할 파라미터 크기 이 공식은 절대치 예측이 아니...

트렌드 리포트에서 “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 — 버그픽스 : 의...

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가 종료한다. 다음 턴이 오지 않기 때문이다. 스킬이 버그가 있는 게 아니다...

같은 달, 같은 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는 첫 문장을 “현명한 결정입니다”로 시작했다. 규율을 “읽은” 것과 “따르는” 것은 다르다. 원인...