릴리즈 Go/No-Go 판단을 위한 의사결정 데이터 설계

CI/CD, 보안, 운영 데이터를 결합해 릴리즈 Go/No-Go 판단의 재현성과 감사 가능성을 확보하는 데이터 설계 방법

2026-08-14 · 최초 발행 2025-12-23

출시 판단의 근거를 하나의 스냅샷으로 묶기

릴리즈 승인에는 테스트 결과만으로 충분하지 않다. 테스트와 커버리지, 취약점·라이선스, 변경 이력과 승인, 인시던트·SLO, 롤백 계획과 런북을 함께 봐야 한다.

릴리즈 Go/No-Go 의사결정 데이터 구성은 이 데이터를 수집하고 정규화한 뒤, 표준 스키마와 룰셋으로 결합해 승인 판단에 쓰는 아키텍처 및 프로세스다. 핵심 산출물은 증거 기반의 결정을 뒷받침하고 사후 감사와 재현을 가능하게 하는, 스냅샷 단위의 불변 데이터 패킷이다.

처리 흐름은 수집, 검증, 정규화, 스코어링, 결정 및 아카이빙으로 이어진다.

스냅샷·검증·승인 기록이 함께 남아야 한다

릴리즈 단위의 데이터 모델에는 스냅샷 ID, 서비스와 버전, 타임스탬프, 지표 값, 근거 링크, 승인 이력이 포함되어야 한다. append-only 원칙과 버전드 스키마를 적용하면 같은 판단을 나중에 다시 확인할 수 있고 감사 추적성도 확보된다.

수집 단계에서는 스키마 레지스트리와 DQ 룰로 필수 필드, 값 범위, 참조 무결성을 검증한다. 검증에 실패한 레코드는 격리하고 재처리 큐로 보내며, SLA 기반 알림과 연계한다.

판정은 가중치 기반 종합 점수와 하드게이트를 함께 사용한다. 예를 들어 Critical 취약점이 0보다 크거나 미준수 라이선스가 존재하면 No-Go로 처리할 수 있다. 서비스 등급과 승인자 역할에 따라 동적 임계치와 예외 룰을 적용할 수도 있다.

정책상 예외가 아니라면 자동 결정을 기본으로 둔다. 예외는 개발 책임자와 보안 또는 운영의 이중 승인을 요구하고, 결정 사유·근거 URL·승인자 서명 토큰을 결정 아티팩트로 영구 보존한다. 대시보드, 증거 리포트, API를 제공하며 SOC2와 ISO 27001 감사 대응을 위해 변경·접근 로그도 유지한다. 접근 권한은 최소화하고, PII를 수집하지 않으며, 서명된 스냅샷의 무결성을 검증한다.

수집부터 예외 처리까지 연결하는 흐름

배치 / 스트리밍배치 / 스트리밍배치 / 스트리밍검증 호출정상실패스냅샷 기록 평가결정 아티팩트 생성예외 조건승인 성공승인 실패CI/CD 데이터: 빌드, 테스트,커버리지보안 데이터: SCA, SAST,DAST운영 데이터: 인시던트, SLO,변경 티켓수집 계층: Kafka / BatchIngestion검증·정규화: SchemaRegistry, DQ스코어링 엔진: 가중치, 임계치,룰셋저장소: DW / Lakehouse,스냅샷결정 노드: Go / Defer /No-Go출력: 대시보드, 승인 워크플로,감사로그수동 오버라이드 승인 조건오류 큐: 재처리, 알림

입력은 CI/CD, 보안 스캔, 변경관리(ITSM), 운영 메트릭(APM/Status)에서 가져온다. 수집은 스트리밍(Kafka)과 배치(API/파일)를 병행하고 스키마 버전을 태깅한다.

검증에서는 필수 필드 존재 여부, 값 범위, 기준 시점 ±허용 오차, 릴리즈 ID 매칭을 확인한다. 이후 서비스·컴포넌트 표준 키를 적용하고 타임존을 UTC로 맞추며 지표 단위를 통일한다. 가중합 점수와 하드게이트를 평가한 뒤 서비스 등급별 임계치를 적용한다.

결과는 Go, Defer, No-Go 결정 아티팩트로 만들고 해시 서명과 근거 링크를 포함한다. 대시보드를 갱신하고 승인 워크플로를 트리거하며 감사 로그를 영구 보존한다.

검증 실패 데이터는 격리 스토리지에 저장한 뒤 재처리 큐로 보내고 SLA 알림을 발생시킨다. 데이터가 지연되면 타임윈도우 내 결측치 보간 정책을 적용하거나 Defer를 결정한다. 외부 API 호출은 백오프 재시도를 수행하고 최대 재시도 초과 시에는 No-Go 대신 Defer를 기본으로 둔다.

스냅샷 빌드와 결정 아티팩트 생성은 단일 트랜잭션으로 커밋한다. 스냅샷 레코드에는 버전 필드와 낙관적 락(version)을 적용하고, 증거 파일인 리포트의 해시를 저장해 서명 검증으로 무결성을 보장한다.

출시 환경에서의 적용 방식

SaaS 주간 릴리즈에서는 기능 플래그 기반 롤링 배포 전에 SLO 위배 위험과 Critical 취약점 하드게이트를 평가할 수 있다. Defer가 나오면 롤백 준비 상태를 점검하고 핫픽스 분기를 생성한다.

