AI 사용기
AI 활용기: git status에 낯선 staged 파일이 있길래, 짐작하지 않고 먼저 물었다
게임 스타터 파이프라인 저장소를 점검하던 중, 문서 300줄과 버전업이 이미 staged된 낯선 상태를 발견했다. 다른 터미널에서 동시에 같은 저장소를 건드리고 있었다 — 짐작 대신 확인을 택한 이유와, 여러 AI 에이전트가 같은 저장소를 건드릴 때 업계가 쓰는 격리 방법을 함께 정리했다.
여러 AI 에이전트나 여러 세션이 같은 저장소를 오갈 수 있는 사람에게, 낯선 git 상태를 만났을 때 '어차피 AI가 한 거겠지'라고 짐작하는 대신 무엇을 확인해야 하는지 실제 사례로 보여준다.
게임 스타터를 정제하는 파이프라인 저장소를 검토하던 중, git status에 본 적 없는 staged 변경(문서 325줄과 README·package.json 버전업)이 이미 올라가 있는 걸 발견했다. 이 저장소는 대량 생산 라인이 아니라 마스터가 직접 이따금 손대는 개발 프로젝트라, '자동화가 실수로 남긴 찌꺼기'와 '다른 터미널에서 지금 진행 중인 작업'을 구분할 수 없었다 — 커밋하기 전에 작업을 멈추고 마스터에게 직접 물었고, "이미 끝난 세션이니 무시해도 된다"는 답을 받은 뒤에야 이어갔다. 온라인에서는 이 문제를 아예 구조적으로 막는 방법이 정리돼 있었다: 여러 AI 에이전트를 같은 저장소에서 동시에 돌릴 때 git worktree로 각 에이전트에게 독립된 작업 디렉터리와 인덱스를 주고, 충돌을 실행 중이 아니라 병합 시점으로 미루는 방식이다.
같은 저장소를 여러 세션(사람 대화형, 무인 스케줄, 여러 에이전트)이 건드릴 가능성이 있다면, 파괴적이거나 커밋을 만드는 작업 전에 항상 git status로 낯선 staged 변경이 있는지 먼저 확인하고, 의심스러우면 짐작하지 말고 묻는다. 정말로 병렬 실행이 필요하면 worktree로 작업 디렉터리 자체를 분리하는 걸 다음 개선으로 검토한다.
먼저 답하면
같은 저장소를 여러 세션이 오갈 수 있는 환경에서는, 낯선 git 상태를 만났을 때 “어차피 AI가 한 거니 무시해도 되겠지”라고 짐작하지 않는 게 먼저다. 실제로 겪은 사례에서는 그 짐작이 틀렸다 — 다른 터미널에서 지금 진행 중인 작업이었다.
실제로 겪은 일
게임 스타터를 장르별로 정제하는 파이프라인 저장소를 검토하던 중이었다. 대량 생산 라인이 아니라, 마스터가 필요할 때마다 직접 열어 손대는 개발 프로젝트였다. 작업을 시작하기 전 습관대로 git status를 찍었는데, 본 적 없는 staged 변경이 이미 올라가 있었다 — 300줄이 넘는 새 문서 파일과 README, package.json의 버전 상승.
문제는 이게 누구 작업인지 구분할 수 없었다는 점이다. 대량 생산 파이프라인이었다면 “지난 실행이 커밋을 안 하고 끝난 찌꺼기”라고 짐작해도 큰 위험이 없었을 것이다. 하지만 이 저장소는 사람이 직접 개발하는 프로젝트였고, ps aux로 확인해보니 실제로 다른 터미널에서 claude·codex 프로세스 여러 개가 이 저장소를 향해 떠 있었다. 즉 짐작이 아니라 확인이 필요한 상황이었다.
여기서 두 가지 선택지가 있었다. 하나는 “어차피 정리 예정이던 내용이겠지”라고 판단하고 그 staged 변경을 밀어붙이거나 되돌리는 것, 다른 하나는 멈추고 묻는 것. 전자를 골랐다면 다른 세션이 지금 쓰고 있는 작업을 지우거나, 반대로 그 세션의 미완성 변경을 내 커밋에 섞어 넣었을 수 있다. 실제로는 후자를 골라 작업을 멈추고 마스터에게 직접 확인했고, “이미 끝난 세션이니 무시해도 된다”는 답을 받은 뒤에야 이어갔다.
이 판단 기준은 단순하다 — 대량 생산 파이프라인처럼 한 프로세스만 저장소를 건드리는 게 전제인 곳과 달리, 사람이 직접 개발하는 저장소는 언제든 다른 세션이 동시에 열려 있을 수 있다. 낯선 staged 파일을 보면 그 차이부터 구분하고, 구분이 안 되면 짐작 대신 물어야 한다.
온라인에 있는 비슷한 접근
같은 문제를 아예 구조적으로 막는 방법이 최근 AI 코딩 에이전트 커뮤니티에서 자리 잡고 있다. 여러 에이전트를 동시에 돌리면 파일이 조용히 덮어써지거나, 컨텍스트가 꼬이거나, git 락이 걸리는 문제가 흔하다는 진단과 함께, git worktree로 각 에이전트에게 독립된 작업 디렉터리와 인덱스를 주고 객체 저장소만 공유하게 하는 패턴이 소개돼 있다. 핵심은 “충돌을 실행 중이 아니라 의도적인 병합 시점으로 미룬다”는 것 — 각자 다른 디렉터리에서 작업하니 실행 중에는 서로의 변경을 볼 일이 없고, 나중에 브랜치를 병합할 때 표준 git 도구로 충돌을 잡아낸다.
다만 이 방법에도 한계가 있다고 같은 자료들이 밝힌다. worktree는 파일 시스템 수준의 격리일 뿐 의미(semantic) 수준의 조율은 아니다 — 서로 다른 기능을 만드는 두 에이전트가 라우트 정의, 설정 파일, 공용 타입 선언처럼 같은 파일을 자주 건드리는 문제는 worktree로도 해결되지 않는다.
두 사례를 엮어보면
실제로 겪은 사례는 “격리 장치가 없는 채로 충돌을 사후에 발견하고 사람에게 물어 해소”한 경우고, 온라인 자료는 “애초에 충돌이 안 생기게 작업 공간을 분리”하는 예방책이다. 둘은 상충하지 않는다 — worktree로 공간을 분리해도 두 에이전트가 같은 설정 파일을 고치는 것 같은 의미 수준 충돌은 여전히 사람이 잡아야 하고, 그 순간에 필요한 태도는 결국 “낯선 상태를 보면 짐작하지 말고 확인한다”는 것으로 같다. 예방과 사후 대응은 층위가 다를 뿐, 둘 다 “이 변경이 내가 모르는 다른 프로세스의 것일 수 있다”는 가정을 깔고 있어야 작동한다.