본문으로 건너뛰기
개인개인 공개 런처 · 프로젝트별 격리 · pool 간 FIFO · OMP upstream 연동

AI CLI 런타임 격리와 영속 FIFO 전달을 구현한 공개 런처

개인 설계·구현·운영

2026-04-01 — present

프로젝트별 AI CLI 런타임 격리에서 시작해, 장기 공용 잠금으로 전달이 지연되던 작업을 영속 접수·목적지별 FIFO 큐로 전환했습니다. OMP는 로컬 포크 대신 upstream 확장·설정 overlay·얇은 adapter로 통합하고, 실행·print·종료 신호 경계를 검증했습니다.

검증된 결과

런타임 격리

등록 프로젝트별 런타임 홈

세션·스킬·MCP·정책을 작업 경계별로 분리

이전: 프로젝트가 전역 CLI 상태를 공유

경계 선택

정규화 경로의 단일 소유 경계 선택

경계 밖·이탈·모호함은 AI CLI 시작 전 중단

이전: 이름·원격 저장소 기반 프로필 추정 위험

통합 전달

실제 두 pool 작업 첫 시도·exit 0·DELIVERED

동일 목적지 FIFO · 중복 동일 ID · wait timeout 비취소

이전: 공용 잠금 대기 600초·3600초 실패

프로필 경계와 실행 검증

런처가 작업 경로를 정규화한 뒤 프로필 레지스트리에서 가장 긴 일치 경계를 고릅니다. 경계 없음·동률·심볼릭 링크 이탈은 시작 전에 중단합니다.

← 좌우로 스크롤해 전체 흐름 보기 →

사용자 요청의 경로를 정규화하고 프로필 레지스트리에서 최장 일치 소유자를 선택한 뒤 소유 런타임과 실행 검증으로 연결하며 경계 없음, 동률, 심볼릭 링크 이탈, 검증 실패를 시작 전에 중단하는 아키텍처

실행과 실패 차단 흐름

경계 판정, fingerprint 기반 재생성, 설정·원문 검증의 각 실패 경로는 AI CLI가 시작되기 전에 종료됩니다.

← 좌우로 스크롤해 전체 흐름 보기 →

프로필 선택 후 경계를 판정하고 fingerprint 변경 여부에 따라 런타임을 재생성한 뒤 검증 통과 시 시작하고 실패 시 중단하는 시퀀스

문제 해결 과정

1

AI CLI의 전역 홈을 여러 프로젝트가 공유하면 세션·도구·규칙이 다른 작업 경계로 섞일 수 있었습니다.

해결 과정

등록한 프로젝트마다 Codex·Kiro 런타임 홈을 생성하고, 프로필 명령과 harness-exec가 같은 실행 정책을 사용하도록 통합했습니다.

결과

프로젝트별 런타임 상태를 분리하고, 공개 저장소의 설치·프로필·런타임 테스트로 동작을 검증합니다.

2

검증·push·원격 재확인까지 공용 잠금을 잡아 전달 대기가 600초와 3600초에 실패했고, timeout 상향만으로 해결되지 않았습니다.

해결 과정

영속 enqueue와 완료 대기를 분리하고 목적지별 FIFO·중복 접수 방지·worker/test 예산을 적용했습니다. 접수 당시 patch·manifest·binding·runtime snapshot을 고정하고, push 직후 crash는 영속 publication intent와 원격 이력으로 재시도 여부를 판단합니다.

결과

실제 두 pool의 동일 목적지 작업이 FIFO로 시작해 모두 첫 시도·exit 0·DELIVERED로 완료됐습니다. 중복 접수는 같은 ID를 반환했고, wait timeout 뒤에도 작업은 queued 상태로 유지됐습니다.

3

OMP 로컬 포크의 소스 드리프트 검사가 실행 세션을 종료시키고, 격리 HOME 때문에 hook 정책과 인증 전달이 어긋났습니다.

해결 과정

로컬 패치를 제거하고 upstream trusted extension·설정 overlay·얇은 adapter로 전환했습니다. hook 자식의 계정 HOME과 shell의 인증 전달을 바로잡고, URL 읽기·print provider 호출 전 정책 검사와 PTY의 FD·PID·signal 전달을 검증했습니다.

결과

