▲

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

 (googlecloudplatform.github.io)
5P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • 컨테이너 안에서 동시에 실행되는 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 <agent-name> "<task>" — 에이전트 실행
    3. scion attach <agent-name> — 에이전트 세션에 인터랙티브 접속, 또는 scion logs로 출력 확인
    4. scion resume <agent-name> — 중단된 에이전트를 상태 보존하며 재시작

워크스페이스 전략: git 격리 방식

에이전트마다 독립된 git 워크스페이스를 부여하는 방식이 두 가지로 나뉨

  • 로컬 모드 — Git Worktrees: Hub 없이 실행 시 사용
    • ../.scion_worktrees/<grove>/<agent> 경로에 전용 브랜치를 가진 워크트리 생성
    • 컨테이너 내부의 /workspace로 마운트되어, 동일 저장소 히스토리를 공유하면서도 독립된 작업 디렉터리를 가짐
    • 작업 완료 후 git merge <agent-branch> 로 수동 병합
  • Hub 모드 — Git Init + Fetch: Hub 사용 시 적용
    • 브로커가 SCION_GIT_CLONE_URL, SCION_GIT_BRANCH, GITHUB_TOKEN을 컨테이너에 주입
    • 컨테이너 내부에서 sciontool init이 워크스페이스를 초기화하고 HTTPS로 저장소를 fetch한 뒤 scion/<agent-name> 브랜치를 체크아웃
    • 호스트의 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) 로, 두 플러그인 타입 모두 레퍼런스 구현 제공

함께 보면 좋은 글 β

▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • 이번에 Scion을 꼭 써보고 싶음
    예전에 같은 장르의 Gastown을 써봤는데, 결과는 좋았지만 편차가 컸음
    Gastown의 주요 불만은 (1) 비쌈, (2) Claude 모델만 강제 사용, (3) 내부 데이터베이스를 백업하거나 원격으로 연결하기 어려움, (4) 업그레이드 시 자주 맥락 손실이 발생함
    그래도 시장의 다른 도구보다 대화와 협업의 ‘마법 같은’ 결과를 내줌

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

  • “제약보다 격리”라는 철학이 맞는 방향 같음
    컨테이너는 경계를 제공하지만 내부 실행 내용을 볼 수 없음
    Scion이 얼마나 많은 실행 컨텍스트를 노출하는지가 궁금함. 그렇지 않으면 LiteLLM 공격처럼, 실행 후에야 피해를 알게 되는 상황이 생길 수 있음

    • Scion의 주 개발자임
      여러 단계의 상태와 telemetry가 있음
      기본적으로 hook 시스템이 데이터를 수집하고, OpenTelemetry를 지원하는 경우 이를 클라우드 수집기로 전달함
      일부 활동은 에이전트가 자체 보고하며, 이 정보는 control plane에 반영됨

  • 코드가 문서 깊숙이 묻혀 있었음
    GitHub 저장소를 찾아야 함

    • 맞음, 나도 3월 말에 별표해두고 잊고 있었는데, 이번에 다시 보니 꽤 흥미로움

  • 방향성은 Gastown과 비슷하지만 핵심 기능 몇 가지가 빠진 듯함
    특히 formula 기능이 게임 체인저였음

    • Scion의 주 개발자임
      빠진 기능들은 의도된 설계임. Scion은 Gastown이 말하는 “gascity”에 더 가까움 — 사용자가 직접 오케스트레이션 캐릭터와 정의를 가져오는 구조임
      이 예시를 보면 단순한 Markdown 기반 오케스트레이션임
      Scion은 게임 엔진 역할을 하며, Gastown을 Scion 위로 포팅하는 작업이 진행 중임

  • 프로젝트가 아직 초기 실험 단계라서 불안함
    로컬 모드는 안정적이지만, Hub 기반 워크플로우는 80% 정도 검증, Kubernetes 런타임은 거칠다고 함
    그래서 지금은 Gastown이 더 나은 선택일지도 모르겠음

    • Gastown이 다른 어떤 것보다 낫다고 생각하는 건 상상하기 어려움

  • 제목을 보고 다른 SCION(인터넷 아키텍처) 을 떠올렸음
    위키 문서 참고

  • 에이전트를 더 실험해보고 싶은데, 회사가 Claude Code만 결제해줌
    게다가 TOS상 다른 용도로 API를 쓰면 안 됨
    혹시 비슷한 상황인 사람 있음? 토큰 기반 과금도 금방 비싸짐

    • 이건 기본적으로 컨테이너 안에서 Claude Code를 실행하므로 TOS 위반이 아님

  • 정말 멋짐! 나도 최근 비슷한 걸 만들어봄
    Parallax를 해킹해봤고, 관련 내용을 블로그에 정리했음

답변달기