배포 운영 분석

정기배포 운영 공지, 합리적인가?

v2.8.1.0 · 마지막 정기 동기화 #8612 이후 베타 반영분 git 포렌식 검증
대상: origin/beta (#8612 이후 21건) 분석일: 2026-06-15 공지자: 김규동

결론 ① — 김규동 공지는 합리적이며 데이터로 입증된다. 직접 cherry-pick 10건 중 다음 정기배포(목)까지 정말 못 기다릴 진짜 P0는 #8620 단 1건, 정기배포로 충분했던 건 6건.

결론 ② — "빠른 개선을 바로 출시" 본능은 옳지만, 이번 데이터에선 산 속도(며칠)보다 치른 비용(중복·drift·추적불가)이 컸다. 빠름의 정답은 cherry-pick 상시화가 아니라 배포주기 단축 + feature flag다.

사실 분기 구조 실측

21
#8612 이후 origin/beta 신규 커밋 (전부 6/15 하루)
6
정기 SYNC 경로 (정상)
10
사후 cherry-pick (명시 8 + 라벨누락 2)
3
beta-only 직접작업 — alpha에 원본 부재 (drift)

※ 로컬 beta는 6/5에 멈춘 stale 상태였음. 실측은 origin/beta(HEAD 2f6b90f69) 기준. alpha는 beta보다 1,754건 앞서 있고, 공통조상은 5/2.

핵심 직접 cherry-pick 10건의 진짜 긴급도

경로 라벨이 아니라 실제 긴급도로 재판정. "다음 목요일까지 못 기다리나?"를 건별로 적용.

PR내용긴급도정기배포 가능?
#8620결제 USD 100배 오표시 수정P0 결제❌ cherry 정당
#8626영수증 PG 문구 Paddle/Toss 분기P1 결제표시△ 경계
#8615마켓 화이트리스트 422 (기능 막힘)P1△ 경계
#8631complete 세션 silent 422 null 가드P1△ 경계
#8630분석탭 당일 세션 날짜경계 버그P2 버그✅ 가능
#8663노이즈필터 해제 시 미분류 누락P2 버그✅ 가능
#8618Paddle 슬랙알림 (#8614와 중복)feat✅ 가능
#8624시퀀스 목록 집계 3.3× 가속perf✅ 가능
#8677trial 분석 커스텀 날짜범위feat✅ 가능
#8637signup 공용도메인 (빈 커밋 0파일)노이즈✅ 가능
1
진짜 못 기다릴 P0
6
정기배포로 충분 (perf 1·feat 3·P2 2)

→ 공지의 "9건 중 상당수가 긴급 핫픽스가 아니었다"는 정확히 입증된다.

공지가 놓친 더 심각한 신호

중복 투입#8614(sync to beta)#8618(cherry-pick)동일한 Paddle 슬랙알림 기능. 같은 변경이 두 경로로 두 번 들어감. 프로세스 혼란의 직접 증거.

beta-only drift 3건#8617 · #8668 · #8670은 alpha에 아예 없음. 특히 #8617은 "#8586 squash 누락 복구" — cherry-pick 남용보다 더 위험한, 이미 시작된 alpha↔beta drift.

A 공지 주장별 검증

공지 주장검증 결과
"9건 중 상당수 긴급 아님" 정기배포 충분 6/10, 진짜 P0 1건
"정기배포가 빈 껍데기" #8612 sync 3분 뒤(#8614)부터 우회 시작
"drift 누적" 분석이 공지보다 강함 — beta-only 3 + squash 누락
"추적 어려움" 라벨 5종 난립 (체리픽/cherry-pick/(beta)/[beta sync]/sync to beta)
"QA 커버리지 감소" 논리는 타당, 정량 증거(soak)는 미제시

보완점 3가지

  1. 숫자 "20건 중 9건"은 미세 오차 (실측 21건·사후 cherry 10·beta-only 3) — 방향성은 정확.
  2. 더 위험한 beta-only drift를 공지가 누락.
  3. "자문해보자"는 권고일 뿐 강제장치 없음 → 라벨 규칙/CI 게이트 없으면 재발.

B "빠른 개선을 유저에게 바로" — 검증

짧은 피드백 루프·조기 가치 전달은 옳은 본능이다. 하지만 이번 케이스로 비용·편익을 실측하면:

산 것 (편익)
perf/feat 6건이 목요일 대신 6/15에 출시 → 평균 며칠 단축
치른 것 (비용)
기능 중복(#8614=#8618), squash 누락→beta 직접복구, alpha 미반영 3건, 추적 불가

핵심 논점 3

  1. "빠름"의 진짜 병목은 정기배포가 아니라 주기가 길다는 것. 주 1회(목)가 답답하면 해법은 cherry-pick 상시화가 아니라 배포주기를 주 2회로 당기는 것. cherry-pick은 속도를 "외상"으로 사고 drift로 갚는다.
  2. 속도가 정말 필요한 건 P0뿐이고, P0는 이미 예외 허용된다. 공지가 막는 건 perf/feat뿐 — 시퀀스 가속·trial 필터를 3일 빨리 본다고 전환율은 안 바뀐다.
  3. 진짜 빠르게 보여주려면 cherry-pick 말고 feature flag. alpha에서 flag로 켜 검증 → 정기배포로. 안전망(soak/QA) 유지하며 속도 확보가 정공법.
예외 인정 — 반값 이벤트(#8642 50% 프로모션)처럼 시한성 마케팅은 빠름이 곧 매출 → cherry 정당. 즉 진짜 다툼은 "빠름 vs 안정"이 아니라 "무엇이 진짜 시한성 있나"의 판정이다.

권고 (우선순위)

  1. beta-only 3건 alpha 역동기화 백로그 등록 (#8617·#8668·#8670) — 다음 정기 sync에서 충돌·유실 전에. 가장 시급.
  2. #8586 squash 누락 재발방지 — squash merge 시 alpha↔beta diff 검증 게이트.
  3. 핫픽스 채널 공식화 — P0 cherry는 허용하되 라벨 hotfix(beta): 표준화 + alpha 백포트 동시 의무화.
  4. (빠름을 원하면) 배포주기 단축 + flag 기반 점진 출시 — cherry-pick 기본값화의 지속가능한 대안.