OpenClaw 성능 최적화: 로그 분석부터 비용 80% 절감까지의 실전 방법

지난달 Anthropic 청구서를 받고 $347이라는 금액을 보는 순간 멍해졌습니다. 저는 OpenClaw로 글 몇 편을 쓰고 코드 리뷰를 조금 했을 뿐이었습니다. 더 나쁜 점은 최근 OpenClaw의 응답도 점점 느려져, 어떤 때는 20초 넘게 기다려야 반응이 왔다는 것입니다.

청구서를 한참 바라보다가 로그를 뒤지기 시작했습니다.

줄줄이 흘러가는 로그를 보면서 문제를 발견했습니다. 매번 대화할 때마다 전체 히스토리를 함께 들고 가고 있었고, 10회 대화 뒤에는 컨텍스트가 150K tokens까지 누적되어 있었습니다. 말할 때마다 이전 대화를 전부 다시 읊고 시작하는 것과 같았습니다. 청구서가 높을 수밖에 없었습니다.

2주 동안 여러 방법을 테스트했습니다. 세션 초기화부터 모델 전환, 캐시 전략, 컨텍스트 제한까지 하나씩 확인했습니다. 결국 월 비용은 $347에서 $68로 내려갔고, 응답 시간은 23초에서 4초로 줄었습니다.

OpenClaw token 소비 문제의 뿌리는 잘못된 사용 방식에 있습니다. 이 글에서는 로그 분석부터 최적화 전략까지, 그대로 복사해 쓸 수 있는 실전 방법을 공유합니다.

저비용 “새우 키우기” 가이드: ArkClaw가 AI Agent를 진짜 대중화합니다

요즘 인기 있는 OpenClaw(랍스터)는 좋지만 설정 장벽이 너무 높다고 느끼셨나요? ByteDance Volcengine의 ArkClaw는 진입 장벽을 바닥까지 낮췄습니다. 서버와 Token 설정으로 고생할 필요 없이, 한 번의 클릭으로 24시간 온라인 상태이며 브라우저를 제어하고 스크립트를 실행하고 캘린더를 관리하는 “AI 일꾼”을 가질 수 있습니다.

핵심은 정말 저렴하다는 점입니다. 월 요금은 9.9위안이고, 제 초대 코드 ZLKUK54M(여기에서 가입)을 사용하면 8.9위안이면 됩니다. 개발자라면 Coding Plan Pro에 바로 가입해 무료로 써볼 수도 있습니다.

성능 문제의 근원, OpenClaw는 왜 느려질까

Token 소비를 키우는 5대 원인

token 소비가 큰 건 그냥 많이 써서 그런 것 아니냐고 생각할 수 있습니다. 하지만 실제로는 그렇게 단순하지 않습니다.

원인 1: 끝없이 누적되는 대화 컨텍스트

OpenClaw는 기본적으로 모든 대화 기록을 보관합니다. 첫 대화는 5K tokens 정도일 수 있지만, 열 번째가 되면 150K까지 커질 수 있습니다. 질문을 할 때마다 OpenClaw는 이전의 모든 내용을 Claude API에 다시 보내야 합니다. 친구와 대화할 때 매번 지난주, 지난달 대화를 먼저 되풀이하는 것과 같습니다. 힘만 들고 효율은 낮습니다.

제가 테스트해보니, “이 코드에 문제가 있는지 봐줘” 같은 간단한 요청도 컨텍스트가 100K tokens까지 쌓여 있으면 답변이 200자뿐이어도 100K 기준으로 비용이 계산됩니다.

원인 2: 도구 출력의 무제한 저장

OpenClaw는 파일을 읽고, 로그를 확인하고, 명령을 실행할 수 있습니다. 문제는 도구의 출력이 매번 컨텍스트에 그대로 저장된다는 점입니다. 500줄 로그 파일을 보라고 하면 그 500줄이 계속 메모리에 남습니다. 설정 파일을 하나 더 확인하면 또 수백 줄이 추가됩니다.

예전에 OpenClaw에게 10MB짜리 오류 로그를 분석하게 한 적이 있습니다. 그 결과 로그 조각이 계속 컨텍스트를 차지했고, 이후의 모든 대화에서 이 10MB에 대한 비용을 계속 내고 있었습니다.

원인 3: 매번 다시 전송되는 시스템 프롬프트

