holaOS, 하루 769스타 모은 올인원 AI 에이전트 워크스페이스가 라이선스로 막아둔 것

holaOS, 하루 769스타 모은 올인원 AI 에이전트 워크스페이스가 라이선스로 막아둔 것

holaOS는 Claude Code와 Codex를 같은 워크스페이스에 얹어 메모리를 공유시키는 오픈소스 도구입니다. 다만 라이선스와 연동 구조는 1차 자료로 따로 확인해야 합니다.

holaOS는 Claude Code와 Codex를 한 앱 안에서 나란히 돌리고, 둘이 같은 메모리·도구·연동을 공유하게 만든 오픈소스 프로젝트예요. GitHub에 올라온 지 5개월 만에 스타 7,626개를 모았고, 그중 769개는 2026년 8월 15일 하루 만에 들어왔습니다(오늘 기준 1일 전 관측). 스타 수만 보고 넘어가면 "오픈소스라는데 라이선스는 괜찮은가"라는 질문에 답하지 못합니다. 이 글은 GitHub 저장소 코드와 공식 문서를 직접 뒤져 구조·라이선스·연동 실체·메모리 격리 범위를 순서대로 정리했어요.

holaOS는 정확히 무엇을 하는 도구인가요

holaOS란: Claude Code, Codex, 자체 holaOS 에이전트를 한 데스크톱 앱에서 동시에 돌리면서 메모리·도구·연동을 공유시키는 오픈소스 워크스페이스입니다. 에이전트를 바꿔도 맥락이 남는다는 점이 핵심입니다.

holaOS desktop workspace

이미지 출처: github.com

저장소를 열어보면 구조가 그대로 드러나요. 모노레포 안에 에이전트마다 "하네스(harness)"라는 어댑터가 따로 있고, runtime/harnesses/src/claude-code.ts와 codex.ts가 실제로 존재합니다. 즉 Claude Code와 Codex를 각각 다른 API로 부르는 게 아니라, 같은 런타임 위에서 하네스만 갈아끼우는 방식이죠.

에이전트뿐 아니라 모델 선택지도 넓습니다. README 기준으로 대량 처리용 Kimi K3·GLM 5.2, 고난도 작업용 GPT 5.6·Claude Opus 5·Fable 5를 내장하고 있고, OpenAI·Anthropic 키를 직접 넣는 BYOK도 지원해요. 자기 키로 돌리면 holaOS 요금제가 아니라 본인 계정으로 과금된다고 명시돼 있습니다.

Claude Code나 Codex를 단독으로 쓰고 있었다면, 에이전트를 옮길 때마다 설정과 맥락을 새로 만드는 게 번거로웠을 겁니다. holaOS가 노리는 지점이 정확히 거기예요.

'오픈소스'라는 말과 실제 라이선스 조항은 다릅니다

GitHub API는 holaOS의 라이선스를 표준 분류값이 아닌 NOASSERTION으로 돌려줍니다. 순정 Apache 2.0이 아니라는 신호죠. LICENSE 원문을 직접 열어보면 이유가 나와요. Modified Apache 2.0이고, 추가 조건이 두 가지 붙어 있습니다.

세 가지 중 앞의 두 가지가 실무에 가장 영향이 커요. 사내 도구로만 쓸 거라면 신경 쓸 게 없습니다. 하지만 자동화 컨설팅이나 SaaS 사업자가 이걸 가져다 고객에게 서비스로 팔거나 자사 제품에 통째로 얹으려 한다면, 도입 전에 이 조항부터 확인해야 해요. "오픈소스니까 뭐든 자유롭게 써도 된다"는 통념이 여기서는 통하지 않거든요.

연동 100개 이상이라는 숫자, 출처를 뜯어보면

GitHub 저장소 설명(description)에는 "100+ integrations"라고 적혀 있어요. README 본문은 조금 다르게 "Gmail, Notion, Slack, GitHub, Linear and 50+ more"라고 씁니다. 숫자가 자료마다 달라진다는 것 자체가 이미 신호죠.

