OpenSpace는 단순한 에이전트 플러그인이 아니다. 이 저장소가 흥미로운 이유는, 스킬을 “설치하는 것”이 아니라 사용하면서 진화시키는 것을 목표로 하기 때문이다. 다시 말해, OpenSpace는 에이전트의 기능을 늘리는 도구가 아니라 스킬 운영 레이어에 가깝다.
왜 지금 이 프로젝트가 중요한가
AI 에이전트를 여러 개 굴려 보면 금방 같은 문제를 만난다.
- 한 에이전트가 찾은 좋은 패턴이 다른 에이전트에 복제되지 않는다
- 잘 작동하던 스킬이 도구 API 변경 이후 조용히 망가진다
- 실패한 작업을 다시 시도할 때마다 토큰이 새로 새어 나간다
- 스킬이 많아질수록 “무엇이 살아 있고 무엇이 죽었는지” 관리가 어려워진다
OpenSpace는 이 병목을 정면으로 건드린다. README가 말하는 핵심 문장은 단순하다.
every task makes every agent smarter and more cost-efficient
이 한 줄은 꽤 큰 의미를 가진다. 스킬을 정적 텍스트가 아니라 학습 가능한 자산으로 보겠다는 선언이기 때문이다.
OpenSpace가 제안하는 3가지 축
1. Self-Evolution
OpenSpace는 AUTO-FIX, AUTO-IMPROVE, AUTO-LEARN을 전면에 둔다.
즉, 스킬이 실패하면 고치고, 성공하면 더 낫게 만들고, 실제 사용에서 나온 패턴을 다시 학습하는 흐름이다. 여기서 중요한 건 모델 자체가 아니라 스킬의 복리다. 한 번 잘 만든 패턴이 이후 작업 전체를 더 싸고 안정적으로 만든다.
2. Collective Agent Intelligence
OpenSpace는 한 에이전트의 개선을 그 에이전트 하나로 끝내지 않는다. 공유 가능한 스킬로 만들고, 다른 에이전트가 다시 가져다 쓴다.
이 구조가 성립하면 조직의 에이전트 운영은 완전히 달라진다.
- 개인 최적화가 곧 팀 최적화가 된다
- 실패 로그가 개인 기록이 아니라 공용 지식이 된다
- 같은 작업을 서로 다른 에이전트가 반복 학습할 필요가 줄어든다
이 방향은 Autoskills, Claude Code skill library, Hermes self-evolution 같은 계열의 흐름과 맞닿아 있다. 다만 OpenSpace는 그중에서도 **“공유와 진화”**를 더 강하게 밀어붙인다.
3. Token Efficiency
README에는 꽤 공격적인 수치가 나온다.
46% fewer tokens4.2x better performancev0.1.0기준의 품질 모니터링
이 수치는 그대로 일반화하면 안 된다. 다만 방향성은 분명하다. 에이전트가 매번 처음부터 reasoning을 다시 시작하면 토큰은 계속 새고, 성공 패턴을 재사용하면 비용은 줄어든다. OpenSpace는 이 차이를 운영 가능한 구조로 만들려는 시도다.
아키텍처를 읽는 법
MCP만이 아니라 실행면까지 본다
OpenSpace는 stdio, SSE, streamable HTTP를 모두 지원한다. 이건 단순한 transport 선택지가 아니다. 로컬 호스트, 원격 호스트, 장기 실행 프로세스 각각을 염두에 둔 설계에 가깝다.
즉, OpenSpace는 “스킬 저장소”가 아니라 에이전트 실행면의 일부로 보아야 한다.
커뮤니케이션 게이트웨이
README에는 WhatsApp과 Feishu 어댑터가 나온다. 이건 장식이 아니다. 에이전트가 외부 채널과 메시지를 주고받을 수 있으면, 스킬 운영은 채팅, 승인, 세션 관리, 첨부파일 처리까지 포함하는 운영 문제가 된다.
정리하면, OpenSpace는 에이전트를 CLI 안에 가두지 않는다. 오히려 대화 가능한 운영체계 쪽으로 밀어 올린다.
host skill directory와 CAPTURED skills
최근 변경 로그를 보면 CAPTURED skills가 host agent 자신의 skill directory에 남도록 바뀌었다. 이건 작아 보이지만 중요하다.
스킬이 원격 레지스트리에만 있으면, 실행 시점에 검색/로딩/신뢰 문제가 생긴다. 반대로 로컬 작업공간으로 내려오면, 다음 작업에서 재사용하기 쉬워진다. OpenSpace는 바로 이 실전 문제를 건드린다.
이 저장소를 어떻게 읽어야 하나
OpenSpace의 README는 메시지가 명확하다.
- 스킬은 한 번 잘 만드는 것으로 끝나지 않는다.
- 여러 에이전트가 같은 개선을 공유해야 한다.
- 비용 절감은 부가 효과가 아니라 핵심 목표다.
다만 README 수치는 전부 프로젝트 자체의 주장이다. 따라서 아래처럼 읽는 게 안전하다.
- 아이디어는 강하다
- 구현 방향도 일관된다
- 그러나 벤치마크 결과는 내 워크로드에서 재검증해야 한다
특히 46% fewer tokens와 4.2x better performance는 매력적이지만, 실제 팀 환경에서는 스킬 품질, retrieval, task mix, model choice에 따라 결과가 크게 달라질 수 있다.
어떤 사람에게 특히 맞나
OpenSpace는 이런 사람에게 잘 맞는다.
- Claude Code, OpenClaw, Hermes, Codex처럼 스킬이 많은 에이전트를 운영하는 사람
- 같은 작업을 여러 에이전트가 반복하는 팀
- “prompt engineering”보다 “skill engineering”이 더 중요해진 환경
- 에이전트가 남긴 성공 패턴을 장기적으로 축적하고 싶은 사람
반대로, 단일 에이전트를 가볍게 쓰는 경우에는 다소 과할 수 있다. OpenSpace는 개인용 편의 도구라기보다, 에이전트 운영을 복리로 키우는 인프라에 가깝다.
마치며
OpenSpace가 던지는 질문은 단순하다.
에이전트가 일을 잘하게 만드는 가장 좋은 방법은, 매번 더 큰 모델을 쓰는 것일까? 아니면 잘 작동한 스킬을 조직의 자산으로 만드는 것일까?
OpenSpace는 후자에 꽤 설득력 있는 답을 준다. 모델은 계속 바뀌어도, 스킬 운영 레이어는 남는다. 그리고 그 레이어가 잘 설계되면, 에이전트는 점점 더 싸고, 더 안정적이고, 더 공유 가능한 시스템이 된다.
🔗 관련 정보
- GitHub: https://github.com/HKUDS/OpenSpace
- Community: https://open-space.cloud/
- Context Vault: OpenSpace 노트, AI Agents MOC, Dev Tools MOC
- 연관 노트: Autoskills, Claude Code skill library, Hermes self-evolution