24GB M4 맥북에서 로컬 LLM 굴려본 현실 후기

24GB M4 맥북에서 로컬 모델을 굴려본 결론

• 작성자는 M4 맥북 프로 24GB 메모리 환경에서 로컬 LLM을 꽤 오래 실험했고, “드디어 그럭저럭 쓸만한 조합을 찾았다”는 쪽임

  • 인터넷 연결 없이 기본 작업, 리서치, 계획 수립을 할 수 있다는 점을 크게 봄
  • 최첨단 클라우드 모델 수준은 전혀 아니지만, 빅테크 의존을 조금이라도 줄인다는 매력도 있다고 함
  • 문제는 세팅이 만만치 않다는 것임

• 로컬 LLM은 모델만 고르면 끝이 아니라 실행 환경부터 갈림

  • Ollama, llama.cpp, LM Studio 중 뭘 쓸지 골라야 함
  • 각 도구마다 지원 모델, 설정 방식, 제약이 다름
  • 거기에 메모리에 들어가면서도 평소 쓰는 Electron 앱들까지 돌릴 여유를 남겨야 함

• 작성자가 원하는 조건은 꽤 현실적임

  • 최소 64K 컨텍스트, 가능하면 128K 이상
  • 도구 사용이 가능해야 함
  • 노트북이 실사용 불가능할 정도로 느려지면 안 됨
  • 단순히 “메모리에 올라간다”와 “쓸 수 있다”는 다르다는 얘기임

제일 괜찮았던 조합은 Qwen 3.5 9B Q4

• 최종적으로 가장 괜찮았던 모델은 Qwen 3.5 9B의 4비트 양자화 모델인 qwen3.5-9b@q4_k_s였음

  • LM Studio에서 실행
  • 사고 모드 활성화
  • 도구 사용 성공
  • 128K 컨텍스트 윈도우
  • 속도는 약 40토큰/초 수준이었다고 함

• 반대로 다른 후보들은 애매했음

  • Qwen 3.6 Q3, GPT-OSS 20B, Devstral Small 24B는 기술적으로 메모리에 들어가긴 했지만 실사용은 불편했다고 함
  • Gemma 4B는 실행 자체는 괜찮았지만 도구 사용에서 많이 버거워했다고 평가함
  • 결국 로컬 모델은 파라미터 크기보다 “내 작업 흐름에서 버티는가”가 더 중요함

• 설정값도 그냥 기본값으로 끝나지 않음
  • 코딩 작업과 사고 모드에는 temperature 0.6, top_p 0.95, top_k 20, min_p 0.0, presence_penalty 0.0, repetition_penalty 1.0을 추천함
  • 사고 모드를 켜려면 LM Studio 모델 설정의 Prompt Template에 {%- set enable_thinking = true %}를 추가해야 했다고 함
  • 이런 세부 설정이 모델 품질과 행동에 꽤 영향을 준다는 게 로컬 LLM의 피곤한 부분임

Pi와 OpenCode 연결도 해봄

• 작성자는 LM Studio를 로컬 API 서버처럼 띄우고 Pi와 OpenCode에서 붙여 씀

  • Pi는 좀 더 빠릿하게 느껴졌다고 함
  • 다만 harness를 직접 구성하는 철학은 좋지만, sensible defaults가 부족해서 세팅에 시간을 많이 잡아먹을 수 있다고 봄
  • “프로젝트보다 Pi 설정을 더 만지게 될 수도 있다”는 불만이 나옴

• Pi 설정은 OpenAI 호환 API로 LM Studio를 바라보게 하는 구조임

  • baseUrl은 http://localhost:1234/v1
  • 모델 ID는 qwen3.5-9b@q4_k_s
  • reasoning을 켜고, thinkingFormat은 qwen-chat-template로 맞춤
  • 생각 블록이 거슬리면 settings에 hideThinkingBlock을 켜는 식임

• OpenCode도 비슷하게 로컬 제공자를 등록함

  • baseURL은 http://127.0.0.1:1234/v1
  • 모델 컨텍스트 길이는 131072로 설정
  • max_tokens는 32768로 둠
  • tools를 true로 켜서 도구 사용을 허용함

잘하는 일과 못하는 일이 꽤 분명함

