2026년 macOS Sequoia에서 openrsync가 도입된 이유와 원격 빌드 동기화 영향
Apple은 macOS Sequoia에서 오랫동안 쓰이던 rsync를 openrsync로 교체했다. 주된 이유는 GPLv3 라이선스 정책과의 관계다. 시스템에 포함된 rsync 2.6.9는 오래되었고, 새 버전 rsync 3.x는 GPLv3이므로 Apple은 BSD 라이선스의 openrsync를 도입해 배포 제약을 피했다. 개발자 입장에서는 openrsync가 더 가볍고 성능도 개선되었지만, 원격 데몬 모드(rsync daemon)·ACL·일부 권한 동기화 동작은 rsync 3.x와 다르다. 파이프라인이 이 기능들에 의존한다면 Homebrew의 rsync 3.x를 계속 쓸지, openrsync의 기능 범위에 맞춰 스크립트를 조정할지 미리 검토해야 한다.
원격 빌드 동기화에서는 주로 세 가지가 영향을 준다. 증분 검사와 delta 전송의 호환성, 대상 쪽 권한·타임스탬프 유지 정도, 기존 CI(GitHub Actions, Jenkins 등)의 rsync 명령과의 호환성이다. “로컬에서 원격 디렉터리로만 동기화”하는 수준이라면 openrsync로도 충분한 경우가 많다. 데몬 모드·복잡한 ACL·다중 노드 동기화가 필요하면 여전히 전체 버전 rsync 사용을 권한다.
rsync와 openrsync 기능 비교표: 권한·ACL·원격 데몬 차이
원격 빌드 동기화에서 자주 쓰는 기능 기준으로 시스템 openrsync와 Homebrew rsync 3.x를 비교했다.
| 기능 | 시스템 openrsync (Sequoia) | Homebrew rsync 3.x | 빌드 동기화 영향 |
|---|---|---|---|
| 증분 / delta 전송 | 지원 | 지원 | 둘 다 증분 동기화 가능, 차이 적음 |
| 원격 daemon 모드 | 제한 또는 동작 차이 | 완전 지원 | CI에서 rsync://로 산출물 가져오면 Homebrew rsync 권장 |
| ACL / 확장 속성 | 일부 지원 | 완전 지원 | 권한을 엄격히 유지하려면 rsync 3.x 선택 |
| --fake-super | 로드맵 예정 (openrsync) | 지원 | root가 아닌데 full permissions 유지할 때 필요 |
| 유지보수·업데이트 | OS 업데이트에 따름 | brew upgrade rsync | 장기적으로는 Homebrew가 더 유연 |
정리하면, “로컬 또는 CI에서 원격 Mac 디렉터리로의 증분 푸시”만 하고 데몬·복잡한 ACL에 의존하지 않는다면 시스템 openrsync를 먼저 시도해도 된다. 그렇지 않다면 빌드 노드에서 brew install rsync를 통일하고 /opt/homebrew/opt/rsync/bin/rsync를 명시하거나 PATH에서 우선하게 해 시스템 openrsync와 섞이지 않게 하자.
원격 Mac에서 빌드 산출물 동기화 권장 구성 (Homebrew rsync / Docker rsync / SFTP)
흔한 세 가지 방식과 각각의 적용 상황·주의점을 정리한다.
- Homebrew rsync: 원격 Mac에서
brew install rsync를 실행하고, CI나 로컬에서 SSH로 해당 rsync를 호출한다. SSH 접근을 표준화했고 rsync 전체 기능을 유지하고 싶은 팀에 적합하다. PATH에서 Homebrew 쪽을 우선하고 시스템 openrsync와 섞이지 않게 한다. - Docker rsync: 원격 Mac에서 컨테이너로 rsync 3.x를 돌려 버전과 동작을 고정한다. 다중 노드·다중 OS가 섞인 환경에 맞지만, 이미지와 네트워크 관리가 필요해 복잡해질 수 있다.
- SFTP 게이트웨이 + 디렉터리 분리: rsync 데몬에 의존하지 않고 SFTP로 빌드 산출물을 업로드·다운로드하며, 디렉터리 권한과 감사를 엄격히 한다. 권한 경계·감사·다중 역할 배포를 중시하는 팀에 적합하다. 증분 동기화도 필요하면 SFTP로 접근을 제어한 뒤 “허용 디렉터리” 안에서 rsync over SSH를 쓰는 구성이 현실적이다.
실제로는 “SFTP로 접근·권한을 담당하고, rsync로 대량 증분 동기화”하는 하이브리드 구성을 쓰는 팀이 많다. SFTP로 허가된 계정만 지정 디렉터리에 접근하고, 그 안에서 rsync가 효율적인 증분 전송을 담당하는 식으로 보안과 효율을 함께 맞출 수 있다.
ENOSPC·ECONNREFUSED 등 자주 나오는 동기화 실패 확인 및 대처
5단계 확인 흐름과 대응 방향을 제시한다.
# 1. 사용 중인 rsync 경로 확인 (openrsync와 혼용 방지)
which rsync
/opt/homebrew/bin/rsync --version
# 2. SSH와 대상 디스크 공간 확인 (ENOSPC 방지)
ssh user@remote-mac "df -h /path/to/dest"
ssh user@remote-mac "df -i /path/to/dest" # inode 고갈 여부
# 3. 대상이 리스닝 중인지 확인 (ECONNREFUSED 방지)
# rsync 데몬 사용 시: netstat -an | grep 873
# rsync over SSH 사용 시: sshd 동작·방화벽 22번 허용 여부
# 4. 드라이런으로 전송 대상 확인
rsync -avzn --delete ./build/ user@remote-mac:/path/to/dest/
# 5. 실제 실행 및 로그 저장
rsync -avz --delete ./build/ user@remote-mac:/path/to/dest/ 2>&1 | tee rsync.log
ENOSPC: 대상 디스크 또는 inode가 가득 찼다. 대상 정리·구 산출물 아카이브·용량 확장을 한다. 필요하면 CI에 “동기화 전 디스크 공간 확인” 단계를 넣는다.
ECONNREFUSED: 상대가 리스닝 중이 아니거나 방화벽에 막혀 있다. SSH라면 sshd와 22번 포트를 확인하고, rsync 데몬이라면 873번과 rsyncd.conf를 확인한다.
Permission denied / 권한 관련: 대상 디렉터리 소유자와 SSH 사용자가 일치하는지, ACL/--fake-super에 의존하는지 확인한다. 권한을 완전히 유지하려면 Homebrew rsync를 우선하고 해당 문서를 참고한다.
선택 체크리스트: 팀 규모·OS 버전에 따라 rsync/openrsync vs SFTP 호스팅
- 단일 머신 또는 단일 노드이고 Sequoia 기본 openrsync로 충분한 경우: 시스템 rsync를 그대로 쓰고, 스크립트에서는 데몬·복잡한 ACL에 의존하지 않도록 한다.
- 다중 노드 CI에서 데몬 또는 엄격한 권한이 필요한 경우: 각 노드에 Homebrew rsync를 설치하고 그 경로를 고정해 사용한다.
- 권한 경계·감사·다중 역할 배포를 중시하는 경우: SFTP 게이트웨이와 디렉터리 분리를 도입하고, 필요 시 허용 디렉터리 안에서 rsync over SSH를 병행한다.
- 단일 머신·rsync 버전 의존을 줄이고 싶은 경우: 빌드 산출물 호스팅을 SFTP를 제공하는 원격 Mac 호스팅에 맡기고, 가용성과 권한 정책을 서비스 측에서 보장하며 로컬·CI는 업로드·다운로드·검증에만 집중하는 구성을 검토한다.
rsync와 openrsync는 “디렉터리 단위 증분 동기화”라면 대부분 잘 동작한다. 체감을 좌우하는 건 버전 통일·경로 일관성·장애 시 빠른 추적이다. 팀이 커지고 규정·감사 요구가 높아지면 rsync만으로는 부족하고, SFTP 같은 명확한 접근 계층과 안정된 원격 환경이 필요해진다.
macOS Sequoia에서 시스템 기본 rsync가 openrsync로 바뀐 이유는?
GPLv3 라이선스와 Apple 정책이 맞지 않아 Apple은 macOS Sequoia에서 기존 rsync를 BSD 라이선스의 openrsync로 교체했습니다. openrsync는 경량화되고 성능도 개선되었지만, 원격 데몬 모드·ACL·일부 권한 동기화에서 rsync 3.x와 동작이 다르므로 원격 빌드 동기화 시 호환성에 주의가 필요합니다.
원격 Mac 빌드 산출물 동기화에는 rsync와 SFTP 중 어떤 것이 적합한가?
팀에서 rsync를 통일해 쓰고 있고 증분·체크섬이 필요하다면 Homebrew의 rsync 3.x를 계속 사용할 수 있습니다. 권한 경계·감사·다중 역할 배포를 중시한다면 SFTP 게이트웨이와 디렉터리 분리가 운영하기 쉬운 경우가 많습니다. 둘을 병행할 수도 있으며, SFTP로 접근 제어와 권한을 담당하고 rsync로 대량 증분 동기화를 하는 구성이 자주 쓰입니다.
동기화 시 ENOSPC 또는 ECONNREFUSED가 나올 때 확인 절차는?
ENOSPC는 대상 디스크 또는 inode가 가득 찼음을 의미합니다. 대상 정리·아카이브·용량 확장을 하세요.ECONNREFUSED는 상대측 서비스가 리스닝 중이 아니거나 방화벽에 막혀 있는 상태입니다. sshd·rsync 데몬·SFTP 포트가 열려 있는지, 로컬과 원격 Mac의 네트워크·방화벽 설정을 확인하세요.
자체 Mac이나 CI 노드에서 rsync/openrsync 버전 관리와 네트워크·디스크 장애 대응에 시간을 쓰기보다, 비즈니스 결과에 집중하고 싶다면 빌드 산출물 동기화와 권한 제어를 원격 Mac 호스팅에 맡기는 선택이 있다. SFTPMAC은 안정적인 SFTP와 디렉터리 분리를 제공하며 rsync over SSH 증분 동기화에도 대응한다. 노드 가용성과 권한 정책은 우리가 보장하므로, 당신은 빌드와 배포에만 집중하면 된다.