매일 기록한 AI 기록

📚 AI 직원 회사 빌드기 — 4부작 시리즈 ① Mac Studio 128GB로 AI 직원 회사 만든 이유 ② 외부 부작용 통제 — Discord 승인 + launchd ③ claude -p 6-step 체이닝 — V3.5 + Phase 2 트랩 (현재 글) ④ 30시간 회고 — 토큰·막힌 5번·다음 6주 KPI (다음 주 발행 예정) 36분짜리 자동화가 Phase 2에서 멈춘다 claude -p 로 블로그 파이프라인을 체이닝하면 특정 단계에서 subprocess가 멈추고 stdout이 비어 돌아온다. returncode는 0이다. 에러 메시지도 없다. 타임아웃까지 그냥 블로킹된다. 이게 Phase 2 트랩이다. blog-draft 스킬이 프레임·제목 후보를 제안하고 “진행 시 Phase 3 시작”이라는 텍스트를 출력한 뒤, 사용자 승인을 기다린다. subprocess.run() 안에서 승인을 기다리면 타임아웃까지 블로킹되고, 결국 md 파일이 생성되지 않은 채 다음 단계로 못 넘어간다. 이 글은 V3 5-step 파이프라인이 V3.5 6-step으로 바뀐 설계 기록이다. 트랩이 왜 발생하는지 구조적으로 분석하고, 실제 코드 변경 3가지로 어떻게 우회했는지 정리한다. 이 신호가 보이면 Phase 2 트랩이다 다음 세 가지가 동시에 나오면 코드 버그가 아니라 트랩이다: Step 2( blog-draft )가 항상 딱 720초 에서 TimeoutExpired로 죽는다. 랜덤하게 실패하는 게 아니라 매번 정확히 timeout에서 죽는다. stdout tail을 보면 “프레임 + 제목 제안” 텍스트가 마지막이고, 그 뒤로 아무것도 없다. work_dir 에 md 파일이 없어서 _latest_md_in() 이 None 을 반환한다. 세 가지가 맞아떨어지는 이유는 스킬 설계 vs 비대화형 실행 환경의 불일치에 있다. 스킬은 대화형 세션을 전제로 만들어져 있고, claude -p subprocess는 st...

두 채점이 정반대 답을 냈다 같은 HTML 출력을 두 채점관에 넘겼다. 한쪽은 “1위”, 다른 쪽은 “4위”라고 답했다. M4 Max 128GB에 ollama로 깔린 로컬 LLM 5종에 같은 프롬프트를 던지고, 코드 구조와 시각 충실도라는 두 기준으로 잰 결과다. 배경은 aimaster3658이 Threads에 올린 13장 이다. Qwen 3.6 27b·35b 같은 로컬 모델에 자동차 시차 애니메이션 HTML 프롬프트를 던지고 결과 스크린샷을 비교한 글이다. 그 글이 사용한 채점 기준은 하나 — 시각 결과물. 시각 결과물이 중요한 작업(데모·UI·애니메이션)이면 그 기준이 옳다. 1년 뒤 고쳐 쓸 코드라면 다른 기준이 필요하다. AI 모델 평가는 채점 기준 선언이다 — 무엇을 얻고 무엇을 잃을지 먼저 정해야 한다 . 끝에서 그 선언을 만드는 5단계를 정리한다. TL;DR 채점 기준 선택이 평가의 본질이며 모델 순위는 그 부산물이다. 같은 출력을 devil(코드 기준)로 재면 gpt-oss 120b가 1위, 시각 기준이면 qwen 35b A3B가 1위. supergemma4는 두 기준 모두에서 0점으로, 출력 자체가 깨진 결과다. 본인 평가 기준을 만드는 5단계 절차는 본문 후반에 정리한다. M4 Max 128GB에 깔린 5종 ollama 0.20.7 기준 설치된 모델: 모델 Quant 크기 qwen3.6:27b Q4_K_M 17.4 GB qwen3.6:35b-a3b-q8_0 Q8_0 (MoE A3B) 38.7 GB gemma4:26b Q4_K_M 18.0 GB supergemma4:26b Q8_0 26.9 GB gpt-oss:120b MXFP4 65.4 GB 같은 프롬프트(Threads 원본 한국어 번역 그대로), num_ctx=16384 , num_predict=16384 , temperature=0.7 . ollama API 콜드 로드 후 첫 호출. 단일 시드 1회 측...

