작년에 저는 이틀이 걸려야 할 기능을 단 4시간 만에 배포했습니다. Copilot이 대부분을 작성했기 때문입니다. 3주 전까지 저는 제가 천재인 줄 알았습니다. 하지만 존재하지 않았던 null check(널 체크) 문제로 인해 해당 기능이 우리의 스테이징(staging) 환경을 다운시켰을 때 깨달았습니다. 그것은 전통적인 의미의 버그가 아니었습니다. 제가 요청한 대로 정확히 수행했지만, 실제로 필요했던 것은 아니었던 AI 생성 코드의 문제였습니다.

"작동한다"와 "올바르다" 사이의 이 간극이 바로 기술 부채(Technical Debt)가 발생하는 지점이며, AI 생성 코드는 이를 축적하는 가장 빠른 방법 중 하나가 되었습니다. 이것은 AI 반대론을 펼치려는 것이 아닙니다. 저 또한 매일 AI 코딩 도구를 사용합니다. 하지만 팀들이 이를 도입하는 과정을 지켜보고, 몇몇 팀의 뒷수습을 하며 2년 동안 관찰한 결과, 대부분의 "AI가 개발자를 대체할 것이다"라는 기사들이 편리하게 생략하는 패턴들을 발견했습니다. 또한 데이터 역시 우리 중 많은 이들이 직감적으로 느껴왔던 것들을 뒷받침하고 있다는 사실이 밝혀졌습니다.

이제 수치가 나왔으며, 이는 결코 미묘하지 않습니다.
한동안 이 주제는 분위기나 일화 수준에 머물러 있었습니다. 하지만 이제 바뀌었습니다. 지난 1년 동안 발표된 여러 독립적인 연구들은 AI 생성 코드가 확장됨에 따라 코드베이스(codebase)에 정확히 어떤 일이 일어나고 있는지를 수치화했으며, 모든 연구에서 놀라울 정도로 일관된 결과가 나타났습니다.

GitClear는 2020년부터 2024년까지 비공개 저장소(private repositories)와 대규모 오픈 소스 프로젝트에 걸쳐 변경된 2억 1,100만 줄의 코드를 분석했습니다. 연구 결과에 따르면, 복사하여 붙여넣은(copy-pasted) 코드의 비율이 전체 변경된 코드 줄의 약 8%에서 12% 이상으로 증가했습니다. 또한 이 데이터셋의 역사상 처음으로, 복사하여 붙여넣은 코드가 "이동(moved)", 즉 재사용 가능한 형태로 리팩터링(refactored)된 코드보다 많아졌습니다. 한편, 리팩터링(refactoring) 활동은 2021년 전체 변경 사항의 약 4분의 1 수준에서 2024년에는 10% 미만으로 감소했습니다. 다시 말해, 코드의 양이 폭발적으로 증가하는 바로 이 시점에 코드 재사용성은 사라지고 있습니다.

보안 기업인 Ox Security는 이를 다른 각도에서 살펴보았습니다. 이들은 300개의 오픈 소스 (open-source) 프로젝트를 분석했는데, 그중 절반은 전체 또는 부분적으로 AI가 생성한 것이었으며, 이를 통해 반복되는 안티 패턴 (anti-patterns)을 식별했습니다. 주석 과다 (Comment overload), 교과서적 패턴에 대한 집착 (textbook-pattern fixation), 리팩터링 (refactoring) 회피, 그리고 과도하게 설계된 예외 케이스 처리 (over-engineered edge-case handling)는 각각 AI 생성 코드 샘플의 80%에서 100% 사이에서 나타났습니다. 이들이 정의한 방식이 제 기억에 남았습니다. AI 생성 코드는 마치 재능 있는 주니어 개발자 군단이 작업한 결과물처럼 읽힙니다. 기술적으로는 기능적이지만, 구조적으로는 감독되지 않은 상태 말입니다.

