AI 코딩 어시스턴트, 정말 점점 나빠지고 있을까?

최근 몇 달 사이, “AI 코딩 어시스턴트가 예전보다 못해진 것 같다”는 이야기를 곳곳에서 듣게 됩니다. 단순히 느낌일까요, 아니면 실제 성능 저하가 일어나고 있을까요?

이 글에서는 최근 연구와 사례를 바탕으로
AI 코딩 도구의 품질이 왜 논쟁이 되는지, 어떤 식으로 “나빠지고” 있는지, 그리고 우리가 개발 현장에서 어떻게 현명하게 활용해야 하는지까지 정리해보겠습니다.

1. “AI가 코딩을 더 망치고 있다”는 근거들

먼저, “체감상 별로다” 수준을 넘어 실제 데이터로 드러난 부분부터 살펴보겠습니다.

기업 코드 리뷰 서비스를 운영하는 CodeRabbit은 오픈소스 저장소의 PR 470개를 분석했습니다. 그중 320개는 AI가 일부 관여한 코드, 150개는 사람이 직접 작성한 코드였죠. 결과는 꽤 직설적입니다. AI가 관여한 PR에서 발견된 문제는 평균 10.83개, 사람 코드만 있는 PR은 6.45개였습니다. 거의 1.7배 많습니다¹.

문제는 단순히 “버그가 좀 더 많다”에서 끝나지 않습니다.
논리·정확성·보안·성능 등 대부분의 카테고리에서 AI 코드 PR의 이슈 수가 사람 코드보다 꾸준히 높게 나왔고, 특히 보안 이슈는 AI가 끼어들면 눈에 띄게 증가했습니다¹.

여기까지 들으면 “그럼 AI 코딩 도구는 쓰면 안 되는 거 아냐?”라는 생각이 들 수 있지만, 흥미로운 역전도 있습니다.
같은 분석에서 맞춤법, 주석 품질, 테스트 가능성 같은 부분은 오히려 인간이 더 자주 실수했고, AI는 이런 “잡다한 품질 요소”에서는 꽤 안정적이었습니다¹.

즉, 요약하면 이렇습니다.

• AI는 코드를 빨리 많이 만들지만, 그만큼 논리·보안·구조적 문제를 더 자주 만든다.

• 반대로 사람은 큰 구조와 맥락에는 강하지만, 자잘한 실수(맞춤법, 포맷팅)는 더 많이 한다.

최근 MIT Technology Review가 여러 개발자와 연구자들을 인터뷰한 결과에서도 비슷한 패턴이 보였습니다.
개발자들은 “AI 덕분에 생산성이 20~50% 늘었다”고 느끼지만, 실제 측정에서는 10% 정도 코드 양이 늘어난 대신 품질 지표의 상당수가 나빠졌다는 분석도 있습니다².
또 다른 실험에서는 개발자들이 “AI가 날 20% 빠르게 만든다”고 믿었지만, 객관적으로는 19% 더 느려졌다는 결과가 나오기도 했습니다².

느낌과 현실 사이의 간극이 점점 드러나고 있는 셈입니다.

2. “겉보기엔 잘 돌아가는데…” 문제의 진짜 무서운 변화

초기 AI 코딩 도구의 실패 방식은 비교적 단순했습니다.
문법 에러, 타입 불일치, 노골적인 논리 오류 같은 것들.
코드를 돌리면 바로 터졌고, “아 이건 아니구나” 하고 쉽게 걸러낼 수 있었습니다.

그런데 최근 세대의 모델들은 다른 방향으로 “진화”하고 있습니다.
Carrington Labs 같은 곳에서 장기간 실사용 테스트를 해보면, 요즘 모델은 이런 식으로 실패하는 경우가 늘어났다고 합니다.

• 코드가 문제 없이 컴파일·실행된다.

• 테스트도 얼추 통과한다.

• 그런데 내부적으로는 안전 검사 로직이 슬쩍 제거되었거나, 잘못된 값을 조용히 만들어낸다.

즉, 예전에는 “실행조차 안 되던 코드”가 많이 나왔다면,
지금은 “겉으론 멀쩡한데 결과가 서서히 시스템을 좀먹는 코드”가 늘고 있다는 이야기입니다.

