Merge pull request #623 from code-zero-to-one/chore/release-record-docs-followup

fix: 운영 릴리즈 기록 문서 정정

Author: Hyeonjun0527

docs/asdfasdf.md

@@ -15,7 +15,7 @@
 2. Jenkins에서 백엔드 운영 배포를 실행합니다.
 3. Jenkins 배포 성공을 확인합니다.
 
-여기까지가 백엔드 운영 배포입니다. 이 단계만으로 프론트엔드 PR이나 새 `releases/prod-*.yaml` 기록이 생기지는 않습니다. 최종 운영 조합 기록은 프론트엔드 운영 배포가 성공할 때 남깁니다.
+여기까지가 사람이 보는 백엔드 운영 배포입니다. 백엔드 PR 머지만으로는 프론트엔드 PR이나 릴리즈 기록이 생기지 않습니다. 다만 Jenkins 운영 배포가 성공해 프론트엔드 저장소로 배포 사실을 보내면, 프론트엔드 저장소가 `frontend.changed: false`, `backend.changed: true`인 backend-only 릴리즈 기록을 남길 수 있습니다.
 
 ## 2. 프론트엔드 운영 배포는 이렇게 합니다
 
@@ -51,7 +51,7 @@ ZERO-ONE은 백엔드와 프론트엔드가 따로 배포될 수 있습니다. 
 Frontend image + Backend image + DB migration 상태
 ```
 
-그래서 프론트엔드 운영 배포가 성공하면 프론트엔드 저장소의 `releases/prod-*.yaml`에 최종 운영 조합을 기록합니다.
+그래서 프론트엔드 또는 백엔드 운영 배포가 성공하면 프론트엔드 저장소의 `releases/prod-*.yaml`에 그 시점의 운영 조합을 기록합니다.
 
 릴리즈 기록에는 다음 정보가 남습니다.
 
@@ -67,7 +67,7 @@ Frontend image + Backend image + DB migration 상태
 
 ### 5-1. 백엔드 운영 배포 자동화
 
-백엔드는 Jenkins가 운영 배포합니다. Jenkins는 DB migration을 검증하고, 백엔드 이미지를 빌드한 뒤 운영 서버에 반영합니다. 배포가 성공하면 운영 백엔드 이미지/버전/DB 상태가 확정되고, 이 상태는 이후 프론트엔드 릴리즈 기록에 함께 남습니다.
+백엔드는 Jenkins가 운영 배포합니다. Jenkins는 DB migration을 검증하고, 백엔드 이미지를 빌드한 뒤 운영 서버에 반영합니다. 배포가 성공하면 프론트엔드 저장소에 backend-only 릴리즈 기록을 남길 수 있습니다. 이때 프론트엔드는 그대로이고 백엔드만 바뀐 조합으로 기록됩니다.
 
 ### 5-2. 프론트엔드 운영 배포 자동화
 
@@ -88,14 +88,14 @@ Frontend image + Backend image + DB migration 상태
 
 1. 운영자가 Jenkins 배포를 실행합니다.
 2. Jenkins가 migration 검증, 이미지 빌드, 운영 서버 반영을 처리합니다.
-3. Jenkins 성공 시 운영 백엔드 상태가 확정됩니다.
+3. Jenkins 성공 시 프론트엔드 저장소가 backend-only 릴리즈 기록을 남깁니다.
 
 짧게 쓰면 이 흐름입니다.
 
 ```txt
 백엔드 Jenkins 배포
 → migration 검증 / image build / production deploy
-→ 운영 백엔드 상태 확정
+→ backend-only releases/prod-*.yaml 기록
 ```
 
 ### 6-2. 프론트엔드 배포 내부 흐름
@@ -150,7 +150,7 @@ Frontend + Backend + Database + Rollback target
 
 ### 9-1. 백엔드 배포가 성공했는데 왜 프론트 PR이 안 생기나요?
 
-정상입니다. 백엔드 Jenkins는 프론트 PR을 만들지 않습니다. 백엔드 운영 배포만으로 프론트 저장소에 새 `releases/prod-*.yaml`이 생긴다고 보면 안 됩니다. 최종 릴리즈 기록은 프론트엔드 운영 배포에서 현재 운영 백엔드 상태까지 포함해 씁니다.
+정상입니다. 백엔드 Jenkins는 프론트 PR을 만들지 않습니다. 대신 Jenkins가 배포 사실을 프론트엔드 저장소로 보내면 backend-only `releases/prod-*.yaml` 기록이 생길 수 있습니다. 그래서 프론트 PR은 없는데 YAML만 생기는 상황은 정상입니다.
 
 ### 9-2. 프론트 PR 본문에 백엔드 payload 값을 직접 적어야 하나요?
 

docs/ops/onboarding.md

@@ -68,7 +68,7 @@ prod-YYYYMMDD-HHmm
 
 ## 4. 백엔드 운영 상태 전달 payload 계약
 
-백엔드 운영 배포가 성공하면 백엔드 이미지/버전/DB migration 상태가 확정됩니다. 이 값은 프론트엔드 운영 배포가 최종 릴리즈 기록을 만들 때 사용할 수 있도록 전달됩니다.
+백엔드 운영 배포가 성공하면 백엔드 이미지/버전/DB migration 상태가 확정됩니다. 이 값은 프론트엔드 저장소가 backend-only 릴리즈 기록을 만들 때 사용합니다.
 
 전달 방식으로 `repository_dispatch`를 사용할 경우 아래 계약을 따릅니다.
 
@@ -113,7 +113,7 @@ prod-YYYYMMDD-HHmm
 }
 ```
 
