일주일 쯤 전부터 OpenClaw (당시에는 ClawdBot)이 눈에 들어오기 시작했다. 간단히 말하자면 이는 agentic AI의 일종이다. Agentic AI는 작업의 능동성에서 기존의 AI들과 차별화된다. 예를 들어 프로그램을 전혀 모르는 나같은 사람이 AI로 바이브 코딩을 한다고 생각하면, 그 동안은

  1. AI를 통해 코드를 작성함
  2. 해당 코드를 적용함.
  3. 오류 발생, AI를 활용하여 다시 디버깅
  4. 될 때까지 반복

이러한 과정을 수행했어야 한다. Agentic AI는 여기에서 코드를 적용하고, 디버깅을 하는 과정까지 AI가 알아서 수행한다. 즉 그 동안은 AI가 완성된 결과물을 내놓기 전에, 인간이 디버깅을 한다던가, 하다못해 AI가 제시한 코드 혹은 결과물을 복사 붙여넣기하는 것이 인간의 몫이었다면 agentic AI는 이 결과물을 내놓는 것 또한 AI가 진행하는 것이다. OpenClaw는 여기에서 더 나아가 이 agentic AI를 개인 PC에 설치한 것이라 생각하면 된다.

장단점은 명확하다. 기존 AI에 비해서 훨씬 편리한 대신, 보안상의 우려가 매우 크다. 또, OpenClaw의 장점 중 하나는 AI의 기억을 마크다운 형태로 저장해서, 기억이 휘발되지 않도록 할 수 있다는 것이다. 가령, 다음 스크린샷은 OpenClaw에게, 블로그에 쓸 Raspberry Pi에 OpenClaw 설정하는 과정을 안내하는 글의 초안을 부탁했을 때의 반응이다.

스크린샷들을 보면, 한 번의 명령으로 다음 과정들을 모두 수행하는 것을 확인할 수 있다.

  1. 블로그 폴더에서 Raspberry Pi 관련 글이 있을 것으로 추정되는 경로를 찾아본다. (내 OpenClaw 에이전트는 블로그 구조를 어느정도 알고있다.)
  2. Raspberry Pi 관련 글을 찾고, 이 글의 내용을 읽어 그 글에 아무 내용도 없다는 것을 확인했다.
  3. 같은 경로에 2026-02-05-OpenClaw_Journey.md라는 제목의 새 파일을 만들어서, 이 파일에 원하는 글의 내용을 적는다.

해당 파일의 내용은 다음과 같다.

img

작년 말부터 RPi5를 사용했다던가, 특정 케이스를 샀다던가 하는 사실과 다른 것들이 들어있기는 하지만 대략적으로 글의 구색은 갖춘 것을 확인할 수 있다. 나는 OpenClaw 에이전트를 Kimi-K2.5 모델로 돌리고 있는데, 더 유려한 글을 쓴다고 평가받는 Claude 등등을 썼다면 사정이 조금 나았을 것이다.

Raspberry Pi 5

OpenClaw는 그 자체로 AI 모델을 탑재한 것이 아니라, 외부 AI 모델의 API를 받아와서 돌리는 플랫폼의 일종이다. 맨 처음의 이름인 ClawdBot만 해도 Claude를 염두에 둔 이름이다. 그러다가 상표권 문제로 MoltBot으로 바뀌었다가, 또 다시 OpenClaw로 바뀌었다. 그 이름의 변화만큼이나 기능 변화 등등도 활발하게 이루어지고 있어서, 이 글에서 구체적인 설정 방법을 이야기하는 것은 적절치 못할 것 같고 (당장 내일이면 outdated일지도 모르니…) 간략히 환경 설명과 활용법 공유 정도나 하려 한다.

나는 원래 Homebridge용 Raspberry Pi Zero 2W를 갖고 있었어서, OpenClaw 이야기를 듣고 Raspberry Pi에 설치할 생각을 하는 것은 어찌보면 당연한 일이었다. 그러나 Raspberry Pi Zero는 아무래도 사양이 많이 딸려서, Raspberry Pi 5를 새로 구매했다. 여기서 가격 관련 부분을 짚고 넘어가지 않을 수가 없는데, agentic AI는 그 특성 상 API 소모가 아주 많다. 가령 내가 Raspberry Pi에 설치하고, 이것저것 설정한 게 2월 1일부터 2월 3일까지인데, 이 과정에서 API 사용료만 24달러가 넘게 깨졌다.

다행인 것은 OpenClawLM StudioOllama 같은 로컬 LLM도 연동해줄 수 있다는 것인데, 이를 위해서는… 다소 비싼 초기비용이 발생한다. 전력 소모와 성능 등등을 고려한다면 Mac Mini를 OpenClaw 전용 서버로 굴리는 것을 생각할 수 있겠지만, 단적으로 내 Mac Mini는 M4, 10코어에 16GB 모델인데 LM Studio로 조금 큰 파라미터 (9B정도)를 가진 LLM을 돌리면 RAM 사용량이 100%를 찍는다. 답답하지 않게 쓰려면 RAM 용량도 넉넉하고 저장공간도 뒷받침해주는 성능의 Mac Mini를 새로 구비해야 하는 것이다.

