최근 저는 사람들이 인정하는 것보다 훨씬 더 흔하게 발생하는 실패 패턴을 목격했습니다:

• OpenClaw 설치
• Ollama에 연결
• 괜찮은 로컬 모델(local model) 다운로드(pull)
• 모델을 직접 테스트하면 정상 작동
• 첫 번째 실제 에이전트 턴(agent turn)을 실행하면 모든 것이 무너짐

그 시점에서 대부분의 사람들은 당연한 행동을 합니다. 바로 모델을 탓하는 것이죠.

Qwen을 Llama로 교체해 봅니다. 더 큰 모델을 써봅니다. 더 작은 모델을 써봅니다. 가중치(weights)를 다시 다운로드합니다. 양자화(quantization)를 조정합니다. 이 과정을 반복합니다.

제 생각에 그것은 대개 잘못된 첫 번째 조치입니다.

진짜 문제는 종종 프롬프트 부하(prompt baggage), 컨텍스트 예산(context budgeting), 또는 백엔드 호환성(backend compatibility) 때문입니다. 모델 자체가 아닙니다.

Ollama를 통한 직접적인 프롬프트는 아주 작은 테스트일 뿐입니다. OpenClaw 에이전트 턴은 그렇지 않습니다.

징후: Ollama 직접 실행은 성공하지만, OpenClaw는 실패함

저는 r/openclaw의 스레드를 읽었는데, Ubuntu Server를 사용하는 누군가가 단지 hello라고만 입력한 완전히 새로운 세션에서도 반복적인 오류가 발생할 수 있다고 말했습니다. 이상한 점은 동일한 모델을 4096 컨텍스트(context)와 함께 Ollama를 통해 직접 사용할 때는 "번개처럼 빠르고 훌륭하다"고 느껴졌다는 것입니다.

그것이 결정적인 단서입니다.

만약 다음과 같은 작업이 작동한다면:

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
...

하지만 OpenClaw가 일반적인 턴에서 무너진다면, 모델은 아마도 여러분의 첫 번째 문제가 아닐 것입니다.

여러분은 대개 다음 중 하나를 겪고 있는 것입니다:

• 컨텍스트 폭발(context blowout)
• 과도한 시스템 지침(system instructions)
• 너무 많은 스킬(skills) 로드
• 매 턴마다 주입되는 메모리 페이로드(memory payloads)
• 도구 스키마(tool schema) 오버헤드
• 너무 공격적인 출력 예약(output reservation) 설정
• 백엔드의 OpenAI 호환성(OpenAI-compat) 특이 사항

이러한 패턴은 OpenClaw 외부에서도 나타납니다. 저는 n8n, Make, Zapier, 그리고 맞춤형 OpenAI 호환 에이전트 스택에서도 동일한 현상을 보았습니다. 'Hello-world' 프롬프트는 통과하지만, 실제 자동화는 실패합니다. 왜냐하면 실제 운영 요청(production request)이 누구도 예상했던 것보다 훨씬 더 무겁기 때문입니다.

"새로운" OpenClaw 설치는 실제로 비어 있지 않습니다

이것이 사람들이 놓치는 부분입니다.

로컬 모델이 실제 OpenClaw 턴을 마주할 때쯤이면, 모델은 이미 다음과 같은 것들을 떠안고 있을 수 있습니다:

• system instructions
• tool definitions
• skill prompts
• memory context
• chat history
• compacted summaries
• reserved output budget

따라서, 모델이 42,967 토큰의 컨텍스트 창을 광고한다고 해서,
다음 응답에 사용할 수 있는 토큰이 42,967개라는 의미는 아닙니다.

바로 이 간극 때문에 많은

• requiresStringContent: true는 백엔드가 구조화된 messages[].content를 거부할 때 도움이 됩니다.
• supportsTools: false는 백엔드가 도구 지원(tool support)을 주장하지만 실제 도구 호출(tool-calling) 시 제대로 작동하지 않을 때 도움이 됩니다.

이것은 "가중치(weights) 문제"가 아닙니다.

이것은 배관(plumbing) 문제입니다.

배관이 잘못되었다면, Qwen에서 Llama로 교체하는 것은 그저 물이 새는 집을 재단장하는 것에 불과합니다.

reserve_tokens_floor가 실패 빈도를 높일 수 있습니다

이 설정은 안전 설정처럼 보이기 때문에 저를 놀라게 했습니다.

Reddit 스레드에서 한 댓글 작성자는 reserve_tokens_floor를 확인하고, 만약 값이 증가했다면 20,000으로 설정할 것을 언급했습니다. 값이 높을수록 에러가 더 자주 발생했기 때문입니다.

수치를 계산해 보면 이는 타당한 이야기입니다.

