r/openclaw Mac 스레드를 읽어보았습니다: 잘못된 LLM 기기에 4,000달러를 낭비하지 않는 법

여러분이 직접 읽으실 필요 없도록 제가 추천수 21개와 댓글 25개가 달린 r/openclaw 스레드를 모두 살펴보았습니다. 여기서 가장 유용한 결론은 "Mac은 나쁘다"라거나 "클라우드가 더 낫다"가 아니었습니다.

바로 이것입니다:

OpenClaw 스타일의 에이전트 (agent) 워크로드에서는 초당 토큰 수 (tokens/sec)가 아니라, 프롬프트 처리 (prompt processing)가 보통 병목 현상 (bottleneck)이 됩니다.

잘못된 지표를 최적화하기 위해 수천 달러를 쓰기 전까지는 이 말이 사소하게 들릴 수 있습니다.

만약 여러분이 주로 OpenClaw를 로컬에서 실행하기 위해 Mac을 구매하려는 것이라면, 이 차이는 매우 중요합니다.

실제로 중요한 스레드의 한 구절

원문 작성자는 다음과 같이 말했습니다:

내 Mac에서 여러 모델을 실행해 본 결과, 문제가 되는 것은 초당 토큰 수 (tokens/second)가 아니라 프롬프트 처리 (prompt processing)라는 것을 알게 되었습니다.

이 한 문장이 문제의 핵심입니다.

많은 로컬 LLM 구매 결정이 생성 속도를 보여주는 스크린샷을 바탕으로 내려집니다. 하지만 OpenClaw는 단발성 채팅 앱이 아닙니다. 이 앱은 모델에 엄청난 양의 컨텍스트 (context)를 계속해서 다시 보냅니다:

에이전트 지침 (agent instructions)
이전 단계 (previous steps)
도구 출력 (tool outputs)
메모리 (memory)
재시도 (retries)
서브 에이전트 추적 (subagent traces)

따라서 모델은 다음 토큰을 쓰기 전에 세상을 다시 읽는 데 많은 시간을 소비합니다.

이 단계를 사람들은 보통 프리필 (prefill) 또는 **프롬프트 처리 (prompt processing)**라고 부릅니다.

그리고 에이전트 루프 (agent loops)에서는 이 단계가 지연 시간 (latency)을 지배할 수 있습니다.

왜 Mac은 채팅에서는 빠르고 에이전트에서는 느리게 느껴질 수 있는가

Apple Silicon은 로컬 추론 (inference)에 진정으로 뛰어납니다.

그 부분은 사실입니다.

llama.cpp는 Metal에서 잘 작동합니다.
MLX는 훌륭합니다.
통합 메모리 (unified memory)는 유용합니다.
최신 Mac Studio / 고용량 RAM 구성은 놀라울 정도로 큰 모델을 수용할 수 있습니다.

채팅 UI를 열고 짧은 질문을 던진다면, Mac은 매우 훌륭해 보일 수 있습니다.

하지만 그 벤치마크는 OpenClaw에게는 오해의 소지가 있습니다.

장난스러운 채팅 테스트:

사용자 -> 짧은 프롬프트
모델 -> 답변

에이전트 루프는 다음과 더 비슷합니다:

시스템 프롬프트 (System prompt)
+ 메모리 (memory)
+ 이전 작업 (previous actions)
...

이는 기기가 긴 프롬프트를 반복적으로 처리해야 함을 의미합니다.

따라서 누군가 "내 Mac은 괜찮은 tok/s를 보여줘"라고 말한다면, 이어지는 질문은 다음과 같아야 합니다:

어떤 프롬프트 부하 (prompt load) 상황에서 말인가요?

왜냐하면 바로 그 지점에서 경험이 "꽤 괜찮네"에서 "이 기계는 왜 이렇게 오래 생각하지?"로 바뀌기 때문입니다.

벤치마크의 거짓말: tokens/sec가 전부가 아니다

개발자들은 단순한 지표를 좋아합니다. 초당 토큰 수(tokens/sec)는 비교하기 쉽고, 스크린샷을 찍기 편하며, 오용하기도 쉽습니다.

에이전트 워크로드 (agent workloads)를 위해서는 최소한 다음과 같은 질문들이 필요합니다:

프롬프트 주입 (prompt ingestion) 속도는 얼마나 빠른가?
컨텍스트 (context)가 커짐에 따라 지연 시간 (latency)이 어떻게 변하는가?
10회, 20회, 50회의 도구 호출 (tool calls) 이후에는 어떤 일이 발생하는가?
재시도 (retries)나 하위 에이전트 (subagents) 환경에서 설정값은 어떻게 작동하는가?
고통스럽지 않게 긴 루프 (long loops)를 유지할 수 있는가?

