v0.17.7 — 통계 게시 대기와 중복 검증을 줄이는 릴리스 (2026-09-10)
- 기간: 2026-09-09 ~ 2026-09-10. 오너 지시: “너 목표는 17.7 릴리스 최종 main 머지야”, “ci는 진짜 최소로만”.
- 랜딩: 앱 통합 PR #1484 → staging #1488 → main #1489. main
937042d775049b96ad00438fbe4019e1ec464e0c는 2026-09-10 01:10:48 KST에 병합됐고, 검증한 release mergee56604cb0ae4d9fcaa361fbd99c3978dabb60535와 tree12d339cd21d807000671f80e69de477e4d592d64가 같다. 운영 배포·smoke 성공 후 v0.17.7이 01:15:01 KST에 발행됐고 문서·관리자 주소의 운영 전환도 완료했다. - 설계서: 각 원 이슈의 승인된 Phase 계획과 저장소 경계, 통계 게시 예약 기록.
- 정본: 앱의 실행 코드와 문서·관리자 운영, 로컬 CI, 사후 브라우저 점검.
- 도구: 앱
merge:request, GitHub Actions 및gh run watch. HQ의 임시 재현 자료는 로컬 작업 폴더에 보관하며 앱에 기록용 커밋을 추가하지 않았다. - 게이트: 전체 큐 CI, 환경별 배포·smoke, 관리자 API/연결 확인. 첫 전체 실행의 pgTAP는 130파일·2,328개 단언 통과였으며 별도 precheck 중복 실행 생략은 오너가 승인했다. 최종 실행 결과는 아래에 구분한다.
Phase 현황
| Phase | 내용 | 상태 |
|---|---|---|
| Phase 1 | 승인된 변경 통합 및 문서 없는 후보의 선행 큐 호환 | 코드 통합, 선행 staging #1486/main #1487 완료 |
| Phase 2 | 최종 후보 검증과 release 병합 | 전체 CI 성공, release #1484 병합 완료 |
| Phase 3 | staging 배포·관리자/문서 연결·main 승격 | 완료. staging/Production 배포·smoke, main #1489·태그, 문서·관리자 운영 주소 전환 확인. 사후 브라우저 실패는 아래 별도 기록 |
1. 배경
v0.17.6이 main에 병합된 뒤 다음 패치 릴리스에 예정된 작업을 HQ에서 함께 통합했다. 처음 범위는 #1463·#1464·#1465·#1468·#1470·#1476·#1477·#1480의 8개였다. #1478은 오너가 명시적으로 제외했다. #1485는 첫 전체 검증 전에 준비되면 포함하라는 별도 지시에 따라 추가됐다.
작업마다 같은 기반을 전체 검증하는 대신 한 통합 후보를 만들고 필요한 수리만 좁게 재현했다. 소스 검증과 실제 환경 배포, 문서·관리자 독립 호스팅 전환은 각각의 증거로 확인한다.
2. 문제 제기
문서가 없는 앱 후보를 기존 main의 큐가 처리하지 못했다
신뢰하는 main에서 실행되는 큐가 후보의 docs 설치·빌드와 문서 성공 증거를 필수로 요구했다. #1463의 최종 후보는 모든 문서를 별도 저장소로 옮기므로 선행 호환이 필요했다.
통합 뒤 드러난 테스트 조건을 그대로 두면 전체 검증을 반복하게 됐다
스키마 지문 생성물 한 줄이 뒤처져 단위 검사 2개가 실패했다. 반복 장애 뒤 실제 앱이 사용하는 30초 탐색 간격 두 번을 새 10초 동작 대기로 기다리던 CASE-015/029/039/041도 수정이 필요했다. CASE-039/040의 구버전 빌드는 Windows 긴 작업 경로에서 Git checkout이 실패해 건너뛰었다.
3. 해결 방안
오너 결정
- D1: “여기서 1478 빼고 전부임” — 지정 8개를 통합하고 #1478을 제외했다.
- D2: #1485가 빠르게 준비되면 17.7에 포함 — 첫 전체 CI 전에 준비되어 포함했다.
- D3: “응 바로 병합해줘 관리자예외로” — CI 선행 2파일만 staging/main에 반영하고 그 두 승격의 중복 full과 앱/DB 재배포를 생략했다.
- D4: “승인 — 사전검증 생략, 전체 CI 1회” — 같은 정적·단위·DB 검사를 별도 precheck에서 다시 실행하지 않았다.
- D5: “아니 내가 이거 알아서 진행하라그랬는데 뭘 승인을 기다려” — HQ가 추가 승인 대기로 멈춘 것을 바로잡고 필요한 최종 검증과 승격을 계속한다. 같은 성공 tree의 승격 전체 CI는 중복 실행하지 않으며 실제 배포와 점검은 유지한다.
접근
| 선택 | 이유 |
|---|---|
| 통합 후보 한 개의 전체 검증 | 작업별 중복 실행을 줄이고 최종 조합을 확인한다. |
| 실패 케이스만 재현·수리 | 이미 확인한 다른 범위를 매번 다시 실행하지 않는다. |
| 테스트 타이머 진행 및 실제 응답 확인 | 앱의 복구 정책과 60초/10초 제한을 유지하며 재전송·DB·완주 단언을 검증한다. |
| Git 명령에만 longpaths 적용 | 사용자 전역 설정에 의존하지 않고 실제 긴 경로 checkout을 처리한다. |
| 제한 시간 확대·재시도 추가는 채택하지 않음 | 원래 검증 요구를 완화하지 않는다. |
4. 적용한 내용
| 작업 | 변경 |
|---|---|
| #1463 | 모든 문서와 관리자 프런트엔드를 Barbelic-docs로 이관. 앱에는 구현·테스트·실행 설정과 안내 링크만 유지한다. |
| #1464 | 정적·단위·DB·브라우저 병렬화, 브라우저 기본 4묶음, 소유 샌드박스 정리. |
| #1465 | 기존 통계 3단계 예약을 1초로 조정하고 오래된 해당 cron 실행 로그 정리. |
| #1468 | 케이스 60초·동작 대기 10초·자동 재시도 0회. |
| #1470 | 유저 실사용 시뮬레이션·화면 정합성 검사로 표시 이름 변경. |
| #1476 | 같은 tree의 성공한 전체 검증 결과를 확인해 재사용하는 경로. |
| #1477 | 앱에 남은 홍보 랜딩 코드와 참조 제거. 랜딩 정본은 Barbelic-landing. |
| #1480 | 재사용 배포 워크플로 호출자의 쓰기 권한. |
| #1485 | Production smoke 뒤 태그를 발행하고 사후 브라우저 점검을 별도로 실행·보고. |
신규 SQL은 20260914000000_stats_projection_cadence.sql 한 개이며 위험은 medium이다. 기존 작업 명령·소유자·중지 상태와 Production의 6초 게시 설정을 보존한다. 해당 작업의 7일 지난 완료 운영 로그만 10분마다 최대 5,000개 정리하고 사용자 원본은 수정하지 않는다.
작업 중 드러난 것
- 첫 전체 CI 34364544193: 전체 검사 7분 37초/Actions 작업 9분 16초 후 실패. 정적·단위 묶음 2·DB·화면 검사 22개는 통과했고 단위 2개/브라우저 3개 실패, 구버전 2개 건너뜀을 성공으로 바꾸어 보고하지 않았다.
- 생성물은 기존 db:model로 한 줄 재생성했다. 복구 테스트는 실제 서버 probe를 확인하며 브라우저 타이머만 진행했다. CASE-015/029/041과 마지막 CASE-039/040 모두 개별 검증에서 retry/skip/flaky 없이 통과했다.
- CASE-040의 임시 재현기는 실제 큐에 없는 NODE_ENV=test로 개발 React를 빌드했다. 이때 종료된 조회 객체 오류가 관측됐지만 정상 큐 빌드 조건에서는 소스 변경 없이 통과했다. 이 관측을 배포 제품 결함으로 단정해 별도 앱 수리로 확대하지 않았다.
- 수정본 실행 34372350355는 2분 53초 후 unit 로그 쓰기의 Windows EBUSY 오류로 중단됐다. 같은 로그를 복사하던 HQ 보조 작업과 충돌했을 가능성이 있어 그 작업을 비활성화하고 남은 소유 빈 네트워크만 정리했다. 테스트 결과가 완결되지 않아 전체 성공·실패 케이스 수로 합산하지 않는다.
- 최종 전체 CI 34372922344는 보조 로그 복사 없이 2026-09-10 01:00 KST에 성공했다. 전체 검사 7분 32초/Actions 작업 9분 17초이며, 검증한 merge commit 그대로 release에 반영했다.
- 이번 큐를 실행한 기존 main
65a12274에는 #1476 장부 기록이 없었으므로 후보의 재사용 함수를 그 큐가 이미 호출했다고 주장하지 않는다. 새 main937042d7에는 해당 코드가 도달했지만, 실제 성공 장부 생성·후속 재사용 실행은 이번 릴리스에서 추가로 돌리지 않았다. 승인한 동일 tree 승격 예외와 향후 실제 자동 재사용 증거를 구분한다. - staging 승격 자동 CI 34374138225와 main 승격 34375064318은 관리자 병합으로 PR이 이미 닫혀 있다는 scope 조건에서 종료됐다. 제품 검사는 모두 실행 전 건너뛰었으며 이 실행들을 성공으로 세지 않는다. 같은 tree의 큐 성공 증거로 승격했고 중복 CI를 다시 실행하지 않았다. main 실행 취소 명령을 보냈을 때는 이미 종료된 상태였으므로 취소 성공으로 기록하지 않는다.
5. 적용 결과
| 항목 | 결과 |
|---|---|
| 통합 범위 | 지정 8개 + 조건부 준비된 #1485, #1478 제외 |
| 선행 큐 호환 | staging #1486 / main #1487, 기존 38개 검사 통과 tree와 동일 |
| 생성물 단위 실패 | 2실패 → 같은 2검사 통과 |
| 브라우저 개별 수리 | 015 16.351초 / 029 28.704초 / 041 20.087초 / 039 26.045초 / 040 19.010초, 모두 첫 시도 통과 |
| 최종 전체 CI | 7분 32초 성공. 정적·단위 3,423건, 기존 조건부 제외 30건. pgTAP 130파일·2,328 assert 및 DB 실사용 검사 통과. 브라우저 56건/화면 22건, 실패·제외·flaky 0건, 증거 게이트 통과 |
| 5분 내외 CI 목표 | 이번 실제 full은 7분 32초, 작업 전체 9분 17초로 5분 목표 미달. 성공하지 않은 과거 실행과 단순 비율 비교해 개선율을 만들지 않음 |
| release/staging/main | release #1484 / staging #1488 / main #1489 병합 완료. 세 단계의 tree가 모두 동일 |
| 실제 staging 배포 | 34374171430 성공. DB 64초·Edge 28초·앱 74초·smoke 24초, 실제 CRUD 12건 통과 |
| 실제 관리자 API | staging 12검사 통과. 두 허용 origin OPTIONS204, 비허용403, 무인증401, 일반사용자403, 관리자200, 정확 migration/Edge·no-store·CORS. 임시 Auth2명 삭제 후404 부재 확인 |
| 실제 관리자 주소 연결 | staging docs/admin 양쪽 정상 인증의 proxy HTML/JS200 및 upstream 일치. Production docs 배포 dpl_3S3U2Dti3wHevNaijjjbLPPvmAJ1에서 기존 관리자 주소·JS·문서·docs/앱 양쪽 원문 27확인 통과. 보호 설정 변경 없음 |
| 실제 Production 배포 | 34375087828의 DB 72초·Edge 34초·앱 67초·smoke 29초 성공. 실제 CRUD 12건, 실패·제외0. 공개 www.barbelic.com이 이번 배포를 제공함도 확인 |
| 릴리스 태그와 사후 점검 | smoke 01:14:43 완료 → 태그 잡 01:14:47 시작 → v0.17.7 01:15:01 발행. 브라우저 잡은 01:14:48~01:19:10 독립 실행해 5통과·10실패. 태그는 먼저 발행됐고 실패 알림은 01:19:16 자동 등록 |
| Production 관리자 API 경계 | 허용 docs/admin origin OPTIONS204, 무인증401·no-store, 비허용 origin GET/OPTIONS403 확인. 관리자 Bearer 양성은 staging에서 검증했으며 Production 양성으로 확대하지 않음 |
| 문서 자동배포 토큰 | 아직 미설정. 확인된 기존 CLI 로그인으로 이번 배포가 가능하며 두 상태를 구분 |
staging proxy에서 처음 보인 Vercel 로그인 화면은 docs 프로젝트의 인증만으로 독립 admin 프로젝트도 통과하려던 검증 조건 때문이었다. 두 프로젝트의 정상 인증을 함께 제공한 뒤 연결을 확인했고, 코드 수리나 보호 해제는 하지 않았다. 이 결과를 무자격 공개 접근 성공으로 확대하지 않는다. 기존 문서 경로와 약관·개인정보 4버전, 사업자 정보, 스타일, 계정 삭제 안내 11파일의 원문 일치도 확인했다.
Production 사후 브라우저 점검은 실제 테스트 단계가 exit1로 끝났고 성공 표식은 생성되지 않았다. 전체 워크플로가 비차단 설정으로 success여도 브라우저 검사가 통과했다는 뜻은 아니다. 결과 업로드와 자동 실패 보고는 성공했다. 이번 실행은 태그 독립·테스트 실패·성공 표식 누락·자동 보고 경로의 실제 증거이며, 40분 잡 시간초과와 준비 단계 실패는 발생하지 않아 실증하지 않았다. 브라우저 10실패를 해결했다고 기록하지 않는다.
실패 ID와 직접 오류는 #1485의 기존 로그 요약에 남겼다. 복원/작성 창이 클릭을 가리는 현상, 초안·화면 요소 기대 불일치, 통계 정리 오류, CASE-029/039의 로컬 service-role 요구 등이 관측됐지만 공통 원인이나 실제 사용자 영향을 확정하지 않았다. 원래 태그 누락 수리는 BUG-089로 기록하며 새로운 브라우저 수리 과제를 추가하지 않았다.
6. 이번 개선으로 향상된 것
문서·관리자·랜딩 단독 변경의 앱 검증 비용을 분리한다
각 저장소는 자기 변경의 검사와 게시만 수행한다. 공통 DB·백엔드 계약은 앱이 한 곳에서 소유하며 문서 이관이 사용자 기록 이동으로 확대되지 않는다.
필요한 전체 검증과 중복 실행을 구분한다
최종 조합을 확인한 뒤 같은 코드의 승격에서는 검증 증거를 유지하고 환경별 배포를 확인한다. 케이스 시간 제한과 재시도 0은 느리거나 불안정한 검사를 드러내며 실제 재전송·저장·재조회 확인은 보존한다.
확인 범위와 한계
main 병합·운영 배포·기본 동작 검사·태그 발행·문서/관리자 서비스 전환은 완료했다. Production 사후 브라우저는 5통과·10실패이며 실패 사실을 자동 보고했다. 독립 문서/관리자 Actions 자동배포는 토큰 미설정으로 비활성이고 이번 서비스 게시는 기존 CLI로 수행했다.
외부 제공자 로그인 전체는 검증하지 않았다. docs/admin 복귀 주소로 Kakao·Google·Apple 로그인 시작 6개 요청의 제공자302 이동은 확인했지만 반환 state에서 최종 복귀 주소를 확인하지 못했다. 이를 callback 허용이나 로그인 완료 증거로 확대하지 않는다.