AI가 AI 코드를 학습하면 어떻게 될까?

다음 세대 AI 코드가 더 나빠질 수 있는 이유

요즘에는 AI 코딩 에이전트한테 대충 설명하면 코드가 뚝딱 나오는 시대입니다. 바이브 코딩이라는 말까지 생겼죠. 그런데 한 가지 생각해 본 적 있으신가요? 이렇게 생성된 코드들이 쌓이고 쌓여서, 다음 세대 AI의 학습 데이터가 된다면 어떻게 될까요?

조금 먼 미래의 이야기를 해보겠습니다.

악몽 시나리오

2032년입니다. 스타트업에서 결제 시스템을 새로 구축해야 합니다. npm을 둘러보니 결제 라이브러리가 47개나 있고, 다들 문서도 잘 되어 있고 별도 많습니다. 가장 인기 있는 걸 골랐습니다.

3주 후, 이상한 버그가 터집니다. 특정 조건에서 결제가 두 번 처리되는 거예요. 코드를 뜯어봤습니다. 그런데... 뭔가 이상합니다. 같은 검증 로직이 세 군데에 흩어져 있고, 서로 미묘하게 다릅니다. 어떤 건 타임아웃이 3초, 어떤 건 5초, 어떤 건 아예 없습니다. 왜 이렇게 만들었는지 주석도 없고, 커밋 히스토리를 봐도 "generated by AgentDev-2031"만 반복됩니다. 도대체 누가 만든 거지? GitHub 프로필을 확인해 봤습니다. "AgentDev-2031, 자율 프레임워크 생성기."

다른 라이브러리를 써봤습니다. 비슷한 문제, 다른 버그. 또 다른 라이브러리. 또 비슷한 문제.

그제야 깨달았습니다. 이 프레임워크들 전부 AI 에이전트가 만든 거였습니다. 그것도 다른 AI 에이전트가 만든 코드를 학습해서요. 그 에이전트들은 또 다른 AI가 만든 코드를 학습했고... 끝이 어딘지 알 수 없습니다. 코드는 돌아가긴 합니다. 그런데 왜 이렇게 동작하는지 아는 사람이 아무도 없습니다. 고장 나면? 고칠 방법이 없습니다.

이게 소프트웨어에 적용된 모델 붕괴입니다. 허무맹랑한 이야기 같지만, 지금 우리가 가고 있는 방향이기도 합니다.

모델 붕괴란

2023년 5월, 옥스포드, 케임브리지, 토론토 연구진이 흥미로운 논문을 발표했습니다. The Curse of Recursion: Training on Generated Data Makes Models Forget

핵심 발견은 이렇습니다. AI 모델이 AI가 생성한 데이터로 학습하면, 세대가 거듭될수록 품질이 되돌릴 수 없이 나빠집니다.

연구진은 이 현상을 "모델 붕괴(model collapse)"라고 이름 붙였습니다.

어떻게 이런 일이 일어나는가

모델 붕괴가 어떻게 일어날 수 있는지 예상 시나리오를 생각해 보겠습니다.

1세대: 실제 사람이 만든 데이터로 AI를 학습시킵니다. 대부분의 패턴을 잘 배우지만, 드물게 나타나는 패턴은 조금씩 왜곡됩니다. 95% 정확도라고 해봅시다.

2세대: 1세대가 만든 출력으로 새 AI를 학습시킵니다. 95% 맞는 것도 배우고, 5% 틀린 것도 배웁니다. 둘 다 "정답"으로 취급하니까요. 여기에 자체 오류까지 더해집니다. 정확도는 90% 정도로 떨어집니다.

9세대: 이런 식으로 8번 더 반복하면? 출력이 엉망이 됩니다.

연구진은 Meta의 OPT-125M 모델로 직접 실험했습니다. 처음에는 제대로 된 위키피디아 글을 생성하던 모델이, 9세대를 거치고 나니 횡설수설하는 글을 내놓더라고요.

왜 그런가

AI는 데이터를 생성할 때 흔한 패턴 위주로 만들어냅니다. 그러다 보니 드물지만 중요한 케이스들은 점점 빠지게 됩니다.

예를 들어볼까요. 고양이 사진 100장이 있습니다. 노란 고양이 90장, 파란 고양이 10장.

- 1세대 AI: 대부분 노란 고양이를 생성합니다. 파란 고양이도 만들긴 하는데, 색이 좀 녹색 쪽으로 섞입니다.

