올해 당신의 팀이 머지(merge)한 코드 중 약 4분의 1에서 절반 사이는 아마도 AI 어시스턴트가 작성했을 것입니다. 어떤 PR(Pull Request), 어떤 파일, 어떤 라인인지 물어봐도 대부분의 팀은 어깨만 으쓱할 뿐입니다.

중요한 점은 다음과 같습니다: 그 답은 이미 당신의 git 히스토리에 있습니다. 다만 아무도 그것을 읽지 않을 뿐입니다.

아무도 읽지 않는 트레일러 (trailer)

Claude Code가 커밋(commit)을 작성할 때, 메시지에 다음과 같은 내용을 추가합니다:

Co-Authored-By: Claude <noreply@anthropic.com>

GitHub Copilot도 마찬가지입니다. Cursor도 마찬가지입니다. 이 도구들이 손을 대는 모든 커밋에는 기계가 읽을 수 있는 속성 스탬프(attribution stamp)가 포함되어 있습니다. 이는 설정이나 인간의 규율 없이도 자동으로 생성됩니다.

반면, 제가 본 대부분의 "AI 사용 정책"은 다음과 같이 작동합니다: _"이 PR은 AI가 생성한 코드를 포함하고 있습니다"_라는 체크박스가 있는 PR 템플릿이 있고, 이는 신의(honor system)에 의존해 작성되며, 아무도 읽지 않고, 아무런 강제성도 없습니다.

우리는 모든 커밋에 신뢰할 수 있는 자동 공개 신호를 가지고 있음에도 불구하고, PR 본문에 있는 신뢰할 수 없는 수동 신호에 의존하며, 팀들은 자신들의 거버넌스(governance)를 그 수동 신호에 걸고 있습니다.

Open Delivery Spec (ODS)는 하나의 아이디어로 구축된 작은 오픈 소스 프로젝트입니다: 이미 존재하는 신호를 읽고, CI에서 그에 따라 행동하는 것입니다.

탐지가 아닌 속성 (Attribution)

ODS가 무엇이 _아닌지_에 대해 솔직하게 말씀드리겠습니다. 이 지점이 이 분야의 대부분의 도구들이 저를 실망시키는 부분이기 때문입니다.

스타일을 통해 AI가 작성한 코드를 법과학적으로 식별한다고 주장하는 "AI 코드 탐지기(AI code detectors)"는 라인 수준에서 볼 때 유사 판매(snake oil)에 불과합니다. 오탐률(false-positive rate) 때문에 결과에 영향을 미치는 어떤 작업에도 사용할 수 없습니다. ODS는 그런 시도를 하지 않습니다. ODS의 주요 신호는 **속성(attribution)**입니다. 즉, AI 도구들이 Co-Authored-By 트레일러를 통해 스스로 공개하는 정보입니다. 만약 누군가 커밋을 스쿼시(squash)하고 트레일러를 제거한다면, ODS는 이를 잡아내지 못할 것입니다. 이것은 거짓말 탐지기가 아니라, 도구들이 보고한 내용을 기록한 원장(ledger)입니다.

프로젝트 자체 문서에서는 이를 직설적으로 표현합니다: ODS는 **품질 오라클(quality oracle)이 아니라, 시그널 생성기(signal producer)**입니다. "PASS"는 정책 규칙이 발동되지 않았음을 의미할 뿐, 코드가 좋다는 뜻이 아닙니다. 85%의 탐지 신뢰도(detection confidence)는 해당 _변경 사항(change)_이 AI의 도움을 받았을 가능성이 높다는 의미이지, 코드 라인의 85%가 기계에 의해 작성되었다는 뜻이 아닙니다.

저는 이러한 정직함이 다른 방식보다 더 유용하다고 생각합니다. 실패 모드(failure modes)를 이해하고 있는 시그널을 바탕으로 실제적인 정책을 구축할 수 있기 때문입니다.

실제로 수행하는 작업

ODS는 모든 풀 리퀘스트(pull request)에 대해 네 가지 단계를 실행합니다:

