로컬 AI 에이전트가 빠르게 흥미로워지고 있습니다. 이제 브라우저 탭에 머무는 비공개 챗봇에 그치지 않고, 코드를 작성하고 터미널을 사용하며 웹사이트를 탐색하고 프로젝트를 기억하고 사용자가 제어하는 하드웨어에서 실제 워크플로를 실행할 수 있습니다.
2026년에 더 이상 어려운 질문은 에이전트를 로컬에서 실행할 수 있는지 여부가 아니라, 실제로 주목할 가치가 있는 오픈 소스 프로젝트가 무엇인지입니다. 아래는 코딩, 자동화, 브라우저 제어, 메모리, 개인 지식 및 멀티 에이전트 워크플로에서 두각을 나타내는 10가지 프로젝트입니다.
오픈 소스 로컬 AI 에이전트 프로젝트를 선정한 방법
이는 GitHub 스타 수 순위표가 아닙니다. 과거에 많은 지지를 받은 프로젝트라도 미래 지향적인 2026년 주목 목록에는 적합하지 않을 수 있습니다.
대신 아래 프로젝트는 다음 다섯 가지 실용적인 질문을 중심으로 평가했습니다.
- 에이전트 런타임을 사용자가 제어하는 하드웨어에서 실행할 수 있나요?
- 로컬 또는 비공개 호스팅 모델 추론을 위한 신뢰할 만한 경로가 있나요?
- 도구, 코드, 브라우저, 워크플로, 메모리 또는 위임을 통해 실제로 작업을 수행할 수 있나요?
- 이 프로젝트는 2026년 오픈 소스 에이전트의 방향성에 여전히 부합하나요?
- 단순히 또 하나의 채팅 인터페이스가 아니라 에이전트 스택의 독립적인 영역을 대표하나요?
숫자 순서는 벤치마크 점수가 아닌 편집 기준입니다. 로컬 모델의 성숙도, 에이전트 역량, 생태계 잠재력, 배포 유연성, 그리고 각 프로젝트가 2026년 셀프 호스팅 AI의 방향성과 얼마나 밀접하게 맞는지를 반영합니다.
인기도를 기준으로 한 목록을 선호한다면, GitHub에서 인기 상승 중인 오픈 소스 AI 에이전트 스킬에 대한 별도 가이드를 확인해 보세요.
한눈에 보는 오픈 소스 로컬 AI 에이전트 프로젝트 상위 10개
| 순위 | 프로젝트 | 유형 | 로컬 AI 경로 | 추천 대상 |
|---|---|---|---|---|
| 1 | OpenClaw | 개인용 AI 에이전트 | 로컬 또는 비공개 호스팅 모델 엔드포인트 | 항상 실행되는 개인용 에이전트 |
| 2 | OpenHands | 소프트웨어 엔지니어링 에이전트 | Ollama, LM Studio, vLLM, SGLang | 자율 코딩 |
| 3 | goose | 데스크톱 및 CLI 에이전트 | Ollama 및 호환 로컬 엔드포인트 | 로컬 도구 자동화 |
| 4 | LocalAI | 추론 및 에이전트 플랫폼 | 네이티브 셀프 호스팅 추론 | 비공개 AI 인프라 |
| 5 | Agent Zero | 범용 컴퓨터 에이전트 | 모델 계층을 통한 로컬 모델 제공업체 | 완전한 작업 공간을 갖춘 에이전트 |
| 6 | Browser Use | 브라우저 에이전트 프레임워크 | Ollama 지원 모델 | 웹 자동화 |
| 7 | Cline | 코딩 에이전트 | Ollama, LM Studio 및 호환 엔드포인트 | IDE 중심 코딩 |
| 8 | Khoj | 개인 지식 에이전트 | 로컬 및 셀프 호스팅 LLM | 비공개 지식 및 리서치 |
| 9 | Letta | 상태를 유지하는 에이전트 플랫폼 | 로컬 에이전트 런타임 및 모델에 구애받지 않는 아키텍처 | 지속적인 에이전트 메모리 |
| 10 | CrewAI | 멀티 에이전트 프레임워크 | 로컬 모델 통합 | 구조화된 멀티 에이전트 워크플로 |
1. OpenClaw — 자체 기기에서 실행되는 개인용 AI 에이전트
OpenClaw는 AI 에이전트가 단일 채팅 창을 넘어서는 모습을 보여 주는 가장 명확한 사례 중 하나입니다. 이 프로젝트는 자체 기기에서 실행되며 Gateway가 어시스턴트의 제어 평면 역할을 하는 개인용 AI 어시스턴트라고 설명합니다.
이 아키텍처는 중요합니다. OpenClaw는 AI 모델을 애플리케이션 전체로 취급하는 대신 에이전트 계층을 기반 모델, 채널, 도구, 기기, 스킬과 분리합니다. 따라서 브라우저 탭이 열려 있을 때만 존재하는 것이 아니라 항상 실행되는 서비스로 어시스턴트를 바라볼 수 있습니다.
자체 호스팅 사용자에게 더 큰 기회는 아키텍처의 유연성입니다. 에이전트를 조정하는 머신이 반드시 무거운 모델 추론을 수행하는 머신일 필요는 없습니다. 소형 서버가 에이전트를 온라인 상태로 유지하는 동안, 요청은 네트워크의 다른 더 강력한 로컬 AI 서버로 라우팅할 수 있습니다.
이는 여러 클라이언트 기기가 각자 모델을 실행하려 하기보다 중앙 Ollama 환경을 사용하는, ZimaBoard 2 공유 로컬 AI 서버 구축에서 소개한 패턴과 유사합니다.
최적의 대상: 메시징, 도구, 스킬, 기기, 자동화를 하나의 자체 호스팅 제어 계층 아래에서 연결할 수 있는 지속형 개인 에이전트를 원하는 사용자.
주목할 점: 에이전트의 권한 범위가 넓어질수록 샌드박싱과 도구 정책의 중요성도 커집니다. 파일, 터미널, 브라우저 또는 커뮤니케이션 계정에 연결된 개인 에이전트에는 일반적인 챗봇보다 더 강력한 보안 모델이 필요합니다.
2. OpenHands — 가장 완성도 높은 로컬 코딩 에이전트 환경 중 하나
소프트웨어 엔지니어링을 AI 에이전트의 출발점으로 정의한다면, OpenHands는 주목할 만한 가장 강력한 프로젝트 중 하나입니다.
코드만 제안하는 대신, OpenHands는 저장소를 다루고 파일을 검사하며 명령을 실행하고 변경 사항을 적용한 뒤 소프트웨어 개발 작업을 반복 수행할 수 있는 에이전트를 중심으로 설계되었습니다. 따라서 기존의 코드 자동 완성 도구보다는 자율형 엔지니어링 환경에 더 가깝습니다.
로컬 모델 지원도 매우 명확하게 명시되어 있습니다. 공식 OpenHands 로컬 LLM 문서에서는 LM Studio, Ollama, vLLM 및 SGLang을 비롯한 로컬 모델 서버를 다룹니다.
동일한 문서는 이 목록의 거의 모든 프로젝트에 적용되는 중요한 점도 지적합니다. 로컬 모델에 연결할 수 있다고 해서 모든 로컬 모델이 에이전트로서 우수한 성능을 발휘하는 것은 아닙니다. 코딩 에이전트는 일반적인 채팅보다 도구 호출, 컨텍스트 관리, 지시 따르기 및 다단계 추론에서 훨씬 더 높은 수준을 요구합니다.
적합한 대상: 로컬 추론을 위한 탄탄한 경로를 갖춘 자체 호스팅 가능한 소프트웨어 엔지니어링 에이전트를 원하는 개발자.
주목할 점: 기술적으로 로컬에서 실행할 수 있는 모델과 장시간 코딩 작업을 안정적으로 수행할 수 있는 모델 사이에는 차이가 있습니다. 에이전트의 품질은 에이전트 프레임워크의 문제라기보다 모델 선택의 문제가 되는 경우가 많습니다.
3. goose — 코드, 리서치 및 자동화를 위한 네이티브 로컬 에이전트
goose는 데스크톱, CLI 및 API 인터페이스를 통해 사용할 수 있는 범용 오픈 소스 에이전트입니다. 코딩을 넘어 리서치, 글쓰기, 자동화, 데이터 분석 및 소프트웨어 개발과 같은 작업 흐름을 지원하도록 설계되었습니다.
goose의 로컬 모델 지원은 특히 강력합니다. 공식 goose 제공업체 문서에는 Ollama가 로컬 모델 실행기로 포함되어 있으며, 사용자 지정 OpenAI 호환 및 Ollama 호환 엔드포인트도 지원합니다.
즉, goose를 한 컴퓨터에서 실행하면서 LAN의 다른 위치에 있는 Ollama 또는 호환 가능한 모델 서버에 연결할 수 있습니다.
goose는 Model Context Protocol을 기반으로 한 확장 기능을 통해 도구도 제공합니다. 공식 goose 확장 기능 가이드에서는 외부 도구와 MCP 서버를 에이전트 세션에 추가하는 방법을 설명합니다.
네이티브 로컬 실행, 로컬 모델, MCP, 터미널 액세스 및 데스크톱 도구를 결합한 goose는 현재 오픈 소스 에이전트 생태계에서 가장 균형 잡힌 프로젝트 중 하나입니다.
적합한 대상: 좁은 범위의 코딩 도우미가 아니라 터미널 작업, 개발, 리서치 및 일반 자동화를 하나의 에이전트로 처리하려는 사용자.
주목할 점: 로컬 모델에는 안정적인 도구 호출 기능이 필요합니다. goose는 유용한 도구 호출을 지원하지 않는 모델이 사실상 일반적인 채팅 동작으로 되돌아갈 수 있다고 명시적으로 경고합니다.
4. LocalAI — 로컬 모델 서버에서 비공개 에이전트 인프라로
LocalAI는 주로 단일 어시스턴트가 아니라는 점에서 이 목록의 대부분 프로젝트와 다릅니다.
여러 추론 백엔드를 지원하면서 익숙한 API 인터페이스를 통해 로컬 모델을 제공할 수 있는 오픈 소스 AI 엔진입니다. 현재 프로젝트에는 도구 사용, RAG, MCP, 스킬을 포함한 기본 제공 AI 에이전트 기능도 포함되어 있습니다.
따라서 LocalAI는 다른 비공개 AI 애플리케이션을 뒷받침하는 인프라로서 점점 더 중요해지고 있습니다. 하나의 애플리케이션이 모델 서빙, 에이전트 로직, 멀티모달 생성, API를 모두 담당하도록 하는 대신, LocalAI를 여러 서비스가 함께 사용하는 공유 로컬 계층으로 활용할 수 있습니다.
공식 LocalAI 빠른 시작 문서에서는 로컬 추론과 기본 제공 모델 및 에이전트 관리 기능을 설명합니다.
이 아키텍처는 한 서버에서 로컬 모델, API, 임베딩, RAG, 여러 에이전트 애플리케이션을 동시에 호스팅할 수 있는 대규모 셀프 호스팅 환경에서 특히 흥미롭습니다.
이처럼 더 폭넓은 아키텍처를 살펴보고 있다면, 로컬 지식 베이스를 위한 AI 에이전트 스킬 가이드에서 모델 런타임, 검색, 스토리지, 에이전트 스킬을 하나의 비공개 스택에 어떻게 통합할 수 있는지 설명합니다.
적합한 대상: 독립형 어시스턴트 하나가 아니라 공유 로컬 AI 인프라 계층을 원하는 홈랩 사용자와 개발자.
주목할 점: LocalAI는 초보자에게 필요한 수준을 넘어서는 플랫폼일 수 있습니다. 로컬 AI 서비스, 모델, 사용자, 워크플로의 수가 늘어날수록 그 가치가 커집니다.
5. Agent Zero — 에이전트에게 실제 작업 공간 제공
Agent Zero는 에이전트에 대해 다른 방향으로 접근합니다. 모델에 제한적인 도구 몇 가지만 제공하는 대신, 보다 완전한 컴퓨팅 환경 안에서 에이전트가 작업하도록 설계되었습니다.
이 프로젝트에는 브라우저 상호작용, Linux 데스크톱 사용, 프로젝트 및 Git 워크스페이스, 메모리, 스킬, MCP, 플러그인, 모델 프리셋, 호스트 머신 리소스 연결을 위한 워크플로가 포함되어 있습니다.
공식 Agent Zero 문서는 이러한 기능을 단순한 모델 채팅이 아니라 실용적인 에이전트 작업을 중심으로 구성합니다.
에이전트가 자신만의 컴퓨터와 같은 워크스페이스를 갖는다는 개념을 실험하고 싶을 때 특히 유용합니다. 파일을 조작하고, 소프트웨어 작업을 수행하며, 브라우저나 데스크톱 인터페이스를 사용하고, 프로젝트 안에서 컨텍스트를 유지할 수 있습니다.
적합한 용도: 작은 고정 도구 목록을 통해서가 아니라 완전한 워크스페이스 안에서 작동하는 에이전트를 실험하려는 고급 사용자.
주의할 점: 에이전트 컨테이너와 호스트 시스템 사이의 경계입니다. 자율 에이전트를 호스트 파일이나 셸 명령에 직접 연결하면 잠재적 영향이 크게 커지므로, 격리와 제한된 마운트가 중요합니다.
6. Browser Use — 웹 브라우저를 에이전트 도구로 전환하기
API는 자동화에 이상적이지만, 웹의 상당 부분은 여전히 브라우저를 필요로 합니다. 바로 이 문제를 해결하도록 설계된 것이 Browser Use입니다.
Browser Use는 AI 에이전트가 웹페이지와 상호작용하고, 인터페이스를 탐색하며, 정보를 추출하고, 브라우저 기반 워크플로를 완료할 수 있도록 지원하는 오픈 소스 프레임워크입니다.
또한 로컬 모델을 사용하는 경로도 문서화되어 있습니다. 공식 Browser Use Ollama 예시에서는 브라우저 에이전트와 함께 로컬에서 제공되는 모델을 사용하는 방법을 보여 줍니다.
따라서 Browser Use가 주력 어시스턴트가 되지 않더라도 중요합니다. API나 MCP 서버만으로 작업을 깔끔하게 완료할 수 없을 때, 브라우저 제어를 더 큰 에이전트 스택의 한 기능으로 사용할 수 있기 때문입니다.
적합한 용도: 웹 리서치, 브라우저 테스트, 양식 상호작용, 인증이 필요한 워크플로, 반복적인 웹 관리, 기존 웹사이트와 상호작용해야 하는 에이전트.
주의할 점: 브라우저 자동화는 본질적으로 여전히 까다롭습니다. 인증, CAPTCHA, UI 변경, 동적 요소, 권한, 악성 웹페이지 콘텐츠는 모두 안정성을 떨어뜨리거나 보안 문제를 일으킬 수 있습니다.
7. Cline — IDE 및 CLI 워크플로 전반에서 로컬 실행이 가능한 코딩 에이전트
Cline은 여전히 가장 잘 알려진 오픈 소스 코딩 에이전트 프로젝트 중 하나이지만, 로컬 AI에서 Cline의 의미는 IDE 경험을 넘어섭니다.
Cline은 Ollama와 LM Studio를 비롯한 런타임을 통해 로컬 추론을 공식 지원합니다. 로컬 모델 가이드에서는 설정 단계를 설명하고 다양한 유형의 로컬 코딩 모델에 필요한 하드웨어에 관한 유용한 지침도 제공합니다.
따라서 Cline은 기존 IDE 지원과 더욱 자율적인 에이전트 워크플로 사이를 연결하는 접근성 높은 다리 역할을 합니다. 개발자는 익숙한 대화형 환경을 유지하면서 추론을 호스팅 제공업체를 통해 수행할지, 자신의 컴퓨터에서 실행되는 모델을 사용할지 선택할 수 있습니다.
적합한 대상: IDE 중심의 코딩 워크플로를 유지하면서 로컬 모델의 유연성을 원하는 개발자.
주의할 점: 로컬 코딩 성능은 컨텍스트 길이와 도구의 안정성에 크게 영향을 받습니다. 모델을 성공적으로 로드하는 것과 여러 파일을 안정적으로 편집하고 디버깅하는 것은 다릅니다.
8. Khoj — 문서와 개인 지식을 위한 비공개 에이전트
Khoj는 로컬 에이전트 생태계의 또 다른 갈래를 보여 줍니다. 코딩이나 브라우저 제어가 아니라 개인 지식에 초점을 둡니다.
Khoj는 스스로를 셀프 호스팅할 수 있는 AI 세컨드 브레인으로 설명합니다. 로컬 또는 온라인 모델과 함께 사용할 수 있고, 개인 문서에서 질문에 답하며, 정보를 검색하고, 특화된 에이전트를 만들고, 반복적인 리서치를 자동화할 수 있습니다.
공식 Khoj 프로젝트 개요에서는 비공개 셀프 호스팅, 로컬 LLM, 문서 검색, 사용자 지정 에이전트, 자동화된 리서치 워크플로 지원을 강조합니다.
로컬 AI가 특히 유용해질 수 있는 지점이 바로 여기입니다. 개인 문서, 프로젝트 아카이브, 노트, PDF, 트랜스크립트, 내부 파일에는 에이전트를 유용하게 만드는 바로 그 종류의 맥락이 담겨 있는 경우가 많지만, 동시에 많은 사용자가 서드파티 서비스로 지속적으로 전송하고 싶어 하지 않는 데이터이기도 합니다.
따라서 스토리지 중심의 비공개 에이전트 아키텍처에서는 역할을 분리할 수 있습니다. 에이전트는 추론과 도구를 담당하고, 로컬 모델 서버는 추론 실행을 담당하며, 로컬 스토리지는 지식 베이스, 임베딩, 원본 문서 및 생성된 결과물을 보관합니다.
이러한 스토리지와 AI의 결합 방향을 보여주는 예로는 ZimaCube 2 AI NAS 워크플로를 참고하세요.
최적의 용도: 자신의 문서를 기반으로 하는 비공개 리서치 비서 또는 개인 지식 에이전트를 원하는 사용자.
주목할 점: 검색 품질은 모델 품질만큼이나 중요합니다. 비공개 에이전트는 올바르게 검색하거나 색인하거나 인용하지 못하는 문서를 안정적으로 추론할 수 없습니다.
9. Letta — 세션이 바뀌어도 기억하는 에이전트 구축
대부분의 에이전트는 여전히 놀랄 만큼 쉽게 잊습니다. 오래된 대화를 검색하거나 벡터 데이터베이스를 조회할 수는 있지만, 영구 에이전트 메모리는 더 근본적인 아키텍처 문제입니다.
이전에 MemGPT와 연관되었던 Letta는 상호작용 전반에서 유지되고 발전할 수 있는 고급 메모리를 갖춘 상태 유지형 에이전트에 직접 초점을 맞춥니다.
2026년에 주목할 중요한 세부 사항 중 하나는 원래 Letta 저장소가 이제 이전 서버 구현을 레거시로 표시한다는 점입니다. 이 프로젝트는 새로운 개발을 최신 Letta Agent 아키텍처와 Letta Code를 중심으로 진행하도록 안내합니다.
공식 Letta README는 에이전트를 컴퓨터에서 로컬로 실행할 수 있으며, 최신 Agent SDK가 로컬 백엔드를 지원한다고 설명합니다.
이러한 전환이 바로 Letta를 주목할 프로젝트 목록에 올려야 하는 이유입니다. 에이전트가 고립된 작업에서 프로젝트 컨텍스트, 사용자 선호도, 학습한 절차, 이전 결정을 기억해야 하는 장기 실행 비서로 발전함에 따라 영구 메모리는 더욱 중요해질 가능성이 높습니다.
최적의 용도: 장기간 실행되는 비서, 적응형 메모리, 지속적인 프로젝트 컨텍스트, 상태를 유지하는 에이전트를 실험하려는 개발자.
주목할 점: 프로젝트의 아키텍처 전환입니다. 이전 Letta 서버를 참조하는 오래된 튜토리얼은 새로운 배포에 권장되는 방식을 반영하지 않을 수 있습니다.
10. CrewAI — 전문 에이전트 팀 조율
CrewAI는 하나의 에이전트가 모든 작업을 수행하는 것이 핵심 아이디어가 아니기 때문에 개인 비서와는 다릅니다.
대신 개발자는 역할, 책임, 도구, 작업이 서로 다른 전문 에이전트 그룹을 정의한 다음, 더 큰 워크플로 안에서 이들을 조율합니다.
이 모델은 자연스럽게 여러 단계로 나뉘는 작업에 유용합니다. 리서치 워크플로에서는 한 에이전트가 근거를 수집하고, 다른 에이전트가 이를 분석하며, 또 다른 에이전트가 보고서 초안을 작성하고, 마지막 에이전트가 결과를 검토한 후 게시할 수 있습니다.
로컬 AI의 매력은 멀티 에이전트 아키텍처가 모든 추론을 클라우드 API에서 수행하도록 본질적으로 요구하지 않는다는 점입니다. 개발자는 워크플로에 필요한 기능을 해당 모델이 제공한다면 로컬 모델이나 프라이빗하게 제공되는 모델을 연결할 수 있습니다.
적합한 용도: 구조화된 멀티 에이전트 파이프라인, 자동화된 리서치, 콘텐츠 워크플로, 데이터 분석, 그리고 에이전트마다 서로 다른 책임을 맡겨야 하는 애플리케이션.
주의할 점: 멀티 에이전트 시스템은 비용, 지연 시간, 컨텍스트, 실패 요인을 배가할 수 있습니다. 에이전트가 많다고 해서 결과가 자동으로 더 좋아지는 것은 아닙니다. 실제로 모델의 판단이 필요하지 않은 작업에서는 결정론적 워크플로 단계가 더 적합한 경우가 많습니다.
어떤 로컬 AI 에이전트 프로젝트를 먼저 사용해 봐야 할까요?
가장 적합한 시작점은 별 수가 가장 많은 리포지토리가 아니라 에이전트가 무엇을 제어하기를 원하는지에 따라 달라집니다.
| 원하는 작업... | 다음으로 시작 | 이유 |
|---|---|---|
| 항상 켜져 있는 개인 비서 구축 | OpenClaw | 영구적인 개인 에이전트 아키텍처를 중심으로 설계 |
| 소프트웨어 엔지니어링 자동화 | OpenHands | 리포지토리, 명령어, 코드 변경, 엔지니어링 작업을 중심으로 구축 |
| 범용 로컬 데스크톱 또는 터미널 에이전트 실행 | goose | 로컬 모델, CLI, 데스크톱, 도구, MCP 확장 기능 결합 |
| 공유 가능한 프라이빗 AI 인프라 구축 | LocalAI | 로컬 추론 API와 에이전트, RAG, 도구, 여러 백엔드를 결합 |
| 에이전트에 완전한 작업 공간 제공 | Agent Zero | 브라우저, 데스크톱, 파일, 프로젝트, 메모리, 도구를 중심으로 설계 |
| 웹사이트 자동화 | Browser Use | 브라우저 상호작용이 프로젝트의 핵심 추상화 |
| 코딩 워크플로에서 로컬 AI 사용 | Cline | 명시적인 로컬 모델 지원을 갖춘 강력한 IDE 워크플로 |
| 개인 지식 검색 및 자동화 | Khoj | 문서, 검색, 에이전트, 셀프 호스팅 결합 |
| 영구 에이전트 메모리 실험 | Letta | 상태와 메모리가 아키텍처의 중심 |
| 전문 에이전트 조율 | CrewAI | 역할 기반 멀티 에이전트 프로세스를 중심으로 설계 |
로컬 AI 에이전트 아키텍처: 에이전트와 모델은 하나의 머신을 공유할 필요가 없습니다
홈 랩에서 가장 유용한 설계 패턴 중 하나는 에이전트 런타임과 모델 런타임을 분리하는 것입니다.
가벼운 머신에서 OpenClaw, Khoj, 워크플로 서비스, 데이터베이스, 에이전트 도구를 24시간 실행하고, 같은 LAN에 연결된 더 강력한 컴퓨터에서 Ollama, vLLM 또는 다른 추론 서버를 실행할 수 있습니다.
에이전트 서버
|
|-- OpenClaw / goose / OpenHands / Khoj
|-- MCP 도구
|-- 자동화
|-- 메모리 / 데이터베이스
|
+------ 로컬 네트워크 ------+
|
모델 서버
|
Ollama / vLLM
|
GPU / 대용량 RAM
이 방식은 모든 작업을 처리하기 위해 하나의 초대형 머신을 구축하는 것보다 효율적일 수 있습니다. 또한 스토리지, 추론, 에이전트 오케스트레이션, 백업을 서로 독립적으로 확장할 수 있습니다.
이러한 구성에서 ZimaBoard 2는 고급 GPU 워크스테이션을 대체하는 장치라기보다 항상 켜져 있는 서비스 및 오케스트레이션 노드로 이해하는 편이 적절합니다. 실제 사례로는 ZimaBoard 2 및 Ollama 로컬 AI 허브가 있으며, 소형 클라이언트 장치가 중앙 모델 서비스에 액세스합니다.
더 많은 스토리지와 확장성이 필요하다면 아키텍처는 NAS 중심의 AI 서버로 발전할 수 있습니다. ZimaCube 2 로컬 AI 홈랩 가이드에서는 스토리지, Ollama, PCIe 확장, 향후 GPU 업그레이드 간의 관계를 다룹니다.
GPU 지원 추론이 필요해진다면, ZimaCube 2 Intel Arc 로컬 AI 빌드에서 전용 가속기 하드웨어를 추가하는 한 가지 방법을 확인할 수 있습니다.
로컬 AI 에이전트에 실제로 필요한 하드웨어는 어느 정도일까?
에이전트 프레임워크 자체는 일반적으로 하드웨어 예산에서 가장 큰 부분을 차지하지 않습니다. 메모리와 컴퓨팅 요구 사항은 모델, 브라우저 세션, 컨텍스트 길이, 임베딩, 벡터 데이터베이스, 동시 작업량에 의해 결정될 가능성이 더 높습니다.
Cline의 공식 로컬 모델 가이드는 유용한 대략적인 예를 제시합니다. 더 작거나 양자화된 로컬 모델은 16~32GB급 시스템에 탑재할 수 있고, 중간 크기의 코딩 모델은 더 많은 메모리를 요구하며, 대형 모델이나 더 큰 컨텍스트 창은 시스템 메모리 64GB를 넘어설 수 있습니다.
OpenHands는 또 다른 유용한 현실 점검 사례를 제공합니다. 해당 문서에서는 어떤 소형 채팅 모델이든 동일한 경험을 제공한다고 암시하기보다, 에이전트형 코딩에 적합한 성능의 모델을 권장합니다.
일반적인 배포 패턴은 다음 세 가지입니다.
에이전트는 로컬에서, 모델은 클라우드에서
에이전트, 파일, 메모리, 도구는 서버에서 실행되고, 복잡한 추론 요청은 호스팅 모델로 전송됩니다. 가장 간단한 아키텍처이지만, 모델 제공업체로 전송된 프롬프트는 로컬 머신을 벗어납니다.
에이전트는 로컬에서, 모델은 LAN의 다른 곳에서
에이전트는 항상 켜져 있는 홈 서버에서 실행되고, 워크스테이션이나 GPU 머신은 Ollama, vLLM, LM Studio 또는 호환 가능한 다른 엔드포인트를 제공합니다. 이는 개인 정보 보호를 중시하는 아키텍처 중 가장 실용적인 방식인 경우가 많습니다.
하나의 로컬 AI 서버에 모두 담기
같은 컴퓨터에서 모델, 에이전트 프레임워크, 브라우저 자동화, 컨테이너, 데이터베이스, 임베딩, 저장소를 실행합니다. 편리하지만 RAM, VRAM, 발열 관리, 저장 공간, 전력에 훨씬 더 큰 부담을 줍니다.
로컬이라고 해서 자동으로 비공개가 되는 것은 아닙니다
로컬 AI 에이전트도 네트워크 외부로 데이터를 전송할 수 있습니다.
예를 들어 에이전트 런타임은 로컬에서 실행되더라도 다음과 같은 경우가 있을 수 있습니다.
- LLM은 클라우드 API입니다.
- 웹 검색은 외부 서비스를 사용합니다.
- 브라우저는 공개 웹사이트를 엽니다.
- MCP 서버는 SaaS 애플리케이션에 연결됩니다.
- 임베딩 API는 비공개 문서를 원격으로 처리합니다.
- 메시징 통합 기능은 서드파티 플랫폼을 통해 콘텐츠를 전송합니다.
따라서 "로컬 에이전트"와 "완전 오프라인 에이전트"를 동의어로 취급해서는 안 됩니다.
진정으로 비공개인 워크플로를 구축하려면 모델 제공업체, 임베딩, 도구, 브라우저 트래픽, 외부 API, 텔레메트리, 저장소, 로그, 백업의 모든 계층을 검토해야 합니다.
로컬 AI 에이전트에는 챗봇보다 더 강력한 보안 모델이 필요합니다
챗봇은 잘못된 답변을 생성할 수 있습니다. 에이전트는 잘못된 답변을 행동으로 옮길 수 있습니다.
에이전트가 셸 명령을 실행하거나, 리포지토리를 편집하거나, 브라우저를 제어하거나, 파일을 이동하거나, 비공개 문서에 액세스하거나, 홈 서버 API를 호출할 수 있다면 해당 권한은 AI 안전 모델의 일부가 됩니다.
따라서 실용적인 셀프 호스팅 에이전트 배포에서는 다음을 고려해야 합니다.
- 컨테이너 또는 VM 격리: 가능한 경우 실험적인 에이전트를 호스트 시스템에서 분리합니다.
- 제한된 파일 시스템 마운트: 작업에 필요한 폴더만 노출합니다.
- 도구 허용 목록: 모든 에이전트에 사용 가능한 모든 도구를 제공하지 않습니다.
- 분리된 서비스 계정: 관리자 자격 증명을 재사용하지 않습니다.
- 승인 절차: 파괴적이거나 영향이 큰 작업을 수행하기 전에 확인을 요구합니다.
- 버전 관리: 자율적인 편집을 허용하기 전에 코드와 구성을 복구할 수 있는 상태로 유지합니다.
- 백업: 에이전트의 실수를 되돌릴 수 있어야 합니다.
- 로그: 어떤 도구가 호출되었고 무엇이 변경되었는지 기록합니다.
이는 브라우저 에이전트에 특히 중요합니다. 웹페이지, 이메일, 문서, 이슈 댓글 또는 다운로드한 파일에는 에이전트를 조작하도록 설계된 지침이 포함될 수 있습니다. 자율 시스템은 외부 콘텐츠를 권위 있는 지침이 아니라 신뢰할 수 없는 입력으로 취급해야 합니다.
커뮤니티 스킬과 플러그인에도 같은 규칙이 적용됩니다. 서드파티 확장 기능을 설치하기 전에 어떤 작업을 실행하는지, 어떤 파일을 읽는지, 어떤 자격 증명을 요청하는지, 외부 서비스와 통신하는지를 확인하세요.
일부 유명 에이전트 프로젝트가 빠진 이유
감시 목록에 작년 가장 잘 알려진 이름들을 자동으로 포함할 필요는 없습니다.
여기서의 목표는 2026년 오픈 소스 로컬 에이전트의 방향과 특히 관련성이 높은 프로젝트를 식별하는 것입니다. 따라서 현재 프로젝트의 방향성은 과거의 인기만큼이나 중요합니다.
이는 또한 코딩 에이전트 열 개로 목록을 채우는 방식을 의도적으로 피했다는 의미입니다. 현재 코딩은 가장 강력한 에이전트 분야 중 하나이지만, 로컬 AI 스택에는 브라우저 제어, 지속적인 메모리, 개인 지식, 모델 인프라, 범용 자동화, 다중 에이전트 오케스트레이션도 필요합니다.
이 목록의 다양성은 의도된 것입니다.
- OpenClaw는 개인 에이전트 계층을 대표합니다.
- OpenHands와 Cline은 소프트웨어 엔지니어링을 대표합니다.
- goose는 범용 로컬 에이전트 실행을 대표합니다.
- LocalAI는 공유 AI 인프라를 대표합니다.
- Agent Zero는 전체 작업 공간에서의 자율성을 대표합니다.
- Browser Use는 브라우저 제어를 대표합니다.
- Khoj는 비공개 지식을 대표합니다.
- Letta는 지속적인 메모리를 대표합니다.
- CrewAI는 다중 에이전트 오케스트레이션을 대표합니다.
오픈 소스 로컬 AI 에이전트에서 다음으로 주목할 점
가장 큰 흐름은 단순히 Ollama에 연결할 수 있는 프로젝트가 늘고 있다는 것이 아닙니다.
더 중요한 변화는 로컬 에이전트 스택이 모듈화되고 있다는 점입니다.
모델은 한 서버에 둘 수 있습니다. 에이전트 런타임은 다른 서버에서 실행할 수 있습니다. 문서와 메모리는 로컬 스토리지에 계속 보관할 수 있습니다. MCP 서버는 도구를 제공할 수 있습니다. 브라우저 자동화는 별도의 기능이 될 수 있습니다. 스킬은 반복 가능한 절차를 패키징할 수 있습니다. 특화 에이전트는 더 큰 워크플로 아래에서 작동할 수 있습니다.
이는 미래의 로컬 AI 서버가 하나의 거대한 챗봇이라기보다 서로 협력하는 서비스 모음에 가까운 형태가 될 수 있음을 의미합니다.
로컬 모델
|
에이전트 런타임
|
+----+-----------+-----------+-----------+
| | | |
메모리 브라우저 MCP 스킬
| | | |
문서 웹사이트 서비스 워크플로
| | | |
+---------------- 로컬 스토리지 ---------+
셀프 호스팅 사용자에게 이는 중요한 변화입니다. 이제 하나의 프로젝트가 모든 일을 처리하도록 할 필요가 없습니다. 대신 각 계층에서 가장 강력한 구성 요소를 선택하고, 어떤 부분을 로컬에 유지할지 정확히 결정할 수 있습니다.
최종 요약
2026년에는 단 하나의 최고의 오픈 소스 로컬 AI 에이전트가 존재하지 않습니다. 이러한 프로젝트들이 점점 서로 다른 문제 영역을 해결하고 있기 때문입니다.
OpenClaw를 선택하세요 항상 켜져 있는 개인 에이전트를 실험하고 싶다면.
OpenHands를 선택하세요 자율 소프트웨어 개발이 주된 목표라면.
goose를 선택하세요 로컬 모델과 MCP 도구를 사용할 수 있는 유연한 데스크톱 및 터미널 에이전트를 원한다면.
LocalAI를 선택하세요 여러 비공개 AI 애플리케이션을 뒷받침하는 인프라를 구축하고 있다면.
Agent Zero를 선택하세요 더 넓은 컴퓨터 작업 공간 안에서 에이전트를 작동시키고 싶다면.
Browser Use를 선택하세요 브라우저 자체가 자동화 대상이라면.
Cline을 선택하세요 로컬 모델의 유연성을 갖춘 IDE 중심 코딩이 목적이라면.
Khoj를 선택하세요 비공개 문서와 개인 지식을 위한 선택입니다.
Letta를 선택하세요 지속적인 에이전트 메모리가 가장 중요하게 생각하는 실험이라면.
CrewAI를 선택하세요 워크플로가 전문화된 에이전트 팀으로 구성되는 편이 더 적합할 때.
2026년의 더 큰 기회는 하나의 승자를 고르는 데 있지 않습니다. 중요한 모델, 도구, 권한, 메모리, 스토리지 및 인프라를 직접 통제할 수 있는 비공개 에이전트 스택을 구축하는 데 있습니다.
FAQ
오픈 소스 AI 에이전트를 완전히 오프라인으로 실행할 수 있나요?
일부는 가능합니다. 모델, 에이전트 런타임, 도구, 임베딩 및 필요한 데이터를 모두 로컬에서 사용할 수 있다면 가능합니다. 하지만 웹 검색, 클라우드 API, SaaS 통합, 메시징 플랫폼 및 공개 웹사이트와 같은 기능에는 여전히 네트워크 액세스가 필요합니다.
Ollama 자체가 AI 에이전트인가요?
아니요. Ollama는 주로 모델 런타임입니다. OpenHands, goose, Cline, Browser Use와 같은 에이전트 프레임워크나 다른 에이전트 시스템은 모델에 계획 수립, 도구 사용, 메모리, 워크플로 및 작업 기능을 추가합니다.
코딩에 가장 적합한 오픈 소스 로컬 AI 에이전트는 무엇인가요?
완전한 자율 소프트웨어 엔지니어링 환경을 원한다면 OpenHands가 가장 강력한 선택지 중 하나입니다. IDE 중심의 워크플로를 선호하는 개발자에게는 Cline이 매력적이며, 코딩이 더 광범위한 로컬 자동화 설정의 일부일 뿐이라면 goose가 유용합니다.
홈 서버에 가장 적합한 로컬 AI 에이전트는 무엇인가요?
서버의 역할에 따라 다릅니다. OpenClaw는 지속적으로 실행되는 개인 비서에 적합하고, Khoj는 비공개 문서 및 지식 워크플로에 잘 맞으며, LocalAI는 공유 로컬 추론 및 에이전트 인프라 계층을 구축하려는 사용자에게 더 적합합니다.
로컬 AI 에이전트를 실행하려면 GPU가 필요한가요?
반드시 그런 것은 아닙니다. 많은 에이전트 프레임워크는 전용 GPU 없이도 실행할 수 있습니다. 하드웨어 요구 사항은 주로 선택한 로컬 모델에서 비롯됩니다. 더 작은 양자화 모델은 CPU나 공유 메모리에서 실행할 수 있지만, 더 큰 에이전트 코딩 및 추론 모델은 더 많은 RAM, VRAM 및 가속기 하드웨어가 있을 때 성능이 크게 향상됩니다.
에이전트는 한 컴퓨터에서 실행하고 모델은 다른 컴퓨터에서 실행할 수 있나요?
네. 이는 가장 유용한 홈 랩 아키텍처 중 하나입니다. 에이전트를 항상 켜져 있는 서버에서 실행하고, 로컬 네트워크를 통해 더 강력한 하드웨어에서 실행 중인 Ollama, vLLM, LM Studio 또는 다른 모델 서버에 연결할 수 있습니다.
로컬 AI 에이전트가 클라우드 에이전트보다 안전한가요?
로컬 배포는 개인 데이터에 대한 통제력을 높일 수 있지만, 그렇다고 에이전트가 자동으로 안전해지는 것은 아닙니다. 셸, 브라우저, 파일 시스템, 네트워크 또는 애플리케이션에 광범위한 권한을 가진 에이전트는 여전히 파괴적인 실수를 할 수 있습니다. 샌드박싱, 제한된 권한, 승인 단계, 로그 및 백업은 여전히 필수입니다.
오픈 소스 AI 에이전트를 설치하기 전에 무엇을 확인해야 하나요?
프로젝트의 현재 유지 관리 상태, 라이선스, 최근 릴리스, 문서, 모델 요구 사항, 도구 권한, 인증 옵션, Docker 또는 샌드박스 지원, 외부 네트워크 의존성, 그리고 에이전트가 실수했을 때 파일이나 구성을 얼마나 쉽게 복구할 수 있는지 확인하세요.
기술 및 AI 허브
더 읽어보기

Why Does Home Assistant Reprocess Existing Data After an Upgrade?
Home Assistant may revisit existing data after an upgrade to make stored state, indexes, caches, and integrations compatible with new code.

What Dependencies Most Often Set the Real Home Assistant Performance Ceiling?
Home Assistant performance is capped by the slowest required dependency in the event-to-result path, not necessarily by the host CPU.

Home Assistant Networking: How Discovery, DNS, and Routing Produce Reachability
Home Assistant reachability requires discovery, correct name resolution, a valid route, permitted traffic, and a listening endpoint.