- 2세대 AI: 1세대 출력으로 학습하니까 파란 고양이가 거의 사라집니다. 녹색이 더 많아지고요.

- 3세대: 파란 고양이 완전히 사라짐. 노란색 위주에 녹색 조금.

- 5세대: 노란 고양이만 남습니다.

파란 고양이라는 정보가 세대를 거치면서 완전히 사라진 겁니다.

코드로 치면 어떨까요? 드물지만 중요한 것들, 특이한 엣지 케이스 처리, 성능 최적화 트릭, 보안 관련 고려사항. 이런 것들이 먼저 사라집니다.

연구진의 결론은 명확했습니다. AI가 만든 데이터로 학습하면 되돌릴 수 없는 손상이 생긴다고요. 특히 원래 데이터에서 드물게 나타나던 패턴들이 사라진다고요.

이건 고칠 수 있는 버그가 아닙니다. 재귀적 학습이 가진 수학적 특성입니다. 원래 연구는 텍스트 생성에 초점을 맞췄지만, 같은 원리가 코드 생성에도 적용됩니다.

다만 한 가지 알아둘 점이 있습니다. 모델 붕괴는 사람의 검증 없이 AI 출력으로만 계속 학습할 때 일어납니다. 중간에 사람이 개입해서 검증하면 이 체인이 끊어집니다.

지금 보이는 경고 신호

모델 붕괴가 일어나려면 AI가 AI 출력으로 여러 세대에 걸쳐 학습해야 합니다. 코드 쪽에서 그게 실제로 일어나고 있다는 직접적인 증거는 아직 없습니다.

그렇지만 다른 종류의 증거는 있습니다. 바로 AI로 작성된 코드베이스에서 품질이 떨어지고 있다는 것이죠.

데이터를 한번 볼까요.

GitClear 2025년 연구: 2억 줄 분석

GitClear가 2020년부터 2024년까지 주요 기업들의 코드 2억 1,100만 줄을 분석했습니다. 결과가 좀 걱정됩니다. 중복은 늘고, 리팩토링은 줄고 있습니다.

막대: 코드 중복 (상승). 선: 리팩토링 (하락)

구체적인 수치를 보면 (2021년 → 2024년):

코드 중복률: 8.3% → 12.3% (+48%)

긴 중복 블록 (5줄 이상): 8배 증가

리팩토링 비율: 25% → 10% 미만 (-61%)

단기 수정 (2주 내 재작성): 3.1% → 5.7% (+84%)

기록상 처음으로, 복사/붙여넣기가 코드 재사용을 넘어섰습니다.

이게 의미하는 것

코드 중복 폭발: AI는 각 요청을 따로따로 처리합니다. 이미 날짜 포맷팅 함수가 있는지 모르고 또 하나 만들어버립니다. 또 만들고, 또 만들고. GitClear에 따르면 긴 중복 블록이 2년 전보다 8배 많아졌습니다.

리팩토링 실종: 원래 개발자들은 비슷한 코드가 보이면 공통 모듈로 묶습니다. 그런데 AI 시대에 이런 리팩토링이 61%나 줄었습니다. 추상화 대신 복붙이 대세가 된 거죠.

수정이 잦아짐: 작성 후 2주 안에 다시 고쳐야 하는 코드가 84% 늘었습니다. AI가 만든 코드 품질이 그만큼 낮다는 뜻입니다.

GitClear CEO는 AI 생성 코드를 "여기저기 돌아다니면서 DRY 원칙을 어기고 다니는 임시 기여자" 같다고 표현했습니다.

Google DORA 2025도 같은 패턴

Google DORA 2025 보고서가 39,000명 이상을 조사했는데, 비슷한 결과가 나왔습니다.

- AI 채택률이 25% 올라갈 때마다 → 배포 안정성 7.2% 하락

- AI 채택률 90%인 팀에서 → 버그율 9% 상승

- 코드 리뷰 시간 91% 증가

- PR 크기 154% 증가

숨은 비용 루프: 코드가 많이 생성될수록 리뷰 부담이 커지고, 안정성이 떨어집니다.

생산성이 올라간 건 맞습니다. 그런데 숨은 비용이 따라옵니다. AI 코드 디버깅에 작성 시간보다 더 오래 걸린다면, 혼자만 그런 게 아닙니다. 66%가 같은 경험을 합니다.

개발자들은 어떻게 느끼나

Harness의 2025 보고서에 따르면 대다수 개발자가 AI 생성 코드를 디버깅하는 데 작성에서 절약한 시간보다 더 많이 씁니다.