llama.cpp 성능 논의도 같은 방향을 가리킵니다. 즉, 런타임 설정 (runtime settings)과 워크로드의 형태 (workload shape)가 결과에 큰 영향을 미칩니다. 구성 (configuration)에 따라 출력 결과가 크게 요동치는 것을 볼 수 있습니다.

이 점은 사람들이 단일 수치로 된 벤치마크를 매우 의심스럽게 바라봐야 함을 시사합니다.

여러분의 실제 워크로드가 OpenClaw라면, 대신 다음과 같이 벤치마크를 수행하십시오:

# 의사 벤치마크 워크플로우 (pseudo-benchmark workflow)
# 1. 로컬 모델 서버 실행
lama-server -hf ggml-org/gemma-3-1b-it-GGUF
...

만약 짧은 프롬프트만을 벤치마크한다면, 여러분은 잘못된 것을 측정하고 있는 것입니다.

Mac은 OpenClaw에 좋지 않은가?

아니요.

그건 너무 단순한 결론입니다.

더 정확한 관점은 다음과 같습니다:

여러분의 주된 목표가 빠른 OpenClaw 에이전트 실행이라면, Mac은 종종 가성비가 떨어집니다.

이는 Mac이 나쁜 기계라고 말하는 것과는 다릅니다.

Mac의 사양 (specs)은 매우 중요합니다.

기본형 Mac mini는 고용량 메모리를 갖춘 Mac Studio와는 다릅니다. RAM이 중요합니다. 최신 Apple Silicon이 중요합니다. 모델 선택도 중요합니다.

그리고 맞습니다, 사람들은 Mac에서 다음과 같은 것들을 통해 괜찮은 로컬 결과를 얻고 있습니다:

Ollama
MLX
llama.cpp
Qwen 제품군 모델
Llama 제품군 모델
더 작은 MoE 스타일 모델

하지만 해당 스레드에는 일반적인 낙관론을 꿰뚫는 댓글이 하나 있었습니다:

지금 당장 프라이버시가 필요한 경우에만 그렇게 하세요. 속도가 필요하다면, 대신 RTX 6000 2개를 장착한 설정을 고려하는 편이 낫습니다.

가혹하지만, 기본적으로는 맞는 말입니다.

이 분야에서 Apple의 강점은 편의성과 기기당 모델 수용량 (model capacity)이지, 본격적인 NVIDIA 하드웨어를 상대로 원시적인 에이전트 처리량 (agent throughput) 싸움에서 이기는 것이 아닙니다.

통합 메모리 (Unified memory)는 모델을 맞추는 데 도움을 줍니다.

하지만 에이전트가 거대한 컨텍스트 (context)를 끌고 다니기 시작할 때, 프롬프트 처리 지연 시간 (prompt-processing latency)을 마법처럼 지워주지는 않습니다.

OpenClaw가 실제로 최적화된 대상

OpenClaw에서 제가 좋아하는 점 중 하나는 이데올로기를 강요하지 않는다는 것입니다.

로컬 우선 (local-first) 워크플로우를 지원하면서도, 클라우드 제공업체 및 혼합 설정 (mixed setups)도 지원합니다.

이것이 올바른 설계입니다.

왜냐하면 진짜 결정해야 할 문제는 '로컬 대 클라우드'라는 종교적 선택이 아니기 때문입니다.

그것은 당신의 실패 모드 (failure mode)를 선택하는 것입니다.

당신의 세 가지 실제 옵션

옵션	최적의 용도
Mac 로컬 LLM 설정	개인정보 보호, 온디바이스 제어, Apple 생태계의 편의성, 대규모 OpenClaw 컨텍스트 하에서의 느린 프롬프트 처리 감수
...

이것이 결정 트리 (decision tree)입니다.

"어떤 벤치마크 스크린샷이 가장 멋져 보였는가"가 아닙니다.

사람들이 실제로 사용하는 실용적인 설정 패턴

가장 현실적인 OpenClaw 사용자들은 순수성을 쫓지 않습니다. 그들은 도구들을 섞어서 사용합니다.

현실적인 설정은 다음과 같을 수 있습니다:

