요약 (TL;DR): OpenClaw 7.1 beta 버전을 설치했다가 마음에 들지 않아 6.6 stable 버전으로 다운그레이드했습니다. 그러자 AI 어시스턴트의 API 소비량이 400% 폭증했습니다. 단순한 질문 하나에 20개 이상의 API 호출이 발생하며 토큰이 끊임없이 소모되었습니다. 오후 내내 디버깅을 한 끝에 드디어 원인을 찾아냈습니다. 다운그레이드 과정에서 이전 버전과 새 버전의 설정(config)이 조용히 뒤섞여 버린 것이었습니다. 이것은 전체 디버깅 여정과 잘못된 판단, 그리고 실제 해결책에 대한 기록입니다.

한 줄 진단

오류 없이 실행되는 데몬(daemon)이 모든 것이 괜찮다는 것을 의미하지는 않습니다. 최신 버전에서 남겨진 설정 파일 하나가 조용히 연쇄적인 이상 현상을 일으킬 수 있으며, 청구서를 확인하기 전까지는 이를 알아차리지 못할 것입니다.

무슨 일이 일어났는가

이야기는 이렇습니다.

저는 개인 AI 어시스턴트 프로젝트인 OpenClaw를 만지작거리고 있었습니다. 7.1-beta.6 버전이 출시되었을 때, 저는 열정적으로 이를 설치했습니다. 반나절 정도 지나자 균열이 나타나기 시작했습니다. 디렉토리를 설정하는 동안 프로젝트 파일을 삭제하거나, 깨진 문자로 가득 찬 기사를 쏟아냈습니다. 참을 만큼 참았습니다. 다시 6.6 stable 릴리스로 다운그레이드할 시간이었습니다. 어쨌든 그냥 npm 다운그레이드일 뿐이니까요. 명령어 하나면 되는 거 아닌가요?

그랬듯이, npm install -g openclaw@2026.6.6 명령은 약 30초 정도 걸렸습니다.

그 후 상황이 이상해졌습니다.

이전에는 제가 "hello"라고 입력하면 AI 어시스턴트가 한 번 응답하며 약 3~5개의 API 호출을 소모했습니다. 다운그레이드 이후에는 동일한 질문에 20개 이상의 호출이 발생했습니다. 마치 커피를 너무 많이 마신 사람처럼, 혼잣말을 중얼거리며 확인을 위해 여러 번 되돌아오는 듯했습니다. 토큰 소비량이 4배로 늘어났습니다. 불과 몇 분 만에 DeepSeek API 잔액이 마이너스로 떨어졌고, 저는 즉시 프로세스를 종료해야 했습니다.

만약 여러분이 어떤 형태로든 AI 도구나 프레임워크를 다룬다면, 이 글은 향후 5분의 시간을 투자할 가치가 있습니다.

디버깅 여정

첫 번째 생각: 네트워크 문제인가?

아니었습니다. 응답은 정상적으로 돌아왔습니다. 다만... 과도했을 뿐입니다.

두 번째 생각: 설정(Config)이 손상되었나?

openclaw doctor를 실행했더니 버전 불일치(version mismatch) 경고가 출력되었습니다:

Warning: config was created by version 2026.7.1-beta.6,
current version is 2026.6.6.

빙고(Bingo). 설정(config)은 7.1 버전에서 생성되었지만, 실행 중인 바이너리(binary)는 6.6 버전이었습니다. 버전이 뒤섞인 상태(Version soup)였죠.

제 직관은 단순했습니다. 설정 파일에서 meta 필드를 그냥 삭제하고 다시 생성되게 만드는 것이었죠. 그게 뭐 그리 어렵겠습니까?

$config = Get-Content "openclaw.json" | ConvertFrom-Json
$config.PSObject.Properties.Remove("meta")
$config | ConvertTo-Json | Set-Content "openclaw.json"

스크립트는 문제없이 실행되었습니다. 설정이 새로고침되었습니다. 저는 문제가 해결되었다고 확신하며 게이트웨이(gateway)를 재시작했습니다 — 그리고 meta 필드는 다시 돌아와 있었습니다.

저는 당혹스러웠습니다.

돌파구: OpenClaw에는 자동 복구 메커니즘이 있다

시작 로그(startup logs)를 파헤친 끝에 전체 그림이 드러났습니다:

1. OpenClaw가 openclaw.json을 읽음 → 수동 변조(manual tampering) 감지
2. 스키마(schema)에 따라 검증 → 불일치(mismatch) 발견
3. 복구(recovery) 트리거 → openclaw.json.last-good에서 복원
...

제가 수동으로 그 meta 필드를 삭제할 때마다, 복구 메커니즘이 조용히 그것을 복원해 버린 것입니다. 저는 한 시간 동안 편집을 했고, 시스템은 한 시간 동안 그것을 되돌렸습니다. 우리는 교착 상태(stalemate)에 빠져 있었고, 저는 그 사실조차 모르고 있었습니다.

