Advanced Renamer 사용기 파일명 일괄 변경 정리

파일 이름 때문에 일이 자꾸 끊길 때

업무 파일을 많이 다루다 보면 이름 정리가 은근히 시간을 잡아먹는다. 보고서 초안, 수정본, 최종본, 전달본이 섞이기 시작하면 검색보다 눈으로 훑는 시간이 더 길어질 때가 있다. 특히 사진, 녹음 파일, 스캔 문서처럼 생성 시점은 다르지만 폴더 하나에 몰아넣는 자료는 더 그렇다.

처음에는 윈도우 탐색기에서 F2로 몇 개씩 바꾸는 식으로 버텼다. 10개 정도면 할 만했지만 120개를 넘기면 얘기가 달라진다. 번호를 붙이면서 중간에 하나라도 빠뜨리면 뒤가 전부 어긋나고, 날짜 형식을 2026-03-28로 맞추려다가 어떤 파일은 20260328로 남는 식의 실수가 생겼다.

문제는 단순히 귀찮다는 데 있지 않았다. 파일명이 들쭉날쭉하면 정렬이 틀어지고, 공유할 때도 상대가 내용을 파악하기 어렵다. 이름을 잘 붙이는 일은 정리 습관의 문제처럼 보이지만, 실제로는 검색 속도와 재작업 비용에 바로 연결된다.

먼저 해본 방법과 왜 오래 못 갔는지

가장 먼저 쓴 건 탐색기의 기본 이름 바꾸기 기능이었다. 여러 파일을 선택하고 한 번에 이름을 바꾸면 회의자료 (1), 회의자료 (2) 식으로 붙는다. 급할 때는 쓸 만하지만, 파일명 안에 날짜나 부서명, 버전 규칙을 넣으려면 손을 더 대야 한다. 폴더가 두 개만 넘어가도 다시 수작업으로 돌아간다.

그다음엔 PowerToys의 PowerRename도 써봤다. 문자열 치환 중심으로는 꽤 괜찮았다. 예를 들어 IMG_현장촬영_으로 바꾸거나, 공백을 밑줄로 바꾸는 정도는 빠르게 끝난다. 다만 사진의 EXIF 날짜를 읽어 2025-11-03_회의실A_001.jpg처럼 만들고 싶을 때는 한계가 분명했다.

한 번은 MP3 86개 제목을 정리하려고 태그 편집기와 탐색기를 번갈아 썼다. ID3 태그에서 곡명은 보이는데 파일명으로 그대로 옮기는 과정이 끊겨 있었다. 복사해서 붙여넣는 식으로 몇 개 해보니 오타가 나고, 괄호와 대시 위치도 제각각이라 중간에 포기했다. 여기서 느낀 불편은 명확했다. 내가 원하는 건 일괄 변경이 아니라 규칙 기반 정리였다.

Advanced Renamer를 고른 이유

필요했던 조건은 세 가지였다. 첫째, 미리보기로 결과를 확인할 수 있어야 한다. 둘째, 단순 치환이 아니라 날짜, 메타데이터, 번호를 조합할 수 있어야 한다. 셋째, 한글 파일명과 긴 경로에서 문제를 일으키지 않아야 했다.

Advanced Renamer는 처음 실행하면 다소 빽빽해 보인다. 왼쪽에는 파일 목록이 있고, 오른쪽에는 Add Method로 규칙을 쌓는 구조다. 처음엔 복잡해 보이지만 오히려 이 점이 실무용에 가깝다. 이름 바꾸기 규칙을 하나씩 분리해서 넣을 수 있어, 어디서 결과가 틀어졌는지 추적하기 쉽다.

선택한 결정적 이유는 태그 기반 조합이었다. {num}, {date}, {year}, {camera} 같은 값을 섞어 파일명을 만들 수 있고, 사진은 EXIF, 음악은 ID3 같은 메타데이터를 바로 읽어온다. 이름을 사람이 직접 짓는 게 아니라 파일 안의 정보를 끌어와 구조를 만드는 방식이라 반복 작업이 눈에 띄게 줄었다.

사진 파일 350장 정리한 과정

가장 체감이 컸던 건 촬영본 정리였다. 행사 사진 JPG 350장과 PNG 캡처 42장이 한 폴더에 섞여 있었고, 원래 이름은 DSC_, IMG_, Screenshot_가 뒤섞인 상태였다. 목적은 촬영 날짜와 일련번호를 붙여 나중에 전달용 ZIP을 만들 때 정렬이 바로 되게 하는 것이었다.

진행 순서는 단순했다. 파일을 목록에 넣고, 오른쪽에서 Add Method > New Name을 추가했다. 그다음 이름 형식을 {Image Date Taken}_{Num 3} 형태로 잡고, 필요하면 접두어로 프로젝트명을 앞에 붙였다. 미리보기에서 2026-03-12_001.jpg처럼 보이는지 먼저 확인한 뒤 실행했다.

여기서 중요한 건 한 번에 끝내려 하지 않는 것이다. 먼저 날짜 형식만 맞추고, 두 번째 메서드로 불필요한 공백을 제거하고, 세 번째 메서드로 번호 자릿수를 3으로 맞추는 식이 더 안전했다. 규칙을 한 줄에 몰아넣으면 수정할 때 헷갈리는데, 메서드를 나누면 원인과 결과가 분리된다.

