2026년 macOS에서 OpenClaw staging·프로덕션 워크스페이스 분리: LaunchAgent, 8787/8788, doctor 스모크와 클라우드 Mac mini

2026년 플랫폼 엔지니어는 한 대의 Apple Silicon Mac mini에 OpenClaw staging 게이트웨이와 프로덕션 게이트웨이를 동시에 올리고 싶어 한다. 조달보다 하루 약 16.9달러부터 시작하는 클라우드 macOS를 먼저 돌리는 편이 빠르기 때문이다. 그러나 설정 루트를 공유하면 staging의 npm link나 임시 도구 허용 목록이 프로덕션 sqlite에 기록되고, 장애 분석은 “누가 마지막에 건드렸나” 추리가 된다. PATH만 나눠도 launchd plist의 Label이 같으면 launchctl kickstart -k가 엉뚱한 프로세스를 재시작한다. 이 글은 chmod 700 이중 홈, 포트 8787/8788, 로그 경로 분리, 디버깅 시 ThrottleInterval을 최소 10초로 올리는 운용, 그리고 트래픽 전 doctor 5분 스모크를 묶는다. EADDRINUSE·lsof, 첫 실행 PATH·LaunchEnvironmentVariables, doctor 진단을 함께 읽으면 재현성이 크게 좋아진다.

감사 질문 세 가지——어느 디렉터리가 어느 API 키를 갖는가, 어느 Label이 어느 포트를 LISTEN하는가, 마지막으로 성공한 doctor 로그가 어디에 보관되는가——에 바로 답할 수 있게 만드는 것이 목표다.

운영 측면에서 각 환경의 launchctl print 출력을 주간 스냅샷으로 남기면, 조용한 설정 드리프트를 빨리 잡을 수 있다.

추가로, 각 프로필에 대해 sysctl kern.boottime과 게이트웨이 기동 시각을 티켓에 함께 적어 두면 “재부팅 후 plist가 빠졌다”는 유형의 이슈를 빠르게 걸러낼 수 있다. 재부팅 직후에는 launchctl print gui/$(id -u)로 로드된 에이전트 목록을 다시 캡처해 이전 스냅샷과 비교하라.

마지막으로, 스테이징에서만 허용할 임시 스크립트 경로를 PATH 끝에 두고 프로덕션 plist에서는 아예 제외하는 식으로 “실수로 스테이징 전용 바이너리를 프로덕션이 호출”하는 상황을 줄일 수 있다.

한 대 두 역할의 이유

클라우드 Mac mini는 launchd·키체인·Safari 병행처럼 Linux CI에서 놓치기 쉬운 경계를 그대로 제공한다. PoC에선 staging을 하루 여러 번 머지하고 프로덕션은 변경 창에서만 만지는 패턴이 흔하다. 프로필을 플래그 전환이 아니라 격리 경계로 취급하면 권한 검토가 쉬워진다. 디스크가 512GB급이어도 잘못된 프로덕션 연결 한 번의 손실보다 싸다.

재무 설득에는 “일 16.9USD 전후 렌탈로 이중 게이트웨이 검증”처럼 숫자로 말하면 통과가 빠르다. 금속 서버 두 대를 사기 전에 먼저 물리 동작을 빌려 확인하는 것이 현실적이다.

디렉터리·비밀 관리

~/.openclaw-staging과 ~/.openclaw-prod를 만들고 chmod 700으로 다른 사용자의 열람을 막는다. staging을 프로덕션에 심볼릭 링크하지 않는다. README에 생성일, 담당자, 마지막 doctor 성공 시각, 로그 로테이션(파일당 128MB 상한 등)을 적는다. 나중에 OS 사용자를 분리해도 디렉터리 이름을 유지하면 마이그레이션이 단순해진다.

백업 tarball은 환경별로 분리하고 복원 절차를 Runbook에 적는다. 같은 tarball을 두 환경에서 재사용하면 비밀이 섞인다.

plist·로그·환경 변수

com.example.openclaw.gateway.staging처럼 Label을 절대 중복하지 않는다. StandardOutPath와 StandardErrorPath는 ~/Library/Logs/OpenClaw/ 아래에서 파일명을 나눈다. LaunchEnvironmentVariables에는 which node로 확인한 절대 경로, Homebrew나 volta shim을 앞에 둔 PATH, OPENCLAW_PROFILE_DIR 같은 루트 변수를 넣는다. 크래시 루프에는 ThrottleInterval을 10초 이상으로 올려 로그 홍수를 멈춘다.

포트 책임 매트릭스

항목	staging	프로덕션
TCP 포트	8787	8788
설정 루트	~/.openclaw-staging	~/.openclaw-prod
LaunchAgent	…staging	…prod
키 로테이션	주간 가능	변경 창에 맞춰 월간 등
doctor	머지 전 필수	태그 후 필수

리버스 프록시·루프백 함정

nginx나Caddy로 TLS를 종료하고 루프백으로 넘기는 구성에서는 게이트웨이를 127.0.0.1에 고정하고 불필요한 0.0.0.0 바인드를 피한다. 유휴 타임아웃은 staging과 프로덕션 간 5% 이내로 맞추지 않으면 재현성이 무너진다. security find-identity -v -p codesigning 스크린샷으로 서명 자료가 섞이지 않았음을 보여 준다.

장애 시 killall node만 치면 launchd 밖의 제3 프로세스가 남는다. 반드시 bootout과 포트 해제 순서를 Runbook에 고정한다.

체크리스트

1. 디렉터리 생성·chmod 700·ls -le로 ACL 확인.
2. lsof로 8787/8788이 비어 있는지 확인.
3. plist diff는 Label·경로·포트·환경 변수 외 금지.
4. 각 루트에서 doctor 실행 후 티켓에 로그 첨부.
5. staging을 먼저 기동하고 127.0.0.1:8787에 3회 연속 200(간격 2초).
6. 프로덕션 bootstrap 후 8788에서 동일 확인.
7. plist SHA-256을 변경 관리에 등록.
8. 롤백(프로덕션 bootout→staging 단독)을 문서화.

FAQ

설정 파일만 나누면 되나요?

sqlite·캐시 충돌이 남습니다. 디렉터리 단위 분리가 필요합니다.

공용 도메인 하나뿐입니다

SNI나 경로로 두 루프백 포트로 분기합니다.

보안 감사에 무엇을 제출하나요?

서로 다른 Label·로그·API 키·타임스탬프가 찍힌 doctor 출력.

Apple Silicon Mac mini는 두 개의 Node 게이트웨이와 log stream을 동시에 돌려도 저소음이라 책상 검증에 적합하다. MacHTML 클라우드 미니는 SSH와 선택적 VNC를 함께 쓸 수 있어 plist를 두 사람이 맞춰 볼 때 노트북을 우편으로 보낼 필요가 없다. 시험이 끝나면 인스턴스를 중지하고 달력 일 단위 요금만 지불한다——OpenClaw 같은 단기 프로필 검증과 잘 맞는다.

staging은 자주 깨져도 되고 프로덕션은 지루해야 한다. 렌탈 macOS는 그 “자주”와 “지루함”을 같은 금속 위에서 양립시키는 현실적인 해법이다.