# Google, 실험적 에이전트 오케스트레이션 테스트베드 Scion 오픈소스 공개

> Clean Markdown view of GeekNews topic #28307. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28307](https://news.hada.io/topic?id=28307)
- GeekNews Markdown: [https://news.hada.io/topic/28307.md](https://news.hada.io/topic/28307.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-04-08T10:31:43+09:00
- Updated: 2026-04-08T10:31:43+09:00
- Original source: [googlecloudplatform.github.io](https://googlecloudplatform.github.io/scion/overview/)
- Points: 10
- Comments: 1

## Topic Body

- 컨테이너 안에서 동시에 실행되는 LLM 기반 에이전트들을 로컬 머신과 원격 클러스터에 걸쳐 관리하도록 설계된 실험적 플랫폼  
- 각 에이전트는 **독립된 신원, 자격증명, 워크스페이스**를 가진 격리된 프로세스로 동작하며, 코딩·감사·테스트 등 다양한 목표를 동적·병렬로 추진  
- **"에이전트를 위한 하이퍼바이저"** 로 정의되며, 행동 규칙을 맥락에 주입하는 대신 컨테이너·git 워크트리·네트워크 정책으로 외부에서 격리하는 철학을 채택  
- Gemini CLI, Claude Code, OpenCode, Codex 등 주요 에이전트를 **하네스(harness)** 어댑터로 통합하며, Docker·Podman·Apple Container·Kubernetes를 런타임으로 지원  
- 에이전트 수명주기(Phase), 현재 행동(Activity), 세부 상태(Detail)를 **3차원 상태 모델**로 추적하며, 협업 시나리오를 데모 게임 코드베이스로 시연  
  
---  
  
### Scion이란?  
  
- 컨테이너에서 동시에 실행되는 **LLM 기반 에이전트 그룹**을 로컬 머신, 원격 VM, Kubernetes 클러스터 전반에서 관리하는 실험적 오케스트레이션 테스트베드  
- 에이전트별로 독립된 신원·자격증명·워크스페이스를 부여해, 리서치·코딩·감사·테스트 등 서로 다른 목표를 **동적으로 진화하는 병렬 태스크 그래프**로 실행  
- Google은 Scion을 **"에이전트를 위한 하이퍼바이저"** 로 정의하며, 에이전트 메모리·채팅룸·태스크 관리를 독립적(orthogonal) 관심사로 통합  
  
### 핵심 설계 철학: 제약보다 격리  
  
- 에이전트 행동을 규칙으로 제한하는 대신, **컨테이너·git 워크트리·네트워크 정책** 같은 인프라 레벨 경계로 안전성을 확보  
- 에이전트는 `--yolo` 모드로 자유롭게 실행되되, **격리 레이어**가 외부에서 가드레일을 담당  
- 이 방식 덕분에 에이전트 컨텍스트에 복잡한 규칙을 주입할 필요가 없어, 에이전트가 자신의 태스크에만 집중 가능  
  
### 핵심 개념 (용어 사전)  
  
Scion은 독자적인 용어 체계를 사용하므로, 아래 개념을 먼저 이해해야 함  
  
- **Agent**: LLM + Harness 루프를 실행하는 격리된 프로세스. Scion의 기본 실행 단위이며, 독립적인 신원·자격증명·워크스페이스를 보유  
- **Grove**: 에이전트들이 존재하는 프로젝트 워크스페이스. 파일 시스템의 `.scion` 디렉터리에 대응하며, git 저장소 루트나 사용자 홈 폴더에 위치 가능  
  - git 기반 Grove는 **UUID v5** (저장소 URL에서 결정론적 생성), Hub 네이티브 Grove는 **UUID v4** 사용  
- **Hub**: 호스팅 Scion 아키텍처의 **중앙 컨트롤 플레인**. 사용자·Grove·런타임 브로커 간 상태를 조율하는 "두뇌" 역할  
  - OAuth 기반 신원·인증 관리, 에이전트/Grove/템플릿 상태의 중앙 DB 저장, 수명주기 커맨드 디스패치, Web Dashboard를 통한 협업 뷰 제공  
- **Profile**: 특정 런타임과 Harness 설정을 묶어 정의하는 **실행 환경 명세**. "Local Docker", "Production Kubernetes" 등 환경 간 전환 시 템플릿 수정 없이 Profile만 교체  
- **Harness**: Gemini CLI·Claude Code·Codex 등 특정 LLM 도구를 Scion 생태계에 통합하는 **어댑터**. `start`, `stop`, `attach`, `resume` 같은 범용 Scion 커맨드가 어떤 에이전트에서도 일관되게 동작하도록 처리  
- **Template**: 에이전트 생성의 청사진. 기본 설정·시스템 프롬프트·툴을 정의하며 `.scion/templates/`에 저장  
  - 기본 제공 템플릿(`gemini`, `claude`, `opencode`, `codex`) 외에 "보안 감사자", "React 전문가" 같은 **커스텀 역할 템플릿** 생성 가능  
- **Runtime**: 에이전트 컨테이너를 실행하는 인프라 레이어. Docker·Podman·Apple Container·Kubernetes를 지원  
- **Runtime Broker**: Hub에 등록해 실행 용량을 제공하는 컴퓨팅 노드(서버·랩톱·K8s 클러스터). 에이전트 수명주기 관리, 워크스페이스 동기화, 로그 스트리밍 담당  
  
### 아키텍처: Manager-Worker 구조  
  
- **scion CLI**: 호스트 측에서 에이전트 수명주기를 오케스트레이션하는 도구. Grove(프로젝트 워크스페이스) 관리와 템플릿 관리(`scion templates`) 제공  
- **Agents**: Docker 등의 격리된 런타임 컨테이너 안에서 Gemini CLI·Claude Code·Codex 등의 에이전트 소프트웨어를 실행  
- 기본 사용 흐름:  
  1. `scion init` — 프로젝트 루트에서 `.scion` 디렉터리 생성  
  2. `scion start &lt;agent-name&gt; "&lt;task&gt;"` — 에이전트 실행  
  3. `scion attach &lt;agent-name&gt;` — 에이전트 세션에 인터랙티브 접속, 또는 `scion logs`로 출력 확인  
  4. `scion resume &lt;agent-name&gt;` — 중단된 에이전트를 상태 보존하며 재시작  
  
### 워크스페이스 전략: git 격리 방식  
  
에이전트마다 독립된 git 워크스페이스를 부여하는 방식이 두 가지로 나뉨  
  
- **로컬 모드 — Git Worktrees**: Hub 없이 실행 시 사용  
  - `../.scion_worktrees/&lt;grove&gt;/&lt;agent&gt;` 경로에 전용 브랜치를 가진 워크트리 생성  
  - 컨테이너 내부의 `/workspace`로 마운트되어, 동일 저장소 히스토리를 공유하면서도 독립된 작업 디렉터리를 가짐  
  - 작업 완료 후 `git merge &lt;agent-branch&gt;` 로 수동 병합  
- **Hub 모드 — Git Init + Fetch**: Hub 사용 시 적용  
  - 브로커가 `SCION_GIT_CLONE_URL`, `SCION_GIT_BRANCH`, `GITHUB_TOKEN`을 컨테이너에 주입  
  - 컨테이너 내부에서 `sciontool init`이 워크스페이스를 초기화하고 HTTPS로 저장소를 fetch한 뒤 `scion/&lt;agent-name&gt;` 브랜치를 체크아웃  
  - 호스트의 SSH 자격증명 불필요, `GITHUB_TOKEN` 필요  
  - 모든 브로커 머신에서 저장소 로컬 존재 여부에 관계없이 **일관된 동작** 보장  
  
### 리소스 격리 메커니즘  
  
- **파일시스템**: 에이전트별 전용 홈 디렉터리를 컨테이너에 마운트  
- **Shadow Mounts (tmpfs)**: `.scion` 설정 데이터나 다른 에이전트 워크스페이스에 접근하지 못하도록 **tmpfs 섀도 마운트**로 차단  
- **자격증명**: `gcloud` 인증 등 민감 자격증명은 읽기 전용 마운트 또는 환경변수 주입으로, 해당 에이전트에만 제한 노출  
- **Grove 데이터 외부화**: non-git Grove 데이터와 에이전트 홈 디렉터리는 외부화해, 에이전트가 워크스페이스에서 타 에이전트 데이터를 순회(traverse) 불가  
  
### 에이전트 상태 모델 (3차원)  
  
에이전트 상태를 세 가지 차원으로 추적해 인프라 이벤트와 에이전트 인지 상태를 구분  
  
- **Phase** (수명주기 단계): `created` → `provisioning` → `cloning` → `starting` → `running` → `stopping` → `stopped` (또는 `error`)  
- **Activity** (running 중 에이전트 행동): `idle`, `thinking`, `executing`, `waiting_for_input`, `blocked`, `completed`, `limits_exceeded`, `offline`  
  - `completed`, `blocked`, `limits_exceeded`는 **"sticky"** 상태로, 에이전트가 명시적으로 재시작되거나 중단될 때까지 유지  
  - `blocked`는 에이전트 스스로 설정하며, 하위 에이전트 완료를 기다리는 중임을 나타내 시스템이 **오류로 오인하는 것을 방지**  
  - `offline`은 에이전트 하트비트가 일정 시간 감지되지 않을 때 발생하며, 인증 토큰 갱신 실패가 원인일 수 있음  
- **Detail**: 현재 Activity의 부가 컨텍스트 (툴 이름, 메시지, 태스크 요약 등 자유 형식)  
  
### 플러그인 시스템  
  
- `hashicorp/go-plugin` 기반 플러그인 아키텍처로 시스템 확장 가능, **gRPC** 통신 사용  
- **메시지 브로커 플러그인**: 에이전트 알림 및 구조화된 메시징을 위한 커스텀 메시지 전달 백엔드 제공  
- **에이전트 하네스 플러그인**: 코어 코드베이스 수정 없이 새 LLM 도구를 Scion에 통합하는 커스텀 하네스 구현 가능  
- 현재 **초기 단계(foundational stage)** 로, 두 플러그인 타입 모두 레퍼런스 구현 제공

## Comments



### Comment 54898

- Author: neo
- Created: 2026-04-08T10:31:43+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47675213) 
- 이번에 **Scion**을 꼭 써보고 싶음  
  예전에 같은 장르의 [**Gastown**](https://github.com/gastownhall/gastown/)을 써봤는데, 결과는 좋았지만 편차가 컸음  
  Gastown의 주요 불만은 (1) 비쌈, (2) **Claude 모델만 강제 사용**, (3) 내부 데이터베이스를 백업하거나 원격으로 연결하기 어려움, (4) 업그레이드 시 자주 **맥락 손실**이 발생함  
  그래도 시장의 다른 도구보다 대화와 협업의 ‘마법 같은’ 결과를 내줌  

- Google의 접근 방식이 흥미로움  
  나는 [**Optio**](https://news.ycombinator.com/item?id=47520220)라는 **Agent Orchestration 플랫폼**을 만들었는데, Notion, Github Issues, Jira, Linear 같은 티켓 시스템과 통합하고, 코드 에이전트가 PR 병합까지 진행하도록 설계했음  
  Scion의 **장기 실행 에이전트**와 **컨테이너 간 통신** 지원이 인상적임  
  다만, 나는 k8s 위에 구축했는데 Scion은 자체 **control plane 재구현**을 시도하는 듯해서 약간 회의적임  

- “제약보다 격리”라는 철학이 맞는 방향 같음  
  컨테이너는 경계를 제공하지만 내부 실행 내용을 볼 수 없음  
  Scion이 얼마나 많은 **실행 컨텍스트**를 노출하는지가 궁금함. 그렇지 않으면 LiteLLM 공격처럼, 실행 후에야 피해를 알게 되는 상황이 생길 수 있음  
  - Scion의 **주 개발자**임  
    여러 단계의 상태와 **telemetry**가 있음  
    기본적으로 hook 시스템이 데이터를 수집하고, OpenTelemetry를 지원하는 경우 이를 **클라우드 수집기**로 전달함  
    일부 활동은 에이전트가 자체 보고하며, 이 정보는 **control plane**에 반영됨  

- 코드가 문서 깊숙이 묻혀 있었음  
  [GitHub 저장소](https://github.com/GoogleCloudPlatform/scion)를 찾아야 함  
  - 맞음, 나도 3월 말에 별표해두고 잊고 있었는데, 이번에 다시 보니 꽤 흥미로움  

- 방향성은 Gastown과 비슷하지만 핵심 기능 몇 가지가 빠진 듯함  
  특히 **formula 기능**이 게임 체인저였음  
  - Scion의 **주 개발자**임  
    빠진 기능들은 의도된 설계임. Scion은 Gastown이 말하는 “**gascity**”에 더 가까움 — 사용자가 직접 오케스트레이션 캐릭터와 정의를 가져오는 구조임  
    [이 예시](https://github.com/ptone/scion-athenaeum)를 보면 단순한 **Markdown 기반 오케스트레이션**임  
    Scion은 **게임 엔진** 역할을 하며, Gastown을 Scion 위로 포팅하는 작업이 진행 중임  

- 프로젝트가 아직 **초기 실험 단계**라서 불안함  
  로컬 모드는 안정적이지만, Hub 기반 워크플로우는 80% 정도 검증, Kubernetes 런타임은 거칠다고 함  
  그래서 지금은 Gastown이 더 나은 선택일지도 모르겠음  
  - Gastown이 다른 어떤 것보다 낫다고 생각하는 건 상상하기 어려움  

- 제목을 보고 다른 **SCION(인터넷 아키텍처)** 을 떠올렸음  
  [위키 문서](https://en.wikipedia.org/wiki/SCION_(Internet_architecture)) 참고  

- 에이전트를 더 실험해보고 싶은데, 회사가 **Claude Code**만 결제해줌  
  게다가 TOS상 다른 용도로 API를 쓰면 안 됨  
  혹시 비슷한 상황인 사람 있음? 토큰 기반 과금도 금방 비싸짐  
  - 이건 기본적으로 **컨테이너 안에서 Claude Code**를 실행하므로 TOS 위반이 아님  

- 정말 멋짐! 나도 최근 비슷한 걸 만들어봄  
  [**Parallax**](https://github.com/s2-streamstore/parallax)를 해킹해봤고, 관련 내용을 [블로그](https://s2.dev/blog/distributed-ai-agents)에 정리했음
