Claude Code 전용 맥, 에이전트 격리의 현실

예비 맥이 에이전트 샌드박스가 된다

ykdojo의 가이드는 남는 맥을 Claude Code가 제어하는 항상 켜진 머신으로 설정하는 절차를 설명한다. 핵심은 새 로컬 계정, Apple ID 미사용, SSH 접속, 비밀번호 없는 sudo, 화면 공유와 컴퓨터 사용 권한이다. 저장소 버전은 GitHub repo에 공개돼 있다.

이 글이 주목받은 이유는 단순한 팁이 아니라 에이전트 운용의 현실을 드러내기 때문이다. --dangerously-skip-permissions처럼 강한 권한을 주면 에이전트는 훨씬 유능해지지만, 주 머신의 개인 파일과 인증 토큰까지 닿을 수 있다. 그래서 Guardian Angels 개인화 LLM 보안과 같은 흐름에서 보듯, 개인 AI의 경쟁력은 기억과 권한을 어떻게 나누느냐에 달려 있다.

컨테이너만으로 부족한 이유

개발자는 보통 Docker나 VM을 떠올린다. 그러나 GUI 앱, Unity 같은 macOS 앱, 브라우저 로그인, 파일 드래그, 화면 클릭이 필요한 작업은 컨테이너로 처리하기 어렵다. 가이드가 예비 맥을 고른 이유도 이 지점이다. 물리적으로 분리된 장치라면 네트워크, 파일, 앱 권한을 주 머신과 다르게 설계할 수 있다.

Anthropic Claude Code 문서, Apple 원격 로그인 안내, OpenSSH 매뉴얼, Apple 화면 공유 문서를 함께 보면 이 구성은 낯선 해킹이 아니라 기존 원격 관리 기능을 AI 에이전트에 맞게 재조합한 형태다.

권한 설계가 생산성 설계다

에이전트는 권한이 넓을수록 덜 귀찮다. 매번 확인을 요구하지 않으면 빌드 설치, 앱 실행, 파일 이동을 빠르게 끝낸다. 그러나 같은 이유로 피해도 커진다. 비밀번호 없는 sudo는 편리하지만, 실수나 프롬프트 인젝션이 시스템 변경으로 이어질 수 있다. 따라서 이 설정의 핵심은 "위험한 옵션을 써도 된다"가 아니라 "위험한 옵션을 잃을 것이 없는 계정과 장치 안에 가둔다"다.

ReasonGate 프롬프트 방화벽과 VulnHunter 보안 에이전트가 보여준 흐름도 같다. 에이전트 보안은 모델에게 조심하라고 말하는 문제가 아니라 실행 경계, 권한 경계, 감사 로그의 문제다. 개인 개발자에게는 예비 맥이 가장 이해하기 쉬운 경계가 될 수 있다.

한국 개발자와 기업의 적용법

개인 개발자는 오래된 맥북이나 미니 PC를 에이전트 작업대로 만들 수 있다. 다만 업무 계정, 메신저, 클라우드 드라이브, SSH 키를 그대로 복사하지 말아야 한다. 테스트용 GitHub 계정, 제한된 저장소 권한, 별도 브라우저 프로필, 로컬 네트워크 방화벽을 두는 것이 좋다. 에이전트가 실패해도 다시 밀 수 있는 이미지나 초기화 절차도 필요하다.

기업은 더 엄격해야 한다. 예비 맥 방식은 실험실에는 좋지만, 대규모 도입에서는 MDM, 감사 로그, 비밀 관리, 네트워크 세그먼트가 붙어야 한다. 에이전트 시대 API 설계처럼 권한은 암묵적 편의가 아니라 계약으로 표현돼야 한다. 어떤 파일을 읽을 수 있고, 어떤 명령은 승인 필요하며, 어떤 로그가 남는지 명확해야 한다.

자주 묻는 질문

Q1: 왜 굳이 예비 맥이 필요한가요?

A: GUI 앱과 macOS 전용 도구를 제어하면서도 주 머신의 개인 데이터와 인증 정보를 분리할 수 있기 때문이다.

Q2: 컨테이너보다 안전한가요?

A: 목적이 다르다. 컨테이너는 CLI 작업에 좋고, 예비 맥은 GUI와 물리적 격리에 좋다. 둘을 함께 쓰는 방식도 가능하다.

Q3: 비밀번호 없는 sudo는 위험하지 않나요?

A: 위험하다. 그래서 개인 데이터가 없는 별도 계정과 장치에서만 제한적으로 써야 한다. 업무 환경에서는 감사와 승인 절차가 필요하다.

Q4: 휴대폰에서 제어하는 것이 왜 중요하죠?

A: 장시간 실행되는 에이전트 업무를 이동 중에도 확인하고 지시할 수 있다. 다만 편의성만큼 오작동 감시도 중요해진다.

Q5: 회사에서 바로 도입해도 되나요?

A: 바로 운영 환경에 쓰기보다 실험실 환경에서 권한, 로그, 초기화 절차를 검증한 뒤 MDM과 보안 정책에 맞춰 확장해야 한다.