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

RDC · 배포관리 화면 시안 · 3분할
위 = 실제 화면(제품 UI) · 아래 = 그 화면의 설명(배포 흐름 · 단계별 정의). 흐름 단계를 누르면 정의가 강조됩니다.
①실제 화면운영자가 보는 제품 UI
작성중 승인대기 배포가능 배포중 완료 취소
※ 상태 시연용 — 각 상태가 최소 1개씩 보이게 구성 · ⚠ = 조치 필요(재승인·부분실패)
릴리스상태업무승인일시
소유자 bit · 정기배포 · 승인 완료 → 배포 버튼 활성
업무단위
PR검사
머지
테스트(IT·PM)
배포결과
TFDOL-101
통과
통과
통과
대기
TFDOL-201
통과
통과
통과
대기
TFDOL-205
통과
통과
통과
대기
🔬 SAST 통과↗ · 영향도분석 통과↗ · 보안성검토 통과↗ · 릴리스 태그 rdc-v2026.06
게이트 통과 → 승인 4인 → 배포
소유자 bit · 릴리스 태그 완료 → 게이트 통과 → 4인 승인 받는 중
업무단위
PR검사
머지
테스트(IT·PM)
배포결과
TFDOL-220
통과
통과
통과
대기
TFDOL-221
통과
통과
통과
대기
🔬 SAST 통과↗ · 영향도분석 통과↗ · 보안성검토 통과↗ · 릴리스 태그 rdc-v2026.07-B
전 업무단위 머지 → 동결 → 승인 진행중(2/4) · 본인작성 본인승인 불가
소유자 bit · 봉인 후 코드 변경 → 기존 승인 4/4 무효(0/4) · 배포 잠김
업무단위
PR검사
머지
테스트(IT·PM)
배포결과
TFDOL-401
통과
통과
통과
대기
TFDOL-402
통과
통과
통과
대기
TFDOL-403
통과
통과
통과
대기
TFDOL-404
통과
통과
IT만
대기
🔬 SAST 재스캔 대기 · 영향도분석 재스캔 대기 · 보안성검토 재스캔 대기 · 태그 rdc-v2026.08 무효 → 재태그 필요
승인 무효 → 재태그·자동 스캔·증적 보완 후 4인 전원 재승인해야 배포 가능
PM이 할 일: ⓐ 추가된 TFDOL-404 확인 ⓑ 시나리오 증적 다시 업로드(코드가 바뀌어 이전 증적 무효) ⓒ 4인에게 재승인 요청 — 재태그·스캔·알림은 RDC가 자동 · TFDOL-404의 IT 증적은 그 개발자가 올림
소유자 bit · 업무단위들이 게이트(분석·테스트·머지) 통과 중
배포티켓 ①(에픽) → PrimeKR-API ▾ · ⑵단계: 빈 버전 상세에서 배포티켓 만들며 대상서비스 연동(1개↔1개)
브랜치 미활성 · PM이 개발 착수 전 클릭 → main에서 release 브랜치 생성(PM 역할)
업무단위
PR검사
머지
테스트(IT·PM)
배포결과
TFDOL-310
통과
통과
대기
대기
TFDOL-311
검사중
대기
대기
대기
TFDOL-312
실패
–
–
대기
TFDOL-313
대기
대기
대기
대기
🔬 SAST 대기 · 영향도분석 대기 · 보안성검토 대기 · 전 PR 머지 후 릴리스 태그에서 1회
게이트 미통과 → 배포 불가
PR검사(정적·영향도+approve) 통과분만 머지 → 전 업무단위 머지되면 릴리스 태그 → 자동 스캔 → 테스트증적 → 승인대기.
소유자 bit · 핫픽스 · DevOps 실행 → Jenkins 진행 중 (핫픽스 = 4인 전원 승인 · 전체 게이트)
업무단위
PR검사
머지
테스트(IT·PM)
배포결과
TFDOL-290
통과
통과
통과
성공
TFDOL-291
통과
통과
통과
부분실패
🔬 SAST 통과↗ · 영향도분석 통과↗ · 보안성검토 통과↗ · 릴리스 태그 rdc-vhf2026.06.24
실패분은 DevOps가 젠킨스에서 조치(성공분 유지) · 조치 후 담당자가 성공 복구 처리젠킨스에서 조치 ↗
부분실패 = 실패분만 멈춤 · RDC 자동 복구 없음 — 젠킨스 조치 후 성공 복구 (성공분은 유지).
소유자 bit · 핫픽스 · DevOps 실행 시도 → Jenkins 연동 오류 (핫픽스 = 4인 전원 승인)
업무단위
PR검사
머지
테스트(IT·PM)
배포결과
TFDOL-289
통과
통과
통과
실패
🔬 SAST 통과↗ · 영향도분석 통과↗ · 보안성검토 통과↗ · 릴리스 태그 rdc-vhf2026.06.23
실패분만 재시도(성공분 유지)
실행 실패 = Jenkins 연동 오류 → 재시도 대기.
소유자 bit · 정기배포 · 5개 업무단위 전부 통과·승인·배포 완료 · 릴리스노트 자동 작성 · 증적 불변 보존 · Jira released
업무단위
PR검사
머지
테스트(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) 취소 · 사유: 일정 변경 — 배포 전 취소 · 취소 사유·시각 로그 보존
업무단위
PR검사
머지
테스트(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 ▾
※ 시각은 모두 KST · 회색 글씨는 모두 실제 기록되는 값(SHA·빌드번호·태그·파일명 등) — 설명·주석은 화면에 찍히지 않음
※ 재승인 루프 포함 — 첫 승인 2건을 받은 뒤 봉인 후 머지가 들어와 승인이 무효화되고, 재태그·재스캔·증적 재업로드 후 4인 전원 다시 승인한 흐름. 이력은 불변이라 무효가 된 옛 승인 줄도 그대로 남고, 무효 사실은 `재승인` 줄에 기록된다
※ 반복 이벤트는 건별로 쌓임 — 승인 4건·배포결과 5건은 펼쳐서 보여주고, PR등록·PR검사·머지·IT증적은 대표 1건만 표시(실제로는 티켓·PR마다 쌓임)
※ 승인 4인 = gary(CPO) · jake(CTO) · jamie(정보보안팀장) · winnie(DevOps팀장) — 각자 1건씩 · 부재 시 그 석의 대리 승인자가 채움
2026-06-21 09:30PM/bitmain반영[main 머지] 클릭 → release/2026.05 → main
2026-06-20 15:05RDC 자동완료릴리스 완료 — Jira 버전 released(API)
2026-06-20 15:04RDC 자동결과TFDOL-505 배포 성공 (Jenkins #1284 ↗)
2026-06-20 15:03RDC 자동결과TFDOL-504 배포 성공 (Jenkins #1283 ↗)
2026-06-20 15:03RDC 자동결과TFDOL-503 배포 성공 (Jenkins #1282 ↗)
2026-06-20 15:02RDC 자동결과TFDOL-502 배포 성공 (Jenkins #1281 ↗)
2026-06-20 15:01RDC 자동결과TFDOL-501 배포 성공 (Jenkins #1280 ↗)
2026-06-20 15:00데브옵스/winnie실행배포 → Jenkins 트리거 (멱등키 rel-2026.05#1 · SHA f4e5d6a)
2026-06-20 11:52승인권자/winnie승인승인 4/4 완료 — DevOps팀장석(정) · 태그 rdc-v2026.05-2
2026-06-20 11:45승인권자/jamie승인승인 3/4 — 정보보안팀장석(정) · 태그 rdc-v2026.05-2
2026-06-20 11:38승인권자/jake승인승인 2/4 — CTO석(정) · 태그 rdc-v2026.05-2
2026-06-20 11:30승인권자/gary승인승인 1/4 — CPO석(정) · 태그 rdc-v2026.05-2
2026-06-20 11:20PM/bitPM증적PM 시나리오 테스트증적 재업로드 (scenario-2026.05-2.png · 3장)
2026-06-20 11:15디벨로퍼/bobbyIT증적IT 테스트증적 업로드 — TFDOL-506 (TFDOL-506-it.png · 1장)
2026-06-20 11:12RDC 자동태그스캔태그 자동 스캔 PASS — SAST·영향도분석·보안성검토 (rdc-v2026.05-2)
2026-06-20 11:10RDC 자동태그릴리스 재태그 rdc-v2026.05-2 — 커밋 묶음 봉인
2026-06-20 11:06RDC 자동재승인봉인 후 코드 변경 감지 — 이전 승인 2건 무효(2/4 → 0/4) · 배포 잠금 · 승인대기로 되돌림 (rdc-v2026.05 → rdc-v2026.05-2)
2026-06-20 11:05디벨로퍼/bobby머지TFDOL-506 → release 머지 (SHA 4c5d6e7 · 태그 봉인 후 추가)
2026-06-20 10:58승인권자/jake승인승인 2/4 — CTO석(정) · 태그 rdc-v2026.05
2026-06-20 10:45승인권자/gary승인승인 1/4 — CPO석(정) · 태그 rdc-v2026.05
2026-06-20 10:40PM/bitPM증적PM 시나리오 테스트증적 업로드 (scenario-2026.05.png · 3장)
2026-06-20 10:20디벨로퍼/bobbyIT증적IT 테스트증적 업로드 — TFDOL-501 (TFDOL-501-it.png · 2장)
2026-06-20 09:35RDC 자동태그스캔태그 자동 스캔 PASS — SAST·영향도분석·보안성검토
2026-06-20 09:30RDC 자동태그릴리스 태그 rdc-v2026.05 — 커밋 묶음 봉인
2026-06-19 17:40디벨로퍼/bobby머지TFDOL-501 → release 머지 (SHA 9f8e7d1)
2026-06-19 17:20RDC 자동PR검사TFDOL-501 PR 검사 PASS — SAST·영향도 + approve 확인
2026-06-19 17:10디벨로퍼/bobbyPR등록TFDOL-501 PR #482 올림
2026-06-17 10:00PM/bit활성화[활성화] 클릭 → main에서 release/2026.05 생성 (기준 main SHA c3d4e5f)
2026-06-17 09:00PM/bit수정릴리스일자 2026-06-18 → 2026-06-20
2026-06-16 16:05PM/bit연동배포티켓 TFDOL-505 생성 · 대상서비스 연동 (PrimeKR-Web)
2026-06-16 14:20PM/bit연동배포티켓 TFDOL-501 생성 · 대상서비스 연동 (PrimeKR-API)
2026-06-16 14:10PM/bit생성릴리스버전 R-2026.05 생성 (릴리스일자 2026-06-18 · Flex REQ-2026-071)
1–32 / 139건 · 최신순25개씩 ▾
페이지당 25건(기본)·정렬·필터 같은 화면 상세는 PRD/구현 몫 — 통제 요건은 누락 없이 전량 기록·조회(R5)와 CSV 전량 내보내기.
ⓘ 추가만 가능 · 수정·삭제 불가 · 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 머지] PM이 [활성화] 버튼으로 생성 tag release 브랜치 — 전 feature 머지 → tag 후, 아래를 1회 실행SAST · 영향도분석 · 보안성검토 → 테스트증적 확인 → 승인 → 배포
📖 아래는 위 실제 화면에 대한 설명 — 배포 흐름 & 단계별 정의
②배포 흐름게이트 = 청록 테두리
단계를 누르면 ③ 정의의 해당 줄이 강조됩니다 ↘
↓
↓
↓
↓
↓
↓
↓
↓
③단계별 정의누가 · 무엇을 · 규칙
단계누가무엇을 / 규칙
① 릴리스 생성PM·RDCPM이 [릴리스 생성] → RDC가 Jira에 빈 버전 생성(릴리스일자 함께) · 이어서 릴리스 상세에서 배포티켓(에픽) 생성 + 대상서비스 1:1 연동 · Flex 근거 연결
② 브랜치 활성화 → 개발 → PRPM·개발자PM이 개발 착수 전 [활성화] 클릭 → main에서 release 브랜치 생성(누가·언제 기록) → 개발자가 개발 후 Bitbucket에 PR
③ PR 검사자동·BitbucketPR마다 정적분석(SAST·영향도) + approve 확인 — 둘 다 통과해야 머지(fail-closed)
④ 머지개발자·Bitbucket통과분만 release로 머지 · RDC는 머지정보 트래커 연계로 확인(소유 아님)
⑤ 릴리스 태그 → 자동 스캔자동·RDC전 PR 머지 → 릴리스 태그 = 커밋 묶음 봉인 → 그 태그에서 SAST·영향도·보안성 자동 1회 · 통과 못 하면 차단
⑥ 테스트증적 업로드개발자·PMRDC 화면에서 직접 업로드 — IT=개발자·에픽별 / PM=시나리오·릴리스 단위(전 머지 후) · 코드 아닌 UI 화면 이미지 · 저장 S3 · 없으면 차단
⑦ 승인승인권자 4인Slack 전원 승인 · 본인작성은 본인 승인 불가 · 그 태그를 승인 — 이후 release에 머지가 더 들어오면 승인 전부 무효(4/4→0/4)·배포 잠금 → 재태그·재승인(4인 전원)
⑧ 실행데브옵스RDC에서 클릭 → Jenkins 트리거 · 콘솔 직접 배포 차단 · 멱등
⑨ 결과·완료자동·PM성공→완료 / 부분실패→배포중 유지(젠킨스에서 조치 후 성공 복구) · 불변 기록 · RDC → Jira 버전 released(API) · 운영 이슈 없음 확인 후 [main 머지]