원문은 jonattan.in에 게시되었습니다.

앞으로 12개월 이내에, 당신의 엔지니어링 팀 외부의 누군가가 당신의 git 히스토리로는 답할 수 없는 질문을 던질 것입니다. 바로 이 코드베이스의 어느 부분이 AI에 의해 작성되었는가 하는 질문입니다.

그것은 벤더 실사(vendor due diligence)를 수행하는 고객일 수도 있습니다. 질문지에 AI 사용 여부를 추가한 SOC 2 또는 ISO 27001 감사관일 수도 있습니다. 혹은 순수하게 AI가 생성한 저작물은 저작권 보호를 받을 수 없으며, 인간이 실제로 작성한 것을 보호하기 위해서는 AI가 생성한 부분을 식별하고 권리를 포기(disclaimed)해야 한다는 미국 저작권청(U.S. Copyright Office)의 입장을 읽은 당신의 법무팀일 수도 있습니다. 누가 먼저 묻든, 오늘날 대부분의 기업이 내놓는 정직한 답변은 동일합니다. 우리는 모르며, 이를 재구성할 방법도 없다는 것입니다.

AI가 자동 완성(autocomplete) 제안을 작성하던 2024년에는 그 답변이 괜찮았을지 모릅니다. 하지만 에이전트(agents)가 풀 리퀘스트(pull requests)를 열고, 밤새 모듈 전체를 리팩터링(refactor)하며, 많은 팀에서 병합된 코드 라인의 대부분을 생성하게 될 2026년에는 괜찮지 않습니다. 도구(tooling)의 도입 속도가 거버넌스(governance)보다 빨랐고, 이 둘 사이의 간극은 이제 실질적인 리스크(liability)가 되었습니다.

2026년에 이것이 시급해진 이유

올해 세 가지 별개의 압박이 하나로 모였으며, 그 중 어느 것도 사라지지 않을 것입니다.

EU AI Act(EU 인공지능법)의 투명성 규칙이 2026년 8월 2일에 시행됩니다. 그날부터 제50조가 효력을 발생하며, 다양한 모달리티(modalities)에 걸쳐 AI가 생성한 콘텐츠를 기계 판독이 가능한 방식으로 표시할 것을 요구합니다. 또한 이번 달에 서명자들이 공개 목록에 게시될 투명성에 관한 실무 지침(Code of Practice on transparency)도 함께 마련됩니다. 정확히 말하면, 제50조는 소스 코드가 아니라 사람에게 제시되는 콘텐츠(챗봇, 합성 미디어, 딥페이크)를 대상으로 합니다. 하지만 규제는 파급 효과를 통해 작동합니다. 일단 기업이 AI로 생성된 마케팅 문구의 출처(provenance)를 증명해야 하는 상황이 되면, 구매 팀은 구매하는 소프트웨어에 대해서도 동일한 질문을 던지기 시작할 것입니다. 챗봇의 경우 "충분히 명백한 AI 상호작용"이 방어 수단이 될 수 있습니다. 하지만 실사(due-diligence) 설문지에서는 방어 수단이 되지 못합니다.

저작권은 '예/아니오'의 문제가 아니라 스펙트럼의 문제입니다. 에이전트 워크플로우(agentic workflow)에서의 코드 저작권은 "사람이 모든 글자를 직접 타이핑함"부터 "사람이 프롬프트를 작성하고 출력을 편집함", 그리고 "사람이 잠든 사이에 에이전트가 변경 사항을 계획하고 실행함"에 이르는 스펙트럼을 가집니다. 저작권국(Copyright Office)은 각 파일이 그 스펙트럼의 어디에 위치하는지에 관심을 가집니다. 현재 상태의 git 로그는 이 중 어느 것도 기록하지 않습니다. jonattan이 작성한 커밋은 누가 git commit을 실행했는지는 알려주지만, 누가 그 변경 사항에 대해 추론했는지는 알려주지 않습니다.

