매일 기록한 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) ≈ 메모리 대역폭 ÷ 토큰당 읽어야 할 파라미터 크기 이 공식은 절대치 예측이 아니...