코딩 에이전트가 넓힌 .gitignore 규칙

시리즈: 바이브코딩 Tips #50

이전: 49편 | 목록 | 다음 없음

2026년 7월 12일 | 바이브코딩 Tips

---

작업트리가 깨끗해졌다는 사실만 보지 않고, 무시된 파일과 그 규칙의 출처를 함께 확인한다.

작업트리가 갑자기 깨끗해진 장면

git status에 파일이 열 개쯤 쌓여 있었는데 코딩 에이전트가 정리를 마친 뒤 두 개만 남았다. 처음에는 임시 산출물을 잘 치웠다고 생각했다. 그런데 요청했던 테스트 fixture 세 개도 같이 보이지 않았다. 파일은 디스크에 있었지만, 에이전트가 추가한 .gitignore 규칙 아래로 들어간 상태였다.

이런 일은 “불필요한 파일을 정리해 달라”거나 “커밋에 필요한 변경만 남겨 달라”고 맡겼을 때 잘 생긴다. 에이전트는 로그, 캐시, 생성물처럼 보이는 파일을 빠르게 분류하고, 가장 짧은 해결책으로 ignore 패턴을 넓힌다. 문제는 새 규칙이 진짜 임시 파일뿐 아니라 테스트 데이터, 샘플 설정, 문서용 JSON까지 함께 가릴 수 있다는 점이다. 깨끗한 status와 완전한 결과물은 같은 상태가 아니다.

.gitignore 수정은 정리가 아니라 가시성 변경이다

.gitignore는 파일을 삭제하지 않는다. 대신 Git이 어떤 파일을 기본 화면에서 보여 줄지 바꾼다. 그래서 규칙을 한 줄 추가하면 diff가 줄고 작업이 정돈된 것처럼 보이지만, 실제로는 리뷰 대상이 화면 밖으로 이동했을 뿐일 수 있다. 특히 *.json, fixtures/, output/처럼 넓은 패턴은 이름만 보고 임시 파일과 소스 파일을 구분하지 못한다.

나는 에이전트가 ignore 규칙을 건드린 날에는 “왜 이 파일이 사라졌나”를 먼저 묻는다. 삭제됐는지, 이동했는지, 무시됐는지 세 경우의 다음 행동이 다르기 때문이다. 삭제는 복구 대상을 찾는 문제이고, 이동은 참조 경로를 확인하는 문제다. 무시는 파일이 남아 있으면서 리뷰 화면에서만 빠진 문제다. 이 셋을 섞으면 에이전트가 같은 파일을 다시 만들거나 더 넓은 규칙을 덧붙이기 쉽다.

일반 status 말고 무시된 파일까지 펼친다

첫 확인에는 git status --ignored --short를 쓴다. 보통 status에서 빠진 파일이 !! 표기와 함께 나타나면, 사라진 것이 아니라 ignore 대상이 된 것이다. 이때 파일 목록 전체를 길게 읽기보다 요청에 포함된 경로가 있는지 먼저 찾는다. 내가 요청한 fixture, schema, snapshot이 무시 목록에 있으면 정리 완료가 아니라 검토 보류로 돌린다.

git status --ignored --short
git check-ignore -v tests/fixtures/case-timeout.json

두 번째 명령은 어떤 파일이 왜 무시됐는지 보여 준다. 출력에는 규칙이 들어 있는 파일, 줄 번호, 실제 패턴이 함께 나온다. 이 정보가 중요한 이유는 프로젝트 루트의 .gitignore만 원인이 아닐 수 있어서다. 하위 디렉터리 규칙, 저장소의 exclude 설정, 사용자 전역 ignore도 같은 결과를 만들 수 있다. 파일 존재 여부와 무시 규칙의 출처를 한 번에 맞춰야 엉뚱한 파일을 되살리지 않는다.

패턴은 확장자보다 생성 위치로 좁힌다