좋아서 한 번 쓴 SKILL.md, 다시 찾으려면 어디 있나? 이 질문에 답하려고 만든 게 vibe-writing 이다. 글쓰기 라이프사이클 — 초안·리뷰·다듬기·발행 — 을 위한 11개 스킬을 SKILL.md 포맷으로 묶어 OSS로 공개한 라이브러리다(저장소: github.com/jason-h23/vibe-writing ). 한 줄 결론 : 글쓰기 프롬프트는 휘발되지만 SKILL.md로 묶으면 자산이 된다. 단, 자산화에는 비용이 따른다. 이 글은 이미 프롬프트·스킬 10개 이상 누적해서 흩어진 자산을 정리해야 하는 사람 을 위한 것이다 — 처음 시작하는 사람에겐 별 의미 없다. 자산화의 두 갈래 — SDK vs SKILL 라이브러리 프롬프트를 자산으로 만들려면 두 갈래가 있다. (1) Anthropic SDK·OpenAI SDK 같은 코드 자산, (2) Claude Code의 SKILL.md 같은 마크다운 자산. 저자는 에이전트 스킬 vs SDK 글 에서 후자를 택한 이유를 정리한 적이 있다. 1인 운영자에게 SDK는 과한 인프라이고, SKILL은 즉시 합치고 분리할 수 있는 단위다. 결정적 신호 하나는 monarchjuno/vibe-investing 이었다. 13명 투자가 페르소나를 SKILL.md로 묶은 OSS가 12일 만에 77⭐를 받았다(출처: GitHub API, 2026-04-27 조회). 단, 이 ⭐가 실사용 입증인지 호기심 클릭인지는 아직 모른다 — 단일 사례로 보편 명제를 도출하기엔 이르다는 점은 인정한다. vibe-writing — 3 카테고리 11 스킬 카테고리 수 스킬 content-review 5 devil, simon-review, refine-to-9, ai-cliche-check, writing-review-pipeline content-production 4 blog-draft, blog-thumbnail, blog-topic-dedup, humanize-korean meta ...

📚 AI 직원 회사 빌드기 — 4부작 시리즈 ① Mac Studio 128GB로 AI 직원 회사 만든 이유 ② 외부 부작용 통제 — Discord 승인 + launchd (현재 글) ③ claude -p 6-step 체이닝 — V3.5 + Phase 2 트랩 (이번 주 발행 예정) ④ 30시간 회고 — 토큰·막힌 5번·다음 6주 KPI (다음 주 발행 예정) AI 자동화 시스템을 처음 설계할 때 대부분 이렇게 생각한다. 코드만 잘 짜면 된다고. 테스트 커버리지를 높이고, 에러 핸들링을 꼼꼼히 하고, 엣지 케이스를 처리하면 안전하다고. 그런데 실제로 자동화 시스템을 운영해보면, 가장 무서운 실패는 코드 버그가 아닌 곳에서 온다. 이런 경험, 한 번쯤 있을 것이다 프로덕션에서 자동화 스크립트가 예상보다 훨씬 많이 실행된 걸 뒤늦게 발견한 적 있다. 외부 API를 수십 번 호출해버렸거나, 콘텐츠가 승인 전에 발행됐거나, “이 정도면 안전하겠지”하고 켜뒀다가 당황한 경험 말이다. 자동화를 끄는 것이 켜는 것보다 훨씬 어렵다는 것도 안다. 무엇을 멈춰야 하는지, 비상 정지 버튼이 어디 있는지 불명확한 시스템은 문제가 생겼을 때 더 큰 문제를 만든다. 이 글은 그 불안감의 정체와, 코드 이전에 설계해야 할 것이 무엇인지에 관한 것이다. 코드 품질은 필요조건이지 충분조건이 아니다 AI 에이전트가 자동으로 블로그 주제를 제안하고, QA를 거쳐 Discord 카드로 승인 요청을 보내는 시스템을 구축했다. 65개 이상의 유닛 테스트가 전부 통과했다. 드라이런도 end-to-end 정상 작동했다. 그런데 이 상태에서 “이제 켜도 됩니까?”라는 질문에 바로 “예”라고 답할 수 있는가? 코드 품질은 필요조건이다. 하지만 자동화 시스템의 안전성은 다른 차원의 문제다. 코드가 의도대로 동작하는 것과, 자동화가 의도한 결과를 만드는 것 사이에는 간극이 있다. 그 간극을 메우는 게 통제권 설계다. 자동화 시스템의 진짜 위험은 두 가지다. ...