• 작성자는 Qwen 3.5 9B Q4가 장시간 복잡한 문제를 독립적으로 해결하는 수준은 아니라고 못박음

  • 앱 전체를 한 번에 만들라고 시키면 노트북만 뜨거워지고 결과는 별로일 거라고 함
  • 중간에 루프에 빠지거나, 요청을 잘못 해석하거나, 산만해지는 경우가 있음
  • 최첨단 모델처럼 “알아서 끝까지 밀어붙이는” 타입은 아님

• 대신 사람이 계속 방향을 잡아주는 인터랙티브 워크플로에서는 쓸만함

  • 단계별로 명확히 요청하고, 계속 확인하고, 사람이 계획을 잡아줘야 함
  • 작성자는 오히려 이 방식이 자신을 더 작업에 관여하게 만들어서 좋았다고 함
  • 클라우드 최첨단 모델은 인지적 노력을 너무 쉽게 떠넘기게 만드는 단점이 있다고 봄

• 성공 사례는 Elixir linter 경고 수정이었음

  • mix credo --strict 결과를 보고 테스트 파일 4곳에서 length(list) > 0을 list != []로 바꾸라고 제안함
  • Elixir에서 리스트 길이를 계산하지 않아도 돼 더 관용적이라는 설명도 붙임
  • 이후 4개 병렬 편집을 깔끔하게 수행했다고 함

• 실패 사례는 git rebase 충돌 처리였음

  • dependabot PR 충돌에서 sentry는 13.0.1, tailwind는 0.4.1을 유지하면 된다는 판단 자체는 맞았음
  • 그런데 실제 수정 없이 git add와 git rebase --continue를 시도해 conflict marker가 남은 상태로 진행하려 함
  • 게다가 rebase continue가 편집기를 연다는 점을 놓쳐 OpenCode가 멈춘 듯한 상황도 나옴

로컬 모델의 매력은 다른 데 있음

• 작성자가 보는 로컬 모델의 장점은 생산성 10배 같은 마케팅이 아님

  • 비행기에서도 인터넷 없이 쓸 수 있음
  • 구독료 없이 전기요금과 이미 산 하드웨어만으로 굴릴 수 있음
  • 데이터센터 사용을 줄이고 자기 하드웨어에서 실행한다는 점도 매력으로 봄
  • 무엇보다 tinkering 자체가 재밌다고 함

• 결론은 꽤 균형 잡혀 있음

  • LLM이 세상에 준 영향은 크고, 좋은 것만은 아니지만, 어쨌든 계속 남을 기술이라고 봄
  • 로컬 모델 실험은 이 기술과 더 지속가능하고 긍정적으로 상호작용하는 방식일 수 있다고 함
  • 틀릴 때조차 재밌다는 말이 이 글의 정서에 가까움

---

기술 맥락

• 작성자가 Qwen 3.5 9B Q4를 고른 이유는 품질, 메모리, 속도, 컨텍스트의 균형 때문이에요. 24GB 머신에서는 더 큰 모델이 들어가더라도 운영체제와 개발 도구가 같이 돌아갈 여유가 없으면 실사용이 힘들거든요.

• 양자화는 여기서 핵심 선택이에요. Q4_K_S처럼 4비트로 줄이면 모델이 작아져서 로컬에서 돌릴 수 있지만, 대신 추론 품질과 안정성은 어느 정도 양보해야 해요. 그래서 “최고 성능”보다 “내 노트북에서 계속 쓸 수 있음”이 기준이 돼요.

• 128K 컨텍스트를 원하는 이유도 코딩 작업의 특성 때문이에요. 파일 여러 개, 터미널 출력, 이전 대화, 에러 로그를 같이 넣어야 모델이 맥락을 잃지 않아요. 컨텍스트가 작으면 매번 사람이 배경을 다시 설명해야 해서 로컬 모델의 장점이 줄어들어요.

• 도구 사용은 아직 가장 위험한 부분이에요. 모델이 충돌 원인을 말로는 맞게 이해해도, 실제 파일을 수정하지 않고 명령부터 실행할 수 있어요. 그래서 로컬 에이전트는 자율 주행보다 페어 프로그래밍 보조로 보는 게 훨씬 현실적이에요.