레이블이 로컬AI인 게시물을 표시합니다. 모든 게시물 표시
레이블이 로컬AI인 게시물을 표시합니다. 모든 게시물 표시

2026/06/07

GitHub Copilot Pro+ 사용한도 소진 이후: 로컬 LLM(Gemma) 전환기

안녕하세요. 오늘 공유할 내용은 최근 저의 개발 도구 환경 변화에 대한 이야기입니다.

GitHub Copilot Pro+ 사용한도 소진

저는 Hermes Agent를 효과적으로 사용하기 위해 GitHub Copilot Pro+ 구독을 유지해 왔습니다. 코드 자동 완성, AI 기반 리팩토링, PR 리뷰 등 개발 워크플로우 전반에 Copilot이 깊이 통합되어 있었죠.

하지만 아직 6월의 절반도 지나지 않은 시점에서 사용한도 소진으로 구독을 취소하고 로컬 LLM 전환을 결정했습니다.

사용한도 소진 이후에는 기본적인 Copilot 기능만 제한적으로 사용할 수 있고, Pro급 고급 기능은 전혀 이용할 수 없는 상태가 되었죠.

로컬 LLM 모델로 전환 결정을 내리다

Copilot 사용 불가 상황에서도 개발 생산성을 유지하기 위해 여러 대안을 검토한 결과, 로컬에서 실행 가능한 LLM 모델로 방향을 전환하기로 결정했습니다.

구글의 Gemma 시리즈를 선택한 이유는 다음과 같습니다.

1. 오픈 소스 및 오픈 웨이트 — 상업적 사용 제한이 명확하고 투명합니다.

2. 다양한 사이즈 옵션 — 사용 환경에 맞게 모델을 선택할 수 있습니다.

3. 좋은 성능/속도 트레이드오프 — 작은 모델로도 충분한 성능을 발휘합니다.

사용 환경

현재 다음과 같은 Apple Silicon 환경을 보유하고 있습니다.

1. Mac Studio M4 Max 64GB — API 서버로 운영 중

2. MacBook Pro M4 Max 64GB — 개발용으로 사용

양쪽 모두 64GB 유니파이드 메모리로 로컬 LLM 실행에 충분한 사양을 갖추고 있습니다.

Gemma 4 E4B vs Qwen 3.6 35B A3B 혼용 전략

두 가지 모델을 상황에 맞게 혼용해서 사용하기로 했습니다.

Gemma 4 E4B (작은 모델)

속도 우선 작업에 적합 — 코드 자동 완성, 간단한 질문 응답, 빠른 탐색에 사용

리소스 Consumption이 적어 실시간 사용 가능 — macOS에서도 부담 없이 실행 가능

Qwen 3.6 35B A3B (대형 모델)

성능 우선 작업에 적합 — 복잡한 코드 분석, 아키텍처 설계, 심층 리서치에 사용

E4B보다 훨씬 높은 추론 능력 — 필요할 때만 호출하는 방식으로 리소스 효율화

전환 기대 효과

데이터 프라이버시 — 모든 추론이 로컬에서 이루어져 코드와 데이터가 외부로 유출되지 않습니다.

비용 효율 — 구독료 없이 무제한 사용 가능

커스터마이징 — 파인튜닝이나 로컬 환경 최적화가 자유롭습니다.

안정성 — 인터넷 연결이나 API 서버 상태에 의존하지 않습니다.

마무리하며

Copilot Pro+ 사용한도 소진은 불편한 변화였지만, 오히려 로컬 LLM 생태계를 본격적으로 탐색하는 계기가 되었습니다. Gemma 4 E4B와 Qwen 3.6 35B A3B를 상황에 맞게 혼용하는 전략으로, 클라우드 의존도를 낮추면서도 개발 생산성을 유지할 수 있을 것으로 기대합니다.

앞으로 Gemma 모델 활용 경험과 성능 비교 결과를 계속해서 공유하겠습니다. 관심 있으신 분들은 팔로우 부탁드립니다!

2026/06/03

oMLX — 맥에서 로컬 LLM을 제대로 쓰기 위한 추론 서버

맥에서 LLM을 로컬로 돌려본 사람이라면 한 번쯤 Ollama를 설치했을 거다. 설치는 쉽고, 모델도 잘 받아지고 — 근데 조금 쓰다 보면 뭔가 아쉽다. 동시에 여러 요청을 보내면 버벅이고, 한 번 세션이 끊기면 컨텍스트를 처음부터 다시 읽어야 하고, 모델 여러 개를 관리하려면 터미널을 뒤적여야 한다. 맥이 이 정도 하드웨어인데, 좀 더 잘 쓸 방법이 없나 싶었다.

oMLX가 그 답에 가장 가까운 도구다. GitHub 스타 15,700개. Apple Silicon 전용 추론 서버인데, 단순히 빠른 것 이상의 것들을 해준다. 직접 설치해서 쓰면서 정리해봤다.


