EC2 공유 워킹트리 git Staged 충돌 — 원인과 대책

1. 사건 경위

2026-06-21 세션에서 EOS는 두 가지 독립적인 커밋 작업을 수행했다.

1. feat(rhms): recall boost_tags 기능 추가 + RHMS 검증 보고서 v1.1
2. feat(thesis): ADMIN_ISSUERS에 Aegis 추가

두 커밋 모두 git add <대상파일> && git commit 패턴으로 실행했으나, 결과 커밋에는 의도하지 않은 파일이 포함됐다.

두 커밋 모두 push 전에 발견하여 git reset --soft HEAD~1 로 즉시 복구했다. main 브랜치 오염은 없다.

2. 근본 원인

2-1. 공유 워킹트리

ec2.hyperbook.com 에서 EOS와 EROS는 동일한 경로 /home/ec2-user/hyperbook/ 를 git 워킹트리로 사용한다.

두 에이전트가 같은 인덱스(.git/index)를 공유하기 때문에, 한 에이전트가 git add 로 staged 한 파일은 다른 에이전트의 git commit 대상에도 포함된다.

2-2. Phase 2 홀드 중 staged 상태 유지

EROS는 thesis-network 동적 재작성(Phase 2)을 위해 아래 파일을 staged 상태로 대기 중이었다.

• services/ers-web/main.py +780줄 (_VIZ_HUB_HTML 신설)
• services/thesis-web/app.py +36줄 (GET /api/papers 엔드포인트)

이 상태에서 EOS가 git add services/rhms/app.py && git commit 을 실행하면, git은 인덱스 전체 를 커밋 대상으로 삼으므로 EROS의 staged 파일까지 포함된다.

2-3. stash 후 재-stage 반복

git pull --rebase 실행 시 unstaged 변경사항이 있으면 실패한다. 이를 피하기 위해 git stash → pull → git stash pop 을 반복했는데, stash pop 이 staged 상태를 unstaged 로 복원하면 이후 git add 시 EROS 파일이 다시 포함되는 악순환이 생겼다.

3. 즉각 복구 절차

# staged 내용 사전 확인
git diff --staged --stat

# 실수 커밋 취소 (push 전에만 가능)
git reset --soft HEAD~1

# EROS 파일 unstage
git restore --staged services/ers-web/main.py services/thesis-web/app.py

# 안전 커밋 — 지정 파일만
git commit --only services/rhms/app.py docs/RHMS_VERIFICATION_REPORT.md

# EROS 파일 재-stage
git add services/ers-web/main.py services/thesis-web/app.py

4. 재발 방지 대책

4-1. 즉시 적용 — git commit --only <파일>

git commit --only <파일> 은 지정한 파일의 워킹트리 버전만을 임시 인덱스로 커밋하고, 기존 인덱스(다른 에이전트의 staged 포함)는 그대로 보존한다.

# 권장 패턴 (공유 워킹트리 환경)
git commit --only services/rhms/app.py -m "fix: ..."

이 방식은 다른 에이전트의 staged 상태를 전혀 건드리지 않는다.

4-2. 커밋 전 필수 확인

# 커밋 전 staged 목록 반드시 확인
git diff --staged --stat
# 자신의 파일만 있는지 검증 후 진행

4-3. 장기 대책 — 에이전트별 git worktree 분리

근본적 해결책은 에이전트별 독립 git worktree 사용이다.

# EROS 전용 워킹트리 생성 예시
git worktree add /home/ec2-user/hyperbook-eros eros-branch

각 에이전트가 별도 경로에서 작업하면 인덱스 충돌이 원천 차단된다. 단, 브랜치 관리 규칙과 머지 전략 합의가 선행돼야 한다.

4-4. staged 홀드 금지 규칙

Phase 홀드 등 장기 대기가 필요한 경우, staged 상태 유지 대신 별도 브랜치 커밋 또는 patch 파일 저장을 권장한다.

# 홀드 필요 시 브랜치 보관
git stash -m "eros-phase2-hold"
# 또는
git diff --staged > /tmp/eros_phase2.patch
git restore --staged .

5. 교훈

공유 인프라에서 복수 에이전트가 협업할 때, git 인덱스는 공유 자원이다. 각 에이전트는 커밋 전 git diff --staged 로 타 에이전트의 staged 파일 유무를 확인해야 하며, git commit --only <파일> 을 기본 패턴으로 채택하는 것이 안전하다.

Hyperbook Polis에서 에이전트 간 협업이 심화될수록 이런 충돌은 증가할 수 있다. 워킹트리 분리(4-3)를 중기 과제로 사령관과 합의하길 권고한다.