모바일 앱 스토어 제출에서는 크래시율, 퍼포먼스 회귀, 3rd-party SDK 라이선스 준수 지표를 스냅샷에 고정한다. 마케팅 런칭과 연결된 일정에서는 Defer 발생 시 커뮤니케이션 템플릿을 자동 발송한다.

핀테크 변경관리에서는 이중 승인과 변경 창(Change Window) 준수 검증을 룰셋에 포함할 수 있다. SOC2 감사에 대비해 모든 결정 로그와 증거 리포트를 1년 이상 보존한다.

PostgreSQL에서 점수를 계산하는 예시

-- 전제: release_snapshot 테이블 존재
-- 주요 컬럼: snapshot_id, service, version, created_at,
-- test_pass_rate(0~1), code_coverage(0~1), high_vuln_cnt, open_incidents,
-- change_failure_rate(0~1), approvals_cnt, rollback_ready(boolean)

WITH base AS (
  SELECT
    snapshot_id,
    service,
    version,
    created_at,
    LEAST(GREATEST(test_pass_rate, 0), 1) AS tpr,
    LEAST(GREATEST(code_coverage, 0), 1) AS cov,
    GREATEST(high_vuln_cnt, 0) AS hv,
    GREATEST(open_incidents, 0) AS inc,
    LEAST(GREATEST(change_failure_rate, 0), 1) AS cfr,
    approvals_cnt,
    rollback_ready
  FROM release_snapshot
  WHERE snapshot_id = $1
),
score AS (
  SELECT
    *,
    /* 가중치: 테스트 0.35, 커버리지 0.25, 변경실패율 0.15(역가중), 취약점/인시던트 패널티 */
    ROUND(
      100 * (
        0.35 * tpr +
        0.25 * cov +
        0.25 * (1 - cfr) -
        0.05 * LEAST(hv, 5) -
        0.05 * LEAST(inc, 5)
      )
    ) AS readiness_score
  FROM base
),
decision AS (
  SELECT
    *,
    CASE
      WHEN hv > 0 THEN 'No-Go'                                 -- 하드게이트: Critical 취약점 존재
      WHEN NOT rollback_ready THEN 'Defer'                     -- 롤백 계획 미준비
      WHEN approvals_cnt < 2 THEN 'Defer'                      -- 이중 승인 미충족
      WHEN readiness_score >= 85 THEN 'Go'
      WHEN readiness_score BETWEEN 70 AND 84 THEN 'Defer'
      ELSE 'No-Go'
    END AS decision
  FROM score
)
SELECT * FROM decision;

스냅샷 생성과 decision 기록은 BEGIN…COMMIT 트랜잭션 안에서 같은 snapshot_id로 수행한다. threshold와 가중치는 별도 config 테이블에서 관리하고 유효기간(versioned)을 부여하는 방식을 권장한다.

엄격한 통제와 운영 복잡도 사이의 선택

불변 스냅샷과 증거 해시를 보존하고 결정 아티팩트에 서명한다. 하드게이트는 최소화하면서 가중치 기반의 점진적 개선을 유도하고, 예외에는 만료일자와 근거를 필수로 둔다. 최소권한, WORM 기반 감사 로그 불변 저장, PII 비수집 원칙도 함께 적용한다.

엄격한 하드게이트는 출시 민첩성을 낮출 수 있지만 장기적으로 품질과 신뢰성을 높인다. 실시간 스트리밍은 지연과 신선도를 개선하는 대신 운영 복잡도를 키운다. 중앙 집중형 룰셋은 표준화에 유리하고, 팀 자율 룰셋은 도메인 특화 유연성을 제공한다.

항목 스프레드시트 기반 DWH+BI 대시보드 이벤트 드리븐 레이크하우스
성능 낮음: 수작업 갱신 지연 중간: 배치 집계 높음: 스트리밍/마이크로배치
확장성 낮음: 팀/서비스 증가 시 한계 중간: 스케일 아웃 가능 높음: 파티셔닝·스케일 아웃 용이
일관성 낮음: 버전 관리 취약 높음: 스냅샷·스키마 버전 높음: 이벤트 소싱·타임 트래블
안정성 낮음: 휴먼 에러 빈번 중간: ETL 실패 영향 높음: 재처리·사이드카 격리
운영 편의 높음: 진입 간단 중간: ETL/모델 운영 필요 중간: 인프라 복잡, 자동화 필수

릴리즈 실패율(change failure rate)은 2040% 감소하고, 승인 리드타임은 3060% 단축될 수 있다. Defer와 No-Go 사유가 명확해지면 재작업 시간은 15~25% 절감된다. 감사 준비 시간은 50% 이상 단축되고 증거 수집 자동화율은 80% 이상 달성할 수 있다.

이 체계는 판단의 투명성과 재현성을 높이고 조직 신뢰도를 높인다. 엔지니어링·보안·운영의 목표를 정렬해 분쟁 비용을 줄이며, 데이터 기반 품질 문화와 기술 부채 축소에도 연결된다. 초기에는 DWH+BI 기반으로 시작하고, 서비스 규모와 실시간성 요구에 따라 이벤트 드리븐 아키텍처로 확장한다.

릴리즈 관리Go No-GoCI/CD품질 관리변경 관리