OpenClaw는 주말 프로젝트에서 시작해 5개월도 채 되지 않아 GitHub에서 가장 많은 별을 받은 저장소 중 하나가 되었으며, 이제 모든 사람이 자신의 편지함, 캘린더, 그리고 디지털 생활 전체를 운영하기 위해 이를 사용하고 있습니다. 저는 그 반대를 원했습니다. 그 생태계의 가능한 한 작은 조각을 가져와, 로컬 우선(local-first)으로 실행하며, 하나의 지루한 작업인 인프라 모니터링을 잘 수행하는 것이었습니다. 제가 실제로 그것을 구축하려고 시도했을 때 일어난 일은 다음과 같습니다.

더 큰 생태계, 그리고 내가 실제로 원했던 더 작은 조각

OpenClaw는 "AI 에이전트"라는 말이 챗봇을 의미하는 것을 넘어, 이메일을 읽고, GitHub 이슈를 정리하며, 캘린더 일정을 재조정하고, Discord나 Telegram 인터페이스를 통해 반자율적으로 실행되는 무언가를 의미하게 만든 주역입니다. 이는 인상적입니다. 완전한 에이전트 함대(agent fleets), 수십 개의 서비스에 대한 OAuth, 음성 모드, 전화 앱까지 갖추고 있습니다. 하지만 이는 제가 실제로 원했던 것과는 완전히 맞지 않는 형태였습니다. 제가 원한 것은 제가 책임지는 인프라 근처에서 무인으로 실행되는 것을 신뢰할 수 있을 만큼 충분히 작은 것이었습니다.

그것이 저를 PicoClaw로 이끌었습니다. PicoClaw는 확장을 지양하면서도 동일한 핵심 아이디어(모델, 도구 세트, 샌드박스 작업 공간, 통신 채널)를 유지하는 훨씬 더 가볍고 CLI 우선(CLI-first)인 에이전트 런타임(runtime)입니다. 편지함 통합도, 캘린더도, 수십 개의 서비스에 대한 OAuth 접점도 없습니다. 그저 작업 공간 폴더와 제가 명시적으로 허용한 도구 세트를 향해 있는 에이전트 루프(agent loop)뿐입니다.

설치는 쉬운 부분이었습니다. 진짜 작업은 그 안에서 실제로 실행할 모델을 어떤 것으로 신뢰할지 결정하는 것부터 시작되었습니다.

의도적으로 구성한 최소한의 스택

에이전트 런타임:  PicoClaw (CLI, 웹 UI 없음, Docker 없음)
Tier 1 로컬:   테스트 완료 — 아직 채택되지 않음 (아래 참조)
Tier 2 로컬:   Qwen3, no-think 설정
...

PicoLM(사소한 단답형 답변을 위해 설계된 아주 작고 즉각적인 응답을 제공하는 로컬 모델)은 설치된 채로 손도 대지 않고 있습니다. 인프라 모니터링 맥락에서 아직은 사용할 사례가 없습니다. "지금 몇 시야?" 같은 질문은 제가 해결하려는 문제가 아닙니다. 그렇게 빠른 모델로 라우팅할 가치가 있는 실제 저위험, 고빈도 작업이 생기면 다시 검토할 목록에 올려두었습니다.

진정한 작업은 Tier 1 이상의 모든 과정에 걸쳐 이루어졌습니다.

로컬 모델 테스트: 많은 가능성, 그러나 충분하지 않은 신뢰

저는 로컬 모델(Gemma 또는 Qwen과 같이 완전히 온디바이스(on-device)에서 실행되는 모델)이 실제 분석 작업에 충분히 훌륭할 것이라고 기대하며 시작했습니다. 온라인상의 많은 사람들이 에이전트의 도구 사용(tool-use)을 위해 정확히 그 조합을 성공적으로 실행하고 있으며, 저는 그들을 의심하지 않습니다. 저는 Gemma4의 여러 변체와 몇 가지 Qwen 빌드를 시도했으며, 특히 단순한 대화 품질보다는 도구 호출(tool-calling)의 신뢰성을 중점적으로 스트레스 테스트했습니다. read_file이나 run_command를 안정적으로 호출할 수 없는 에이전트는 문장이 아무리 유창하더라도 무용지물이기 때문입니다.

그 테스트를 통해 두 가지 결과가 도출되었습니다:

추론 모드(Reasoning mode)를 꺼야 하며, 그 방법은 예상과는 다릅니다. Qwen3의 기본 "사고(thinking)" 출력은 개방형 추론에는 훌륭하지만, 깨끗하고 즉각적인 도구 호출을 기대하는 에이전트 루프(agent loop)에는 매우 해롭습니다. 모델이 무언가를 호출하기도 전에 스스로 말을 뱅뱅 돌며 논리를 낭비하기 때문입니다. 명백한 해결책은 런타임 플래그(runtime flag)를 사용하는 것입니다:

PARAMETER think false

하지만 이는 Error: unknown parameter 'think'를 발생시킵니다. Ollama의 Modelfile 구문은 작동하는 다른 모든 PARAMETER 라인과 똑같이 생겼음에도 불구하고 이를 전혀 지원하지 않습니다.