oMLX가 뭔가

oMLX는 Apple의 MLX 프레임워크 위에 올라가는 LLM 추론 서버다. 코어 추론 엔진은 Apple이 공식으로 관리하는 mlx-lm을 쓰고, 그 위에 프로덕션 서빙에 필요한 것들을 다 쌓아올렸다. 멀티 모델 관리, 티어드 KV 캐시, 연속 배칭, macOS 메뉴바 앱까지.

만든 사람의 말을 그대로 인용하면:

"Every LLM server I tried made me choose between convenience and control. I wanted to pin everyday models in memory, auto-swap heavier ones on demand, set context limits - and manage it all from a menu bar."

그래서 직접 만들었다는 거다. 요구사항이 명확하고 아키텍처가 그걸 실제로 구현하고 있다.

왜 MLX 기반이 빠른가 — 유니파이드 메모리 이야기

llama.cpp나 Ollama가 느리다는 게 아니다. 그쪽도 Apple Silicon에서 Metal 백엔드를 쓴다. 근데 MLX는 한 단계 더 간다.

Apple Silicon의 핵심은 CPU와 GPU가 메모리를 공유한다는 거다. MLX는 이걸 적극 활용해서 배열 연산 결과를 CPU→GPU, GPU→CPU로 복사하지 않는다. 제로 카피(zero-copy). LLM 추론은 메모리 대역폭에 병목이 걸리는 작업인데, 불필요한 복사가 없으면 그만큼 유리하다.

실제 커뮤니티 경험으로는 같은 모델, 같은 하드웨어에서 MLX 기반이 llama.cpp/Ollama 대비 생성 속도(TG)가 10~30% 빠른 경우가 많다고 한다. 컨텍스트 처리(PP)도 대용량에서 더 유리하다.

벤치마크 수치들

oMLX 공식 사이트에 커뮤니티 벤치마크 25,000개 이상이 모여 있다. 실측치들을 보면:

M3 Ultra 512GB · Qwen3.5-122B-A10B 4bit · 32k 컨텍스트

→ 프롬프트 처리 765 tok/s, 생성 42.4 tok/s

M2 Max 64GB · Qwen3.6-35B-A3B 4bit · 16k 컨텍스트

→ 프롬프트 처리 728 tok/s, 생성 66.8 tok/s

M4 Max 64GB · Qwopus3.6-27B 8bit · 4k 컨텍스트

→ 프롬프트 처리 241.8 tok/s, 생성 16.4 tok/s

연속 배칭(Continuous Batching) 효과도 인상적이다. 동시 요청 수에 따라 처리량이 선형 이상으로 오른다:

동시 1개: 56.6 tok/s → 동시 2개: 92.1 tok/s → 동시 4개: 135.1 tok/s → 동시 8개: 190.2 tok/s (3.36배)

에이전트 루프나 여러 도구가 동시에 LLM을 호출하는 상황에서 이게 의미 있는 차이다.

설치 방법

요구 사항: macOS 15 (Sequoia) 이상, Apple Silicon (M1 이상), Python 3.10+

방법 1 — macOS 앱 (GUI 선호하는 경우)

GitHub Releases 페이지에서 .dmg 파일을 받아서 Applications에 드래그하면 끝. 단, 이 방법은 터미널에서 쓰는 omlx CLI 명령이 설치되지 않는다.

방법 2 — Homebrew (CLI + 서비스 관리)

brew tap jundot/omlx https://github.com/jundot/omlx

brew install omlx

업그레이드:

brew update && brew upgrade omlx

백그라운드 서비스로 등록 (크래시 시 자동 재시작):

brew services start omlx

방법 3 — 소스 직접 설치

git clone https://github.com/jundot/omlx.git && cd omlx

pip install -e ".[all]"

MCP(Model Context Protocol) 지원이 필요하다면:

/opt/homebrew/opt/omlx/libexec/bin/pip install mcp

기본 사용법

서버 시작

omlx serve --model-dir ~/models

서버가 뜨면 http://localhost:8000/v1 에 OpenAI 호환 API가 열린다. 어드민 패널은 http://localhost:8000/admin.

모델 디렉토리 구조

~/models/ 아래에 MLX 포맷 모델 폴더를 그냥 넣으면 된다. HuggingFace에서 mlx-community 그룹 모델을 받거나, mlx-lm 툴로 직접 변환/양자화할 수 있다.

~/models/

├── Qwen3-27B-4bit/

├── Qwen3.6-35B-A3B-4bit/

└── bge-m3/

주요 옵션들

# SSD KV 캐시 활성화 (서버 재시작 후에도 캐시 유지)

omlx serve --model-dir ~/models --paged-ssd-cache-dir ~/.omlx/cache

# 메모리 한도 설정

omlx serve --model-dir ~/models --memory-guard-gb 48

# 동시 요청 수 늘리기

omlx serve --model-dir ~/models --max-concurrent-requests 16

