OpenClaw 백업이 설정 파일이 사라지기 전까지는 괜찮아 보였던 이유

무서운 점은 프롬프트(prompt)를 잃는 것이 아닙니다.

에이전트(agent)를 복구했는데, 정작 해당 에이전트를 작동하게 만들었던 모델 라우팅(model routing), 비밀 값(secrets), 커넥터 인증(connector auth), 또는 API 베이스 URL(API base URL)이 "백업"에 전혀 포함되지 않았다는 사실을 깨닫는 것입니다.

저는 "Unknown Backup Error"에 관한 이 r/openclaw 스레드를 본 후 이 문제에 깊이 빠져들게 되었습니다. 저에게 남은 것은 에러 그 자체가 아니었습니다. 그것은 바로 잘못된 안전감(false sense of safety)이었습니다.

우리 중 많은 이들이 내보내기(export) 파일을 보고 이렇게 생각합니다: "좋아, 백업이 있네."

하지만 그것은 복구(restore)를 할 수 있다는 것과는 전혀 다른 이야기입니다.

함정: 워크플로 JSON은 시스템이 아니다

서류상으로는 이 모든 것이 책임감 있게 보입니다:

• OpenClaw 워크플로(workflow) 내보내기 완료
• n8n 플로우(flows)를 Git에 동기화
• Make 시나리오(scenarios)를 블루프린트(blueprints)로 저장

만약 저장소(repo)를 훑어봤다면, 아마도 스택(stack)이 모두 커버되었다고 말했을 것입니다.

하지만 그렇지 않았습니다.

에이전트는 워크플로의 형태만으로 실행되지 않기 때문입니다. 에이전트는 다음과 같은 숨겨진 상태(hidden state) 위에서 실행됩니다:

• API 키(API keys)
• OAuth 연결(OAuth connections)
• 환경 변수(environment variables)
• 프로바이더 선택(provider selection)
• 모델 ID(model IDs)
• 폴백 규칙(fallback rules)
• 라우팅 로직(routing logic)
• API 베이스 URL(API base URLs)

이 중 하나라도 잃게 되면, 깔끔한 실패(clean failure)가 발생하지 않을 수도 있습니다.

더 나쁜 상황을 맞이할 수도 있습니다: 기술적으로는 실행되지만, 다르게 동작하는 복구 결과입니다.

최악의 복구 실패는 조용히 찾아온다

명확한 실패(hard failure)는 짜증 나지만, 적어도 정직합니다.

조용한 동작 변화(silent behavior change)는 팀이 며칠을 허비하게 만드는 지점입니다.

에이전트를 복구합니다. 임포트(import)는 성공합니다. UI는 정상적으로 보입니다. 테스트 실행도 통과합니다.

하지만 이제 다음과 같은 상황이 발생합니다:

• Slack 연결이 끊겨 있음
• Postgres 자격 증명(credential)은 존재하지만, 비밀 값(secret value)이 비어 있음
• OPENAI_BASE_URL 환경 변수가 누락됨
• 모델 별칭(model alias)이 다른 곳을 가리킴
• 폴백 경로(fallback path)가 이제 다른 프로바이더(provider)로 라우팅됨

워크플로는 동일합니다. 하지만 시스템은 다릅니다.

이는 출력 품질(output quality)이 달라지고, 지연 시간(latency)이 달라지며, 도구 동작(tool behavior)이 달라지고, 대개 비용(cost)도 달라짐을 의미합니다.

만약 프로덕션(production) 환경에서 에이전트를 실행하고 있다면, 이 사실은 당신을 불안하게 만들어야 마땅합니다.

각 도구가 실제로 제공하는 것

실무적인 버전으로 정리해 드립니다.

세 가지 모두 유용합니다.

하지만 그 어떤 것도, 단독으로는 재해 복구 (disaster recovery)라고 불릴 만한 수준은 아닙니다.

모델/제공자 상태가 중요하다면 OpenClaw는 특히 위험합니다

이 부분이 사람들이 과소평가하는 지점입니다.

정상적으로 작동하는 OpenClaw 에이전트는 다음과 같은 요소에 의존할 수 있습니다:

