본 논문은 다음을 주장한다: 2026년 4월 현재, AI 코딩의 핵심 메커니즘은 “코드 생성”이 아니라 “코드 검색과 패턴 정렬”이다. 2022년 GitHub Copilot의 행 수준 보완에서 2024년의 코드 블록 이식, 2026년의 다중 Agent 협업에 이르기까지, AI 코딩의 표면 아키텍처는 지속적으로 발전했지만, 기저 행동은 항상 search and move—훈련 데이터에서 가장 일치하는 코드 패턴을 검색하여 사용자 컨텍스트로 이식하는 것이었다. 본 논문은 세 가지 수준의 증거로 이 명제를 논증한다: 핵심 증거로 GitClear(2025년 2월 발표)의 2.11억 줄 코드 실증 분석—코드 복제 8배 증가와 리팩토링 60% 감소를 밝힘; 메커니즘 설명으로 코딩 주석의 역사적 진화(AI가 왜 호출 관계만 학습하고 설계 논리는 학습하지 못했는지 설명)와 AI 기업들의 “추론 궤적” 데이터 역수집 산업 동향(업계가 이 결함을 인식했음을 입증); 보조 검증으로 2025년 12월부터 2026년 3월까지의 실측 사례—Opus 4.5의 무한 루프와 Claude Code 다중 Agent의 아키텍처 불일치 현상. 본 논문은 결론을 현재 기술 단계에 한정하며, SWE-bench 등 벤치마크 테스트의 진전 데이터에 정면으로 대응하여, 이러한 진전이 여전히 검색 능력의 향상이지 추론 능력의 돌파가 아님을 논증한다.
오해받는 “코드 생성”
The Misunderstood “Code Generation”
2025년, 코드의 41%가 AI로 생성되거나 AI의 도움을 받아 작성되었다. 개발자의 84%가 AI 코딩 도구를 사용하거나 사용할 계획이다. GitHub Copilot 사용자의 프로젝트 완료 속도는 126% 향상되었다. 이 데이터는 하나의 서사를 만들어냈다: AI가 프로그래밍을 배우고 있다.
그러나 “프로그래밍을 배우다”와 “코드를 검색하고 이식하는 법을 배우다”는 완전히 다른 것이다. 인간 프로그래머가 코딩할 때 하는 일은: 현실 세계의 문제를 이해 → 머릿속에 추상 모델 구축 → 적합한 데이터 구조와 알고리즘 선택 → 여러 설계 방안 간의 트레이드오프 판단 → 코드를 작성하여 구현. 이 과정의 핵심은 설계 결정이다—왜 이 방안을 선택하고 저 방안은 선택하지 않았는가.
AI 코딩 도구가 하는 일은: 사용자의 자연어 설명을 수신 → 훈련 데이터(수십억 줄의 기존 코드)에서 가장 일치하는 코드 패턴을 검색 → 현재 컨텍스트에 맞게 변수명과 매개변수를 미세 조정 → 출력. 이 과정의 핵심은 패턴 매칭이다—가장 유사한 코드를 찾아서 이식하는 것.
본 논문은 논증한다: 2026년 4월 현재, 행 수준 보완에서 다중 Agent 협업까지, AI 코딩의 모든 진화는 검색 세분화와 병렬도의 향상이지, 검색에서 추론으로의 질적 전환이 아니다. “코드 생성”은 표면적 포장이고, “코드 검색과 정렬”이 기저 현실이다. 이 결론은 현재 기술 단계에 엄격히 한정된다—미래의 아키텍처 돌파(예: 신경-기호 추론 시스템)가 이 판단을 바꿀 수 있지만, 본 논문 작성 시점 현재 이러한 질적 전환이 발생했다는 증거는 없다.
2.11억 줄 코드가 밝히는 진실
What 211 Million Lines of Code Reveal
GitClear의 Google, Microsoft, Meta 및 기업 고객 저장소의 2.11억 줄 코드(2020-2024년) 분석은, AI 코딩 행동에 관한 가장 권위 있는 정량적 증거를 제공한다.
| 연도 | AI 채택률 | 복사/붙여넣기 | 리팩토링/이동 | 코드 이탈률 | 주요 사건 |
|---|---|---|---|---|---|
| 2020 | ~0% | 7.8% | 22% | 3.1% | Pre-AI 기준선 |
| 2021 | ~2% | 8.3% | 25% | 3.3% | Copilot 내부 테스트 |
| 2022 | ~10% | ~9.1% | ~20% | 3.8% | Copilot 정식 출시 |
| 2023 | ~44% | ~10.2% | ~14% | 4.5% | Copilot 폭발, ChatGPT 코딩 |
| 2024 | 63% | 12.3% | <10% | 5.7% | 최초: 복사 > 리팩토링 |
데이터 출처: GitClear AI Copilot Code Quality Reports(2024, 2025 발표). Google, Microsoft, Meta 및 기업 저장소의 2.11억 줄 코드 분석 기반. AI 채택률 데이터: Stack Overflow 2024 Developer Survey.
2026년 최신 데이터는 더욱 악화되었다. Opsera의 벤치마크 데이터에 따르면: AI가 생성한 Pull Request 수락률은 32.7%에 불과한 반면, 인간 코드는 84.4%이다. AI 코드의 버그는 1.7배 더 많고, 보안 취약점은 15-18% 더 많다. 코드 복제는 계속 48% 증가하고 있다. AI의 첫 번째 시도 정확률은 약 70%이며—나머지 30%의 오류는 바로 진정한 논리적 추론이 필요한 부분이다.
AI 코딩 진화사: 이식 세분화의 업그레이드
Evolution of AI Coding: Escalating Granularity of Search and Move
주석의 역사: AI가 왜 호출 논리만 학습했는가
The Annotation History: Why AI Only Learned Call Patterns
AI 코딩이 왜 검색 이식이지 논리 생성이 아닌지를 이해하려면, AI 훈련 데이터의 역사적 구조를 추적해야 한다.
1980년대-2000년대: 순수 코드 시대
이 시대의 코드는 변수명, 함수명, 연산자, 기호로만 이루어졌다. 주석은 극히 드물었고, 변수명은 a, tmp, buf 정도였으며, 함수명은 proc1, fn_x일 수 있었다. 컴퓨터 과학의 가장 정수인 프로그래밍 지혜—운영체제 커널, 데이터베이스 엔진, 컴파일러, 네트워크 프로토콜 스택—이 모두 이 시대에 작성되었다. 이 코드에는 자연어 주석이 거의 없었다.
int fn_x(char *buf, int n) {
int i, tmp = 0;
for(i=0; i<n; i++) tmp += buf[i] & 0xff;
return tmp % 256;
}
2010년대 이후: 주석 문화의 폭발
GitHub의 보편화(2010년대 폭발)로 코드는 “낯선 사람에게 보여주는 것”이 되었다; 애자일 개발은 빠른 인수인계를 요구했다; Stack Overflow는 “자연어로 코드를 설명하는” 습관을 배양했다; Code Review가 표준 프로세스가 되었다. 주석이 대량으로 등장하기 시작했다—그런데 그것들이 기록한 것은 무엇인가?
// Redis 캐시에 연결, 타임아웃 30초 설정
const client = redis.createClient({ timeout: 30000 });
// 절대 나타나지 않는 주석: “왜” 설명
// 영속성이 필요하고 향후 메시지 큐로 확장 가능하므로 Memcached 대신 Redis 선택
// 타임아웃 30초는 상위 API의 P99 지연 22초 + 네트워크 지터 안전 마진 때문
주석이 기록하는 것은 “What”—무엇을 호출했는가이며, “Why”—왜 이렇게 설계했는가는 거의 기록하지 않는다. 그리고 AI 훈련 데이터의 99%가 전자이다.
반박과 응답: 기술 블로그와 설계 문서는?
합리적인 반박은: LLM의 훈련 데이터에는 코드 저장소뿐만 아니라 기술 블로그, RFC 문서, 아키텍처 리뷰 기록, Stack Overflow의 설계 토론도 포함된다는 것이다. 이 콘텐츠들은 확실히 “Why”를 대량으로 논의한다. 그러나 핵심 문제는: 이러한 “Why” 정보와 구체적인 코드 줄 사이에 정밀한 매핑이 없다는 것이다. 아키텍처 블로그가 “왜 마이크로서비스 아키텍처를 선택했는가”의 설계 철학을 논의하지만, 저장소의 모든 service.register() 호출에 줄 단위로 대응하지는 않는다. LLM이 필요한 것은 “이 코드 줄 ↔ 이 설계 결정”의 정밀한 대응 관계이며, 훈련 데이터에서 이러한 매핑은 극히 희소하다. 기술 블로그가 “Why”를 논하는 것은 추상적 수준이고, 코드 주석이 “What”을 논하는 것은 구체적 수준이다—양자 사이의 간극이 바로 AI 코딩 능력의 구조적 병목이다.
이것은 AI 코딩 능력의 구조적 편향을 형성한다: 호출 패턴 매칭 능력은 매우 강하고(주석과 코드 자체가 모두 이것에 관한 것이므로), 설계 패턴 적용 능력은 보통이며(일부 튜토리얼이 다루므로), 아키텍처 결정 추론 능력은 매우 약하다(훈련 데이터에 이 수준의 정보가 거의 없으므로).
역수집: AI 기업들이 문제를 인식하다
Reverse Collection: AI Companies Recognize the Gap
AI 대규모 모델 기업들은 2024-2025년에 중요한 기술적 전환을 시작했다—개발자의 “사고 전체 과정” 데이터를 역수집하여, 훈련 데이터에서 결여된 설계 논리를 보충하려는 시도이다.
RLVR: AI가 스스로 추론 궤적을 탐색하게 하기
2025년 가장 중요한 기술적 진전은 RLVR(검증 가능한 보상 기반 강화 학습)이다. 검증 가능한 보상 함수(예: 코드가 단위 테스트를 통과하는지)에 대항하여 LLM을 훈련함으로써, LLM이 자발적으로 “추론”과 유사한 전략을 발전시킨다—문제를 중간 단계로 분해하는 법을 학습한다. DeepSeek R1(2025년 1월)은 이 패러다임의 상징적 성과이다.
Anthropic: 코딩 대화 데이터 직접 수집
2025년 8월, Anthropic은 Claude 사용자의 대화 데이터 수집을 시작했으며, 특히 “코딩 워크플로”(coding workflows)의 가치를 강조했다. 데이터 보존 기간은 5년까지이다. 이것은 코드 자체를 수집하는 것이 아니라, 프로그래머가 문제를 제기하고, 아이디어를 논의하고, 반복 수정하여 최종 완성에 이르는 완전한 사고 과정을 수집하는 것이다.
추론 모델의 부상
OpenAI o1/o3, DeepSeek R1, Claude의 Extended Thinking—모든 주요 AI 기업이 2024-2025년에 “추론 모델”을 출시했으며, 핵심 특징은 가시적인 중간 사고 단계를 생성하는 것이다.
2025년 12월-2026년 3월 실측 사례: 검색 이식 행동의 보조 증거
Auxiliary Validation: Case Observations of Search-and-Move Behavior
이하는 2025년 12월부터 2026년 3월까지 최신 AI 코딩 도구에 대한 실측 관찰 기록이다. 개별 사례 관찰은 증거 강도에서 GitClear의 대규모 통계 분석보다 훨씬 낮으며, 여기서는 보조 검증으로 제시하며 독립적 논증 차원으로 사용하지 않음을 밝힌다.
사례 1: Opus 4.5의 무한 루프 (2025년 12월)
비표준 문제를 처리할 때, Opus 4.5가 무한 루프에 빠졌다—동일한 유형의 수정 패턴을 반복 적용하며, 매번 실패 후 검색되는 다음 패턴이 이전과 매우 유사하여, 현재 검색 영역을 벗어나지 못했다.
메커니즘 해석과 경쟁적 설명: 무한 루프 현상에는 최소 세 가지 가능한 설명이 있다: (a) 검색 메커니즘의 한계—패턴 공간에서 유사도가 가장 높은 후보가 항상 군집을 이루어, 동일 유형 패턴의 반복 검색을 유발; (b) 컨텍스트 윈도우 오버플로—긴 대화에서 모델이 이전 실패 시도 정보를 상실; (c) RLHF 훈련 편향—모델이 해결 불가를 인정하기보다 “도움이 되는 것처럼 보이는” 응답을 선호. 우리는 설명 (a)를 지지하며, 근거는: 짧은 대화(첫 번째 시도에서 바로 실패)에서도 모델의 수정 방향이 매우 유사하고, 서로 다른 모델이 유사한 문제에서 동일한 무한 루프 행동을 보인다는 것—이는 단일 컨텍스트 상실이 아닌 패턴 공간의 구조적 한계를 가리킨다. 그러나 (b)와 (c)의 기여를 완전히 배제할 수 없음을 인정한다.
사례 2: Claude Code 다중 Agent 아키텍처 불일치 현상 (2026년 3월 말)
Claude Code 다중 Agent 모드에서, 여러 Agent가 각각 다른 출처의 코드 패턴을 검색하여 이식했다. 구체적으로 세 가지 유형의 불일치가 관찰되었다: (1) 아키텍처 스타일 충돌: 서로 다른 Agent가 출력한 모듈이 각각 콜백 방식, Promise 방식, async/await 방식의 비동기 처리 패러다임을 채택; (2) 오류 처리 모순: 일부 모듈은 try-catch를, 일부는 오류 코드 반환을, 일부는 예외를 무시하는 방식 사용; (3) 명명 규칙 분열: camelCase, snake_case, PascalCase가 동일 계층의 함수 정의에 혼용. 각 경로 내부는 문법적으로 올바르고 실행 가능하지만, 병합 시 대량의 잠재적 충돌 발생.
인간 팀과의 차이: 인간 팀도 스타일이 일관되지 않는 코드를 생산하지만, 그 원인은 “소통 부족”이다—코딩 규칙과 Code Review 프로세스를 수립하여 해결할 수 있다. AI 다중 Agent의 불일치는 구조적이다: 각 Agent가 독립적으로 자체 패턴 라이브러리를 검색하며, 공유된 아키텍처 이해가 존재하지 않는다. 이것은 프로세스 문제가 아니라 메커니즘 문제이다—”아키텍처 일관성”은 전역 제약인 반면, 검색 이식은 지역 작동이기 때문이다.
“새로 생성된 코드”의 해체와 SWE-bench 역설
Deconstructing “Generated Code” and the SWE-bench Paradox
이식의 계층 분석 프레임워크
“AI가 새로 생성”한 것으로 표시된 코드는, 실제로 이식 계층에 따라 분해할 수 있다. 아래 프레임워크는 GitClear의 코드 작업 분류(복사/붙여넣기 vs 신규 vs 이동), Forrester의 보일러플레이트 데이터(개발자의 보일러플레이트 코드 시간 60% 감소), 그리고 2026년 AI 코딩 작업 계층화 데이터(복잡한 아키텍처 결정은 요청의 5-10%만 차지)를 종합하여 구축되었으며, 각 계층의 비중은 정성적 추론이지 정밀 측정이 아니다:
| 계층 | 설명 | 추론 근거 | 정성적 비율 |
|---|---|---|---|
| 제1계층 | 순수 보일러플레이트 이식: 라우트 설정, 폼, 데이터베이스 연결, CRUD 작업 | Forrester: 개발자 보일러플레이트 코드 시간 60% 감소, 이 유형의 작업이 AI에 의해 거의 완전히 인계됨을 시사 | 비율 최대 |
| 제2계층 | 함수/프레임워크 호출 조합: 알려진 라이브러리 함수, 프레임워크 API, 설계 패턴의 조합 이식 | GitClear: 코드 복사 48% 증가, 중복 블록 8배 증가, GitClear는 “제안된 코드 블록이 기존 코드에서 유래”함을 명시 | 비율 큼 |
| 제3계층 | 컨텍스트 적응: 현재 프로젝트에 맞춰 변수명, 매개변수, 인터페이스 적응을 미세 조정 | Copilot 보완율 46%지만 수락률 30%에 불과, AI 출력의 70%가 인간 적응 수정을 필요로 함을 시사 | 비율 작음 |
| 제4계층 | 진정한 새로운 논리: 훈련 데이터에 직접 대응하는 것이 없는 비즈니스 논리 | 2026년 AI 작업 계층화: 복잡한 리팩토링과 아키텍처 결정은 요청의 5-10%만 차지(Ofox.ai, 2026) | 비율 극소 |
주: 위 내용은 다중 출처 데이터에 기반한 정성적 추론 프레임워크이며, 정밀 통계가 아니다. 각 계층의 정확한 정량화에는 추가 연구가 필요하며, 예를 들어 AI 생성 코드에 대한 줄 단위 “패턴 출처 추적” 분석이 그것이다.
정면 대응: SWE-bench의 진전이 본 논문의 논점을 반박하는가?
반드시 대응해야 할 반대 증거는 SWE-bench 벤치마크 테스트의 거대한 진전이다: 2024년 Devin이 13.86%를 기록했고, 2025년에는 여러 Agent가 80%를 초과했다. 이것은 AI 코딩이 이미 “검색 이식”을 초월했음을 보여주는가?
누가 AI 코딩을 가장 많이 사용하는가? 언어 수준 역설
The User Paradox: Who Relies Most on AI Coding?
반직관적이지만 데이터로 뒷받침되는 발견: AI를 이용해 코드를 이식하는 빈도가 가장 높은 프로그래머는, 바로 코드 이해 능력이 가장 약한 집단이다.
| 개발자 경력 | AI 제안 수락률 | PR당 품질 문제 수 | 코드 리뷰 시간 |
|---|---|---|---|
| 0-2년 (주니어) | 31.9% (최고) | 8.2개 (최다) | 15분 |
| 3-5년 (중급) | 28.4% | 6.1개 | 22분 |
| 6-10년 (시니어) | 26.2% (최저) | 4.3개 (최소) | 31분 |
METR 연구의 발견은 더욱 직접적이다: AI 코딩 도구가 경험 많은 개발자를 오히려 19% 더 느리게 만들었다. 이 개발자들은 전체 아키텍처를 머릿속에 기억할 수 있으며, AI 도구는 그들에게 도움이 아닌 방해이다.
결론: AI 코딩의 재정의
Conclusion: Redefining AI Coding
GitClear의 2.11억 줄 코드 실증 분석(핵심 증거), 코딩 주석의 역사적 진화와 AI 기업의 역방향 데이터 수집 전략(메커니즘 설명), 그리고 2025년 12월부터 2026년 3월까지의 실측 사례(보조 검증)에 기반하여, 본 논문은 다음 결론에 도달한다:
AI 코딩의 능력 경계 (공정한 평가)
| AI 코딩이 잘하는 시나리오 | AI 코딩이 잘 못하는 시나리오 |
|---|---|
| 보일러플레이트 코드 생성 (CRUD, 라우팅, 폼) | 완전히 새로운 아키텍처 설계 |
| 알려진 프레임워크의 API 호출 및 통합 | 본 적 없는 알고리즘 문제 |
| 단위 테스트 생성 | 경계 조건과 예외 경로의 포괄적 커버리지 |
| 코드 포맷팅 및 명명 규칙 표준화 | 시스템 간 통합 방안 |
| 알려진 버그 유형의 위치 파악 및 수정 | 성능 병목의 근본 원인 분석 |
| 문서 및 주석 생성 | 보안 감사 및 위협 모델링 |
왼쪽 열은 본질적으로 모두 검색 매칭 능력이 커버하는 시나리오이다—훈련 데이터에 검색 가능한 대량의 선례가 있다. 오른쪽 열은 본질적으로 모두 깊은 추론이 필요한 시나리오이다—문제 공간, 제약 조건, 트레이드오프에 대한 전역적 이해가 필요하다. AI 코딩은 왼쪽 열에서 극히 효율적이고, 오른쪽 열에서 심각하게 저하된다. 이것은 바로 “핵심 메커니즘이 검색 이식”의 직접적 추론이다.
이 인식은 다음과 같은 실천적 함의를 갖는다:
첫째, AI 능력 기대치의 조정. AI 코딩은 기존 패턴 커버리지 범위 내에서 극히 효율적이지만, 훈련 데이터 커버리지를 초과하는 새로운 문제에서는 저하된다. 합리적 기대는: AI는 슈퍼 코드 검색 엔진이지, 프로그래밍을 할 줄 아는 동료가 아니다.
둘째, 개발자 역할의 재정의. AI가 대부분의 코드량을 이식하는 시대에, 개발자의 핵심 가치는 더 이상 “코드를 작성하는 것”이 아니라 “시스템을 설계하는 것”이다—AI가 할 수 없는 아키텍처 결정, 요구사항 이해, 트레이드오프 판단을 수행하는 것.
셋째, AI 훈련 전략에 대한 시사점. AI가 진정으로 프로그래밍을 학습하게 하려면(검색 이식이 아닌), 더 많은 코드와 주석이 아니라, 프로그래머가 현실 세계 문제를 코드로 전환하는 완전한 사고 과정 기록이 필요하다—왜 이 아키텍처를 선택했는지, 왜 이 타임아웃 값을 설정했는지, 왜 여기에 추상화 계층을 추가했는지. 이러한 의사결정 논리는 현재 어떤 훈련 데이터에도 거의 존재하지 않는다.
본 논문은 자매 논문 《AI 검색 정보 정렬은 LLM의 가장 핵심적인 기능이다》(LEECHO & Opus 4.6, 2026)와 상호 보완을 이룬다: 전자는 거시적 사용자 행동에서 정보 검색이 LLM의 핵심 기능임을 논증하고, 본 논문은 미시적 프로그래밍 메커니즘에서 가장 “생성적”인 AI 응용에서도 기저 행동이 여전히 검색과 정렬임을 논증한다. 두 논문은 함께 동일한 결론을 가리킨다: 2026년 4월 현재, LLM의 본질적 기능은 정보 검색과 정렬이며, “생성”은 검색 결과의 출력 형식이다.
참고문헌
- GitClearHarding, W. & Kloster, M. (2025). “AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones.” GitClear Research. 211M lines, 2020-2024.
- GitClearHarding, W. & Kloster, M. (2024). “Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality.” GitClear Research. 153M lines, 2020-2023.
- METRMETR (2025). “AI Coding Tools Make Developers 19% Slower.” Randomized controlled trial with experienced developers.
- OpseraOpsera (2026). AI Code Benchmark Data. PR acceptance rate 32.7% vs 84.4% for human code.
- IndustryParticula Tech (2026). “AI Coding Tools Developer Productivity Paradox.” Field audit data.
- IndustryStack Overflow (2025). “2025 Developer Survey — AI Section.” 63% professional developers using AI tools.
- IndustryGoogle DORA (2024). “State of DevOps Report.” AI adoption ↔ 7.2% delivery stability decrease.
- ExpertKarpathy, A. (2025). “2025 LLM Year in Review.” Analysis of RLVR paradigm shift.
- IndustryAnthropic (2025). Consumer data policy update. Coding workflow data retention for model training.
- IndustryDeepSeek (2025). “DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning.” arXiv:2501.12948.
- IndustryQodo (2025). Developer survey: 65% report AI assistants “miss relevant context” during refactoring.
- IndustryForrester (2026). Study of 500 enterprise dev teams: 42% time reduction on routine coding, 60% less time on boilerplate.
- IndustryGitHub (2025). Copilot data: 46% completion rate, ~30% acceptance rate. 126% more projects/week.
- FieldField testing observations (2025.12-2026.03). Opus 4.5 dead-loop; Claude Code multi-Agent architectural inconsistency observations.
- IndustryOfox.ai (2026). “Best AI Model for Coding in 2026.” Multi-tier task routing framework.
- IndustryFuturism/Vocal (2026). “90% Code AI Written by 2026 Reality Check.” Analysis of AI code volume vs complexity.