저장소 코드 전체를 검색해보면 "100+ integrations"라는 문자열은 어디에도 나오지 않습니다. 검색 결과는 0건이에요. 다시 말해 100개 이상이라는 숫자는 저장소 설명에만 존재하고 코드나 문서 같은 1차 자료로는 확인되지 않습니다. 물론 설명이 README보다 먼저 갱신됐을 수도 있고, Composio 카탈로그 전체를 센 숫자일 수도 있어요. 다만 지금 공개된 자료만으로는 그 근거를 확인할 수 없다는 뜻입니다.

그렇다면 연동은 실제로 어떻게 이뤄질까요. 코드 검색에서 Composio 관련 히트가 185건 나오고, composio-api-client.ts·composio-remote-source.ts 같은 전용 모듈이 여러 개 있습니다. holaOS는 "로컬 우선(local-first)"을 표방하지만, OAuth 기반 연동 레이어는 Composio라는 서드파티 플랫폼을 경유해요. 메모리는 로컬 마크다운 파일이 맞지만, 자체 호스팅한다고 연동까지 독립되는 건 아닙니다.

공유 메모리는 어디까지 공유되고 어디서 끊기나요

holaOS를 쓰는 이유의 절반은 "메모리 공유"입니다. 그런데 정작 README에는 이 스코프가 자세히 안 나와요. 공식 문서 durable-memory.mdx를 열어야 나옵니다.

정리하면 이렇습니다. 워크스페이스를 고객사별로 나누면 대화 맥락(interaction)은 섞이지 않아요. 다만 연동에서 나온 증거와 사용자 선호(preference)·정체성(identity)은 전역으로 공유됩니다. 완전한 격리는 아니라는 얘기죠.

메모리 설계는 마크다운 우선입니다. 마크다운 파일이 진실의 원천이고, 임베딩·벡터 인덱스는 거기서 파생된 결과물이에요. 둘이 어긋나면 런타임이 마크다운 기준으로 인덱스를 다시 만듭니다. 원시 대화 기록 자체는 영속 메모리로 취급하지 않고요.

바로 이 지점을 콕 집어 물은 공개 이슈가 있습니다. 2026-08-15(오늘 기준 1일 전) 등록된 이슈 #471은 "개인 프로젝트와 고객 저장소 사이에 맥락이 새는가"를 물었고, 작성 시점 기준 아직 미해결 상태예요. 고객 데이터를 다루는 워크스페이스라면, 도입 전에 이 경계를 직접 시험해보는 걸 권합니다.

지금 프로덕션에 바로 투입해도 될까요

지표를 종합해보면 판단이 조금 더 분명해져요.

지금 프로덕션에 바로 투입해도 될까요

자료: github.com · QJC 재구성

개발 속도 자체는 빠릅니다. 최근 3주 커밋이 꾸준히 두 자릿수고, 최근 푸시도 2026-08-15로 활발해요. 문제는 다른 쪽에 있습니다. 릴리스·태그 API가 시맨틱 버전 없이 latest 하나만 돌려주기 때문에, 특정 버전으로 고정하거나 재현하기가 어렵습니다. 또 스타 대비 워처(174)·열린 이슈(7)가 상대적으로 적어요. "관심은 폭발했는데 실사용 피드백은 이제 막 쌓이는 단계"로 읽히는 대목이죠.

외부 검증도 아직 얇습니다. 2026-08-16 Hacker News를 검색해보면 holaOS 관련 게시물이 0건이에요(유사 명칭 프로젝트 오탐만 나옵니다). Reddit과 X 반응은 이번 조사에서 API 차단으로 확인하지 못했습니다.

이 조합을 보면, 지금은 프로덕션에 상시 투입하기보다 별도 워크스페이스에서 먼저 검증해보는 편이 안전해 보여요.

보안·권한 표면은 얼마나 넓은가요

