OpenClaw와 관련하여 동일한 디버깅 실수를 계속해서 목격하고 있습니다.

에이전트가 멈춥니다.
Telegram이 조용해집니다.
iPhone 앱의 연결이 끊깁니다.
누군가는 GPT-5.4가 나빠졌다고 말합니다. 다른 누군가는 Claude를 탓합니다. 그러고 나서 팀은 단 하나의 트레이스(trace)도 확인하지 않은 채 모델을 교체하기 시작합니다.

이해합니다. 외부에서 보기에는 "LLM이 응답을 중단했다"는 현상이 모델의 문제처럼 보일 수 있습니다.

하지만 OpenClaw 문서, 인시던트(incident) 패턴, 그리고 한 사용자는 iOS 앱을 "엉망진창(a hot mess)"이라고 부르고 다른 사용자는 기본적으로 "그냥 검사하고 고치면 된다"라고 말한 r/openclaw 스레드를 파헤쳐 본 결과, 저는 진짜 패턴이 이것이라고 생각합니다:

대부분의 OpenClaw '나쁜 모델' 불만은 사실 관측 가능성(observability)의 실패입니다.

모두가 그런 것은 아닙니다.
하지만 사람들이 인정하고 싶어 하는 것보다 훨씬 더 많습니다.

그리고 이것은 OpenClaw 너머의 문제이기도 합니다. 만약 여러분이 n8n, Make, Zapier, OpenClaw 또는 자체 루프(loops)에서 에이전트를 실행한다면, 동일한 일이 끊임없이 발생합니다:

• 멈춰버린 MCP 서버를 Claude의 탓으로 돌림
• OpenAI 429 오류를 GPT-5.4의 탓으로 돌림
• Telegram 인증 문제를 프롬프트 품질의 탓으로 돌림
• 재시도 폭풍(retry storm)을 "제공업체 불안정성"의 탓으로 돌림

이것이 바로 실제 문제가 스택(stack)의 더 낮은 곳에 있음에도 불구하고 팀들이 며칠 동안 모델 쇼핑을 하며 시간을 낭비하는 방식입니다.

예측 가능한 AI 운영(AI ops)에 관심이 있다면, 모델이 실제로 유죄인지, 아니면 인프라가 모델을 유죄처럼 보이게 만든 것인지 구분할 줄 알아야 합니다.

내가 실행할 첫 5가지 명령어

OpenClaw는 이미 적절한 1차 진단 도구를 제공합니다:

openclaw status
openclaw gateway status
openclaw logs --follow
...

이 목록은 네 가지 실패 클래스(failure classes)를 꽤 빠르게 구분해 줍니다:

1. iOS 또는 Telegram 채널 문제
2. OpenClaw 런타임(runtime) 또는 게이트웨이(gateway) 문제
3. 도구 호출(tool call) 지연
4. 업스트림(upstream) 모델/API 실패

만약 이 단계를 건너뛰고 GPT-5.4에서 바로 Claude Opus 4.6으로 넘어간다면, 그것은 디버깅이 아닙니다.
그것은 주사위를 던지는 것입니다.

왜 모델 교체가 때때로 문제를 해결한 것처럼 보이는가

타이밍 버그(timing bugs)는 거짓말을 하기 때문입니다.

모델을 바꾸는 것은 "품질"보다 훨씬 더 많은 것을 변화시킵니다:

• 지연 시간 (latency)
• 재시도 타이밍 (retry timing)
• 페이로드 크기 (payload size)
• 페이싱 (pacing)
• 타임아웃 동작 (timeout behavior)

그것은 고장 난 MCP 호출, 불안정한 Telegram 폴러 (poller), 또는 게이트웨이 레이스 컨디션 (race condition)을 숨기기에 충분할 수 있습니다.

따라서 GPT-5.4에서 Claude Opus 4.6으로 전환하는 것이 문제를 해결한 것처럼 보일 수도 있습니다.
하지만 종종 당신이 증명한 것은, 동일한 취약한 경로가 약간 다른 타이밍(timing) 하에서 다르게 동작했을 뿐이라는 사실입니다.

그것은 근본 원인 (root cause)이 아닙니다.
그것은 운 좋게 포장된 우연일 뿐입니다.

Telegram은 가짜 모델 실패를 만들어내는 데 탁월합니다

Telegram 문제는

• iPhone 앱이 2:14에 멈춤
• Telegram이 2:15에 재연결됨
• 도구 타임아웃 (tool timeout)이 2:15:03에 발생함
• OpenAI가 2:15:04에 429 에러를 반환함

그 타임라인은 “오늘 Claude가 좀 이상한 것 같아”라고 말하는 열 개의 Slack 메시지보다 훨씬 더 가치가 있습니다.

최소한의 로깅 설정 (Minimal logging setup)