SonarQube의 2026 State of Code 설문조사는 이러한 신뢰의 격차를 수치로 직접 보여주었습니다. 개발자의 53%는 AI가 올바르게 보이지만 결함(defects)을 숨기고 있는 코드를 생성한다고 답했으며, 40%는 AI가 생성한 중복(duplication)이 기술 부채 (technical debt)를 측정 가능한 수준으로 증가시켰다고 답했습니다. 동일한 설문조사에서 개발자의 88%가 AI 도구로부터 최소 하나 이상의 부정적인 기술 부채 영향을 보고했으며, 동시에 93%는 주로 문서화 (documentation) 및 레거시 코드 (legacy-code) 탐색과 관련하여 최소 하나 이상의 긍정적인 영향을 보고했습니다. AI가 나쁘다는 뜻이 아닙니다. AI는 양날의 검과 같아서, 양방향 모두에서 강력하게 작용한다는 뜻입니다.

기술 부채 (Technical Debt)의 실제 의미 (교과서적인 버전이 아닌)
Ward Cunningham은 1992년에 빠른 출시와 깨끗한 코드 작성 사이의 절충안 (tradeoff)을 설명하기 위해 기술 부채라는 용어를 만들었습니다. 이 비유는 유효합니다. 지금 시간을 빌려 쓰고, 나중에 이자를 붙여 갚는 것입니다.

사람들이 놓치는 부분은 바로 여기입니다. 부채는 단순히 나쁜 코드를 의미하는 것이 아닙니다. 부채란 아무도 기록하지 않은 가정 하에 작성되어, 이제는 더 이상 완전히 이해할 수 없게 된 코드, 그리고 다른 것을 망가뜨리지 않으면서 반드시 수정해야만 하는 코드를 의미합니다.

AI 생성 코드는 미주리 과학기술대학교(Missouri University of Science and Technology)의 2026년 학술 연구에서 명명한 특정한 방식으로 이를 가속화합니다: 바로 '생성형 AI 유발 자가 인정 기술 부채 (GenAI-Induced Self-Admitted Technical Debt)', 즉 GIST입니다. 연구진은 AI 도구를 참조한 GitHub 저장소(repos) 전반의 수천 개의 코드 주석을 조사한 다음, 이를 TODO 및 FIXME와 같은 고전적인 부채 지표와 교차 참조했습니다. 그들이 발견한 패턴은 다음과 같습니다: 개발자들은 설계 결함(design flaws)이 아니라, 불완전한 구현(incomplete implementation)과 테스트 지연(deferred testing)을 이유로 AI 코드를 가장 자주 지적했습니다. 즉, 코드는 구조적으로는 괜찮아 보일 때가 많지만, 지름길(shortcuts)은 아키텍처가 아닌 검증(verification) 단계에 있다는 것입니다.

문제를 명확히 정의하자면

직접 코드를 작성할 때는, 설령 나쁜 코드일지라도 각 결정을 내린 이유에 대한 정신적 모델(mental model)을 갖게 됩니다. 하지만 AI가 코드를 작성할 때는, 당신의 머릿속에도, 그리고 모델 자체에도 그러한 정신적 모델이 존재하지 않습니다.

결과적으로 다음과 같은 코드를 얻게 됩니다:

• 해피 패스(happy path)는 통과하지만 엣지 케이스(edge cases)는 무시함
• 학습 데이터에서 가져온 오래된 패턴을 사용함
• 기존 유틸리티를 재사용하는 대신 로직을 중복함
• 깔끔해 보이지만 미묘한 논리적 오류를 숨기고 있음
• 실제 비즈니스 문제가 아닌, 문자 그대로의 프롬프트(prompt)만을 해결함

이러한 문제들은 빠른 검토 과정에서는 드러나지 않습니다. 대신 세 번의 스프린트가 지난 후, 새벽 2시의 운영(production) 환경에서 나타납니다. 한 개발자가 Dev.to에 매우 정확하게 묘사하여 그대로 인용할 가치가 있는 시나리오가 있습니다: 기술적으로는 본인 소유이지만 직접 작성하지는 않은 코드를 디버깅하며, 애초에 추론(reasoning) 능력이 없었던 모델의 추론 과정을 역공학(reverse-engineer)하려고 시도하는 상황 말입니다.

실제 개발자 시나리오

