2026년 5월 28일 기준 · 실사용 관점 리뷰
Nanoclaw 실사용후기: 개인 AI 에이전트로 써볼 만할까?
한 줄로 말하면, Nanoclaw는 “내 메신저 안에 상주하는 개인 AI 에이전트”를 직접 굴려보고 싶은 개발자에게 꽤 매력적인 선택지입니다. 다만 설치 버튼 하나로 끝나는 서비스형 앱은 아니고, Docker, Claude Code, 채널 인증, 권한 설계를 어느 정도 이해해야 진짜 편해집니다.
먼저 결론: “가벼운 개인용 에이전트”라는 방향은 좋다
Nanoclaw를 살펴보면서 가장 먼저 든 생각은 “큰 플랫폼을 하나 더 들여오는 느낌”보다 “내가 이해할 수 있는 작은 런타임을 손에 쥐는 느낌”에 가깝다는 점이었습니다. 공식 홈페이지는 Nanoclaw를 보안형 개인 AI 에이전트로 설명하고, 컨테이너 안에서 실행되며 사용자가 이해하고 커스터마이즈할 수 있게 만들었다고 소개합니다. GitHub 저장소와 문서를 함께 보면 이 방향이 단순 마케팅 문구만은 아닙니다. 메시징 채널, 라우터, 세션, 컨테이너 실행기, 데이터베이스가 비교적 명확하게 나뉘어 있고, 기능을 전부 기본값으로 끌어안기보다 필요한 채널과 프로바이더를 스킬 방식으로 더하는 구조입니다.
실사용 관점에서 장점은 분명합니다. WhatsApp, Telegram, Discord, Slack 같은 대화 채널을 통해 에이전트를 부를 수 있고, 반복 작업은 스케줄로 돌릴 수 있으며, 각 에이전트 그룹이 별도 컨테이너와 작업 폴더를 갖는다는 점이 안심 포인트입니다. 반대로 단점도 선명합니다. 일반 소비자 앱처럼 “가입하고 로그인하면 끝”이 아닙니다. 터미널, Git, Docker, Claude Code, API 키 또는 구독, 채널별 인증 흐름을 다뤄야 합니다. 그래서 이 글의 결론은 중간입니다. 개발자, 홈서버 사용자, 업무 자동화에 진심인 사람에게는 추천할 만하지만, 단순 챗봇 앱을 기대한다면 아직은 꽤 손이 갑니다.
| 항목 | 체감 평가 | 이유 |
|---|---|---|
| 설치 난이도 | 중간 이상 | 공식 문서는 `bash nanoclaw.sh` 중심으로 단순화했지만, Docker와 Claude Code 환경 이해가 필요합니다. |
| 운영 매력 | 높음 | 메신저에서 에이전트를 부르고, 스케줄 작업과 메모리를 붙일 수 있어 개인 자동화에 잘 맞습니다. |
| 보안 설계 | 좋음 | 애플리케이션 권한 체크만 믿기보다 컨테이너 격리를 전면에 둔 점이 강점입니다. |
| 초보자 친화성 | 보통 이하 | 문서가 좋아도 결국 로컬 런타임, 인증, 서비스 상태를 봐야 합니다. |
Nanoclaw가 하는 일: 메신저와 로컬 에이전트 사이의 얇은 허브
Nanoclaw는 독립형 AI 모델이라기보다, Claude Agent SDK와 채널 앱 사이를 이어주는 개인용 에이전트 허브에 가깝습니다. 공식 사이트는 “개인 AI 에이전트”, “컨테이너에서 안전하게 실행”, “필요한 기능만 추가”라는 메시지를 반복합니다. GitHub README도 비슷합니다. 핵심은 메시지가 들어오면 호스트 프로세스가 라우팅하고, 세션 데이터베이스에 기록한 뒤, 컨테이너 안의 에이전트가 작업을 수행하고, 결과를 다시 채널로 돌려보내는 흐름입니다.
이 구조가 좋은 이유는 책임 경계가 보인다는 데 있습니다. 일반적인 자동화 봇은 어느 순간 “이 봇이 내 파일과 키를 어디까지 볼 수 있지?”라는 불안이 생깁니다. Nanoclaw는 이 질문에 대해 컨테이너, 명시적 마운트, 에이전트 그룹별 작업 공간이라는 답을 내놓습니다. 완벽한 보안이라는 뜻은 아니지만, 적어도 사용자가 검토할 수 있는 단위로 위험을 쪼개려는 설계입니다.
기능을 모두 넣지 않고, 필요한 것만 붙이는 방식
흥미로웠던 부분은 “스킬 over 기능”이라는 철학입니다. 채널 어댑터와 대체 모델 프로바이더를 전부 기본 패키지에 넣는 대신, 필요한 경우 `/add-telegram`, `/add-opencode`, `/add-ollama-provider` 같은 식으로 추가하는 방향입니다. 이 방식은 처음에는 낯설지만, 개인용 에이전트에서는 꽤 합리적입니다. 내가 Telegram만 쓸 사람이라면 Slack, Discord, Teams, iMessage 관련 코드를 기본으로 끌고 갈 필요가 없습니다. 반대로 여러 채널을 하나의 기억으로 묶거나, 채널별로 다른 에이전트를 붙이는 식의 운영도 가능해집니다.
설치와 첫 인상: 쉬운 듯하지만, “개발자용 쉬움”이다
공식 설치 문서는 macOS, Linux, Windows WSL2를 다룹니다. macOS는 12 Monterey 이상, Linux는 Ubuntu 22.04 이상 또는 Debian 12 계열, Windows는 WSL2 환경이 전제입니다. 문서상 최소 메모리는 macOS와 Windows 쪽에서 4 GB, Linux 쪽에서 2 GB로 제시되지만, 실제로 에이전트와 컨테이너를 같이 굴릴 생각이라면 여유 메모리가 있는 장비가 편합니다. 설치 명령 자체는 단순합니다.
git clone https://github.com/nanocoai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash nanoclaw.sh여기서 중요한 포인트는 명령이 짧다고 해서 과정이 가볍다는 뜻은 아니라는 겁니다. 설치 스크립트는 Node, pnpm, Docker 또는 컨테이너 런타임, OneCLI Agent Vault, 채널 페어링, 서비스 등록 같은 단계를 지나갑니다. 이미 개발 환경이 정리된 Mac이나 Linux 서버라면 흐름이 꽤 매끄럽게 느껴질 수 있습니다. 하지만 Docker가 처음이거나, WSL2와 Docker Desktop 연동이 낯선 환경이라면 첫날은 설치 자체가 실사용의 절반입니다.
제가 보기엔 Nanoclaw의 설치 경험은 “초보자도 된다”보다 “개발자가 덜 헤매게 해준다”에 가깝습니다. 이 차이를 알고 접근하면 만족도가 높습니다. 예를 들어 `better-sqlite3` 빌드 오류, Docker 데몬 미실행, WSL2 파일시스템 문제는 자동화 스크립트가 어느 정도 안내하더라도 결국 사용자가 환경을 이해해야 해결됩니다. 반대로 평소에 로컬 개발 서버, Docker 컨테이너, GitHub 저장소를 다뤄본 사람이라면 낯선 부분이 크게 줄어듭니다.
직접 설치하고 테스트한 결과: OpenAI Codex로도 동작했다
이번 글은 문서만 읽고 쓴 요약이 아니라, 실제로 macOS에서 NanoClaw를 클론하고 Docker Desktop, OneCLI, 에이전트 컨테이너, CLI 채팅까지 돌려본 뒤 정리했습니다. 처음 환경 점검에서는 Docker가 없어서 Docker Desktop을 설치했고, 이후 `setup/index.ts --step environment`에서 Docker가 실행 중인 상태를 확인했습니다. 그 다음 `pnpm install`, 타입체크, 빌드, 테스트를 진행했고, 기본 컨테이너 빌드는 `BUILD_OK: true`, `TEST_OK: true`로 통과했습니다.
OneCLI 단계도 성공했습니다. OneCLI는 NanoClaw가 비밀값을 컨테이너 안에 직접 넣지 않고, 게이트웨이를 통해 필요한 요청에 주입하게 만드는 핵심 구성입니다. 설치 후 로컬 게이트웨이는 `http://127.0.0.1:10254`에서 healthy 상태로 올라왔습니다. Anthropic 토큰 등록은 브라우저 OAuth 승인 코드가 필요해 중단했지만, 이 지점에서 중요한 발견이 있었습니다. NanoClaw의 `providers` 브랜치에는 `/add-codex` 경로가 있고, 현재 Mac에는 Codex CLI가 ChatGPT 계정으로 로그인되어 있어 OpenAI Codex provider로 우회 테스트가 가능했습니다.
OpenAI로 가능한지 확인하기 위해 `providers` 브랜치의 Codex provider 파일을 테스트 설치본에 추가했습니다. 이후 Dockerfile에 `@openai/codex@0.133.0` 설치 레이어를 넣고 에이전트 이미지를 다시 빌드했습니다. 컨테이너 내부에서 Codex provider 단위 테스트 9개가 통과했고, 새 이미지 빌드에서도 `@openai/codex` 설치, 컨테이너 테스트, `STATUS: success`를 확인했습니다. 즉 “NanoClaw는 Anthropic만 가능한가?”라는 질문에는 “기본값은 Claude지만, provider 추가 방식으로 OpenAI Codex도 가능하다”가 제 답입니다.
마지막으로 CLI 채널에 `NanoCodex`라는 테스트 에이전트 그룹을 만들고 provider를 `codex`로 설정한 뒤 실제 메시지를 보냈습니다. `pnpm run chat "안녕, 한 문장으로 자기소개해줘. provider 확인용 테스트야."`를 실행하자 NanoClaw가 세션을 만들고, Docker 컨테이너를 띄운 뒤, 한국어 답변을 돌려줬습니다. 공식 `verify` 단계도 `SERVICE: running`, `CONTAINER_RUNTIME: docker`, `CREDENTIALS: configured`, `REGISTERED_GROUPS: 1`, `STATUS: success`로 끝났습니다.
| 직접 테스트한 항목 | 결과 | 메모 |
|---|---|---|
| Docker Desktop 설치 및 데몬 확인 | 성공 | Docker 29.5.2 기준으로 컨테이너 빌드와 실행 확인 |
| pnpm install / build / test | 성공 | 기본 테스트 332개 통과, Codex provider 테스트 9개 추가 통과 |
| OneCLI gateway | 성공 | 로컬 `127.0.0.1:10254`에서 healthy 확인 |
| Anthropic 토큰 | 수동 승인 필요 | Claude OAuth 코드 입력이 필요한 구간에서 중단 |
| OpenAI Codex provider | 성공 | ChatGPT 로그인된 Codex CLI auth를 활용해 실제 채팅 왕복 성공 |
OpenClaw와 다른 점: 큰 플랫폼 vs 작게 이해 가능한 런타임
NanoClaw README는 스스로를 OpenClaw의 가벼운 대안으로 설명합니다. README 기준으로 NanoClaw가 문제 삼는 지점은 OpenClaw의 큰 코드베이스와 많은 설정 파일, 애플리케이션 레벨 보안 모델입니다. 반면 OpenClaw 공식 문서와 GitHub는 50개 이상 채널, 수천 개 스킬, macOS/iOS/Android 보조 앱, WebChat, Voice Wake, Live Canvas 같은 넓은 기능 표면을 강조합니다. 그래서 둘의 차이는 “누가 더 좋다”보다 “무엇을 우선하느냐”에 가깝습니다.
| 비교 항목 | NanoClaw | OpenClaw |
|---|---|---|
| 기본 방향 | 작고 이해 가능한 개인용 런타임. 필요한 기능을 스킬로 더하는 쪽. | 여러 채널, 앱, 스킬 생태계를 포함한 넓은 개인 AI 플랫폼. |
| 보안 관점 | 에이전트별 Docker 컨테이너와 명시적 마운트를 전면에 둠. | 공식 문서상 secure sandbox와 권한 승인을 강조하지만 기능 표면이 더 넓음. |
| 기능 폭 | 기본은 얇고, 채널/프로바이더는 필요한 것만 추가. | 50개 이상 채널, 5700개 이상 스킬, 앱과 UI 기능을 강조. |
| 설정 방식 | 코드 커스터마이즈와 fork 운영을 자연스럽게 전제. | `~/.openclaw/openclaw.json` 같은 설정과 앱/CLI 중심 운영. |
| 추천 상황 | 내가 이해 가능한 작은 시스템, 컨테이너 격리, 직접 커스터마이즈를 원할 때. | 처음부터 많은 통합, 앱 UI, 커뮤니티 스킬 생태계를 원할 때. |
제가 직접 설치해본 느낌으로는 NanoClaw가 더 “DIY 개발자 도구”에 가깝습니다. OpenClaw는 공식 홈페이지에서 Mac, Windows, Linux, Anthropic, OpenAI, 로컬 모델, 다양한 채팅 앱, 브라우저 제어, 전체 시스템 접근까지 폭넓게 내세웁니다. 이건 장점입니다. 처음부터 많은 것을 연결하고 싶은 사람에게는 OpenClaw 쪽의 넓은 생태계가 매력적일 수 있습니다. 다만 그만큼 사용자는 더 큰 시스템을 신뢰해야 합니다.
NanoClaw는 반대로 일부러 작게 시작합니다. 실제 테스트에서도 기본 Claude 경로가 막히자 `providers` 브랜치의 Codex provider를 붙여 OpenAI로 전환할 수 있었고, 그 과정이 코드 변경과 이미지 재빌드로 투명하게 드러났습니다. 즉 NanoClaw의 장점은 “기능이 더 많다”가 아니라 “내가 무슨 코드를 추가했고, 어떤 컨테이너에서 실행되는지 볼 수 있다”에 있습니다. 개인 파일과 API 키를 맡기는 도구라면 이 차이는 꽤 큽니다.
실사용에서 좋았던 점: “대화창을 작업 큐로 쓰는 느낌”
Nanoclaw의 매력은 별도 대시보드를 열지 않고도 메신저에서 에이전트를 호출한다는 점입니다. 일반 자동화 도구는 설정 화면, 워크플로 편집기, 로그 화면, 권한 화면이 따로 흩어져 있는 경우가 많습니다. Nanoclaw는 이걸 대화 중심으로 가져옵니다. 예를 들어 매주 월요일 아침에 뉴스를 정리하게 하거나, 특정 저장소를 주기적으로 점검하게 하거나, 가족 채팅방에서 일정 정리를 맡기는 식의 사용 시나리오가 자연스럽습니다.
물론 실제 업무에 바로 연결하려면 조심해야 합니다. AI 에이전트는 단순 답변기가 아니라 파일을 읽고, 명령을 실행하고, 외부 API를 호출할 수 있는 작업자입니다. 그래서 컨테이너 격리와 마운트 허용 목록은 장점이면서 동시에 사용자가 계속 챙겨야 할 운영 체크리스트입니다. “편하다”는 감각만 보고 모든 폴더를 열어주면 Nanoclaw를 쓰는 의미가 줄어듭니다. 반대로 필요한 폴더만 좁게 열고, 에이전트 그룹별로 역할을 나누면 개인용 자동화 시스템으로 꽤 믿음직해집니다.
체감상 좋은 활용 흐름
특히 마음에 든 부분은 “나중에 봐줘”류의 요청과 잘 맞는다는 점입니다. 단발성 질문은 ChatGPT나 Claude 앱에서 해도 충분합니다. Nanoclaw가 빛나는 지점은 반복 작업입니다. 매일 아침 요약, 매주 저장소 점검, 특정 채팅방에 올라온 내용을 정리, 개인 노트 폴더에서 자료를 찾아 답하기 같은 작업은 한 번 연결해두면 대화창 자체가 작업 큐가 됩니다.
메신저 연동: 넓지만, 채널별 준비물이 다르다
통합 문서를 보면 Nanoclaw는 채널과 프로바이더를 나눠 설명합니다. 채널은 메시지가 들어오는 곳이고, 프로바이더는 어떤 AI가 에이전트를 실행하는지에 해당합니다. WhatsApp, Telegram, Discord, Slack, Signal 같은 채널이 문서화되어 있고, Teams, iMessage, Matrix, Google Chat, Webex, Linear, GitHub, WeChat 같은 항목도 채널 브랜치에서 언급됩니다. 프로바이더 쪽은 Claude 기본값 외에 OpenAI Codex, OpenCode, Ollama 같은 선택지가 설명됩니다.
여기서 실사용 팁은 처음부터 모든 채널을 붙이지 않는 겁니다. 개인용이면 Telegram 또는 WhatsApp 중 하나, 팀 실험이면 Discord 또는 Slack 하나만 먼저 붙이는 편이 좋습니다. 채널이 늘어나면 인증 방식, 메시지 권한, 그룹별 메모리, 알림 소음도 함께 늘어납니다. Nanoclaw의 장점은 여러 채널을 지원한다는 것이지만, 운영 품질은 “얼마나 많이 붙였는가”보다 “어떤 채널을 어떤 에이전트 그룹에 안전하게 연결했는가”에서 갈립니다.
아쉬운 점과 주의할 점: 아직은 손맛이 있는 도구
Nanoclaw를 추천할 때 가장 조심해야 할 부분은 기대치입니다. 이름만 보면 가벼운 앱처럼 느껴질 수 있지만, 실제로는 로컬 런타임과 컨테이너를 직접 운영하는 도구입니다. 설치가 한 번 끝났다고 모든 관리가 끝나는 것도 아닙니다. Docker 업데이트, 채널 토큰, Claude 사용량, 로그 확인, 마운트 권한, 저장소 업데이트를 챙겨야 합니다. 자동화가 편해질수록 책임도 함께 늘어납니다.
또 하나는 비용입니다. Nanoclaw 자체가 오픈소스라고 해도, 실제 에이전트가 사용하는 모델 비용은 별도입니다. Claude Agent SDK나 Claude Code 구독, API 키, 또는 대체 프로바이더를 어떤 방식으로 쓰는지에 따라 비용 체감이 달라집니다. 반복 작업을 많이 걸어두면 “편해서 많이 쓰는 만큼” 모델 사용량도 올라갈 수 있습니다. 그래서 처음에는 스케줄 작업을 적게 만들고, 로그와 사용량을 보면서 늘리는 게 좋습니다.
실사용 전 체크리스트
- Docker Desktop 또는 Docker Engine이 안정적으로 켜져 있는지 확인합니다.
- 에이전트가 접근할 폴더를 최소 단위로 정하고, 불필요한 홈 디렉터리 전체 마운트는 피합니다.
- 처음에는 채널 1개, 에이전트 그룹 1개, 스케줄 1개로 시작합니다.
- Claude 또는 대체 프로바이더 비용을 주간 단위로 확인합니다.
- 업데이트 전에는 현재 설정과 데이터베이스 위치를 백업합니다.
첫 주 운영 시나리오: 작게 시작해야 오래 간다
Nanoclaw를 실제로 굴린다고 가정하면 첫 주 목표는 거창한 자동화가 아니라 안정성 확인이어야 합니다. 1일차에는 설치와 채널 1개 연결만 끝내고, 에이전트가 어떤 이름으로 호출되는지, 답장이 어느 정도 지연되는지, 로그가 어디에 쌓이는지 확인하는 정도가 적당합니다. 2일차에는 에이전트가 읽을 수 있는 폴더를 아주 좁게 정합니다. 예를 들어 블로그 초안 폴더, 회의록 폴더, 테스트용 저장소처럼 실패해도 피해가 작은 공간부터 열어보는 식입니다. 처음부터 홈 폴더 전체나 업무 자료 전체를 연결하면 편하긴 하지만, 문제가 생겼을 때 원인과 영향을 파악하기 어려워집니다.
3일차부터는 반복 작업 1개를 걸어보는 편이 좋습니다. 매일 오전 9시에 전날 메모를 요약하거나, 매주 금요일 오후 5시에 저장소 변경점을 정리하게 하는 정도면 충분합니다. 이 단계에서 봐야 할 것은 답변 품질보다 운영 리듬입니다. 메시지가 중복으로 오지 않는지, 실패했을 때 다시 시도하는지, 비용이 예상보다 빨리 늘지 않는지, 채널 알림이 생활을 방해하지 않는지 확인해야 합니다. 개인 AI 에이전트는 한 번 멋진 답을 하는 것보다 매일 조용히 제 역할을 하는지가 더 중요합니다.
4일차 이후에는 역할을 나누는 실험을 해볼 수 있습니다. 하나의 에이전트에게 모든 일을 맡기는 대신, 블로그 자료 조사용 에이전트, 코드 리뷰용 에이전트, 개인 일정 요약용 에이전트를 분리하면 권한 설계가 쉬워집니다. 각 에이전트 그룹이 별도 작업 공간과 기억을 갖는 구조는 이런 운용에 잘 맞습니다. 다만 역할을 너무 많이 나누면 관리가 번거로워지므로 처음에는 2개 정도가 적당합니다. “많이 자동화했다”보다 “어떤 일은 맡기고 어떤 일은 직접 한다”는 경계를 잡는 것이 Nanoclaw를 오래 쓰는 요령입니다. 이 경계가 선명할수록 에이전트 답변도 안정되고, 문제가 생겼을 때 되돌리기도 쉬워집니다. 작게 시작하는 편이 결국 빠릅니다.
추천 대상: 개인 자동화에 진심인 사람에게 맞다
Nanoclaw는 “AI 비서 앱 하나 추천해줘”라는 사람보다 “내가 쓰는 채팅 앱을 개인 자동화 허브로 만들고 싶다”는 사람에게 어울립니다. 홈서버를 굴리는 사람, 개인 지식 관리 폴더를 AI에게 제한적으로 열어주고 싶은 사람, GitHub 저장소나 문서 작업을 주기적으로 점검하고 싶은 사람, 메신저 기반 업무 자동화에 관심 있는 사람이라면 시도할 가치가 있습니다.
반대로 비개발자에게 바로 추천하기는 조심스럽습니다. 공식 FAQ는 코드를 몰라도 설치할 수 있다고 말하지만, 현실적으로 터미널과 Docker가 등장하는 순간 심리적 장벽이 생깁니다. 주변에 설치를 도와줄 사람이 있거나, 본인이 커맨드라인을 배우는 데 거부감이 없다면 괜찮습니다. 하지만 “카카오톡 챗봇처럼 바로 쓰고 싶다”는 기대라면 지금은 서비스형 AI 앱이 더 편합니다.
| 추천 | 보류 |
|---|---|
| Docker와 Git 사용 경험이 있는 사람 | 터미널 사용 자체가 부담스러운 사람 |
| 반복 리서치, 요약, 알림을 자동화하고 싶은 사람 | 단순 질의응답 챗봇만 필요한 사람 |
| 로컬 파일 접근 범위를 직접 통제하고 싶은 사람 | 권한과 보안 설정을 신경 쓰고 싶지 않은 사람 |
| 메신저를 작업 지시 인터페이스로 쓰고 싶은 사람 | 모바일 앱 하나로 모든 설정이 끝나길 원하는 사람 |
최종 평가는 “기대보다 실용적이지만, 기대보다 엔지니어링 도구에 가깝다”입니다. Nanoclaw의 진짜 장점은 화려한 UI가 아니라, 에이전트가 어디서 실행되고 무엇에 접근하는지 사용자가 이해할 수 있게 만들려는 태도입니다. 개인 AI 에이전트를 오래 굴릴수록 이 태도는 중요해집니다. 지금 당장 모든 사람에게 필요한 도구는 아니지만, AI 자동화를 로컬과 메신저 중심으로 가져가려는 사람에게는 꽤 좋은 출발점입니다.
참고한 공식 자료
FAQ
Q1. Nanoclaw는 일반 AI 챗봇 앱인가요?+
아닙니다. Nanoclaw는 메신저 채널, 로컬 호스트 프로세스, 컨테이너 안의 AI 에이전트를 연결하는 오픈소스 런타임에 가깝습니다. 단순 질문 답변보다 반복 작업, 파일 기반 작업, 채널 연동 자동화에 더 잘 맞습니다.
Q2. 비개발자도 쓸 수 있나요?+
가능은 하지만 추천 조건이 있습니다. Git clone, Docker 실행, 터미널 명령 입력, 채널 인증 흐름을 따라갈 수 있어야 합니다. 설치를 도와줄 사람이 있으면 비개발자도 사용할 수 있지만, 혼자 처음부터 끝까지 하려면 어느 정도 학습이 필요합니다.
Q3. Nanoclaw 자체는 무료인가요?+
저장소는 MIT 라이선스의 오픈소스로 공개되어 있습니다. 다만 실제 에이전트 실행에는 Claude Code, Claude API, 또는 대체 프로바이더 사용 비용이 들 수 있습니다. 반복 스케줄을 많이 만들수록 모델 사용량도 늘 수 있으니 초반에는 작업 수를 제한하는 편이 좋습니다.
Q4. 가장 먼저 어떤 채널을 붙이는 게 좋나요?+
개인용이면 Telegram 또는 WhatsApp 중 하나, 팀 실험이면 Discord 또는 Slack 중 하나로 시작하는 편이 좋습니다. 처음부터 여러 채널을 붙이면 인증과 권한, 알림 관리가 복잡해지므로 작은 구성으로 안정성을 확인한 뒤 늘리는 방식이 안전합니다.
Q5. Nanoclaw의 핵심 장점은 무엇인가요?+
핵심 장점은 이해 가능한 크기, 컨테이너 기반 격리, 메신저 중심 인터페이스, 필요한 기능만 추가하는 구조입니다. 특히 개인 파일과 반복 작업을 AI에게 맡기고 싶지만 권한 경계를 직접 통제하고 싶은 사용자에게 잘 맞습니다.
Q6. OpenAI로도 사용할 수 있나요?+
가능합니다. 기본 설치 흐름은 Claude 중심이지만, `providers` 브랜치의 `/add-codex` 경로를 통해 OpenAI Codex provider를 붙일 수 있습니다. 이번 테스트에서는 ChatGPT 계정으로 로그인된 Codex CLI 인증을 사용했고, `provider: codex`로 설정한 테스트 에이전트가 실제로 한국어 답변을 반환했습니다.
'AI' 카테고리의 다른 글
| Hermes Agent 리뷰 (0) | 2026.05.29 |
|---|---|
| OpenClaw 다운로드 및 테스트 후기 (0) | 2026.05.29 |
| MCP 정확히 이해하기: AI 스킬과 도구 연결 표준의 차이 (0) | 2026.05.28 |
| Superpowers? 그래서 그게 뭔데? AI 코딩 에이전트 스킬 프레임워크 정리 (0) | 2026.05.27 |
| DESIGN.md란 무엇이고 어떻게 사용하는가 (0) | 2026.05.27 |
