이 코드는 누가 만들었나: AI Coding Agent 시대의 Git Provenance와 PR 증명서 설계

이경규·2026년 8월 19일

이 코드는 누가 만들었나: AI Coding Agent 시대의 Git Provenance와 PR 증명서 설계

예전에는 Git Commit을 보면 대체로 질문이 단순했다.

누가 작성했는가?

언제 변경했는가?

왜 변경했는가?

그래서 Git에는 이미 필요한 정보가 상당 부분 들어 있다.

Author

Committer

Timestamp

Commit Message

Diff

Pull Request

Reviewer

그런데 Coding Agent가 본격적으로 개발 Workflow 안으로 들어오면서 이 정보만으로는 부족해지기 시작했다.

예를 들어 이런 Commit이 있다고 하자.

Fix race condition in session refresh

작성자는:

developer@company.com

이다.

하지만 실제 과정은 이랬을 수도 있다.

Developer
   ↓
Claude Code
   ↓
Subagent 3개가 원인 조사
   ↓
Claude Code가 코드 수정
   ↓
Agent가 Test 생성
   ↓
Agent가 Build 실행
   ↓
Developer가 Diff 확인
   ↓
Commit

Git에는 최종적으로 사람 이름만 남아 있다.

그러면 몇 달 뒤 이 코드를 보는 사람은 알 수 없다.

이 코드는 사람이 직접 작성했는가?

AI가 대부분 작성했는가?

어떤 Agent가 작성했는가?

어떤 모델을 사용했는가?

어떤 Prompt에서 시작됐는가?

Agent가 어떤 Tool을 실행했는가?

Test는 실제로 실행했는가?

사람은 어디까지 검토했는가?

Coding Agent가 단순 자동완성 수준일 때는 크게 중요하지 않았다.

하지만 Agent가:

Repository 조사

Architecture 판단

코드 수정

Test 작성

Shell 실행

Dependency 변경

PR 생성

까지 수행하기 시작하면 이야기가 달라진다.

이제 Source Code에도 Provenance, 즉 “이 변경이 어디에서 어떤 과정으로 만들어졌는가”에 대한 정보가 필요해진다.

1. Provenance는 이미 Software Supply Chain에서 중요한 개념이다

Provenance 자체는 AI 때문에 새로 생긴 개념이 아니다.

SLSA에서는 Provenance를 Software Artifact가 어디서, 언제, 어떤 방식으로 만들어졌는지를 추적할 수 있는 검증 가능한 정보로 정의한다. 현재 SLSA 1.2에서는 Build Provenance뿐 아니라 Source Provenance도 별도 Track으로 다루고 있다.

Build Artifact라면 이런 질문에 답한다.

어떤 Source에서 빌드됐는가?

어떤 Builder가 만들었는가?

어떤 Build Definition을 사용했는가?

어떤 Input이 들어갔는가?

SLSA Build Provenance의 목적 역시 Artifact가 예상된 방식으로 만들어졌는지 검증하고, 필요하다면 재현할 수 있도록 하는 것이다.

이 개념을 Coding Agent에 가져오면 질문이 조금 바뀐다.

어떤 Agent가 변경했는가?

누가 Agent를 시작했는가?

어떤 Repository 상태에서 실행됐는가?

Agent가 어떤 Policy 아래서 작업했는가?

무슨 검증을 통과했는가?

사람은 어디에서 승인했는가?

이것을 Agent Provenance라고 생각할 수 있다.

2. Git Author만으로는 부족하다

기존 Git에서는 보통 다음 정도면 충분했다.

Author:
Kim Developer

Commit:
a81f3ce

하지만 AI Agent 시대에는 Author와 실제 생성 주체가 다를 수 있다.

예를 들어:

Human Initiator
      │
      ▼
Coding Agent
      │
      ▼
Generated Patch
      │
      ▼
Human Review
      │
      ▼
Commit

이 경우 Commit Author를 누구로 해야 할까?

사람?

Agent?

둘 다?

정답은 프로젝트 정책에 따라 달라질 수 있지만 중요한 것은 정보를 잃어버리지 않는 것이다.

GitHub는 이 문제를 이미 일부 해결하기 시작했다.

2026년 3월부터 GitHub Copilot Coding Agent가 만든 Commit은 Copilot이 Author가 되고, 작업을 시작한 사람은 Co-author로 기록된다. 여기에 Agent-Logs-Url Commit Trailer를 추가해 해당 Commit에서 실제 Agent Session Log까지 추적할 수 있게 했다.

즉:

Commit

↓

Agent

↓

Human Initiator

↓

Agent Session

연결이 생긴 것이다.

3. 앞으로 Commit은 결과가 아니라 실행 기록의 Entry Point가 된다

기존:

Commit
  ↓
Diff

Agent 시대:

Commit
  │
  ├─ Diff
  ├─ Agent Identity
  ├─ Human Initiator
  ├─ Session
  ├─ Validation
  ├─ Policy
  └─ Evidence

가 될 가능성이 높다.

Commit만 읽으면 모든 내용을 다 보여줄 필요는 없다.

대신 Provenance Record로 연결할 수 있으면 된다.

예:

commit a81f3ce

Agent: claude-code
Agent-Session: sess_9d71
Initiated-By: kim@company.com
Validation: agent-validation-182
Provenance: provenance/a81f3ce.json

이런 식이다.

4. Commit Message에 모든 정보를 넣으면 안 된다

처음에는 이렇게 하고 싶어진다.

Generated by Claude Code
Model: ...
Prompt: ...
Session: ...
Files read: ...
Commands executed: ...
Tests: ...

하지만 Commit Message가 금방 엉망이 된다.

Git Commit에는 Index 역할을 하는 최소 정보만 남기는 것이 낫다.

