OpenClaw 심층 해부 및 활용 가이드

지난 며칠간 개인용 AI 비서인 **OpenClaw(오픈클로)**를 로컬 환경(맥북/리눅스)에 직접 구축하고, 설정부터 토큰 최적화까지 샅샅이 뜯어보며 치열하게 고민했던 과정을 정리해 보았습니다.

단순한 사용기를 넘어, **“이 에이전트가 도대체 어떤 녀석이고, 시스템 내에서 어떻게 살아 움직이는가?”**에 대한 본질적 궁금증부터, 실제 운영 과정에서 마주친 비용 폭증 문제와 그 해결책, 그리고 향후 개발 파트너로서의 확장 가능성까지 살펴보았습니다.

1. OpenClaw란 무엇인가?:작동 원리와 아키텍처

흔히 쓰이는 ChatGPT, Gemini 같은 웹 기반 챗봇과 OpenClaw 같은 로컬 AI 에이전트의 가장 큰 차이는 물리적인 컴퓨터의 제어권과 자율성에 있습니다. OpenClaw는 내 컴퓨터의 백그라운드에 상주하며 시스템을 제어하고, 독립적으로 작업을 수행할 수 있는 “자율형 개인 비서(Autonomous Personal Assistant)” 프레임워크입니다.

🧠 이원화된 시스템 구조: 엔진과 자아의 분리

오픈클로의 구조를 뜯어보면 크게 두 가지 영역으로 나뉩니다.

• 구동 엔진 (전역 node_modules): Node.js 기반의 이벤트 루프로 돌아가는 핵심 로직 꾸러미입니다. 사용자의 명령을 파싱하고, 도구를 실행하며, LLM과 통신하는 뼈대 역할을 합니다.
• 자아와 기억 (~/.openclaw 폴더): 바로 이 부분이 오픈클로의 핵심 정체성입니다. 이 폴더 안에는 에이전트의 성격이 정의된 SOUL.md, 설정 파일인 openclaw.json, 대화 세션 기록(sessions), 그리고 각종 정보가 축적되는 memory 폴더가 격리되어 관리됩니다.

🔄 의사 학습(Pseudo-learning) 메커니즘

OpenClaw의 가장 흥미로운 점은 LLM 모델 자체를 튜닝(Fine-tuning)하지 않고도 스스로 성장하는 듯한 모습을 보인다는 것입니다. 그 비결은 바로 파일 시스템을 활용한 장기 기억(Long-term Memory) 관리에 있습니다. 대화 도중 알게 된 나의 취향이나, 에러를 경험했을 때 “아, Anthropic API 키는 이렇게 설정하면 안 되는구나”라는 깨달음을 얻으면 이를 텍스트 파일(MEMORY.md나 일일 메모)에 스스로 적어둡니다. 그리고 다음 동작 시 이 기록을 읽어들여 같은 실수를 반복하지 않는 경험적(Empirical) 행동 교정을 구현합니다.

📂 Openclaw 폴더 및 파일 구조

Openclaw를 설치하고 나면 사용자 계정 홈 디렉토리에 숨김 폴더인 .openclaw가 생성됩니다(MacOS/Linux기준). 이 폴더는 Openclaw가 동작하는데 필요한 설정, 로그, 에이전트 데이터 등을 보관하는 핵심 디렉토리입니다.

아래는 .openclaw 폴더의 전체적인 구조와 각 요소들에 대한 간단한 설명입니다.

~/.openclaw/
├── agents/
│   └── main/
│       └── sessions/
├── completions/
│   ├── openclaw.bash
│   ├── openclaw.fish
│   ├── openclaw.ps1
│   └── openclaw.zsh
├── identity/
│   └── device.json
└── logs/
    ├── gateway.err.log
    └── gateway.log

📝 주요 폴더 및 파일 설명

1. agents/ (에이전트 데이터)

AI 에이전트와 관련된 데이터와 상태가 저장되는 공간입니다.

• main/sessions/: 메인 에이전트가 사용자와 상호작용했던 채팅 세션 내역이나 실행 상태 등을 기록하고 관리하는 폴더로 추정됩니다.

2. completions/ (터미널 자동 완성 스크립트)

터미널에서 openclaw 명령어를 입력할 때, 탭(Tab) 키를 눌러 명령어를 자동 완성할 수 있도록 돕는 쉘 스크립트 파일들이 모여있는 곳입니다.

• 사용 중인 터미널 환경에 맞춰 Bash, Fish, **PowerShell **, Zsh 용 스크립트를 모두 기본적으로 제공합니다.

3. identity/ (인증 및 기기 식별)

기기 인증이나 사용자 식별과 관련된 보안 정보가 담긴 폴더입니다.

• device.json: 현재 Openclaw가 설치된 기기의 고유 식별자나 인증 토큰 등, 시스템과 통신하는 데 필요한 디바이스 정보가 JSON 형태로 저장되어 있습니다.

4. logs/ (시스템 로그)

