Rinda CD Pipeline — 시점별 변경 분석

.github/workflows/ci-cd-alpha.yml · .github/workflows/ci-cd-beta.yml

2026-03-31 ~ 2026-05-24 분석 기준 branch: alpha 대상 커밋 50건 중 핵심 6건

TL;DR

  • 선택적 재배포 골조는 4월에 완성됨 — Detect Changed Components 가 worker / api / admin 변경 여부를 판정하고, WORKER_CHANGED 분기로 zero-downtime 대상이 달라짐.
  • 5/21 chlee 가 concurrency 큐잉으로 인한 worker-rebuild 누락을 막으려 EC2 .last-deploy-sha 기반 diff 로 보강 시도 (#7782) — 9분 뒤 본인이 revert (#7784). 운영 절차("PR 1개씩 머지")로 대체.
  • 5/24 새벽 chlee 가 ref: ${{ github.sha }} 2줄로 checkout race 차단 — beta(#7833) 검증 후 alpha cherry-pick(#7834). 양쪽 동기화.
  • 현재 두 워크플로는 2026-05-07 안정 버전 + 2줄 상태로 수렴.

핵심 질문 두 가지

사용자 질문을 분석 결과와 매핑한 답.

그 이전에는 "변경된 컨테이너만 재배포"되게 세팅하지 않았나?

맞다. 4월에 이미 구축되어 있었다. 워크플로의 Detect Changed Components 단계가 변경 파일을 분류한다.

2026-04-15 · #4522
worker 자동 재배포 안전장치 3개 추가 — drizzle/*.sql, db/schema/, services/*.service.ts 변경 시 자동 worker 재배포 트리거. SendGrid 사고 회고에서 도출.
2026-04-19 · #5985
worker-buyersearch 는 자동 배포 대상에서 제외 (mastra lab run 중단 방지 — 수동 재시작 정책).
오늘까지의 상태
워커 변경 → elysia-server admin bullmq-worker 모두 zero-downtime. 변경 없음 → elysia-server admin 만 빌드·재배포, worker 컨테이너 ID 유지.

그러니까 #7782 의 본질은 "선택 재배포 자체"가 아니라 diff 의 base 가 누락된 PR 들을 못 보는 문제였다. concurrency 큐잉으로 중간 5개 run 이 취소되면 마지막 run 의 git diff HEAD~1 HEAD 는 마지막 commit 하나만 본다 → 그 사이에 들어간 worker 변경이 안 보이게 되는 시나리오.

ref: ${{ github.sha }} 가 왜 도입됐나?

push 직후 race 차단. actions/checkout@v4 의 기본 동작은 "runner 가 checkout 을 실제 실행하는 시점의 브랜치 tip" 을 가져온다 — 트리거된 SHA 가 아니라.

시나리오

  1. commit A push → run #1 트리거 (SHA=A).
  2. 몇 초 뒤 commit B push → run #2 트리거 (SHA=B). 같은 group → run #1 큐 대기.
  3. run #1 이 늦게 checkout 할 때 브랜치 tip 은 이미 B. SHA=A 라고 표시되지만 실제 빌드된 코드는 B.
  4. 결과: Slack 알림·diff·Slack PR 번호 모두 mismatch. 운영자가 "어떤 SHA 가 실제 alpha 에 떠있는지" 확신 불가.

fix 는 단순:

# actions/checkout@v4
  with:
+   # 트리거 sha 명시 — push 직후 race 로 더 새 commit 이 들어와도 트리거된 sha 그대로 빌드
+   ref: ${{ github.sha }}
    fetch-depth: 2

비용: 2줄. 효과: 빌드 SHA 가 트리거 SHA 와 항상 일치. 두 워크플로 동시 적용 (#7833 beta → #7834 alpha cherry-pick).

시점별 변경 흐름

파일에 영향을 준 6개 변곡점.

  1. 2026-04-15 20:50 변경 컨테이너 안전장치 3개 도입 alpha + beta chlee #4522

    SendGrid IP 장애 회고에서, webhook 수정 PR (#4502) 머지 후에도 worker 가 구 코드로 남던 문제 확인. 화이트리스트(.github/worker-rebuild-trigger-files.txt) 만으로는 누락이 쉬워서, drizzle / db schema / services 세 종류 변경을 자동 worker 재배포 트리거로 추가.

    "변경된 컨테이너만 재배포" 의 안전망이 이때 완성됨.

  2. 2026-04-19 ~ worker-buyersearch 자동 배포 제외 alpha + beta chlee #5985

    mastra lab run 1건이 수 분 단위로 길어 zero-downtime 의 SIGKILL grace period 안에 끝나지 않음. 매 배포마다 잡 stalled / SSE 끊김 발생 (alpha 사고 1777271302847). 새 코드는 수동 재시작으로만 반영하기로 정책 결정.

  3. 2026-05-19 10:37 activity_logs typed helper (간접) 간접 영향 Gyudong Kim #7604

    워크플로 본질은 변경 없음. 컴플라이언스 Issue 6 작업이 부수적으로 같은 파일을 터치한 것으로 보임.

  4. 2026-05-21 18:24 EC2 last-deploy-sha 기반 diff base (시도) alpha only chlee #7782 +42 −5

    의도: concurrency.group=deploy-alpha + cancel-in-progress:false 에서 7개 PR 빠른 머지 시 중간 5개 run 이 큐잉 갱신으로 취소됨. 마지막 run 만 HEAD~1 diff 로 worker 변경을 판정 → 안전장치 누락 가능.

    해결안: EC2 에 ~/send-grid-test/.last-deploy-sha 기록. 다음 run 의 Detect Changed Components 가 그 SHA 와 diff. 폴백 체인: last-deploy-sha → event.before → HEAD~1.

  5. 2026-05-21 18:33 #7782 즉시 revert alpha only chlee #7784 +5 −42

    본인 PR 을 9분 만에 본인이 revert. over-engineering 으로 판단. byte-identical with 472282d03 (2026-05-07).

    대안 채택: "PR 1개씩 머지 + deploy 완료 확인" 운영 절차. 5/7~5/20 동안 워크플로 미변경에도 deploy 가 안정적이었다는 관찰이 근거.

    패턴: 인프라 코드 복잡도를 늘리기 전에 "운영 절차로 푸는 게 더 간단한가?" 를 먼저 검증. 9분 안에 결정 번복할 수 있었던 건 자기 PR 이라서.
  6. 2026-05-24 00:45 checkout race fix — ref: github.sha alpha + beta chlee #7834 ← #7833 +2

    email-warmup reply 100% 보장 / WarmupRecoveryWorker 시간당 backfill 과 묶여 머지. 워크플로 변경분은 2줄.

    beta(#7833) 에서 먼저 검증 → alpha cherry-pick(#7834). 다른 race 와 달리 이건 실제 빌드된 SHA 와 표시된 SHA 의 mismatch 문제라 절차로는 해결 불가능 → 코드 fix 가 합당.

    대조: #7782 는 "복잡한 코드로 인프라 보강" 이었고 revert. #7834 는 "최소 2줄로 race 차단" 이어서 살아남음. 같은 race 카테고리여도 fix 규모 vs 효과 비율이 결정.

의도자 분포

최근 6개 변경 중 5개가 chlee 단독. 1개만 다른 인원의 부수 영향.

PR 일시 의도자 대상 요지
#4522 2026-04-15 chlee alpha + beta worker 안전장치 3개 (drizzle/schema/services)
#5985 2026-04-19 chlee alpha + beta worker-buyersearch 자동 배포 제외
#7604 2026-05-19 Gyudong Kim (부수 영향) activity_logs typed helper
#7782 2026-05-21 chlee alpha only EC2 last-deploy-sha 기반 diff (시도)
#7784 2026-05-21 chlee alpha only #7782 revert (over-engineering)
#7834 2026-05-24 chlee alpha + beta checkout race fix (ref: github.sha)

현재 상태 요약

레이어 동작 도입 시점
Checkout ref: github.sha 명시 — race 차단 2026-05-24
Diff base git diff HEAD~1 HEAD (단순). "1개씩 머지" 운영 절차로 보완 2026-05-21 회귀
변경 감지 분류 worker / api / admin 3분류. worker 트리거: 화이트리스트 + drizzle/schema/services 안전장치 2026-04-15 완성
Zero-downtime 대상 worker 변경 → elysia-server admin bullmq-worker 같이. 없으면 elysia-server admin 만 2026-04-19 정착
worker-buyersearch 자동 배포 제외 — 이미지만 빌드, 수동 --force-recreate 필요 2026-04-19
Concurrency group=deploy-{env}, cancel-in-progress:false 2026-04 이전

인사이트

1. 인프라 코드 < 운영 절차 — 같은 문제(concurrency 큐잉 누락)를 코드(#7782, 42줄)로 풀려다 9분 만에 절차("1개씩 머지")로 회귀. 자기 PR 이라 빠른 번복이 가능했다.
2. fix 규모 vs 효과 비율 — race 차단이라는 같은 카테고리에서 2줄(#7834)은 살고 42줄(#7782)은 죽음. 워크플로 변경은 "최소 효과적 코드" 기준으로 채택 여부 결정.
3. beta 먼저, alpha cherry-pick — 최근 패턴이 beta 검증 후 alpha 로 옮기는 형태(#7833 → #7834). beta 가 production 이라는 점을 감안하면 흥미로운 우선순위.