예:

Fix session refresh race condition

Agent: claude-code
Agent-Session: sess_9d71
Human-Initiator: kim@company.com
Provenance-Id: prov_01892

나머지는 별도 Provenance Object로 저장한다.

5. Agent Provenance Record를 만든다면 무엇을 넣을까

최소 구조는 다음 정도면 충분하다.

{
  "version": "1",
  "commit": "a81f3ce",
  "agent": {
    "name": "claude-code",
    "sessionId": "sess_9d71"
  },
  "initiator": {
    "type": "human",
    "id": "kim@company.com"
  },
  "repository": {
    "url": "git@company/mobile-app.git",
    "baseRevision": "3a8cd12"
  },
  "task": {
    "id": "MOB-1421",
    "type": "bugfix"
  },
  "validation": {
    "build": "passed",
    "tests": "passed",
    "lint": "passed"
  },
  "humanReview": {
    "required": true,
    "status": "approved"
  }
}

여기서 중요한 것은 Agent가 작성했다고 주장하는 것과 실제로 검증된 사실을 구분하는 것이다.

6. “Agent가 Test를 실행했다”와 “Test가 통과했다”는 다르다

Agent가 보고한다.

모든 테스트가 통과했습니다.

이 문장을 Provenance에 그대로 넣으면 안 된다.

좋은 구조는:

Agent Claim

과

Verification Evidence

를 나눈다.

예:

{
  "validation": {
    "tests": {
      "status": "passed",
      "command": "./gradlew test",
      "exitCode": 0,
      "runner": "ci-runner-182",
      "artifact": "test-results-182"
    }
  }
}

즉:

Agent의 말

X

실행 결과

O

가 Source of Truth가 되어야 한다.

7. Provenance에서 가장 중요한 필드는 Agent 이름이 아닐 수도 있다

처음에는 다음에 집중하기 쉽다.

Claude가 만들었나?

Codex가 만들었나?

Copilot이 만들었나?

하지만 실제 Audit에서는 이것보다 더 중요한 정보가 있다.

누가 실행했는가?

어떤 Repository Revision에서 시작했는가?

어떤 권한을 가지고 있었는가?

어떤 Policy를 적용했는가?

어떤 검증을 통과했는가?

사람이 승인했는가?

Agent Vendor는 바뀔 수 있다.

하지만 Execution Context는 계속 중요하다.

8. 그래서 Agent Identity와 Runtime Identity를 분리하는 게 좋다

예:

{
  "agent": {
    "product": "claude-code"
  },
  "runtime": {
    "environment": "self-hosted",
    "runner": "agent-runner-42",
    "sandbox": "sandbox-921",
    "policy": "coding-agent-v12"
  }
}

지난 글에서 다룬 Self-hosted Coding Agent Runtime과 연결되는 지점이다.

Agent가:

어디에서 실행됐는가

도 Provenance의 일부가 된다.

9. Model 정보는 얼마나 남겨야 할까

다음처럼 남길 수도 있다.

{
  "model": {
    "provider": "anthropic",
    "family": "claude"
  }
}

하지만 Model ID를 무조건 Audit의 핵심으로 삼는 것은 조심해야 한다.

서비스에 따라 내부 Routing이 바뀔 수도 있고, 특정 Agent 제품이 Model을 자동 선택할 수도 있다.

따라서 Provenance Schema를:

agentProduct

agentVersion

model

runtime

policy

로 분리하는 편이 좋다.

Model 정보가 제공되는 경우 기록하고, 그렇지 않은 경우 억지로 추정하지 않는다.

10. Prompt 전체를 저장해야 할까

여기서도 고민이 생긴다.

Agent가 작업한 Prompt를 그대로 저장하면 재현성은 좋아질 수 있다.

하지만 Prompt 안에는:

고객 정보

Internal URL

Secret

Security Issue

미공개 Feature

개발자 개인 정보

가 포함될 수 있다.

그래서 Provenance에 Raw Prompt를 넣는 것은 권장하기 어렵다.

대신:

{
  "task": {
    "id": "MOB-1421",
    "summary": "Fix session refresh race condition"
  },
  "promptArtifact": {
    "id": "prompt-182",
    "retention": "30d",
    "access": "restricted"
  }
}

처럼 분리할 수 있다.

11. Provenance와 Agent Log도 분리한다

구조를 세 단계로 나누면 깔끔하다.

Commit

↓

Provenance

↓

Detailed Session Log

Commit:

작은 Metadata

Provenance:

구조화된 요약 + Evidence

Session Log:

상세 Tool Call / Conversation

이다.

GitHub가 Copilot Coding Agent Commit에서 Session Log URL을 Trailer로 연결한 방식 역시 이 방향과 비슷하다.

12. 모든 Agent Conversation을 영구 저장할 필요는 없다

Coding Agent Conversation은 상당히 클 수 있다.

또 민감한 정보가 들어갈 수도 있다.

그래서 Retention을 나눈다.

Commit Provenance

장기 보관

Validation Evidence

중장기 보관

Detailed Agent Conversation

30~90일

같은 식이다.

Compliance 요구에 따라 조정한다.

13. PR에는 별도의 “Agent Contribution Manifest”를 붙일 수 있다

Commit 하나보다 PR 단위가 더 유용할 수도 있다.

예:

version: 1

contribution:
  pullRequest: 1842

agents:
  - product: claude-code
    role: implementation

  - product: internal-review-agent
    role: review

human:
  initiator: kim@company.com
  reviewer: lee@company.com

changes:
  type: bugfix
  risk: medium

validation:
  unitTest: passed
  integrationTest: passed
  lint: passed

externalDependencies:
  added: false

humanApproval:
  required: true
  completed: true

이것을 PR 증명서처럼 생각할 수 있다.

