OpenSpace

왜 중요한가

• OpenClaw를 명시적으로 지원하고, host skill 2개와 MCP 연동으로 붙이는 흐름을 제시한다.
• 모델 자체보다 반복 업무 패턴을 skill 자산으로 굳히는 운영 계층을 노린다는 점이 핵심이다.
• 최근 OpenClaw 문서 보강, streamable-http transport, communication gateway 추가 등으로 단순 데모보다 운영형 방향으로 움직이고 있다.

핵심 관찰

• 로컬에서 repo 일부를 sparse clone으로 받아 실제 파일을 확인했다.
• pyproject.toml 기준 openspace, openspace-mcp, openspace-dashboard, openspace-gateway 같은 entry point가 정의되어 있었다.
• 공개 showcase DB showcase/.openspace/openspace.db를 직접 열어 SQLite 스키마와 기록 수를 확인했다.
• 간단한 질의 결과 기준 skill_records 77, execution_analyses 37, tool_execution_history 437, skill_judgments 52가 들어 있었고, 최근 skill/analysis/tool 기록도 실제 row로 남아 있었다.
• 즉 “진화”, “기록”, “품질 추적”을 말만 하는 것이 아니라 최소한 공개 artifact 차원에서 흔적을 남기고 있다는 점은 긍정적이다.
• 다만 오늘은 패키지 설치/실행까지는 하지 않았다. Python 3.12+가 필요하고, 오늘 판단에는 OpenClaw 연동 구조와 artifact 검증이 더 핵심이었다.

해석

OpenSpace는 기존 agent 위에 얹어 skill 검색, task 위임, skill 수정, skill 공유를 돌리며 점진적으로 agent workflow를 축적시키는 self-evolving layer다.

• 연구팀: 반복 조사, 데이터 정리, 보고서 생성 같은 루틴을 explicit skill 자산으로 축적하는 실험 플랫폼

• 운영팀: 개인 기억이 아니라 재사용 가능한 workflow skill을 남기는 운영 방식 참고

• 도구 제작자: skill-discovery, delegate-task 같은 host skill 패턴과 OpenClaw MCP 연동 설계 비교 대상

• 소규모 팀: 반복 workflow를 에이전트가 재활용 가능한 skill로 만들고 싶을 때

• 에이전트 운영팀: task delegation, fix, upload 루프를 별도 계층으로 운영하고 싶을 때

• 개인 개발자: Claude Code, Codex, OpenClaw 같은 agent 위에 한 층 더 얹는 진화/재사용 레이어가 필요할 때

누구에게 도움이 되나

• 연구팀: 반복 조사, 데이터 정리, 보고서 생성 루틴을 explicit skill 자산으로 축적하고 싶은 경우
• 에이전트 운영팀: task delegation, fix, upload 루프를 별도 계층으로 운영하고 싶은 경우
• 도구 제작자: self-evolving skill layer와 host integration 패턴을 비교하고 싶은 경우

어디에 바로 써볼 수 있나

• OpenClaw 같은 host agent 위에 재사용 가능한 skill layer를 얹는 구조 검토
• skill-discovery, delegate-task 같은 host skill 패턴 설계 비교
• 반복 업무를 개인 기억이 아니라 workflow asset으로 남기는 운영 방식 점검

주요 출처

• HKUDS/OpenSpace GitHub repo
• OpenSpace host_skills README
• OpenSpace skills README

공식 docs / repo

• OpenSpace repository
• Host integration docs
• Skill docs

다음에 볼 포인트

• 세션 메모리와 장기 메모리의 범위 분리가 더 명시적인 제품 기본값으로 굳어지는지 볼 것.
• skills, orchestration, writable memory를 어떤 정책 경계로 나누는지 비교할 것.