장기적으로 보면 이쪽이 이득일 것은 분명하지만, 내 API 사용량을 찬찬히 뜯어보면 어제, 오늘 쓴 비용은 합쳐서 3달러 정도, 그것도 블로그 글 생성 실험해본다고 써본 게 클테니 한 달 유지비는 별로 나오지 않을 것이라 판단했다. 무엇보다 어디까지나 호기심에 써 보는거고, 당장 한 달 후에 내가 이걸 쓰고 있을지 아닐지도 모르는 상황에서 굳이 이걸 돌리기 위해 Mac Mini를 살 필요는 없다고 판단했다. 그리고 짧게나마 사용해본 결과 그게 현명한 것 같다.

모델 선택

모델은 Moonshot/Kimi-K2.5를 사용했다. 어차피 OpenClaw는 플랫폼에 불과하므로 모델 사용에 제한은 없으나, 아무래도 가장 큰 강점이 도구 사용에 있는만큼 도구 사용을 위해 훈련된 모델을 사용하는 것이 좋다.

기타 설정

그 외에, 라즈베리 파이를 산 김에 미뤄뒀던 숙원사업들을 했다.

  • 배선 정리: 최근(?)에 이사를 했는데, 원룸이 아니라 와이파이 음영지역이 생겼다. 딱히 넓지도 않은데 아무래도 집 구조가 약간 꼬여있어서 벽들에 가로막히는 게 큰 이유인 것 같았다. 내가 공부방으로 사용하는 방은 집 가장 안쪽에 있고, 그 사이에 거실 겸 통로를 지나 현관쪽 방을 침실로 쓰다보니 침실에서 인터넷이 잘 안 잡혔다. 원래는 인터넷 가입하며 받는 대여용 공유기를 공부방에 두고, 침실에 있는 랜선에 와이파이 공유기를 하나 더 연결하려 했으나 어쩐 일인지 인터넷이 잡히지 않았다.
    단자함을 까봐서 이것저것 테스트를 해봤는데 아무래도 단자함에서 침실로 이어지는 선에 문제가 있는 것 같았다. 굳이 기사님을 부르기에는 귀찮아서 그냥 단자함 안에 통신사 공유기를 두고, 그 공유기를 거쳐서 공부방으로 연결되게 한 다음 공부방에 있는 공유기를 허브모드로 돌렸다. 이것이 라즈베리 파이 구입과 묶인 이유는 라즈베리 파이를 산 이유 중 하나가 단자함 안에 놓기 딱 좋은 사이즈인 것도 있기 때문이다. img
  • 홈서버 구축: 라즈베리 파이를 살 생각을 하고, 여러가지 활용법을 고민해서 이를 개인용 홈서버처럼 사용하기로 했다. 우선 블로그. 나는 기본적으로 개발자가 아니라 Git을 이용한 버전관리 시스템의 소중함을 느껴본 적이 별로 없다. 그래서 블로그에 글을 쓸 때도 로컬에서만 글 쓰고 Push하는 걸 까먹어서 바깥에서 블로그 글을 쓰려고 하면 한참 전 커밋이라 아무것도 못할 때가 많았다. 그래서 라즈베리 파이에 블로그 파일 및 Jekyll을 띄워놓고, Tailscale로 이를 다른 기기에서 수정하는 것을 떠올렸다. 그리고 하는 김에 아이클라우드 용량을 많이 잡아먹던 책 PDF 파일들도 옮겨놨다.
  • Homebridge 돌리기: 이건 원래부터 나에게 라즈베리파이의 존재의의였는데, RPi 5를 산다면 굳이 Zero 2W에 이를 굴릴 이유가 없어서 RPi 5에 통합했다.

활용법

