베이스 업데이트 받기

라이선시 fork는 한 번 받고 끝나는 것이 아닙니다. 베이스(ddakit/blog-studio)가 새 스킬을 추가하거나, 훅을 고치거나, AI_AUTOMATION.md의 도메인 규칙이나 Blogger 발행 스크립트를 갱신할 때마다 그 변경이 fork에 도달해야 라이선스 가치가 유지됩니다. /update-from-base는 git rebase를 몰라도 안전하게 받게 해 주는 명령입니다.

자동으로 적용할 수 있는 영역, 절대 건드리지 않는 영역, 사람이 결정하는 영역. 이 셋으로 갈라지는 것이 핵심입니다.

영역별 owner

업데이트가 무엇을 덮어쓰고 무엇을 그대로 두는지는 파일이 어느 영역에 속하는지로 결정됩니다.

base-owned: 자동 갱신 대상

경로	무엇
`.claude/skills/{base-skill-name}/`	베이스 스킬입니다 (start, blog-orchestrator, 블로그 트랙 13개 + 마케팅 트랙 6개)
`.claude/agents/*.md`	에이전트 6개입니다 (strategy, production, quality + marketing-director, content-lead, seo-discovery-lead)
`.claude/hooks/*.sh`, `.claude/settings.json`	베이스 훅과 그 등록 설정입니다
`AI_AUTOMATION.md`	도메인 기준 문서입니다 (Phase 정의, 산출물 계약, AI 게이트 항목, 보안 S1~S8)
`scripts/deploy_to_blogger.py`, `scripts/deploy.sh`, `scripts/requirements.txt`, `scripts/README.md`	Blogger 발행 스크립트입니다
`.env.example`, `.gitignore`	자리 표시 값과 표준 설정입니다

베이스 스킬 본문은 직접 수정하지 않는 것이 원칙입니다. 자기 스킬을 추가하고 싶으면 별도 디렉터리에 만듭니다. base-owned 영역에 새 스킬이 추가돼도 사용자 자신의 디렉터리는 영향받지 않습니다.

user-owned: 절대 건드리지 않는 영역

경로	무엇
`_workspace/posts/`, `_workspace/pages/`, `_workspace/briefs/`	작성 중인 글과 발행 보관본, 단계별 브리프, 이미지입니다
`.env`	`BLOG_ID_KO`와 `BLOG_ID_EN`입니다
`scripts/credentials.json`, `scripts/token.json`	Google OAuth 자격증명입니다 (git이 추적하지 않습니다)
`.claude/agent-memory/`, `.claude/state/`, `.claude/session-state/`	메모리와 런타임 상태, 세션 인계 정보입니다
`LICENSE`, `COMMERCIAL-LICENSE.md`	라이선스 파일입니다

라이선스 파일과 .env는 베이스가 갱신해도 자동으로 덮어쓰지 않습니다. 베이스가 .env.example에 새 변수를 추가했다면 그 변수를 본인 .env에 채우라고 안내만 합니다.

mixed: 3-way 안내

CLAUDE.md와 AGENTS.md, README.md 셋입니다. 베이스와 사용자 양쪽의 편집이 동시에 들어갈 수 있어서 자동으로 갱신하지 않고 diff만 보여 준 다음 묻습니다. README.md는 /start가 본인 블로그 이름과 정체성으로 다시 쓰는 파일이라, base 변경분을 통째로 덮으면 사용자 블로그 정체성이 사라집니다.

.claude/product-marketing-context.md는 한 가지 예외입니다. fork 사용자가 채운 블로그 정체성이라 평소에는 user-owned이지만, 베이스가 자리 표시 값 구조 자체를 갱신하면 mixed로 분류해 안내합니다.

사전 설정: 한 번만

베이스를 git remote로 등록합니다. 처음 호출할 때 이 단계를 자동으로 안내하므로 미리 입력할 필요는 없습니다.

git remote add base https://github.com/ddakit/blog-studio.git
git remote -v

상태 파일은 .claude/state/base-upstream.json에 들어가고, last_synced_commit부터 base/main까지의 변경분만 봅니다.

한 사이클

/update-from-base 또는 “베이스 업데이트 받아줘”라고 요청하면 다음을 거칩니다.

git status --porcelain으로 저장하지 않은 변경을 검사합니다. 남아 있으면 git stash를 권합니다.
git fetch base main으로 베이스를 가져옵니다.
git diff --name-status <last_synced_commit>..base/main으로 변경 파일을 영역별로 분류합니다.
base-owned 변경을 요약합니다. 새 스킬 몇 개, 갱신된 훅 몇 개, AI_AUTOMATION.md 갱신 여부, 발행 스크립트 갱신 여부를 알려 줍니다.
사용자가 동의하면 base-owned 경로만 git checkout base/main --로 적용합니다.
mixed 파일은 하나씩 세 가지 방법(통째로 덮기, 3-way merge, 미루기) 중 하나를 골라 적용합니다.
적용한 뒤에 검증합니다. .sh에 chmod +x를 주고, settings.json의 JSON 파싱을 확인하고, 새 스킬의 trigger 키워드를 나열합니다.
.claude/state/base-upstream.json을 갱신합니다.
commit을 권합니다. 메시지는 chore(base): sync from ddakit/blog-studio @ {short-hash} 형식입니다.

되돌리기 어려운 명령은 자동으로 실행하지 않고 사용자 확인을 받습니다. 기본 흐름은 30초에서 2분 사이에 끝나고, mixed 파일 결정에 시간이 더 걸리는 갈래가 하나 있습니다.

발행 스크립트가 base-owned인 이유

deploy_to_blogger.py는 AI-smell 게이트와 품질 게이트를 코드 차원에서 강제합니다(S8). 사용자가 이 스크립트를 수정하면 게이트가 무력해질 수 있어서, 베이스가 기준 문서처럼 관리합니다. 발행 동작을 바꾸고 싶으면 스크립트를 고치는 대신 AI_AUTOMATION.md의 게이트 기준값 안에서 조정합니다. 게이트를 우회해야 하는 재발행은 --skip-gate 플래그로만 허용합니다.

베이스 스킬을 본인이 수정한 흔적이 있을 때

.claude/skills/{base-skill}/ 안의 파일을 사용자가 commit으로 수정한 적이 있으면(git log로 감지합니다) 그 파일은 base-owned가 아니라 mixed로 처리됩니다. 자동으로 덮어쓰면 사용자 작업이 사라지기 때문입니다. 이런 상황을 피하려면 베이스 스킬을 직접 고치지 말고, 같은 trigger 키워드를 가진 별도 스킬을 자기 디렉터리에 만듭니다.

인접 문서

같은 절차를 비개발자용으로 풀어 쓴 문서는 비개발자용 업데이트에 있습니다.