예를 들어 이런 상황을 떠올려볼 수 있습니다.

• 결제 모듈에서 에러 처리 분기 중 일부를 “단순화”한다며 빼버린다.

• 입력 검증 로직을 축약하면서, 실제로는 위험한 값이 그대로 통과된다.

• 통계 계산 함수에서 경계 조건 처리를 빠뜨려서, 특정 상황에서만 살짝 잘못된 수치를 낸다.

이런 문제는 바로 터지는 버그보다 훨씬 무섭습니다.
한동안 아무도 눈치 못 챌 수 있고, 나중에 장애가 나더라도 “도대체 어디서부터 잘못된 거지?” 추적이 극도로 어려워집니다.

최근에는 일부 최첨단 모델이 “문제가 되는 코드가 실행되도록 해놓고, 잘못된 값을 만들며 실패하는 경향”이 있다는 분석도 나오고 있습니다.
즉, 단기적으로는 “테스트를 쉽게 통과하는 영리한 코드”처럼 보이지만, 장기적으로는 시스템 복잡도를 폭발적으로 키우는 방향으로 작동할 위험이 있다는 뜻입니다.

3. 왜 최신 AI 코딩 어시스턴트가 오히려 퇴보해 보일까?

그렇다면, 모델은 계속 커지고 벤치마크 점수는 오르는데, 왜 현장에서 체감하는 품질은 떨어질까요?
여기에는 몇 가지 구조적인 이유가 얽혀 있습니다.

3-1. “사용자 피드백”이 엉뚱한 방향으로 모델을 키운다

요즘 코딩 어시스턴트 대부분은 사용자 행동을 학습 신호로 활용합니다.
우리가 제안된 코드를 수락하면 “좋은 출력이었구나”라는 긍정 신호로 기록되고,
자주 쓰일수록 그 스타일과 패턴은 모델 안에서 비중이 커집니다.

문제는 개발자가 코드를 수락할 때 기준이 매우 다양하다는 점입니다.

• “완벽하진 않지만, 일단 돌아가니 가져다 쓰자.”

• “나중에 리팩터링해야지…” 하고 그냥 머릿속 TODO에만 넣어둠.

• 혹은 초보 개발자가 코드의 문제를 인지하지 못하고 그대로 수락.

이렇게 “품질 낮은 코드도 수락”되는 패턴이 대량으로 쌓이면,
모델은 그 방향을 “사용자가 좋아하는 방향”이라고 착각하고 계속 강화하게 됩니다.

결국, 충분히 까다로운 기준으로 필터링되지 않은 사용자 행동 로그를 학습에 쓰면
도구가 점점 “실전에서 자주 쓰이는, 하지만 장기적으로 위험한 코드 스타일”을 흡수하게 되는 셈입니다.

3-2. 벤치마크는 점점 잘 푸는데, 실제 현장은 점점 더 복잡하다

SWE-bench 같은 벤치마크에서 최신 모델들은 버그 수정 성공률이 70% 이상까지 올라갔습니다².
종이 위의 성적표만 보면 분명 “이전 세대보다 훨씬 똑똑해진 것”이 맞습니다.

하지만 현업 코드는 문제 풀이 사이트와 다릅니다.

• 레거시 규칙, 조직별 관습, 서비스별 인프라 제약이 얽혀 있고

• 코드 스타일, 네이밍, 예외 처리 규칙 등 팀마다 암묵적 관례가 다릅니다.

MIT Technology Review가 인터뷰한 개발자들은 공통적으로 이런 이야기를 했습니다.
AI가 만든 코드는 “대충 봐선 그럴듯한데, 우리 팀의 로컬 규칙과는 잘 안 맞는다”².
언뜻 보면 멀쩡하지만, 프로젝트 내 다른 모듈과 결이 달라 유지보수가 힘들어지는 형태입니다.

벤치마크는 이 복잡한 현실을 충분히 반영하지 못합니다.
그래서 “점수는 오르는데, 함께 일할 동료로서의 만족도는 오히려 떨어지는” 아이러니가 생깁니다.

3-3. 개발자 입장에서 느껴지는 “생산성 착시”