이것이 진짜 교훈입니다: 일부 프레임워크는 다운그레이드할 때 단순히 이전 설정을 읽고 인식되지 않는 필드를 무시하는 데 그치지 않습니다. 이들은 능동적인 감지 및 자동 롤백(automatic rollback) 로직을 가지고 있습니다. 파일을 무작정 수정(brute-force)해서는 안 됩니다. 내부 작동 원리를 이해해야 합니다.

실제 해결 방법

핵심 원칙은 간단했습니다: 6.6 버전이 7.1 버전의 흔적을 단 하나도 보지 못하게 하는 것입니다.

# 1단계: 이전 설정을 격리한다 (삭제하지 말고 이름 변경)
Rename-Item "openclaw.json" "openclaw.7.1.compat.backup.json"
Rename-Item "openclaw.json.last-good" "openclaw.7.1.last-good.backup.json"
...

결정적인 단계는 설정을 편집하는 것이 전혀 아니었습니다. 바로 6.6 바이너리로부터 전체 온보딩(onboard)을 실행하여, 해당 버전이 처음부터 완전히 자신의 설정(configuration)을 생성하도록 만드는 것이었습니다.

그제서야 마이그레이션(migration)이 시작되었습니다:

• ✅ 모델 설정 (Model configs), 게이트웨이 설정 (gateway settings), 커스텀 스킬 (custom skills) → 그대로 가져와도 안전함
• ❌ 세션 기록 (Session histories), 작업 큐 (task queues), SQLite 데이터베이스 (SQLite databases) → 남겨두어야 함 (버전 간 포맷 호환 불가)

최종 확인: openclaw doctor 실행 결과 경고가 0개였으며, API 소비량이 정상으로 돌아왔습니다.

교훈 (Lessons)

발견부터 해결까지 이 모든 과정에 반나절 이상이 소요되었지만, 얻은 지식의 밀도는 높았습니다. 세 가지 핵심 요약입니다:

1. 다운그레이드는 단순히 "버전 번호를 바꾸는 것"이 아닙니다. 바이너리 (binary), 설정 스키마 (config schema), 세션 포맷 (session format), 그리고 데이터베이스 구조 (database structure)는 하나의 통합된 스택을 형성합니다. 하나를 변경했다면 나머지 네 가지를 모두 점검하십시오.

2. 프레임워크의 자기 보호 메커니즘 (self-protection mechanism)과 싸우지 마십시오. 만약 편집한 파일이 계속 원래대로 되돌아간다면, 프레임워크 개발자들은 당신보다 설정 오염 (config corruption)을 더 걱정하고 있는 것입니다. 해결책은 더 강하게 편집하는 것이 아니라, 메커니즘의 로직을 이해하고 정당한 경로(이 경우에는 온보딩 (onboard)을 다시 실행하는 것)를 따르는 것입니다.

3. 설정 버전 (config version)과 바이너리 버전 (binary version)이 일치하지 않을 때, 가장 취약한 지점은 에이전트의 동작 (agent behavior)입니다. 시스템 충돌 (crashes)이나 에러 로그 (error logs)가 아닙니다. 바로 소리 없는 이상 징후 (silent anomalies)입니다. 겉보기에는 정상처럼 보이지만 비정상적인 비용 지표를 보이는 동작 — 이것이 알아차리기 가장 어렵고, 비용이 가장 많이 드는 버그 유형입니다.

마지막으로 덧붙이자면, 공정하게 말해서 OpenClaw 팀은 이 분야에서 탄탄한 작업을 해두었습니다. 그들은 마지막 정상 백업 (last-good backups), 자동 복구 (automatic recovery), 그리고 버전 불일치 감지 (version mismatch detection) 기능을 갖추고 있습니다. 부족한 점은 단지 문서화 (documentation)뿐입니다. 다운그레이드 시 새로운 온보딩 (onboard)이 필요하다는 점을 어디에서도 강조하지 않고 있습니다. 저처럼 이 함정에 빠진 사람이 저뿐만은 아닐 것이라 생각합니다.

만약 상태 유지 서비스 (stateful services)나 AI 툴체인 (AI toolchains)을 관리한다면, 체크리스트에 "업그레이드/다운그레이드 전 설정 버전 확인"을 추가하십시오. 이 지뢰요? 저는 이미 밟았습니다. 천만에요.

참고 문헌 (References)

• OpenClaw GitHub: https://github.com/openclaw/openclaw
• 이 기사는 실제 2026.7.1-beta.6 → 2026.6.6 다운그레이드 사례를 바탕으로 작성되었으며, 모든 단계가 검증되었습니다.

투명성 노트 (Transparency note): 이 기사에 포함된 모든 문제 해결 단계는 재현 및 확인되었습니다. 자동 복구 (auto-recovery) 동작은 추측이 아닌, 의도적인 여러 차례의 시도를 통해 검증되었습니다. API 소비량 비교는 버전이 일치하는 조건과 일치하지 않는 조건에서 동일한 작업에 대해 측정된 데이터를 기반으로 합니다.