v0.77.7 선택 snapshot에서 실제 native print의 거부는 provider 호출 0회·exit 2, 허용은 receipt PID 일치를 확인했습니다. Ctrl-C는 shell 130·남은 native 프로세스 0개로 종료했습니다. 전체 global DB SSOT와 MCP/LSP upstream 활성화는 완료 범위가 아닙니다.

운영 한계

아키텍처·시퀀스 다이어그램은 프로젝트 경계 선택과 런타임 격리 흐름을 설명합니다. 새 영속 큐나 OMP 내부 구조를 그린 도표는 아닙니다.
검증된 범위는 영속 FIFO 전달과 OMP 실행·URL 읽기·print·signal 경계입니다. 전체 global DB SSOT와 MCP/LSP upstream 활성화는 미완료이며, v0.77.7 선택 snapshot을 Homebrew legacy keg 교체 완료와 동일시하지 않습니다.
공개 contract demo는 격리·원문 재검증 예제입니다. 비공개 회사 데이터와 운영 인덱스는 개인 프로젝트의 공개 근거에서 제외합니다.

프로젝트 설명

harness-launcher는 등록한 프로젝트 경로를 신뢰 경계로 삼고, 소유 경계가 불명확하면 AI CLI를 시작하지 않습니다. 통합 큐는 접수와 완료를 분리해 여러 pool의 동일 목적지 작업을 FIFO로 시작하며 worker·test 예산을 제한합니다. OMP 연동은 upstream 실행기 위에서 기존 정책을 집행합니다. 별도 공개 contract demo는 격리·원문 SHA-256 재검증을 재현하며, 비공개 문서·회사 데이터·운영 인덱스는 공개 근거에서 제외합니다.

주요 내용

  • 정규화된 프로젝트 경로로 런타임을 격리하고 경계 밖·심볼릭 링크 이탈·모호한 소유권은 실행 전 차단
  • 영속 접수·목적지별 FIFO·중복 방지·worker/test 예산으로 장기 공용 잠금 대체
  • 실제 두 pool 전달 완료, 중복 접수 동일 ID, wait timeout 비취소 확인
  • OMP upstream 연동과 실제 print·Ctrl-C 검증, PR #146·v0.77.7로 공개 변경 추적

기술 선택 근거

  • ▶저장소 이름이나 원격 URL을 추정하지 않고 정규화된 프로젝트 경로를 신뢰 경계로 사용합니다. 가장 구체적인 단일 경계가 아니면 실행하지 않습니다.
  • ▶timeout을 늘리는 대신 영속 접수와 완료 대기를 분리했습니다. 동일 목적지의 시작 순서는 pool을 넘어 보장하되 worker·test 동시성은 별도 예산으로 제한합니다.
  • ▶OMP 로컬 포크를 유지하지 않고 upstream trusted extension·overlay·얇은 adapter를 사용합니다. 필요한 upstream API가 없는 MCP/LSP는 활성화하지 않습니다.

깨달은 점

  • •프로필은 이름 추정이 아니라 정규화된 경로 소유권으로 선택한다.
  • •접수와 완료를 분리해야 호출자의 timeout이 이미 접수한 작업을 취소하지 않는다.
  • •upstream 연동은 설정 호환만으로 끝나지 않는다. 실제 HOME·인증·입력·종료 신호까지 확인한다.

용어 풀이

비전문가도 시스템의 역할을 이해할 수 있도록 핵심 용어를 먼저 설명합니다.

하네스
AI CLI의 실행 환경·도구·정책·검증을 반복 가능한 경로로 묶는 운영 계층.
프로필
한 등록 프로젝트와 그 프로젝트가 소유하는 실행 경계.
런타임 홈
CLI별 설정·세션·스킬을 보관하는 프로젝트 범위 생성 디렉터리.
경계 확인
정규화된 현재 경로를 소유하는 단일 등록 프로젝트를 찾는 절차.
Fail-closed
경계나 설정을 확정할 수 없으면 대체 경로로 진행하지 않고 실행을 중단하는 방식.
MCP
AI CLI가 프로젝트 도구를 표준 방식으로 호출하게 하는 연결 규약.
Contract demo
운영 데이터 없이 경계·검증·실패 조건만 재현하는 공개 예제.
CI
공개 저장소 변경마다 테스트를 자동 실행하는 검증 파이프라인.

기술 스택

ZshBashPythonHomebrewGitHub ActionsMCPRuntime IsolationFail-closed Validation