14. 왜 PR 단위가 좋은가

Agent 작업은 Commit 하나에 끝나지 않는다.

Agent Commit 1

Agent Commit 2

Agent Commit 3

Human 수정

Agent 수정

Squash

가 흔하다.

Squash Merge하면 개별 Commit Provenance가 흐려질 수도 있다.

PR은 전체 Contribution의 경계로 사용하기 좋다.

PR

=

Task Boundary

+

Review Boundary

+

Validation Boundary

이기 때문이다.

15. PR Template에 단순 체크박스를 넣는 것부터 시작할 수도 있다

거창한 Platform이 없어도 된다.

## AI Assistance

- [x] AI Coding Agent 사용
- Agent: Claude Code
- Human Initiator: @kim

## Validation

- [x] Unit Test
- [x] Build
- [x] Lint
- [ ] Integration Test

## Human Review

- [x] Agent가 생성한 Diff 전체 확인

## External Dependency

- [x] 새 Dependency 없음

이 정도만으로도 기존보다 정보가 훨씬 많아진다.

16. 하지만 Self-Reported Checkbox만으로 끝내면 약하다

사람이나 Agent가:

[x] Test Passed

를 체크했다고 실제 Test가 통과한 것은 아니다.

그래서 CI가 Provenance를 채우게 한다.

Agent

↓

PR

↓

CI

↓

Validation Evidence

↓

Manifest Update

예:

validation:

  unitTest:
    status: passed
    workflowRun: 829124

  lint:
    status: passed
    workflowRun: 829125

검증 정보는 CI가 작성한다.

17. Provenance를 누가 생성해야 하는가

Agent가 직접 만들면 간단하다.

하지만 신뢰 문제가 있다.

Agent

↓

Code 작성

↓

Provenance 작성

↓

“모두 정상”

이면 자기평가가 된다.

더 강한 구조는:

Agent Runtime

↓

Execution Event

↓

Provenance Service

이다.

Agent가 직접 Metadata를 만드는 게 아니라 Runtime이 실제 Event에서 자동 생성한다.

18. Event 기반으로 Provenance를 쌓는다

예:

session.started

tool.executed

file.modified

test.completed

build.completed

branch.pushed

pr.created

human.approved

이벤트가 발생할 때마다 기록한다.

마지막에는:

Event Stream

↓

Provenance Builder

↓

Contribution Manifest

로 만든다.

이렇게 하면 Agent가 기억해서 적을 필요가 없다.

19. 가장 좋은 Provenance는 자동 생성된다

개발자에게 매번:

어떤 모델 썼어요?

테스트 했어요?

몇 번 Retry 했어요?

Agent Session ID 뭐예요?

를 입력시키면 곧 무너지기 시작한다.

좋은 구조:

Agent Runtime

Git

CI

PR

Review

에서 자동으로 데이터를 가져온다.

사람이 적는 것은:

왜 이 변경을 승인했는가

정도면 된다.

20. Human Contribution도 Provenance에 남긴다

AI만 기록하면 안 된다.

예:

{
  "contributors": [
    {
      "type": "agent",
      "role": "implementation"
    },
    {
      "type": "human",
      "id": "kim",
      "role": "initiator"
    },
    {
      "type": "human",
      "id": "lee",
      "role": "reviewer"
    }
  ]
}

중요한 질문은:

AI가 몇 퍼센트 작성했나?

보다

누가 어떤 책임을 맡았나?

일 수 있다.

21. “AI가 70% 작성했다”는 지표는 생각보다 애매하다

Line Count로 계산할 수도 있다.

Agent 700줄

Human 300줄

하지만 사람은 Agent가 만든 700줄을 모두 검토하고 설계를 수정했을 수도 있다.

반대로 사람이 100줄만 추가했지만 결정적인 Business Logic을 작성했을 수도 있다.

그래서:

AI Contribution %

만으로 판단하는 것은 위험하다.

역할 기반 기록이 더 유용하다.

Agent

Implementation

Human

Architecture Decision

Agent

Testing

Human

Approval

22. 최근 OSS 연구에서도 Disclosure가 중요한 주제가 되고 있다

2026년 공개된 연구는 1,000개의 인기 GitHub Repository를 조사해 118개의 AI Contribution Policy를 확인했다.

그중 78%는 AI 지원 Contribution을 허용했지만, 51%는 AI 사용 사실의 Disclosure를 요구했고 74%는 Human-in-the-loop를 요구했다.

즉 OSS에서도 단순한:

AI 허용 / 금지

보다:

AI 사용 사실을 밝혀라.

사람이 책임지고 확인해라.

라는 방향이 상당히 중요해지고 있다.

23. 그런데 Agent가 이런 규칙을 스스로 읽을까

여기서 문제가 생긴다.

2026년 7월 공개된 RepoComplianceBench 연구는 AI Contribution Rule이 있는 49개 Repository의 106개 Issue를 이용해 Coding Agent가 실제 규칙을 따르는지 평가했다.

연구 결과 현재 Agent들은 Repository의 AI Contribution Rule을 자발적으로 찾아 읽는 경우가 거의 없었다. Rule을 Prompt에 알려주거나 Verifier Feedback을 주면 Disclosure와 Verification 수행은 개선됐지만, AI Contribution이 금지된 Repository에서도 Agent가 스스로 Contribution을 포기하지 않는 문제가 남았다.

이건 중요한 의미가 있다.

CONTRIBUTING.md에 써놨으니
Agent가 알아서 지키겠지.

라고 기대하면 안 된다는 것이다.

24. Contribution Rule은 Agent Runtime이 강제해야 한다

예:

Repository

↓

Policy Discovery

↓

Contribution Policy

↓

Agent Runtime

Repository에:

aiContribution:

  allowed: true

  disclosure: required

  humanReview: required

  verification:
    - unit-test
    - lint

같은 Machine-readable Policy를 둘 수 있다.

Agent가 읽지 않아도 Runtime이 강제한다.

25. AGENTS.md와 Provenance Policy는 역할이 다르다

AGENTS.md:

어떻게 코딩할 것인가

Provenance Policy:

AI Contribution을
어떻게 기록하고 검증할 것인가

이다.

예:

AGENTS.md

Architecture
Naming
Testing

.ai/contribution-policy.yaml

Disclosure
Human Gate
Audit
Retention

이렇게 나눌 수 있다.

26. Contribution Policy 예시

version: 1

ai:
  allowed: true
  disclosure: required

human:
  reviewerRequired: true

provenance:
  required: true
  sessionId: required
  runtimeIdentity: required

validation:
  required:
    - build
    - unit-test
    - lint

externalDependency:
  requireApproval: true

Agent Platform이 이 파일을 읽는다.

27. Risk에 따라 요구하는 Provenance 수준도 달라질 수 있다

모든 변경에 같은 기록이 필요하지 않다.

예:

README 수정

Risk: Low

필요:

Agent Disclosure
Human Review

반면:

Authentication Logic

Risk: High

필요:

Agent Identity

Session

Runtime

Tool History

Security Test

Dependency Report

Human Reviewer 2명

처럼 달라질 수 있다.

28. Risk Tier를 둔다

Tier 0

Documentation
Formatting

Tier 1

일반 UI
Small Refactor

Tier 2

Business Logic
Database
Network

Tier 3

Auth
Payment
Security
Production

그리고:

tier3:

  provenance: full

  sessionLog: required

  securityValidation: required

  reviewers: 2

처럼 Policy를 정한다.

29. Provenance는 Reviewer의 시간을 줄이는 방향이어야 한다

목적이:

Audit 문서 하나 더 만들기

가 되어서는 안 된다.

Reviewer에게 보여줄 정보는 간단해야 한다.

AI CONTRIBUTION

Agent
Claude Code

Initiated By
Kim

Risk
Medium

Files
8

Dependencies
No change

Build
PASS

Tests
42 / 42 PASS

Lint
PASS

Architecture
PASS

Human Review
Required

이 정도면 한눈에 들어온다.

30. PR 상단에 Agent Summary Card를 만들 수 있다

예:

┌─────────────────────────────┐
│ Agent Contribution          │
├─────────────────────────────┤
│ Agent        Claude Code    │
│ Session      #A-182         │
│ Human        @kim           │
│ Risk         MEDIUM         │
│ Files        8              │
│ Dependency   No change      │
├─────────────────────────────┤
│ Build        PASS           │
│ Test         PASS           │
│ Lint         PASS           │
│ Security     N/A            │
├─────────────────────────────┤
│ Reviewer     REQUIRED       │
└─────────────────────────────┘

Reviewer가 먼저 이것을 보고 Diff로 들어간다.

31. Agent가 여러 개면 어떻게 기록할까

앞으로는 하나의 PR에 Agent 하나만 참여하지 않을 가능성이 높다.

Planner Agent

↓

Coding Agent

↓

Test Agent

↓

Review Agent

라면:

{
  "agents": [
    {
      "role": "planner",
      "session": "p-182"
    },
    {
      "role": "implementation",
      "session": "c-721"
    },
    {
      "role": "test",
      "session": "t-501"
    }
  ]
}

처럼 역할별로 기록한다.

32. Subagent까지 전부 기록해야 할까

작은 내부 Worker까지 전부 PR에 표시할 필요는 없다.

그러면 Noise가 너무 많아진다.

추천은:

Top-level Agent

PR Provenance에 표시

Subagent

Session Trace에 표시

이다.

필요할 때 Drill-down 한다.

33. Provenance Graph로 생각하면 쉽다

Human
  │
  ▼
Main Agent
  │
  ├─ Search Agent
  ├─ Test Agent
  └─ Security Agent
  │
  ▼
Commit
  │
  ▼
CI
  │
  ▼
PR
  │
  ▼
Reviewer

이 전체가 하나의 Contribution Graph다.

34. Agent Provenance를 Hash와 연결할 수도 있다

좀 더 강한 무결성이 필요하다면 Provenance Object를 Hash한다.

provenance.json

↓

SHA-256

↓

Commit Trailer

예:

Provenance-SHA256:
7ae913...

그러면 Provenance가 나중에 변경됐는지 확인할 수 있다.

35. 더 강하게 가면 Attestation으로 만든다

SLSA가 Build Artifact Provenance를 Attestation으로 표현하는 것처럼, Agent Contribution도 Attestation 방식으로 확장할 수 있다.

예:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "git-commit",
      "digest": {
        "sha1": "a81f3ce"
      }
    }
  ],
  "predicateType":
    "https://company.example/agent-contribution/v1",
  "predicate": {
    "agent": "claude-code",
    "session": "sess_182",
    "initiator": "kim",
    "validation": "ci-829"
  }
}

이것은 SLSA 공식 Agent Schema가 아니라 in-toto/SLSA의 Provenance 개념을 Agent Contribution에 응용한 설계 예시다.

SLSA 자체는 Provenance를 Artifact가 어떻게 만들어졌는지 설명하는 검증 가능한 Attestation으로 정의하고 있다.

36. 왜 Signature까지 고려할까

JSON 파일만 Repository에 두면 수정할 수 있다.

예:

validation: failed

↓

validation: passed

로 바꿔버릴 수 있다.

Attestation에 Signature가 있다면:

Provenance

↓

Signed by Agent Platform

↓

Verified by PR Gate

구조를 만들 수 있다.

37. Agent 자신이 Sign하면 안 된다