문제가 확인되면 규칙을 통째로 지우기보다 실제 생성 위치로 좁힌다. 프로젝트 전체의 *.json을 무시하는 대신 도구가 만드는 /tmp/report/*.json만 무시하는 식이다. 루트 기준 슬래시와 구체적인 하위 경로를 쓰면 테스트 fixture나 설정 예제가 함께 사라질 가능성이 줄어든다. 파일 이름이 일정하다면 디렉터리 전체보다 생성 파일 패턴 하나를 고르는 편이 낫다.

예외 규칙을 덧붙이는 방법도 있지만, 넓은 무시 뒤에 예외를 여러 개 붙이면 읽는 사람이 실제 범위를 계산해야 한다. 나는 예외가 두세 줄로 늘어나면 처음 규칙이 너무 넓었다고 본다. 정리 규칙은 숨길 파일보다 남겨야 할 파일을 더 많이 설명하게 되면 실패한 셈이다. 에이전트에게도 “JSON을 무시해”보다 “이 명령이 이 경로에 만드는 결과만 무시해”라고 말하는 편이 훨씬 정확하다.

규칙을 고친 뒤 같은 파일로 다시 묻는다

패턴을 좁혔다고 바로 끝내면 또 다른 파일이 조용히 숨을 수 있다. 나는 처음 문제를 발견한 파일과 반드시 남아야 하는 파일, 정말 무시할 생성물에서 각각 하나씩 골라 같은 명령으로 다시 확인한다. 테스트 fixture는 더 이상 무시되지 않고, 임시 리포트만 여전히 무시되며, 설정 예제는 처음부터 영향이 없어야 한다. 세 파일을 나란히 보면 규칙이 너무 넓은지와 너무 좁은지를 동시에 잡기 쉽다.

그다음에는 새 파일을 하나 만들어 보는 대신, 실제 생성 명령을 다시 실행한다. 손으로 만든 샘플은 예상한 경로에만 놓이지만 빌드 도구는 날짜 디렉터리나 중첩 폴더를 추가할 수 있다. 공식 명령 뒤에 무시 목록이 어떻게 바뀌는지 봐야 운영 상태와 맞는다. 에이전트가 “규칙을 수정했습니다”라고 말하면 나는 같은 생성 명령 뒤에도 요청 파일이 보이는가를 마지막 확인으로 둔다.

완료 보고에는 사라진 파일 수를 넣는다

ignore 수정 뒤에는 변경 파일 목록만 받지 않는다. 새로 무시된 파일이 몇 개인지, 그중 요청 산출물이 섞였는지, 규칙을 좁힌 뒤 status가 어떻게 달라졌는지를 같이 받는다. 예를 들어 “임시 리포트 12개는 무시됨, 테스트 fixture 3개는 추적 후보로 유지, ignore 규칙은 /tmp/report/ 한 경로에만 적용” 정도면 충분하다.

이 숫자가 있으면 status가 깨끗하다는 말을 덜 막연하게 들을 수 있다. 에이전트가 파일을 많이 만들고 지우는 작업에서는 특히 그렇다. 화면에서 사라진 파일 수가 예상보다 크면 기능 테스트보다 먼저 ignore 범위를 다시 본다. 반대로 예상한 생성물만 빠졌다면 그때 staged·unstaged 변경을 확인하고 다음 검증으로 넘어간다. 이때 요청 파일의 실제 경로도 한 번 더 대조한다.

정리 요청의 성공 조건을 바꿨다

예전에는 “불필요한 파일이 status에 안 보이면 완료”라고 생각했다. 지금은 조금 다르게 잡는다. 필요한 소스와 fixture는 계속 보이고, 재생성 가능한 임시 파일만 빠지며, 어떤 규칙이 그 경계를 만들었는지 설명할 수 있어야 한다. .gitignore diff가 들어온 순간에는 코드 정리보다 리뷰 가시성이 바뀌었다고 보는 편이 맞았다.

코딩 에이전트가 만든 깨끗한 작업트리는 보기 좋다. 하지만 그 깨끗함이 삭제, 이동, 무시 중 어디서 왔는지 모르면 다음 세션의 입력이 줄어든다. 나는 그래서 ignore 변경을 작은 설정 수정으로 넘기지 않는다. 무시된 파일 목록과 규칙 출처를 먼저 펼치고, 넓은 패턴을 실제 생성 경로로 줄인 뒤에야 정리가 끝났다고 판단한다.

시리즈: 바이브코딩 Tips #50

이전: 49편 | 목록 | 다음 없음