다음 단계의 개선 사항: Llama.cpp, Gemma 4 12B, MCP 및 Tavily를 활용한 개인용 에이전트 AI 어시스턴트 최적화

서론 (Introduction)

$0 비용의 개인용 에이전트 AI 어시스턴트 (personal agentic AI assistant)를 구축한다는 것은 무한한 클라우드 규모를 사용할 수 있는 사치가 없음을 의미합니다. 게으른 시스템 프롬프트 (system prompt)에 거대한 128k 컨텍스트 윈도우 (context window)를 그냥 던져 넣고 끝낼 수는 없습니다. 불필요한 모든 토큰이 제한된 CPU 코어에 영향을 주거나 메모리 부족 (OOM, out-of-memory) 충돌을 위협할 때, 아키텍처 (architecture)가 중요해집니다.

저의 최신 시리즈인 Openclaw Personal AI Assistant에서, 저는 OpenClaw 프레임워크를 사용하여 개인용 에이전트 파이프라인 (agent pipeline)의 초기 설정을 자세히 설명했습니다.

위 다이어그램: 개인용 에이전트 AI 어시스턴트의 기반으로 시작한 초기 기술 스택 (tech stack)

오늘 저는 다음 진화 단계에 대한 심층 분석을 공유하고자 합니다. 플랫폼 전체를 Google DeepMind의 Gemma 4 12B로 마이그레이션 (migrating)하고, 모델 컨텍스트 프로토콜 (MCP, Model Context Protocol)을 통해 통합 계층을 분리하며, Tavily를 통해 실시간 웹 인텔리전스 (web intelligence)를 연결하고, 이 모든 것을 고도로 최적화된 로컬 백그라운드 Llama.cpp 서버에서 구동하는 과정입니다.

다음은 엄격한 리소스 제약 조건 내에서 프로덕션급 성능과 실제 도구들을 끌어내는 방법에 대한 엔지니어링 분석입니다.

핵심 업그레이드: Gemma 4 12B 네이티브 로컬 실행

이전 버전에서는 빠른 로컬 실행을 위해 더 작은 3B 모델 (Qwen 2.5 Coder 등)을 활용했으며, 복잡한 에이전트 도구 호출 (tool-calling) 로직이 필요할 때마다 무료 API 티어 (API tiers)로 전환했습니다. 효율적이긴 하지만, 외부 LLM API에 의존하는 것은 진정한 개인용 어시스턴트의 독립적인 철학을 깨뜨립니다.

Gemma 4 12B의 출시는 기준점을 완전히 바꾸어 놓았습니다. 이 모델은 복잡한 멀티 에이전트 오케스트레이션 (multi-agent orchestration)에 필요한 밀도 높은 추론 능력을 제공합니다. 하지만 제한된 호스트 예산에서 120억 개의 파라미터 (parameter)를 가진 모델을 실행하려면 정밀한 인프라 선택이 필요합니다.

스택 및 하드웨어 제약 사항 (The Stack & Hardware Constraints)

불필요한 백그라운드 CPU 오버헤드를 유발하는 Ollama와 같은 무거운 추상화 계층을 실행하는 대신, 백그라운드 systemd 서비스로 실행되는 네이티브 컴파일된 llama.cpp 서버로 전환했습니다.

이것이 표준 노트북 사양과 같은 소비자용 설정에서 현실적으로 실행될 수 있는지 평가하기 위해, 제 서버의 실행 제약 조건을 엄격한 샌드박스(sandbox)로 고정했습니다:

CPU: 3 코어 (ARM64)
RAM: 18 GB 물리 RAM
모델 (Model): Gemma 4 12B Instruction-Tuned (Q4_K_M GGUF 양자화 (quantization))

MCP 및 Tavily를 통한 통합 문제 해결 (Solving the Integration Mess with MCP & Tavily)

이전 설계에서는 도구(tool)를 추가하려면 에이전트가 해석해야 하는 맞춤형 Python 래퍼(wrapper) 함수를 작성해야 했습니다. 이는 취약하고 커스텀적인 "N×M" 통합 악몽을 만들어냈습니다.

어시스턴트의 미래 대응력을 확보하기 위해, 범용 연결 계층으로서 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)을 도입했습니다.

위 다이어그램: 네이티브 llama.cpp 체크포인팅, MCP 프로토콜 추상화 및 Tavily 통합을 활용한 업그레이드된 아키텍처.

MCP로 전환함으로써, 로컬 모델은 표준 인터페이스를 통해 표준 JSON-RPC 2.0 메시지를 사용하여 통신합니다. 이를 통해 호스트 애플리케이션 로직을 비대하게 만들지 않고도 특화된 외부 유틸리티를 쉽게 플러그인할 수 있었습니다.