• 특정 제공자 (provider)
• 특정 모델 별칭 (model alias)
• 긴 컨텍스트 (long-context) 작업을 위한 경로 (route)
• 분류 (classification)를 위한 더 저렴한 경로
• 속도 제한 (rate limits) 또는 실패에 대비한 폴백 (fallback)

만약 가시적인 로직은 복구했지만 해당 모델/제공자 계층을 잃어버린다면, 에이전트는 여전히 실행될 수도 있습니다.

하지만 더 이상 이전과 같은 에이전트가 아닐 것입니다.

특정 벤더와 직접 통신하는 대신 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint)를 사용하는 경우, 이 점은 훨씬 더 중요해집니다.

예를 들어, 에이전트가 Standard Compute로부터 OpenAI 호환 기본 URL (base URL)을 기대한다면, 복구 과정에서 해당 가정을 반드시 유지해야 합니다:

export OPENAI_BASE_URL="https://api.standardcompute.com/v1"
export OPENAI_API_KEY="sc_..."

만약 이 값들이 사라지고 누군가가 기본 OpenAI 엔드포인트로 복구하거나 수동으로 제공자를 교체한다면, 워크플로우는 여전히 실행될지 몰라도 품질, 지연 시간 (latency), 그리고 비용이 밑바닥에서부터 모두 변해버릴 수 있습니다.

이것이 바로 팀들이 라우팅 (routing) 및 엔드포인트 설정 (endpoint config)을 백업하지 않았을 때 맞닥뜨리게 되는 전형적인 혼란입니다.

실패한 복구가 실제로 어떤 모습인지

일반적인 순서는 다음과 같습니다:

1. JSON 가져오기 (Import JSON)
2. 서비스 하나 재연결 (Reconnect one service)
3. 실행 (Hit run)
4. 인증 오류 발생 (Get an auth error)
5. 자격 증명 패치 (Patch the credential)
6. 다시 실행 (Hit run again)
7. 모델 설정이 변경된 것을 인지 (Notice the model setting changed)
8. 해당 설정 패치 (Patch that)
9. 폴백 경로 (fallback route)가 다른 곳을 가리키고 있음을 깨달음
10. 워크플로우가 마침내 완료되었으므로 승리를 선언 (Declare victory because the workflow finally completed)

그 시점에서 시스템은 "작동"합니다.

하지만 그것은 이전에 사용하던 것과 동일한 시스템이 아닐 수도 있습니다.

그것이 핵심적인 실수입니다. 성공적인 가져오기 (import)를 성공적인 복구 (recovery)로 취급하는 것입니다.

워크플로우 외에 백업해야 할 것들

에이전트 (agent)가 중요하다면, 백업에는 JSON 이상의 것이 포함되어야 합니다.

저의 체크리스트는 다음과 같습니다:

• 워크플로우 정의 (workflow definitions)
• 환경 변수 (environment variables)
• 비밀 정보가 아닌 설정 값 (non-secret config values)
• 별도의 비밀 관리자 (secret manager)에 저장된 비밀 정보 (secrets)
• 커넥터 매핑 (connector mappings)
• 계정 재연결 단계 (account reconnection steps)
• 모델 ID (model IDs)
• 제공자 라우팅 규칙 (provider routing rules)
• 폴백 동작 (fallback behavior)
• API 기본 URL (API base URLs)
• OpenAI 호환 가정에 관한 노트 (notes about OpenAI-compatible assumptions)
• 복구가 실제로 테스트되었다는 증거 (proof that restore was actually tested)

이것이 너무 많게 느껴진다면, 실제로 그렇기 때문입니다.

에이전트 시스템은 대부분의 팀이 인정하는 것보다 더 많은 숨겨진 운영 상태 (operational state)를 가지고 있습니다.

실용적인 백업 레이아웃

만약 제가 소규모 팀을 위해 이를 설정한다면, 지루할 정도로 명시적으로 유지할 것입니다.

1. 워크플로우 아티팩트 (workflow artifacts) 버전 관리

mkdir -p backup/workflows
cp openclaw-export.json backup/workflows/
cp n8n-flows.json backup/workflows/
...

