챗봇에게 질문을 던지고 답을 받는 방식에 익숙해진 사이, 다른 방향의 실험도 꾸준히 이어지고 있다. 질문에 답하는 대신 실제로 일을 처리하고, 앱을 닫아도 계속 돌아가며, 사용자를 기억하는 '개인 에이전트'다. 최근 Show HN에 공개된 nanoMuse도 그 계보에 속한다. 메타(Meta)의 Muse 콘셉트에서 영감을 받아 이름과 생김새를 가진 하나의 에이전트를 지향하되, 전체 구성을 직접 내려받아 실행하고 배포할 수 있는 오픈소스로 공개됐다는 점이 특징이다. 라이선스는 GPL-3.0-or-later이며, 프로젝트는 비영리 커뮤니티 성격을 내세운다.
무엇을 묶어 놓았나
nanoMuse에서 'nano'는 작게 쪼갠 모델을 뜻하는 것이 아니라, 혼자서도 돌릴 수 있을 만큼 전체 묶음이 간결하다는 의미로 쓰인다. 휴대폰 앱, 데스크톱 앱, 웹 콘솔, 그리고 이들을 연결하는 릴레이(relay)가 모두 하나의 저장소 안에 들어 있다. 이메일이나 중국 본토 전화번호로 로그인하면 세 종류의 기기가 하나의 계정을 공유하고 같은 대화 내역을 보여 준다. 로그인 시 커뮤니티 릴레이에서 일정량의 모델 사용이 무료로 제공되는데, 이 비용은 개발자가 부담하며 소진된 뒤에는 사용자가 자신의 API 키를 쓰는 구조다. 같은 릴레이를 사용자의 서버에 올릴 수도 있어, 원한다면 데이터를 집 밖으로 내보내지 않고 운용하는 길도 열어 둔다.
구조에서 눈여겨볼 부분은 기기마다 에이전트가 따로 돈다는 점이다. 휴대폰에서는 APK 안에서 proot로 올린 Alpine Linux와 셸, 브라우저, MCP가 돌아가고, 컴퓨터에서는 nanoMuse 데스크톱이 파이썬 런타임을 '손' 삼아 작업을 수행한다. 로그인한 기기들은 릴레이에서 만나 서로에게 작업을 요청할 수 있다. 이때 대화의 텍스트는 릴레이를 거쳐 오가지만, 파일과 스크린샷은 만들어진 자리에 그대로 남는다고 설명한다. 민감한 원본은 네트워크를 타지 않게 하고 조율용 메시지만 중계한다는 설계 의도로 읽힌다.
실무자가 따져 볼 지점
자체 호스팅 선택지가 세 갈래로 나뉘는 점은 도입을 검토하는 쪽에 의미가 있다. 서버 없이 자신의 키만 쓰는 방식, 제공된 스크립트(scripts/self-host.sh)로 자체 릴레이를 올리는 방식, 그리고 웹 앱을 위한 별도 런타임을 운용하는 방식이다. 문서는 VPS 한 대에 한 시간이면 구성할 수 있다고 안내한다. 사내 데이터 유출을 걱정해 외부 SaaS 에이전트를 꺼리던 팀이라면, 통제권을 어디까지 가져올지 단계적으로 고를 수 있다는 점이 실험 대상으로서의 매력이다. 설치 방법, 기기별 구성, 커넥터, 메모리, 프로토콜 등은 공식 문서와 저장소 내 docs 디렉터리에 정리돼 있다.
되돌릴 수 없는 작업 앞에서는 멈춰 확인을 구한다는 동작 원칙도 주목할 만하다. 파일 삭제나 외부 전송처럼 복구가 어려운 행위에 대해 사람의 승인을 받도록 설계했다는 것인데, 실제 작업을 수행하는 자율 에이전트에서 이런 확인 단계는 사고를 막는 최소한의 안전장치에 해당한다. 다만 공개된 설명만으로는 이 확인이 어떤 범위의 작업에 적용되는지, 사용자가 기준을 조정할 수 있는지까지는 알기 어렵다. 실제 업무에 붙여 보고 어디까지 자동으로 진행되는지 직접 확인하는 과정이 필요하다.
아직 초기 단계라는 점
현재 버전은 0.1.40으로, 숫자가 말해 주듯 초기 단계의 프로젝트다. 휴대폰 앱은 OpenMinis 1.13(GPL-3.0)을 기반으로 2026년 9월 24일 이후 수정돼 왔고, 파이썬 계열의 이전 버전은 MIT 라이선스였다고 밝힌다. 프로젝트 측은 Meta와 제휴하거나 승인받은 관계가 아니며 Muse는 메타의 상표라는 점, 로고로 쓰인 용은 프로젝트 고유의 것이라는 점을 분명히 하고 있다. 상표와 라이선스 경계를 명시한 것은 파생·재배포를 염두에 둔 오픈소스 프로젝트로서 합리적인 태도다.
정리하면 nanoMuse는 '여러 기기에 걸친 개인 에이전트'라는 아이디어를, 클라우드 종속을 줄이는 방향으로 통째 공개했다는 데 의미가 있다. 완성된 제품이라기보다 실제 작업에 써 보고 깨진 부분을 보고하며 함께 다듬어 가자는 초대에 가깝다. 자율 에이전트의 데이터 경계와 자체 호스팅에 관심 있는 실무자라면, 기능 목록을 평가하기보다 작은 작업 하나를 실제로 맡겨 보며 안전 확인과 기기 간 연동이 기대대로 동작하는지 가늠해 보는 편이 이 프로젝트의 성격에 맞는 접근이다.