기술 요약: 코드 저장소 내 LLM 생성 코드 및 주석에 관한 탐색적 연구

1. 문제 정의

코드 생성 및 요약을 위한 대규모 언어 모델(LLM)의 급격한 도입으로 인해, 주요 기술 기업의 코드 중 20%에서 30%가 LLM에 의해 생성되었다는 보고가 있습니다. 그러나 디버깅 시간 증가, 부자연스러운 주석 생성, 취약점 유입 가능성 등에 대한 우려와 함께, 이 콘텐츠의 실제 유용성에 대한 상당한 회의론이 존재합니다.

광범위한 사용에도 불구하고, 실제 저장소 내 LLM 생성 콘텐츠의 실제 비율, 그 특성, 그리고 소프트웨어 버그와의 연관성을 정량화하는 실증적 데이터는 부족한 실정입니다. 이를 해결하는 데 있어 주요 과제는 공개 저장소 내에 정답 레이블(인간이 검증한 LL로 생성된 콘텐츠)이 부재하다는 점입니다. 따라서 기존 탐지 도구를 활용한 프록시 기반 분석을 통해 LLM 사용 현황을 파악할 필요가 있습니다.

2. 방법론

본 연구는 2021년 10월부터 2025년 10월까지 활발하게 운영되는 소프트웨어 저장소의 코드와 주석을 조사하기 위해 탐지기 기반 프록시 분석(detector-based proxy analysis) 프레임els를 채택하였습니다.

데이터 수집 및 선택

• 저장소: 포함 기준(활발한 개발, 주류 언어, 분석 가능한 텍스트)과 제외 기준(자동 생성 템플릿 없음, 포크된 저장소 아님)에 따라 8개의 활성 저장소를 선정했습니다. 이 세트는 4개의 기업 관리 저장소(Go-github, Guava, Liquid, Zap)와 4개의 커뮤니티 관리 저장소(Act, Jadx, Kafka, Pandas)를 포함합니다.
• 시간 범위: Codex 및 GitHub Copilot과 같은 주요 LLM의 출시 시기에 맞춰 2021년부터 2025년까지 매년 데이터를 수집했습니다.
• 콘텐츠: 소스 파일은 코드와 주석을 추출하기 위해 전처리되었습니다.

탐지 도구

연구는 LLM에 의해 생성되었을 가능성이 높은 콘텐츠를 식별하기 위해 다음과 같은 제로샷 탐지기 제품군을 활용했습니다:

• 코드용: DetectCodeGPT (코드를 위해 특별히 설계됨).
• 주석용: Binoculars, Log-Likelihood, Entropy, Rank, Log-Rank, LRR, DetectGPT, Fast-DetectGPT.

임계값 보정

정답(ground truth)의 부재로 인해, 최적의 결정 임계값은 다음과 같이 도출되었습니다:

• 코드: DetectCodeGPT의 기본 임계값을 사용했습니다. 이는 개발자 저장소에서 평가되었기 때문입니다.
• 주석: AISE 데이터셋(2021년 이전에 수정된 파일의 주석만을 포함하도록 필터링하여 인간이 작성한 텍스트에 근사하도록 함)으로부터 임계값을 도출했습니다. 소프트웨어 공학(SE) 도메인에 적합한 임계값을 결정하기 위해 AUROC(Area Under the Receiver Operating Characteristic Curve)를 사용했습니다.

분석 절차

1. 시계열 분석: 시간이 경과함에 따라 탐지된 LLM 생성 콘텐츠의 비율을 추적했습니다.
2. 범주화: 수동 코딩 프로세스(상호 신뢰도 검사 포함)를 통해 탐지된 코드는 논리적 그룹(예: 핵심 로직, 테스트, 인터페이스)으로, 주석은 기능적 그룹(예: 메타, 설명, 유형)으로 분류했습니다.
3. 클론 탐지: CCFinderX를 사용하여 저장소 내부 및 저장소 간 코드 클론, 그리고 GPTCloneBench 데이터셋과의 클론을 분석했습니다.
4. 언어적 분석: 철자, 구두점, 문법 및 AI 관련 어휘의 빈도를 평가하기 위해 주석을 분석했습니다.
5. 버그 연관성: 인간이 레이블을 지정한 버그를 PreciseBugs 데이터셋(특히 2021년 이후의 NVD 및 OSS-Fuzz 소스)과 매핑하여, 해당 버그가 LLM 생성물로 탐지되는지 확인했습니다.

3. 주요 기여

본 논문은 세 가지 주요 기여를 합니다:

1. 실증적 정량화: 멀티 탐지기 프레임워크를 사용하여 다양한 저장소에 걸쳐 LLM에 의해 생성되었을 가능성이 높은 코드 및 주석의 비율을 광범위하게 분석하고, 주석 탐지를 위한 다양한 임계값을 테스트했습니다.
2. 비교 분석: 기업 관리 저장소와 커뮤니티 관리 저장소를 대조하여, LLM 생성 콘텐츠의 양과 특성 면에서 뚜렷한 차이를 밝혀냈습니다.
3. 버그 상관관계: 인간이 레이블을 지정한 버그가 LLM 생성 코드와 연관되었을 가능성이 있는 비율을 분석한 첫 번째 연구로서, 놀라울 정도로 낮은 상관관계를 발견했습니다.