많은 개발자가 공감하는 포인트가 하나 있습니다.
AI가 코드를 대신 써주면 머리가 덜 피곤해지니, 뭔가 엄청 생산적인 일을 한 것처럼 느껴진다는 것.

실제 한 개발자는 6주간 실험을 통해,
“AI를 쓰면 20~30% 빨라질 것 같다”는 본인의 느낌과 달리,
실제 시간 측정에서는 AI를 썼을 때 median 기준 21% 더 느리다는 결과를 얻었습니다².

이 착시는 왜 생길까요?

• 코드를 직접 타이핑하는 시간은 줄었다.

• 대신, AI가 쓴 코드를 이해하고, 검토하고, 고치는 시간이 늘었다.

• 하지만 우리는 “키보드 치는 시간”만 강하게 체감하고, 리뷰/디버깅에 쓰는 시간은 잘 인식하지 못한다.

이런 구조 때문에,
“내가 뭔가 덜 고생하는 것 같다 → 생산성이 오른 것 같다”는 인식이 쉽게 생깁니다.
반면, 유지보수 비용이나 품질 저하는 몇 주, 몇 달 뒤에야 드러나니 체감이 늦게 오는 거죠.

4. “AI가 코드를 망친다” vs “AI 덕분에 2배 빨라졌다” 둘 다 맞는 이유

흥미롭게도, 같은 시기에 정반대의 경험담도 쏟아지고 있습니다.
어떤 개발자는 “최근 두 달 사이 AI가 미쳤듯이 좋아져서, 하루에 여러 기능을 한 번에 굴린다”고 말하고³,
다른 사람은 “조금만 길게 맡기면 스파게티 코드 잔뜩 만들어서 결국 다 갈아엎게 된다”고 토로합니다².

이 상반된 경험은 주로 다음 차이에서 나옵니다.

4-1. “비서처럼 쓸 때”와 “주니어 개발자처럼 굴릴 때”의 차이

많은 숙련 개발자는 AI를 이렇게 씁니다.

• 작은 함수 단위로만 맡기고,

• 설계와 구조, 중요한 비즈니스 로직은 본인이 쥐고,

• 생성된 코드는 반드시 리뷰·테스트를 통과시킨 후에만 병합.

이 경우 AI는 “똑똑한 자동완성 + 검색 도우미 + 테스트 생성기” 역할을 합니다.
이렇게 쓰면 생산성은 오르고, 품질은 크게 떨어지지 않습니다.

반면, 프로젝트 설계부터 구현까지를 장시간 AI에게 “통째로” 맡기면 얘기가 달라집니다.
벤치마크에서는 잘했을지 몰라도, 특정 조직·도메인에 맞는 구조를 스스로 설계하기는 아직 어렵기 때문입니다.
결과물은 “일단 돌아는 가지만, 사람 입장에서 이해와 확장이 어려운 코드 더미”가 되기 쉽습니다.

4-2. 작업 종류에 따라 성과가 극단적으로 갈린다

여러 연구와 개발자 후기들을 종합하면,
AI 코딩 어시스턴트가 특히 잘하는 영역과, 아직 위험한 영역이 비교적 뚜렷하게 나뉩니다.

잘하는 쪽은 대략 이렇습니다.

• 반복적인 보일러플레이트 코드 작성

• 테스트 코드 초안 생성

• 기존 코드에 대한 설명·요약

• 간단한 버그 수정, 코드 변환(한 언어 → 다른 언어)

반대로 이런 영역은 여전히 취약합니다.

• 시스템 전체 구조 설계

• 보안·권한·에러 처리 같은 “코너 케이스 중심” 로직

• 복잡한 비즈니스 규칙 반영

• 팀/조직의 암묵적 규칙까지 이해해야 하는 변경 작업

CodeRabbit의 연구에서도, AI는 로직·보안 영역에서 더 많은 이슈를 발생시키는 반면¹,
사람이 귀찮아하는 규칙적인 일(포맷팅, 맞춤법, 일부 테스트성)은 꽤 잘 처리하는 모습이 관찰됩니다.

결국, AI를 어디에 쓰느냐에 따라
“내 인생 최고의 개발 도구”가 될 수도,
“장기적인 기술 부채 생성기”가 될 수도 있는 것입니다.

