배포 전에 운영 스키마를 대조한다 — compare_prod_schema 를 절차에 넣기

무엇을

scripts/compare_prod_schema.py(09-20, 운영 DB ↔ db/schema.sql 컬럼 단위 대조)를 배포 절차 안에 넣는다.

왜

도구는 있는데 사람이 기억해야 돈다. 스키마가 바뀐 서버 이미지가 마이그레이션보다 먼저 나가면 그 테이블을 읽는 경로가 운영에서 500 이 된다 — 09-15 에 27·29 테이블로 늘 때마다 손으로 맞췄다. 09-20 대조는 29 테이블 198 컬럼 어긋남 0 이었지만 그건 그날의 값이다.

완료 조건

• 런북 배포 절(19장)에 단계로 들어가거나, release.yml 에서 돌게 한다 — 어느 쪽인지와 이유를 적는다
• 어긋나면 배포를 멈춘다(경고만 하고 지나가지 않는다)
• DB 자격증명을 워크플로 로그에 찍지 않는다(SEC-2)

방식 결정 (2026-09-21, 정성윤) — _project/decisions/128

release.yml 의 k3s-deploy 가 매니페스트 적용 전에 대조하고, 어긋나면 적용하지 않고 실패한다. 운영 컬럼 목록은 SSM 으로 서버 파드 안에서 뜬다(scripts/compare_prod_schema.py 머리말 ①). 비교 대상은 이번 커밋의 db/schema.sql 이다. 마이그레이션이 든 PR 은 배포가 일부러 실패한다 → 운영 DB 에 넣는다 → 워크플로를 다시 돌린다.

구현 준비 — 09-21 확인한 것

• release.yml 의 SSM 적용은 aws ssm send-command 한 번으로 명령 여러 줄을 보낸다(「SSM 으로 적용한다」 단계). 대조는 그 앞에 별도 send-command 로 두는 편이 실패 지점이 분명하다
• 운영 파드의 이미지가 옛 커밋이라도 상관없다 — 대조하는 것은 파드가 아니라 DB 이고, 파드는 DB 접속 수단일 뿐이다
• 워크플로 편집이라 런북을 먼저 읽는다(infra_runbook_guard.py)

2026-09-22 — 장민석이 넘겨받음

미결 항목 「정성윤 님께 확인 — 백엔드 티켓 둘을 장민석이 넘겨받아도 되는지」(09-22)에 정성윤 님 12번 로그가 「장민석 님께 넘기기로 한 둘」로 답했다. 착수 전(todo)이라 보존할 수행 기록이 없어 담당을 옮긴다. 결정(위 절)은 정성윤 님 것 그대로다. 착수는 수동 QA 게이트 뒤다(decisions/319 — 통과 전에는 이 티켓을 시작하지 않는다). 방식(decisions/128)은 그대로 따른다.

재발 사례 (2026-09-22, 정성윤) — 이 티켓이 막았어야 할 것

PR #111 머지 → release.yml 이 10:26 KST 에 server 0.1.25 를 먼저 배포 → 마이그레이션 2026-09-22-blacklist-request-note-unmeasured.sql 은 10:37 KST 에 손으로 넣었다(_logs/2026-09-22-05-seongyun). 그 사이 블랙리스트 요청 생성·목록·결정이 500, /health 는 ok. 09-14 와 똑같다. 대조 자체는 넣은 뒤 199 컬럼 어긋남 0. 이 워크플로 단계가 있었으면 배포가 멈추고 「마이그레이션을 넣으라」는 실패로 보였을 것이다. 우선순위를 올릴 근거다.

2026-09-22 — 정성윤이 되가져와 구현 (사용자 지시)

담당 장민석 → 정성윤. todo 라 보존할 수행 기록이 없다(§4). ⚠ 이 티켓은 decisions/319 로 「수동 QA 게이트 뒤」였는데 사용자 지시로 먼저 했다 — 오늘 11분 장애(재발 사례 절)를 막았어야 할 장치라서.

• release.yml 에 「운영 스키마를 대조한다」 — 적용 전, 서버 파드 안에서 운영 컬럼을 떠 compare_prod_schema.py --allow-prod-extra 로 대조, 어긋나면 실패(운영 그대로). 로그에는 테이블·컬럼·타입만 — 자격증명은 파드 밖으로 안 나온다
• 스크립트: 잘린 덤프 거절 · 「운영에만 있음」 경고 옵션 · 테스트 5건 · 런북 19장 머리 · decisions/128 구현 절
• 이 머신에서 단계를 그대로 운영에 돌려 봤다 → 멈췄다: 운영에 eval_run.components(PR #132) 가 없다. db/migrations/2026-09-22-eval-run-components.sql 을 넣어야 다음 배포가 지나간다

done 조건: 그 마이그레이션 운영 적용 → 이 PR 머지 → 릴리스에서 이 단계가 초록(어긋남 0)으로 지나가는 것을 본다.

2026-09-22 (밤) — 운영 스키마가 맞춰졌다

정성윤이 19:57 KST 에 2026-09-22-eval-run-components.sql 을 운영에 넣었다(해시 대조 후 서버 파드 안에서, SSM 명령 설명 「migration eval_run.components」 · Success). 20:19 에 한 번 더 돌린 것은 파일 안 안전장치(「이미 적용된 DB 다 — 멈춘다」)가 막았다 — 운영은 그대로. 워크플로 단계를 그대로 다시 돌려 어긋남 0(29 테이블 · 200 컬럼)을 확인 — 이제 머지해도 배포가 지나간다. done 조건은 머지 뒤 첫 릴리스에서 이 단계가 초록인 것.

2026-09-22 (밤) — 첫 릴리스에서 초록 → done

PR #139 릴리스(35721485684) 의 「운영 스키마를 대조한다」 단계: 저장소 schema.sql 29 테이블 · 200 컬럼 = 운영 29 · 200 — ✅ 어긋남 0 뒤 적용 · 스모크 테스트 통과.