① Detect (탐지)   →  AI 코드가 있는가?         (Co-Authored-By 트레일러, PR 공개 여부, 브랜치 접두사)
② Analyze (분석)  →  어떤 품질 결함이 있는가?     (내장 휴리스틱(heuristics) + SARIF를 통한 사용자의 분석기)
③ Score (점수화)  →  얼마나 많은 기술 부채가 추가되었는가? (품질 중심, AI 리스크에 따른 가중치 적용)
...

설정은 워크플로(workflow) 파일 하나면 충분합니다:

# .github/workflows/ods.yml
name: ODS AI Code Quality
on:
...

이것이 통합의 전부입니다. PR 코멘트, 작업 요약(job summary), HTML 보고서, 그리고 배지(badge)를 받게 됩니다. semgrep: true를 추가하면 Semgrep을 실행하고 그 결과를 게이트(gate)에 병합합니다. 저장소에 .ods/policy.rego 파일을 넣으면 사용자만의 규칙이 무엇을 차단할지 결정합니다.

실제 사례: 실제 취약점 차단하기

다음은 스펙 저장소의 재현 가능한 워크스루(reproducible walkthrough)에서 가져온 내용입니다. 아래의 모든 출력값은 직접 작성한 것이 아니라 도구로부터 캡처한 것입니다.

AI의 도움을 받은 변경 사항에 다음과 같은 전형적인 코드가 포함되었습니다:

def run_user_command(user_input):
    # 신뢰할 수 없는 입력이 셸(shell)로 흘러 들어갑니다 — 커맨드 인젝션(command injection) 위험.
    return subprocess.run(user_input, shell=True, capture_output=True)

Semgrep이 이를 찾아내고 SARIF를 생성합니다. ODS는 Semgrep의 규칙 ID와 심각도(severity)를 유지한 채 해당 탐지 결과를 수집하며, 정책 게이트(policy gate)가 제 역할을 수행합니다:

$ ods check --sarif semgrep.sarif --policy .ods/policy.rego
❌  Policy check failed
   Policy: .ods/policy.rego
...

0이 아닌 종료 코드(Non-zero exit), CI 실패, 머지(merge) 차단. 코드를 수정하고(인자 리스트를 전달하고, shell=False 설정), Semgrep이 탐지 결과가 없음을 보고하면, 동일한 게이트가 통과됩니다:

$ ods check --sarif semgrep.sarif --policy .ods/policy.rego
✅  Policy check passed
$ echo $?
...

여기서 역할 분담에 주목하십시오. ODS가 취약점을 찾아낸 것이 아니라, Semgrep이 찾아냈습니다. ODS의 역할은 속성 부여(attribution, 이 변경 사항이 AI의 도움을 받았음을 명시), 집계(aggregation, 외부 탐지 결과를 하나의 점수와 하나의 정책 입력값으로 통합), 그리고 집행(enforcement, 사용자의 Rego 규칙 및 단일 종료 코드 적용)이었습니다. ODS는 기존에 신뢰하던 분석 도구들을 대체하려 드는 대신, 그 도구들과 결합하여 작동합니다.

점수 산정 철학: AI 사용은 죄가 아니다

이전 버전의 점수 산정 방식은 "AI 코드 비율" 자체를 기술 부채(technical debt)로 취급했습니다. 그것은 잘못된 방식이었으며, 현재는 수정되었습니다. 깨끗하고 완전히 AI가 작성한 변경 사항은 이제 ~0점을 받습니다.

현재 모델은 결함 밀도(defect density), 높음/심각(high/critical) 탐지 결과, 커버리지 공백(coverage gaps), 중복(duplication)과 같은 실제 품질 신호들을 기본 부채로 형성합니다. AI 비율은 그 위에 제한된 리스크 승수(risk multiplier) (1.0× ~ 1.5×)로만 작용합니다. 왜냐하면 AI가 작성한 결함은 인간이 논리적으로 검토하지 않은 결함이기 때문입니다. 품질 문제는 AI 비중이 높은 변경 사항에서 증폭되지만, AI의 양 자체만으로는 결코 부채를 생성하지 않습니다.

만약 당신의 AI가 테스트를 거친 깨끗한 코드를 작성한다면, ODS는 이를 통과시킵니다. 이는 설계된 대로 작동하는 것입니다. 핵심은 게이트키핑(gatekeeping, 통제)이 아니라 거버넌스(governance, 관리)에 있습니다.

