AOS Community Edition

캡슐을 사용자 공간 부품으로 삼는 검사 가능한 오픈 에이전트 운영체제

curl --proto '=https' --tlsv1.2 -fsSL https://aos.unicity.ai/install.sh | sh

Unicity 가 공개한 에이전트 운영체제의 커뮤니티 판입니다. aos 명령과 HTTP API, 배포판, 1차 캡슐, 감사 기능을 하나의 제품 표면으로 묶어 냅니다. 설치 관리자가 aos 명령과 고정된 런타임, 커뮤니티 에디션 캡슐 묶음을 제품이 소유하는 경로 아래에 함께 설치하며 오프라인 초기화를 지원합니다. 캡슐은 사용자 공간의 범용 부품이라 하네스나 커넥터, 서비스로 조립할 수 있습니다.

판단

이럴 때 씁니다

  • 에이전트 실행 환경을 조각조각 조립하는 대신 통째로 구성된 것을 받고 싶을 때
  • 에이전트가 쓸 기능을 최소 권한 단위로 잘라 관리하고 싶을 때
  • Codex 와 Claude, Grok 이 같은 제품 경계를 통해 붙는 구조가 필요할 때
  • 설치물의 출처 증명과 서명, 런타임 호환 고정이 요구되는 환경일 때
  • 인터넷이 닿지 않는 환경에서 초기화해야 할 때

이럴 땐 쓰지 마세요

  • Unicity CE 가 아닌 다른 배포판을 쓰려 할 때. 이 릴리스는 배포 상태가 고정돼 있어 별도 독립 설치가 필요합니다
  • 가벼운 도구 하나만 필요할 때. 운영체제 수준의 구성 전체를 받게 됩니다
  • 제품이 소유하는 설치 경로를 따르기 어려운 환경일 때

차별점

  • 명령 경계를 명시적으로 나눴습니다. 제품이 소유한 루트는 제품 구현이 대체하고 나머지 런타임 루트는 인자와 종료 코드와 시그널이 그대로 통과합니다.
  • 릴리스 검증이 고정된 런타임의 명령 목록과 제품의 루트 계약을 비교합니다. 새 런타임 명령이 상속인지 소유인지 정하지 않고는 릴리스에 들어올 수 없습니다.
  • 모든 릴리스가 체크섬과 Sigstore 번들, 빌드 출처 증명, 런타임 호환 고정 파일을 함께 냅니다.
  • 업그레이드 게이트가 실제 후보로 복제본을 보존하고 새로 만든 조정 상태로 부팅되는지를 확인한 뒤에만 통과합니다.
  • Forge 가 에이전트에게 캡슐 모델을 가르쳐 실제 작업 중 발견한 공백을 스스로 메우도록 유도합니다.

워크플로

  1. 01설치 관리자를 실행합니다. aos 명령과 고정 런타임, 커뮤니티 에디션 캡슐이 함께 들어옵니다.
  2. 02aos init 으로 초기화합니다. 오프라인 옵션을 쓰면 내려받지 않고 로컬 캡슐 자산으로 구성합니다.
  3. 03aos status 로 상태를 봅니다. 기계가 읽을 형식으로도 받을 수 있습니다.
  4. 04에이전트를 붙이려면 aos mcp serve 를 씁니다. 이것이 Codex 와 Claude, Grok 이 공유하는 제품 경계입니다.
  5. 05기능 공백을 발견하면 Forge 로 최소 권한 캡슐을 만들어 검증하고 붙입니다.
  6. 06재설치는 독립 런타임 설치를 새로 쓰지 않고 제품 전체를 함께 올립니다.

주요 명령

명령설명
curl --proto '=https' --tlsv1.2 -fsSL https://aos.unicity.ai/install.sh | shaos 명령과 고정 런타임, 캡슐을 한 번에 설치합니다. 버전을 명시해 정확한 릴리스를 고를 수 있습니다.
aos init --offline내려받지 않고 로컬의 제품 버전 캡슐 자산으로 초기화합니다.
aos status --json상태를 기계가 읽을 형식으로 냅니다.
aos --principal codex-code mcp serveMCP 제품 경계를 띄웁니다. Codex 와 Claude, Grok 이 공유합니다.
aos doctor런타임 진단입니다. 인자와 종료 코드가 그대로 통과합니다.

함정

