GitLab CI, SAST, Code Quality, SonarQube 신호를 나열하지 않고 병합 전 조치, 담당자, confidence로 바꾸는 실무 검토 틀입니다.
CI 실패와 scanner finding은 중요한 신호입니다. 하지만 신호는 결론이 아닙니다. 승인자가 필요한 것은 실패 로그 전체가 아니라 병합 판단에 미치는 영향과 끝낼 수 있는 조치입니다.
GitLab 문서상 MR pipeline, approval policy, security report는 설정과 기준 branch에 따라 해석이 달라집니다. SonarQube의 quality gate도 품질 조건 신호이지 업무 영향 설명서는 아닙니다.
이 백서는 실패를 유형화하고, 이번 MR과의 관련성을 확인하고, required action으로 바꾸는 방법을 제안합니다. 취약점 진위나 false positive를 AI가 단정하지 않습니다.
CI와 scanner 문서는 기능이 많습니다. 이 백서는 병합 판단에 직접 영향을 주는 조건만 골랐습니다.
build, test, lint, scanner, deployment 환경 문제를 분리합니다. 실패 job 이름만 보지 않고 변경 파일, 재현성, 기준 branch를 함께 봅니다.
신규인지 기존인지, target branch에도 있던 문제인지, 기준 report가 있는지, MR pipeline이 실제로 돌았는지 확인합니다. 불확실하면 confidence를 낮춥니다.
‘CI 실패’가 아니라 ‘payment-service integration test 실패 로그 재현 후 MR pipeline 결과 첨부’처럼 완료 기준이 보이는 조치로 바꿉니다.
승인자는 로그를 전부 읽을 시간이 없습니다. 먼저 실패가 병합 판단을 바꾸는 실패인지 봐야 합니다. GitLab MR pipeline은 설정에 따라 source branch 기준으로 실행되며, MR context job이 별도로 필요할 수 있습니다.
근거 해석: GitLab MR pipelines 문서는 MR pipeline 실행 조건과 `merge_request_event` 규칙을 설명합니다. 따라서 CI 결과는 설정 문맥과 함께 읽어야 합니다.
보안과 품질 스캐너는 발견 항목을 만듭니다. 병합 판단에서는 finding 자체보다 이번 MR에서 새로 생겼는지, 기존 위험인지, 개선된 것인지, 비교가 불가능한지 구분해야 합니다.
GitLab merge request approval policies는 scanner report artifact와 completed pipeline에 의존합니다. 지정된 scanner가 report를 내지 않거나 평가가 불가능하면 추가 approval이 필요할 수 있습니다. 이는 단순 알림이 아니라 판단 공백입니다.
조치 문장은 짧아야 하지만 닫힐 수 있어야 합니다. ‘보안팀 확인’보다 ‘보안팀이 SAST 신규 high finding 1건의 exploit path와 예외 승인 가능 여부를 확인’이 낫습니다.