OpenClaw의 시스템 프롬프트(system prompt)는 보통 5K-10K tokens이며, 능력과 행동 방식을 정의합니다. 이 내용은 매 대화마다 전송됩니다. 하루에 OpenClaw와 50회 대화한다면 시스템 프롬프트만으로도 250K-500K tokens가 소비됩니다.

원인 4: 잘못된 모델 선택

Claude에는 여러 등급의 모델이 있습니다. Haiku는 저렴하고 빠르며, Sonnet은 균형형이고, Opus는 강력하지만 비쌉니다. 가격 차이는 대략 15배입니다.

많은 사람이 편하다는 이유로 기본 모델을 Opus로 설정합니다. 그러면 간단한 형식 변환이나 정보 조회도 가장 비싼 모델로 처리됩니다. 아래 편의점에 물 한 병 사러 가는데 탱크를 몰고 가는 것과 비슷합니다. 갈 수는 있지만 그럴 필요는 없습니다.

원인 5: 부적절한 heartbeat 설정

OpenClaw에는 API 연결을 유지하기 위해 정기적으로 ping을 보내는 heartbeat 메커니즘이 있습니다. 누군가는 heartbeat 간격을 30초로 설정합니다. 그러면 시간당 API 호출이 120번 발생합니다. 호출 하나하나는 작아도 너무 자주 쌓이면 부담이 됩니다.

제가 본 한 사례에서는 어떤 사용자의 heartbeat 간격이 너무 짧아 한 달 동안 heartbeat만으로 3600회 호출이 발생했습니다. 실제 작업은 아무것도 하지 않았는데 돈부터 많이 나간 셈입니다.

메모리 문제의 진짜 모습

OpenClaw가 느릴 때는 네트워크 문제가 아니라 메모리가 부족한 경우가 있습니다.

많은 사람이 OpenClaw를 그냥 채팅 도구라고 생각하고 2GB 메모리면 충분할 거라고 봅니다. 실제로 돌려보면 전혀 그렇지 않습니다.

OpenClaw는 메모리를 많이 쓰는 애플리케이션입니다. Node.js 프로세스를 실행하고, WebSocket 연결을 유지하고, 세션 메모리를 저장하고, Web UI를 렌더링해야 합니다. 이 요소들을 합치면 기본 실행만으로도 약 1.5GB를 먹습니다. 2GB만 할당하면 50kg 배낭을 메고 마라톤을 뛰는 것과 같습니다. 이론적으로는 가능하지만 언제든 쓰러질 수 있습니다.

제 경험은 이렇습니다:

• 2GB 메모리: 시작은 되지만 조금 쓰면 버벅이고 자주 크래시가 납니다.
• 4GB 메모리: 정상적으로 사용할 수 있으며 개인 일상 개발에 적합합니다.
• 8GB 메모리: 매끄럽고 안정적이며 팀이나 고빈도 사용에 적합합니다.
• 16GB 메모리: 운영 환경의 표준 구성이며 장시간 실행해도 부담이 적습니다.

또 하나의 문제는 메모리 누수입니다. OpenClaw를 오래 실행하면 메모리 사용량이 서서히 늘어납니다. 처음에는 1.8GB였는데 일주일 뒤 3.5GB가 되고, 며칠 더 지나면 4GB를 넘는 식입니다. 이때 시스템은 swap을 자주 쓰기 시작하고, 디스크를 메모리처럼 쓰면서 응답 속도가 급격히 떨어집니다.

저도 이런 일을 겪었습니다. VPS 메모리는 4GB였고 처음에는 잘 돌아갔습니다. 2주 뒤 갑자기 OpenClaw 반응이 매우 느려졌고, docker stats로 확인해보니 메모리 사용량이 3.8GB까지 치솟아 시스템 여유 메모리가 200MB도 남지 않았습니다. 컨테이너를 재시작하자 바로 정상으로 돌아왔고, 메모리도 1.8GB로 내려갔습니다.

그러니 응답 지연이 꼭 OpenClaw 자체의 문제는 아닙니다. VPS 구성이 부족한 것일 가능성이 큽니다.

로그 분석과 모니터링, OpenClaw를 숨을 곳 없이 보기

Docker 로그를 제대로 여는 방법

문제는 OpenClaw가 실제로 무엇을 하는지 어떻게 알 수 있느냐입니다.