Agent Sandbox 안에 Signing Key를 넣으면 의미가 줄어든다.

Agent가:

코드 작성

+

자기 증명서 생성

+

자기 Signature

를 모두 수행한다.

더 좋은 구조:

Agent Sandbox

↓

Runtime Event

↓

Trusted Control Plane

↓

Attestation

↓

Signature

이다.

이 역시 SLSA Build Provenance에서 Builder와 Control Plane의 신뢰 경계를 분리하는 사고방식과 비슷하다. SLSA는 builder.id가 해당 Build를 신뢰성 있게 수행하고 Provenance를 기록하는 Platform의 신뢰 경계를 표현한다고 설명한다.

38. Runtime이 실제 Source Revision을 기록해야 한다

Agent에게:

어느 Commit에서 시작했어?

라고 묻지 않는다.

Runtime이 Git에서 직접 읽는다.

git rev-parse HEAD

결과:

3a8cd124...

Provenance:

{
  "baseRevision": "3a8cd124..."
}

이다.

39. Diff Digest도 남길 수 있다

git diff --binary HEAD

를 기반으로 Hash를 만들 수도 있다.

Patch

↓

Digest

↓

Provenance

그러면 Agent가 검증받은 Patch와 실제 Merge된 Patch가 같은지 확인할 수 있다.

40. CI 결과도 Digest와 연결하면 좋다

예:

Patch SHA

4e92...

CI:

Build PASS
Test PASS

PR Merge 직전:

현재 Patch SHA

4e92...

같음.

그러면:

검증 이후 코드가 바뀌지 않았다.

를 확인할 수 있다.

41. Agent가 수정한 뒤 사람이 고쳤다면?

흔한 상황이다.

Agent Patch

↓

Human 수정

↓

Final Patch

Provenance는 이를 숨기지 않는다.

{
  "agentContribution": true,
  "humanModificationAfterAgent": true
}

정도로 남길 수 있다.

하지만 줄 단위 Attribution을 완벽하게 계산하려고 할 필요는 없다.

42. 핵심은 책임 추적이다

몇 줄을 누가 썼는지를 100% 밝히는 것보다:

이 Task는 누가 시작했는가?

Agent가 어떤 권한으로 작업했는가?

누가 결과를 승인했는가?

무슨 검증을 통과했는가?

가 훨씬 중요하다.

43. AI Detection으로 Provenance를 해결하려 하면 안 된다

다른 접근은:

이 코드를 분석해서
AI가 썼는지 찾아내자.

이다.

하지만 이것은 사후 추정이다.

Provenance는 반대 방향이어야 한다.

생성 순간부터
Metadata를 남긴다.

즉:

Detection

X

Attestation

O

이다.

44. 왜 Detection보다 Attestation이 나을까

Detection:

Code

↓

Classifier

↓

AI 작성 확률 82%

Attestation:

Agent Session

↓

Runtime Event

↓

Commit

↓

Signed Evidence

두 방식의 신뢰 수준이 다르다.

AI가 만든 코드와 사람이 만든 코드의 Style이 점점 비슷해질수록 Detection은 더 어려워질 수 있다.

반면 Provenance는 생성 과정에서 기록된다.

45. Agent Contribution이 이미 OSS Governance 문제로 번지고 있다

2026년 연구에서는 AI Contribution 증가 속도가 Maintainer가 Risk와 Evidence를 평가할 수 있는 속도보다 빠를 수 있다는 문제를 지적하고 있다.

Agent Governance Manifest 연구는 Repository 수준에서 AI Contribution을 관리하려면 단순한 Agent-readable Rule이나 Trace만으로는 부족하고 Risk, Evidence, Accountability, Review Gate를 함께 구조화해야 한다고 제안한다.

이게 바로 Provenance가 단순 Metadata에서 끝나면 안 되는 이유다.

46. Provenance 다음 단계는 Governance다

단계가 이렇게 발전한다.

1.

Agent-readable

Agent가 Rule을 읽을 수 있다.

↓

2.

Traceable

누가 무엇을 했는지 추적할 수 있다.

↓

3.

Governable

Risk에 따라 Policy와 Approval을 강제할 수 있다.

최근 Agent Governance 연구 역시 비슷하게 agent-readability, traceability, governability의 세 층으로 문제를 정리한다.

47. Repository에 이런 구조를 둘 수 있다

repo/
├── AGENTS.md
│
├── .ai/
│   ├── contribution-policy.yaml
│   └── provenance-schema.json
│
├── .github/
│   ├── pull_request_template.md
│   └── workflows/
│       └── agent-provenance.yml
│
└── src/

각 역할은:

AGENTS.md

Coding Rule

contribution-policy.yaml

Governance

provenance-schema.json

Metadata Contract

CI

Verification

이다.

48. PR Workflow 예시

Developer

"이 Bug 수정해줘."

↓

Agent Runtime

Session 생성

↓

Coding Agent

수정

↓

Runtime

Provenance Event 수집

↓

Agent

Branch Push
PR 생성

↓

CI

Build
Test
Lint
Security

↓

Provenance Service

Manifest 생성

↓

PR Check

Policy 검증

↓

Human Reviewer

Diff + Evidence 검토

↓

Merge

이다.

49. CI Gate는 이렇게 판단할 수 있다

rules:

  aiDisclosure:
    required: true

  provenance:
    required: true

  validation:
    build: required
    test: required

  humanReview:
    required: true

PR이 조건을 충족하지 않으면:

MERGE BLOCKED

한다.

50. Agent가 만든 PR인데 Provenance가 없다면?

Agent identity detected

+

No provenance

이면:

BLOCK

또는 최소:

WARNING

을 낼 수 있다.

정책 수준에 따라 다르게 한다.

