PatchTrack으로 추적하는 AI 생성 코드 기여도와 소프트웨어 감사

PR에 남은 AI 코드의 흔적을 측정하는 PatchTrack

AI가 제안한 코드가 제품 코드에 어느 정도 반영됐는지 파악하는 일은 단순한 사용량 집계로 끝나지 않는다. 코드 품질, 지적재산권, 소프트웨어 공급망을 함께 검토해야 하는 감사 대상이 된다.

PatchTrack은 ChatGPT가 제안한 코드 패치가 실제 풀 리퀘스트에 어떤 수준으로 들어갔는지를 토큰 단위에서 자동 분류하고 정량화하는 arXiv 연구 도구다. 다니엘 오겐르워트(Daniel Ogenrwot)와 존 부싱게(John Businge)는 2025년 5월, ChatGPT 사용을 자인(self-admitted)한 338개의 풀 리퀘스트와 255개 저장소를 분석했다. 대상에는 AI 생성 코드 스니펫 645개와 개발자 작성 패치 3,486개가 포함됐다.

⤢✕

이 연구가 다루는 공백은 세 갈래다. AI 도구의 제안이 실제 제품 코드에 반영됐는지 자동으로 추적할 방법이 부족했고, 학습 데이터의 오픈소스 코드가 생성물에 재현될 때 라이선스 문제가 생길 수 있었다. 기업 공급망 안에서 AI 코드의 비율을 측정할 표준 방법론도 미비했다.

토큰 비교로 패치 적용 여부를 판정하는 방식

PatchTrack의 처리 과정은 데이터 수집, 패치 추출, 패치 분류, PR 집계, 정성 분석으로 이어진다. GitHub에서는 https://chat.openai.com/share/[a-zA-Z0-9-]{36} 패턴의 ChatGPT 대화 링크를 포함한 PR을 식별한다. 이후 해당 링크를 오프라인 HTML로 변환하고 GitHub API에서 PR diff를 추출한다.

추출된 패치는 토큰 수준에서 비교돼 hunk별 레이블을 받고, hunk 결과는 PR 수준으로 집계된다. 마지막으로 주제 코딩(thematic coding)을 적용해 수용 패턴을 분류한다.

n-gram 토큰 매칭은 이 과정의 중심이다. 연구팀은 n=1, 2, 3, 4를 비교했으며, 단어 단위인 unigram(n=1)이 가장 높은 성능을 보였다.

N-gram	전체 정확도	정밀도	재현율	F1
n=1	97.5%	96.5%	96.7%	96.6%
n=2	96.9%	95.2%	94.7%	94.9%
n=3	97.2%	94.3%	94.3%	94.3%
n=4	97.1%	95.3%	94.4%	94.8%

짧거나 부분적인 코드 단편이 자주 나타나는 ChatGPT 응답에서는 unigram이 가장 높은 재현율을 보였기 때문에 선택됐다. 정규화 과정에는 공백과 주석 제거, 코드 소문자 변환, 비ASCII 문자 필터링, 38가지 파일 타입을 대상으로 한 구문 인식 휴리스틱이 들어간다.

자료 구조도 성능에 영향을 준다. PatchTrack은 선행 도구 PaReco의 블룸 필터(O(n) 조회) 대신 해시 테이블 임시 배열을 사용해 O(1) 평균 조회를 달성했다.

⤢✕

PR은 세 범주로 나뉜다. PA(Patch Applied)는 토큰 매칭이 1개 이상인 경우로 116건(40.7%)이었다. PN(Patch Not Applied)은 스니펫은 있으나 매칭이 없는 경우로 63건(22.1%), NE(No Existing Patch)는 ChatGPT 코드 스니펫을 식별하지 못한 경우로 106건(37.2%)이다.

