RDC 배포관리 3분할 화면 시안. 좌측은 실제 화면 목업(현황·등록·이력 탭), 우측 상단은 배포 흐름, 우측 하단은 각 단계 동작 설명표. 흐름 단계를 클릭하면 설명표의 해당 줄이 강조된다.

RDC · 배포관리 화면 시안 · 3분할
위 = 실제 화면(제품 UI) · 아래 = 그 화면의 설명(배포 흐름 · 단계별 정의). 흐름 단계를 누르면 정의가 강조됩니다.
①실제 화면운영자가 보는 제품 UI
작성중 승인대기 배포가능 배포중 완료 취소
※ 상태 시연용 — 각 상태가 최소 1개씩 보이게 구성
릴리스상태업무승인일시
소유자 bit · 정기배포 · 승인 완료 → 배포 버튼 활성
업무단위
머지
테스트(IT·PM)
배포결과
TFDOL-101
통과
통과
대기
TFDOL-201
통과
통과
대기
TFDOL-205
통과
통과
대기
🔬 SAST 통과↗ · 영향도분석 통과↗ · 보안성검토 통과↗ · 릴리스 태그 rdc-v2026.06
게이트 통과 → 승인 4인 → 배포
소유자 bit · 릴리스 태그 완료 → 게이트 통과 → 4인 승인 받는 중
업무단위
머지
테스트(IT·PM)
배포결과
TFDOL-220
통과
통과
대기
TFDOL-221
통과
통과
대기
🔬 SAST 통과↗ · 영향도분석 통과↗ · 보안성검토 통과↗ · 릴리스 태그 rdc-v2026.07-B
전 업무단위 머지 → 동결 → 승인 진행중(2/4) · 본인작성 본인승인 불가
소유자 bit · 업무단위들이 게이트(분석·테스트·머지) 통과 중
배포티켓 ①(에픽) → PrimeKR-API ▾ · ⑵단계: 빈 버전 상세에서 배포티켓 만들며 대상서비스 연동(1개↔1개)
업무단위
머지
테스트(IT·PM)
배포결과
TFDOL-310
대기
대기
대기
TFDOL-311
대기
대기
대기
TFDOL-312
대기
–
대기
TFDOL-313
대기
대기
대기
🔬 SAST 대기 · 영향도분석 대기 · 보안성검토 대기 · 전 PR 머지 후 릴리스 태그에서 1회
게이트 미통과 → 배포 불가
전 업무단위 머지되면 릴리스 태그 → SAST·영향도분석·보안성검토 → 승인대기.
소유자 bit · 핫픽스 · DevOps 실행 → Jenkins 진행 중 (핫픽스 = 4인 전원 승인 · 전체 게이트)
업무단위
머지
테스트(IT·PM)
배포결과
TFDOL-290
통과
통과
성공
TFDOL-291
통과
통과
부분실패
🔬 SAST 통과↗ · 영향도분석 통과↗ · 보안성검토 통과↗ · 릴리스 태그 rdc-vhf2026.06.24
실패분은 DevOps가 젠킨스에서 조치(성공분 유지) · 조치 후 담당자가 성공 복구 처리젠킨스에서 조치 ↗
부분실패 = 실패분만 멈춤 · RDC 자동 복구 없음 — 젠킨스 조치 후 성공 복구 (성공분은 유지).
소유자 bit · 핫픽스 · DevOps 실행 시도 → Jenkins 연동 오류 (핫픽스 = 4인 전원 승인)
업무단위
머지
테스트(IT·PM)
배포결과
TFDOL-289
통과
통과
실패
🔬 SAST 통과↗ · 영향도분석 통과↗ · 보안성검토 통과↗ · 릴리스 태그 rdc-vhf2026.06.23
실패분만 재시도(성공분 유지)
실행 실패 = Jenkins 연동 오류 → 재시도 대기.
소유자 bit · 정기배포 · 5개 업무단위 전부 통과·승인·배포 완료 · 릴리스노트 자동 작성 · 증적 불변 보존 · Jira released
업무단위
머지
테스트(IT·PM)
배포결과
TFDOL-501
통과
통과
성공
TFDOL-502
통과
통과
성공
TFDOL-503
통과
통과
성공
TFDOL-504
통과
통과
성공
TFDOL-505
통과
통과
성공
🔬 SAST 통과↗ · 영향도분석 통과↗ · 보안성검토 통과↗ · 릴리스 태그 rdc-v2026.05
운영 문제 시 직전 성공 버전으로 되돌림(롤백) · 승인 없음·기록만(표준 변경) · 게이트 생략 (ADR 0002·0009)
롤백 · 직전 성공 버전(R-2026.05) 재배포 · 게이트 생략 · 승인 없음 · 기록만 (사전 승인된 표준 변경)
배포 결과 전 대상서비스 성공 ✅
롤백 = 이미 검증·승인된 직전 성공 버전만 · [롤백] 버튼 하나(버전 선택 없음) · 개별 승인 없이 전 과정 기록 · 필요 시 장애보고서(Flex) 작성 (ADR 0009 개정).
요청자(bit) 취소 · 사유: 일정 변경 — 배포 전 취소 · 취소 사유·시각 로그 보존
업무단위
머지
테스트(IT·PM)
배포결과
TFDOL-301
대기
대기
–
TFDOL-302
대기
대기
–
🔬 SAST 해당없음 · 영향도분석 해당없음 · 보안성검토 해당없음 · 태그 전 취소
새 릴리스 등록
유형정기·핫픽스 = 4인 전원 승인 · 전체 게이트 · (롤백은 새로 등록하지 않고 기존 릴리스에서 [롤백]으로)
버전R-2026.07 (자동 제안 · 수정 가능)
릴리스일자2026-07-15 (수정 가능)
소유자bit (요청자 = 본인)
Flex 근거REQ-2026-091 × REQ-2026-093 × · 여러 건 가능 · 요청서↔릴리스 1:1·1:n·n:n
ⓘ [릴리스 생성] 누르면 빈 릴리스버전만 만들어집니다. 이후 현황 → 그 릴리스 상세에서 배포티켓(에픽) 추가 → 대상서비스 연동(배포티켓 1개↔대상서비스 1개).
이력 · 감사 추적 불변 기록R-2026.05 ▾
※ 전 단계 예시(생성→main 머지) — 각 줄의 E·X 번호는 이력 이벤트 정의(wrdc-history-events.md) 매핑표와 1:1 · 태그(18종)·행위자(6종)는 같은 문서 §1·§2 사전
E14 · 2026-06-21 09:30PO/bitmain반영[main 머지] 클릭 → release/2026.05 → main (운영 이슈 없음 확인 후)
E13 · 2026-06-20 15:05RDC 자동완료릴리스 완료 — Jira 버전 released(API) (릴리스노트 자동 기록은 P1)
E12 · 2026-06-20 15:04RDC 자동결과배포 결과 성공 5/5 (업무단위별 · Jenkins 빌드 링크)
E11 · 2026-06-20 15:00어드민(데브옵스)/winnie실행배포 → Jenkins 트리거 (멱등키 rel-2026.05#1 · SHA f4e5d6a)
E10 · 2026-06-20 11:20승인권자/4인승인4/4 전원 완료 · 태그 rdc-v2026.05 승인 (CPO·CTO·정보보안팀장·DevOps팀장 · 각 승인 시각 개별 기록)
E9 · 2026-06-20 10:40PO/bit증적PM 시나리오 테스트증적 업로드 (릴리스 단위 · 전 머지 후 · UI 화면 이미지)
E8 · 2026-06-20 10:20디벨로퍼/bobby증적IT 테스트증적 업로드 — TFDOL-501 (에픽별 · UI 화면 이미지) 외 4건
E7 · 2026-06-20 09:35RDC 자동태그스캔태그 자동 스캔 PASS — SAST·영향도분석·보안성검토 (태그에서 1회)
E6 · 2026-06-20 09:30RDC 자동태그릴리스 태그 rdc-v2026.05 — 커밋 묶음 봉인 (이후 변경 시 재태그·재승인)
E5 · 2026-06-19 17:40디벨로퍼/bobby머지TFDOL-501 → release 머지 (SHA 9f8e7d1) 외 4건
E4 · 2026-06-19 17:20RDC 자동PR검사TFDOL-501 PR 검사 PASS — SAST·영향도 + approve 확인 외 4건
E3 · 2026-06-17 10:00디벨로퍼/bobbyrelease생성[release 생성] 클릭 → main에서 release/2026.05 생성
X7 · 2026-06-17 09:00PO/bit수정릴리스일자 2026-06-18 → 2026-06-20 (개체 필드 수정 — 이력은 전/후값으로 추가 기록될 뿐, E1은 안 바뀜)
E2 · 2026-06-16 16:05PO/bit연동배포티켓 TFDOL-505 생성 · 대상서비스 연동 (PrimeKR-Web — 나중에 1건 추가 → 별도 이벤트)
E2 · 2026-06-16 14:20PO/bit연동배포티켓 TFDOL-501 생성 · 대상서비스 연동 (PrimeKR-API) — 같은 시각 3건(외 2건)
E1 · 2026-06-16 14:10PO/bit생성릴리스버전 R-2026.05 생성 (빈 버전 · 릴리스일자 06-18[당시 값] · Flex REQ-2026-071 연결)
ⓘ 추가만 가능 · 수정·삭제 불가 · 3년 보존 — SOC2 증적
브랜치 전략 — 버전형 · main 트렁크
버전형 Git 브랜치 전략 — 여러 feature가 release로 모인 뒤 배포 파이프라인 1회 main이 트렁크다. 여러 feature 브랜치가 main에서 갈라져 나와 개발한 뒤 각각 PR로 release/버전 브랜치에 머지된다. 전 feature가 다 머지된 뒤 release 브랜치에서 태그·SAST·영향도분석·보안성검토·테스트증적·승인·배포를 1회 실행하고, 운영에서 이슈가 없으면 다시 main으로 머지한다. main release feature/* feature A feature B 각 PR(검사+approve) → release 머지 운영확인 → [main 머지] [release 생성] 버튼으로 생성 tag release 브랜치 — 전 feature 머지 → tag 후, 아래를 1회 실행SAST · 영향도분석 · 보안성검토 → 테스트증적 확인 → 승인 → 배포
📖 아래는 위 실제 화면에 대한 설명 — 배포 흐름 & 단계별 정의
②배포 흐름게이트 = 청록 테두리
단계를 누르면 ③ 정의의 해당 줄이 강조됩니다 ↘
↓
↓
↓
↓
↓
↓
↓
③단계별 정의누가 · 무엇을 · 규칙
단계누가무엇을 / 규칙
① 릴리스 생성RDC·요청자⑴ 생성 클릭 → Jira에 빈 릴리스버전만 생성 · ⑵ 릴리스 상세에서 배포티켓(에픽티켓) 만들며 대상서비스 연동(배포티켓 1개↔대상서비스 1개·젠킨스 셀렉) · Flex 근거 연결
② 개발 → PR개발자PR 올리기 전 릴리스 상세 [release 생성] 버튼 → main에서 release 브랜치 생성(누가·언제 기록 · R36) · Bitbucket에 PR — PR에서 정적분석(SAST·영향도) 자동 + approve, 통과해야 머지(fail-closed)
③ 머지개발자·Bitbucket검사·approve 통과분만 release로 머지 · RDC는 머지정보 트래커 연계로 확인(소유 아님)
④ 릴리스 태그 · SAST · 영향도분석 · 보안성검토자동·RDC전 PR 머지 → 릴리스 태그 → 그 태그에서 SAST · 영향도분석 · 보안성검토(자동 스캔) 1회 · 통과해야 다음(미통과면 차단)
⑤ 테스트증적 업로드IT·PM 담당자IT(개발자)=에픽 단위 / PM=릴리스 시나리오(전 머지 후) — 각자 RDC에서 직접 업로드(슬롯 분리) · 증적 = 코드 아닌 UI 화면 이미지(실제 테스트했음을 기록) · 저장=S3 · 없으면 차단
⑥ 승인승인권자 4인Slack 전원 승인 · 본인작성은 본인 승인 불가 · 그 태그를 승인(이후 코드 바뀌면 재태그·재승인)
⑦ 실행DevOps팀장RDC에서 클릭 → Jenkins 트리거 · 콘솔 직접 배포 차단
⑧ 결과·완료자동·요청자성공→완료 · 부분실패→배포중 유지(젠킨스에서 조치 후 성공 복구) · 불변 기록·릴리스노트 · RDC → Jira 버전 released(API) · 운영 이슈 확인 후 [main 머지] 버튼으로 main 반영·기록(R36)