소개
사이트를 로컬로 띄워서(npm run dev) 계획대로 잘 나왔는지 확인한 뒤, AI 협업 메이토에게 "여기까지 커밋해줘"라고 부탁했다. 그런데 .git/index.lock이라는 파일 때문에 커밋이 계속 실패했다. 메이토가 지워도 지워도 다시 생겼고, 왜 이런 일이 생기는지, 그리고 AI 자동화로 안 풀리는 문제는 결국 어떻게 풀어야 하는지 직접 겪어보고 싶어서 끝까지 따라가 봤다.
진행 방법
메이토(AI)가 git add / git commit을 시도하자 이런 에러가 났다.
fatal: Unable to create '.../.git/index.lock': File exists.
Another git process seems to be running in this repository...여기서부터 한참 헤맸다.
먼저 잠금 파일을 지우려고 함 → 메이토가 쓰는 자동화 도구(리눅스 환경)에서
rm -f .git/index.lock을 실행했는데 "Operation not permitted" 에러. 같은 소유자 파일인데도 권한이 없다고 나왔다.혹시 GitHub Desktop 같은 프로그램이 저장소를 열어두고 있나? 작업 관리자를 열어서 git 관련 프로세스를 찾아봤는데 아무것도 없었다. 범인이 아니었다.
파일 탐색기로 직접 지워보니 성공. 그런데 메이토가 곧이어
git status만 실행해도 잠금 파일이 새 타임스탬프로 다시 생겨났다. 알고 보니 메이토가 쓰는 자동화 환경(리눅스 쪽)이 이 저장소가 있는 드라이브에서 파일을 "만들 수는 있지만 지울 수는 없는" 이상한 권한 구조였고, 그래서 git 명령을 한 번 실행할 때마다 자기가 만든 잠금 파일을 자기가 못 치우고 그대로 남기고 있었다.배치 파일(.bat)로 우회 시도 → 메이토가
_commit.bat파일을 만들어서 더블클릭으로 실행하게 했는데, 이번엔 더블클릭 자체가 반응이 없었다. 내가 직접 더블클릭해봐도 마찬가지였다. (이 컴퓨터의 보안 정책 때문으로 추정.)결국 메이토가 방향을 바꿔서, 직접 터미널에 쳐달라고 부탁함. 새 명령 프롬프트 창을 열어서 아래 한 줄을 직접 붙여넣어 달라고 했다.
cd /d D:\클로드 && git add -A && git commit -m "..."내가 직접 터미널에 붙여넣고 엔터를 치니 한 번에 바로 됐다.
[main d9bc2e0] 2주차 진행분 커밋: ...
20 files changed, 692 insertions(+), 15 deletions(-)(Tip: 이 과정을 직접 겪은 사람이라면, 터미널 창 캡처를 여기 남기면 좋다 — 에러 화면 → 성공 화면.)
결과와 배운 점
Before → After
Before (자동화로 시도)
After (내가 직접 타이핑)
소요 시간
30분 넘게 (잠금 지우기 → 재생성 → 배치파일 실패 반복)
1분 미만
결과
index.lock 계속 재생성, 배치파일 무반응
즉시 커밋 성공
원인
리눅스 자동화 환경이 이 드라이브에서 파일을 못 지우는 권한 구조
내 실제 컴퓨터에서 직접 실행하니 권한 문제 자체가 없음
배운 점
AI가 화면을 대신 조작해주는 게 편하긴 한데, AI가 쓰는 실행 환경과 내 컴퓨터가 완전히 같은 게 아니라서 가끔 이런 식으로 어긋난다는 걸 알았다. 특히 파일 삭제·권한처럼 "환경 경계"에 걸리는 작업은 AI 쪽에서 아무리 재시도해도 안 풀릴 수 있다. 이럴 땐 붙잡고 계속 자동화를 시도하기보다, 내가 직접 한 줄 치는 게 제일 빠른 길일 수 있다.
나만의 꿀팁 (재사용 자산)
1. git 에러에 "index.lock", "File exists"가 보이면 → 진짜 다른 프로그램이 열어뒀는지 작업 관리자에서 먼저 확인
2. 그것도 아닌데 자동화 도구가 계속 못 지운다면 → 환경 경계(자동화 도구 vs 내 컴퓨터) 문제일 수 있음
3. 이럴 땐 자동화를 계속 시도하기보다, 내가 직접 터미널을 열어서 한 줄 쳐보는 게 제일 빠르다시행착오: 잠금 파일 삭제 시도 → 재생성 반복, 배치 파일 더블클릭 무반응까지 총 두 가지 우회로가 막혔다. 원인을 명확히 못 밝힌 채(왜 이 드라이브에서만 리눅스 쪽이 삭제 권한이 없는지) 사람이 직접 처리하는 쪽으로 방향을 틀었다.
도움이 필요한 부분: 왜 마운트된 드라이브에서 자동화 환경이 파일을 만들 수는 있는데 지울 수는 없는지, 근본 원인은 아직 못 밝혔다. 비슷한 구조(리눅스 샌드박스 + Windows 마운트 드라이브)를 쓰는 분이 있다면 원인을 아는지 궁금하다.
앞으로의 계획: 이번 사건 이후로 "git 쓰기 명령은 자동화로 시도하지 않는다"를 원칙으로 정했다. 다음에 비슷한 상황이 오면 바로 사람이 직접 터미널에 치는 쪽으로 넘어갈 생각이다.