만약 OpenClaw가 응답을 위해 컨텍스트(context)의 거대한 부분을 예약(reserving)하고 있다면, 그 외의 모든 것을 위해 사용할 수 있는 예산은 빠르게 줄어듭니다.

여기에 다음을 더하면:

• 스킬 프롬프트 (skill prompts)
• 메모리 (memory)
• 도구 스키마 (tool schemas)
• 시스템 지침 (system instructions)
• 일부 히스토리 (some history)

모델이 광고하는 컨텍스트 창(context window)이 관대해 보일지라도, 갑자기 턴(turn)이 들어가지 않게 됩니다.

따라서 모델이 불안정하다고 느껴서 예약(reserve) 설정을 계속 높여왔다면, 여러분이 스스로 불안정성을 만들어내고 있는 것일 수도 있습니다.

/compact는 히스토리 관리에 도움이 될 수 있습니다:

/compact

하지만 매 턴마다 여전히 주입되는 거대한 시스템 프롬프트(system prompts), 로드된 스킬(skills), 메모리 페이로드(memory payloads), 또는 도구 정의(tool definitions)를 마법처럼 제거해주지는 않습니다.

스킬 비대화(Skill bloat)는 실재합니다

이것은 아무도 듣고 싶어 하지 않는 짜증 나는 답변입니다.

여러분은 더 많은 기능을 원하기 때문에 에이전트 프레임워크(agent framework)를 설치합니다.

그러면 그 기능들이 문제가 됩니다.

OpenClaw 토론에서 제가 본 가장 유용한 댓글 중 하나는 기본적으로 다음과 같았습니다: "무언가가 여러분의 컨텍스트 창을 잡아먹고 있으며, 만약 여러분이 수많은 스킬을 다운로드했다면 아마 그것 때문일 것입니다."

직설적인 표현이지만, 많은 경우 아마 맞을 것입니다.

빠르게 누적되는 몇 가지 요소들은 다음과 같습니다:

• 드림 기능 (dreaming features)
• 메모리 플러그인 (memory plugins)
• LanceDB 기반 메모리 (LanceDB-backed memory)
• 추가 오퍼레이터 스킬 (extra operator skills)
• 광범위한 도구 프로필 (broad tool profiles)
• 장기 실행 세션 히스토리 (long-running session history)

결과는 간단합니다. 모델이 더 이상 깔끔하게 맞지 않는 턴(turn)을 할당받게 됩니다.

모델을 변경하기 전에 에이전트를 간소화하세요

로컬 OpenClaw 설치를 디버깅하고 있다면, 가능한 한 가장 작고 재현 가능한 설정(reproducible setup)을 원할 것입니다.

그것은 다음을 의미합니다:

1. 로드된 기술(skills) 축소
2. 메모리(memory) 단순화 또는 비활성화
3. LanceDB 없이 테스트
4. 가능한 가장 좁은 도구 프로필(tool profile) 사용
5. 프롬프트(prompt)를 단조롭게 유지

여기서는 OpenClaw의 도구 프로필 기본값이 중요합니다. 새로운 로컬 설정은 종종 coding으로 기본 설정되지만, 다음과 같은 차이가 있습니다:

• minimal은 session_status만 허용합니다.
• messaging은 좁은 범위를 유지합니다.
• full은 프로필 제한을 제거합니다.

즉, Qwen, Llama 또는 다른 어떤 모델이 토큰(token)을 생성하기도 전에 도구 프로필이 동작을 변화시킨다는 의미입니다.

만약 최소 프로필(minimal profile)은 작동하고 더 넓은 프로필이 실패한다면, 중요한 사실 하나를 배운 것입니다.

ollama 모델 전환 전 나의 실질적인 체크리스트

제가 사용하는 순서는 다음과 같습니다.

1. 모델이 직접 작동하는지 증명하기

Ollama에 대해 일반적인 요청을 실행합니다.

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
...

이것이 실패한다면, Ollama를 먼저 해결하세요.

이것이 작동한다면, 계속 진행하세요.

2. OpenClaw 진단 실행하기

openclaw status
openclaw doctor
openclaw logs --follow

로그(logs)를 건너뛰지 마세요.

3. 컨텍스트 폭발(context blowout) 확인하기

만약 로그가 컨텍스트 압박(context pressure)을 가리킨다면, 그 말을 믿으세요.

모델의 광고된 컨텍스트 창(window)이 충분히 커 보인다고 해서 증거와 계속 싸우지 마세요.

4. 에이전트 축소하기

임시로 부가적인 요소들을 제거하세요:

• 더 적은 기술(skills)
• 더 적은 메모리(memory)
• LanceDB 제외
• 더 좁은 도구 프로필(tool profile)
• 짧은 테스트 프롬프트(test prompt)