수동 검증은 230개 PR을 대상으로 신뢰수준 95%, 오차범위 5%에서 수행됐다. 평가자 간 코헨 카파(Cohen's Kappa)는 0.85였다. 다만 GitHub API가 400행을 초과한 diff를 생략하면서 위음성(false negative)이 발생할 수 있고, 단일 토큰 매칭은 의미론적 관련성 없이 위양성(false positive)을 낼 수 있다.

적용 여부보다 실제 통합 강도를 보는 지표

PatchTrack은 패치가 적용됐는지 여부만 보지 않고, 제안 코드가 병합 코드에 얼마나 남았는지도 계산한다. 이를 위해 Jaccard 포함률을 사용한다.

Jacc(t_x, t_y) = |t_x ∩ t_y| / |t_x| × 100

t_x는 ChatGPT 토큰 집합이고 t_y는 병합된 코드 토큰 집합이다. 이 값은 AI가 제안한 코드 중 병합 코드에 포함된 비율을 백분율로 나타낸다.

분석에서 중앙값 통합률은 25%였고, 상위 사분위(75th percentile)도 38%에 그쳤다. 병합 PR의 75%는 제안 코드의 38% 이하만 채택했다. PA로 분류된 PR은 전체의 40.7%였지만, 실제 코드 통합 강도는 낮았다.

89개 PR의 심층 분석에서는 구조적 통합(Structural Integration), 선택적 추출(Selective Extraction), 반복적 정제(Iterative Refinement), 직접 구현(Direct Implementation), 제약 처리(Constraint Handling), 지식 지원(Knowledge Support)이라는 반복 패턴이 확인됐다. 개발자는 전체 구조와 로직을 유지한 채 세부 구현을 고치기도 하고, 필요한 함수나 블록만 가져가기도 했다. AI 제안을 출발점으로 여러 차례 수정하는 경우도 있었으며, 거의 그대로 병합하는 직접 구현은 드문 경우였다. 환경과 의존성 제약에 맞춰 코드를 조정하거나, 코드를 채택하지 않고 개념과 접근법만 참고하는 패턴도 나타났다.

NE 범주가 전체 PR의 37.2%를 차지한 점도 중요하다. 이는 AI의 영향이 코드 패치 생성에만 머물지 않는다는 뜻이다. 문서와 주석 개선, 명명 규칙과 아키텍처 의사결정 가이드, 디버깅 전략과 코드 리뷰 지침에도 AI가 활용될 수 있다.

공급망 감사에 필요한 탐지·측정·검증·추적

2025~2026년 산업계에는 AI 코드 감사를 위한 구조적 공백이 있다. 조직의 95%가 개발에 AI 도구를 활용하지만 AI 생성 코드를 체계적으로 평가하는 조직은 24%에 그친다. 31%의 조직은 AI 코드 검증·감사에 월 10시간 이하를 쓰며, 5%는 감사를 전혀 수행하지 않는다. 53%의 조직은 전격 감사에서 아티팩트의 출처와 버전을 보고하는 데 상당한 수작업이 필요하다.

⤢✕

PatchTrack의 방법론을 기업 환경에 확장하면 감사 체계는 탐지, 측정, 검증, 추적 계층으로 나눌 수 있다. 탐지 계층은 패턴 매칭과 LLM 워터마크 감지로 AI 생성 코드를 식별하고, 커밋 메타데이터에 AI 기여 태그를 붙이는 방식을 다룬다.

측정 계층은 파일·함수·라인 단위로 저장소 전체의 AI 코드 비율을 산출하고 모듈과 팀별 기여도를 정량화한다. 검증 계층에서는 오픈소스 라이선스 호환성 스캔과 보안 취약점의 정적·동적 분석을 연계한다. 추적 계층은 AI 생성 항목을 포함한 SBOM(Software Bill of Materials)을 만들고, 프롬프트 로그·코드 변경 이력·승인 기록을 보존한다.

이 체계에서 볼 지표로는 전체 신규 코드 중 AI 생성 코드가 차지하는 비율, Jaccard 포함률에 따른 통합 강도, 최종 병합 전 리뷰·수정 횟수, 인간 작성 코드와 비교한 결함 밀도 차이, AI 코드 구간의 SAST 취약점 밀도가 있다.

라이선스와 출처를 함께 관리해야 하는 이유

오픈소스 라이선스 관점에서는 AI가 학습 데이터로 활용한 GPL·AGPL 코드가 생성물에 재현될 때 라이선스 감염 가능성이 생길 수 있다. 라이선스 비호환 컴포넌트가 AI를 통해 코드베이스에 무의식적으로 들어올 수 있고, 원출처가 불명확한 상태에서 퍼미시브 라이선스와 카피레프트 라이선스가 혼용될 위험도 있다.

CI/CD 파이프라인에서는 ScanOSS·FOSSA를 통합해 AI 생성 코드를 알려진 오픈소스 코드 패턴과 대조할 수 있다. Sigstore 기반 암호화 검증으로 코드 아티팩트에 서명을 추가해 출처와 무결성을 증명하고, 재현 가능 빌드(Reproducible Build)로 동일 입력에서 동일 출력을 보장해 감사 신뢰성을 확보하는 방식도 포함된다. 프롬프트 라이브러리를 로그로 관리해 생성 맥락을 추적하고, GPL v3·AGPL 등 고위험 라이선스가 탐지되면 법무팀으로 자동 에스컬레이션하는 게이트웨이도 고려 대상이다.

감사 추적에는 AI 도구에 입력한 요청의 타임스탬프·사용자·도구 정보를 담은 프롬프트 로그, 생성된 원본 코드 스니펫, 개발자가 수정한 과정의 diff, 리뷰어의 수용·거부 기록이 필요하다. AI 생성 컴포넌트도 SBOM의 명시적 항목으로 포함한다.

토큰 매칭이 남긴 한계와 확장 과제

PatchTrack에는 GitHub API의 400행 초과 diff 생략으로 대형 패치에서 위음성이 발생하는 제약이 있다. 토큰 수준 매칭은 구조적 동일성은 탐지할 수 있지만 기능적 동일성을 판정하지 못한다. 현재는 ChatGPT(OpenAI) 사용 패턴에 특화돼 Copilot·Gemini·Claude 등 다른 AI 도구를 지원하지 않으며, ChatGPT 사용을 스스로 밝힌 PR만 연구 표본에 들어가므로 은밀한 AI 사용은 탐지할 수 없다.

후속 방향으로는 Copilot·Cursor·Gemini Code Assist 등 여러 도구의 기여도를 함께 측정하는 방식, 코드 임베딩 기반 기능적 유사도 측정, CI/CD 안의 실시간 AI 기여도 대시보드, LLM 워터마크를 이용한 출처 추적 자동화가 제시된다. SPDX·CycloneDX SBOM 형식에 AI 컴포넌트 항목을 표준화하는 작업도 같은 흐름에 있다.

PatchTrack의 결과는 AI 코드가 완성된 구현물로 그대로 수용되기보다, 개발자가 수정하고 선택하는 출발점으로 쓰인다는 점을 보여준다. 중앙값 25%의 통합률은 AI와 인간의 협업이 AI 대체가 아니라 AI 보강의 방향으로 진행되고 있음을 수치로 보여준다. 소프트웨어 감사, IP 추적, 공급망 보안에서 이 방법론은 AI 코드 거버넌스 프레임워크를 설계하는 기반이 될 수 있다.