OpenBSD 팀이 만든 openrsync, 왜 지금 다시 볼 만한가
rsync는 인프라 하는 사람이라면 거의 무의식적으로 손이 가는 도구다. 백업, 배포, 서버 간 파일 동기화, 심지어 S3 마이그레이션 전 단계까지. 그런데 오늘 HN 상단(426점)과 GeekNews에 동시에 openrsync가 올라왔다. "또 rsync 클론인가" 싶겠지만, 이건 OpenBSD 팀이 base에 통합해서 굴리고 있는 물건이라 결이 다르다. 실무에서 한 번쯤 짚고 넘어갈 가치가 있어서 정리한다.
왜 지금 openrsync인가
기존 rsync(우리가 흔히 쓰는 그것, tridge가 만든)는 오래되고 검증됐지만 GPLv3 라이선스다. 코드 베이스도 20년 넘게 쌓이면서 복잡해졌고, 과거 여러 CVE도 있었다. 파일 동기화 프로토콜을 다루는 도구가 setuid나 데몬 모드로 돌아갈 때, 코드 복잡성은 그대로 공격 표면이 된다.
openrsync는 OpenBSD 팀이 이 프로토콜(버전 27 기반)을 ISC 라이선스로 새로 구현한 것이다. ISC는 BSD 계열 퍼미시브 라이선스라, GPL 의무가 부담스러운 상용 제품이나 임베디드 펌웨어에 그냥 끼워 넣을 수 있다. 실제로 Apple이 macOS에서 GPLv3를 피하려고 GPLv2 시절 도구들을 그대로 쓰거나 BSD 대체재로 갈아탄 전력이 있는데, 같은 맥락이다.
정리하면 openrsync가 푸는 문제는 두 가지로 보인다. 첫째 라이선스 자유도, 둘째 작고 감사 가능한(auditable) 코드 베이스. 기능적으로 더 빠르거나 더 많은 걸 하려는 프로젝트가 아니다.
핵심: 무엇이 같고 무엇이 다른가
프로토콜 호환이 핵심이다. openrsync는 rsync 프로토콜 27을 지원하므로, 반대편이 평범한 rsync(테스트엔 3.1.3이 쓰였다고 함)여도 통신이 된다. 즉 한쪽만 openrsync여도 동작할 수 있다.
쓰는 법은 우리가 아는 그대로다.
# 로컬 → 원격 (SSH 경유)
openrsync -av ./build/ user@server:/var/www/app/
# 원격 → 로컬, 삭제 동기화
openrsync -av --delete user@server:/data/ ./backup/비유하자면 rsync가 풀옵션 스위스 군용칼이라면, openrsync는 자주 쓰는 날 몇 개만 남기고 깔끔하게 다시 만든 칼이다. 델타 전송(바뀐 블록만 보내기), -a 아카이브 모드, --delete, SSH 터널링 같은 일상 옵션은 대부분 커버한다.
대신 rsync의 변두리 옵션들 — 예를 들어 --fuzzy, 정교한 필터 룰, 일부 데몬 모드 세부 기능 — 까지 1:1로 다 구현됐다고 보장하긴 어렵다. 이 부분은 반드시 자기 워크플로의 옵션으로 직접 테스트하고 man 페이지로 확인해야 한다.
실무 관점: 도입 시 따져볼 것들
1. 어디서 돌릴 건가. openrsync는 OpenBSD base에 들어있어서 OpenBSD 환경이라면 이미 있거나 기본에 가깝다. 문제는 우리 대부분이 굴리는 리눅스 서버다. 리눅스용 포팅이 진행되긴 했지만 배포판 기본 패키지로 어디까지 들어와 있는지는 환경마다 다르니, apt/dnf로 바로 잡힐 거란 기대는 접고 직접 확인하는 게 맞다. 일부러 빌드해서까지 깔 이유가 있는지 먼저 자문해야 한다.
2. "그냥 rsync 쓰면 되는데"라는 함정. 솔직히 말해 일반적인 백업/배포 파이프라인에서 굳이 rsync를 openrsync로 갈아탈 강한 이유는 없다. 기존 rsync는 잘 동작하고 생태계도 두텁다. openrsync가 빛나는 건 다음 같은 상황이다.
- 제품에 rsync 기능을 번들로 넣어야 하는데 GPLv3가 법무 검토에 걸릴 때
- BSD 계열 시스템이나 임베디드/어플라이언스에서 의존성을 최소화하고 싶을 때
- 코드 감사가 필요한 보안 민감 환경에서 작은 코드 베이스를 선호할 때
3. 옵션 비호환에서 오는 사일런트 실패. 가장 무서운 시나리오. 자동화 스크립트에서 rsync 옵션을 그대로 openrsync에 던졌는데 해당 옵션이 무시되거나 다르게 동작하면, 명령은 성공으로 끝나지만 결과 파일 상태가 의도와 다를 수 있다. 특히 --delete와 필터 규칙이 얽히면 데이터 누락으로 이어진다. 운영 투입 전엔 dry-run으로 검증하는 습관이 필수다.
# 무엇이 전송/삭제될지 먼저 확인
openrsync -avn --delete src/ dst/4. 대안 비교. 단순히 "더 가볍고 빠른 동기화"가 목적이라면 openrsync보다 다른 선택지가 더 맞을 수도 있다. 다수 서버 fan-out 배포라면 설정 관리 도구(Ansible 등)나 오브젝트 스토리지 기반 배포, 대용량 클라우드 동기화라면 rclone이 더 현실적이다. openrsync는 "rsync 프로토콜을 퍼미시브 라이선스로 쓰고 싶다"는 구체적 요구가 있을 때의 답이지, 만능 업그레이드가 아니다.
정리
한 줄 요약: openrsync는 더 빠른 rsync가 아니라, ISC 라이선스로 깔끔하게 다시 쓴 작고 감사 가능한 rsync다.
일상 백업/배포에 이미 rsync를 잘 쓰고 있다면 굳이 바꿀 이유는 없다. 다만 (1) 상용 제품에 rsync를 번들해야 하는데 GPL이 걸리거나, (2) BSD/임베디드 환경에서 의존성과 공격 표면을 줄이고 싶거나, (3) 보안 감사 대상 시스템이라면 진지하게 검토할 만하다. 도입할 땐 반드시 자기 워크플로의 옵션을 dry-run으로 검증하고, 비호환 옵션이 조용히 무시되지 않는지 확인하라.