Linux Container로 만들던 Cell을 macOS 사용자로 바꿨다

✨ GPT-5.6 Sol의 요약 　

Linux VM과 사용자별 Container를 기본으로 잡았던 계획을 접고, 직원별 macOS 사용자와 native OpenClaw를 실행 단위로 다시 정한 기록.

하루 만에 기본 구조를 뒤집었다

어제는 코디네이터와 워커를 실제로 연결해봤다. 여러 AI가 만든 결과를 Worktree와 Branch, commit으로 나누고 다시 합치는 방법을 실험했다.

그 작업과 함께 AI Orchestration의 실행환경도 만들고 있었다. 14일까지 잡았던 기본 구조는 다음과 같았다.

Mac mini
→ Colima Linux VM 1개
→ 직원별 OpenClaw Cell Container

공통 Image를 만들고 직원마다 Network와 Volume을 나누면 배포와 재현이 편해 보였다. 실제로 공식 OpenClaw Linux arm64 Image를 확인하고, child Image와 Cell Network 계약도 만들었다. 직원별 환경을 Container로 분리하는 방향이 꽤 구체적으로 진행된 상태였다.

그런데 15일에 이 구조를 기본안에서 내렸다.

내가 만들려던 것은 Container 서비스가 아니었다

AI Orchestration의 목적을 다시 적어보니 어긋난 부분이 보였다.

내가 만들고 싶었던 것은 직원들이 WebChat에 목표만 말하면, 개인 AI가 필요한 작업을 나누고 도구를 골라 끝까지 처리하는 환경이었다. 코드와 문서만 만드는 것이 아니라 Mac 앱을 다루고, Xcode와 Simulator를 실행하고, 사용자의 Workspace와 Git identity로 실제 결과를 남겨야 했다.

Linux Container 안에서 억지로 macOS 기능을 호출하는 순간 구조가 이상해진다. Container 바깥에 별도 실행기를 두고, 다시 권한과 상태를 이어 붙이고, 사용자의 Keychain과 GUI Session을 전달해야 한다. 격리를 위해 넣은 계층 때문에 정작 필요한 기능은 계속 우회 경로를 만들어야 했다.

OpenClaw도 단순한 stateless worker가 아니었다. 한 사용자의 Gateway와 Profile, Session, Memory, OAuth와 실행 상태를 함께 가진 개인 환경에 가까웠다. 그렇다면 Cell을 Container 하나라고 정의한 것부터 잘못됐을 수 있었다.

15일에는 Cell의 뜻을 다시 정했다.

직원 1명
= macOS 사용자 1개
= 독립 OpenClaw Gateway 1개
= UID·HOME·Keychain 1세트
= ChatGPT OAuth·CODEX_HOME 1세트
= Workspace·Git identity·Session·Memory 1세트

Mac mini 한 대에서 직원마다 독립된 macOS 사용자를 만들고, 각 사용자 안에서 complete OpenClaw Gateway를 native로 실행하는 구조였다.

Linux와 Container를 실패로 지우지는 않았다

방향을 바꿨다고 14일까지 만든 것을 실패로 처리하고 싶지는 않았다.

Container 실험에서 확인한 것은 분명히 있었다. 공식 Image, 비root 실행, read-only root, Network 분리, Volume과 credential 경계, Image provenance와 restart 같은 증거는 그대로 가치가 있었다.

다만 그것이 최종 Cell의 정의는 아니었다.

Linux VM과 Container는 기본 Pilot 환경이 아니라, 정말 격리가 필요한 특정 작업에만 선택하는 sandbox 후보로 내렸다. native macOS가 기본이고, Container는 필요가 증명됐을 때 쓰는 도구가 됐다.

이 차이가 중요했다. 이미 많은 시간을 썼다는 이유로 Container 구조를 계속 밀고 가면, 제품이 실행환경에 끌려다니게 된다. 구현한 양이 선택을 정당화해주지는 않았다.

macOS 사용자만 나눈다고 격리가 끝나는 것도 아니었다

native 구조가 단순해 보였지만 검증할 것은 더 많아졌다.

• 로그인한 직원과 실제 macOS 실행 사용자가 같은가?
• 그 사용자의 Gateway, OAuth, Workspace와 Git 작성자가 정확히 묶이는가?
• 한 사용자의 인증이 실패했을 때 다른 사용자의 인증으로 넘어가지 않는가?
• 다른 사용자의 HOME, Keychain, Port와 Workspace에 접근할 수 없는가?
• 빠른 사용자 전환과 재부팅 뒤에도 각 Gateway가 자기 상태로 복구되는가?

그래서 문서에서 topology만 바꾼 뒤 끝내지 않았다. native macOS Cell 계약과 Acceptance를 새로 만들고, 실제 Runtime 증거가 없는 항목은 NOT_READY로 남겼다.

테스트 fixture가 통과했다고 실제 두 사용자의 격리가 끝났다고 말할 수도 없었다. 외부 입력 파일의 hash와 실제 probe 실행 증거를 분리했고, 다른 사용자를 흉내 낸 값이나 symlink, macOS의 대소문자·Unicode 경로 alias로 검사를 우회하지 못하게 계속 고쳤다.

낮 12시에 topology를 바꾼 뒤 오후 내내 “통과했다고 거짓말할 수 있는 구멍”을 막는 commit이 이어졌다. 구조를 바꾸는 것보다 새 구조의 통과 조건을 정직하게 만드는 데 더 많은 코드가 들어갔다.

공통 Workflow와 개인 상태도 분리했다

직원마다 완전히 다른 환경을 주더라도 회사가 관리하는 공통 Workflow는 같은 버전으로 배포해야 했다. 반대로 공통 Workflow를 업데이트한다고 개인 OAuth, Memory, Workspace까지 바뀌면 안 됐다.

15일 오후에는 Workflow Release를 version과 content hash로 고정하고, 검증된 release만 선택하도록 admission 계약을 만들었다. 새 release 선택은 원자적으로 바뀌어야 하고, 실행 중인 작업은 시작할 때 선택한 release에 고정돼야 하며, rollback과 정리 과정에서도 사용 중인 release가 사라지면 안 됐다.

이 역시 Source와 테스트를 만들었다고 실제 Mac의 공용 설치 위치에 배포됐다고 기록하지 않았다. 설치하지 않은 Runtime은 끝까지 NOT_READY였다.

제품이 실행환경보다 먼저였다

14일에는 여러 AI를 어떻게 나누고 통합할지를 고민했다. 15일에는 그 AI들이 실제로 살아갈 Cell이 무엇인지 다시 고민했다.

Container를 많이 준비해둔 상태에서 native macOS로 방향을 바꾸는 것이 아깝지 않은 것은 아니었다. 그래도 제품이 해야 할 일이 macOS 앱과 Xcode, 사용자별 OAuth와 Memory까지 포함한다면 실행환경도 그 목적을 따라야 했다.

Cell은 격리된 process 하나가 아니었다. 한 사람이 자기 인증과 기억, 작업 공간과 도구를 가지고 일하는 온전한 개인 AI 환경이었다.

15일은 Linux VM 위에 Container를 더 쌓는 대신, macOS 사용자 자체를 Cell의 경계로 삼기로 한 날이었다.