검증이 백서가 믿을 만한 근거로 본 것
일반 외주 체크리스트는 많지만 MR 근거까지 연결되는 문서는 적습니다. 그래서 공식 거버넌스 문서와 GitLab 운영 문서를 중심으로 재구성했습니다.
- 수용 기준 근거: NIST SSDF와 CISA Secure by Demand처럼 구매자가 공급자에게 요구할 수 있는 보안 개발 질문.
- 리뷰 책임 근거: GitLab approvals와 Code Owners처럼 실제 승인자와 전문 리뷰어를 지정하는 기능.
- 의존성 근거: GitLab dependency scanning과 CycloneDX SBOM처럼 lockfile, dependency graph, SBOM artifact가 있을 때만 해석 가능한 공급망 신호.
- 한국 조직 맥락: 정보시스템 감리와 산출물 검수 언어는 배경으로만 사용합니다. Mantis Gate가 감리나 법적 수용을 대신하지 않습니다.
인사이트검토 회의에 바로 쓸 핵심 정리
- 외주 MR 검수는 체크박스가 아니라 수용 판단 문장으로 끝나야 합니다.
- 자료를 많이 모으는 것보다 MR별 근거가 서로 연결되어 있는지가 더 중요합니다.
- 대표 MR 3건은 정상, 조건부, 보류 후보가 섞여야 합니다. 그래야 산출물의 판단력이 보입니다.
- GitLab token 없이도 첫 검증은 가능합니다. MR diff, CI log, scanner report, 테스트 메모를 수동 업로드 근거로 시작합니다.
- dependency/SBOM/SCA 근거는 제공된 lockfile, dependency report, SBOM artifact 기준으로만 해석합니다. 근거가 없으면 안전하다고 보지 않고 missing evidence로 표시합니다.
범위무엇을 수용 판단할지 먼저 정합니다
업무 시스템, 대상 브랜치, 배포 영향, 외주사 책임 범위, 예외 승인권자를 먼저 정합니다. 범위가 없으면 모든 근거가 애매해집니다.
근거MR마다 같은 근거를 붙입니다
diff 요약, CI 결과, scanner report, 테스트 수행 여부, 리뷰 코멘트, 배포 메모를 MR 단위로 묶습니다. 누락된 근거는 숨기지 않고 판단 공백으로 표시합니다.
수용승인 조건을 행동으로 바꿉니다
수용, 조건부 수용, 보류를 나누고 required actions와 담당자를 씁니다. ‘확인 필요’가 아니라 무엇을 확인해야 끝나는지 적어야 합니다.
1. 외주 검수에서 자주 생기는 공백
외주사는 MR을 만들고 내부 담당자는 병합 여부를 봅니다. 하지만 요구사항 링크, 변경 범위, CI 실패, scanner finding, 테스트 근거가 서로 연결되지 않으면 수용 판단이 사람의 기억에 의존합니다.
- 변경 목적은 있지만 업무 영향이 설명되지 않습니다.
- CI 실패는 있지만 외주사 조치인지 내부 환경 문제인지 구분되지 않습니다.
- 보안 finding은 있지만 이번 MR에서 새로 생긴 것인지 확인되지 않습니다.
- 승인자는 있지만 품질, 보안, 업무 책임이 분리되지 않습니다.
2. 대표 MR 3건을 고르는 기준
파일럿은 전수 분석보다 대표성 있는 세 건이 낫습니다. 정상 케이스만 고르면 산출물의 가치가 보이지 않고, 문제 케이스만 고르면 운영 현실이 왜곡됩니다.
- Ready 후보: CI와 테스트가 통과했고 변경 범위가 분명한 MR.
- Conditional 후보: 실패나 누락이 있지만 조치가 명확한 MR.
- Not Ready 또는 Blocked 후보: 실패 원인, 보안 영향, 승인 책임자가 불명확한 MR.
- 업무 영향 후보: MES, WMS, 주문, 정산, 인증처럼 운영 리스크가 큰 MR.
3. MR마다 준비할 근거
검수자는 모든 자료를 원하지 않습니다. 판단에 필요한 자료가 빠지지 않기를 원합니다. 아래 항목이 없으면 패킷은 제공됨, 누락됨, 비교불가, 미적용을 구분하고 confidence를 낮추거나 Blocked로 표시해야 합니다.
- MR 기본 정보: 제목, target branch, 관련 이슈, 업무 시스템, 변경 목적.
- 변경 근거: diff 요약, 주요 파일, migration, config 변경, rollback note.
- 품질 근거: pipeline status, 실패 job 로그, 테스트 종류, 누락된 테스트.
- 보안 근거: SAST, Semgrep, Snyk, SonarQube 등 기존 scanner report와 신규/기존 구분.
- 의존성 근거: lockfile 변경, dependency/SCA report, CycloneDX SBOM, VEX 또는 risk acceptance 메모. 없으면 취약점 없음이 아니라 missing evidence입니다.
- 책임 근거: reviewer, Code Owner, 품질/보안/업무 승인자, 남은 조치 담당자.
4. 좋은 수용 판단 문장
좋은 문장은 짧지만 책임을 흐리지 않습니다. 예를 들어 ‘Conditional: 주문 배정 모듈의 integration test 2건이 실패했습니다. 실패 로그는 test fixture 불일치로 보이며 운영 데이터 영향은 낮습니다. 배포 전 DevOps가 fixture 재생성 후 MR pipeline 결과를 첨부해야 합니다. Confidence: Medium.’처럼 씁니다.
- 나쁜 문장: 외주사 확인 필요.
- 좋은 문장: 누가, 무엇을, 어떤 근거로 보완해야 하는지 적습니다.
- 나쁜 문장: 문제 없음.
- 좋은 문장: 어떤 근거 때문에 Ready로 볼 수 있는지 남깁니다.
근거확인한 문헌