우선 나는 RPi 5에 내 블로그 파일들과 전공서적 PDF 파일들을 모두 올려두었다. 블로그 레포지토리는 어차피 Public이니 노출되어도 거리낄 것이 없고, 책 PDF들도 모으느라 고생은 하긴 했지만 날아간다 해도 뭐… 다시 구할 수 있으니 이들 파일에 대해서는 RPi에 올려두는 것이 문제 없을 것이라 판단했기 때문이다. 그럼 이 상태에서 내가 할 수 있는 활용법은 대충 이렇다.

  1. 우선 블로그 글 쓸 때 편하다. 초안을 AI에게 작성시킬 수도 있고 내가 갖고 있는 PDF들이 있으니 이를 별도로 업로드할 필요 없이 무슨무슨 책에서 어떠한 내용을 찾아달라고 부탁할 수 있다. 솔직히 초안 작성은 어떤 모델로 시도해도 만족스럽지가 않아서 포기했지만, 내가 갖고 있는 PDF 파일을 쉽게 검색할 수 있는 것은 확실히 편하다. 보통 내가 읽어봤던 내용이 어렴풋이 기억나지만, 어느 책에 있었는지가 잘 기억이 안 날 때가 많은데 내가 읽어본 책들은 대충 나한테 PDF 파일로 있기 마련이고, 이걸 하나하나 찾아보는 건 인간이 하기엔 시간이 많이 걸리지만 AI에게 시키면 꽤 빠르게 (그리고 다른 작업과 비교하여 상당히 정확하게) 수행할 수 있기 때문이다.
  2. Cron job이 의외로 편했다. 말했다시피 나는 Git을 이용한 버전관리가 귀찮은데, 10분마다 push하도록 설정해둘 수 있다. 물론 여러 기기에서 쓸 때 conflict가 발생하면 미리 설정한 채널로 알림이 가도록 할 수도 있다.

사용 후기

개인적으로 재미있는 장난감이라 생각하지만 이곳저곳에서 야단법석 떠는 것만큼 유의미하지는 않아보인다.

  1. 가령 내 경우에 블로그 글에서 Clipboard API를 실행하는 자바스크립트가 있는데, 원래는 localhost에서 돌아가니까 문제가 없지만 서버를 RPi에 따로 둔 이상 로컬하게 올린 블로그 페이지가 http여서 이 자바스크립트가 작동하지 않는 문제가 있었다. 이를 해결하도록 시켜보았더니 Tailscale 포트를 18789에서 4000으로 돌리더라. 참고로 Jekyll이 포트 4000에서 돌아가고 Tailscale을 사용해서 이 페이지에 접근할 수는 있으니 이건 아주 틀린 해결책은 아니지만, 문제는 OpenClaw 웹 UI가 18789에서 돌아간다는 것. 당연히 자기 스스로 코드를 뽑아서 죽음을 택한 OpenClaw는 Gateway disconnected 에러를 뱉어냈고 직접 라즈베리파이에 연결해서 다시 설정을 원상복구했어야 했다.
  2. 뿐만 아니라 SSH 키를 만들 일이 있었는데 이를 내 블로그 레포지토리에 저장하는 바람에 Cron job이 이걸 자동으로 push해버렸다. 기본적으로 나는 이것이 어떻게 작동하는지 상당히 회의적이었어서 실행 결과물이 무엇인지 주시하고 있어서 바로 발견했지만, 만일 이를 완전히 믿고 있었다면 상당히 슬퍼졌을 것이다.
  3. 그와 별개로 만듦새가 상당히 좋지 않다. Ollama로 로컬모델을 돌린다면 thinking 태그가 잘못 붙어 응답이 전체 삭제된다. (Ollama에서는 응답을 뱉어내지만 OpenClaw에이전트 단에서 이를 추론과정이라 판단하여 무시한다. 물론 이는 Ollama에 올릴 때 신경을 덜 쓴 탓도 있다.) 이를 수정하려면 isReasoningProvider 함수에서 Ollama를 하나하나 빼줘야 한다. 이를 수정해서 로컬 모델을 띄운다고 해도, 새 세션을 시작할 때 사용자와의 기억 파일들 및 프롬프트을 통째로 AI에 입력하는 바람에 컨텍스트 윈도우가 작은 모델에서는 사용이 거의 불가능하거나 무의미하다. (새 세션 시작할 때 기본으로 16k 정도는 쓴다.) 그 외 자잘한 오류들 및 보안 취약점은 말하기도 입아프다.

물론 위의 오류들은 내가 사용한 AI 모델의 잘못인 것이 크다. 그러나 만일 누군가가 이를 완전히 AI 모델의 탓으로만 돌린다면, 이 워크플로우에서 OpenClaw라는 플랫폼의 역할은 무엇인지 묻지 않을 수 없다. 결국 OpenClaw라는 플랫폼에서 에이전틱 AI는 별개의 것으로 둔다면 남는 것은 광범위한 시스템 접근 권한 정도 뿐인데, 어차피 이러한 오류들 때문에 사람이 파일을 저장하거나 수정해야 한다면 이 플랫폼의 역할은 아무것도 없다.

결과적으로, 이왕 만들어둔 김에 쓰긴 쓰겠지만 이게 AI의 미래라며 호들갑 떨 정도는 전혀 아닌 것 같다. 큰 방향에서 이런 식으로 워크플로우가 적용되기야 하겠지만, 각각의 구성요소를 다 뜯어봤을 때 기존에 못하던 걸 새롭게 하게 되었는가 물어본다면 그건 아니기 때문이다. 그래도 덕분에 작업환경을 개선하기는 했으니 뭐…

댓글남기기