답은 간단합니다. 로그를 보면 됩니다. 다만 많은 사람이 로그를 어떻게 보는지 모르거나, 봐도 이해하지 못합니다.

실시간 로그 보기

docker logs -f openclaw-gateway

이 명령은 OpenClaw 로그를 계속 출력합니다. 계기판을 바라보는 것과 같습니다. 메시지를 하나 보내면 OpenClaw가 어떻게 처리하는지, 어떤 도구를 호출하는지, tokens를 얼마나 쓰는지 볼 수 있습니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

최근 오류 보기

docker logs openclaw-gateway 2>&1 | tail -50

이 명령은 최근 50줄 로그를 보여줍니다. 저는 보통 문제를 빠르게 찾을 때 이걸 씁니다. 컨테이너 시작이 실패했나요? 먼저 마지막 50줄을 보세요. 90%의 경우 답이 그 안에 있습니다.

핵심 오류 식별자

로그에는 특히 자주 보이는 오류가 있습니다. 아래 키워드만 기억해도 문제를 빠르게 좁힐 수 있습니다:

• WebSocket Error 1008: 인증 만료, 브라우저 캐시를 지워야 합니다.
• No API key found for anthropic: API 키 설정에 문제가 있습니다.
• Error: Address already in use: 포트가 이미 사용 중입니다.
• FATAL ERROR: Reached heap limit: 메모리가 부족하므로 구성을 업그레이드해야 합니다.

예전에 OpenClaw가 갑자기 연결되지 않은 적이 있습니다. 로그에는 계속 WebSocket Error 1008이 찍혔습니다. 한참 문서를 뒤진 뒤에야 시스템 시간을 조정해서 인증 token이 만료됐다는 걸 알았습니다. 브라우저 localStorage를 삭제하자 문제가 바로 해결됐습니다.

openclaw-telemetry 모니터링 도구

OpenClaw를 더 전문적으로 모니터링하고 싶다면 openclaw-telemetry 도구를 써볼 수 있습니다.

이 도구는 OpenClaw가 실행한 모든 명령, 프롬프트, 도구 호출을 기록합니다. 데이터는 syslog를 통해 수집되고 SIEM 시스템으로 전달해 보안 감사에 사용할 수도 있습니다. 가장 중요한 점은 민감 정보를 자동으로 마스킹하고, 위변조 방지 해시 체인으로 로그 무결성을 보호한다는 것입니다.

솔직히 개인 사용자에게는 조금 무거울 수 있습니다. 하지만 회사 환경에서 OpenClaw를 쓰거나 고객 데이터를 처리해 감사 기록이 필요하다면 이 도구는 꽤 가치가 있습니다.

설치와 설정은 복잡하지 않고 GitHub에 자세한 문서가 있습니다. 저는 개인 개발에는 필요하지 않아 직접 쓰지는 않지만, 팀에서 사용하는 사례를 봤고 반응도 괜찮았습니다.

리소스 모니터링 명령

OpenClaw가 리소스를 얼마나 쓰는지 알고 싶다면 명령 하나면 됩니다:

docker stats openclaw-gateway

이 명령은 컨테이너의 리소스 사용량을 실시간으로 보여줍니다:

CONTAINER ID   NAME               CPU %   MEM USAGE / LIMIT   MEM %   NET I/O
a1b2c3d4e5f6   openclaw-gateway   12.5%   1.85GB / 4GB       46.25%  15.2MB / 8.3MB

중점적으로 볼 지표는 다음입니다:

• CPU 사용률: 가끔 80-100%까지 치솟는 것은 괜찮습니다. OpenClaw가 작업을 처리하고 있다는 뜻입니다. 하지만 계속 높은 상태라면 문제가 있습니다.
• 메모리 사용량: 가장 중요합니다. 90% 이상에 계속 머물면 구성을 업그레이드해야 합니다.
• 메모리 비율: 80%를 넘으면 주의해야 하고, 90%를 넘으면 언제든 크래시가 날 수 있습니다.

제 경험상 이 명령을 정기적으로 한 번씩 보는 것이 좋습니다. 메모리 사용량이 계속 늘어난다면, 예를 들어 어제 1.8GB, 오늘 2.5GB, 내일 3.2GB라면 메모리 누수의 신호입니다. 컨테이너를 재시작하거나 세션을 초기화해야 합니다.

