OpenClaw 심층 해부 및 활용 가이드

Zi.log·2026년 3월 12일

AI AI Agent Anthropic Antigravity Claude Generative AI LLM OpenClaw agent 생성형AI 오픈클로 인공지능 인공지능비서

지난 며칠간 개인용 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 (노아)
운영 방식	대화 주도형 (Interactive) 내가 부를 때만 나타나서 복잡한 미션을 깊이 있게 수행하고 종료함	이벤트 주도형 (Autonomous) `systemd` 서비스로 24시간 백그라운드에 상주하며 능동적으로 알림
기억 체계	프로젝트/세션 중심 현재 해결 중인 코딩이나 분석 과제의 문맥(Context)에 고도로 집중함	영구적 파일(Log) 중심 과거의 대화, 사용자의 성향, 포트폴리오 등을 파일에 영구 축적함
강점 영역	복잡한 시스템 분석 및 코딩 아키텍처 설계, 대규모 리팩토링, 버그 트래킹 등 "전문 엔지니어"	개인화된 일상 자동화 뉴스 스크랩, 스케줄 모니터링, 외부 메신저(디스코드) 연동 등 "전담 비서"

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

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

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

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

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

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)의 핵심 로직:

메모리 계층화: 거대한 MEMORY.md는 평소에 절대 로드하지 못하게 강제해버렸습니다. 대신, 꼭 필요한 내용만 담은 일일 메모만 가볍게 로드하고, 깊은 과거는 에이전트가 필요할 때만 스스로 '검색'하게 만들었습니다.
윈도우 리밋 설정: 과거 기록 전체가 아닌, 가장 최근 $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이 붙어서 무겁습니다만), 로컬 시스템의 제어권을 가졌다는 점에서 그 확장성은 무궁무진합니다. 특히 개발에 특화된 에이전트와의 결합을 상상해 보면 놀라운 아키텍처가 그려집니다.

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

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

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

6. 마치며

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

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