실행 시간도 확인해봤다. JPG와 PNG 합쳐 392개를 처리하는 데 체감상 10초 남짓 걸렸고, 미리보기 검토 시간까지 포함해도 3분 안쪽이었다. 예전처럼 수작업으로 했다면 최소 30분은 잡았을 일이다. 더 중요한 건 파일명 패턴이 완전히 통일돼서, 압축 후 상대방에게 보내도 정렬 기준이 흔들리지 않았다는 점이다.

음악과 문서 파일은 접근 방식이 조금 달랐다

음악 파일은 사진보다 단순하지 않았다. MP3 86개에 ID3 태그가 어느 정도 들어 있었지만, 일부는 트랙 번호가 비어 있고 일부는 제목 앞에 불필요한 사이트명이 붙어 있었다. 여기서는 한 번에 새 이름을 만들기보다 정리 순서를 나누는 게 맞았다.

먼저 Add Method > Replace로 제목 앞 불필요한 문자열을 제거했다. 다음으로 Add Method > New Name에서 트랙 번호와 제목을 조합해 {track} - {title} 형식으로 맞췄다. 빈 트랙이 있는 파일은 미리보기에서 바로 드러나서, 실행 전에 그 파일만 제외하고 태그를 보완한 뒤 다시 넣었다.

문서 파일은 또 다르게 접근했다. PDF 58개와 DOCX 14개를 프로젝트 폴더로 넘길 때는 생성일보다 문서 성격이 중요했다. 그래서 보고서, 계약, 회의록 같은 접두어를 수동으로 붙일지 고민했는데, 결국 폴더별로 나눠 넣고 Insert 메서드로 앞부분에 분류명을 삽입했다. 이 방식은 자동화 수준은 조금 떨어지지만, 규칙이 명확한 환경에서는 오히려 실수를 줄여준다.

같은 프로그램이라도 파일 종류에 따라 해법이 달라진다는 점은 기억할 만하다. 사진은 메타데이터 중심, 음악은 태그 정리 후 조합, 문서는 폴더 단위 분류와 접두어 삽입이 더 잘 맞았다. 한 가지 방식으로 전부 밀어붙이면 중간에 예외가 쌓인다.

대안과 비교해보면 어디까지 필요한가

PowerRename은 윈도우 사용자라면 가장 가볍게 시도할 수 있는 대안이다. 문자열 교체, 패턴 수정, 확장자 유지 같은 기본 작업에서는 충분히 빠르다. 다만 메타데이터를 읽어 규칙을 세우는 작업에는 깊이가 부족하다. 파일명 안 텍스트를 고치는 데는 적합하지만, 파일 정보를 기반으로 새 구조를 만드는 쪽은 아쉽다.

Bulk Rename Utility도 비교 대상에 자주 올라온다. 기능은 많고 세밀하지만 화면 구성이 꽤 공격적이다. 항목이 많아 익숙해지면 강력한데, 처음 쓰는 사람은 어디를 건드렸는지 파악하기 어렵다. 반면 Advanced Renamer는 복잡하긴 해도 메서드를 쌓는 방식이라 논리가 비교적 선명하다.

선택 기준은 분명하다. 단순 치환과 빠른 수정이 목적이면 PowerRename이 부담이 적다. 정기적으로 사진, 음악, 스캔 자료를 묶어서 정리하고, 날짜나 태그를 파일명 규칙에 넣어야 한다면 Advanced Renamer 쪽이 낫다. 기능 수가 많다고 무조건 좋은 건 아니고, 내가 반복하는 작업이 문자열 교체인지 정보 기반 재구성인지부터 구분하는 게 먼저다.

쓰다 보니 보인 한계와 추천할 사람

아쉬운 점도 있다. 처음 열었을 때 메뉴와 옵션이 친절한 편은 아니다. Add Method를 여러 개 쌓기 시작하면 무엇이 최종 결과에 영향을 주는지 감이 오기까지 시간이 필요하다. 간단한 이름 변경만 원하는 사람에게는 인터페이스가 과한 편으로 느껴질 수 있다.

또 하나는 규칙을 잘못 잡으면 대량 변경이 대량 실수로 이어질 수 있다는 점이다. 미리보기가 있어도, 사용자가 메타데이터 필드를 잘못 선택하면 의도와 다른 결과가 나온다. 예를 들어 사진 촬영일 대신 수정일을 가져오면 백업 시점 기준으로 이름이 바뀌어 버린다. 그래서 실행 전 표본 10개 정도는 꼭 눈으로 확인하는 습관이 필요하다.

추천할 사람은 분명하다. 매주 수십 개 이상 파일을 정리하고, JPG, PNG, MP3, PDF처럼 형식이 섞인 자료를 다루며, 파일명 규칙을 한 번 정해 반복 적용하고 싶은 사람이다. 반대로 한 달에 한두 번 폴더 정리하는 수준이거나, 문서(1) 정도만 붙이면 충분한 사람이라면 여기까지 갈 필요는 없다. 내가 다시 선택하겠냐고 묻는다면, 메타데이터를 써야 하는 작업에서는 그렇다. 대신 아주 가벼운 이름 변경만 할 때는 예전처럼 PowerRename으로 끝낼 가능성이 높다.

댓글 남기기