shud.log
바이브코딩 기록

어떤 로컬 AI를 쓸지 AI들에게 토론시켰습니다 — M5 맥북 로컬 AI 세팅기

2026-07-16로컬LLMollamaqwen3FLUXmflux맥북바이브코딩

노트북에서 튀어나온 로봇 조수

지난 글에서 새 맥북으로 이사하다 크롬이 즉사한 이야기를 했습니다. 복구를 끝내고 나니 드디어 본론을 시작할 수 있었습니다. 이 기계를 산 이유, 로컬 AI입니다.

램 64GB짜리 맥북에서는 꽤 큰 AI 모델이 인터넷 없이, 구독료 없이, 전기값만으로 돌아갑니다. 목표는 세 가지였습니다.

  1. 로컬 LLM — 텔레그램 봇들의 두뇌 + AI 토론 참여용
  2. 로컬 이미지 생성 — 게임 에셋과 블로그 썸네일 자급자족
  3. 멀티 AI 토론 시스템에 로컬 모델 합류시키기

어떤 모델을 쓸지, AI들에게 토론시키기

옛날 같으면 벤치마크 표 보고 감으로 골랐을 텐데, 이번엔 방법을 바꿨습니다. 멀티 AI 오케스트레이터(여러 AI에게 같은 주제를 주고 라운드제 토론을 시켜 합의안을 뽑는 도구)에 모델 선정을 통째로 맡겼습니다.

조건을 주고 — 램 64GB, 한국어 품질 중요, 용도는 봇·토론·코딩 보조, 디스크 규칙상 상시 2개까지 — 후보군(qwen3, llama3.3 70b, gemma3, deepseek-r1, EXAONE...)을 던졌습니다.

토론 결과가 재미있었습니다.

  • llama3.3 70b 탈락 — 42GB로 슬롯 하나를 통째로 먹고 초당 8토큰으로 느림
  • deepseek-r1 탈락 — 한국어 답변에 중국어 토큰이 새는 문제
  • EXAONE 탈락 — 한국어 특화는 장점이지만 슬롯 2개뿐인데 코딩·범용이 약해 사치
  • 쟁점은 하나 — 같은 qwen3라도 dense 32B(품질파)냐 MoE 30B(속도파)냐

최종 합의는 MoE였습니다. "봇 응답속도가 실사용 병목이고, 로컬은 빠른 조수 역할"이라는 논리에 품질파가 설득당했습니다.

qwen3:30b        ← 범용·토론·봇 (약 19GB)
qwen3-coder:30b  ← 코딩 보조 (약 19GB)

설치 후 실측: 초당 74~80토큰. 합의 때 예상했던 50토큰을 크게 웃돌았고, 우려됐던 한국어 품질 저하도 없었습니다. AI들이 고른 답이 맞았습니다.

이미지 생성: 터미널에서 5초

이미지 쪽은 FLUX.1-schnell을 골랐습니다. 이유는 성능보다 라이선스입니다. schnell은 Apache 2.0이라 상업적 사용이 가능합니다(애드센스 블로그에 써도 OK). 형제 모델인 dev는 비상업 전용이라 블로그에 쓰면 안 됩니다. 로컬 이미지 모델 고를 때 의외로 다들 놓치는 부분입니다.

실행 도구는 mflux — 애플 실리콘 전용 CLI입니다. GUI 없이 터미널 한 줄이면 끝납니다.

mflux-generate --model schnell --quantize 4 --steps 2 \
  --width 512 --height 512 \
  --prompt "cute pixel art mushroom warrior" \
  --output warrior.png

512px 기준 5초, 메모리 피크 10GB. 이 글의 썸네일도, 이 블로그 홈의 카테고리 아이콘 6개도 전부 이걸로 뽑았습니다. 예전엔 무료 이미지 사이트를 뒤지거나 유료 API를 썼는데, 이제 프롬프트만 바꾸면 무한 생산입니다.

삽질 기록 (6연속)

순탄하게 읽혔다면 착각입니다. 오늘의 삽질 목록:

1. 모델 18GB를 엉뚱한 컴퓨터에 다운로드. 옛 맥북 시절 .zshrc에 OLLAMA_HOST=<홈서버 주소>가 남아있었습니다. 로컬로 받는 줄 알았던 모델이 원격 홈서버(램 16GB — 30B 모델을 돌리지도 못하는)로 들어가고 있었습니다. 마이그레이션은 설정 파일의 유령까지 데려옵니다.

2. 토론 도구에도 같은 유령. 멀티 AI 오케스트레이터 소스에도 홈서버 주소가 기본값으로 박혀 있었습니다. 다행히 환경변수로 덮어쓸 수 있게 만들어져 있어서 소스는 안 건드렸습니다.

3. FLUX 다운로드가 401. FLUX는 HuggingFace에서 라이선스 동의 + 로그인이 필요한 게이트 모델입니다. 계정 만들고 토큰 발급받아야 합니다.

4. 로그인해도 다운로드 실패. HuggingFace의 새 전송 방식(Xet) 버그로 "Unable to parse string as hex hash value" 에러. HF_HUB_DISABLE_XET=1로 구형 다운로드 강제하면 해결됩니다.

5. ollama가 엔진 없이 설치됨. brew로 깐 ollama가 llama-server 바이너리 없이 굴러가고 있었습니다. brew reinstall ollama 한 방.

6. 같은 파일명으로 생성하면 조용히 _1이 붙음. mflux는 덮어쓰기를 안 합니다. "왜 다시 뽑았는데 그대로지?" 하고 한참 들여다봤습니다.

마지막 조각: 로컬 AI를 토론 테이블에 앉히기

세팅의 마무리는 방금 깐 qwen3:30b를 멀티 AI 토론의 정식 멤버로 등록하는 것이었습니다. 클라우드 AI 둘 + 내 맥북에서 도는 로컬 AI 하나가 같은 주제로 토론하고 만장일치 합의까지 가는 걸 확인했습니다.

이 그림이 마음에 듭니다. 아침에 봇이 밤새 수집한 데이터를 로컬 모델이 요약하고, 글감이 나오면 로컬 이미지 모델이 삽화를 그리고, 사람은 고르고 다듬기만 하는 파이프라인. 전부 전기값만으로 돌아갑니다.

배운 것

  1. 모델 선정 같은 "정답 없는 결정"은 AI 토론에 맡길 만합니다. 혼자 고르면 벤치마크 숫자에 홀리는데, 관점이 다른 AI들이 서로 반박하게 하면 "우리 상황에서 뭐가 중요한가"가 정리됩니다.
  2. 로컬 이미지 모델은 라이선스부터 확인. schnell(Apache 2.0)과 dev(비상업)의 차이가 수익화 블로그에선 결정적입니다.
  3. 마이그레이션 후엔 .zshrc의 환경변수를 의심하세요. 옛 컴퓨터의 사정이 새 컴퓨터의 미스터리가 됩니다.
  4. 양자화 + MoE면 노트북에서도 30B급이 실용 속도로 돕니다. "로컬은 느려서 못 쓴다"는 이제 옛말입니다.

덧. 다음 글은 이 로컬 모델을 실전 투입하는 이야기가 될 예정입니다 — 매일 아침 트위터를 그라인딩해서 알파와 글감을 물어오는 봇. 클라우드 API로 돌리던 걸 로컬로 갈아끼우면 추론 비용이 0원이 됩니다.

← 목록으로