PicoClaw는 Go로 만든 단일 바이너리형 AI 에이전트 런타임으로, 저장소는 10달러급 하드웨어, 10MB 미만 메모리, 약 1초 부팅을 목표 수치로 제시합니다. 본체가 가벼운 이유 중 하나는 대형 모델을 내부에서 실행하기보다 외부 LLM API 또는 별도로 연결한 Ollama에 요청을 보내기 때문입니다. 따라서 도입 판단에서는 런타임 메모리뿐 아니라 모델 서버 자원, API 비용, 네트워크와 로컬 도구 권한을 함께 측정해야 합니다.
PicoClaw는 저사양 보드에서 무엇을 실행하나: 설치와 비용, 권한 기준
PicoClaw는 무엇을 가볍게 만든 것인가?
PicoClaw는 “OpenClaw의 초경량 버전”을 지향하는 오픈소스 개인용 AI 비서입니다. 기존의 AI 에이전트들이 Node.js나 Python 같은 무거운 런타임 위에서 돌아가며 기가바이트(GB) 단위의 램을 요구했던 것과 달리, PicoClaw는 Go(Golang) 언어로 바닥부터 새로 작성되었습니다.
저장소가 제시하는 슬로건은 다음과 같습니다.
“$10 Hardware와 10MB RAM와 1s Boot”
이는 저가 하드웨어와 작은 런타임 메모리, 짧은 부팅 시간을 목표로 한다는 주장입니다. 실제 값은 빌드 버전, 아키텍처, 설정한 도구와 연결한 모델에 따라 달라질 수 있으므로 대상 보드에서 다시 측정해야 합니다.
README의 자원 수치를 어떻게 검증해야 할까?
README에 소개된 특징은 다음과 같습니다.
- 초경량 (Ultra-Lightweight):
- 메모리 사용량 10MB 미만을 보고합니다. 측정 조건과 활성 기능을 함께 확인해야 합니다.
- 저가 하드웨어 목표 (Minimal Cost):
- 10달러 수준의 리눅스 보드를 목표 사례로 듭니다. 모든 도구와 모델 구성이 같은 보드에서 원활하다는 뜻은 아닙니다.
- 짧은 부팅 목표:
- 저장소는 약 1초 부팅을 제시합니다. 첫 LLM 응답 시간은 별도의 네트워크, 모델 지연입니다.
- 이식성:
- 외부 의존성이 없는 단일 바이너리(Single Binary) 파일로 제공됩니다.
- RISC-V, ARM, x86 지원을 소개합니다. 각 릴리스에 해당 아키텍처 빌드가 있는지 확인해야 합니다.
- AI-Bootstrapped 개발:
- 저장소는 코드의 95%를 AI 에이전트가 작성하고 사람이 검토했다고 설명합니다. 이는 코드 품질이나 보안을 보증하는 지표가 아니므로 일반 프로젝트와 같은 검토가 필요합니다.
작은 바이너리는 실제 LLM 작업을 어디서 처리할까?
PicoClaw가 이렇게 가벼울 수 있는 비결은 Go 언어의 특성과 효율적인 설계 덕분입니다.
- No Runtime Hell: Node.js나 Python 인터프리터가 필요 없습니다. 운영체제에 맞는 실행 파일 하나만 있으면 됩니다.
- 플러그인 구조: 필요한 기능만 로드하여 메모리를 절약합니다.
- LLM 연동: 자체적으로 대형 모델을 포함하기보다 OpenRouter, Zhipu, OpenAI, Anthropic 같은 외부 API를 호출합니다. Ollama를 연결할 수도 있지만, 모델 파일과 추론 자원까지 10MB 안에 포함된다는 뜻은 아닙니다.
설치 전에 어떤 파일과 자격 증명을 확인해야 할까?
아래는 글 작성 당시 저장소에 근거한 설치 흐름입니다. 릴리스 파일과 빌드 명령, 지원 운영체제는 실행 시점의 저장소에서 다시 확인해야 합니다.
1. 설치 방법
방법 A: 미리 컴파일된 바이너리 다운로드 (가장 쉬움) GitHub Releases 페이지에서 본인의 OS에 맞는 파일을 다운로드하여 실행 권한을 주고 실행하면 끝입니다.
방법 B: 소스코드 빌드 (개발자 추천) Go 언어가 설치되어 있다면 다음 명령어로 최신 버전을 빌드할 수 있습니다.
1
2
3
4
5
git clone https://github.com/sipeed/picoclaw.git
cd picoclaw
make deps # 의존성 설치
make build # 빌드
sudo make install # 설치
방법 C: Docker 사용
1
docker compose run --rm picoclaw-agent -m "2+2는 뭐야?"
2. 초기 설정
설치 후 picoclaw onboard 명령어를 실행하거나, 수동으로 설정 파일을 만듭니다. 설정 파일은 ~/.picoclaw/config.json에 위치합니다.
설정 파일 예시 (config.json):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
{
"agents": {
"defaults": {
"workspace": "~/.picoclaw/workspace",
"model": "glm-4.7", // 또는 gpt-4o, claude-3-5-sonnet 등
"max_tokens": 8192,
"temperature": 0.7
}
},
"providers": {
"openrouter": {
"api_key": "sk-or-v1-......",
"api_base": "https://openrouter.ai/api/v1"
}
},
"tools": {
"web": {
"brave": {
"enabled": true,
"api_key": "YOUR_BRAVE_API_KEY",
"max_results": 5
}
}
}
}
웹 검색 기능을 켜면 별도의 검색 API 키와 외부 전송이 생깁니다. 예시 키를 실제 설정에 남기지 말고 파일 권한과 로그 노출을 확인해야 합니다.
첫 실행에서는 어떤 작업부터 맡겨야 할까?
PicoClaw는 설정한 도구를 통해 파일과 외부 서비스에 작업을 요청할 수 있는 에이전트입니다. 읽기 전용 질문부터 시작해 실행 로그와 승인 범위를 확인한 뒤 권한을 넓혀야 합니다.
- 기본 대화: 터미널에서 바로 질문하고 답을 얻습니다.
- 자동화 (Cron): “매일 아침 9시에 뉴스 요약해서 알려줘” 같은 명령을 내리면 내부 스케줄러(Cron)에 등록되어 자동으로 실행됩니다.
- 메신저 연동: 텔레그램(Telegram)이나 디스코드(Discord), 슬랙(Slack) 봇으로 연결할 수 있습니다. 밖에서도 폰으로 내 집의 서버나 컴퓨터에게 일을 시킬 수 있는 것이죠.
예시 시나리오:
“@picoclaw 지금 인기 있는 GitHub 트렌드 레포지토리 5개 찾아서 요약해주고, 내 로컬 파일
report.md에 저장해줘.”
이 예시는 웹 검색, 요약, 파일 쓰기 도구가 모두 설정된 경우의 흐름입니다. 에이전트 런타임의 메모리와 외부 모델이 사용하는 자원은 분리해서 봐야 합니다.
OpenClaw와 비교할 때 숫자만 보면 안 되는 이유는 무엇인가?
| 특징 | OpenClaw (Node.js/TS) | PicoClaw (Go) |
|---|---|---|
| 언어 | TypeScript | Go |
| 필요 메모리 | 기능, 설정별 측정 필요 | 저장소 보고 10MB 미만 |
| 부팅 속도 | 같은 환경에서 측정 필요 | 저장소 보고 약 1초 |
| 하드웨어 비용 | 구성별 차이 | 저가형 보드 목표, API, 모델 비용 별도 |
| 확장성 | 방대한 생태계 | 빠르고 효율적인 바이너리 |
PicoClaw의 후보 환경은 런타임 메모리와 부팅 시간이 중요한 엣지 기기입니다. 반면 필요한 채널, 스킬, 관리 기능이 부족하거나 외부 API 지연이 전체 시간을 지배하면 작은 바이너리의 이점이 줄어듭니다. 같은 작업과 도구를 켠 상태에서 종단 메모리와 응답 시간을 비교해야 합니다.
결론: PicoClaw가 맞는 환경은 어디인가?
PicoClaw는 제한된 메모리에서 메신저 연결과 도구 호출을 관리하고, 실제 언어 모델은 외부 API나 별도 서버에 맡기려는 환경에 적합합니다. 대상 보드에서 바이너리 메모리, 첫 응답과 전체 작업 지연, 네트워크 중단 시 동작, API 비용을 직접 측정해야 합니다.
파일 쓰기와 셸, 스케줄 작업을 허용한다면 작은 런타임도 큰 피해를 낼 수 있습니다. 별도 사용자 계정과 제한된 작업 공간에서 시작하고, 비밀 키를 로그와 설정 예시에 남기지 않으며, 실패 복구와 승인 절차가 확인된 작업만 자동화해야 합니다.
저사양 보드 시험에서는 무엇을 측정해야 할까?
첫 측정은 아무 도구도 켜지 않은 바이너리의 대기 메모리와 부팅 시간입니다. 다음으로 메신저, 검색, 파일 도구를 하나씩 추가해 자원 변화와 실패를 기록합니다. 모든 기능을 켠 값과 최소 구성의 값을 섞으면 README의 10MB 수치가 실제 업무에서도 유지되는지 판단하기 어렵습니다.
응답 시간은 런타임 시작, 외부 모델 호출, 도구 실행으로 분해합니다. 약 1초 안에 프로세스가 켜져도 네트워크와 LLM 응답이 오래 걸리면 사용자가 느끼는 전체 시간은 달라집니다. Ollama를 같은 보드나 별도 장비에 둘 때도 모델 메모리와 전력을 PicoClaw 본체와 분리해 기록해야 합니다.
네트워크를 끊었을 때 대기, 재시도, 오류 보고가 어떻게 되는지도 확인합니다. 외부 API가 실패한 뒤 같은 파일 작업을 중복 실행하거나 스케줄이 쌓이면 작은 기기에서 복구가 어려워질 수 있습니다. 최대 재시도와 시간 제한, 재부팅 뒤 예약 작업의 상태를 점검해야 24시간 운영 가능성을 판단할 수 있습니다.
마지막으로 같은 작업을 여러 아키텍처에서 비교하되 지원 바이너리와 기능이 동일한지 확인합니다. RISC-V에서 실행된다는 사실과 모든 플러그인이 같은 성능으로 동작한다는 사실은 다릅니다. 필요한 기능, 권한, 종단 비용을 충족한 가장 작은 구성만 남기는 것이 PicoClaw의 설계 의도와 맞습니다.
측정 결과는 사용한 커밋과 설정 파일의 기능 목록과 함께 남겨야 다음 릴리스에서도 같은 조건을 비교할 수 있습니다. 기능이 늘어난 뒤 메모리가 달라졌다면 프로젝트 전체의 약속이 깨진 것인지, 시험 구성이 달라진 것인지 구분할 수 있어야 합니다.
함께 읽으면 이해가 이어지는 글
- Agno: 순수 파이썬 기반 고성능 멀티 에이전트 시스템과 AgentOS 구축 — Agno(구 Phidata)는 복잡한 그래프나 체인 추상화 없이 순수 파이썬 코드만으로 멀티 에이전트를 구축할 수 있는 고성능 오픈소스 프레임워크입니다. 기존 프레임워크 대비 에이전트 인스턴스화 속도가 최대 5,000배 빠르고 메모리…
- 2-Tier Context Skill은 토큰을 줄일까? 로딩 구조와 보존율 검증 — 메타데이터 뒤 필요한 지침만 읽는 2-Tier 구조가 실제 토큰을 줄이는지, 요약 전후 핵심 정보 보존율과 라우팅 정확도로 검증하는 법을 정리합니다.
- everything-claude-code를 팀에 도입할까: 역할 분리, 스킬, 훅의 비용 — everything-claude-code의 역할별 에이전트, 필요할 때 불러오는 스킬, 훅 기반 기록 구조를 살펴보고 컨텍스트, 권한, 비용, 팀 설정의 도입 기준을 정리합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.