데모를 구축하다 우리 도구 자체에서 버그를 발견하다

이 이야기는 들려줄 가치가 있습니다. 실행 가능한 예제가 왜 중요한지에 대한 논거 그 자체이기 때문입니다.

위의 워크스루(walkthrough)를 구축하던 중, 게이트가 차단을 거부하는 현상이 발생했습니다. 실제 Semgrep 탐지 결과들이 심각도 info 수준으로 통과되어 버린 것입니다. 이유는 다음과 같습니다. Semgrep은 심각도를 개별 결과가 아닌 SARIF 규칙의 defaultConfiguration.level에 배치하는데, 데이터 수집기(ingester)가 결과별 필드만 읽도록 되어 있었습니다. 모든 실제 Semgrep 탐지 결과가 조용히 정보성(informational) 수준으로 강등되고 있었으며, 이는 운영 환경에서 정책 게이트가 Semgrep의 어떤 결과도 결코 차단하지 못했을 것임을 의미합니다.

실제로 실행 가능한 데모가 단위 테스트(unit tests)와 문서화(documentation)가 잡아내지 못한 것을 찾아냈습니다. 수정 사항은 워크스루(walkthrough)가 배포되기 전에 이미 반영되었습니다. 이 글에서 얻을 수 있는 단 하나의 비(non)-ODS 교훈을 꼽으라면, 여러분의 예제는 반드시 실행 가능하게 만드십시오.

아직은 할 수 없는 것들

여러분이 명확한 판단을 내릴 수 있도록 솔직한 한계점을 밝힙니다:

• 기여도 식별(Attribution)을 회피할 수 있습니다. Squash-and-strip(스쿼시 및 스트립) 방식은 트레일러(trailers)를 제거합니다. ODS는 공개된 AI 사용 여부를 측정하며, 이는 _거버넌스(governance)_를 위한 올바른 기반이지, 우리가 어차피 승산 없는 게임이라고 생각하는 포렌식 탐지(forensic detection)가 아닙니다.
• 내장 분석기는 휴리스틱(heuristic) 방식입니다. 흔한 AI 코드 스멜(code smells)을 겨냥한 5가지 규칙이 포함되어 있습니다. 실제 결함을 찾아내는 강력한 힘은 SARIF를 통해 여러분이 기존에 사용 중인 분석기(analyzers)로부터 나와야 합니다. 내장 기능은 제품 그 자체가 아니라, 보조적인 신호(fallback signal)로 취급하십시오.
• 임계값(Thresholds)은 휴리스틱한 기본값입니다. 점수 판정(pass / review / block at 1 / 3 / 5)은 합리적인 시작점일 뿐, 정밀하게 교정된 과학적 수치가 아닙니다. 여러분의 자체적인 Rego 정책으로 이를 재정의하십시오. 그것이 이 도구가 존재하는 이유입니다.
• 아직 초기 단계입니다. ODS 조직은 자체 리포지토리의 모든 PR(Pull Request)에 대해 이 도구를 직접 사용(dogfoods)하고 있으며, 이제 막 외부 프로젝트를 온보딩하기 시작했습니다. 얼리 어답터(Early-adopter) 영역에 있습니다.

사용해 보기

• 사양 및 워크스루(Spec & walkthrough): github.com/open-delivery-spec/spec
• CLI (Go): github.com/open-delivery-spec/cli — go install github.com/open-delivery-spec/cli/cmd/ods@latest
• GitHub Action: github.com/open-delivery-spec/validate-action

모든 것은 Apache-2.0 라이선스입니다. 실제 리포지토리에서 실행해 보신다면, 메인테이너들은 무엇이 고장 났는지, 무엇이 잘못 차단되었는지, 어떤 임계값이 말이 안 되었는지에 대한 의견을 진심으로 듣고 싶어 할 것입니다. 그러한 피드백은 스타(star) 하나보다 더 가치 있습니다 (물론 스타도 좋습니다).

여러분의 리포지토리는 이미 1년 이상 AI 기여도 데이터를 축적해 왔습니다. 이를 읽기 시작하는 데 드는 비용은 워크플로(workflow) 파일 하나면 충분합니다.