실제 해결책은 파라미터 블록이 아니라 프롬프트 템플릿(prompt template)에서 이루어져야 합니다. TEMPLATE이 다음 세 가지 특정 작업을 수행하는 Modelfile을 통해 커스텀 모델을 구축해야 합니다:

1. 모델에 도달하기 전 모든 사용자 메시지 끝에 /no_think를 추가합니다.
2. 어시스턴트 응답이 렌더링될 때 모든 <think>...</think> 블록을 제거합니다.
3. 모든 어시스턴트 턴의 시작 부분에 빈 `<think>

</think>` 쌍을 강제로 삽입하여, Qwen3에게 "사고 단계"가 이미 완료되었음을 신호함으로써 모델이 즉시 콘텐츠나 도구 호출로 넘어가도록 합니다.

cat > /tmp/qwen3-nothinker.modelfile << 'EOF'
FROM qwen3:8b

...

(가독성을 위해 생략됨 — 전체 템플릿은 도구 호출 형식 지정 및 멀티 턴 히스토리(multi-turn history)도 처리합니다)

그다음 에이전트 설정(agent config)을 일반적인 qwen3:8b 태그가 아닌 qwen3-local로 지정하세요. 커스텀 빌드는 Ollama에서 별도로 명명된 모델이므로, 수정 사항이 암시적으로 적용되지 않습니다. 에이전트에 연결하기 전에 ollama run qwen3-local "hello"를 빠르게 실행하여 응답에 <think> 블록이 유출되지 않는지 확인합니다.

진짜 장애물은 성능(capability)이 아니라 환각(Hallucination)이었습니다. 도구 호출(tool-calling)이 안정화되자 진짜 문제가 드러났습니다. 바로 답변을 신뢰할 수 있느냐는 점이었습니다. 다단계(multi-step) 또는 다중 파일 분석 시, 로컬 모델들은 존재하지 않는 파일, 일치하지 않는 로그 라인, 그럴듯하게 들리지만 완전히 틀린 결론 등 존재하지 않는 것들을 자신 있게 보고하곤 했습니다. 일반적인 어시스턴트에게는 짜증스러운 정도겠지만, 인프라 상태가 정상인지 판단하는 용도라면 자신 있게 틀린 답변을 내놓는 것은 답변이 없는 것보다 더 나쁩니다.

이것이 클라우드 API를 통한 DeepSeek V4 Flash가 결국 3단계(tier-3) 모델로 선정된 실제 이유입니다. 로컬 모델이 나쁘기 때문이 아니라(많은 사람들이 바로 이런 종류의 에이전트를 위해 Gemma4와 Qwen을 잘 작동시키고 있습니다), 모든 호출을 온디바이스(on-device)로 유지하는 것보다 신뢰성과 번거로움이 적은 것이 저에게 더 중요했기 때문입니다. 이는 실용적인 결정이며, 로컬 모델 전반에 대한 판결은 아닙니다. 낮은 위험도의 작업(lower-stakes tasks)을 위해 Gemma4와 Qwen을 추가로 테스트하는 것은 여전히 계획에 있습니다.

하나의 설정 그 이상의 의미

여기서 보이는 더 큰 패턴은 OpenClaw 흐름을 타고 구축하는 많은 사람들이 결국 마주하게 될 문제입니다. 에이전트 프레임워크(agent framework) 자체는 더 이상 어려운 부분이 아닙니다. CLI 에이전트, 샌드박스(sandbox), 그리고 모델을 연결하는 것은 주말이면 끝납니다. 실제 엔지니어링은 지루한 중간 계층(middle layer)에 있습니다. 즉, 어떤 모델이 작업별, 단계별로 위임할 만큼 충분히 신뢰할 수 있는지 결정하는 것, 그리고 더 화려해 보이는 로컬 전용 설정이 실제로는 더 신뢰할 수 있는 것이 아닐 때 솔직해지는 것입니다.

특히 인프라 모니터링 (infrastructure monitoring)의 경우, 그 지루한 중간 계층 (middle layer)이 평소보다 더 중요합니다. 채팅 앱에서의 잘못된 출력은 그냥 나쁜 답변일 뿐입니다. 하지만 프로덕션 인프라 (production infrastructure)에 대한 자동화된 점검에 잘못된 출력이 입력된다면, 이는 잘못된 보안 신뢰감 (false sense of security)을 주며, 이는 어쩌면 자동화를 아예 하지 않는 것보다 더 나쁠 수 있습니다.

다음 단계

위에서 언급한 모델 라우팅 (model-routing) 결정은 준비 작업이었습니다. 실제 테스트(이 에이전트를 실제 인프라에 대한 실제 감사 작업에 투입하고, 클라우드 기반 모델이 분석을 수행하는 것)는 다음에 진행됩니다. 파트 2에서는 그 결과가 어떠했는지, 즉 무엇을 잡아냈고 무엇을 틀렸는지, 그리고 신뢰성을 위해 DeepSeek을 선택한 도박이 깨끗한 테스트 환경 밖에서도 유효했는지를 다룹니다.

인프라 모니터링을 위한 최소한의 로컬 우선 (local-first) AI 에이전트 스택 구축에 관한 짧은 시리즈의 파트 1입니다. 스택: PicoClaw (CLI 전용), Qwen3 (로컬 계층, no-think 설정), 자체 호스팅된 LiteLLM 프록시를 통한 DeepSeek V4 Flash (클라우드 계층).