복사 전에 바뀔 파일만 먼저 확인하기

2026년 5월 29일 | 개발 깨알 상식_Tips

---

동기화를 실행하기 전에 어떤 파일이 바뀌는지 먼저 확인해 실수를 줄이는 흐름.

rsync로 폴더를 맞출 때 가장 위험한 순간은 실제 복사 명령을 실행하기 직전이다. 파일 몇 개만 옮기는 줄 알았는데 삭제 후보가 섞여 있거나, 경로 끝의 슬래시 하나 때문에 디렉터리 구조가 한 단계 더 들어가는 일이 생긴다. 나는 이런 작업에서는 거의 습관처럼 --dry-run과 --itemize-changes를 먼저 붙인다. 복사 자체보다 “무엇이 바뀔지”를 먼저 읽는 쪽이 훨씬 덜 불안하다.

먼저 실행하지 말고 먼저 보여 달라고 하기

기본 형태는 단순하다. -a는 보통의 archive 복사, -n은 실제 변경 없이 미리 보기, -i는 바뀔 항목을 줄마다 표시하라는 뜻으로 읽으면 된다.

rsync -ani src/ dst/

여기서 중요한 건 출력이 “예쁜 로그”가 아니라는 점이다. 이 출력은 곧 실행 계획에 가깝다. 새로 만들어질 파일, 내용이 달라질 파일, 시간만 달라진 파일, 삭제될 항목을 미리 보여 준다. 그래서 나는 배포 전 파일 동기화나 백업 정리처럼 되돌리기 귀찮은 작업에서는 곧바로 rsync -a를 치지 않는다. 먼저 rsync -ani로 변화 목록을 보고, 그 목록이 내 머릿속 작업 범위와 맞는지 확인한다.

출력 앞글자를 대충이라도 읽기

--itemize-changes 출력은 처음 보면 암호처럼 보인다. 예를 들어 >f.st...... app.log 같은 줄이 나온다. 앞의 >는 파일이 대상 쪽으로 전송될 수 있다는 뜻이고, f는 파일을 가리킨다. 뒤쪽 문자들은 크기, 시간, 권한, 소유자 같은 속성 차이를 압축해서 보여 준다. 모든 칸을 외울 필요는 없지만, 최소한 파일이 새로 가는지, 내용이 바뀌는지, 메타데이터만 바뀌는지는 구분해야 한다.

특히 삭제 옵션을 붙인 경우에는 더 조심한다.

rsync -ani --delete build/ deploy/

--delete는 원본에 없는 대상 파일을 지우겠다는 뜻이다. dry-run 없이 바로 쓰면, 내가 대상 폴더에 수동으로 남겨 둔 파일까지 정리될 수 있다. 반대로 dry-run 출력에서 삭제 후보가 보이면 “아, rsync가 이렇게 이해했구나”를 먼저 알 수 있다. 이 한 단계가 실제 사고를 꽤 많이 막아 준다.

슬래시 하나를 검증 대상으로 보기

rsync에서 src/와 src는 느낌이 다르다. src/는 대체로 src 안의 내용을 목적지로 맞추는 쪽이고, src는 src 디렉터리 자체를 목적지 아래에 만들 수 있다. 이 차이는 문서로 한 번 읽을 때보다, dry-run 출력으로 직접 보는 편이 훨씬 빨리 몸에 들어온다.

rsync -ani src/ dst/
rsync -ani src dst/

두 명령의 출력 경로가 어떻게 다른지 보면, 내가 지금 “내용을 맞추려는지” 아니면 “폴더를 하나 더 복사하려는지”가 드러난다. 작은 차이지만 배포 폴더나 정적 파일 경로에서는 결과가 크게 달라진다. 그래서 경로 끝 슬래시는 기억으로 처리하지 않고, dry-run 결과의 경로 모양으로 확인하는 편이 안전하다.

필터와 삭제를 같이 쓸 때

exclude 규칙이 들어가면 더 헷갈린다. 예를 들어 캐시와 임시 파일을 빼고 동기화하려면 이런 식으로 쓸 수 있다.