Openclaw가 실행되면서 발생하는 각종 시스템 로그가 평문 형태로 저장됩니다. 시스템에 문제가 생겼을 때 트러블슈팅 용도로 가장 먼저 확인해야 하는 폴더입니다.

• gateway.log: 정상적인 동작 과정, 통신 내역 등 일반적인 시스템 실행 로그가 기록됩니다.
• gateway.err.log: 프로그램 실행 중 발생한 오류나 예외 상황들만 따로 분리되어 기록됩니다. 빈 화면이 뜨거나 연결이 안 될 때 용하게 쓰입니다.

2. Antigravity vs OpenClaw: 두 에이전트의 결정적 차이

저에게는 개발 코파일럿인 ‘Antigravity(애니)‘와 일상 비서인 ‘OpenClaw(노아)’, 두 명의 강력한 로컬 에이전트가 있습니다. (일일이 풀네임으로 지칭하기 귀찮아서 이름을 붙여줬습니다.) 둘 다 제 컴퓨터의 터미널과 파일에 접근할 수 있지만, 설계 철학이 완전히 다릅니다.

결론적으로: Antigravity는 내가 코딩할 때 옆자리에 앉혀두고 자문을 구하는 ‘사수 개발자’ 라면, OpenClaw는 내가 자는 동안에도 내 주식 포트폴리오를 모니터링하고 아침에 디스코드로 브리핑해 주는 ‘성실한 비서’ 입니다.(실제로 그렇게 썼습니다.)

3. 그래서 OpenClaw는 어떤 용도로 사용해야 할까?

OpenClaw의 강점인 자율성과 외부 연결성을 극대화하기 위해서는 다음과 같은 **정기적이고 반복적인 ‘모니터링 및 자동화 업무’**에 투입하는 것이 가장 이상적입니다.

1. 투자 자산 및 뉴스 모니터링:
   • 매일 아침 크론잡(Cron)을 통해 내가 보유한 주식이나 채권과 관련된 뉴스를 스크래핑하고 요약하여 디스코드로 브리핑
2. 시스템 헬스 체크:
   • 로컬 서버나 개인용 NAS의 메모리 부족, 게이트웨이 에러 등 상태를 주기적으로 체크하고 이상 발생 시 나에게 즉각 경고
3. 가벼운 리서치 및 개인화 비서:
   • 외부에서 폰으로 디스코드에 접속해 “내일 일정 정리해 줘”, “최근에 저장한 링크 요약해 줘” 등의 일상적인 명령 수행

반면, 방대한 코드 베이스를 뒤엎거나 복잡한 디버깅 등 묵직한 작업은 이 녀석의 역할이 아님을 분명히 알아야 합니다. 그 이유는 아래에 후술합니다.

4. 토큰 폭증의 악몽: API 연동 시 왜 이런 일이 발생했고 어떻게 해결했나?

오픈클로를 디스코드에 연동하고 Anthropic(Claude) API를 물려 놓았더니, 작업 세션 하나 완료하기도 전에 TPM(Tokens Per Minute) Limit으로 에이전트가 뻗는 현상이 반복되었습니다. 일 하나 시키다 뻗고, 다시 일어나서 처리하다가 뻗고 하는게 반복되니 아무리 똑똑한 비서라도 일을 시킬 맛이 안 나더라고요…

💸 토큰 사용 폭증의 근본 원인

범인은 제가 에이전트를 너무 믿고 방치한 사이 비대해진 **‘세션 파일’**에 있었습니다.

OpenClaw는 나를 더 잘 이해하기 위해 대화 내역을 계속 쌓아둡니다. 아직 이전 작업을 완료하기도 전에 뻗어버린 메인 세션이 캐싱한 토큰이 어느덧 **153k(약 15만 토큰)**까지 불어나 있을 정도로요.

근데 Claude Haiku-4.5 모델의 TPM 제한은 50,000입니다. 제가 “안녕?”이라고 한마디만 해도 오픈클로는 맥락을 유지하겠다며 153k를 한꺼번에 서버로 던졌고, 서버는 “한 번에 5만 토큰 이상은 안 받아!”라며 입구 컷을 해버린 것이죠.

심지어 접근성을 높이기 위해 설정해 둔 디스코드 봇에서 “안녕?”이라고 짧게 물어볼 때조차, 오픈클로는 지금까지 쌓아온 나의 모든 성향, 과거의 대화 기록 전체, 심지어 이전 채팅 내역까지 모조리 읽어서 LLM에게 한 번에 전송 해버렸으니 뭐 하나 시킬만하면 뻗는건 당연한 수순이었을지도 모르겠습니다.

아마 제가 설정해 둔 요금제 때문일수도 있지만 정말 이건 아니다 싶더군요.

🛠️ 해결을 위한 3단계 실험 (The A/B/C Benchmarking)

이 ‘무한 에러 루프’를 끊기 위해 저는 세 가지 가설을 세우고 직접 시스템을 역설계하며 테스트를 진행했습니다.

• Test A (Full-Scan Baseline): - 기존 방식대로 세션 전체와 장기 기억을 모조리 LLM에게 전송하는 방식입니다.

  • 결과: 153k 토큰 소모. 비용 폭발은 물론, 기술적으로 더 이상 서비스 유지가 불가능함을 확인했습니다.