Stack Overflow 2025 개발자 설문을 보면:

- AI 정확도를 신뢰한다는 응답이 40%에서 29%로 하락

- 66%가 "거의 맞는데 완전히는 아닌" AI 코드 수정에 시간을 더 씀

- 45%가 최대 불만으로 "거의 맞지만 완전히는 아닌 AI 솔루션"을 선택

"더 빨리 코딩"이 목표였는데, 현실은 "더 오래 디버깅"인 경우가 많습니다.

한 가지 중요한 점: 이 데이터는 바이브 코딩, 즉 자동완성 수락하고 ChatGPT에서 복붙하는 식의 비구조화된 AI 코딩을 측정한 겁니다. 명세를 꼼꼼히 쓰고 체계적으로 리뷰하는 개발자는 따로 구분하지 않았습니다. 그러니까 이 저하가 AI 코딩의 필연은 아닐 수 있습니다. 방법의 문제일 수도 있습니다.

물론 바이브 코딩으로도 잘 되는 사람들이 있긴 합니다. 뭐가 다른 건지는 아직 모릅니다. 프로젝트 종류인지, 개인 역량인지, 코드베이스 크기인지. 이건 집계 데이터이지 절대적 법칙은 아닙니다. 66%가 디버깅에 더 많은 시간을 쓴다고 해서 전부 그런 건 아니니까요.

확실한 건 이겁니다. 집계 데이터를 보면 코드 품질 지표가 하락하고 있습니다. 구조화된 방법론은 바이브 코딩이 "무조건 안 된다"라고 말하는 게 아닙니다. 장기적으로 유지보수해야 하는 코드에서 성공 확률을 높이려는 대응입니다.

데이터가 보여주는 것과 안 보여주는 것

정리하면 이렇습니다. 데이터는 바이브 코딩에서 품질이 떨어지고 있다는 걸 보여줍니다. 중복 늘고, 리팩토링 줄고, 디버깅 부담 커지고.

이건 아직 모델 붕괴가 아닙니다. 모델 붕괴는 AI가 AI 출력으로 여러 세대 걸쳐 학습해야 합니다.

그런데 걱정이 되는 건 이겁니다. 지금 만들어지는 저품질 코드가 GitHub, npm, Stack Overflow를 통해 미래 AI의 학습 데이터에 들어가면 어떻게 될까요?

복합 위험: 오늘의 문제가 내일의 모델을 오염시킬 때

앞에서 모델 붕괴의 원리를 살펴봤고, 현재 코드 품질이 떨어지고 있다는 데이터도 봤습니다. 이 두 가지가 만나면 어떻게 되는지, 대략적인 그림은 예상이 가실 겁니다. 여기서 현재 추세가 그대로 간다면 어떤 전개가 이루어질지 좀 더 구체적으로 살펴보겠습니다.

지금 (2024-2025):

- AI 에이전트가 사람이 만든 프레임워크 사용 (React, Django, PostgreSQL)

- 품질 기준: 높음 (수십 년간 사람들이 다듬어옴)

- 이해도: 깊음 (문서 잘 되어 있고, 실전에서 검증됨)

과도기 (2026-2028):

- 에이전트가 유틸리티 라이브러리나 프레임워크를 만들기 시작

- 기반: 사람이 만든 프레임워크 + 초기 에이전트 코드

- 품질: 조금 떨어짐 (중복 늘고, 리팩토링 줄고)

- 이해도: 부분적 (문서는 있는데, 왜 이렇게 했는지 모르는 부분 생김)

위험 구간 (2028-2032):

- 에이전트가 주로 2세대 에이전트 코드를 기반으로 프레임워크 구축

- 품질: 심각하게 저하

- 이해도: 거의 없음, 원래 설계 의도 상실

- 문서: 불완전 (AI가 쓴 문서는 "왜"를 설명 못 함)

왜 이게 문제인가

1. 맥락이 사라집니다

보통 시스템 지식은 문서와 사람 머릿속에 나눠서 있습니다. 문서에 다 적혀 있으면 좋겠지만, 현실에서는 "왜 이렇게 했는지"는 담당자한테 물어봐야 알 수 있는 경우가 많죠. 그래서 핵심 인력이 퇴사하면 지식 공백이 생깁니다.

그런데 에이전트가 만든 프레임워크는요? 처음부터 그 "왜"를 아는 사람이 없습니다. "이 프레임워크가 왜 인증을 이렇게 처리하지?"라는 질문에 대답할 사람이 없는 거죠.

