베이스 업데이트 받기
이 페이지는 base가 새 버전을 내놓았을 때 본인 사본에 그 변화를 가져오는 방법입니다. base 안에 새 스킬이 추가됐거나, 자동화 훅이 개선됐거나, AI에게 알려 주는 도메인 규칙(AI_AUTOMATION.md)이 갱신됐을 때 이 흐름이 필요합니다.
받아야 하는 이유는 한 줄입니다. base는 본인이 산 시점의 코드 위에 본인 테스트가 쌓이는 출발점인데, base 자체가 계속 좋아지고 있어서 그 좋아진 부분을 받지 않으면 본인 사본만 시간 안에 갇힙니다. 매번 받을 필요는 없습니다. 한 달에 한 번 정도, 또는 base 측에서 “새 스킬 나왔어요” 같은 안내가 도착했을 때 받아 보면 됩니다.
이 흐름은 비개발자도 직접 누를 수 있게 설계돼 있습니다. git rebase 같은 명령을 외울 필요가 없습니다. Claude Code 또는 Codex에 “베이스 업데이트 받아줘”라고 말하면 됩니다.
처음 한 번 — base 저장소를 등록합니다
섹션 제목: “처음 한 번 — base 저장소를 등록합니다”이 등록은 한 번만 합니다. 내려받기와 설치에서 B 경로(git clone 후 git remote rename origin base)로 받았다면 이미 등록돼 있으니 이 절은 건너뛰어도 됩니다. A 경로(GitHub Template)로 받았다면 등록이 필요합니다.
터미널을 열고 본인 폴더에서 다음을 실행합니다.
git remote add base https://github.com/ddakit/e2e-base.git명령이 끝나도 화면에는 아무것도 출력되지 않습니다. 그게 정상입니다. 등록이 잘 됐는지 확인하려면 다음을 실행합니다.
git remote -vbase와 origin 두 줄씩 모두 네 줄이 보이면 끝입니다. /update-from-base를 처음 부를 때 base 등록이 안 돼 있으면 도구가 위 명령을 안내하면서 대신 실행해 드릴지 묻습니다.
fatal: remote base already exists가 보인다면 이미 등록돼 있다는 뜻이니 그대로 다음 절로 넘어가면 됩니다.
업데이트 한 번 받기
섹션 제목: “업데이트 한 번 받기”등록이 끝났다면 다음번부터는 한 줄입니다. Claude Code 또는 Codex 대화창에 다음 중 하나를 입력합니다.
/update-from-base또는 자연어로 “베이스 업데이트 받아줘”. 둘은 같은 결과를 만듭니다.
호출이 들어가면 도구는 다음 순서를 거칩니다. 단계마다 무엇이 보여야 정상인지 같이 적어 두었으니 그 줄을 보면서 따라가면 됩니다.
1. 저장 안 된 변경 검사
섹션 제목: “1. 저장 안 된 변경 검사”본인 작업물에 아직 commit 안 된 변경이 있는지 먼저 봅니다. 있으면 “먼저 commit하거나 따로 빼두는 게 안전해요. git stash로 잠깐 빼둘까요?”라고 묻습니다. yes라고 답하면 잠깐 옆으로 빼 두고, 업데이트가 끝나면 원래대로 돌립니다. 안전하게 가는 길이라 가급적 yes를 권합니다.
2. base의 변경분 요약
섹션 제목: “2. base의 변경분 요약”도구가 base 저장소에서 새 commit들을 가져온 다음, 본인 사본의 어디가 영향받는지 영역별로 묶어서 보여 줍니다.
베이스 업데이트 요약 (지난 sync 후 새 변경분)
새로 추가된 스킬 (자동 적용 가능)- 2개
갱신된 베이스 파일 (자동 적용 가능)- .claude/skills/ (3개 갱신)- .claude/hooks/ (1개 갱신)- AI_AUTOMATION.md (✓ 갱신됨)
수동 확인 필요 (당신 편집과 충돌 가능)- CLAUDE.md- README.md
진행할까요? (yes / no / show-diff)yes면 자동 적용이 가능한 영역을 한 번에 받습니다. 이 영역은 base가 책임지는 자리(스킬, 에이전트, 훅, AI_AUTOMATION.md)라서 덮어써도 본인 테스트가 사라지지 않습니다. show-diff를 고르면 어떤 줄이 바뀌는지 자세히 보여 줍니다. 처음 한두 번은 show-diff로 한 번 보고 yes로 넘어가는 흐름이 무난합니다.
3. 본인 테스트는 절대 건드리지 않습니다
섹션 제목: “3. 본인 테스트는 절대 건드리지 않습니다”여기서 안심해도 되는 자리가 있습니다. 업데이트는 본인이 작성한 것은 절대 덮지 않습니다.
tests/ 폴더의 테스트 전부, playwright.config.ts나 .maestro/ 같은 트랙 설정, .env.test.local, docs/design/e2e-spec.md, docs/adr/의 결정 기록은 모두 본인 영역입니다. base 업데이트가 손대지 않습니다. 자동으로 갱신되는 건 base가 만든 자동화 자산뿐입니다.
CLAUDE.md와 README.md는 base도 고치고 본인도 메모를 더했을 수 있는 자리라 자동으로 덮지 않고 한 파일씩 묻습니다. 베이스 버전으로 통째로 덮을지, 변경 부분만 합칠지, 일단 둘지 셋 중 하나를 고릅니다. 본인이 그 파일을 손댄 적이 없다면 통째로 덮는 1번이 정답입니다.
4. 적용 후 마무리
섹션 제목: “4. 적용 후 마무리”도구가 적용된 파일을 한 번 더 점검합니다. 훅 파일이 갱신됐으면 실행 권한을 다시 붙이고, 새 스킬이 들어왔다면 그 스킬을 어떤 키워드로 부르는지 한 줄씩 나열해 줍니다. 마지막에 commit으로 박아 둘지 묻습니다. yes면 자동으로 commit합니다.
받을지 한 번 멈추는 자리
섹션 제목: “받을지 한 번 멈추는 자리”업데이트는 매번 받을 필요가 없습니다. 다음 자리에서 한 번 멈춥니다.
본인이 base 스킬을 직접 수정한 적이 있으면 멈춥니다. base 스킬 본문을 직접 고쳤다면 자동 갱신이 그 수정을 덮습니다. base 스킬을 직접 고치지 말고 같은 키워드로 본인 디렉토리(예: .claude/skills/my-team-{이름}/)에 따로 만드는 길을 권합니다.
작업이 한창이고 곧 commit할 변경이 있다면 그걸 먼저 마치고 받습니다. 잠깐 빼 둔 작업이 base 변경과 같은 줄을 건드리면 충돌이 나는데, 이 충돌은 비개발자가 풀기 가장 어려운 자리입니다. 가능하면 작업이 안정된 시점에 받습니다.
무언가 깨졌을 때
섹션 제목: “무언가 깨졌을 때”업데이트 후 빌드가 깨지거나 명령이 안 먹히면, 먼저 트러블슈팅을 한 번 봅니다. base가 새 도구 버전을 요구하기 시작했을 수 있습니다.
그래도 안 풀리면 적용된 변경을 통째로 되돌립니다.
git revert HEAD이 명령은 update가 가져온 변경을 되돌리는 새 commit을 만듭니다. 본인 테스트는 그대로 살아 있고, base도 다음 호출에서 다시 가져올 수 있습니다.
이미 테스트가 있는 앱에 base 패턴을 얹고 싶을 때
섹션 제목: “이미 테스트가 있는 앱에 base 패턴을 얹고 싶을 때”이건 update와 다른 자리입니다. base를 fork한 게 아니라, 이미 e2e 테스트가 일부 있는 앱 저장소에 base의 패턴(트랙 구조, 인증 재사용, CI)을 맞춰 넣고 싶을 때는 /adopt를 부릅니다.
/adopt이 명령은 본인 저장소에 이미 있는 도구와 디렉토리 구조, 인증 방식, CI를 살펴보고, base 패턴과 어디가 다른지 짚어 우선순위 매긴 이행 계획을 만들어 줍니다. 한 번에 다 바꾸지 않고 어디부터 손대면 되는지 순서를 잡아 줍니다. 자세한 흐름은 전문가용 매뉴얼의 updates 페이지에 있습니다.
업데이트가 끝났으면 본인 테스트가 여전히 잘 도는지 실행하고 보고서 읽기의 /run-suite로 한 바퀴 돌려 확인합니다. base의 보안 자리가 건드려진 업데이트라면, 스테이징에서 한 사이클 돌려 본 다음 다음 단계로 넘어갑니다.