설치 전에 확인하세요

  • 캡슐 개수가 문서마다 다릅니다. README 는 21개라고 적고 2026.1.3 릴리스 노트는 서명된 19개라고 적습니다. 정확한 구성은 각 아카이브의 릴리스 매니페스트에서 확인해야 합니다.
  • 라이선스가 MIT 또는 Apache-2.0 이중입니다. 한쪽만 보고 판단하면 안 됩니다.
  • 이 릴리스는 배포 상태를 Unicity CE 로 고정합니다. 다른 배포판을 적용하려면 독립 런타임 설치와 별도 런타임 홈이 필요합니다.
  • MCP 폼 요청을 지원하지 않는 클라이언트에서는 로컬 승인 창이 뜹니다. macOS 는 AppKit, 윈도우는 기본 대화 상자, 리눅스는 Pinentry 입니다.
  • 그 로컬 승인 경로는 불리언 하나나 정해진 승인 열거값만 받습니다. 임의 문자열과 비밀번호 형태 입력, URL 요청은 수집하지 않습니다.
  • 이동 채널 설치는 별도의 보호된 승격 절차를 거친 뒤에만 바뀝니다.

검토 메모

공식 문서·릴리스·공개 자료를 바탕으로 정리한 편집 메모입니다.

저는 이 프로젝트에서 가장 공들인 부분이 기능이 아니라 경계 정의라고 봅니다. 어떤 명령을 제품이 소유하고 어떤 명령을 런타임에서 그대로 통과시킬지를 문서로 못박고, 릴리스 검증이 고정된 런타임의 명령 목록과 그 계약을 비교합니다. 새 런타임 명령이 상속인지 소유인지 결정하지 않으면 릴리스가 나가지 않는다는 뜻입니다. 이런 규칙은 보통 몇 번 어긋난 뒤에 생기는데 처음부터 세워 두었습니다.

공급망 쪽도 같은 태도입니다. 체크섬과 서명 번들, 빌드 출처 증명이 매 릴리스에 붙고 런타임 호환 값이 파일로 고정됩니다. 업그레이드 게이트는 실제 후보가 기존 홈 복제본을 보존한 채 새로 만든 조정 상태로 부팅되는지를 확인한 뒤에만 통과합니다. 설치물을 감사해야 하는 환경이라면 이 부분이 도입 근거가 될 만합니다.

다만 확인하고 들어가실 것이 둘 있습니다. 하나는 캡슐 개수인데 README 는 21개, 2026.1.3 릴리스 노트는 서명된 19개로 서로 다르게 적고 있어 제가 어느 쪽도 단정하지 않았습니다. 실제 구성은 아카이브의 릴리스 매니페스트를 보셔야 합니다. 다른 하나는 라이선스로, MIT 또는 Apache-2.0 중에서 고르는 이중 라이선스입니다. 한쪽만 보고 사내 검토를 올리면 되돌아옵니다.

구조를 이해하는 열쇠는 캡슐이라는 단위라고 생각합니다. 저장소는 캡슐을 특정 용도의 플러그인이 아니라 사용자 공간의 범용 부품으로 규정하고, 하네스나 커넥터, 서비스로 조립하도록 열어 두었습니다. Forge 라는 도구가 에이전트에게 이 모델을 가르쳐 실제 작업 중에 기능 공백을 발견하면 최소 권한 캡슐을 직접 만들어 검증하도록 유도합니다. 에이전트가 쓰는 환경을 에이전트가 넓히게 한다는 발상인데, 그 확장이 권한 경계 안에서 일어나도록 묶어 둔 점이 이 설계의 핵심입니다.

비교

에이전트 프레임워크가 코드 수준의 조립 방식을 정한다면, AOS 는 그보다 아래에서 실행 환경 자체를 제품으로 묶습니다. 설치와 업그레이드, 서명, 권한 경계까지 한 덩어리로 오는 대신 그 구성을 그대로 받아들여야 합니다. 도구 하나가 필요한 경우에는 과합니다.

최근 변경

2026.1.3 은 Astrid 런타임 v0.10.4 를 함께 묶은 제품 릴리스입니다. 정확한 런타임 식별자와 WIT 커밋, 호환 고정 값은 런타임 호환 파일과 각 아카이브의 릴리스 매니페스트에 공개됩니다. 커뮤니티 에디션이 고른 서명된 설치 가능 캡슐 산출물이 함께 들어 있고 공개된 캡슐 식별자는 그대로 유지됩니다.