AI 코딩 도구를 팀 단위로 쓰기 시작하면, 몇 주 안에 같은 질문이 반복됩니다.

  • “이 코드, 누가 쓴 거야?”
  • “어떤 프롬프트/근거로 이렇게 바뀐 거지?”
  • “오픈소스 라이선스나 취약점 이슈가 생기면 추적 가능해?”

초기에는 생산성이 올라가서 이 질문을 뒤로 미루기 쉽지만, PR 수가 늘고 릴리스가 빨라지면 결국 병목은 생성 품질이 아니라 증적 체계 부재에서 발생합니다. 그래서 최근 트렌드는 “AI를 더 똑똑하게 쓰는 법"보다, AI가 만든 변경의 출처를 추적하고, 공급망 메타데이터(SBOM)를 운영 파이프라인에 붙이는 법으로 이동하고 있습니다.

이 글에서 얻는 것

  • 왜 AI 도입 2단계에서 provenance(출처 추적)와 SBOM이 필수 운영 항목이 되는지 이해할 수 있습니다.
  • 어떤 필드를 최소 단위로 남겨야 감사/보안/법무 이슈에 대응 가능한지 실무 기준을 얻습니다.
  • “모든 걸 다 기록"이 아니라, 비용 대비 효과가 높은 우선순위로 도입하는 방법을 정리할 수 있습니다.

핵심 개념/이슈

1) Provenance는 로그가 아니라 “결정 경로"다

팀에서 필요한 건 단순 활동 로그가 아닙니다. 실제로는 아래 질문에 답할 수 있어야 합니다.

  • 어떤 요구사항에서 시작된 변경인가 (task_id)
  • 사람이 직접 작성했는가, AI가 제안했고 사람이 편집했는가 (author_mode)
  • 어떤 도구/모델/버전을 썼는가 (tool, model, version)
  • 어떤 테스트/리뷰 근거로 머지됐는가 (evidence[])

이 구조가 없으면 사고가 났을 때 “누가 잘못했는지"만 남고, 다음 개선이 되지 않습니다.

2) SBOM은 배포 직전 문서가 아니라 개발 중 생성물이어야 한다

많은 팀이 릴리스 직전에만 SBOM을 만듭니다. 이러면 이미 늦습니다.

  • 의존성 추가 시점의 맥락이 사라짐
  • PR 단위 변경 영향 분석이 어려움
  • “어떤 AI 제안이 어떤 라이브러리 도입으로 이어졌는지” 연결이 끊김

그래서 트렌드는 PR 생성 시 SBOM diff 자동 생성입니다. 최소한 “새로 들어온 패키지/라이선스/중요 취약점"은 리뷰 단계에서 바로 보이게 해야 합니다.

3) 생성 속도와 통제 수준은 비례하지 않는다

흔한 오해가 있습니다. “통제를 강화하면 속도가 너무 느려진다"는 주장입니다. 실제로는 위험도 기반 분기만 제대로 두면 둘 다 잡을 수 있습니다.

  • low-risk(문서/테스트 보강): 자동 머지 허용 폭 확대
  • medium-risk(비핵심 비즈니스 로직): 1인 리뷰 + 자동 스캔 필수
  • high-risk(인증/결제/권한/외부전송): 2인 승인 + provenance/SBOM 증적 필수

이미 런타임 거버넌스와 AI 코드 리뷰 거버넌스에서 말한 것처럼, 핵심은 “모두에게 같은 규칙"이 아니라 “위험도별 다른 규칙"입니다.

실무 적용

1) 최소 Provenance 스키마부터 시작

처음부터 완벽한 표준을 만들 필요는 없습니다. 아래 8개 필드만 있어도 운영 품질이 크게 올라갑니다.

  • task_id
  • repo, branch, commit_sha
  • author_mode (human / ai_suggested / ai_generated)
  • tool + model_version
  • prompt_hash (원문 대신 해시로 민감정보 최소화)
  • evidence[] (테스트 결과, 코드리뷰 링크)
  • risk_level
  • approver