저렴한 Linux 박스, Mac mini, 또는 VPS에서 OpenClaw 실행
무거운 에이전트 루프 (agent loop)에는 클라우드 모델 사용
폴백 (fallback) 또는 개인적인 작업을 위해 로컬 모델 유지
서브에이전트 (subagents)가 돈이나 시간을 낭비하지 않도록 가드레일 (guardrails) 추가

이 방식은 놀라울 정도로 저렴할 수 있습니다.

OpenClaw + Ollama

{
  "models": {
    "providers": {
...

OpenClaw + llama.cpp OpenAI 호환 서버

lama-server -hf ggml-org/gemma-3-1b-it-GGUF

OpenClaw 설치

npm install -g openclaw@latest
openclaw onboard --install-daemon
openclaw dashboard

설정 자체는 어려운 부분이 아닙니다.

어려운 부분은 추론 (inference)이 어디에서 일어나야 하는지를 결정하는 것입니다.

그럼에도 사람들이 여전히 로컬을 원하는 이유

클라우드에도 그 나름의 실패 모드가 있기 때문입니다: 바로 걷잡을 수 없는 청구서입니다.

r/openclaw를 읽던 중, 서브에이전트들이 OpenRouter와 DeepSeek Flash를 통해 폭주한 후 한 시간 만에 4,000만 토큰이 소비된 사례를 설명한 다른 스레드를 발견했습니다.

이것이 바로 로컬 추론이 여전히 시장을 가지고 있는 정확한 이유입니다.

사람들이 항상 로컬을 선택하는 이유는 그것이 더 빠르기 때문만은 아닙.

사람들이 로컬을 선택하는 이유는 로컬이 재앙에 대한 확실한 상한선(hard ceiling)을 설정해주기 때문입니다.

만약 새벽 2시에 당신의 에이전트(agent)가 통제 불능 상태가 된다면:

로컬은 시간만 낭비합니다.
클라우드는 돈을 낭비할 수 있습니다.

이것은 매우 실질적인 트레이드오프 (tradeoff)입니다.

API 가격 책정 시 상황이 난처해지는 이유

클라우드 가격 책정은 당신의 자동화(automation)가 이상하게 작동하기 직전까지는 믿기지 않을 정도로 저렴할 수 있습니다.

이것이 에이전트에게 사용량 기반 과금 (usage-based billing) 방식이 가진 문제입니다.

단 한 번의 잘못된 루프 (loop)가 "저렴함"을 "왜 이 워크플로우(workflow) 비용이 이번 달 나머지 비용보다 더 많이 나왔지?"로 바꿔놓을 수 있습니다.

이것이 바로 에이전트 워크로드 (workload)에 있어 정액제 컴퓨팅 (flat-rate compute)이 흥미로운 이유이기도 합니다.

만약 여러분이 OpenClaw, n8n, Make, Zapier 또는 커스텀 에이전트 스택 (agent stacks)에서 자동화를 실행하고 있다면, 어려운 점은 단순히 모델의 품질만이 아닙니다. 바로 비용 예측 가능성 (cost predictability)입니다.

이것이 바로 Standard Compute가 해결하고자 하는 격차입니다.

여러분은 OpenAI 호환 워크플로우를 유지하면서도, 토큰당 비용에 대한 공포 (per-token panic)에서 벗어날 수 있습니다.

예상치 못한 청구서를 피하기 위해 전체 스택을 구축하는 대신, 다음과 같은 이점을 얻게 됩니다:

정액제 월간 요금
OpenAI 호환 API 액세스
장시간 실행되는 에이전트에 대한 토큰 불안감 해소
GPT-5.4, Claude Opus 4.6, Grok 4.20과 같은 모델 간의 라우팅 (routing)

이는 로컬 대 클라우드 (local-vs-cloud) 결정의 양상을 다소 변화시킵니다.

왜냐하면 많은 팀에게 있어, 로컬 하드웨어를 과도하게 구매하는 진짜 이유는 성능 때문이 아니기 때문입니다.

그것은 가변적인 API 비용에 대한 두려움입니다.

그 두려움을 제거한다면, 토큰 청구서를 피하기 위해 주로 4,000달러짜리 기계를 구매하는 것은 훨씬 덜 합리적으로 보이기 시작할 것입니다.

더 유용한 선택 방법

Mac, 클라우드 API, 또는 하이브리드 (hybrid) 설정 사이에서 고민 중이라면, 다음 질문들을 던져보세요:

다음과 같은 경우 Mac 로컬 설정을 구매하세요:

개인정보 보호 (privacy)가 필수 요구 사항인 경우
온디바이스 추론 (on-device inference)이 필요한 경우
로컬 모델을 튜닝 (tuning)하는 것에 거부감이 없는 경우
느린 프롬프트 처리 속도를 수용할 수 있는 경우
최대 처리량 (throughput)보다 편의성이 더 중요한 경우

다음과 같은 경우 클라우드 추론 (cloud inference)을 사용하세요:

더 빠른 에이전트 루프를 원하는 경우
로컬 모델 인프라를 관리하고 싶지 않은 경우
워크로드가 도구 중심적 (tool-heavy)이고 컨텍스트 중심적 (context-heavy)인 경우
온디바이스 제어보다 속도에 더 신경을 쓰는 경우

다음과 같은 경우 하이브리드를 사용하세요:

폴백 경로 (fallback paths)가 필요한 경우
일부 프라이빗한 로컬 작업 (private local tasks)이 필요한 경우
클라우드 속도를 완전히 포기하지 않으면서 비용 제어 (cost controls)를 원하는 경우
프로덕션 자동화 (production automations)를 실행하며 회복 탄력성 (resilience)이 필요한 경우

많은 개발자에게 하이브리드 (hybrid) 방식은 가장 이념적이지 않으면서도 가장 정답에 가까운 답변입니다.

이를 제대로 테스트하고 싶다면, 이렇게 하세요

귀여운 프롬프트로 벤치마크 (benchmark)를 수행하지 마세요.

프로덕션 (production)에 더 가까운 무언가를 실행하세요.

예를 들어:

# OpenClaw 워크로드 테스트를 위한 체크리스트
# 로컬 및 클라우드 백엔드에 대해 동일한 작업 사용

...

다음 항목들을 추적하세요:

첫 번째 토큰 생성 시간 (time to first token)
총 단계 지연 시간 (total step latency)
컨텍스트 성장 후의 지연 시간 (latency after context growth)
실행당 비용 (cost per run)
루프 상황에서의 실패 동작 (failure behavior under loops)

그것이 바로 중요한 벤치마크입니다.

스레드를 읽은 후 나의 견해

원글 작성자(OP)의 방향은 옳았습니다.

Mac이 쓸모없기 때문이 아닙니다.

로컬 모델 (local models)이 끝났기 때문도 아닙니다.

그리고 모든 사람이 클라우드 API (cloud APIs)로 이동해야 하기 때문도 아닙니다.

그들이 옳았던 이유는 진짜 병목 현상 (bottleneck)을 식별했기 때문입니다:

OpenClaw 에이전트 워크로드 (agent workloads)는 원시 생성 속도 (raw generation speed)에서 문제가 생기기 훨씬 전부터, 프롬프트 처리 (prompt processing) 단계에서 고통을 줍니다.

이 사실은 여러분의 하드웨어 구매 방식을 바꿔 놓아야 합니다.

개인정보 보호와 완전한 로컬 제어를 원한다면, Mac을 구매하세요. 가능하다면 RAM을 최대로 올리세요. Ollama, MLX, 그리고 llama.cpp를 사용하세요. 그것은 유효한 선택입니다.

빠른 에이전트를 원한다면, 챗봇 취미가처럼 벤치마크를 하지 마세요. 프로덕션에서 에이전트를 운영하는 사람처럼 벤치마크를 하세요.

긴 컨텍스트 턴 (long-context turns)을 측정하세요.
도구 사용이 많은 루프 (tool-heavy loops)를 측정하세요.
재시도 (retries)를 측정하세요.
하위 에이전트 (subagents)를 측정하세요.
비용 동작 (cost behavior)을 측정하세요.

만약 여러분이 로컬로 기울어지는 유일한 이유가 걷잡을 수 없는 토큰 비용에 대한 두려움 때문이라면, 바로 그 지점에서 Standard Compute와 같은 서비스가 유의미해집니다. 정액제 방식의 OpenAI 호환 컴퓨팅 (OpenAI-compatible compute)은 "만약을 대비해 비싼 로컬 하드웨어를 산다"는 것이 더 이상 당연한 답이 되지 않을 정도로 경제성을 변화시킵니다.

하지만 불편한 질문은 여전히 동일합니다:

어떤 실패 모드 (failure mode)가 더 짜증 나나요: 프롬프트 처리를 기다리는 것인가요, 아니면 폭주하는 토큰 비용을 지불하는 것인가요?

이것이 진짜 OpenClaw 하드웨어 논쟁의 핵심입니다.

그 외의 모든 것은 알루미늄, VRAM, 그리고 정신 승리일 뿐입니다.