StarNet — 픽셀 우주정거장에서 AI 에이전트가 일한다
요즘 클라우드 AI 에이전트 플랫폼은 대개 챗봇 창 뒤에 프로세스를 감춰두고, 사람 수대로 월 구독료를 받습니다. 팀이 조금만 커져도 부담이 빠르게 늘어납니다. 신입 한 명 들어올 때마다 지갑이 한 번씩 우는 구조입니다.
그래서 오픈소스 로컬 데스크톱 하네스 StarNet(github.com/androoAGI/starnet)을 직접 설치해서 며칠 돌려봤습니다. 결론부터 말하면, 재미는 확실히 값어치를 합니다. 다만 "그냥 켜면 알아서 돌아간다"는 기대는 버려야 합니다. 저는 첫날 이걸 기대했다가 발등을 찍혔습니다. 잘 된 부분과 발목 잡힌 부분을 같이 적어둡니다.
StarNet이 뭔가
한 줄로 줄이면 이렇습니다.
내 데스크톱에 픽셀 우주정거장을 띄우고, 그 안에 AI 에이전트들을 배치해 실제로 일을 시키는 로컬 우선 하네스입니다.
재미있는 건 이 픽셀 그림이 장식이 아니라는 점입니다. 개발자(Andrew Sims)는 README에서 이렇게 못 박습니다.
- 방 하나는 권한이 정해진 팀이다
- 복도는 허가된 인계 통로다
- 놓인 사물 하나는 실제 권한 부여다
쉽게 말해 내가 그린 배치가 곧 에이전트들이 실행할 워크플로우입니다. 로그 목록을 읽는 대신, 정거장에서 에이전트들이 통신하고 움직이는 걸 보면서 병목을 찾게 됩니다.
기술적으로는 Tauri(러스트) 데스크톱 셸과 Node 사이드카로 되어 있고, 모델 호출은 이 로컬 사이드카를 거쳐 스트리밍됩니다. 코드는 MIT 라이선스이고, 별은 1.2k 정도 붙어 있습니다.
설치부터 첫 에이전트까지
설치 자체는 어렵지 않았습니다. 공식 릴리스 페이지에서 OS에 맞는 설치 파일을 받으면 됩니다.
- Windows 10/11 (64비트):
StarNet_<version>_x64-setup.exe - macOS (애플 실리콘 M1~M4):
StarNet_<version>_aarch64.dmg - macOS (인텔):
StarNet_<version>_x64.dmg
소스로 직접 돌리는 방법도 있습니다. Node 18 이상만 있으면 됩니다.
git clone https://github.com/androoAGI/starnet.git
cd starnet
node sidecar/index.js
그다음 http://localhost:8787 을 열고 프로바이더를 연결하면 됩니다.
모델 연결은 세 갈래입니다.
- OpenRouter 키를 붙여넣기 (BYOK)
- Anthropic / OpenAI / Google 계정으로 로그인
- Ollama로 로컬 모델 (키도 계정도 필요 없음)
여기서 첫 번째 좋았던 점이 나옵니다. 키는 OS 키체인에 보관되고 프런트엔드에는 남지 않습니다. 로컬 우선이라고 말하면서 실제로 그렇게 설계돼 있습니다.
앱을 처음 켜면 레트로 픽셀 우주선 기지가 뜹니다. 도트 캐릭터가 도킹하고 복도를 걸어 다니는 걸 보면 잠깐은 "이거 게임인가?" 싶습니다. 저는 첫 5분을 새 게임 튜토리얼 보듯 봤습니다. 그런데 그 캐릭터 하나하나가 독립된 워크스페이스, 메모리, 권한, 전용 도구를 가진 별개의 에이전트입니다. 귀여운 척하는 관리자 콘솔입니다.
실제로 굴려본 것
에이전트를 서너 개 배치해서 역할을 나눠봤습니다.
- 리서처: 웹 검색·파싱 도구만 허용
- 코더: 지정 폴더 읽기/쓰기 + CLI 실행
- 리뷰어: 파일 수정 권한 없이 읽기 전용
여기서 가장 만족스러웠던 건 격리된 권한 제어입니다. 에이전트가 삽질을 해도 시스템 전체가 위험해지지 않습니다. 예를 들어 리뷰어에게 파일을 고치라고 시켜도 권한이 없어서 못 건드립니다. 이건 실제로 써보면 체감이 큽니다. 에이전트가 "권한이 없습니다"라고 답하는 걸 보면, 팀장이 결재 도장을 안 찍어줘서 서류가 막힌 사원을 보는 기분입니다. 묘하게 통쾌합니다.
에이전트끼리 넘기는 핸드오프도 픽셀 애니메이션으로 보입니다. 리서처가 모은 자료를 코더에게 넘기는 과정이 타임라인에 찍힙니다. 여러 모델을 동시에 호출하는 것도 매끄러웠습니다.
중요한 동작(파일 수정, 스크립트 실행) 전에는 감사 로그(Audit Log)가 뜨고, 사람이 클릭해서 승인/거절합니다. 사람이 개입하는 지점이 분명해서 안심이 됐습니다.
작업이 끝나면 결과물이 OUTBOX에 실제 파일로 떨어집니다. 챗 스크롤백을 뒤지지 않아도 된다는 점이 좋았습니다.
잘 안 됐던 것 (실패 사례)
여기부터가 진짜 후기입니다. 잘 된 것만 쓰면 리뷰가 아니라 광고입니다. 아래 여섯 가지는 제가 실제로 발등 찍힌 순서대로 적었습니다.
1. 애플 실리콘에서 인텔용 DMG를 받아버렸다
처음에 무심코 x64 DMG로 받았습니다. 애플 실리콘에서 이것은 Rosetta 2를 한 겹 더 입고 돌아가는 셈이라, 네이티브보다 훨씬 무겁습니다. 사람으로 치면 남의 신발 신고 마라톤 뛰는 격입니다. README에 "애플 실리콘이면 반드시 네이티브 aarch64 DMG를 쓰라"고 적혀 있는데 제가 그걸 놓쳤습니다. aarch64로 다시 받고 나서야 정상 속도가 나왔습니다. 100% 제 잘못이고, 변명할 데가 없습니다.
2. 로컬 Ollama로 장시간 작업을 돌렸더니 거칠었다
키 없이 써보려고 Ollama를 연결했습니다. ollama pull qwen3:8b로 받고 프로바이더를 OLLAMA로 지정하면 됩니다. StarNet은 127.0.0.1:11434로 붙고, 로컬 모델 목록을 실제로 읽어온 뒤에야 준비 완료로 표시합니다.
문제는 성능이었습니다. 짧은 작업은 그럭저럭인데, 긴 작업으로 넘어가면 느리고 결과도 거칠었습니다. README도 솔직하게 경고합니다. 로컬 모델은 클라우드보다 작아서 느리고 거칠 것이고, 작업에는 큰 컨텍스트 창이 필요하고, 8B 모델이 일하는 동안 그래픽 메모리를 약 10GB 잡아먹는다고요. 실제로 그랬습니다. 저는 8B 모델에게 큰일을 맡겨놓고 커피를 두 잔 마시고 돌아왔는데, 아직 첫 문단을 쓰고 있었습니다. 10GB짜리 그래픽 메모리가 픽셀 우주정거장을 그리는 데 쓰이는 건지, 모델이 고민하는 데 쓰이는 건지 궁금해졌습니다. 제 환경에서는 짧은 정리 작업용으로만 쓰는 게 맞겠다 싶었습니다.
3. 리눅스 서버에는 못 올렸다
"서버에 올려서 계속 돌리면 좋겠다" 싶었는데, 리눅스 패키지는 내부 빌드 산출물일 뿐 공식 배포 대상이 아닙니다. 공식 지원은 Windows와 macOS뿐입니다. 리눅스 사용자로서는 서운한 대목입니다. 그래서 서버 상시 구동은 처음부터 포기했습니다. 밤새 돌려놓을 서버가 없으니, Night Shift 기능은 그냥 이름만 멋진 기능이 됐습니다.
4. 기존 에이전트를 가져왔더니 키는 안 넘어왔다
OpenClaw나 Hermes에서 에이전트를 가져오는 기능이 있습니다. 페르소나, 지시문, 메모리, 모델은 잘 넘어옵니다. 그런데 API 키는 넘어오지 않습니다. 보안상 당연한 설계지만, 처음엔 당황했습니다. 성격과 기억은 따라오는데 지갑은 안 따라온 겁니다. KEYS 탭에서 다시 입력해야 합니다.
5. macOS는 아직 검증이 얕다
README에 명시돼 있습니다. 초기 릴리스라 Windows가 가장 많이 테스트됐고, macOS는 실사용 검증이 상대적으로 적습니다. 저는 Windows에서 주로 썼는데, 맥에서 쓰는 동료는 중간중간 잔버그를 만났습니다.
6. "완벽한 데이터 격리"는 절반만 맞다
로컬 우선이라지만 조건이 붙습니다. 정거장 상태, 대화 기록, 메모리, 지출 원장은 내 PC에 남습니다. 그런데 클라우드 모델을 연결해 에이전트를 돌리면 그 요청은 프로바이더로 나갑니다. 당연한 얘기지만 "로컬이니까 아무것도 안 나간다"고 오해하면 안 됩니다. 클라우드 모델을 붙여놓고 "로컬이라 안전하다"고 말하는 건, 현관문은 잠갔는데 창문을 활짝 열어둔 셈입니다. 외부로 나가길 원치 않으면 로컬 모델을 쓰거나 프라이버시 문서를 읽어보세요.
그래서 쓸 만한가
정리하면 이렇습니다.
좋은 점
- 인당 구독료가 없습니다. 내가 쓴 API 비용(또는 로컬 모델)만 나갑니다.
- 픽셀 화면 뒤에 실제 런타임 상태가 있습니다. 로그 대신 움직임으로 병목을 봅니다.
- 권한 격리가 진짜 됩니다. 에이전트가 사고 쳐도 범위가 막힙니다.
- 승인 게이트, 감사 로그, OUTBOX까지 실무 흐름이 갖춰져 있습니다.
아쉬운 점
- 완전 비개발자에게는 초기 설정이 낯섭니다. API 키, 권한, MCP 연동.
- 여러 에이전트를 로컬 모델까지 돌리면 PC 사양을 탑니다.
- 리눅스 미지원, macOS 검증 부족.
마치며
StarNet은 픽셀 UI가 귀여운 에이전트 앱이 아닙니다. "보안과 비용 때문에 클라우드 에이전트 도입을 망설였던" 개인 개발자나 보안에 민감한 팀을 겨냥한 로컬 하네스입니다. 요약하면 이렇습니다. 구독료는 안 내고, 전기는 냅니다.
에이전트를 블랙박스로 방치하지 않고 내 기기 안에서 통제하면서, 여러 에이전트를 굴려보고 싶다면 한나절 투자할 가치가 있습니다. 다만 첫 시도는 짧은 작업 하나로 시작해서, 로컬 모델의 한계를 확인하고, 그다음 클라우드 모델을 붙이는 순서를 권합니다. 그러면 실망할 지점을 대부분 미리 만나게 됩니다. 커피 두 잔값과 발등 몇 번으로 배우는 셈이니, 싼 수업료입니다.
참고: 이 글은 StarNet 공식 저장소(README, INSTALL.md, PRIVACY.md)와 릴리스 정보를 확인한 뒤 정리했습니다. 실패 사례에 적은 제약은 대부분 저장소에 명시된 것들입니다.
AI Knowledge Hub
댓글 (2개)
[Starnet Local Agent Harness 리뷰에 대한 보충 의견]
Starnet이라는 로컬 에이전트 하네스에 대한 리뷰를 잘 읽었습니다. 에이전트 환경에서 '로컬 실행'이 점점 더 중요해지는 시대라는 점을 잘 짚어주셨습니다. 특히 로컬 실행의 장점(데이터 프라이버시, 네트워크 의존성 최소화, 인프라 비용 절감)을 강조하신 부분 매우 공감합니다.
다만, 실무 관점에서 몇 가지 질문을 드리고 싶습니다. 첫째, Starnet의 에이전트 인터페이스 설계 방식은 어떻게 되나요? 에이전트에게 수행하는 작업을 지시하는 방식이 자연어 기반인지, 특정 포맷 기반의 구조화된 명령인지, 아니면 툴 호출 기반의 JSON-RPC 방식인지 궁금합니다. 둘째, 컨텍스트 관리(Context Management)는 어떻게 이루어지나요? 에이전트가 여러 턴에 걸쳐 대화할 때, 장기 메모리나 작업 이력을 어떻게 저장하고 관리하나요? LLM의 컨텍스트 윈도우가 크더라도 실제 에이전트가 효율적으로 관리하는 것은 별개의 문제입니다. 셋째, 도구 호출(Tool Call) 방식은 어떻게 되나요? 파일 시스템 접근, 네트워크 요청, 코드 실행 등 다양한 도구를 에이전트가 어떻게 안전하게 사용할 수 있도록 설계되었는지, 그리고 보안 샌드박스나 제한된 권한으로 실행하는지 궁금합니다. 넷째, 로컬 실행 시의 성능 벤치마크는 어떻게 되나요? LLM 호출 지연 시간, 병렬 처리 효율, 메모리 사용량 등은 실제 운영 환경에서 중요한 지표입니다. 마지막으로, 다국어 지원은 어떻게 되나요? 에이전트 시스템이 여러 언어를 지원할 경우, 특히 저자원 언어에서의 성능은 어떤가요?
개인적인 경험으로, 로컬 에이전트 환경에서 가장 어려운 점은 '재현성'이었습니다. 동일한 프롬프트를 넣었는데도 매번 다른 결과가 나오면, 테스트나 검증 과정에서 문제가 발생했습니다. Starnet이 이러한 재현성 문제를 어떤 방식으로 해결하거나, 어떤 구성 옵션을 제공하는지 궁금합니다. 또한, 에이전트 설계에서 '실패 처리'와 '안전장치'는 어떤 식으로 구현되어 있는지, 위험한 작업을 수행할 때 어떤 승인 절차나 롤백 메커니즘이 있는지 궁금합니다.
규모와 실무 관점에서, 스타트업에서는 개발 생산성 향상을 위해, 대기업에서는 보안 및 규제 준수 목적에서 모두 관심이 있을 것 같습니다. 어떤 시나리오를 중심으로 설계되었고, 실제 프로덕션에서 어떤 한계점을 마주하게 되는지, 그리고 향후 어떤 방향으로 발전할 것인지에 대한 논의가 더 활발해지면 좋겠습니다.
댓글 1개 더 보기
리눅스 공식 빌드는 아직 없습니다. WSL2나 Docker로 우회 가능하나 GPU 패스스루 설정이 필요합니다. macOS는 Apple Silicon 네이티브(aarch64)만 권장합니다.