svn:ignore를 설정했는데 파일이 계속 보인다면, 먼저 그 파일이 이미 저장소에 추가된 상태인지 확인해야 해요. svn:ignore는 아직 버전 관리에 들어가지 않은 항목을 svn status와 svn add에서 걸러 주는 속성이지, 이미 추적 중인 파일의 변경을 숨기는 기능은 아닙니다. 또 무시할 폴더 이름은 그 폴더 자체가 아니라 바로 위 부모 폴더의 속성에 적어야 합니다.
이 글은 명령줄 Subversion과 TortoiseSVN을 함께 쓰는 오래된 프로젝트에서 빌드 결과물, 로그, 임시 폴더가 계속 변경 목록에 나타날 때 적용할 수 있어요. 실제 파일을 지우지 않고 원인을 구분하는 확인 순서부터, 팀과 합의한 뒤 추적을 중단하는 방법까지 차례로 설명합니다.
svn:ignore가 안 먹는 원인은 먼저 두 갈래로 나뉩니다
문제 파일이 미추적 상태라면 ignore 패턴의 위치나 문법을 확인하면 됩니다. 반대로 과거에 한 번이라도 svn add와 커밋을 거쳐 추적 중인 상태라면 ignore를 추가해도 변경 목록에서 사라지지 않아요. 이 차이를 놓치면 같은 속성을 여러 폴더에 반복해서 설정하거나, 필요한 파일을 실수로 삭제하기 쉽습니다.
가장 먼저 작업 복사본의 루트에서 다음 명령을 실행하세요.
svn status
svn info path/to/item
svn status에서 앞에 ?가 붙으면 아직 추적되지 않은 항목입니다. M, A, D처럼 버전 관리 상태 문자가 보이거나 svn info가 저장소 URL과 revision 정보를 반환한다면 이미 추적 중이에요. 이때는 ignore 문법을 고치는 것만으로 해결되지 않습니다.
무시된 항목까지 포함해 현재 판단을 다시 보고 싶다면 svn status --no-ignore를 사용할 수 있습니다. Apache Subversion 공식 설명에서도 --no-ignore를 주면 런타임 설정, svn:ignore, svn:global-ignores에 의해 감춰진 미추적 항목을 다시 표시한다고 안내합니다. 평소 상태 출력에서 사라진 파일이 실제 삭제된 것은 아니라는 뜻이에요.
미추적 폴더라면 속성을 부모 폴더에 설정합니다
예를 들어 작업 복사본이 아래처럼 생겼고 build 폴더 전체를 제외하고 싶다고 해볼게요.
project/
├── src/
├── build/
└── README.md
build를 무시하는 svn:ignore는 project 폴더에 설정합니다. 속성 값에는 보통 전체 경로가 아니라 부모 폴더에서 보이는 항목 이름이나 패턴을 한 줄씩 적어요.
cd project
svn propedit svn:ignore .
편집기가 열리면 기존 내용을 지우지 말고 필요한 패턴을 새 줄에 추가합니다.
build
*.log
*.tmp
간단한 값 하나라면 svn propset svn:ignore build .도 쓸 수 있지만, propset은 기존 속성 값을 새 값으로 바꿀 수 있어요. 이미 여러 패턴을 관리 중인 프로젝트라면 svn propget svn:ignore .로 현재 값을 읽고, svn propedit으로 보존하면서 추가하는 편이 안전합니다.
설정 뒤에는 아래 순서로 확인합니다.
svn propget svn:ignore .
svn status
svn status --no-ignore
첫 명령에서 기대한 패턴이 나오고, 일반 svn status에서는 build가 사라지며, --no-ignore에서는 무시 상태로 다시 보이면 의도대로 적용된 것입니다. 속성 자체도 버전 관리 대상이므로 svn status에는 부모 폴더가 수정된 것으로 나타날 수 있어요. 팀 전체에 같은 규칙을 적용하려면 이 속성 변경을 검토한 뒤 커밋해야 합니다.
하위 경로를 통째로 적었는데 안 되는 이유
svn:ignore는 속성이 설정된 디렉터리의 바로 아래 항목 이름과 패턴을 기준으로 동작합니다. 프로젝트 루트에 trunk/cache를 한 줄로 적는 대신, trunk에 속성을 설정하고 값에는 cache라고 적는 방식이 기본이에요.
svn propset svn:ignore cache trunk
오래된 Subversion 클라이언트를 함께 쓰는 조직에서는 이 규칙이 특히 중요합니다. “루트에서 모든 하위 폴더에 적용되는 한 장의 ignore 파일”처럼 생각하면 원하는 결과가 나오지 않을 수 있어요. Apache Subversion 1.8부터는 상위 디렉터리의 규칙을 하위 트리에 상속하는 svn:global-ignores 속성이 추가됐지만, 팀에 1.7 이하 클라이언트가 남아 있다면 호환성을 먼저 확인해야 합니다.
svn:global-ignores는 저장소 트리 전체에서 반복되는 빌드 산출물이나 편집기 임시 파일을 관리할 때 유용합니다. 공식 문서에 따르면 이 값도 줄바꿈으로 구분한 패턴 목록이며, 속성을 설정한 경로 아래에 상속됩니다. 다만 기존 svn:ignore와 로컬 설정의 패턴을 없애는 것이 아니라 함께 적용된다는 점을 알아두세요.
이미 추적 중인 파일은 ignore로 숨길 수 없습니다
파일이 이미 저장소에 들어갔다면 Subversion은 그 파일의 변경을 계속 관리해야 합니다. 그래야 다른 사람이 수정한 내용과 내 변경을 비교하고, 업데이트와 커밋에서 누락을 막을 수 있기 때문이에요. 이 상태에서 ignore가 변경을 감춰 버리면 버전 관리의 신뢰성이 무너집니다.
따라서 먼저 “이 파일을 저장소에서 정말 제거해도 되는가”를 결정해야 합니다. 빌드 때 자동으로 다시 생기는 결과물이나 개인별 캐시라면 추적 중단 후보가 될 수 있어요. 반면 기본 설정 파일, 데이터베이스 스크립트, 배포에 필요한 라이브러리처럼 다른 작업 복사본에도 반드시 있어야 하는 파일은 그대로 추적하는 편이 맞습니다.
추적을 중단하기로 팀에서 합의했다면 파일을 로컬에 남겨 둔 채 저장소 삭제를 예약하는 --keep-local 옵션을 검토할 수 있습니다.
svn delete --keep-local path/to/generated-folder
svn status
여기서 멈추고 반드시 상태를 확인하세요. 작업 복사본의 파일은 남아 있어도, 다음 커밋에는 저장소에서 해당 경로를 삭제하는 변경이 포함됩니다. 커밋이 완료되면 다른 사람이 업데이트할 때 그 경로가 제거될 수 있으므로, 공유 파일에 이 명령을 성급하게 사용하면 안 됩니다. 필요한 산출물이라면 빌드나 초기화 과정에서 다시 만드는 방법도 함께 문서화해야 해요.
삭제 예약이 의도와 다르다면 커밋하기 전에 svn revert로 되돌릴 수 있습니다. 하지만 경로와 작업 복사본 상태에 따라 로컬 변경 처리 방식이 달라질 수 있으므로, 중요한 파일은 먼저 별도 백업하고 svn status와 diff를 확인하세요. 이 글의 명령을 운영 저장소에 바로 적용하기보다 작은 테스트 작업 복사본에서 같은 구조를 재현하는 편이 안전합니다.
폴더 자체는 유지하고 그 안의 새 파일만 무시할 수도 있습니다
빈 디렉터리 구조는 저장소에 남겨야 하지만 그 안에 실행 중 생성되는 파일은 넣고 싶지 않을 때가 있어요. 이 경우 추적 중인 폴더 자체에 * 패턴을 설정하면 폴더는 유지하면서 새 미추적 자식 항목을 무시할 수 있습니다.
svn propset svn:ignore "*" path/to/runtime-folder
svn status
이 설정도 이미 추적 중인 자식 파일에는 적용되지 않습니다. 또한 셸이나 운영체제에 따라 따옴표 처리 방식이 다를 수 있으니, 실행 후 svn propget svn:ignore path/to/runtime-folder로 값이 별표 한 줄로 저장됐는지 확인하세요. 모든 새 파일을 숨기는 규칙은 필요한 신규 파일까지 놓치게 만들 수 있어 사용 목적이 분명한 생성 폴더에만 제한하는 것이 좋습니다.
TortoiseSVN에서는 무엇을 확인해야 할까요?
TortoiseSVN의 “Add to ignore list”도 본질적으로는 svn:ignore 또는 관련 ignore 속성을 설정합니다. 메뉴가 보였다고 해서 이미 추적 중인 파일의 변경을 무시해 주는 것은 아니에요. Commit 창에서 파일이 계속 보인다면 먼저 상태 열을 확인하고, Repository Browser나 Properties에서 그 항목이 저장소에 존재하는지 확인하세요.
미추적 항목이라면 해당 항목의 부모 폴더에서 속성 값을 살펴봅니다. 이름 하나만 무시할지, 확장자 패턴을 무시할지, 재귀적으로 적용할지 선택이 다르므로 메뉴 문구를 확인하세요. 팀원이 다른 Subversion 버전을 쓰는 경우에는 svn:global-ignores보다 디렉터리별 svn:ignore가 더 예측 가능한 선택일 수 있습니다.
반대로 추적 중인 파일의 로컬 변경만 개인 PC에서 계속 숨기고 싶은 요구라면, ignore 규칙으로 해결하려고 하지 않는 편이 낫습니다. 공유 설정과 개인 설정을 분리하거나, 템플릿 파일을 저장소에 두고 실행 시 개인 파일을 생성하는 구조가 더 안전해요. 예를 들어 config.example.ini는 추적하고 config.local.ini는 ignore하는 방식입니다. 작은 프로젝트의 파일 분리 기준이 필요하다면 HTML·CSS·JavaScript를 언제 나눌지 정리한 폴더 구조 기준도 함께 참고할 수 있습니다. 비밀번호나 토큰이 과거에 이미 커밋됐다면 ignore 추가만으로 기록에서 사라지지 않으므로 즉시 자격 증명을 폐기하고 별도 보안 절차로 저장소 이력을 점검해야 합니다.
상황별로 선택하면 실수가 줄어듭니다
| 현재 상태 | 맞는 조치 | 주의할 점 |
|---|---|---|
| 미추적 파일·폴더 | svn:ignore를 부모 폴더에 설정 |
기존 패턴을 덮어쓰지 않도록 먼저 읽기 |
| 여러 하위 폴더의 공통 미추적 항목 | svn:global-ignores 검토 |
Subversion 1.8 이상 호환성 확인 |
| 이미 추적 중인 생성물 | 팀 합의 뒤 svn delete --keep-local과 ignore 검토 |
커밋하면 저장소에서는 삭제됨 |
| 공유해야 하는 설정 파일 | 계속 추적하거나 템플릿·개인 설정으로 분리 | 중요 변경이 조용히 누락되지 않게 설계 |
적용 전 마지막 점검 순서
첫째, svn status와 svn info로 대상이 미추적인지 추적 중인지 구분합니다. 둘째, 미추적 항목이면 부모 폴더의 현재 svn:ignore 값을 읽고 패턴을 추가합니다. 셋째, 일반 status와 --no-ignore 결과를 비교해 규칙이 실제로 적용됐는지 확인합니다.
추적 중인 항목이라면 바로 삭제 명령을 실행하지 말고, 그 파일이 다른 작업자와 빌드·배포에 필요한지 먼저 확인하세요. 저장소에서 빼기로 결정했다면 로컬 백업, 변경 목록 검토, 팀 공지, 재생성 절차를 갖춘 뒤 --keep-local을 사용합니다. 백업 사본의 이름과 위치를 일관되게 남기는 방법은 원본·수정본·백업 파일을 다시 찾는 보관 규칙에서 이어서 확인할 수 있어요. 가장 중요한 기준은 변경 목록을 깨끗하게 만드는 것이 아니라, 필요한 파일을 잃지 않으면서 저장소에 남겨야 할 것과 자동 생성되는 것을 정확히 나누는 일이에요.
확인한 공식 자료
- Version Control with Subversion: Ignoring Unversioned Items —
svn:ignore의 적용 범위와 미추적 항목 처리 - Apache Subversion: Repository Dictated Configuration — Global Ignores — 로컬 설정,
svn:ignore,svn:global-ignores의 차이 - Apache Subversion 1.8 Release Notes — 상속 속성과
svn:global-ignores도입 조건
정보 기준일: 2026년 9월 4일. 명령은 작업 복사본 상태와 팀 운영 규칙에 따라 결과가 달라질 수 있으므로, 커밋 전 변경 목록과 로컬 백업을 확인하세요.