시나리오 1: 아무도 잡아내지 못한 인증(Auth) 버그
제가 컨설팅했던 한 스타트업은 비밀번호 재설정 흐름을 구축(scaffold)하기 위해 ChatGPT를 사용했습니다. 테스트 단계에서는 잘 작동했습니다. 하지만 사용 후 이전 재설정 토큰을 무효화하지 않는 문제가 조용히 숨어 있었고, 이는 오래된 재설정 링크가 무기한 유효하게 남는 결과를 초래했습니다. 코드 리뷰에서 아무도 이를 잡아내지 못했는데, 코드가 올바르게 보였기 때문입니다. 기본적으로 튜토리얼에서 본 것과 같은 형태였기에 마치 튜토리얼의 일부처럼 읽혔습니다.

시나리오 2: 중복된 유틸리티의 확산
한 중소 규모의 SaaS 팀은 여러 엔지니어가 6개월 동안 독립적으로 Copilot을 사용하도록 방치했습니다. 마침내 코드베이스를 감사(audit)했을 때, 그들은 미묘하게 서로 다른 7개의 날짜 형식 지정(date-formatting) 함수를 발견했습니다. AI가 다른 6개가 존재한다는 사실을 몰랐기 때문에, 각 함수는 별도의 PR(Pull Request)을 통해 생성되었습니다. 이것이 바로 GitClear의 데이터가 산업 규모로 포착해내는 패턴입니다. 자신의 6개월간의 일일 Claude Code 사용 경험을 기록한 한 개발자는 이를 구체적인 수치로 제시했습니다: 15개의 엔티티(entity)로 구성된 프로젝트에서 47개의 AI 생성 인터페이스가 발견되었으나, 다형성(polymorphism)이 실제로 필요한 경우는 단 3건뿐이었습니다.

시나리오 3: 해결되지 않은 "수정된" 버그
한 엔지니어가 AI 도구에 큐 프로세서(queue processor)의 레이스 컨디션(race condition)을 수정해달라고 요청했습니다. AI는 setTimeout 지연(delay)을 추가했습니다. 테스트에서는 버그가 사라졌습니다. 하지만 부하가 걸린 운영 환경에서는 버그가 다시 나타났습니다. 타임아웃은 해결책이 아니라 타이밍이 유지될 것이라는 도박일 뿐이며, 운영 트래픽은 그런 도박을 존중하지 않기 때문입니다. 이는 일부 개발자들이 "침묵하는 성능 저하(silent degradation)"라고 부르는 패턴과 매우 유사합니다. 즉, 실제 문제를 드러내기보다 오류를 삼켜버리고 빈 값을 반환해버리는 모델들의 특성입니다.

이것들은 예외적인 사례(edge cases)가 아닙니다. 누군가가 그 코드가 왜 그렇게 작성되었는지에 대한 "이유(why)"를 책임지지 않은 채 AI 출력물을 병합할 때 발생하는 기본 결과입니다.

이 문제가 존재하는 이유

1. AI 모델은 정확성(Correctness)이 아닌 그럴듯함(Plausibility)을 최적화합니다. 대규모 언어 모델(Large Language Models, LLM)은 학습 데이터의 패턴을 기반으로 다음에 올 가능성이 가장 높은 토큰을 예측합니다. 이는 상용구(boilerplate) 코드에는 진정으로 유용합니다. 하지만 시스템의 특정 제약 조건에 대한 실제적인 추론이 필요한 작업에서는 매우 위험한데, 모델은 당신의 시스템을 본 적이 없기 때문입니다. 수개월 동안 매일 Claude Code를 사용한 한 숙련된 Symfony 및 Go 개발자는 다음과 같이 말했습니다. 모델은 의도적으로 나쁜 코드를 쓰는 것이 아니라, 학습 데이터에서 본 것과 통계적으로 유사한 코드를 작성할 뿐이며, "그럴듯함"은 "정확함"과 같은 것이 아니라는 점입니다.

2. 컨텍스트 윈도우(Context Windows)가 코드베이스에 대한 이해를 의미하지는 않습니다. 거대한 컨텍스트 윈도우를 가지고 있더라도, 대부분의 AI 코딩 도구는 저장소(repo)의 일부 조각만을 볼 뿐, 그 이면에 담긴 암묵적 지식(tribal knowledge), 2023년의 장애 상황, 아무도 문서화하지 않은 벤더의 제한 사항, 혹은 특정 함수가 의도적으로 이상하게 보이는 이유 등을 알지 못합니다. LeadDev의 GitClear 연구 보도에 따르면, GitClear의 CEO는 팀들이 개발자의 산출물을 커밋 횟수나 추가된 코드 라인 수로 계속 측정한다면, AI로 인한 유지보수성 저하(maintainability decay)가 계속 확산될 것이라고 경고했습니다.