51. 일반적인 AI autocomplete까지 전부 기록할 필요는 있을까

여기서 Scope를 정해야 한다.

IDE에서:

한 줄 자동완성

까지 Provenance로 남기기 시작하면 Noise가 너무 많아진다.

처음에는 다음 기준이 현실적이다.

Agent가 독립 Task를 수행했는가?

Repository를 탐색했는가?

여러 파일을 수정했는가?

Shell / Test를 실행했는가?

Commit / PR을 만들었는가?

여기에 해당하면 Agent Contribution으로 본다.

52. Assistant와 Agent의 경계를 나눌 수 있다

Autocomplete

No Provenance

Chat Suggestion

Optional

Agent File Modification

Disclosure

Agent Commit / PR

Full Provenance

정도로 시작할 수 있다.

53. 회사에서는 Compliance와 연결될 가능성이 높다

기업이 Coding Agent를 수백 명에게 배포하면 보안팀에서 언젠가는 묻게 된다.

어떤 Repository에서
Agent를 사용하고 있나요?

누가 Agent 작업을 승인했나요?

Agent가 Production Credential을 사용했나요?

Agent 코드가 어떤 검증을 받았나요?

Provenance가 있다면 답하기 쉬워진다.

54. Audit Query도 가능해진다

예:

SELECT *
FROM agent_contributions
WHERE risk = 'high'
AND human_review = false;

또는:

SELECT *
FROM agent_contributions
WHERE external_dependency_added = true;

또는:

SELECT *
FROM agent_contributions
WHERE validation_status != 'passed';

처럼 볼 수 있다.

55. Security Incident 때 특히 가치가 커진다

어떤 취약한 코드가 발견됐다.

Commit

a81f3ce

Provenance를 따라간다.

Commit

↓

Agent Session

↓

Task

↓

Runtime

↓

Tool Calls

↓

Validation

↓

Reviewer

어떤 경로로 문제가 들어왔는지 빠르게 알 수 있다.

56. Agent가 Dependency를 추가했다면 더 중요하다

예:

Agent

↓

npm install obscure-package

↓

Commit.

Provenance:

{
  "dependencyChanges": [
    {
      "package": "obscure-package",
      "action": "added",
      "approved": false
    }
  ]
}

CI가:

External Dependency Approval Missing

으로 막을 수 있다.

57. Provenance가 Supply Chain Security와 만나는 지점이다

기존 Software Supply Chain에서는:

Source

↓

Build

↓

Artifact

의 Provenance를 관리했다.

Agent 시대에는 그 앞 단계가 추가된다.

Human Intent

↓

Agent

↓

Source Change

↓

Build

↓

Artifact

즉 Software Supply Chain의 출발점이 한 단계 앞으로 이동한다.

58. Source Provenance가 더 중요해지는 이유다

SLSA 1.2는 Provenance를 Build에만 한정하지 않고 Source Track도 별도로 다룬다. Source Provenance는 Source Code Revision과 그 생성 과정의 Change Management를 추적하는 방향이다.

Coding Agent Provenance 역시 이 Source 단계와 매우 가까운 문제다.

59. 다만 Agent Provenance 표준이 이미 완성됐다고 보면 안 된다

현재 SLSA에는 공식적으로:

Claude Code Agent Provenance

Codex Provenance

Copilot Agent Provenance

같은 표준 Schema가 있는 것은 아니다.

GitHub는 자체적으로 Copilot Coding Agent Commit과 Session Log 연결 기능을 제공하고 있고, 연구와 OSS 정책은 AI Disclosure와 Human Review 쪽을 빠르게 다루고 있다.

따라서 이 글에서 제안한:

Agent Contribution Manifest

Agent Attestation

PR 증명서

는 이러한 흐름을 기반으로 한 실무 Architecture 제안이다.

60. 가장 작은 도입 방식

처음부터 Attestation Platform을 만들 필요는 없다.

1단계:

PR Template

AI 사용 여부
Agent 이름
Human Reviewer

2단계:

Commit Trailer

Agent Session
Human Initiator

3단계:

CI Validation Metadata

4단계:

Structured Provenance JSON

5단계:

Signed Attestation

순으로 가면 된다.

61. 작은 팀이라면 이것만 해도 충분하다

## Agent Contribution

Agent:
Claude Code

Initiated by:
@kim

Session:
A-182

Validation:
- Build ✅
- Test ✅
- Lint ✅

External dependencies:
None

Human review:
@lee

이걸 PR에 자동 생성한다.

62. 큰 조직이라면 Control Plane에서 만든다

Agent Gateway

↓

Session

↓

Runtime Events

↓

Provenance Service

↓

Signed Manifest

↓

GitHub / GitLab Check

이 구조가 더 적합하다.

63. Provenance Service가 가져야 할 최소 정보

Identity

Agent
Human
Runtime

Input

Repository
Base Revision
Task

Execution

Session
Policy
Tool

Output

Commit
Patch Digest

Verification

Build
Test
Lint
Security

Governance

Risk
Human Review
Approval

정도다.

64. 개인정보와 사내 정보도 고려해야 한다

Provenance를 많이 남긴다고 무조건 좋은 것은 아니다.

예:

Prompt 전체

모든 Shell Output

모든 Internal URL

모든 DB Query

를 영구 저장하면 새로운 보안 문제가 생긴다.

따라서:

Minimum Necessary Evidence

원칙이 중요하다.

65. Provenance에는 결정만 남기고 상세 Log는 별도 보관한다

예:

Test

PASS

Provenance에 저장.

상세:

20MB test.log

Artifact Storage에 저장.

필요할 때만 링크를 따라간다.

66. Secret Redaction은 필수다

Runtime Event:

curl -H "Authorization: Bearer abc..."

를 그대로 저장하면 안 된다.