의사결정 기준:

  • high-risk 변경에서 필드 누락 시 머지 차단
  • medium-risk는 24시간 내 보완 허용
  • low-risk는 주간 샘플 감사(예: 10%)로 관리

2) SBOM을 “배포 산출물"이 아니라 “PR 품질 게이트"로 사용

추천 순서:

  1. PR 생성 시 SBOM snapshot 자동 생성
  2. base 브랜치 대비 diff 계산
  3. 신규 패키지의 라이선스/취약점/유지보수 상태 평가
  4. 위험도 기준 초과 시 리뷰 체크리스트 강제

수치 기준 예시:

  • Critical 취약점 신규 유입: 0건 허용
  • High 취약점 신규 유입: 기본 차단, 예외 승인 필요
  • copyleft 라이선스 신규 유입: 법무 검토 전 차단

이건 MCP 보안/거버넌스에서 다룬 “도구 호출 통제"를 코드 공급망까지 확장하는 접근입니다.

3) 감사 가능한 운영 루프 만들기

좋은 운영팀은 “탐지"보다 “재발 방지"를 더 빨리 합니다.

  • 주간 리포트: provenance 누락률, 위험도별 예외 승인 건수
  • 월간 리뷰: 예외 사유 상위 3개 제거(정책/도구 개선)
  • 분기 점검: SBOM 정확도 샘플 검증(랜덤 20개 PR)

연결해서 보면 Evals 기반 개발의 점수 체계와도 궁합이 좋습니다. “코드가 맞는가"뿐 아니라 “근거가 남았는가"를 평가 지표에 넣을 수 있기 때문입니다.

트레이드오프/주의점

  1. 메타데이터 수집 비용
    필드를 많이 요구할수록 개발자 피로도가 올라갑니다. 자동 수집 가능한 필드(commit, tool, model)는 최대한 자동화하고, 사람 입력은 최소화해야 합니다.

  2. 과도한 차단으로 인한 우회 문화
    규칙이 너무 빡빡하면 팀은 비공식 경로로 우회합니다. 차단 정책은 명확한 예외 경로(기한, 승인자, 사후조치)를 함께 제공해야 작동합니다.

  3. 프라이버시와 증적의 충돌
    프롬프트 원문을 그대로 저장하면 민감정보 리스크가 생깁니다. 원문 대신 해시/요약/마스킹 원칙을 적용해야 합니다.

  4. 도구 종속성 리스크
    특정 벤더 형식에만 묶이면 교체 비용이 커집니다. 내부 공통 스키마를 두고 벤더 포맷은 어댑터로 흡수하는 편이 장기적으로 안전합니다.

체크리스트 또는 연습

팀 체크리스트

  • PR 단위 provenance 최소 필드(8개)를 정의했다.
  • high-risk 변경의 증적 누락 시 머지 차단 규칙이 있다.
  • SBOM diff를 PR 단계에서 자동 생성한다.
  • 신규 Critical 취약점/금지 라이선스 유입 차단 기준이 있다.
  • 예외 승인(누가, 왜, 언제까지) 기록이 남고 주기적으로 정리된다.

연습 과제

  1. 최근 1주 PR 30개를 샘플링해 provenance 누락률을 계산해보세요.
  2. high-risk 변경 5개를 골라 “증적만으로 의사결정 재현"이 가능한지 검증해보세요.
  3. SBOM diff 기준을 적용한 뒤, 리뷰 리드타임과 차단률 변화를 2주간 비교해보세요.

결국 핵심은 간단합니다. AI 시대의 코드 품질은 “얼마나 빨리 만들었나"가 아니라, 문제 발생 시 얼마나 빨리 원인을 특정하고 수정할 수 있나로 평가됩니다. provenance와 SBOM은 규제 대응 문서가 아니라, 팀 학습 속도를 지키는 운영 도구입니다.