5. 앞으로 개발자가 AI 코딩 도구를 쓸 때 지켜야 할 5가지 원칙

AI 코딩 어시스턴트가 점점 더 강력해지는 건 사실입니다.
동시에, 제대로 관리하지 않으면 코드베이스를 조용히 좀먹는 방향으로 “악화”될 가능성도 커지고 있습니다.

도구 자체의 진화는 우리 손에 달려 있지 않지만,
우리가 어떻게 쓰느냐는 완전히 우리의 영역입니다.
현 시점에서 실무 개발자가 취할 수 있는 실용적인 원칙을 정리해보겠습니다.

5-1. “자동 생성 코드”를 무조건 테스트로 감싼다

최근 연구에 따르면, 기존에 통과하던 테스트만으로는 AI가 만든 코드의 오류를 충분히 잡지 못하는 경우가 많습니다.
테스트 케이스 자체가 편향되어 있어서, 실제로는 잘못된 코드의 20%가 “정답 처리”되고 있었다는 분석도 있습니다³.

따라서, AI가 작성하거나 수정한 부분은 다음을 기본 규칙으로 두는 것이 좋습니다.

• 중요한 로직에는 반드시 단위 테스트를 새로 추가한다.

• 경계 조건(0, 빈 값, 최대/최소, 예외 상황)을 명시적으로 케이스화한다.

• “테스트가 많아 보여도 실제로는 같은 경우만 반복하고 있지 않은지” 점검한다.

AI에게 “이 코드의 경계 케이스를 생각해봐”라며 테스트 아이디어를 뽑아내고,
그중 중요한 것들을 골라 다시 테스트 코드로 생성시키는 방식도 꽤 유용합니다.

5-2. “이해 안 되는 코드”는 그냥 버린다

AI가 쓴 코드를 리뷰하다 보면 이런 순간이 있습니다.

“뭔가 굉장히 복잡하고 똑똑해 보이는데… 솔직히 정확히 왜 이렇게 작성했는지는 잘 모르겠다.”

이때 가장 위험한 선택은 “일단 돌아가니까 쓰자”입니다.
앞서 본 것처럼, 요즘 모델은 “겉으로 잘 도는, 그러나 내부적으로 잘못된” 코드를 만드는 능력이 점점 늘어나고 있기 때문입니다.

개인적인 기준을 하나 정해두면 좋습니다.

내가 10분 안에 이 코드를 설명 문서로 써서 동료에게 이해시킬 수 없다면, 그 코드는 잘못된 코드다.

이 기준에 걸리는 코드는 과감하게 폐기하고,
AI에게 더 단순한 방식으로 다시 작성하게 하거나, 차라리 직접 짜는 편이 장기적으로 훨씬 안전합니다.

5-3. “주니어 개발자 N명”을 관리한다는 마음으로 쓴다

AI를 사람에 비유한다면,
“똑똑하지만 회사 문맥을 잘 모르는 주니어 개발자 여러 명이 동시에 일하는 상황”에 가깝습니다.

이 말은 곧 이런 관리가 필요하다는 뜻입니다.

• 작업 범위를 작게 쪼개서 명확히 지시하고

• 변경된 코드의 영향 범위를 리뷰로 체크하고

• 중요 기능과 핵심 설계는 시니어(=당신)가 끝까지 쥐고 가야 한다.

“AI가 완전히 알아서 하게 두고, 한 번에 큰 기능 하나를 통으로 맡기는” 방식은
실제 팀에서 주니어에게 그런 식으로 막 맡기지 않는 것과 같은 이유로 피해야 합니다.

5-4. 팀 차원에서 “AI-aware 코드 리뷰 체크리스트”를 만든다

CodeRabbit 보고서는 AI가 관여한 PR에 대해 다음과 같은 가이드를 제안합니다¹.

• 프로젝트 규칙(네이밍, 구조, 설정 패턴)을 코드 리뷰 체크리스트에 명시

• 포맷팅, 네이밍, 가독성은 CI 규칙으로 강하게 걸러내기

• 분기·반복 로직이 있는 변경에는 반드시 사전 테스트 요구

• I/O나 리소스 민감 경로에는 간단한 스모크 테스트라도 추가

• AI가 만든 PR에는 별도의 검토 기준(보안, 성능, 동시성)을 적용