{
  "logging": {
    "file": "/path/to/openclaw.log"
...

그다음 상황이 잘못되기 시작할 때 JSON 모드로 tail 명령어를 사용하세요:

openclaw logs --follow --json

또한 유용한 명령어:

openclaw status --all
openclaw status --deep

--all은 복사 가능한 보고서를 제공합니다.
--deep은 실시간 게이트웨이 상태(gateway health)와 채널 프로브(channel probes)를 추가합니다.

이것이 바로 팀이 여러 사고(incidents)에 걸쳐 비교할 수 있는 종류의 아티팩트(artifact)입니다.

트레이스(Trace) 수준의 디버깅은 논쟁이 보통 종결되는 지점입니다

이 부분이 실제로 사람들의 생각을 바꾸는 대목입니다.

OpenClaw는 OpenTelemetry 트레이스(traces), 메트릭(metrics), 로그(logs)를 내보낼 수 있습니다.
즉, 다음과 같은 모호한 질문을 던지는 것을 멈출 수 있다는 뜻입니다:

“Claude가 멈췄나요?”

대신 다음과 같은 유용한 질문을 시작할 수 있습니다:

• 프롬프트 빌드(prompt build)가 완료되었는가?
• 모델 해상(model resolution)이 완료되었는가?
• 서브에이전트(subagent)가 반환되었는가?
• MCP 도구 호출(tool call)이 지연되었는가?
• 제공자(provider) 타임아웃이 발생했는가?

최신 OpenClaw 릴리스에는 실패한 도구 호출 및 서브에이전트 전파(subagent propagation)에 대한 더 나은 트레이스 상세 정보가 추가되었습니다. 이는 무작위적인 모델 불안정성(flakiness)처럼 보이는 사고 상황에서 정확히 필요로 하는 기능입니다.

OpenTelemetry 설정 예시

{
  "plugins": {
    "allow": ["diagnostics-otel"],
...

이를 Grafana Tempo, Jaeger, Honeycomb 또는 Datadog으로 파이프라인 연결하세요.

이제 “에이전트가 멈췄다”는 것은 테스트 가능한 주장이 됩니다.

이것이 거대한 변화입니다.
부모 에이전트(parent agent), 서브에이전트(subagent), 압축(compaction), 그리고 MCP 실행에 걸친 스팬(spans)을 확보하고 나면, 책임 소재는 빠르게 좁혀집니다.

때로는 모델이 여전히 유죄일 수도 있습니다.
하지만 대개는 그렇지 않습니다.

업스트림 API 실패는 앱 멈춤 현상과 똑같이 보입니다

이 문제는 자동화 팀에 큰 타격을 줍니다.

n8n, Make, Zapier 또는 커스텀 워커(custom worker)에서 눈에 보이는 증상은 대개 다음과 같습니다:

• 단계(step)가 멈춤
• 봇이 영원히 타이핑 중인 상태로 표시됨
• 워크플로우가 대기하다가 조용히 실패함

그것은 분명히 모델(model) 문제일 수 있습니다.
또한 할당량(quota), 인증(auth), 또는 속도 제한(rate limiting) 문제일 수도 있습니다.

OpenAI 스타일의 API는 UI상에서 모두 동일해 보이는 여러 가지 이유로 실패할 수 있습니다:

• 401 unauthorized (인증되지 않음)
• 429 rate limited (속도 제한됨)
• 429 credits are exhausted (크레딧 소진)
• 429 spend limit was hit (지출 한도 도달)
• 500/503 upstream instability (업스트림 불안정성)

만약 제공자(provider)의 응답과 헤더(headers)를 캡처하고 있지 않다면, 속도가 제한된(throttled) API 호출은 불안정한 Telegram 세션과 똑같아 보일 수 있습니다.

이것이 바로 “LLM이 응답을 멈췄다”라는 말이 끔찍한 진단인 이유입니다.
그것은 근본적인 원인이 아니라, 눈앞에 보이는 증상만을 설명하기 때문입니다.

모델 선택을 변경하기 전 나의 디버깅 순서

그리고 실질적인 순서는 다음과 같습니다:

openclaw status
openclaw gateway status
openclaw logs --follow --json
...

그 다음:

1. Telegram 페어링 / BotFather 토큰 / 개인정보 보호 모드(Privacy Mode) 확인
2. api.telegram.org로 가는 DNS, 프록시(proxy), 그리고 IPv6 경로 확인
3. 제공자 응답 코드 및 속도 제한(rate-limit) 동작 조사
4. 문제가 반복된다면, OpenTelemetry를 활성화하고 스팬(spans)을 엔드 투 엔드(end to end)로 조사

지루한 작업입니다.
하지만 확실히 효과가 있습니다.

네, 때로는 정말로 모델 문제일 때가 있습니다

GPT-5.4나 Claude Opus 4.6이 결코 퇴보하지 않는다고 말하는 것이 아닙니다.
퇴보합니다.

OpenClaw 자체도 빠르게 변화하며, 빠르게 움직이는 런타임(runtimes)에는 반드시 버그가 포함되기 마련입니다.

하지만 바로 그렇기 때문에 트레이스(traces)가 중요합니다.

만약 스팬(spans)이 다음과 같이 보여준다면:

• Telegram이 메시지를 전달함
• 프롬프트 빌드(prompt build) 완료
• MCP가 빠르게 응답함
• 서브에이전트(subagent) 완료
• Claude가 에러가 나기 전까지 38초를 소비함

그렇다면 좋습니다 — 이제 당신은 실제 증거를 확보한 것입니다.
Claude를 탓하십시오.

만약 스팬이 Telegram이 메시지를 전혀 전달하지 못했음을 보여준다면, 모델을 탓하는 것을 멈추십시오.

관측성(Observability)은 맹목적으로 누군가를 면제해 주는 것이 아니라, 책임을 좁혀나가야 합니다.

주의해야 할 한 가지

OpenClaw의 콘솔 레드액션(redaction, 정보 마스킹)은 전체 로그 레드액션과는 다릅니다.
운영 환경(production)에서 로깅과 트레이싱을 대폭 강화한다면, 다음 사항을 고려하십시오:

• secrets (비밀 정보)
• PII (개인 식별 정보)
• tool outputs (도구 출력값)
• where trace data gets stored (트레이스 데이터가 저장되는 위치)

좋은 관측성 (observability)은 매우 훌륭합니다.
하지만 민감한 데이터를 로그에 유출하는 것은 결코 그렇지 않습니다.

많은 에이전트를 운영하는 팀에게 이것이 중요한 이유

취미로 봇을 하나만 운영한다면, 무작위로 모델을 교체하는 것은 그저 번거로운 일일 뿐입니다.

하지만 OpenClaw, n8n, Make, Zapier 또는 커스텀 워커 (custom workers)를 통해 실제 자동화 (automations)를 운영하고 있다면, 잘못된 진단은 빠르게 비용 문제로 이어집니다.

당신은 가짜 증거를 바탕으로 라우팅 (routing) 결정을 내리기 시작할 것입니다.
재시도 (retries) 로직을 수정해야 할 때 제공업체를 교체하게 됩니다.
인증 (auth) 문제를 해결해야 할 때 프롬프트 (prompts)를 수정하게 됩니다.
실제 병목 현상 (bottleneck)은 그대로 방치된 채, 토큰 소모량과 지연 시간 (latency)이 널뛰는 것을 지켜보게 될 것입니다.

그렇기에 여기서 얻을 수 있는 더 큰 교훈은 단순히 "OpenClaw에서 트레이스 (traces)를 사용하라"는 것이 아니라고 생각합니다.
그것은 바로 이것입니다:

모델 선택을 첫 번째 디버깅 (debugging) 도구로 취급하지 마십시오. 마지막 도구 중 하나로 취급하십시오.

그리고 많은 에이전트 트래픽을 운영하고 있다면, 이 지점부터 인프라 (infrastructure) 선택이 중요해지기 시작합니다.
GPT-5.4인지 Claude Opus 4.6인지가 실제로 문제인지 이미 알고 있는 상태라면, 모델 간 라우팅이 가능하고, 급증하는 트래픽 (bursts)을 완만하게 처리하며, 비용을 예측 가능하게 유지할 수 있는 백엔드 (backend)가 훨씬 더 유용합니다.

그것이 Standard Compute와 같은 서비스의 매력입니다. OpenAI 호환 API, 고정된 월간 가격, 그리고 이번 주에 어떤 모델이 "더 별로였는지" 논쟁하는 대신 실제 문제를 해결하는 동안 토큰당 비용 때문에 패닉에 빠질 필요가 없습니다.

최종 결론

만약 당신의 OpenClaw iPhone 앱이나 Telegram 봇이 저주받은 것처럼 느껴진다면, 모델 교체부터 시작하지 마십시오.
증거부터 시작하십시오.

내장된 상태 명령어를 실행하십시오.
로그를 테일링 (tail) 하십시오.
채널을 조사 (probe) 하십시오.
제공업체 오류를 확인하십시오.
트레이스 (traces)를 켜십시오.

"Claude가 멈췄다"는 사건이 알고 보니 BotFather 401 오류, Telegram 개인정보 설정, 또는 OpenAI 429 오류였다는 것을 한 번이라도 경험하고 나면, 당신은 더 이상 모델 교체를 만병통치약처럼 취급하지 않게 될 것입니다.

당신은 모델 교체를 원래 의도했던 방식대로 취급하기 시작할 것입니다:

나머지 스택 (stack)이 깨끗하다는 것을 증명한 뒤에 수행하는, 마지막 단계의 최적화 (optimization)로 말입니다.