Approval rule, Code Owners, CI, 보안 리포트가 있어도 승인자가 다시 묻는 질문을 한 장의 Merge Readiness Packet으로 정리하는 방법입니다.
GitLab은 병합 요청을 운영하기 위한 좋은 장치를 이미 갖고 있습니다. 승인 규칙은 누가 승인해야 하는지 정하고, Code Owners는 전문 리뷰어를 부르고, pipeline과 report는 변경 신호를 보여줍니다.
그런데 승인 회의의 질문은 조금 다릅니다. 이 MR은 왜 지금 병합 가능한가. 남은 위험은 무엇인가. CI 실패와 scanner finding은 이번 변경 때문에 생긴 문제인가. 이 질문은 설정값이 아니라 판단 기록을 요구합니다.
Mantis Gate의 역할은 GitLab을 대신 조작하는 것이 아니라, 흩어진 근거를 Ready, Conditional, Not Ready, Blocked 중 하나의 권고와 필수 조치, 담당 리뷰어, confidence로 정리하는 것입니다.
기능 소개 문서만으로는 고객의 병합 판단 문제를 설명할 수 없습니다. 그래서 근거를 세 층으로 나누어 봤습니다.
필수 승인 수, Code Owner 승인, thread 해결, pipeline 상태, protected branch 규칙은 GitLab이 관리하는 병합 조건입니다. 이 조건을 바꾸는 것은 Mantis Gate의 첫 범위가 아닙니다.
CI 로그, 테스트 결과, Code Quality, SAST, SonarQube quality gate는 판단 재료입니다. 재료가 많아도 회의용 결론은 자동으로 만들어지지 않습니다.
이 MR의 상태, 위험, 남은 조치, 담당 리뷰어, 근거 요약, confidence를 한 번에 읽히는 문장으로 남겨야 다음 회의와 감사에서 재사용할 수 있습니다.
GitLab approvals는 리뷰 프로세스를 구성하는 장치입니다. 필요한 승인 수, 승인 가능한 그룹, Code Owner 승인, 특정 리뷰어 범주를 정할 수 있습니다. 이 장치는 ‘누가 승인해야 하는가’에는 강하지만 ‘왜 승인해도 되는가’를 회의 문장으로 바꾸지는 않습니다.
근거 해석: GitLab approvals 문서는 승인 규칙과 승인자를 다룹니다. Mantis Gate는 그 위에 사람이 읽는 결정 기록을 만드는 레이어로 위치해야 합니다.
MR 화면에는 diff, comment, pipeline, scanner report가 모입니다. 하지만 운영 책임자는 로그를 읽고 싶은 것이 아니라 결론을 알고 싶습니다. 실패가 이번 MR에서 새로 생긴 문제인지, 운영 업무에 영향이 있는지, 누구 확인이 필요한지 한 문서에 들어가야 합니다.
패킷은 긴 분석 보고서가 아닙니다. 승인자가 30초 안에 읽고 다음 행동을 정할 수 있어야 합니다. 필요한 필드는 readiness status, risk, summary, reasons, required actions, CI failure RCA, scanner triage, new vs existing issues, suggested reviewers, evidence summary, confidence입니다.
대표 MR 3건을 고르면 효과를 빠르게 볼 수 있습니다. 정상 후보, 조건부 후보, 보류 후보를 섞어야 산출물이 단순 요약인지 실제 판단 문서인지 드러납니다.