감사관들이 따라잡고 있습니다. 보안 검토와 기업 고객의 평가 단계에서 코드베이스 내 AI 사용 여부를 직접적으로 묻기 시작했으며, "약 60% 정도로 추정합니다"라는 답변은 감사(audit)를 통과할 수 없는 답변입니다. 데이터로 답변할 수 있는 팀이 느낌(vibes)으로 답변하는 팀보다 기업 간 거래(enterprise deals)를 더 빠르게 성사시킬 것입니다.

엔지니어링 조직을 운영하고 있다면, 이는 에이전트가 페이지(pager)를 호출하기 시작했을 때 운영(ops) 세계가 배웠던 거버넌스(governance) 교훈과 동일합니다. 감사 추적(audit trail) 없는 자율성은 미래의 자신에게 빌려온 대출과 같습니다.

코드에 있어 "출처 (Provenance)"가 실제로 의미하는 것

유용한 출처 기록은 주어진 모든 변경 사항에 대해 네 가지 질문에 답합니다.

1. 기원 (Origin): 이 변경 사항은 사람이 직접 입력했는가, AI가 제안했는가, 사람이 검토한 AI 작성인가, 아니면 완전히 자율적이었는가?
2. 도구 (Instrument): 어떤 도구와 모델이 이를 생성했는가 (Claude Code, Codex, Cursor, 내부 에이전트 등), 그리고 어떤 버전인가?
3. 의도 (Intent): 어떤 프롬프트(prompt)나 작업 설명(task description)이 이를 유발했는가? 프롬프트가 없는 디프(diff)는 원인 없는 결과와 같습니다.
4. 감독 (Oversight): 어떤 사람이 이를 검토했으며, 얼마나 실질적으로 검토했는가?

질문 3번이 사실상 컨텍스트(context) 문제라는 점에 주목하십시오. 프롬프트, 에이전트가 읽은 파일, 그리고 에이전트가 작동한 지침이 코드에 대한 실제 설명입니다. 이는 제가 컨텍스트 엔지니어링 (context engineering)에 대해 주장했던 것과 동일한 논리입니다. 에이전트가 행동할 때 알고 있었던 정보가 전체 워크플로(workflow)에서 가장 가치 있으면서도 가장 많이 버려지는 산출물입니다. 출처(Provenance)는 시간을 거슬러 올라가는 컨텍스트 엔지니어링입니다.

실무 플레이북 (Practical Playbook)

엔터프라이즈 플랫폼을 구매하지 않고도 "전혀 모르는 상태"에서 "감사 준비 완료" 상태로 갈 수 있습니다. 비용이 저렴한 순서대로 구성한 스택은 다음과 같습니다.

1. 지금 바로 커밋 트레일러 (Commit trailers) 도입하기

Git에는 이미 메커니즘이 있습니다. Claude Code는 기본적으로 Co-Authored-By: Claude 트레일러를 추가하지만, 대부분의 팀은 이를 노이즈로 느껴 삭제합니다. 삭제를 멈추십시오. 대신 이를 표준화하고 확장하십시오.

feat: rate-limit the webhook endpoint

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

트레일러는 기계가 읽을 수 있으며 (git log --format='%(trailers)'), 커밋 본문의 산문보다 리베이스(rebase) 시 더 잘 유지되며, 비용도 들지 않습니다. 한 페이지 분량의 컨벤션(convention) 문서와 라벨이 없는 커밋을 거부하는 CI 린트(lint)만 갖춰도 가치의 80%를 얻을 수 있습니다.

2. 에이전트 세션 유지하기

모든 코딩 에이전트(coding agent)는 세션 트랜스크립트(session transcript), 즉 프롬프트(prompts), 읽은 파일, 실행한 명령어를 생성합니다. 대부분의 팀은 이러한 기록들이 발생한 노트북에서 그대로 증발하도록 방치합니다. 이를 아카이브(archive)하세요. 커밋 SHA(commit SHA)를 키로 사용하는 단순한 S3 버킷만 있어도, "에이전트가 이것을 작성한 것 같습니다"라는 추측을 "이 디프(diff)를 생성한 정확한 대화 기록은 이것입니다"라는 확신으로 바꿀 수 있습니다.