3. 개발자들은 깔끔해 보이는 출력물을 신뢰합니다. 깔끔한 포맷팅은 올바른 것처럼 읽힙니다. 일관된 명명 규칙(naming)은 의도적인 것처럼 읽힙니다. 하지만 이 중 어느 것도 실제로 로직을 검증하지는 않습니다. 리뷰어들이 사람이 작성한 풀 리퀘스트(Pull Requests, PR)보다 AI가 생성한 PR을 검토할 때 눈에 띄게 적은 시간을 소비한다는 사실이 입증되었는데, 이는 포맷팅이 마치 유능한 사람이 작성한 것처럼 보이기 때문입니다. 한 엔지니어는 이러한 역학 관계를 "예쁜 카펫이 깔려 있는 함정 문(trap door)"이라고 요약했습니다.

4. 리뷰 피로(Review Fatigue)가 빠르게 찾아옵니다. PR의 대부분이 AI에 의해 생성되었고 겉보기에 문제가 없어 보이면, 리뷰어는 추론하는 대신 훑어보기 시작합니다. Google의 2024년 DORA 연구는 여기서 실제적인 트레이드오프(tradeoff)를 발견했습니다. AI 사용량이 25% 증가하면 코드 리뷰 속도가 빨라지고 문서화가 개선되었지만, 소프트웨어 인도 안정성(software delivery stability)은 약 7% 하락했습니다.

속도와 안정성은 서로 반대 방향으로 움직였습니다.

5. 아무도 의사결정을 "소유"하지 않습니다. 사람이 작성한 코드에는 트레이드오프(tradeoff)를 결정하고 나중에 이를 설명할 수 있는 사람이 존재합니다. 하지만 AI가 생성한 코드에서는 소유권이 모호해집니다. 왜 이 접근 방식이 선택되었는지 누구에게 물어보겠습니까? 아무도 없습니다. 그것이 바로 부채입니다. 일부 엔지니어들은 이러한 소유권 부채(ownership debt)를, 무언가 고장 났을 때 개발자의 본능이 "이걸 디버깅(debug)해 보자"에서 "다른 프롬프트(prompt)로 다시 생성해 보자"로 바뀌는 지점이라고 부르기 시작했습니다. 그것은 더 이상 디버깅이 아닙니다. 그것은 단계가 더 추가된 도박일 뿐입니다.

실제로 효과가 있는 실질적인 해결책들
저는 여러분에게 "AI 코드를 주의 깊게 리뷰하세요"라고 말하지 않겠습니다. 모두가 그렇게 말하지만 아무것도 바뀌지 않습니다. 모든 것을 동일한 정밀도로 리뷰하는 것은 확장성(scale)이 없기 때문입니다. 제가 함께 일했던 팀에서 실제로 효과가 있었고, 다른 곳에서도 효과를 보고 있는 방법들을 소개합니다.

머지(merge) 전, 한 문장의 "이유"를 요구하십시오. 만약 엔지니어가 PR(Pull Request) 설명에 AI의 접근 방식이 왜 올바른지 자신의 언어로 설명할 수 없다면, 머지할 수 없습니다. "AI가 생성한 재시도 로직(retry logic)" 같은 식은 안 됩니다. 다음과 같은 식이어야 합니다: "이 코드는 상위 API가 세 번의 빠른 재시도 후에 속도 제한(rate-limit)을 걸기 때문에 지수 백오프(exponential backoff)를 사용합니다." 이 단 하나의 규칙만으로도 인증 버그(auth-bug) 및 레이스 컨디션(race-condition) 범주의 실수 중 엄청난 비중을 잡아낼 수 있습니다. 왜냐하면 형식이 아닌 로직을 실제로 읽도록 강제하기 때문입니다.

