Copilot은 주니어 개발자에게 미드 레벨 (mid-level) 개발자의 속도를 부여하지만, 판단력은 인턴 수준에 머물게 합니다. 이는 관련된 그 누구에게도 칭찬이 아닙니다.

저는 한동안 주니어 개발자들이 제출한 PR (Pull Request)을 검토해 왔는데, 지난 1년 동안 변화를 감지했습니다. 코드가 더 깔끔해_보입니다_. 더 빠르게 전달됩니다. 하지만 무언가 고장 나면, 코드를 작성한 사람은 그것이 무엇을 하는지 설명하지 못하는 경우가 많습니다.

속도의 함정 (The Speed Trap)

GitHub Copilot과 같은 AI 프로그래밍 도우미는 정말 놀랍습니다. 주니어 개발자는 2년 전이라면 구현하는 데 일주일이 걸렸을 새로운 기능의 구조를 단 몇 시간 만에 설정할 수 있습니다.

하지만 이해 없는 속도는 그저 리본을 달아놓은 기술 부채 (technical debt)일 뿐입니다. 코드는 머지 (merge)되고, 티켓 (ticket)은 닫히며, 운영 환경 (production)에서 문제가 발생하기 전까지는 아무도 문제를 알아차리지 못합니다.

제가 발견한 반복되는 패턴은 다음과 같습니다:

→ Copilot이 표면적인 리뷰를 통과하는 미묘하게 잘못된 코드를 생성함
→ 주니어 개발자는 로직을 직접 작성하지 않았기 때문에 문제를 찾아내지 못함
→ 시니어 리뷰어는 코드가 깔끔하고 관용적 (idiomatic)으로 보이기 때문에 대충 훑어봄
→ 팀원 중 누구도 완전히 이해하지 못하는 버그가 배포됨

이것은 가설이 아닙니다. 바로 지금 일어나고 있는 일입니다.

기초의 격차 (The Fundamentals Gap)

연구에 따르면 AI가 제안한 코드는 보안 오류를 포함할 가능성이 더 높다고 합니다. 이는 제안을 수락하는 사람이 그것이 무엇을 하는지 완전히 이해하지 못할 때 예상되는 결과와 일치합니다.

우려스러운 점은 나쁜 코드가 존재한다는 사실 자체가 아니라, AI가 첫 시도에 겉보기에 작동하는 코드를 써주기 때문에 기초를 배우려는 시도조차 하지 않는 주니어들이 생겨날 가능성입니다. Copilot이 테스트를 통과하는 무언가를 제공해 주는데, 왜 비동기 (async) 에러 핸들링이 실제로 어떻게 작동하는지 배울 필요가 있겠습니까? 🤷

간단한 답은 테스트가 모든 개별 유스케이스 (use case)와 잠재적 문제를 다룰 수는 없다는 것입니다. 그리고 Copilot이 작성한 코드가 새벽 2시에 실패했을 때, 당신에게 필요한 사람은 단순히 수정을 위해 프롬프트 (prompt)를 입력할 수 있는 사람이 아니라, 실제로 코드를 읽을 수 있는 사람입니다.

저는 우리가 빠르게 배포할 수는 있지만, 자신이 배포한 것을 디버깅(debug)할 수는 없는 개발자 세대를 만들고 있는 것은 아닌지 걱정됩니다.

이것은 반(反) AI적인 관점이 아닙니다

저도 Copilot에 의존합니다. Copilot을 사용하는 것을 즐깁니다. 보일러플레이트 (boilerplate) 코드를 작성할 때 시간을 실질적으로 아껴주고, 접근 방식을 더 빠르게 생각할 수 있도록 도와줍니다.

하지만 저는 이미 좋은 코드가 어떤 모습인지 알고 있습니다. 추천된 내용이 완전히 옳지 않을 때 어떻게든 알아챌 수 있습니다. 그러한 직관은 제가 직접 형편없는 코드를 작성하며 고생하며 배웠던 수년간의 경험에서 나옵니다.

주니어들은 아직 그러한 직관을 쌓지 못했습니다. 만약 AI가 그러한 직관을 만들어내는 고통스러운 과정을 없애버린다면, 우리는 진짜 문제에 직면하게 됩니다. 이는 곱셈의 개념을 이해하기도 전에 계산기를 쥐여주는 것과 비슷합니다. 그들은 답변을 받겠지만, 정답이 틀렸을 때 그것이 틀렸다는 사실을 알지 못할 것입니다. 🎯

실제로 도움이 되는 것들

주니어 개발자들에게 AI 도구 사용을 금지해야 한다고 제안하는 것이 아닙니다. 그렇게 한다 해도 효과가 없을 것이며, 오히려 반대의 결과를 초래할 수도 있습니다.

저는 팀들이 이러한 상황이 발생할 것에 대비해 계획을 세워야 한다고 믿습니다.

→ PR 리뷰 (PR reviews) 시 주니어들이 AI가 생성한 코드를 한 줄씩 설명하도록 요구하기
→ 단순히 구축하는 것뿐만 아니라, 디버깅 (debugging) 과정에서 페어 프로그래밍 (pair programming) 하기
→ 주니어들이 때로는 지저분하고 느리며 수동적인 코드를 작성할 수 있는 공간을 만들어 주기 — 바로 그곳에 배움이 존재합니다
→ Copilot의 제안을 Stack Overflow의 답변처럼 취급하기: 유용한 시작점일 뿐, 절대적인 진리가 아님

목표는 개발 속도를 늦추는 것이 아닙니다. 키보드 뒤에 있는 사람이 코드베이스 (codebase)만 키우는 것이 아니라, 실제로 성장하고 있는지 확인하는 것입니다.

진짜 질문

AI 어시스턴트는 사라지지 않을 것입니다. 점점 더 좋아질 것입니다. 번창할 개발자는 AI를 학습을 건너뛰기 위한 지름길이 아니라, 학습을 가속화하기 위한 도구로 사용하는 사람이 될 것입니다.

코드를 복사해서 붙여넣기만 하며 자신이 무엇을 하고 있는지 제대로 이해하지 못한 채, 초기 몇 년을 그저 흘려보낸 학생들은 어떻게 될까요? 그들은 엄청난 장애물에 직면하게 될 것입니다. 그리고 왜 막혔는지 디버깅할 기술조차 갖추지 못한 상태일 것입니다. 😬

여러분의 팀은 주니어 개발자들의 AI 어시스턴트(AI assistants) 활용을 어떻게 관리하고 계신가요? 여러분도 저와 같은 패턴을 목격하고 계신가요, 아니면 제가 지나치게 깊이 생각하고 있는 것일까요?