메인 서버를 지켜줄 AI 비서 찾기: OpenClaw를 넘어서 (1편)

내 소중한 M4 맥미니를 AI 에이전트한테 통째로 맡기려니 등골이 서늘해졌다.

OpenClaw는 편하긴 진짜 편했지만, 내 메인 서버에 얹어두기엔 보안상 너무 불안했다. 결국 더 안전하고 믿음직한 AI 비서 대안을 찾아 나선 이야기다.

OpenClaw, 편하지만 불안하다

홈 서버로 굴리는 M2 맥미니에서 OpenClaw를 돌리면서 AI 에이전트의 단맛을 제대로 봤다. 터미널 명령어를 대신 쳐주고, 귀찮은 파이썬 스크립트 뚝딱 짜주고, 번거로운 설정 파일까지 알아서 고쳐주니 그렇게 편할 수가 없었다.

그런데 쓰면 쓸수록 뒷목을 서늘하게 만드는 문제가 하나 있었다. 바로 ‘보안’이다.

OpenClaw는 로컬 파일 시스템에 마구 접근하고 쉘 명령어를 실행하는 권한이 너무 막강하다. 이게 편리함의 핵심이기도 하지만, 동시에 거대한 시한폭탄이었다. 소스코드를 직접 까봤더니, 파일이나 디렉터리에 접근하기 전에 권한을 검증하는 로직이 거의 없었다(터미널에서 실수로 rm -rf라도 날리면 상상만 해도 끔찍하다). 내 일상 작업이 전부 들어있는 메인 컴퓨터에 이런 무방비 상태의 봇을 상주시키는 건 미친 짓 같았다.

그래서 결국 OpenClaw는 “망가져도 포맷하면 그만인” M2 맥미니에만 철저히 격리해 두고 돌렸다. 어디까지나 가벼운 토이 프로젝트나 일회용 실험 코드를 굴리는 샌드박스 용도로만 묶어둔 셈이다.

메인 서버에도 비서가 절실하다

진짜 문제는 내 메인 워크스테이션인 M4 맥미니다.

정작 일감이 쏟아지고 복잡한 작업을 처리해야 하는 곳은 이 M4 맥미니인데, 보안 걱정 때문에 OpenClaw를 못 쓰니 답답해 미칠 지경이었다. 코드 리뷰 자동화, 실시간 로그 분석, 새벽 정기 백업 스크립트 관리 같은 귀찮은 일들을 AI 비서한테 싹 넘기고 싶었는데 말이다.

결국 메인 서버에 올려도 밤에 발 뻗고 잘 수 있는, 검증되고 안전하며 커뮤니티가 활발한 대체재를 찾아 깃허브 바다로 뛰어들었다.

후보군 탐색

며칠 동안 GitHub 트렌딩, Reddit, Hacker News를 샅샅이 뒤지며 후보군을 추렸다.

AutoGPT

AI 에이전트계의 시조새 격이다. 궁금해서 도커로 한번 띄워봤는데, 숨만 쉬어도 메모리를 기본 3GB 넘게 집어삼킨다. 게다가 사소한 명령어 하나 처리하는데도 토큰이 폭포수처럼 쏟아져 나가는 게 눈에 보였다. “가볍게 띄워두는 비서” 용도로는 너무 헤비해서 곧바로 내렸다.

SuperAGI

엔터프라이즈급 기능들을 잔뜩 갖추고 있고 웹 UI도 아주 화려하다. 그런데 도커 기반의 복잡한 멀티 컨테이너 세팅이 필수였다. 회사 인프라에서 대규모로 굴린다면 모를까, 개인 홈서버 맥미니에서 조촐하게 돌리기엔 배보다 배꼽이 더 큰 느낌이었다.

LangChain Custom Agent

직접 에이전트 코드를 짜는 방법이다. 자유도는 끝판왕이겠지만, 기능 하나 추가할 때마다 프레임워크 업데이트 따라가며 유지보수할 자신이 없었다(아님, 사실 내가 게을러서 그렇다). 처음 만들 땐 재미있어도 나중엔 분명 유지보수 지옥이 뻔했다.

최종 결정: HKUDS/Nanobot

고민과 비교 끝에 최종 낙점한 녀석은 바로 HKUDS/nanobot이다.

선택한 이유는 명확했다:

• 커뮤니티 규모: GitHub Stars가 수천 개에 달하고 컨트리뷰터들의 활동도 왕성하다. 물론 스타 수가 무조건 보안을 보장해주진 않지만, 최소한 많은 눈이 지켜보고 있으니 치명적인 백도어나 보안 구멍이 방치될 확률은 훨씬 낮다.
• 다양한 모델 확장성: 텔레그램, Slack, Discord 연동이 기본 탑재되어 있고, LLM 백엔드를 내 입맛대로 갈아 끼울 수 있다. GLM, Claude, OpenAI 등 선택지가 아주 넓다.
• 안전한 보안 모델: 이 부분이 결정타였다. README를 읽어보니 OpenClaw와 달리 파일 시스템 접근 권한을 명시적으로 제한하는 구조였다. 화이트리스트 방식으로 허용된 명령어만 실행할 수 있고, 샌드박스 모드도 지원한다. OpenClaw가 “문 열어놓고 다 허용하는” 무대포 구조라면, Nanobot은 “허락받은 것만 건드릴 수 있는” 절제된 구조다.

실제로 리포지토리 코드를 뜯어보니 파일 I/O를 수행하기 전에 권한을 체크하는 로직이 꼼꼼하게 박혀 있었다. 물론 100% 완벽한 방패는 없겠지만, 적어도 “아무 파일이나 제멋대로 주물럭거릴 수 있다”는 불안감에서는 벗어날 수 있겠다는 계산이 섰다.

이 정도면 내 피 같은 M4 맥미니에 세입자로 입주시켜도 괜찮겠다는 결론을 내렸다.

설치는 Git Clone으로 직진

설치 방법은 몇 가지가 있었지만, 최신 기능과 패치를 곧바로 당겨 쓰고 싶어서 소스코드 클론 방식을 택했다.

git clone https://github.com/HKUDS/nanobot.git
cd nanobot
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt

여기까진 일사천리였다. 속으로 ‘어? 생각보다 싱겁게 끝나네?’ 싶었다(물론 거대한 착각이었다).

pip install이 끝나자마자 터미널에 온갖 노란색 deprecated 경고 메시지들이 폭포수처럼 쏟아졌다. Python 3.11 호환성 문제 같았는데, “어쨌든 설치는 끝났으니 돌아가겠지” 하고 가볍게 넘겨버렸다(이게 나중에 내 발목을 제대로 잡을 줄은 꿈에도 몰랐다).

게다가 설정 파일을 열어보는 순간 숨이 턱 막혔다. config.yaml의 계층 구조가 생각보다 훨씬 깊고 복잡했다. API 키 몇 개 던져주면 끝나는 줄 알았더니, provider 설정부터 모델 라우팅, 에이전트 권한 범위까지 일일이 세팅해 줘야 했다.

이때까지만 해도 앞으로 닥쳐올 “Default Provider”의 저주와 PM2 연동의 험난한 삽질을 전혀 예상하지 못했다(과거의 나를 한 대 쥐어박고 싶다). 그 눈물겨운 삽질기는 2편에서 이어진다.

---

Nanobot 설치기 시리즈

• 1편: 메인 서버를 지켜줄 AI 비서 찾기 (현재 글)
• 2편: Config의 늪과 PM2 무중단 배포 →