3. 커밋을 프롬프트에 자동으로 연결하기

이 영역은 새로운 도구들이 빠르게 등장하고 있는 단계입니다. 이번 달에 출시된 brain0는 제가 발견한 것 중 가장 흥미로운 도구입니다. 이 도구는 Claude Code 및 Codex 세션을 수동적으로 수집하고, 모든 커밋을 그 뒤에 있는 에이전트 프롬프트와 연결하는 결정 그래프(decision graph)를 구축하며, 서명된 출처 증명(provenance attestations)과 함께 기본적으로 오프라인에서 실행됩니다. 단 하나의 명령어로 작동하며, Node 20을 사용하고, 외부 유출(egress)이 없습니다. 이를 중심으로 출처 도구 카테고리(category of provenance tools)가 성장하고 있지만, 벤더(vendor)보다 중요한 것은 패턴입니다. 나중에 재구성할 수 없으므로, 발생하는 즉시 프롬프트와 커밋 간의 연결 고리를 캡처해야 합니다.

4. PR 템플릿에 출처 기입하기

풀 리퀘스트(pull request, PR) 템플릿에 필수 필드를 하나 추가하세요: AI 참여 여부(없음 / 보조 / 에이전트 작성) 및 검토한 사람(reviewing human)입니다. 리뷰어들은 이미 리뷰 시점에 답을 알고 있습니다. 이를 기록하는 데는 10초가 걸리지만, 18개월 후에 이를 복구하는 데는 포렌식 프로젝트(forensic project) 수준의 비용이 듭니다.

5. AI 코드 탐지기에 신경 쓰지 마세요

유혹적인 지름길은 저장소(repo)에 분류기(classifier)를 실행하여 사후에 코드를 라벨링하는 것입니다. 하지만 연구 결과에 따르면 귀속(attribution)은 탐지기가 복구할 수 없는 스펙트럼 상에 존재한다는 것이 명확합니다. 대폭 수정된 AI 출력물과 관용적인(idiomatic) 인간의 코드는 빠르게 수렴합니다. 탐지는 확률적인 추측일 뿐입니다. 작성 시점에 캡처된 출처(provenance)는 기록(record)입니다. 감사관(auditors)은 기록을 수용합니다.

불편한 부분

이 작업을 수행하는 이유는 단순히 컴플라이언스 연극(compliance theater)을 하기 위해서가 아닙니다. 출처(provenance)가 팀 내부의 인센티브(incentives)를 변화시키기 때문입니다.

AI가 작성한 코드에 라벨(label)이 붙으면, 리뷰 노력은 실제 리스크가 존재하는 곳으로 향하게 됩니다. 프롬프트(prompts)가 아카이브(archive)되면, 잘못된 변경 사항을 디버깅(debugging)할 때 고고학적 발굴(archaeology) 대신 이를 생성한 추론(reasoning) 단계부터 시작할 수 있습니다. 그리고 고객이 "이 중 얼마나 AI가 작성했습니까?"라고 물었을 때, 경쟁사가 시간을 벌기 위해 후속 회의를 잡고 있는 동안 당신은 수치와 방법론(methodology)을 가지고 답변할 수 있게 됩니다.

이전의 모든 엔지니어링 거버넌스(engineering governance) 물결(버전 관리 그 자체, 코드 리뷰, CI, SBOMs)은 그것이 필수 요건(table stakes)이 되기 직전까지는 관료적인 오버헤드(bureaucratic overhead)처럼 보였습니다. AI 코드 출처(AI code provenance)는 현재 정확히 그 변곡점(inflection point)에 와 있으며, 달력에는 8월 2일이라는 규제 날짜가 표시되어 있습니다. "이 코드를 누가 작성했는가"에 답할 수 있는 팀은 코드를 가장 많이 직접 타이핑한 팀이 아닐 것입니다. 그들은 그것을 기록(write down)한 팀이 될 것입니다.