주요 사례는 Tavily Search의 추가입니다. 에이전트가 실시간 개발자 생태계 트렌드에 관한 질의를 접하면, 원시 웹 스크래핑(web scraping) 및 노이즈 필터링(noise-filtering) 워크로드를 Tavily의 최적화된 API로 안전하게 오프로드(offload)하고, 표준 MCP 채널을 통해 정제되고 합성된 사실적 페이로드(payload)를 다시 전달받습니다.

실제 성능 및 컴퓨팅 지표 (Real-World Performance & Compute Metrics)

자원 제한적인 환경에서 로컬 LLM 성능을 평가할 때는 컴퓨팅 그래프(compute graph)의 완전히 다른 두 단계, 즉 프리필 (Prefill, 프롬프트 처리)과 디코드 (Decode, 텍스트 생성)를 살펴보아야 합니다.

런타임 도구 호출 (tool-calling) 스트레스 테스트 중에, 원시 실행 로그(raw execution logs)를 통해 시스템 도구에 대해 추론할 때 엄격한 코어 제한 하에서 12B 모델이 어떻게 작동하는지 정확히 드러났습니다:

1. 프롬프트 프리필 단계 (The Heavy Lift)

에이전트의 시스템 프롬프트, MCP 도구 스키마 (tool schemas), 그리고 대화 상태를 포함한 410개 토큰의 프롬프트가 서버에 도달하면, 실행 텐서 행렬 (execution tensor matrices)을 구축하기 위해 CPU 사용량이 약 195%까지 급증합니다.

첫 번째 토큰 생성 시간 (Time to First Token): ~54.1초
프리필 속도 (Prefill Speed): 초당 7.64개 토큰

2. 텍스트 생성 단계 (The Output Stream)

모델이 입력된 텍스트를 처리하고 도구 인자 (tool arguments) 또는 최종 통찰력을 토큰 단위로 출력하는 단계로 전환되면, 리소스 점유율이 크게 감소합니다:

디코드 속도 (Decode Speed): 초당 1.92 ~ 2.05개 토큰

현실적인 점검 (Reality Check): 초당 약 2개의 토큰 생성 속도는 유동적이고 실시간적인 대화형 챗봇 인터페이스를 기대하기 어렵다는 것을 의미합니다. 하지만 MCP 도구를 실행하고, 기술적 통찰력을 처리하며, 데이터 스트림을 웹훅 (webhook)으로 라우팅하는 비동기식 백그라운드 에이전트의 경우에는 이 방식이 완전히 실행 가능하며, 매우 안정적이고 비용 최적화되어 있습니다.

메모리 아키텍처 및 컨텍스트 체크포인팅 (Memory Architecture & Context Checkpointing)

top 명령어와 free -h 명령어 등을 통해 로컬 엔진을 모니터링할 때 흔히 혼동하는 지점은 대화가 길어짐에 따라 메모리 할당이 어떻게 확장되는가 하는 점입니다.

llama-server가 실행되면, mmap (Memory Mapping, 메모리 매핑)이라고 불리는 Linux 시스템 호출을 사용하여 모델 가중치 (model weights)를 로드합니다. 이는 디스크에서 파일을 가상 주소 공간 (virtual address space)으로 직접 매핑합니다. 이 때문에 top 명령어는 85%에서 88%라는 무시무시한 메모리 소비율을 보고할 수 있지만, 커널은 해당 가중치를 buff/cache 아래에 안전하게 표시합니다.

               total        used        free      shared  buff/cache   available
Mem:            17Gi       10Gi        455Mi       5.3Mi       7.1Gi       7.3Gi

하지만 도구(tools)를 실행함에 따라 대화 컨텍스트(conversation context)가 400개 토큰에서 수천 개의 토큰으로 확장되면 어떤 일이 발생할까요? 메모리가 프로세스가 OOM(Out of Memory) 크래시를 일으킬 때까지 선형적으로 증가할까요?

아니요. 메모리 사용량(memory footprint)은 평탄하게 유지됩니다.

로그를 보면 llama-server가 자동 컨텍스트 캐시 체크포인트(automated context cache checkpoint) 시스템을 활발하게 실행하고 있음을 알 수 있습니다:

restored context checkpoint (pos_min = 0, pos_max = 527, n_tokens = 528... size = 165.007 MiB)
erased invalidated context checkpoint...

매 턴마다 동일한 기본 텍스트(시스템 지침 및 도구 정의와 같은)에 대해 수학적 계산을 다시 수행하는 대신, RAM에서 165 MiB 크기의 캐시 체크포인트를 즉시 복구합니다.