거기에 중복 코드 문제까지 더해집니다. GitClear 연구에 따르면 중복 코드의 결함률이 15-50% 더 높습니다. 프레임워크 B가 A의 버그 패턴을 복사하고, C가 B에서 복사하면, 버그가 생태계 전체로 퍼집니다.

2. 유지보수가 발굴 작업이 됩니다

이런 코드베이스를 물려받은 개발자는 난감합니다. 코드는 돌아가는데, 왜 이렇게 동작하는지 파악이 안 됩니다. 한 줄 고치려면 전체 흐름을 역으로 추적해야 하고, 그러다 보면 간단한 수정에도 시간이 엄청 걸립니다.

더 심각한 건, 일반적인 레거시 코드는 그래도 처음에 누군가 이해하고 만들었다는 점입니다. 의도가 있었고, 그 흔적이 남아 있습니다. 에이전트가 재귀적으로 만든 코드는 처음부터 그런 의도 자체가 없었을 수 있습니다.

3. 비용이 폭발합니다

레거시 시스템 유지보수에 얼마나 많은 비용이 드는지는 업계에서 잘 알려져 있습니다. 작동 원리를 제대로 아는 사람이 없으면 모든 변경이 느리고 위험합니다.

그런데 생각해 보세요. 겨우 3년 된 시스템인데 아무도 이해 못 한다면요? 에이전트가 에이전트 위에 만든 인프라가 바로 그렇게 됩니다.

JavaScript 생태계에 패키지가 200만 개 넘게 있습니다. 이미 방치되거나 버그 있는 것도 많습니다. 여기에 AI가 만든 패키지가 대량으로 추가되면 어떻게 될까요? "사람이 유지보수한다"는 최소한의 품질 보장마저 사라집니다.

그래도 탈출구는 있습니다.

이 시나리오는 매 단계에서 사람 감독이 없다고 가정합니다. 사람이 각 세대 아키텍처를 검증하면, 프레임워크 B가 A 위에 만들어지기 전에 설계를 리뷰하면, 품질 저하를 막을 수 있습니다. 문제는 우리가 이 검증 체계를 어떻게 지속 가능하게 만들 것인가입니다.

인터넷은 이미 오염되기 시작했습니다

사실 코드는 빙산의 일각입니다. 온라인을 둘러보면 블로그 포스팅, Stack Overflow 답변, GitHub 이슈 댓글까지. AI가 작성하거나 도움받은 콘텐츠가 아닌 것을 찾기가 점점 어려워지고 있습니다. 이걸 생각해 보면 사실 학습 데이터 오염은 이미 진행 중이라고 볼 수 있습니다.

악순환

지금 상황에서 특별한 개선이 없이 극단적으로 상황이 돌아간다면 어떤 일이 일어나게 될지 생각을 해보겠습니다. AI가 블로그 글을 씁니다. 그럴듯해 보이니까 사람들이 공유합니다. 검색 엔진이 상위에 노출시킵니다. 다음 세대 AI가 웹을 크롤링할 때 이 글을 학습 데이터로 수집합니다. 그 AI가 또 글을 씁니다.

이 과정이 반복될수록 AI 특유의 패턴이 강화됩니다. 비슷비슷한 문장 구조, 불필요한 이모지, "물론입니다"로 시작하는 답변들. 다양성은 줄어들고, AI가 작성한 듯한 문장만 남게 됩니다.

연구진이 경고했습니다. 오류가 섞인 AI 생성 데이터를 대규모로 만들 수 있게 되면, 그 데이터가 결국 온라인 전체로 퍼지게 될 거라고요.

깨끗한 데이터의 희소성

AI 등장 이전에 만들어진 콘텐츠가 점점 더 귀해지고 있습니다. 2023년 이전에 고품질 데이터를 확보해 둔 기업들이 유리한 위치에 있습니다. 반면 2023년 이후 웹에서 수집한 데이터로 학습하는 기업들은 이미 AI 생성물이 섞여 있을 가능성을 고려해야 합니다.

원래의 "깨끗한" 사람이 만든 데이터는 대체 불가입니다. 그런데 지금 우리는 매일 그 데이터가 희석되는 모습을 지켜보고 있습니다.

다행히 이 문제에 대한 인식이 높아지고 있긴 합니다. AI 연구소들이 학습 데이터에서 AI 생성물을 걸러내려는 노력을 시작했습니다.

붕괴에 맞서는 힘들

