많은 팀이 Windows 데스크톱에서 WSL2로 Linux에 가까운 도구를 쓰고, 빌드와 서명은 MacCloud의 실제 Mac에 맡깁니다. OpenClaw를 WSL 안에서 돌릴 때 고통스러운 부분은 종종 애플리케이션 코드가 아니라 경로 상호운용, 줄바꿈, 네트워크 스택입니다.
1. 배포판과 커널
Ubuntu 22.04 / 24.04 LTS를 권장하고 먼저 sudo apt update && sudo apt upgrade를 실행하세요. WSL2 커널을 비교적 최신으로 유지하세요. 오래된 커널은 가상 NIC에서 끊김이나 DNS 타임아웃을 더 자주 일으킵니다.
2. 저장소 위치: ~/ vs /mnt/c
저장소는 WSL 네이티브 파일 시스템(예: ~/projects)에 두고 /mnt/c는 피하세요. I/O와 파일 감시가 훨씬 낫습니다. Windows 쪽을 읽어야 하면 크로스 마운트에서 권한 비트와 실행 플래그가 달라질 수 있으므로 chmod +x 의미에 과도하게 의존하지 마세요.
3. MacCloud로 SSH
WSL 안에서 별도의 SSH 키를 만들고 공개 키를 클라우드 Mac의 authorized_keys에 넣으세요. VS Code Remote는 Windows와 WSL에 확장과 키 경로를 따로 구성해 「키가 있는데 확장이 못 찾는」 상황을 줄입니다.
4. DNS, VPN, 사내 네트워크
해석이 불안정하면 WSL DNS 정책과 resolv.conf 덮어쓰기를 확인하세요. 사내 VPN과 함께 쓸 때는 호스트에서 스플릿 터널링 등으로 안정적인 라우팅을 만들고 WSL이 이어받게 하세요. 「집에서는 된다」만으로 결론 내리지 마세요.
5. Linux / macOS 문서와의 관계
WSL은 Linux 쪽에 가깝습니다. 서비스 호스팅은 Linux 배포를, GUI나 Xcode 관련 단계는 Mac에서 하고 macOS 설치와 MacCloud 실무를 읽으세요.
6. 자가 점검
- 현재 셸에서
pwd가 WSL 네이티브 디스크인가요? ssh -v로 MacCloud에 예상한 키가 쓰이나요?- VPN 켜기/끄기 전후로
ping/curl을 비교했나요?
WSL을 오케스트레이션·스크립트 쪽, MacCloud를 실제 빌드 쪽으로 경계를 긋면 디버깅이 빨라집니다.
