인프라 코드 풀 리퀘스트 위험 기반 검토

출처: DevOps.com

모든 인프라 풀 리퀘스트가 동일한 검토 경로를 가질 필요는 없습니다. 개발 계정에서의 태그 변경과 프로덕션에서의 네트워크 정책 변경이 동일한 검토자 부담을 만들어서는 안 됩니다. 모든 변경을 고위험으로 취급하면 검토자는 그 신호를 신뢰하지 않게 됩니다.

IaC 검토에서 나는 검토자들이 저위험 변경에 과도한 주의를 기울이는 반면, 미묘한 프로덕션 변경은 약한 컨텍스트만으로 통과되는 모습을 보았습니다. 위험 점수는 인간 판단을 대체하려는 척이 아니라, 인간 판단을 재지향할 때 유용합니다.

위험 기반 검토는 플랫폼 팀에 보다 유용한 패턴을 제공합니다. 시스템은 IaC(공통 IaC 보안 이슈와 해결 방법) 변경을 diff, 환경, 리소스 유형, 의존성 중요도, 최근 사고, 소유권, 롤아웃 계획 등의 증거를 바탕으로 점수를 매깁니다. 이 점수는 검토자를 대체하지 않으며, 변경이 받아야 할 검토 수준을 결정합니다.

점수가 고려해야 할 사항

좋은 점수는 지루하고 설명 가능해야 합니다. 폭발 반경, 프로덕션 노출, 상태 저장 리소스 영향, 정체성 또는 네트워크 변경, 롤백 난이도, 누락된 증거, 그리고 해당 서비스에 최근 사고가 있었는지 여부를 포함해야 합니다. 목표는 기계적 판단이 아니라 일관된 분류입니다.

risk_inputs**:**  environment:** production**  resource_type:** iam_policy**  blast_radius:** account-wide**  rollback:** manual**  owner_present:** true**  recent_incidents:** 1**  missing_evidence:** false

출력도 마찬가지로 명확해야 합니다: 빠른 경로, 소유자 검토, 플랫폼 검토, 보안 검토, 단계적 롤아웃 또는 증거가 완전해질 때까지 차단.

풀 리퀘스트가 적절한 표면인 이유

풀 리퀘스트에는 이미 컨텍스트가 포함되어 있습니다: 작성자, diff, 검토자, 체크, 대상 브랜치, 배포 환경. 따라서 변경이 아직 저렴하게 조정될 수 있을 때 위험을 설명하기에 가장 좋은 위치가 됩니다. 주간 거버넌스 보고서는 리더에게는 유용할 수 있지만, 안전하게 머지하려는 엔지니어에게는 이미 늦은 시점입니다.

코멘트는 원시 정책 출력 전체를 덤프하지 않아야 합니다. 어떤 리소스가 변경됐는지, 어떤 위험 요소가 작용했는지, 어떤 검토 경로가 선택됐는지, 위험을 낮추려면 무엇을 해야 하는지를 알려야 합니다.

구현 스케치

def risk(change):
    score = 0
    if change.environment == "production":
        score += 25
    if change.resource in {"iam_policy", "security_group", "route_table"}:
        score += 25
    if not change.owner:
        score += 20
    if change.rollback == "manual":
        score += 15
    return min(score, 100)

이 예시는 의도적으로 단순합니다. 프로덕션 시스템에서는 신비한 가중치가 아니라 검증된 규칙을 사용해야 합니다. 점수가 변하면 검토자는 어떤 입력이 변했는지 알 수 있어야 합니다.

검토자 피로 방지

가장 큰 위험은 과도한 에스컬레이션입니다. 모든 프로덕션 변경이 중앙 팀으로 가면 시스템이 병목이 됩니다. 임계값은 신중히 설정해야 합니다. 증거가 완전한 프로덕션 태그 변경은 일반 소유자 검토만 필요할 수 있습니다. 롤백이 누락된 프로덕션 정체성 변경은 더 많은 주의가 필요합니다.