# MCP 연동

omlx serve --model-dir ~/models --mcp-config mcp.json

티어드 KV 캐시 — 실제로 왜 중요한가

oMLX에서 가장 특이한 부분이 이거다. KV 캐시를 두 계층으로 나눈다.

핫 캐시 (RAM) — 자주 쓰이는 블록은 메모리에 상주한다.

콜드 캐시 (SSD) — 메모리가 부족해지면 safetensors 형식으로 SSD에 오프로드된다. 다음 요청에서 같은 프리픽스가 오면 복구해서 쓴다.

그리고 이 캐시가 서버 재시작 후에도 살아있다. Ollama는 서버를 껐다 켜면 기존 컨텍스트를 처음부터 다시 읽어야 하는데, oMLX는 이전 세션의 KV 블록이 SSD에 있으면 그냥 가져다 쓴다.

Claude Code 같은 코딩 에이전트로 큰 코드베이스 작업을 할 때 첫 번째 턴(TTFT, time-to-first-token)이 30~90초 걸리던 게 5초 이하로 줄어든다. 이건 실제로 써봐야 체감이 된다.

어떤 모델을 쓸 수 있나

mlx-lm이 지원하는 텍스트 LLM은 다 된다. Llama, Qwen, Mistral, Gemma, DeepSeek, GLM, Phi 계열이 포함된다.

VLM — Qwen3.5 시리즈, GLM-4V, Pixtral, mlx-vlm 지원 모델

OCR 모델 — DeepSeek-OCR, DOTS-OCR, GLM-OCR

임베딩 — BERT, BGE-M3, ModernBERT

리랭커 — ModernBERT, XLM-RoBERTa

툴 콜링은 주요 포맷을 전부 파싱한다. JSON, Qwen XML, Gemma, GLM, MiniMax, Mistral, Kimi K2, Longcat 포맷 모두 지원.

내 맥에서 어떤 모델 크기를 돌릴 수 있나

8GB (M1/M2 Base): 7B 4비트 모델. 느리지만 동작은 한다.

16GB: 7B 8비트 or 13B 4비트. 가벼운 작업에 무난.

32GB: 27B 4비트, 혹은 35B MoE 4비트 (Qwen3.6-35B-A3B 같은 MoE는 스파스 활성화라 메모리를 덜 먹는다). 코딩 작업에 실용적인 구간.

64GB: 70B 4비트, 35B 8비트. M3 Max나 M4 Max 영역. 대부분의 작업에서 GPT-4급 체감.

96GB+: M2/M3/M4 Ultra. 70B 8비트, 122B MoE 4비트. 가성비 좋은 로컬 추론의 최상단.

Claude Code, Codex 등 AI 에이전트와 연동

oMLX는 OpenAI 호환 API(/v1/chat/completions)와 Anthropic API(/v1/messages)를 둘 다 지원한다. Claude Code, OpenClaw, Cursor, Codex, Hermes Agent 등 대부분의 AI 코딩 도구를 그냥 endpoint만 바꿔서 쓸 수 있다.

에이전트 세션에서 컨텍스트 스케일링도 지원해서 Claude Code의 자동 컴팩트가 올바르게 트리거되도록 토큰 카운트를 조정해준다. 긴 prefill 동안 SSE keep-alive로 읽기 타임아웃도 막는다.

MCP 서버로도 사용 가능하다. omlx serve에 --mcp-config로 설정 파일을 넘기면 된다.

써볼 만한가

맥에서 LLM 쓰는 방법이 Ollama/LM Studio만 있는 게 아니다라는 걸 보여주는 프로젝트다. 단순히 빠르기만 한 게 아니라, 프로덕션 서빙을 고려한 설계 — 배칭, 티어드 캐시, 멀티모델 관리, 에이전트 최적화 — 가 다 들어가 있다.

현재 버전 v0.4.0, 커밋 1,400개 이상, 최근 커밋이 몇 시간 전. 오픈 이슈 372개는 많이 쓰인다는 신호다. Apache 2.0 라이선스.

M2 Max 이상 맥을 쓰고 있고, 로컬 LLM을 실제 워크플로우에 붙이고 싶다면 oMLX가 현재 가장 완성도 높은 선택이다. Homebrew 한 줄로 설치되고, 어드민 패널에서 모델 다운로드부터 관리까지 다 된다.

GitHub (⭐15.7k) | 벤치마크 대시보드 | mlx-lm (공식 Apple 추론 라이브러리) | omlx.ai

SK하이닉스 ADR 상장 이후 한국 증시 급락의 원인 분석

분류: 증시분석 SK하이닉스 ADR 상장 이후 한국 증시 급락의 원인 분석 지난 7월 10일, SK하이닉스가 미국 나스닥에 미국주식예탁증서(ADR)를 상장했다. 공모가 149달러로 상장한 하이닉스 ADR은 첫 거래일인 13일 기준 약 168달...