오후 한나절 만에 400줄짜리 PR을 올렸다. 테스트는 전부 통과했고, 코드는 깔끔했다. 그런데 배포 직후 프로덕션에서 메모리 누수가 터졌다. 팝업도 없고 자동완성도 없다. 그래프만 천천히 올라가고, 주니어 개발자는 화면 앞에서 굳어버렸다. dev.to에 올라온 이 장면 하나가, 지금 우리가 외면하고 있는 불편한 진실을 정확하게 가리킨다.
우리가 소리 내어 말하지 않는 것
AI 네이티브 세대 개발자를 둘러싼 논쟁은 이미 시작됐다. r/ExperiencedDevs에서 'AI만 쓰다가 해고된 동료' 이야기가 1,000개 넘는 댓글을 끌어모았을 때, 양쪽 모두 절반만 맞고 절반은 핵심을 비켜갔다. 진짜 문제는 AI 사용 여부가 아니다. 우리가 '엔지니어'를 채용한다고 생각했지만, 실제로는 '프롬프트 오퍼레이터'를 데려왔다는 사실—그리고 그걸 모른 척해왔다는 점이다.
데이터는 이미 말하고 있었다
Anthropics가 2026년 1월에 발표한 연구 "How AI assistance impacts coding skills"는 불편하지만 명확한 숫자를 내놓는다. AI를 사용한 그룹의 코드 이해도 퀴즈 평균은 50점, 직접 코딩한 그룹은 67점(Cohen's d=0.738, p=0.01). 가장 큰 차이가 난 영역은 문법이나 스타일이 아니라 디버깅이었다. 특히 AI에 전적으로 의존한 '위임 그룹'은 40점 이하로 떨어졌다. 가장 빨리 작업을 끝냈지만, 독립적 사고는 가장 적었다.
연구자들의 표현은 직접적이다. "주니어 개발자의 역량 개발이 AI 사용으로 인해 저해됐다면, 생산성 이득은 AI가 작성한 코드를 검증하는 데 필요한 역량을 희생시킨 대가일 수 있다." 코드를 검증해야 할 사람이, 애초에 검증 능력을 키우지 못한 사람이 되어버린 구조다.
GitClear의 분석도 같은 방향을 가리킨다. 2020년부터 2024년까지 2억 1,100만 줄의 코드를 추적한 결과, 리팩토링 비율은 2021년 전체 커밋의 25%에서 2024년 10% 미만으로 줄었다. 같은 기간 중복 코드 블록은 800% 증가했고, 복사-붙여넣기 코드량이 리팩토링 코드량을 처음으로 추월했다. 코드베이스가 조용히 썩어가고 있다. 전체를 조망하는 사람이 없기 때문이다.
왜 하필 디버깅인가
코드를 생성하는 것과 시스템을 이해하는 것은 완전히 다른 능력이다. 코드 작성은 로컬하다—파일 하나, 목표 하나. 디버깅은 글로벌하다—수백 개의 파일이 머릿속에서 동시에 살아있어야 한다. AI는 전자에 탁월하고 후자에서 무너진다.
SWE-bench는 실제 GitHub 저장소의 버그를 모은 벤치마크다. GPT-4, Claude 2 같은 범용 모델들은 5%조차 넘지 못했다. 실제 버그를 고치려면 수백 개의 연결된 파일에 대한 정신적 지도가 필요한데, 그 지도를 주는 설명서 같은 건 존재하지 않는다. 처음의 주니어가 멈춰버린 이유와 정확히 같다.
잘 쓰는 사람의 방식은 다르다
그렇다면 AI와 올바르게 협업하는 모습은 어떤 것일까. dev.to에서 55개 Rust 크레이트로 구성된 대형 프로젝트를 혼자 구축한 개발자의 경험은 좋은 대조군이 된다. 그는 AI 덕분에 전체적으로 약 30% 빨라졌다고 말한다. 그런데 그 30%가 어디서 나오는지가 핵심이다.
생산성 향상은 특정 영역에 집중됐다. 반복적인 트레이트 구현, 유닛 테스트 초안, rustdoc 주석, 이미 경험한 바로우 체커 에러 설명—이 모든 건 기계적으로 반복되는 작업이다. 반면 서브시스템 구조 설계, 레이스 컨디션 디버깅, 미묘한 라이프타임 이슈는 AI 도입 전후로 속도가 전혀 달라지지 않았다. "AI는 내게 자신 있는 답을 준다. 하지만 그 답이 3개월 후 문제를 만들어낼 때 그걸 멈추는 건 AI가 아니다"—그가 직접 덧붙인 말이다.
그의 워크플로우를 구체적으로 보면 패턴이 선명하다. AI에게는 실제 타입 시그니처와 트레이트 바운드를 포함한 정확한 컨텍스트를 제공한다. '의도'만 설명하는 산문형 프롬프트는 쓰지 않는다. 테스트 스캐폴딩은 AI가 잡고, 실제로 버그를 잡는 엣지 케이스는 본인이 직접 추가한다. 아키텍처 결정은 AI에게 묻지 않는다—그건 코드베이스를 2년간 직접 쌓아온 사람만 가진 컨텍스트가 필요한 영역이기 때문이다.
진짜 책임은 어디에 있나
주니어 개발자를 탓하기 쉽다. 하지만 dev.to의 글쓴이는 다른 곳을 지목한다. 우리가 함정을 설계하고 그 안으로 이끌었다. 빠른 PR을 칭찬했고, 그 논리를 설명하라고 한 번도 묻지 않았다. Tuskira의 CISO/CPO 옴 물찬다니는 2025년 4월에 이렇게 말했다. "주니어 리소스들은 문제 해결 능력이 부족하고, 시스템 수준의 깊은 이해가 없다. 코드 조각을 만들 수는 있지만 그 논리를 설명하거나 실제 공격 시나리오로부터 방어하는 건 어렵다." 러닝 커브를 외주로 넘겼더니, 러닝이 일어나지 않았다.
지금 당장 바꿀 수 있는 것
도구를 금지하는 건 해법이 아니다. 문제는 AI가 아니라, AI를 감당할 수 있는 기반 없이 AI를 먼저 쥐어줬다는 데 있다. 실천 가능한 방향은 몇 가지로 정리된다.
머지 전에 diff를 소리 내어 설명하게 하라. "AI가 썼다"는 설명은 없는 것과 같다. 구현 결정을 자신의 언어로 풀 수 없다면, 그 코드는 아직 그 사람의 코드가 아니다. 자동완성 없이 일주일에 한 번은 복잡한 버그를 직접 추적하게 하라. 내 것이 아닌 오래된 코드를 읽어서 시스템이 '마법'처럼 느껴지지 않을 때까지 파고들게 하라.
AI는 이미 프레임워크가 있는 사람에게 가속을 준다. 55개 크레이트 프로젝트를 혼자 만든 개발자가 30% 빨라진 건, 그가 아키텍처와 엣지 케이스를 스스로 판단할 수 있었기 때문이다. AI가 보일러플레이트를 처리해준 덕분에 그의 주의력이 정말 어려운 문제에 집중될 수 있었다. 프레임워크가 없는 상태에서 AI는 속도를 주지 않는다—착각을 준다.
한 가지 질문으로 마무리하고 싶다. 지금 팀에서 가장 빠른 주니어에게 일주일 동안 AI 도구를 모두 끄면 어떻게 될까. 여전히 같은 자리에 있을까. 그 답이 불편하다면, 우리가 지금 측정하고 있는 것이 무엇인지 다시 생각해볼 때다.