거짓 양성, 거짓 음성, 검토 지연 시간, 오버라이드 비율, 반복되는 고위험 패턴을 추적하세요. 특정 카테고리가 지속적으로 높은 점수를 받는다면, 이는 플랫폼에 더 안전한 워크플로가 부족하다는 로드맵 입력이 됩니다.

증거와 재현

각 점수화된 결정은 정책 버전, 입력값, 점수, 선택된 경로, 검토자, 최종 결과와 함께 저장되어야 합니다. 이는 사고 발생 시 중요합니다. 나중에 변경이 문제를 일으키면, 팀은 당시 왜 그 검토 경로가 합리적이었는지 재구성할 수 있습니다.

증거 기록은 컴플라이언스 서류가 아니라, 배포 시스템을 위한 운영 메모리입니다.

롤아웃 계획

우선 1개월간 자문 모드로 시작합니다. 점수를 인간 판단과 비교하고, 누락된 컨텍스트와 혼란스러운 설명을 찾아보세요. 그런 다음 소유자 누락 또는 롤백 누락과 같은 좁은 경우에만 강제 적용합니다. 시스템이 신뢰를 얻은 뒤에만 범위를 확대합니다.

위험 기반 검토는 잡음을 줄일 때 가장 강력합니다. 플랫폼은 안전한 변경을 더 빠르게, 위험한 변경을 더 명확하게 만들어야 하며, 단순히 또 다른 체크를 추가하는 것이 아닙니다.

점수 보정

점수 체계는 팀이 숫자가 어떻게 도출됐는지 볼 수 없을 때 실패합니다. 첫 모델은 단순하게 유지하고 점수표를 공개하세요. 정체성 변경이 25점, 롤백 누락이 15점을 더한다면 그렇게 명시합니다. 검토자는 신비한 모델이 아니라, 어디에 주의를 집중할지 일관된 방식을 원합니다.

월간 보정 회의를 열어 점수, 검토자 결정, 배포 결과, 사고 후속 조치를 비교합니다. 낮은 점수의 변경이 반복적으로 문제를 일으킨다면 신호가 누락된 것이고, 높은 점수의 변경이 별다른 우려 없이 통과한다면 모델이 과도하게 민감한 것입니다.

예시 워크플로 출력

Risk score: 72 / 100
Reason: production IAM policy change, account-wide scope, manual rollback
Decision: platform owner review required
Remediation: add rollback plan or reduce policy scope
Evidence: policy-v4, commit 7a91c2, service owner payments-platform

이 출력은 엔지니어가 바로 행동할 수 있게 해 줍니다. 또한 검토자에게 공유된 언어를 제공합니다. 논의는 일반적인 불편함이 아니라 구체적인 위험 요소에 집중됩니다.

안티패턴

• 숨겨진 입력이 너무 많은 점수를 피하세요.
• 환경을 무시하는 전역 임계값을 피하세요.
• 보완 방안을 설명하지 않고 변경을 차단하지 마세요.
• 모델을 완성된 것으로 취급하지 마세요. 인프라 플랫폼은 끊임없이 변하고, 검토 모델도 함께 진화해야 합니다.

최고의 위험 기반 검토 시스템은 시간이 지날수록 조용해집니다. 플랫폼이 일상적인 변경과 깊은 주의가 필요한 패턴을 학습하기 때문입니다.

실용성 유지

검토 모델은 새로운 엔지니어에게 쉽게 설명될 수 있어야 합니다. 팀이 왜 특정 변경이 보안 검토로 라우팅됐는지 설명하지 못한다면, 점수 체계가 너무 불투명한 것입니다. 좋은 위험 점수는 엔지니어에게 공유된 어휘를 제공합니다: 프로덕션 노출, 폭발 반경, 롤백 난이도, 소유권, 누락된 증거.

최종 점검

점수를 요구하기 전에, 지난 한 달간의 인프라 변경에 대해 재현해 보세요. 모델이 엔지니어가 실제로 우려했던 변경을 에스컬레이션했는지 확인합니다.