• 서론: 로컬 LLM 환경에서 마주하는 「수수께끼의 벽」

MacBook M5 Pro (CPU 18Core / GPU 20Core / 메모리 64GB)라는 최상급 머신에 LM Studio와 OpenClaw를 조합하여, Qwen3.6 (35B-A3B)와 같은 중량급 모델을 구동한다. 로컬 LLM을 추구하는 엔지니어에게 이보다 가슴 설레는 셋업은 없습니다.

하지만 기대를 품고 프롬프트 (Prompt)를 입력하는 순간, 처리가 시작되는 대신 무정한 경고가 표시될 때가 있습니다.

「Auto-compaction could not recover this turn」

이 메시지가 뜨면 화면의 지시대로 /compact 명령어로 압축을 시도하거나, /new로 세션을 새로 시작해도 전혀 해결되지 않는 「절망의 루프」에 빠질 수 있습니다. 최강의 하드웨어를 갖췄음에도 왜인지 눈앞의 AI가 움직이지 않는다. 그런 엔지니어의 「수수께끼의 벽」을 돌파하기 위한, 로그 (Log)에 숨겨진 진실을 말씀드리겠습니다.

• 【충격적인 사실 1】 에러 메시지의 「지시」가 반드시 정답은 아니다

에러 화면에는 매우 구체적이고 친절해 보이는 조언이 표시됩니다. 「agents.defaults.compaction.reserveTokensFloor를 20000 또는 그 이상으로 설정하십시오」

하지만 여기에는 큰 함정이 있습니다. 사실 이번 케이스에서 이 조언은 해결은커녕 **상황을 악화시키는 「덫」**이었습니다.

왜냐하면, reserveTokensFloor (예비 토큰)를 늘리는 행위는 이용 가능한 프롬프트 예산 (Prompt Budget)을 더욱 「깎아먹는」 것을 의미하기 때문입니다. 전체 그릇 (컨텍스트 윈도우 (Context Window))이 충분히 확보되지 않은 상태에서 예비 토큰만 늘려봤자, 계산상의 빈 공간이 없어질 뿐입니다. 표면적인 지시를 그대로 믿는 것은 디버깅 (Debugging)에 있어 가장 위험한 길입니다.

"ChatGPT나 화면의 에러 메시지를 그대로 믿지 말고, 문제가 발생했을 때는 에러 로그도 반드시 확인하자!"

• 【충격적인 사실 2】 AI의 제안 (ChatGPT)이 통하지 않는 「맹점」이 있다

자력으로 해결할 수 없을 때, 우리는 ChatGPT에 매달립니다. 실제로 이 트러블을 상담했을 때도, AI로부터는 그럴싸한 3가지 대책이 제안되었습니다.

• openclaw.json의 reserveTokensFloor를 20000으로 설정한다 (UI와 동일한 지시)
• 기존 세션을 삭제한다
• OpenClaw를 재설치한다

안타깝게도 이 대책들을 모두 시도해 보았지만 상황은 1mm도 개선되지 않았습니다.

ChatGPT는 일반적인 베스트 프랙티스 (Best Practice)를 제시해 주지만, MacBook M5 Pro 64GB라는 풍부한 리소스를 가진 환경과 소프트웨어 측의 제한값 사이의 「괴리」까지는 꿰뚫어 보지 못합니다. 고스펙 환경이기에 오히려 발생하는, 설정의 「불일치」라는 맹점이 존재합니다.

• 【충격적인 사실 3】 진정한 답은 「로그」 속의 수치 계산에 숨겨져 있었다

해결의 열쇠는 UI의 친절한 메시지를 무시하고, OpenClaw의 「생(Raw) 에러 로그」를 들여다본 순간 발견되었습니다. 로그에는 냉철한 산술 결과가 기록되어 있었습니다.

• estimatedPromptTokens (추정 프롬프트 토큰): 4785
• promptBudgetBeforeReserve (예비 전 예산): 4500
• overflowTokens (오버플로): 285
• effectiveReserveTokens (유효 예비 토큰): 4500

여기서 읽어낼 수 있는 사실은 불과 285 토큰의 부족입니다. 더욱 주목해야 할 점은 예산의 토대가 되는 수치가 4500 전후로 고정되어 있다는 점입니다. 화면의 지시대로 reserveTokensFloor (바닥)를 아무리 높게 설정해도, 이 「예산의 천장」이 낮은 상태라면 프롬프트가 들어갈 틈 따위는 생길 리가 없습니다.

진정한 병목 현상 (Bottleneck)은 버퍼 (Buffer) 설정이 아니라, OpenClaw가 인식하고 있는 「컨텍스트 윈도우 (Context Window, 전체 그릇)」의 사이즈 부족이었습니다.

• 해결편: openclaw.json의 「contextWindow」를 수정하기

근본적인 원인은 OpenClaw 측의 설정 파일에서 사용 중인 Qwen 모델에 할당된 contextWindow가 LM Studio 측의 설정과 동기화되지 않아 너무 작게 설정되어 있었던 것이었습니다.

최종 해결 절차

설정을 변경하기 전에 반드시 openclaw.json의 백업을 생성하십시오. 그 후, 해당 모델의 contextWindow를 적절한 값(예: 20000)으로 높여줍니다.

"models": [

{

"id": "qwen/qwen3-next-80b", // 또는 사용 중인 qwen3.6-35b-a3b

"name": "qwen/qwen3-next-80b",

"contextWindow": 20000,

"maxTokens": 10000

}

]

이 변경 사항을 저장하는 순간, 그동안 발생하던 「Auto-compaction」 에러가 거짓말처럼 사라졌고, Qwen3.6으로의 실행 문장이 정상적으로 전달(delivery)되기 시작했습니다.

기술적 통찰: 동기화의 중요성

OpenClaw는 오케스트레이터 (Orchestrator)로서 독자적인 「클라이언트 측 제한 (Client-side limit)」을 가지고 있습니다.

• LM Studio (백엔드 (Backend)): 모델이 처리할 수 있는 광대한 컨텍스트 (Context)를 설정
• OpenClaw (프론트엔드 (Frontend)): openclaw.json에 정의된 contextWindow로 제한

이 두 가지가 동기화되지 않으면, 백엔드에 아무리 여유가 있더라도 OpenClaw 측에서 임의로 "넘쳤다!"라고 판단하여 처리를 중단해 버립니다. 고사양 머신을 제대로 활용하려면 이 양측의 파이프라인 (Pipeline)을 동일하게 확장해야 합니다.

• 마치며: 디버깅 (Debugging)의 본질로 돌아가기

이번 트러블을 통해 얻은 교훈은 간단합니다. **"도구가 편리해질수록, 가공되지 않은 데이터 (로그 (Log))를 보는 습관이 중요하다"**는 것입니다.

MacBook M5 Pro라는 괴물 같은 머신을 사용하고 있더라도, 설정 파일의 단 한 줄, 불과 285 토큰의 계산 실수만으로 시스템은 침묵합니다. UI의 메시지나 AI의 조언은 어디까지나 「2차 정보」이며, 엔지니어가 마지막으로 신뢰해야 할 것은 시스템이 내뱉은 「1차 정보 (로그 (Log))」입니다.

다음에 에러가 발생했을 때, 당신은 화면의 친절한 말을 믿겠습니까? 아니면 뒷면에서 이빨을 드러내는 로그의 수치를 믿겠습니까?

※ 유튜브에도 영상을 업로드했습니다