-GitHub Actions에서 이미 `github.event.client_payload`를 선택한 경우, 프론트엔드 스크립트는 내부 `client_payload` 객체만 직접 받아도 됩니다. 단, 이 payload 자체가 곧 최종 `releases/prod-*.yaml` 생성을 의미하지는 않습니다. 최종 기록은 프론트엔드 운영 배포가 현재 FE/BE/DB 조합을 확정할 때 작성합니다.
+GitHub Actions에서 이미 `github.event.client_payload`를 선택한 경우, 프론트엔드 스크립트는 내부 `client_payload` 객체만 직접 받아도 됩니다. 이 payload가 처리되면 프론트엔드 저장소는 현재 운영 프론트엔드 상태와 새 백엔드 상태를 묶어 backend-only `releases/prod-*.yaml` 기록을 작성합니다.
 
 ### 필수 payload 필드
 

docs/ops/release-record-shared-contract.md

@@ -54,7 +54,7 @@ AI agent가 운영 배포, 릴리즈 기록, release intent label, rollback meta
 2. Jenkins에서 백엔드 운영 배포를 실행합니다.
 3. Jenkins 배포 성공을 확인합니다.
 
-백엔드 배포가 성공하면 운영 백엔드 이미지/버전/DB migration 상태가 확정됩니다. 이 단계만으로 프론트엔드 PR이나 새 `releases/prod-*.yaml` 기록이 생기지는 않습니다.
+백엔드 PR 머지만으로는 프론트엔드 PR이나 릴리즈 기록이 생기지 않습니다. Jenkins 운영 배포가 성공하고 배포 사실이 프론트엔드 저장소로 전달되면, 프론트엔드 저장소가 backend-only `releases/prod-*.yaml` 기록을 작성합니다.
 
 ## Release ID와 이미지 태그
 
@@ -145,21 +145,19 @@ components:
 
 운영 백엔드 컨테이너를 확인할 수 있고 그 이미지가 최신 릴리즈 기록과 다르면 프론트엔드 워크플로우는 실패해야 합니다. 오래된 백엔드 메타데이터로 릴리즈 기록을 쓰는 것을 막기 위한 규칙입니다.
 
-## 백엔드 운영 상태와 프론트엔드 릴리즈 기록
+## 백엔드 운영 배포 기록
 
-백엔드 운영 배포가 성공하면 운영 백엔드 이미지/버전/DB migration 상태가 확정됩니다. 하지만 백엔드 배포만으로 프론트엔드 저장소에 새 `releases/prod-*.yaml` 기록이 생긴다고 보면 안 됩니다.
-
-최종 릴리즈 기록은 프론트엔드 운영 배포가 성공할 때 작성합니다. 이때 프론트엔드 워크플로우는 현재 운영 백엔드 상태를 함께 확인해서 다음 형태로 기록합니다.
+백엔드 Jenkins 운영 배포가 성공하면 백엔드 이미지/버전/DB migration 상태가 확정됩니다. Jenkins가 이 배포 사실을 프론트엔드 저장소로 전달하면, 프론트엔드 저장소의 backend release record workflow가 다음 형태의 기록을 작성합니다.
 
 ```yaml
 components:
   frontend:
-    changed: true
-  backend:
     changed: false
+  backend:
+    changed: true
 ```
 
-백엔드 상태를 payload로 전달하는 경우 정확한 필드 스키마는 `docs/ops/release-record-shared-contract.md`를 따릅니다.
+이 기록은 프론트엔드 배포가 아닙니다. 현재 운영 프론트엔드는 그대로 두고, 새 백엔드와 짝이 된 운영 조합만 남기는 기록입니다. 백엔드 payload의 정확한 필드 스키마는 `docs/ops/release-record-shared-contract.md`를 따릅니다.
 
 선택 payload 필드는 사람이 프론트 PR에 적는 값이 아닙니다. 백엔드 Jenkins가 배포 과정에서 채워서 전달할 수 있는 참고 메타데이터입니다.
 
@@ -176,14 +174,6 @@ components:
 - 프론트엔드만 배포하는 경우 최신 `releases/`의 백엔드 이미지가 현재 운영 백엔드와 일치하는지 확인합니다. 다르면 백엔드 디스패치 기록을 먼저 남깁니다.
 - 롤백 대상과 상속/제공된 백엔드 이미지가 `prod`나 `latest-prod`가 아닌 고정 이미지 태그인지 확인합니다.
 
-## 운영 배포 순서
-
-1. `db_migration`
-2. `backend`
-3. `backend_health_check`
-4. `frontend`
-5. `e2e_check`
-
 프론트엔드만 운영 배포하는 경우에도, 릴리즈 기록을 쓰기 전에 현재 배포된 백엔드 이미지/API와 database migration 상태를 기록해야 합니다.
 
 ## 운영 배포 후 체크리스트