실패 원인이 에이전트 오버헤드(agent overhead) 때문인지 알고 싶을 것입니다.

5. 예약 설정(reserve settings) 재검토

만약 reserve_tokens_floor를 높였다면, 다시 낮추고 재테스트하세요.

"안전"해 보이는 예약 예산(reserve budget)이 턴(turn)을 맞추는 것을 훨씬 더 어렵게 만들 수 있습니다.

6. 호환성 플래그(compat flags) 확인

백엔드가 구조화된 콘텐츠(structured content)나 도구(tools)와 함께 불안정하다면, 다음을 시도해 보세요:

compat:
  requiresStringContent: true
  supportsTools: false

7. 그제서야 모델이나 백엔드(Backend)를 교체하세요

그리고 반드시 타당한 이유를 가지고 교체해야 합니다:

• 더 나은 컨텍스트(Context) 동작
• 더 나은 OpenAI 호환성 (OpenAI-compat) 처리
• 더 안정적인 도구 지원 (Tool support)
• 더 적은 런타임 특이사항 (Runtime quirks)

단순히 인내심이 바닥났기 때문이 아니라 말이죠.

스택(Stack)을 교체하는 것이 합리적인 결정인 경우

저는 실험을 위해 로컬 스택(Local stacks)을 선호합니다.

프롬프트(Prompt)를 테스트하고, 에이전트(Agent) 아이디어를 시도하며, 더 큰 작업에 전념하기 전에 워크플로우(Workflow)를 검증하는 데 매우 훌륭하기 때문입니다.

하지만 매일 에이전트를 실행하려고 한다면, 기준이 달라집니다.

다음과 같은 요소가 필요합니다:

• 안정적인 OpenAI 호환 동작
• 예측 가능한 도구 호출 (Tool calling)
• 더 적은 호환성 예외 케이스 (Compat edge cases)
• 컨텍스트 및 토큰 예산 (Token budgets)에 대한 관리 부담 감소
• 자동화가 24/7 실행될 때의 비용 예측 가능성

이것이 바로 많은 팀이 결국 로컬 스택과의 싸움을 멈추고 더 깔끔한 API 레이어(Layer)로 이동하는 지점입니다.

만약 n8n, Make, Zapier, OpenClaw 또는 커스텀 워크플로우에서 에이전트를 구축하고 있다면, 문제는 대개 단순히 "이 모델이 답변할 수 있는가?"가 아닙니다.

진짜 질문은 이것입니다:

이 엔드포인트(Endpoint)가 실제 에이전트 부하(Load) 하에서도 일관되게 동작할 수 있는가?

그것은 차원이 다른 기준입니다.

또한, 이것이 프로덕션 자동화(Production automations)에서 정액제 OpenAI 호환 서비스가 매력적인 이유이기도 합니다. 워크플로우가 도구 호출, 재시도(Retries), 메모리, 긴 프롬프트, 그리고 지속적인 백그라운드 실행을 수행할 때, 토큰당 과금 방식은 모든 디버깅 세션을 비용 계산 문제로 만들어 버립니다.

이는 금방 지치게 만듭니다.

Standard Compute는 이 지점에서 흥미로운데, 월정액으로 무제한 AI 컴퓨팅을 제공하는 OpenAI 호환 엔드포인트를 제공하기 때문입니다. 따라서 매 턴마다 토큰 지출을 감시하지 않고도 에이전트와 자동화를 실행할 수 있습니다. 로컬 백엔드의 특이사항을 디버깅하느라 지쳤고, 프로덕션에서 토큰당 과금 방식으로 인해 손해를 보는 상황이라면 이 모델이 매우 합리적일 것입니다.

핵심 요점

만약 모델이 Ollama에서는 작동하는데 OpenClaw에서는 죽는다면, 모델의 장례식을 치르는 것부터 시작하지 마세요.

프롬프트에 무엇이 함께 실려 가고 있는지 묻는 것부터 시작하세요.

대부분의 신규 설치 실패는 "이 모델이 멍청해서" 발생하는 것이 아닙니다.

대개 다음 중 하나입니다:

• 숨겨진 프롬프트 오버헤드 (hidden prompt overhead)
• 예산 예약 실수 (reserve-budget mistakes)
• 도구/프로필 비대화 (tool/profile bloat)
• 메모리 주입 (memory injection)
• 백엔드 호환성 불일치 (backend compatibility mismatches)

이것들은 해결 가능합니다.

그리고 만약 해결할 수 없다면, 적어도 더 나은 모델이 필요한지, 더 나은 백엔드가 필요한지, 아니면 더 나은 스택 (stack)이 필요한지 알게 될 것입니다.