supergemma4를 strict JSON 1순위에서 뺐다. M4 Max 128GB에 ollama로 5종을 4시간 돌린 결정이다. 빠르다는 평판은 형식 오염 앞에서 무력했다. 응답 앞에 JSON: 프리픽스가 붙고 중간에 <channel|> 태그가 들어가니 파서가 깨진다. 같은 워크로드에서 gemma4:26b는 10.7초로 형식을 지켰다. 각 측정은 1회씩이다. 다시 돌리면 결과가 달라질 수 있다. 그래서 1순위/2순위 대체 구조를 뒀다. TL;DR supergemma4를 strict JSON·한국어 1순위에서 뺐다 (형식 오염) gemma4:26b가 한국어·정형 출력 1순위로 승격 gpt-oss:120b가 추론 24.1초로 qwen3.6:35b(33.9초)보다 빨랐다 시작점 M4 Max에 ollama 모델을 8개 올려놨는데 어떤 작업에 어떤 모델을 써야 할지 매번 헤맨다. “빠른 모델”이라는 평판만 듣고 supergemma4를 골랐다가 출력이 깨진다. 35B 모델보다 120B 모델이 더 빠르다는 결과를 본다. 세 번 다 내 케이스다. 4 워크로드를 정해서 5종을 돌렸다. 모델 크기 qwen3.6:27b 27B Dense qwen3.6:35b-a3b-q8_0 35B MoE A3B gemma4:26b 26B Dense supergemma4:26b 26B 파인튜닝 gpt-oss:120b 120B Sparse MoE 검색용 임베딩 3종(nomic-embed-text, qwen3-embedding:4b, openai/text-embedding-3-small)은 별도 분리. 워크로드 4개: Strict JSON 분류 (포맷 준수) 한국어 재작성 3문단 (언어 품질) 디버깅 off-by-one 버그 (코드 추론) 다리 건너기 단계 계획 (논리 추론) 같은 프롬프트, 같은 시스템 프롬프트, ollama 콜드 로드 후 두 번째 호출 기준. supergemma4를 1순위...

📚 AI 직원 회사 빌드기 — 4부작 시리즈 ① Mac Studio 128GB로 AI 직원 회사 만든 이유 (현재 글) ② 외부 부작용 통제 — Discord 승인 + launchd ③ claude -p 6-step 체이닝 — V3.5 + Phase 2 트랩 ④ 30시간 회고 — 토큰·막힌 5번·다음 6주 KPI Mac Studio를 켜놓고 자도 되는가 Mac Studio 128GB를 켜놓고 자도 되는가. 구입 후 며칠이 지나서야 이 질문이 처음 떠올랐다. 전기요금이 걱정된 게 아니었다. 이 기계가 실제로 뭔가를 만들어내고 있는가 — 라는 질문이었다. 개발자라면 이런 상황을 한 번쯤 겪었을 것이다. 서버를 켜두고 ssh만 가끔 접속하는 걸 "활용 중"이라 부르는 상황 로컬 LLM 148GB를 다운받아 놓고 실제 추론 시간이 전체의 5%도 안 되는 상태 에이전트 파이프라인 세팅을 다 해놓고 "이게 수익이 되는가"라는 질문을 계속 뒤로 미루는 것 이 글은 그 질문에 정면으로 답하는 과정에서 내가 실제로 만든 것, RAM 수치를 어떻게 계산했는지, 그리고 팔 타이밍을 어떤 기준으로 미리 설계했는지를 기록한다. 결론부터 말하면 — 아직 "회사"가 아니고, 처분 시나리오는 이미 설계해뒀다. 로컬 LLM이 이유가 아니다 구입 이유를 물어보면 "로컬 LLM 돌리려고"가 가장 쉬운 답처럼 보인다. 그런데 그게 이유라면 128GB는 정당화하기 어렵다. 로컬 LLM이 실제로 필요한 조건은 대체로 세 가지다. 프라이버시 : 개인 민감 문서를 대량 처리해야 할 때 API 볼륨 : 월 $100+ 이상의 클라우드 API 비용이 발생할 때 오프라인 운용 : 인터넷 없는 환경에서 LLM이 필요할 때 나는 이 세 가지 중 하나도 해당하지 않는다. 그렇다면 로컬 LLM 서버로서의 Mac Studio 128GB는 정당화되지 않는다. ...

결론부터 말한다. 맥 스튜디오 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개 모두 해결됐고,...