Audit Pipeline:

Event

↓

Secret Scanner

↓

Redaction

↓

Storage

를 거친다.

67. Retention도 Risk에 따라 다르게 한다

예:

Low Risk

Session Log 30일

Medium Risk

90일

High Risk

1년

처럼 정책을 둘 수 있다.

실제 기간은 조직 Compliance 요구에 맞춘다.

68. PR 증명서는 Reviewer를 대체하는 것이 아니다

이 구조를 만든다고:

Agent Provenance PASS

↓

자동 Merge

해야 하는 것은 아니다.

Provenance는 Reviewer가 무엇을 믿을 수 있는지 명확하게 만들어주는 Evidence Layer다.

69. Reviewer는 코드보다 Evidence를 먼저 볼 수도 있다

앞으로 PR Review 순서가:

Diff

↓

Test

에서:

Contribution Manifest

↓

Risk

↓

Validation

↓

Diff

↓

Human Decision

으로 바뀔 수도 있다.

특히 AI가 만든 PR 수가 늘어날수록 그렇다.

70. 이것이 중요한 이유

Coding Agent 시대의 문제는:

AI가 코드를 작성한다.

자체가 아니다.

더 어려운 문제는:

AI가 작성한 코드가
조직의 기존 Software Governance 안으로
어떻게 들어오는가?

이다.

이걸 해결하려면:

Agent Identity

Traceability

Validation

Human Accountability

Policy

Attestation

이 필요하다.

71. 마무리

Git은 오랫동안 Software Development의 기록 시스템 역할을 해왔다.

누가

언제

무엇을

왜

바꿨는지를 남겼다.

Coding Agent가 개발 과정에 들어오면서 하나의 질문이 더 생긴다.

어떻게 만들어졌는가?

앞으로 Commit 하나에는 단순한 Diff보다 훨씬 많은 과정이 숨어 있을 수 있다.

Human

↓

Main Agent

↓

Subagents

↓

Tools

↓

Runtime

↓

Tests

↓

Reviewer

그래서 Git History만으로는 Software Change의 전체 경로를 설명하기 어려워진다.

필요한 것은 AI Detection이 아니다.

이 코드는 AI가 만들었을 확률이 87%.

가 아니라:

이 변경은

Claude Code Session A-182가 만들었고,

Kim이 작업을 시작했고,

Self-hosted Runner 42에서 실행됐으며,

Build와 Test를 통과했고,

Lee가 최종 Review했다.

라고 말할 수 있어야 한다.

핵심 구조는 다음과 같다.

Agent Task

↓

Execution Trace

↓

Source Change

↓

Validation Evidence

↓

Human Review

↓

Provenance

↓

Commit / PR

그리고 Provenance는 가능하면 Agent의 자기 보고가 아니라:

Agent Runtime

Git

CI

Review System

에서 자동으로 만들어져야 한다.

한 줄로 정리하면:

AI Coding Agent 시대에는 코드의 내용만 Review하는 것이 아니라, 그 코드가 어떤 Agent·Runtime·Policy·Validation·Human Review를 거쳐 만들어졌는지까지 함께 Review하는 시대가 오고 있다.

Git이 코드의 History를 기록했다면, 다음 단계는 Agent가 만든 Software Change의 History까지 기록하는 것이다.

참고 자료

GitHub — Trace any Copilot coding agent commit to its session logs
GitHub Copilot Coding Agent Commit에서 Agent를 Author, 작업을 시작한 사람을 Co-author로 기록하고 Agent-Logs-Url Trailer를 통해 Commit과 실제 Agent Session Log를 연결하는 기능.
SLSA 1.2 — Provenance
Software Artifact가 어디에서, 언제, 어떤 과정으로 생성됐는지 추적할 수 있는 검증 가능한 정보로 Provenance를 정의하며 Build와 Source Provenance를 별도로 다룬다.
SLSA 1.2 — Build Provenance
Builder, Build Definition, Input, Run Details 등을 기록해 Artifact가 예상된 Build Process를 통해 만들어졌는지 검증할 수 있도록 하는 공식 Provenance Schema.
A First Look at Coding Agents' Compliance with AI Contribution Rules in Open-Source Communities
AI Contribution Rule이 존재하는 49개 Repository의 106개 Issue를 기반으로 Coding Agent Compliance를 평가한 연구. Agent가 Rule을 자발적으로 검색하는 경우가 거의 없었고, Prompt·Rule Disclosure·Verifier Feedback을 통해 Disclosure와 Verification은 개선할 수 있었지만 AI 금지 Repository에서의 자발적 거부는 해결되지 않았다.
AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI?
인기 GitHub Repository 1,000개를 분석해 118개의 AI Contribution Policy를 확인한 연구. 분석된 Policy의 51%가 AI 사용 Disclosure를 요구했고 74%가 Human-in-the-loop를 요구했다.
Making Agent-Mediated Contributions Governable
AI Contribution Governance를 Agent-readability, Traceability, Governability의 세 단계로 바라보고 Risk·Evidence·Accountability·Review Gate를 Repository 수준에서 구조화해야 한다고 제안한 최근 연구.

핵심 참고 포인트

GitHub는 이미 Copilot Coding Agent의 Commit을 실제 Agent Session Log와 연결하기 시작했다. 이는 Agent가 생성한 Source Change에 “누가 시작했고 어떤 Agent Session에서 나왔는가”라는 Provenance가 실제 제품 기능으로 들어오기 시작했다는 의미다.

최근 OSS 연구에서도 단순한 AI 사용 허용 여부보다 Disclosure, Verification, Human Review가 중요한 Governance 요소로 나타나고 있다. 하지만 Coding Agent가 Repository의 Contribution Rule을 스스로 찾아 읽고 준수할 것이라고 가정하기 어렵기 때문에, 중요한 정책은 Prompt가 아니라 Runtime·CI·Merge Gate에서 결정론적으로 강제하는 편이 안전하다.