모든 AI 생성 블록에 실제 인간의 손길을 강제하십시오. 변수 이름을 바꾸는 정도는 인정되지 않습니다. AI가 생성한 블록이 머지되기 전에, 엣지 케이스(edge case) 추가, 조건문 리팩터링(refactored), 또는 다른 에러 핸들링(error-handling) 방식 적용과 같이 최소한 하나 이상의 의미 있는 수정을 요구하십시오. 이해하지 못하는 것은 바꿀 수 없으므로, 수정하는 행위 자체가 코드를 실제로 이해하게 만드는 강제 기제(forcing function)가 됩니다.

AI 생성 코드를 매번 정적 분석 (Static Analysis)을 통해 검증하세요
SonarQube, ESLint 또는 Semgrep과 같은 도구들이 비즈니스 로직 (Business Logic) 오류를 잡아내지는 못하지만, 처리되지 않은 예외 (Unhandled Exceptions), 사용되지 않는 변수 (Unused Variables), 보안 안티 패턴 (Security Anti-patterns), 그리고 점점 더 정교해지는 AI 생성 클론 전용 중복 탐지 (Duplication Detection)와 같은 지루한 문제들은 확실하게 잡아냅니다.

AI가 작성한 코드에 대해 AI가 작성한 테스트를 금지하세요
이 부분은 사람들을 놀라게 할 것입니다. 만약 AI가 구현 (Implementation)과 테스트를 모두 작성한다면, 그 테스트는 실제로 무엇이 옳은지가 아니라 AI가 무엇을 가정했는지를 단순히 검증할 뿐입니다. 한 개발자는 코드 커버리지 (Coverage)가 94%에 달하지만 실제 비즈니스 로직 오류를 단 하나도 잡아내지 못한 테스트 스위트를 발견했는데, 이는 모든 테스트가 단순히 특정 메서드가 예상된 인자 (Arguments)와 함께 다른 메서드를 호출했는지만을 확인했기 때문이었습니다. 테스트는 독립적으로 작성해야 하며, 이상적으로는 AI의 구현을 확인하기 전(TDD 방식)에 작성하는 것이 좋습니다.

금지가 아닌 구역(Zone)을 설정하세요
AI 도구를 완전히 금지하지 마세요. 그것은 패배할 수밖에 없는 싸움입니다. 대신 AI가 자유롭게 활동할 수 있는 곳과 그렇지 않은 곳을 정의하세요. 보일러플레이트 (Boilerplate), 스캐폴딩 (Scaffolding), 유틸리티 함수를 위한 '그린 존 (Green Zone)', 추가 검토가 필요한 비즈니스 로직 및 API 통합을 위한 '옐로 존 (Yellow Zone)', 그리고 버그가 단순한 헤드라인이 아닌 사고 보고서(Incident Report)로 이어지는 인증 (Authentication), 결제 (Payments), 핵심 알고리즘을 위한 '레드 존 (Red Zone, 인간 전용)'으로 구분하십시오.

AI 보조 PR (Pull Request)을 위한 "부채 로그 (Debt Log)"를 유지하세요
엔지니어들이 "이것은 AI의 도움을 받았으며, X 부분에 대해 100% 확신할 수 없습니다"라고 표시하는 간단한 공유 문서 하나는 작성에 2분밖에 걸리지 않지만, 나중에 전체 스프린트 (Sprint)를 아껴줍니다. 이는 보이지 않는 부채를 가시적이고 추적 가능한 부채로 전환하며, 이것이 바로 핵심입니다.

전문가 통찰 (Expert Insights)
GitClear의 2억 1,100만 라인 분석부터 Ox Security의 "Army of Juniors" 보고서, SonarQube의 개발자 설문에 이르기까지, 이 문제에 관한 모든 진지한 연구를 관통하는 일관된 주제는 AI 도구가 코드 이해 (Code Comprehension) 속도를 유의미하게 높이지는 못하면서 코드 생성 (Code Generation) 속도만을 측정 가능할 정도로 높인다는 점입니다. GitClear의 CEO는 LeadDev와의 인터뷰에서, 자신조차 AI 도구를 사용하여 결과물을 배포하는 순간에는 장기적인 비용에 대해 거의 생각하지 않았다고 솔직하게 밝혔습니다.