• Test C (External DB Query): - 대화 로그를 Supabase 등 외부 DB로 옮겨 필요한 부분만 쿼리해오는 방식입니다.

  • 결과: 데이터 보존성은 훌륭했으나, 인프라가 복잡해지고 네트워크 딜레이가 발생했습니다. 무엇보다 DB 통신을 위한 메타데이터가 추가되면서 예상보다 토큰 절감 효과가 드라마틱하지 않았습니다.이건 장기적으로 대량의 데이터가 쌓이면 괜찮을 것 같기도 합니다.

• Test B (Sliding Window - 최종 채택): - 가장 단순하면서도 강력한 ‘슬라이딩 윈도우(Sliding Window)’ 로직을 도입했습니다.

최적화(Test B)의 핵심 로직:

1. 메모리 계층화: 거대한 MEMORY.md는 평소에 절대 로드하지 못하게 강제해버렸습니다. 대신, 꼭 필요한 내용만 담은 일일 메모만 가볍게 로드하고, 깊은 과거는 에이전트가 필요할 때만 스스로 ‘검색’하게 만들었습니다.

2. 윈도우 리밋 설정: 과거 기록 전체가 아닌, 가장 최근 $k$개(5~6개)의 메시지만 잘라서 컨텍스트로 유지하도록 코드를 수정했습니다. 이는 $O(k)$의 일정한 복잡도를 유지하며 서버가 감당할 수 있는 최적의 양만 전송하게 합니다. 디스코드 봇은 더 많은 토큰을 잡아먹기 때문에 $k$를 2~3개로 설정하였습니다.

놀라운 결과: 이 조치를 통해 응답 정확도는 100%에서 96%로 단 4%만 희생하면서, 입력 토큰 소모량을 114 토큰에서 22 토큰으로 약 81% 감소시킬 수 있었습니다. Agent가 나를 잘 알아주는것도 중요하지만, 큰 차이가 없다면 단순함이 최고의 최적화임을 다시금 깨달은 순간이었습니다. 또한 모델별 리밋(Haiku: 50k, Sonnet: 30k)에 따라, 평소엔 Haiku로 가성비를 챙기고 복잡한 로직이 필요할 때나 Haiku의 limit이 임박할 경우 잠시 Sonnet으로 우회하는 **‘듀얼 모델 전략’**을 수립하여 비용과 Limit을 최소화 하였습니다.

5. 개발 파트너로써의 확장 가능성

현재 오픈클로는 가벼운 수준의 개인 비서에 특화되어 있지만(물론 LLM이 붙어서 무겁습니다만), 로컬 시스템의 제어권을 가졌다는 점에서 그 확장성은 무궁무진합니다. 특히 개발에 특화된 에이전트와의 결합을 상상해 보면 놀라운 아키텍처가 그려집니다.

1. 자동화된 CI/CD 감시자: 오픈클로가 백그라운드에서 빌드 로그를 계속 모니터링하다가 특정 에러 패턴이 감지되면, 디스코드로 즉각 알림을 보낼 수 있습니다.
2. 복합 에이전트 협업 시스템 (Agent-to-Agent):
   • 에러를 확인하고 오픈클로에게 “이 문제를 해결해 줘”라고 디스코드로 명령합니다.
   • 오픈클로는 자신이 직접 코딩하는 대신, 터미널을 열어 **전문 개발 에이전트인 Antigravity나 다른 워크플로우를 호출(Trigger)**시킵니다.
   • 전문 에이전트가 코드를 분석하고 패치 계획을 세우면, 그 작업 완료 이벤트를 다시 오픈클로가 릴레이로 받아서 “패치 초안이 작성되었습니다. 검토해 보시겠어요?”라고 모바일로 보고합니다.

이러한 마이크로 에이전트 아키텍처를 구축한다면, 비서의 신속성/모바일 연결성 + 개발 프레임워크의 전문성 등 각자의 전문성을 결합하여 로컬 개발 환경을 압도적으로 강력하게 진화시킬 수 있을 것입니다.

아직 붙여보지 않았지만 동기 중에 전직 개발자분이 만들어 주신 개발 에이전트와의 결합 가능성을 분석해 본 결과 적용 가능성이 높다는 결론이 있었기에, 결국 실제로 구현되는 것은 시간 문제라고 봅니다.

6. 마치며

3일동안 잘 가지고 놀았습니다. OpenClaw를 써보겠다고 노트북도 하나 희생하고 토큰과의 전쟁을 치렀던 지난 며칠은 단순히 툴 하나를 써보는 것을 넘어, AI 에이전트의 ‘메모리 관리 체계’와 ‘정체성 형성 과정’, 그리고 LLM 호출 시 발생하는 ‘비용 효율성’의 민낯을 마주할 수 있는 시간이었습니다.

이 기록이 로컬 AI 환경을 구축하려는 누군가에게 작은 영감이 되기를 바랍니다.