Alin's Dev Journey

라즈베리파이 5에 OpenClaw 올려보기

오케스트레이션은 집에 두고, 추론은 밖에 맡기는 구조로

이 글은 “라즈베리파이 5에 OpenClaw를 설치했다”는 결과보다, 왜 라즈베리파이 5였는지, 왜 로컬 추론이 아니라 클라우드 API로 가는 게 맞았는지, 그리고 모델 제공자를 어떤 기준으로 고르면 덜 헤매는지를 정리한 기록이다.

나는 뭔가를 시작할 때 이론부터 완벽히 다지는 타입은 아니다. 오히려 일단 만들어 보고, 막히고, 성능이 안 나오고, 운영이 귀찮아지는 지점을 겪어본 다음에 “왜 이렇게 되는지”를 다시 정리하는 편이다.

이번에도 똑같았다. 처음엔 라즈베리파이니까 “로컬 추론까지 한 번에?” 같은 욕심이 있었는데, 실사용 관점에서 그 욕심을 내려놓고 구조를 다시 잡았다. 이 글은 그 과정의 메모에 가깝다.

내 환경

내가 만들고 싶은 건 “추론 머신”이 아니었다

OpenClaw가 좋아 보였던 이유는 “모델이 똑똑한 답을 한다”보다도, 메신저에서 요청을 받고 → 상태를 관리하고 → 필요한 도구를 실행하고 → 결과를 다시 돌려주는 이 흐름 자체였다.

즉, 내가 필요한 건 GPU 박스가 아니라:

이 기준으로 보면 라즈베리파이 5는 생각보다 역할이 명확하다. 두뇌(추론)가 아니라, 신경계(연결/실행/운영) 역할.

1) 왜 라즈베리파이 5를 선택했는지

1-1. “항상 켜둘 수 있는 서버”가 필요했다

노트북/데스크탑은 결국 사람이 쓰는 장비다. 업데이트, 재부팅, 잠자기, 자리 이동… 이런 것들이 서비스 운영 관점에선 꽤 큰 변수다.

반면 Pi는 애초에 그런 역할(작고, 조용하고, 상시 구동)에 잘 맞는다. OpenClaw Gateway도 결국 “항상 살아있는 프로세스”가 핵심이라, 이게 먼저 맞았다.

1-2. 8GB를 고른 이유는 ‘브라우저 자동화’ 때문이다

여기서 포인트는 “LLM을 로컬에서 돌리려는 목적”이 아니다.

내가 8GB를 선택한 이유는 브라우저 자동화까지 쓰려는 계획 때문이었다. Openclaw의 브라우저 자동화를 위해 Chromium을 같이 띄우면, 생각보다 메모리가 빠르게 잡아먹힌다. 세션이 겹치면 더 그렇다.

처음부터 “될 듯 말 듯한 사양”으로 시작하면, 나중에 문제가 생겼을 때 원인이 너무 많아진다. 그래서 나는 그냥 메모리 여유를 확보하고 시작하는 쪽을 택했다.

1-3. NVMe SSD를 붙인 이유: 성능도 성능인데, 운영 안정성

라즈베리파이로 뭔가 오래 굴려보면 SD카드가 발목 잡는 순간이 온다. 그래서 이번에는 처음부터 NVMe로 갔다.

그리고 여기서 내가 한 선택이 하나 더 있다.

라즈베리파이 5의 PCIe는 기본이 Gen2지만, Gen3로 활성화가 가능하다. 나는 Gen3를 켜서 NVMe 속도를 조금 더 뽑는 쪽으로 세팅했다.

다만 이건 “무조건 이득만 보는 스위치”는 아니다. Gen3로 올리면 조합(어댑터/케이블/SSD/전원/발열)에 따라 링크가 불안정해질 수 있어서, 문제 생기면 다시 Gen2로 내리는 게 맞다. 나는 이걸 “성능 튜닝”이라기보다는, NVMe를 제대로 쓰기 위한 실험/운영 포인트로 보고 있다.

2) 왜 클라우드 API를 사용하는지

처음엔 솔직히 로컬 추론 욕심이 있었다. “내 장비에서 내 모델로”는 항상 멋있고, 셀프호스팅의 로망도 있다.

근데 메신저 기반 비서/자동화에서 중요한 건 이런 거다:

라즈베리파이에서 로컬 추론은 “가능하게 만드는 것”까진 할 수 있다. 하지만 “실사용 가능한 품질로, 항상 일정하게, 지속적으로 운영하는 것”은 다른 문제다.

그래서 나는 구조를 이렇게 정리했다.

Pi는 실행과 연결을 맡고, 추론은 외부에 맡긴다.

이 구조의 장점은 낭만이 아니라 관리 포인트가 줄어든다는 것이다.

즉, 내 목표는 “로컬에서 다 한다”가 아니라 “내가 통제해야 하는 부분은 로컬에 두고, 무거운 계산은 밖으로 보낸다”는 균형이다.

3) 어떤 모델 제공자 옵션을 선택하는 것이 좋을지

여기서 정답을 하나로 고르기는 어렵다. 대신 “내가 뭘 중요하게 보느냐”가 먼저다.

나는 초반 기준을 이렇게 잡았다.

이 기준으로 보면 제공자는 보통 세 갈래로 정리된다.

A. “첫 성공”이 목적이라면: 단일 상용 API로 시작

초기에는 변수를 줄이는 게 최고다. 처음부터 라우터/프록시/복잡한 구성으로 들어가면, 문제가 생길 때 원인 범위가 너무 넓어진다.

처음 1~2편은 단일 제공자로 ‘끝까지 한 번’ 경험하는 쪽이 좋다고 생각한다.

B. “여러 모델을 비교/실험”하고 싶다면: 라우팅/애그리게이터 계열

모델을 갈아끼우며 비교하고 싶다면 이쪽이 편하다. 다만 구조가 한 겹 더 생기는 만큼, 디버깅 포인트도 늘어난다.

그래서 나는 이건 “확장 편”에서 다루는 게 더 맞다고 본다.

C. “통제/정책/로그/비용 관리”가 중요하다면: 프록시를 앞단에 두기

개인 프로젝트가 커지거나, 조직/정책/로그가 중요해지면 이 방식이 설득력 있다. 대신 운영 부담은 올라간다. 이건 내가 ‘운영을 서비스처럼 해보고 싶어졌을 때’ 다음 단계로 남겨두려 한다.

첫 채널은 왜 텔레그램인가

처음부터 여러 채널(슬랙, 디스코드 등)을 붙이면 안 되는 지점이 생겼을 때 원인 범위가 너무 넓어진다. 나는 이번에 텔레그램 하나만 먼저 붙여서, “입력 → 추론 → 도구 실행 → 응답” 흐름을 끝까지 만드는 걸 1차 목표로 잡았다.

한 번이라도 끝까지 성공하면, 그 다음부터는 ‘확장’이 된다. 하지만 끝까지 못 가면, 그건 그냥 “시도했다”에서 멈춘다. 나는 그걸 피하고 싶었다.