한번은 메모리 사용량이 3.6GB, 전체 4GB까지 올라갔는데도 OpenClaw가 아직 돌아가고 있었습니다. 조금 더 버텨보자고 생각했는데, 다음 날 아침 컴퓨터를 열어보니 컨테이너가 이미 죽어 있었습니다. 로그에는 Out of memory 오류가 가득했습니다. 그 뒤로는 메모리가 3GB를 넘으면 먼저 재시작하는 습관을 들였습니다.

7가지 성능 최적화 전략, 40%에서 80%까지 비용 절감하기

전략 1: 정기적인 세션 초기화(40-60% 절감)

가장 쉽고 효과적인 방법입니다.

왜 효과가 있을까요?

세션을 초기화할 때마다 OpenClaw는 누적된 컨텍스트를 비웁니다. 이전 대화 기록, 도구 출력, 중간 결과가 모두 0으로 돌아갑니다. 다음 대화는 새로 시작하므로 수십, 수백 K의 기록을 짊어지지 않습니다.

어떻게 하나요?

세 가지 방법 중 편한 것을 고르면 됩니다:

# 방법 1: 명령줄 초기화
openclaw "reset session"

# 방법 2: 세션 파일 직접 삭제
rm -rf ~/.openclaw/agents.main/sessions/*.jsonl

# 방법 3: 내장 명령 사용
# OpenClaw 대화창에 입력
/compact

모범 사례

제 습관은 독립 작업을 하나 끝낼 때마다 초기화하는 것입니다. 글 한 편을 쓰고 나면 초기화, PR 하나를 리뷰하고 나면 초기화, 문제 하나를 디버깅하고 나면 초기화합니다.

이렇게 하면 늘 “가벼운” OpenClaw를 쓰게 되어 응답은 빠르고 비용은 낮습니다.

누군가는 걱정할 수 있습니다. 초기화하면 컨텍스트가 사라지는 것 아닌가요? 맞습니다. 하지만 대부분의 경우 이전 작업의 컨텍스트는 다음 작업에 필요하지 않습니다. 블로그를 쓸 때 OpenClaw가 읽은 자료가 다음 코드 디버깅에 어떤 도움이 될까요? 없습니다. 그렇다면 왜 계속 메모리를 차지하고 token을 쓰게 두어야 할까요?

실측 데이터: 예전에 한 달에 $347를 썼는데 정기적으로 세션을 초기화하기 시작한 뒤 다음 달에는 $195로 내려갔습니다. 이 한 가지 작업만으로 40% 넘게 절감했습니다.

전략 2: 대용량 출력 작업 분리(20-30% 절감)

일부 작업은 엄청난 출력을 만듭니다. 전체 로그 확인, 설정 파일 내보내기, 대형 데이터셋 분석 같은 것들입니다. 이런 출력이 메인 세션에 들어오면 끈적하게 달라붙어 이후 대화 때마다 비용을 발생시킵니다.

해결 방법: 독립 세션 사용

# 독립 debug 세션에서 대형 설정 확인
openclaw --session debug "show full system config"

# 필요한 정보를 확인한 뒤 핵심 부분만 복사
# 이후 메인 세션으로 돌아와 계속 작업

쓰레기를 분리수거하는 것과 비슷합니다. 큰 쓰레기는 따로 버리고, 일상 쓰레기통에 밀어 넣지 않습니다.

실제 장면

전에 300줄 오류 로그를 OpenClaw에게 분석시키는 일이 있었습니다. 메인 세션에 그대로 붙여 넣으면 이 300줄이 컨텍스트를 영구 점유합니다. 저는 이렇게 했습니다:

1. --session analyze-log로 임시 세션 열기
2. 로그를 붙이고 OpenClaw에게 분석 요청
3. 결론 받기: 127번째 줄에 null pointer exception이 있음
4. 이 결론만 메인 세션에 복사
5. debug 세션은 닫아버려 300줄 로그가 메인 세션을 오염시키지 않음

조금 번거롭지만 실제로 비용을 꽤 줄일 수 있습니다. 특히 대용량 파일과 긴 로그를 자주 다룬다면 효과가 좋습니다.

전략 3: 지능형 모델 전환(50-80% 절감)

이 전략은 효과가 가장 뚜렷하지만, 많은 사람이 이렇게 할 수 있다는 사실을 놓칩니다.

Claude에는 세 가지 주요 모델이 있습니다:

• Haiku: 저렴하고 빠르며 간단한 작업에 적합합니다.
• Sonnet: 성능과 비용의 균형이 좋습니다.
• Opus: 가장 강력하지만 가장 비싸며, 가격은 Haiku의 15배입니다.

문제는 많은 사람이 편하다는 이유로 모든 작업에 Opus를 쓴다는 점입니다. 어디를 가든 비행기를 타는 것과 같습니다. 마트에 가도 비행기, 출근할 때도 비행기입니다. 갈 수는 있지만 필요하지 않습니다.

작업 등급 원칙

제가 쓰는 분류 방식은 이렇습니다.

Haiku를 쓰는 장면:

• 형식 변환(JSON을 YAML로, Markdown을 HTML로)
• 정보 조회(“이 코드는 어떤 언어인가요?”)
• 간단한 Q&A(“이 오류는 무슨 뜻인가요?”)
• 텍스트 추출(“이 코드의 모든 함수명을 뽑아줘”)

Sonnet을 쓰는 장면:

• 코드 리뷰(논리 취약점, 성능 문제 확인)
• 콘텐츠 작성(글과 문서 작성)
• 기술 분석(아키텍처 분석, 방안 평가)

Opus를 쓰는 장면:

• 아키텍처 설계(전체 시스템 설계)
• 복잡한 리팩터링(대규모 코드 개편)
• 핵심 의사결정(기술 선택, 리스크 평가)

설정 예시

{
  "defaultModel": "claude-3-haiku",
  "complexTaskModel": "claude-3-5-sonnet",
  "triggerKeywords": ["분석", "리팩터링", "아키텍처", "설계"]
}

저는 기본 모델을 Haiku로 두고, 복잡한 작업을 만날 때만 수동으로 전환합니다. 이렇게 하면 작업의 80%는 저렴한 모델로 처리되고 비용이 빠르게 내려갑니다.

실제 효과: 전략 1인 세션 초기화와 함께 적용하니 월 비용이 $195에서 $68로 내려갔습니다. 모델 전환만으로도 거의 65%를 절감한 셈입니다.

전략 4: 캐시 최적화(30-50% 절감)

Claude API에는 캐시 메커니즘이 있습니다. 동일하거나 비슷한 프롬프트를 연속으로 보내면 API가 결과를 캐시하고, 이후 요청 비용이 훨씬 낮아집니다.

캐시는 어떻게 활용하나요?

1. prompt 캐시 활성화(대부분 OpenClaw 버전은 기본 활성화)
2. temperature 낮추기: 0.2 정도로 설정하면 출력이 안정되고 캐시 적중률이 올라갑니다.
3. heartbeat로 캐시를 따뜻하게 유지하기: 너무 자주 하지 말고 5-10분에 한 번을 권장합니다.

{
  "temperature": 0.2,
  "enablePromptCaching": true,
  "heartbeatInterval": 300000  // 5분, 단위는 밀리초
}

4. 캐시를 지원하는 중계 서비스 사용: 일부 서드파티 API 중계는 추가 캐시 최적화를 제공합니다.

실제 효과

캐시의 가장 큰 장점은 시스템 프롬프트(5K-10K tokens)가 캐시 유효 시간 안에서는 한 번만 과금된다는 점입니다. 한 시간 안에 10번 요청했다면 원래는 시스템 프롬프트 비용을 10번 냈지만, 이제는 1번만 냅니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

다만 이 최적화 효과는 사람마다 다릅니다. OpenClaw 사용 빈도가 낮아 하루에 몇 번만 쓴다면 캐시가 자주 만료되어 효과가 크지 않습니다. 고빈도로 사용해 하루 수십 번 대화한다면 캐시만으로도 30-50%를 절감할 수 있습니다.

전략 5: 컨텍스트 창 제한(20-40% 절감)

OpenClaw의 기본 컨텍스트 창은 400K tokens입니다. 커 보여서 좋게 들리죠? 문제는 창이 클수록 무의식적으로 그 안을 채우기 쉽다는 것입니다.

큰 배낭을 주면 자신도 모르게 더 많이 넣고, 작은 가방을 주면 자연스럽게 줄이는 것과 같습니다.

설정 방법

{
  "maxContextTokens": 100000  // 400K에서 100K로 제한
}

왜 효과가 있을까요?

컨텍스트 창을 제한하면 OpenClaw는 더 자주 컨텍스트를 정리하도록 강제됩니다. 컨텍스트가 거의 찰 때 초기화하거나 요약하라고 알려줍니다. 덕분에 수십 회 대화 기록을 계속 끌고 다니지 않게 됩니다.

게다가 대부분의 작업에는 100K면 충분합니다. 초대형 리팩터링을 하거나 수천 줄 코드를 분석하는 게 아니라면 400K까지 쓸 일이 거의 없습니다.

주의할 점

너무 작게 제한하면 부작용이 있습니다. 실제로 많은 컨텍스트가 필요한 작업, 예를 들어 전체 프로젝트 아키텍처를 분석하는 경우라면 창이 너무 작아 OpenClaw가 “잊어버리고” 전체를 이해하지 못할 수 있습니다.

그래서 제 권장은 이렇습니다:

• 일상 사용: 50K-100K
• 복잡한 작업: 200K
• 초대형 프로젝트: 기본 400K 유지

제게는 100K가 적당한 지점입니다. 비용을 줄이면서 사용 경험도 해치지 않습니다.

전략 6: 로컬 모델 사용(60-80% 절감)

설정을 만지는 것을 감수할 수 있다면, 이 방법은 일부 작업의 비용을 사실상 0으로 만들 수 있습니다.

기본 아이디어

Ollama로 로컬 모델, 예를 들어 Llama나 Mistral을 구성하고 OpenClaw가 간단한 작업을 로컬 모델에 맡기게 합니다. 그러면 Claude API를 호출하지 않으니 비용도 들지 않습니다.

적합한 장면

• 형식 변환(JSON, YAML, Markdown 상호 변환)
• 간단한 조회(“모든 TODO 주석을 나열해줘”)
• 정보 추출(텍스트에서 특정 정보 추출)

적합하지 않은 장면

• 코드 리뷰(로컬 모델 품질이 Claude보다 떨어짐)
• 창의적 콘텐츠(글과 문서는 아직 Claude가 더 안정적)
• 복잡한 추론(아키텍처 설계, 기술 분석)

설정 예시

# Ollama 설치 후 모델 받기
ollama pull llama3.2

# OpenClaw가 간단한 작업에 로컬 모델을 쓰도록 설정
{
  "localModel": "llama3.2",
  "localModelTasks": ["format", "extract", "simple-query"]
}

실제 사용감

솔직히 로컬 모델 설정은 꽤 번거롭고 출력 품질도 Claude보다 떨어집니다. 저는 로컬 모델로 형식 변환을 해봤는데, 10번 중 2-3번은 오류가 나서 직접 고쳐야 했습니다.

하지만 예산이 정말 빠듯하거나 반복적인 간단한 작업이 많다면 로컬 모델은 시도해볼 만합니다. 적어도 이 부분의 비용은 60-80% 줄일 수 있습니다.

전략 7: 불필요한 Skills와 도구 비활성화

OpenClaw는 브라우저 자동화, 파일 작업, 코드 실행 등 여러 Skills를 지원합니다. 문제는 활성화된 Skill마다 컨텍스트를 차지한다는 점입니다. 도구 사용 설명을 API에 보내야 하기 때문이고, 작은 모델에서는 특히 체감됩니다.

현재 활성화된 Skills 확인

OpenClaw 설정을 살펴보세요. 한 번도 쓰지 않는 도구가 잔뜩 켜져 있지는 않나요? 브라우저 자동화는 마지막으로 언제 썼나요? Gmail 연동은 정말 OpenClaw가 메일을 보내야 하나요?

최적화 전략

실제로 사용할 도구만 켭니다. 제 설정에는 다음만 남겼습니다:

• 파일 읽기/쓰기(필수)
• Git 작업(자주 사용)
• Bash 명령 실행(디버깅에 필요)

브라우저 자동화, 일정 관리, 메일 연동 같은 것은 전부 비활성화했습니다. 그러면 매 요청의 시스템 프롬프트가 수천 tokens 줄어듭니다.

설정 예시

{
  "enabledSkills": [
    "file-operations",
    "git",
    "bash"
  ],
  "disabledSkills": [
    "browser-automation",
    "gmail",
    "calendar"
  ]
}

이 최적화만 따로 보면 효과가 크지 않습니다. 대략 10-15% 정도일 수 있습니다. 하지만 다른 전략과 함께 쓰면 작은 절감이 계속 쌓입니다.

흔한 장애 빠른 확인표, 5분 안에 90% 문제 해결하기

문제가 생겨도 당황하지 마세요. 이 빠른 확인표는 대부분의 흔한 장애를 빠르게 좁히고 해결하는 데 도움이 됩니다.

몇 가지 실전 팁:

팁 1: WebSocket 문제의 최종 해결책

localStorage를 지워도 안 된다면 다음을 시도해보세요:

# Docker 환경에서 디바이스 페어링 비활성화(내부망 환경에서만)
docker run -e OPENCLAW_DISABLE_DEVICE_PAIRING=true openclaw/openclaw

팁 2: 메모리 문제인지 네트워크 문제인지 빠르게 판단하기

# 여러 지표를 동시에 모니터링
watch -n 1 'docker stats openclaw-gateway --no-stream && curl -s https://api.anthropic.com'

메모리는 안정적인데 응답이 느리다면 네트워크 문제일 수 있습니다. 메모리가 급증한다면 리소스 부족입니다.

팁 3: 로그가 너무 많아 핵심 정보를 찾기 어렵나요?

# 오류와 경고만 보기
docker logs openclaw-gateway 2>&1 | grep -E "ERROR|WARN|FATAL"

예전에 수천 줄 로그를 보며 문제를 디버깅한 적이 있습니다. 이 명령으로 필터링하자 핵심 ERROR가 바로 보였습니다. 알고 보니 API key가 만료되어 있었습니다.

고급 튜닝, OpenClaw를 한층 더 빠르게 만들기

기본 최적화를 이미 끝냈고 성능을 더 끌어내고 싶다면 이 부분이 도움이 됩니다.

고급 컨텍스트 관리

컨텍스트 삼각화(Context Triangulation)

전체 파일을 OpenClaw에 넣지 말고 작업과 관련된 조각만 주입합니다. 예를 들어 어떤 함수를 수정하려면 다음만 제공하면 됩니다:

• 그 함수의 코드
• 그 함수가 호출하는 함수의 시그니처
• 관련 타입 정의

이렇게 하면 컨텍스트를 70-80% 줄일 수 있습니다.

계층형 전역 앵커 아키텍처(TGAA)

프로젝트 루트에 ARCHITECTURE.md를 두고 시스템의 상위 설계를 기록합니다. 전역 관점이 필요할 때 OpenClaw가 전체 코드베이스를 스캔하는 대신 이 파일을 읽게 합니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

저는 각 모듈 디렉터리에 README.md를 두고 그 모듈이 무엇을 하는지 짧게 적어둡니다. OpenClaw가 프로젝트 구조를 이해해야 할 때는 이 README들만 읽어도 충분하고, 모든 소스 코드를 불러올 필요가 없습니다.

동적 도구 로딩

처음부터 모든 도구 정의를 로딩하지 않습니다. 필요할 때 주입합니다. 파일 작업이 필요할 때 파일 도구를, Git이 필요할 때 Git 도구를 로딩합니다.

이 방법은 OpenClaw 설정을 수정해야 해서 약간의 기술 장벽이 있지만, 시스템 프롬프트 비용을 약 30% 줄일 수 있습니다.

사전 압축 메모리 갱신

세션 요약이나 초기화 전에 OpenClaw에게 중요한 정보를 MEMORY.md에 쓰게 합니다. 그러면 초기화 뒤 새 세션은 이 압축된 기억 파일만 읽고 이전 컨텍스트를 이어갈 수 있습니다.

# 요약 전에 핵심 정보 저장
openclaw "우리가 논의한 핵심 결정과 할 일을 MEMORY.md에 기록해줘"

# 세션 초기화
openclaw "reset session"

# 새 세션 시작 시 읽기
openclaw "MEMORY.md를 읽고 이전 작업을 계속해줘"

Docker 보안 강화

2026년 1월, 보안 회사 Bitdefender는 CVE-2026-25253 취약점을 공개하면서 수백 개의 OpenClaw 인스턴스가 잘못된 설정 때문에 API 키와 민감 데이터를 노출했다고 밝혔습니다. 취약점은 이미 수정되었지만, 이 사례는 보안 설정이 중요하다는 점을 상기시켜 줍니다.

non-root로 실행

services:
  openclaw-gateway:
    user: "1000:1000"  # 비특권 사용자 사용

최소 권한 원칙

docker run \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --read-only \
  --tmpfs /tmp \
  openclaw/openclaw

네트워크 격리

OpenClaw가 외부 네트워크에 접근할 필요가 없다면, 예를 들어 로컬 파일만 처리한다면 네트워크를 완전히 격리할 수 있습니다:

services:
  openclaw-gateway:
    network_mode: none

인터넷 연결은 필요하지만 접근 범위를 제한하고 싶다면 allowlist 프록시를 설정합니다.

환경 변수 보호

docker-compose.yml에 API key를 평문으로 쓰지 말고 환경 변수 파일을 사용합니다:

services:
  openclaw-gateway:
    env_file:
      - .env  # 파일 내용: ANTHROPIC_API_KEY=sk-xxx

.env를 .gitignore에 넣는 것을 잊지 마세요. 실수로 GitHub에 올리면 안 됩니다.

운영 환경 모범 사례

로그 로테이션으로 디스크가 가득 차는 것 방지

services:
  openclaw-gateway:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

이렇게 하면 로그가 최대 30MB만 차지하고 무한히 늘어나지 않습니다.

정기 업데이트

OpenClaw는 업데이트가 잦고 성능 개선과 보안 수정이 자주 포함됩니다. 한 달에 한 번 버전을 확인하세요:

docker pull openclaw/openclaw:latest
docker compose up -d

모니터링 알림 설정

간단한 스크립트로 리소스를 모니터링합니다:

#!/bin/bash
MEM_PERCENT=$(docker stats openclaw-gateway --no-stream --format "{{.MemPerc}}" | sed 's/%//')
if (( $(echo "$MEM_PERCENT > 85" | bc -l) )); then
    # 알림 전송(메일, Webhook 등)
    echo "OpenClaw 메모리 사용률이 85%를 넘었습니다!" | mail -s "OpenClaw 알림" [email protected]
fi

cron에 넣어 매시간 실행하면 됩니다.

공개 인터넷 노출 대신 VPN 또는 Tailscale 사용

OpenClaw에 원격으로 접근한다면 포트를 공개 인터넷에 직접 노출하지 마세요. Tailscale로 사설 네트워크를 만들면 안전하고 편합니다.

# Tailscale 설치
curl -fsSL https://tailscale.com/install.sh | sh

# 시작 및 인증
sudo tailscale up

# 이제 공개 IP 없이 Tailscale 네트워크로 OpenClaw에 접근할 수 있습니다.

저도 이렇게 설정해두었습니다. 카페나 공항에서도 집에 있는 OpenClaw 인스턴스에 안전하게 접근할 수 있습니다.

결론

$347에서 $68로, 23초 응답에서 4초로. 이 숫자들은 과장이 아니라 실제 최적화 결과입니다.

돌아보면 OpenClaw의 성능 문제는 사실 복잡하지 않았습니다. 결국 세 가지입니다:

1. 컨텍스트 제어: 끝없이 누적되게 두지 않습니다.
2. 올바른 모델 선택: 간단한 작업에는 저렴한 모델을 씁니다.
3. 리소스 모니터링: 메모리 부족을 제때 발견합니다.

7가지 전략을 모두 쓸 필요는 없습니다. 제 권장은 이렇습니다:

• 즉시 실행: 현재 메모리 사용량 확인(docker stats), 4GB 미만이면 바로 업그레이드
• 이번 주 완료: 지능형 모델 전환 설정(기본 Haiku) + 캐시 활성화(temperature 0.2)
• 습관화: 작업 하나를 끝낼 때마다 세션 초기화(/compact)

이 세 가지만 해도 비용은 최소 50% 줄어듭니다.

마지막으로, OpenClaw는 좋은 도구이지만 결국 도구일 뿐입니다. 도구가 얼마나 쓰기 좋은지는 상당 부분 사용하는 방식에 달려 있습니다. 작동 원리를 이해하고, 리소스를 합리적으로 설정하고, 좋은 사용 습관을 들이는 데 시간을 조금 투자하세요. 그 투자는 분명히 돌아옵니다.

문제가 생겨도 당황하지 말고 로그를 보고, 이 글의 빠른 확인표를 찾아보세요. 90%의 문제는 5분 안에 해결할 수 있습니다. 그래도 해결되지 않는다면 OpenClaw GitHub Issues에도 도와주는 커뮤니티 멤버가 많습니다.

여러분의 OpenClaw가 더 빠르고 더 저렴하게 달리길 바랍니다.