나아가, llama-server는 입력 텍스트를 배치 크기(batch size) 파라미터(보통 --batch-size 512)에 의해 정의된 엄격한 청크(chunks)로 자릅니다. RAM 내의 임시 스크래치패드 작업 공간(temporary scratchpad workspace)을 사용하여 처음 512개 토큰을 처리하고, 다음 512개 토큰에 대해 동일한 작업 공간을 재사용하며, 남은 부분에 대해서도 이를 다시 재사용합니다.

여러 MCP 도구 상호작용으로 인해 컨텍스트가 확장되더라도, 시스템은 7.3 GiB의 가용 운영 체제 메모리를 견고하게 유지합니다. 이 구성 하에서 OOM 크래시의 위협은 사실상 제로에 가깝습니다.

Telegram 게이트웨이 병목 현상 극복하기

로컬 모델을 Telegram과 같은 소비자용 통신 채널과 통합하면 독특한 소프트웨어 개발 마찰(friction)이 드러납니다.

무엇이 병목인가?

처음에 저는 "일반 텍스트 출력(plain text output)"을 강제하도록 시스템 프롬프트를 업데이트했을 때, Gemma 4가 자신의 구조적 채팅 템플릿(chat templates)과 충돌하며 4,100개 이상의 중복 토큰을 생성하는 무한 루프에 빠지는 에지 케이스(edge case)를 경험했습니다. 네이티브 포맷팅으로 되돌리는 작업이 필요했지만, 이로 인해 파편화된 사용자 경험이 남았습니다. 즉, Telegram 채널 내에 깨진 원시 Markdown 태그(Bold)가 나타나는 현상이었습니다.

Telegram의 레이아웃 엔진은 매우 취약하기로 유명합니다. 표준 마크다운(standard markdown)을 전달할 경우, 날짜의 하이픈(-)이나 마침표(.)와 같이 이스케이프(escape)되지 않은 문자가 있으면 API가 페이로드(payload)를 완전히 거부하게 됩니다.

깔끔한 엔지니어링 솔루션 (The Clean Engineering Solution)

시스템 프롬프트 (system prompt)를 과도하게 복잡하게 만들거나 LLM의 내부 토큰 경로 (token paths)를 혼란스럽게 만드는 대신, 가장 깔끔한 솔루션은 모델이 텍스트를 정상적으로 생성하게 두고, 전송 직전 커스텀 Python 게이트웨이 스크립트 내부에서 오버헤드가 없는 가벼운 문자열 치환 함수 (string replacement function)를 통해 포맷팅을 처리하는 것입니다:

url = f"https://api.telegram.org/bot{BOT_TOKEN}/sendMessage"

while text:
...

포맷팅 수정을 단순한 런타임 문자열 메서드 (runtime string method)로 오프로딩 (offloading)함으로써, 모델은 제한 없는 속도로 실행되고, 파이프라인 (pipeline)은 높은 성능을 유지하며, 최종 출력은 깔끔하게 렌더링됩니다.

로컬 아키텍처 (Local Architecture)를 위한 교훈

제한된 하드웨어에서 MCP 및 웹 도구의 지원을 받는 통합 120억 파라미터 (12-billion parameter) 모델을 완전히 스스로의 통제하에 실행하는 것은 효율성 측면에서 매우 보람 있는 연습입니다. 이는 단순히 성능 병목 현상 (performance bottleneck)에 클라우드 컴퓨팅 예산을 쏟아붓는 대신, 기본 설정 (default configurations)을 면밀히 살펴보고 기저의 시스템 호출 (system calls)을 이해하도록 강제합니다.

만약 고사양 노트북에서 이를 재현하는 것을 목표로 한다면, 18 GB 메모리 할당은 안정성을 보장하기 위한 환상적인 최적의 지점 (sweet spot)입니다. 하지만 CPU 기반 설정의 54초 프리필 지연 시간 (prefill latency)을 우회하려면, 레이어 (layers)를 통합 GPU (Apple Silicon의 통합 메모리 또는 NVIDIA 노트북 RTX 카드와 같은)로 오프로딩함으로써 초당 2 토큰 (2 tokens/sec)의 생성 속도를 유연한 실시간 경험으로 쉽게 전환할 수 있습니다.

여러분은 자동화 파이프라인을 로컬 컴파일된 바이너리 (local compiled binaries)와 MCP로 전환하셨나요? 여러분의 커스텀 장비에서는 어떤 종류의 토큰 처리량 (token throughput)과 리소스 프로필 (resource profiles)이 관찰되고 있나요? 아래 댓글에서 함께 논의해 봅시다!

이 지점까지 읽으셨다면, 저는 여러분이 계속 읽을 수 있도록 만족스러운 노력을 기울였습니다. 친절하게 댓글을 남겨주시거나 수정 사항을 공유해 주시면 감사하겠습니다.