SECURITY.md는 자격증명·토큰 노출, 원격 코드 실행, 샌드박스 탈출·권한 상승, 인증 우회를 보안 이슈로 규정하고 비공개 신고 채널을 두고 있습니다. 다만 샌드박스 경계나 권한 모델의 구체적인 명세는 이 문서에 자세히 나와 있지 않아요. 에이전트가 브라우저·파일·연동을 함께 다루는 구조라 권한 표면이 넓은 편인데, 그 경계를 설명하는 문서는 상대적으로 얇습니다.

설치 방식도 눈여겨볼 만해요. 원라인 설치는 curl | bash 패턴이라 스크립트를 먼저 훑어보고 실행하는 편이 안전합니다. 지원 플랫폼은 macOS(Apple Silicon·Intel), Windows, Linux고, 수동 설치에는 Node.js 24.14.1이 명시돼 있어요.

안티디텍트(지문 위장) 브라우저는 오픈소스 빌드에 없습니다. apps/desktop/src/lib/featureFlags.ts의 fingerprintBrowser 플래그가 기본값 OFF로 잠겨 있고, 엔터프라이즈 전용이라 일반 빌드에서는 "Contact Sales" 화면만 떠요.

마무리

holaOS는 Claude Code와 Codex를 한 워크스페이스에 얹어 메모리를 공유시키는, 구조 자체는 명확한 오픈소스 프로젝트예요. 다만 "오픈소스"라는 간판 뒤에는 SaaS·임베드 판매 시 별도 상용 라이선스가 필요하다는 조건, 마케팅 문구와 실제 코드가 어긋나는 "100+ 연동" 숫자, 아직 열려 있는 메모리 격리 질문(#471)이 함께 있습니다. 개발 속도는 빠르지만 버전 고정이 안 되고 외부 검증도 이제 막 시작된 단계고요.

우리 팀 상황에 맞는지부터 따져보셔도 충분합니다. 판단에 필요한 기준은 위에 정리해 뒀어요.

자주 묻는 질문 (FAQ)

Q: 제 개인 프로젝트와 고객 프로젝트를 같은 holaOS에서 써도 정보가 섞이지 않나요?

대화 맥락(interaction 메모리)은 워크스페이스별로 로컬 저장되기 때문에 완전히 섞이진 않아요. 다만 연동에서 나온 증거와 사용자 선호·정체성 정보는 전역으로 공유되기 때문에 100% 격리는 아닙니다. 이 경계를 정확히 묻는 이슈 #471이 2026-08-15에 등록됐고 아직 미해결이라, 고객 데이터를 다룬다면 직접 시험해보는 걸 권해요.

Q: 저희 회사에서 holaOS를 고객에게 서비스로 제공하거나 제품에 넣어 팔아도 되나요?

한 조직 내부에서만 쓰는 거라면 자유롭습니다. 하지만 holaOS를 호스팅 서비스로 제3자에게 제공하거나 상용 제품에 임베드해 판매하려면 LICENSE 원문에 따라 별도 상용 라이선스가 필요해요. 자동화 컨설팅·SaaS 사업 목적이라면 도입 전에 이 조항부터 확인하시는 걸 추천드립니다.

Q: 지금 바로 프로덕션에 투입해도 안전할까요?

버전 태그가 latest 하나뿐이라 특정 버전으로 고정·재현하기가 어렵고, Hacker News 논의는 아직 0건이라 외부 검증도 얇은 편이에요. 개발 자체는 최근 3주 커밋 39건·23건·14건으로 활발하지만, 지금은 상시 프로덕션보다 별도 워크스페이스에서 먼저 평가해보는 단계가 맞아 보입니다.

참고 자료

• holaboss-ai/holaOS GitHub 저장소
• holaOS LICENSE 원문 (Modified Apache 2.0)
• GitHub 이슈 #471 — 메모리 스코프 질의
• GitHub PR #452 — 안티디텍트 브라우저 오픈코어
• holaOS 공식 사이트