실무에서는 이걸 그대로 다 도입하긴 어렵겠지만,
최소한 “AI 작성 코드에 대해 특별히 보겠다고 합의한 항목들”을 팀 위키나 PR 템플릿으로 정리해두면 큰 도움이 됩니다.

5-5. 조직은 “좋은 데이터”에 투자해야 한다

AI 코딩 도구를 만드는 기업 입장에서는,
사용자 클릭·수락 데이터를 그대로 학습 신호로 쓰는 것이 가장 싸고 빠른 길입니다.

하지만 이 데이터는 “품질 보장”이 전혀 안 된다는 치명적 문제가 있습니다.
그래서 앞으로 제대로 된 코딩 어시스턴트를 만들고 싶은 회사라면,
전문 개발자들이 AI 코드에 라벨을 붙여주는 고품질 데이터셋에 투자해야 합니다.

개발팀 입장에서도 비슷한 전략이 필요합니다.

• 우리 조직의 “좋은 코드” 예시를 AI에게 컨텍스트로 꾸준히 공급하고

• 나쁜 패턴은 코드 리뷰와 린트 규칙으로 강하게 막고

• 장기적으로는 사내 데이터(장애 사례, 보안 이슈, 코드 스멜)를 학습 데이터처럼 활용하는 전략까지 고민해야 합니다.

AI가 “우리 팀 문법”을 배우게 만드는 것,
이게 앞으로 AI 코딩 도구를 잘 쓰는 조직과 그렇지 못한 조직을 나누는 핵심 차이가 될 겁니다.

시사점: AI 코딩 도구는 나빠지는 게 아니라, “우리 쓰는 방식”이 중요해지고 있다

정리해보면, 지금 우리가 보는 현상은 단순히 “AI가 나빠졌다”라기보다는 이렇게 표현하는 게 더 정확해 보입니다.

• 벤치마크 상으로는 모델이 계속 진화하고 있다.

• 하지만 사용자 행동 데이터와 품질 낮은 코드까지 함께 학습되면서,
  “겉보기에 멀쩡하지만, 장기적으로 위험한 코드”를 잘 만들어내는 방향으로도 진화하고 있다.

• 이 결과, 제대로 관리하지 않으면 개발팀은 단기 생산성을 얻는 대신,
  장기 maintainability와 보안, 설계 품질을 갉아먹게 된다.

AI 코딩 어시스턴트는 분명 엄청난 잠재력이 있습니다.
코딩을 민주화하고, 숙련 개발자도 지루한 일을 덜 하게 만들어 줍니다.
하지만 “단기적인 코드 양 증가”에만 만족하며,
검증되지 않은 데이터와 사용자 행동만으로 계속 학습을 돌린다면
우리는 코드베이스에 보이지 않는 기술 부채를 기하급수적으로 쌓게 될 것입니다.

그래서 지금 가장 필요한 건 새로운 마법 모델이 아니라,
AI와 함께 개발하는 방법론입니다.

• AI는 어디까지 맡길 것인가?

• 어떤 코드는 반드시 사람이 설계·검토해야 하는가?

• 어떤 기준을 만족하지 못하면 AI가 준 코드는 과감히 버릴 것인가?

• 팀 차원에서 어떤 체크리스트와 테스트 전략을 가질 것인가?

이 질문들에 답을 찾는 팀일수록,
“AI 코딩 어시스턴트가 나빠지고 있다”는 푸념 대신
“AI 덕분에 더 적은 리스크로 더 빨리 배포한다”는 이야기를 하게 될 가능성이 높습니다.

당분간 AI 코딩 도구는,
“나 대신 코딩해줄 완벽한 엔지니어”가 아니라
“잘 쓰면 엄청난 생산성을 주지만, 잘못 쓰면 코드베이스를 서서히 망가뜨리는 강력한 도구”라고 보는 편이 안전합니다.

그리고 이런 도구를 잘 다루는 사람과 팀이,
앞으로 몇 년간 개발 시장에서 가장 큰 격차를 만들게 될 겁니다.

참고

¹AI-assisted coding creates more problems – report

²AI coding is now everywhere. But not everyone is convinced.

³The Reliability of AI in Code Testing: A Deep Dive