위에서 다룬 시나리오는 우리가 그냥 가만히 있는다고 가정합니다. 그런데 반대로 작용하는 힘들이 있습니다.

1. 시장이 이미 반응하고 있습니다

언젠가는 디버깅 비용이 속도 향상을 넘어서게 됩니다. 그리고 그 "언젠가"가 이미 오고 있는 것 같습니다. AI 코드 리뷰와 정리를 전문으로 하는 서비스들이 생겨나고 있거든요. Graphite는 2024년에 매출이 20배 성장했고, 최근 Cursor에 인수되었습니다. CodeRabbit, [Qodo]() 같은 스타트업들도 "AI가 만든 코드를 제대로 리뷰해 드립니다"를 셀링 포인트로 삼고 있습니다.

2. 코드 리뷰가 방화벽 역할을 합니다

코드 리뷰가 에이전트 실수를 잡습니다. 자동화된 품질 검사 도구, 린터, 보안 스캐너도 도움이 됩니다. 다음 글에서 살펴볼 구조화된 방법론이 체계적인 체크포인트를 만들고요. 사람이 검증하는 곳마다 품질 저하의 고리가 끊어집니다.

3. 검증된 프레임워크가 기반이 됩니다

React, PostgreSQL, Django 같은 프레임워크는 수년간 커뮤니티가 다듬어왔습니다. 버그도 많이 잡히고, 문서도 잘 되어 있고, 왜 이렇게 설계했는지 아는 사람들이 있습니다. 이런 "깨끗한 기반" 위에서 작업하는 한, 완전히 표류할 일은 없습니다. 앞으로도 이렇게 많은 사람들에 의해 검증되는 한, 이러한 프레임워크는 계속해서 품질을 유지할 가능성이 높습니다.

4. 새로운 방법론들이 등장하고 있습니다

AI 코딩의 품질 문제를 인식하고, 이를 해결하기 위한 구조화된 접근법들이 나오고 있습니다. GitHub의 SpecKit, BMAD Method, 컨텍스트 엔지니어링 같은 것들이요. 아직 초기 단계이지만, 효과가 있다는 사례들이 나오고 있습니다.

생각보다 많은 부분에서 붕괴 시나리오가 일어나지 않도록 하는 조짐이 보이고 있습니다. 어떤 방법론을 선택하느냐에 따라 결과가 달라질 수 있습니다.

갈림길

우리는 지금 선택의 지점에 놓여 있다고 생각합니다. 다음과 같은 두 가지 경로가 있다면, 어떤 걸 선택해야 할까요?

경로 A: 품질 붕괴

- 검증 없는 바이브 코딩이 계속됨

- 프레임워크가 프레임워크 위에 재귀적으로 쌓임

- 2030년쯤: 겨우 몇 년 된 시스템에서 유지보수 위기

- 어디서부터 손대야 할지 모르는 기술 부채와 의도 부채

경로 B: 구조화된 지속가능성

- 아키텍처 결정에 사람이 감독

- 체계적인 문서화 요구

- 에이전트 생성 코드에 품질 게이트

- 장기적으로 유지보수 가능한 코드베이스

차이는 기술이 아닙니다. 방법론입니다.

우리가 이런 위기를 겪는 건 처음이 아니었고, 앞으로도 계속될 겁니다. 디버깅에서 원인을 파악했으면 절반 이상은 한 거라고 하잖아요. 문제를 인식했으니, 이제 절반은 해결한 셈입니다.

해결책의 핵심은 간단합니다. AI가 만든 코드를 그대로 머지하지 말고, 왜 이렇게 동작하는지 이해한 후에 넘기는 것. 이 한 단계가 품질 저하의 고리를 끊습니다.

물론 핵심이 간단하다고 해서 실천이 쉬운 건 아닙니다. 다음 글에서는 어떻게 해야 AI 코딩에서 더 지속 가능한 개발을 할 수 있는지, 구체적인 방법을 살펴보겠습니다.

요약

- 모델 붕괴: AI가 AI 출력으로 학습하면 세대를 거치며 품질이 저하됨. 드물지만 중요한 패턴들이 먼저 사라짐

- 현재 위기: 바이브 코딩이 늘면서 "일단 돌아가는 코드"는 빨리 만들어지지만, 유지보수 부담이 커지고 있음. 복붙이 늘고 리팩토링이 줄면서, 고치기 어려운 코드가 쌓이는 중

- 핵심: 사람이 검증하는 지점마다 품질 저하의 고리가 끊어짐. 방법론의 차이가 결과의 차이를 만듦