2. 비밀 정보가 아닌 런타임 설정 (runtime config)을 별도로 저장

mkdir -p backup/config
cat > backup/config/runtime.env.example <<'EOF'
OPENAI_BASE_URL=https://api.standardcompute.com/v1
...

실제 비밀 정보 (live secrets)를 Git에 넣지 마세요.

그것들을 위해서는 비밀 관리자 (secret manager)를 사용하세요.

3. 기계 판독 가능한 복구 체크리스트 (restore checklist) 내보내기

{
  "connectors": [
    "Slack",
...

4. 스모크 테스트 (smoke test) 스크립트 추가

단순한 스크립트라도 막연한 느낌 (vibes)보다는 낫습니다.

#!/usr/bin/env bash
set -euo pipefail

...

그런 다음 에이전트가 의존하는 실제 프롬프트 경로 하나를 테스트하세요.

저의 주관적인 규칙: 복구를 테스트하지 않았다면, 당신은 백업을 가지고 있는 것이 아니다

여기서부터는 외교적인 태도를 버리고 솔직하게 말씀드리겠습니다.

만약 당신의 계획이 다음과 같다면:

• JSON을 내보내기(export) 한다
• 어딘가에 커밋(commit) 한다
• 미래의 당신이 알아서 해결할 것이라고 가정한다

그것은 백업 전략이 아닙니다.

그것은 그저 '희망 사항을 적은 파일 (hope file)'일 뿐입니다.

유효한 유일한 백업은 다음과 같은 요소들을 갖춘 작동 가능한 에이전트(agent)로 복구할 수 있는 백업뿐입니다:

• 동일한 커넥터 (connectors)
• 동일한 제공자 동작 (provider behavior)
• 동일한 모델 라우팅 (model routing)
• 동일한 엔드포인트 가정 (endpoint assumptions)
• 동일한 운영 출력 (operational output)

그 외의 모든 것은 문서(documentation)입니다.

물론 유용한 문서이긴 하겠지만, 여전히 문서일 뿐입니다.

에이전트를 종일 실행하는 팀에게 이것이 더 중요한 이유

장난감 수준의 워크플로우(workflow) 하나만 가지고 있다면, 수동 내보내기(manual export)로도 충분합니다.

하지만 에이전트가 프로덕션(production), 고객, 또는 매출에 관여한다면, 이 문제는 순식간에 심각해집니다.

그리고 만약 OpenAI 호환 클라이언트(OpenAI-compatible clients)를 통해 많은 에이전트 트래픽을 실행하고 있다면, 엔드포인트 동작(endpoint behavior)을 보존하는 것은 프롬프트(prompt)를 보존하는 것만큼이나 중요합니다.

이것이 바로 예측 가능한 인프라(infrastructure)가 중요한 이유 중 하나입니다. Standard Compute를 사용하는 팀들은 보통 다음 두 가지를 동시에 피하려고 노력합니다:

• 토큰당 과금(per-token billing)으로 인한 예상치 못한 비용 발생
• 임시적인 제공자 변경(ad hoc provider changes)으로 인한 예상치 못한 동작 발생

복구 과정에서 이 두 가지가 조용히 바뀌는 상황을 원치 않기 때문입니다.

요점 (The takeaway)

OpenClaw 내보내기(export)만으로는 백업이 되지 않습니다.

설계도(blueprints)를 만드는 것은 재해 복구(disaster recovery)가 아닙니다.

n8n Git 동기화(sync)는 비밀 값(secret)과 변수(variable)의 복구가 없다면 완전하지 않습니다.

만약 모델/제공자 설정(model/provider config), API 기본 URL(API base URLs), 그리고 라우팅 동작(routing behavior)을 보존하지 않는다면, 당신은 당신이 생각하는 그 에이전트를 복구하고 있는 것이 아닙니다.

그것이 진짜 실패 모드(failure mode)입니다.

JSON이 누락되는 것이 문제가 아닙니다.

애초에 에이전트를 신뢰할 수 있게 만들었던 '보이지 않는 상태(invisible state)'를 놓치는 것이 진짜 문제입니다.