rsync -ani --delete --exclude-from rsync-exclude.txt src/ dst/

이때 내가 보는 것은 단순히 “에러가 안 났나”가 아니다. 제외해야 할 파일이 출력에 남아 있는지, 삭제되면 안 되는 파일이 삭제 후보로 잡혔는지, 예상보다 많은 디렉터리가 한꺼번에 바뀌는지부터 본다. 출력 줄 수가 너무 많으면 목적지 경로를 더 좁히거나 exclude 파일을 먼저 고친다. dry-run을 했는데도 목록이 읽히지 않을 정도로 크다면, 그 명령은 아직 실제 실행할 준비가 덜 된 상태라고 보는 편이다.

미리 보기 로그도 남겨 두기

한 번만 확인하고 끝나는 복사라면 화면 출력만 봐도 된다. 하지만 배포 서버, 연구 결과물 폴더, 모델 체크포인트처럼 나중에 “그때 무엇을 옮겼지?”를 다시 물을 가능성이 있으면 dry-run 출력 자체도 파일로 남기는 편이 좋다.

rsync -ani --delete src/ deploy/ | tee rsync.plan.log

이 로그는 실제 복사 로그와 역할이 다르다. 실제 로그가 “무엇을 했다”의 기록이라면, dry-run 로그는 “무엇을 하려고 했는지”의 기록이다. 둘을 나눠 두면 나중에 파일이 사라졌을 때도 판단이 조금 쉬워진다. 계획에는 삭제 후보가 있었는데 실제 명령에서 빠졌는지, 아니면 계획에는 없던 경로가 실제 실행에서 새로 들어왔는지 비교할 수 있기 때문이다.

원격 서버를 대상으로 할 때도 이 습관이 꽤 유용하다. 네트워크 경로나 권한 문제 때문에 실제 전송 전에 실패할 수도 있지만, 적어도 rsync가 해석한 source와 destination의 모양은 먼저 볼 수 있다. 나는 특히 --delete, --exclude, 원격 경로, trailing slash가 한 명령에 같이 들어가면 dry-run 로그를 남긴다. 네 요소가 섞이면 머릿속 검산만으로는 놓치는 줄이 생기기 쉽다.

내가 쓰는 실행 순서

• 1단계: rsync -ani ...로 변화 목록만 본다.
• 2단계: 삭제 후보와 경로 모양을 먼저 확인한다.
• 3단계: 출력이 너무 넓으면 source, destination, exclude 규칙을 다시 줄인다.
• 4단계: 같은 명령에서 -n만 빼고 실제 실행한다.
• 5단계: 실제 실행 로그와 dry-run 로그가 크게 달라졌는지 확인하고, 차이가 크면 즉시 멈춰 원인을 다시 본다. 무시하지 않는다.

실제 실행으로 넘어가기 전에는 명령을 새로 치기보다, 방금 확인한 명령에서 -n만 빼는 쪽을 선호한다. 옵션을 다시 조립하면 dry-run에서 확인한 것과 실제 실행한 것이 달라질 수 있다. 긴 명령이라면 셸 히스토리에서 바로 불러와 -n만 지우고, 목적지 경로와 --delete 유무를 한 번 더 본다. 같은 줄을 거의 그대로 실행했다는 확신이 있어야 나중에 로그를 다시 볼 때도 덜 헷갈린다.

이 순서를 지키면 rsync가 마법처럼 안전해지는 건 아니다. 그래도 실수의 위치가 실행 뒤에서 실행 앞으로 옮겨 온다. 복사 명령은 성공했는데 목적지가 이상해진 뒤에야 알아차리는 것보다, dry-run 출력에서 낯선 경로 한 줄을 발견하는 편이 훨씬 싸다. 나한테 --dry-run --itemize-changes 조합은 rsync 옵션 암기라기보다, 파일 동기화 전에 작업 반경을 눈으로 고정하는 작은 안전장치에 가깝다.