SLSA의 Provenance 개념은 현재 Agent Contribution 전용 표준은 아니지만, Source → Builder → Artifact의 생성 경로를 검증 가능한 Metadata로 남긴다는 사고방식은 Coding Agent에도 그대로 적용할 수 있다. 따라서 실무에서는 Commit Trailer → PR Manifest → CI Evidence → Signed Attestation 순으로 단계적으로 도입하는 방식이 현실적이다.

이경규

iOS 앱 개발자

이전 포스트

Claude Code를 회사 서버에서 돌린다: Self-Hosted Coding Agent Runtime 실전 설계

다음 포스트

이 코드는 누가 만들었나: AI Coding Agent 시대의 Git Provenance와 PR 증명서 설계

이 코드는 누가 만들었나: AI Coding Agent 시대의 Git Provenance와 PR 증명서 설계

1. Provenance는 이미 Software Supply Chain에서 중요한 개념이다

2. Git Author만으로는 부족하다

3. 앞으로 Commit은 결과가 아니라 실행 기록의 Entry Point가 된다

4. Commit Message에 모든 정보를 넣으면 안 된다

5. Agent Provenance Record를 만든다면 무엇을 넣을까

6. “Agent가 Test를 실행했다”와 “Test가 통과했다”는 다르다

7. Provenance에서 가장 중요한 필드는 Agent 이름이 아닐 수도 있다

8. 그래서 Agent Identity와 Runtime Identity를 분리하는 게 좋다

9. Model 정보는 얼마나 남겨야 할까

10. Prompt 전체를 저장해야 할까

11. Provenance와 Agent Log도 분리한다

12. 모든 Agent Conversation을 영구 저장할 필요는 없다

13. PR에는 별도의 “Agent Contribution Manifest”를 붙일 수 있다

14. 왜 PR 단위가 좋은가

15. PR Template에 단순 체크박스를 넣는 것부터 시작할 수도 있다

16. 하지만 Self-Reported Checkbox만으로 끝내면 약하다

17. Provenance를 누가 생성해야 하는가

18. Event 기반으로 Provenance를 쌓는다

19. 가장 좋은 Provenance는 자동 생성된다

20. Human Contribution도 Provenance에 남긴다

21. “AI가 70% 작성했다”는 지표는 생각보다 애매하다

22. 최근 OSS 연구에서도 Disclosure가 중요한 주제가 되고 있다

23. 그런데 Agent가 이런 규칙을 스스로 읽을까

24. Contribution Rule은 Agent Runtime이 강제해야 한다

25. AGENTS.md와 Provenance Policy는 역할이 다르다

26. Contribution Policy 예시

27. Risk에 따라 요구하는 Provenance 수준도 달라질 수 있다

28. Risk Tier를 둔다

29. Provenance는 Reviewer의 시간을 줄이는 방향이어야 한다

30. PR 상단에 Agent Summary Card를 만들 수 있다

31. Agent가 여러 개면 어떻게 기록할까

32. Subagent까지 전부 기록해야 할까

33. Provenance Graph로 생각하면 쉽다

34. Agent Provenance를 Hash와 연결할 수도 있다

35. 더 강하게 가면 Attestation으로 만든다

36. 왜 Signature까지 고려할까

37. Agent 자신이 Sign하면 안 된다

38. Runtime이 실제 Source Revision을 기록해야 한다

39. Diff Digest도 남길 수 있다

40. CI 결과도 Digest와 연결하면 좋다

41. Agent가 수정한 뒤 사람이 고쳤다면?

42. 핵심은 책임 추적이다

43. AI Detection으로 Provenance를 해결하려 하면 안 된다

44. 왜 Detection보다 Attestation이 나을까

45. Agent Contribution이 이미 OSS Governance 문제로 번지고 있다

46. Provenance 다음 단계는 Governance다

47. Repository에 이런 구조를 둘 수 있다

48. PR Workflow 예시

49. CI Gate는 이렇게 판단할 수 있다

50. Agent가 만든 PR인데 Provenance가 없다면?

51. 일반적인 AI autocomplete까지 전부 기록할 필요는 있을까

52. Assistant와 Agent의 경계를 나눌 수 있다

53. 회사에서는 Compliance와 연결될 가능성이 높다

54. Audit Query도 가능해진다

55. Security Incident 때 특히 가치가 커진다

56. Agent가 Dependency를 추가했다면 더 중요하다

57. Provenance가 Supply Chain Security와 만나는 지점이다

58. Source Provenance가 더 중요해지는 이유다

59. 다만 Agent Provenance 표준이 이미 완성됐다고 보면 안 된다

60. 가장 작은 도입 방식

61. 작은 팀이라면 이것만 해도 충분하다

62. 큰 조직이라면 Control Plane에서 만든다

63. Provenance Service가 가져야 할 최소 정보

64. 개인정보와 사내 정보도 고려해야 한다

65. Provenance에는 결정만 남기고 상세 Log는 별도 보관한다

66. Secret Redaction은 필수다

67. Retention도 Risk에 따라 다르게 한다

68. PR 증명서는 Reviewer를 대체하는 것이 아니다

69. Reviewer는 코드보다 Evidence를 먼저 볼 수도 있다

70. 이것이 중요한 이유

71. 마무리

참고 자료

핵심 참고 포인트

Claude Code를 회사 서버에서 돌린다: Self-Hosted Coding Agent Runtime 실전 설계

집에도 AI Agent를 둔다: Google Home·Apple Home·Matter 가전을 연결해 만드는 자율 스마트홈

0개의 댓글