AI 코딩 도구를 많이 쓸수록 초보 개발자가 더 빨리 성장한다는 말은 절반만 맞다. 코드를 만드는 속도는 빨라지지만, 초보자가 답을 고르고 오류를 추적하며 설계를 바꾸는 시간을 건너뛰면 나중에 AI의 결과를 검토할 기준도 함께 약해질 수 있다. Lars Faye는 이를 “초보자가 도구를 제대로 쓰려면 이미 전문가 수준의 판단이 필요한” 역설로 설명했다.
AI가 코드를 쓰더라도, 새 라이브러리나 낯선 장애를 만났을 때 무엇을 물어야 하는지, 제안된 변경이 왜 맞는지, 테스트가 통과해도 어떤 경계 조건이 빠졌는지를 판단하는 일은 사람 몫이다. 경험이 있는 개발자는 AI를 초안 작성과 반복 작업에 붙인 뒤 결과를 조정·감사·검증한다. 입문자는 그 판단을 만들기 전부터 같은 자동화를 요구받기 쉽다.
코드가 돌아간다는 사실과 이해했다는 사실은 다르다
Anthropic은 2026년 1월, Trio를 처음 쓰는 소프트웨어 엔지니어 52명을 대상으로 새 기능 두 개를 구현하게 한 무작위 대조 실험을 공개했다. AI 도움을 받은 집단은 퀴즈에서 평균 50%, 직접 코딩한 집단은 67%를 기록했다. AI 집단은 평균 약 2분 빨랐지만 그 차이는 통계적으로 유의하지 않았고, 점수 차이는 특히 디버깅 문항에서 컸다.
이 수치가 “AI를 쓰면 누구나 실력이 떨어진다”는 뜻은 아니다. 이 실험에서 이해도가 높았던 참가자들은 생성된 코드를 그대로 끝내지 않고 후속 질문으로 이유를 묻거나, 개념 질문을 한 뒤 스스로 코딩했다. 반대로 AI에게 작성과 디버깅을 모두 넘긴 참가자 집단은 가장 빨리 끝냈지만 평균 퀴즈 점수가 40% 미만이었다. 같은 도구라도 답을 받는 방식과 자기 판단을 남기는 방식의 결과가 갈렸다.
초보 개발자의 성장 경로는 어디에서 막히는가
초보자의 성장 경로는 대체로 작은 문제를 자기 힘으로 쪼개고, 틀린 가설을 버리고, 로그와 문서를 오가며 원인을 좁히는 경험으로 만들어진다. 이 과정은 느리지만 “이 변경은 위험하다”거나 “이 오류는 데이터 경계에서 났다”는 감각의 재료가 된다. 생성된 코드가 그 중간 과정을 감추면, 겉으로는 더 큰 작업을 끝낸 것처럼 보여도 다음 작업에서 스스로 시작할 발판이 줄어든다.
팀에도 같은 문제가 생긴다. 완료한 티켓 수와 병합 속도만 보면 AI를 많이 쓴 주니어가 빠르게 보일 수 있다. 하지만 코드 리뷰에서 변경 이유를 설명하지 못하거나, 장애 때 생성 도구 없이는 재현과 수정의 첫 단추를 못 끼우면 그 속도는 팀의 검토 비용으로 돌아온다. 그만큼 숙련자의 검토 시간도 더 필요해진다.
학습 경로를 남기며 AI를 쓰는 방법
입문자는 AI 사용 여부보다 작업 순서를 먼저 정해야 한다. 먼저 문제를 자기 말로 적고, 어떤 파일과 테스트를 볼지 짧게 계획한 다음, 막힌 지점에서만 AI에게 힌트나 개념 설명을 요청한다. 코드를 받았다면 복사로 끝내지 말고 한 부분씩 적용해 테스트를 돌리고, 변경 이유와 실패했을 때의 증상을 설명할 수 있어야 한다. 이 순서는 속도를 조금 늦추지만 다음 문제를 혼자 시작할 수 있는 범위를 넓힌다.
조직은 주니어에게 AI 사용량 목표를 주기보다 리뷰에서 확인할 질문을 정하는 편이 낫다. “이 코드가 왜 필요한가”, “다른 선택지는 무엇이었나”, “어떤 테스트가 이 변경을 반박할 수 있나”를 답하게 하면, AI는 이 질문에 답하는 과정에서 생각을 점검하는 도구가 된다. 반복적이고 이미 익힌 작업에서는 자동화의 이득을 크게 가져가되, 새 도메인과 장애 대응에서는 설명과 검증의 마찰을 남겨 두는 운영이 성장 경로를 지킨다.
출처: Lars Faye, “AI Coding will Prevent Expertise”; Anthropic, “How AI assistance impacts the formation of coding skills” (2026-01-29).