.gitignore에 넣었는데 왜 변경 파일에 계속 나올까

로컬 파일 보존과 저장소 추적 종료를 나눠 표시했습니다. 과거 이력 삭제를 뜻하지 않습니다.

.gitignore에 debug.log를 적었는데도 Git의 변경 목록에 계속 나타납니다. 먼저 그 파일이 이미 추적 중인지 확인하세요. 추적 중인 파일이라면 ignore 규칙을 더 늘려도 상태가 달라지지 않습니다.

Git은 .gitignore를 아직 추적하지 않는 파일의 제외 규칙으로 사용합니다. 이미 인덱스에 들어간 파일은 계속 변경을 비교합니다. 인덱스는 다음 커밋에 넣을 파일 상태를 준비하는 곳입니다. 이 글의 목표는 로그 파일 하나를 내 컴퓨터에 남기면서, 다음 커밋부터 저장소에서 제외하는 것입니다. gitignore의 적용 대상

패턴을 고치기 전에 추적 상태를 봅니다

저장소 루트에서 다음 두 명령을 실행합니다. 여기서는 공개해도 되는 연습 파일 debug.log를 예로 듭니다.

git status --short -- debug.log
git ls-files --error-unmatch \
  -- debug.log

둘째 명령이 경로를 출력하고 성공하면 파일이 인덱스에 있습니다. 상태가 M인 파일을 ignore 목록에 적고 기다려도 추적은 끝나지 않습니다. 반대로 경로가 추적되지 않는다는 오류가 나오면 패턴 자체를 살펴볼 차례입니다. 같은 이름의 다른 폴더를 보고 있지 않은지도 확인하세요.

규칙의 출처는 다음 명령으로 조사할 수 있습니다.

git check-ignore -v --no-index \
  -- debug.log

-v는 적용된 규칙의 파일·행 번호·패턴을 보여 줍니다. --no-index를 붙였으므로 이미 추적한 경로에 대해서도 ignore 규칙을 검사할 수 있습니다. 이 출력은 패턴이 맞는지를 알려 줍니다. 파일의 추적을 끝냈다는 결과는 아닙니다. git check-ignore 옵션

루트의 .gitignore에 /debug.log를 쓰면 루트의 그 경로를 가리킵니다. 하위 폴더에도 같은 이름의 로그가 생긴다면 원하는 범위에 맞게 패턴을 고릅니다. 프로젝트 전체를 숨기는 넓은 패턴보다 실제 생성 파일을 먼저 특정하세요.

파일 하나만 인덱스에서 뺍니다

추적을 끝내기로 한 파일이라면 .gitignore에 필요한 규칙을 추가한 뒤 아래처럼 예상 변경부터 봅니다.

git rm --cached --dry-run \
  -- debug.log

대상이 맞으면 실제 인덱스를 변경합니다.

git rm --cached -- debug.log
git diff --cached --name-status \
  -- debug.log
git status --short

--cached는 작업 폴더의 파일을 남기고 인덱스에서 제거합니다. staged diff에 D가 보여도 이 명령이 로컬 파일을 지웠다는 뜻은 아닙니다. 다음 커밋에서 저장소의 해당 경로를 제거할 준비가 됐다는 뜻입니다. 파일 탐색기나 편집기로 debug.log가 그대로 있는지 함께 확인하면 두 상태를 구분할 수 있습니다. git rm의 cached와 dry-run

명령이 파일 상태 불일치로 멈추면 -f부터 붙이지 마세요. 작업 폴더·인덱스·현재 커밋의 내용이 서로 다를 수 있습니다. git diff -- debug.log와 git diff --cached -- debug.log를 확인해 보존할 변경이 어디에 있는지부터 정합니다. 로그에 민감한 내용이 있다면 이 출력을 채팅이나 이슈에 붙이지 않습니다.

규칙 파일 변경과 추적 종료는 함께 검토해야 합니다. .gitignore만 커밋하면 다른 사람에게 제외 의도는 전달되지만 기존 추적 파일은 남습니다. 추적 종료만 반영하고 규칙을 빠뜨리면 나중에 누군가 다시 추가할 수 있습니다. 커밋할 때는 기존에 다른 작업이 staged 상태인지도 확인하고 이번 변경만 포함하세요.

이 삭제 커밋을 받는 동료도 생각해야 합니다

내 작업 폴더에 파일이 남았다는 사실은 다른 사람의 작업 폴더까지 보장하지 않습니다. 추적 파일을 제거하는 커밋이 공유되면 다른 checkout에서는 그 제거가 적용됩니다. 동료가 파일을 개인 설정으로 쓰고 있다면 반영 전에 사본을 확보하도록 알려야 합니다. 로컬 수정이 있으면 Git이 업데이트를 막는 경우도 있어, 모두 같은 결과를 기대할 수는 없습니다.

그래서 공유해야 하는 기본 설정과 개인 설정을 같은 파일로 관리하지 않는 편이 편합니다. 예를 들어 config.example.json은 추적하고 config.local.json은 제외하도록 정할 수 있습니다. 다만 앱이 실제로 어느 파일을 읽는지 확인한 뒤 이름과 로딩 규칙을 바꿔야 합니다. ignore 수정만으로 앱의 설정 경로가 바뀌지는 않습니다.

이미 커밋된 내용은 과거에 남습니다

추적 종료는 앞으로 만들 커밋의 상태를 바꾸는 작업입니다. 이전 커밋에 들어간 debug.log 내용이 소급해서 사라지지는 않습니다. 특히 비밀키를 넣은 파일이었다면 .gitignore를 고친 것으로 노출 대응을 끝낼 수 없습니다. 키의 사용을 중단하고 교체하는 일과 이력 정리는 별도로 처리해야 합니다.

git rm -r --cached .로 저장소 전체를 뺐다가 다시 추가하는 처방은 이 사례에 필요하지 않습니다. 파일 하나의 문제를 해결하면서 무관한 경로까지 staged 변경으로 만들면 검토가 어려워집니다. 지금 목록에 남아 있는 정확한 파일을 확인하고, 그 파일의 staged 삭제와 로컬 보존, 적용된 ignore 규칙 세 가지를 대조하면 됩니다.

문서 확인: 2026년 9월 28일, Git 공식 매뉴얼. 위 명령은 독자가 상태를 확인하고 실행할 절차이며 이 글에서 사용자 저장소를 변경한 결과는 아닙니다.