4. 주요 결과

RQ1: 시계열 트렌드 및 범주화

• 코드: 대부분의 저장소에서 LLM 생성으로 탐지된 코드의 비율이 시간이 지남에 따라 감소했습니다(50%가 감소를 보임). 이 콘텐츠는 주로 테스트 케이스(예: Go-github의 61.6%, Pandas의 67.5%)에서 발견되었습니다.
• 주석: LLM 생성으로 탐지된 주석의 비율은 연도별로 비교적 안정적이었습니다. 이러한 주석은 주로 메타(저자 정보, 라이선스) 및 설명(Explanation) 카테고리에서 발견되었습니다.

RQ2: 탐지된 콘텐츠의 특성

• 코드 클론: LLM 생성으로 탐지된 코드는 높은 비율의 저장소 내 파일 수준 클론(종종 70% 이상)을 보였으나, 메서드 수준의 클론은 낮았습니다. 결정적으로, 이 코드 중 GPTCloneBench 데이터셋과 클론을 형성하는 경우는 매우 적었으며, 이는 개발자들이 GPT 출력을 그대로 붙여넣는 것이 아니라 통합하거나 수정하여 사용함을 시사합니다.
• 주석 속성: 탐지된 주석은 높은 구두점 정확도(~90%)를 보였으나, 문법적으로 올바른 문장의 빈도는 낮았고 AI 특유의 어휘 사용도 제한적이었습니다. 이는 일반적인 LLM 텍스트에 대한 일부 이전 연구 결과와 대조됩니다.

RQ3: 기업 vs. 커뮤니티 저장소

• 볼륨: 기업 관리 저장소는 커뮤니티 관리 저장소에 비해 LLM 생성으로 탐지된 코드와 주석의 비율이 더 높았습니다.
• 클론: 기업 저장소는 또한 더 높은 비율의 저장소 내 파일 수준 코드 클론을 나타냈습니다.
• 분포: 기업 저장소의 경우, 탐지된 코드는 테스트와 핵심 로직에 집중되어 있었던 반면, 커뮤니티 저장소는 더 분산된 패턴을 보였습니다. 기업 저장소의 탐지된 주석은 설명(Explanation) 및 메타(Meta) 카테고리에 더 집중되었습니다.

RQ4: 버그와의 연관성

• 인간이 레이블을 지정한 버그 중 LLM 생성물로 탐지된 비율은 매우 낮았습니다: NVD 데이터셋의 10.79%, OSS-Fuzz 데이터셋의 **5.56%**였습니다.
• 이는 LLM이 코드를 생성할 수는 있지만, 결과물인 버그가 드물거나, 커밋 전에 수정되거나, 혹은 탐지기가 특정 버그가 있는 LLM 코드를 식별하지 못함을 시사합니다.

5. 의의 및 주장

저자들은 자신들의 결과가 실제 LLM 사용량에 대한 정답(ground-truth) 측정이 아닌, 탐지기 출력에 기반한 프록시 기반 관찰임을 강조합니다. 초기 연도(2021–2023)의 높은 탐지율을 광범위한 LLM 채택에 대한 확정적 증거가 아닌 기초 참조점으로 해석해야 한다고 명시적으로 밝힙니다.

본 연구는 다음과 같은 몇 가지 중요한 통찰을 제공합니다:

• 전략적 사용: 탐지된 코드 생성의 감소 추세는 개발자들이 LLM을 더 전략적으로 사용하고 있거나(예: 코드 완성), 최신 모델이 인간의 글과 구별하기 어려울 정도로 정교해져서 탐지기의 민감도가 낮아졌음을 시사할 수 있습니다.
• 기술 부채 위험: 탐지된 코드에서 나타나는 높은 수준의 저장소 내 클론은 기술 부채의 위험을 시사하며, 자동 리팩토링 도구의 통합이 필요함을 보여줍니다.
• 버그 완화: 탐지된 LLM 콘텐츠와 인간 레이블 버그 사이의 낮은 연관성은 개발자들이 커밋 전에 LL로 생성된 코드를 효과적으로 검토하고 수정하거나, 분석된 데이터셋의 특정 버그(보안 및 런타임 예외)가 LLM 생성의 주요 실패 모드가 아님을 시사합니다.

결론적으로, LLM이 저장소 내에 점점 더 많이 존재하고 있지만, 코드 품질(버그 측면)에 미치는 영향은 인간의 검토에 의해 완화되는 것으로 보입니다. 다만, 코드 클로닝을 통한 기술 부채의 가능성은 여전히 우려 사항으로 남습니다. 향후 연구로는 특정 테스트 파일을 AI 지원 검토 대상으로 지정하는 것과 같이, AI 지원 콘텐츠를 검토하기 위한 가이드라인을 수립하는 것이 제안되었습니다.