GitLab 승인 규칙, security policy, SonarQube, Semgrep, Snyk, AI 코드 리뷰와 Mantis Gate가 각각 답하는 질문을 분리합니다.
이미 GitLab approval rule과 scanner가 있는데 왜 Mantis Gate가 필요한가. 이 질문은 정확합니다. 답도 단순해야 합니다. 기존 도구를 바꾸자는 것이 아니라, 기존 도구가 만든 신호를 승인자가 읽을 결정 문서로 묶자는 제안입니다.
GitLab은 협업과 병합 제어에 강합니다. 스캐너는 발견과 품질 조건에 강합니다. AI 코드 리뷰는 개발자에게 개선 피드백을 주는 데 강합니다. Mantis Gate는 이 신호를 MR 단위 readiness 패킷으로 바꿉니다.
따라서 비교의 기준은 ‘무엇이 더 좋은가’가 아닙니다. ‘우리 조직에서 병합 판단을 설명하는 문서가 이미 충분한가’입니다.
비교 콘텐츠는 과장 위험이 높습니다. 그래서 공식 문서에서 확인되는 역할과 경계만 사용했습니다.
승인자가 GitLab 안에서 모든 로그와 리포트를 읽고, 회의와 감사용 기록을 다시 쓰지 않아도 된다면 Mantis Gate가 필요하지 않을 수 있습니다.
외주 산출물 수용, 보안 예외 승인, CI 실패 해석, scanner finding 설명을 반복해서 사람이 다시 쓴다면 readiness 패킷의 가치가 있습니다.
기존 도구를 바꾸지 않고 정상, 조건부, 보류 후보 MR의 근거를 넣어 봅니다. 산출물이 실제 회의에서 쓰이면 다음 단계로 넘어갑니다.
Approval rule은 승인 수와 승인 가능한 사람을 정합니다. Code Owners는 특정 파일의 전문가를 지정합니다. Mantis Gate는 이 규칙을 수정하거나 집행하지 않습니다. 대신 규칙과 근거를 읽고 승인자가 남길 판단 문장을 만듭니다.
GitLab merge request approval policies는 scanner 결과와 정책을 기반으로 추가 approval을 요구할 수 있습니다. Mantis Gate는 정책을 우회하거나 scanner 결과를 보증하지 않습니다. report 누락, 신규 finding, 조치 필요 여부를 사람이 읽는 required action으로 바꿉니다.
스캐너는 발견, 분류, quality gate, remediation workflow에 강합니다. Mantis Gate는 스캔을 다시 실행하거나 finding의 진위를 단정하지 않습니다. 이번 MR에서 이 finding 때문에 병합을 보류해야 하는지, 조건부로 가능한지, 누가 확인해야 하는지를 씁니다.
AI 코드 리뷰 도구는 개발자에게 diff 피드백과 개선 제안을 제공합니다. Mantis Gate는 라인별 코멘트 경쟁을 하지 않습니다. 비개발 승인자가 읽을 수 있는 summary, risk, reasons, required actions, suggested reviewers, confidence를 만드는 데 집중합니다.
아래 질문에 세 개 이상 ‘아니오’라면 대표 MR 3건 파일럿을 해볼 만합니다. 반대로 모두 ‘예’라면 기존 도구만으로 충분할 수 있습니다.