주니어 개발자는 AI 도우미에게 낯선 라이브러리를 사용해 달라고 요청하고 작동하는 코드를 받은 뒤 다음 작업으로 넘어갈 수 있다. 개발자가 코드가 왜 작동하는지 이해하기도 전에 기능이 준비될 수 있다. 다음에 코드가 고장 나거나 요구 사항이 바뀌거나 누군가 도우미가 제안한 수정이 안전한지 판단해야 할 때 문제가 된다.
소프트웨어 엔지니어 알렉산드루 네델쿠는 이 우려를 9월 22일자 에세이에서 제기했다. 그는 개발자가 코드를 읽고 선택을 내리고 실수의 결과를 감당하는 과정에서 판단력을 기른다고 주장한다. 일부 기업이 AI 사용 금지 정책을 내걸 것이라는 그의 예상은 의견이지, 관찰된 업계 변화는 아니다. 1월에 발표된 별도의 실험은 학습에 관한 질문을 더 좁고 검증 가능한 형태로 다룬다. AI의 도움을 받아 과제를 마친 직후 프로그래머는 무엇을 이해했을까? 연구 내용은 Anthropic의 연구 소개에 담겨 있다
큰 변화
- 무엇이 바뀌었나: AI를 사용하면 논리를 직접 따라가 보지 않고도 완성된 소프트웨어를 제출하기 쉬워진다. 처음 접하는 사람은 설명하거나 고치는 데 필요한 판단을 연습하기도 전에 구현 결과를 받을 수 있다.
- 왜 중요한가: 관리자는 오늘 더 많은 결과물을 얻는 대신 주니어 직원이 내일의 실패를 진단할 사람으로 성장하는 경로를 약화할 수 있다. 낯선 개념을 사용하는 과제에서 위험이 가장 크지만, 익숙한 작업에서 AI의 도움은 여전히 유용할 수 있다.
- 지켜볼 점: 팀은 학습을 납품 과정의 일부로 보고 AI의 도움을 받은 작업을 설명하고 진단하고 수정하는 시간을 따로 마련할 수 있다. 그렇게 한다면 채용 과제와 코딩 제품은 속도뿐 아니라 실제 이해도 함께 평가할 수 있다.
완료된 과제와 배운 기술은 서로 다른 결과다
프로그래머 52명을 대상으로 한 무작위 배정 연구에서 참가자들은 익숙하지 않은 Python 라이브러리 Trio를 사용해 두 가지 코딩 과제를 수행했다. 절반은 코딩 환경에서 AI 도우미를 사용할 수 있었고 나머지 절반은 사용할 수 없었다. 참가자들은 이어서 퀴즈를 풀 것이라는 사실을 알고 있었다. 퀴즈는 과제를 마친 직후 개념 이해, 코드 읽기, 디버깅 능력을 평가했다.
AI를 사용한 집단의 평균 점수는 50%였고 AI 없이 작업한 집단은 67%였다. 차이는 17퍼센트포인트이지 상대적으로 17% 하락한 것이 아니다. 가장 큰 격차는 디버깅 문항에서 나타났다. AI 집단은 평균 약 2분 빨리 끝냈지만 시간 차이는 통계적으로 유의하지 않았다. 이는 한 가지 라이브러리를 잠깐 사용한 뒤 바로 시험한 결과이지, 개발자의 경력이나 실제 운영 시스템의 품질을 측정한 결과는 아니다. 연구진의 결과와 한계
연구진은 참가자들이 도우미를 어떻게 사용했는지도 살펴봤다. 일부는 코드 작성과 디버깅을 거의 통째로 맡겼고, 다른 이들은 설명을 요청하거나 개념을 직접 익히려 했다. 더 적극적으로 참여한 유형이 대체로 점수가 높았지만, 이런 소집단은 사후에 구분됐다. 참가자들은 AI를 사용하는 방식이 아니라 AI 사용 가능 여부에 무작위로 배정됐다. 설명을 요청하는 것이 학습자에게 도움이 될 수는 있지만, 이 연구는 특정 프롬프트나 작업 방식이 학습 격차를 막는다고 입증할 수 없다. 논문의 상호작용 분석
실수는 처음 접하는 사람이 라이브러리가 무엇을 전제로 하는지 배우는 순간인 경우가 많다. AI 도우미가 최초 구현과 수정까지 모두 맡으면 개발자가 그런 전제를 마주치는 일이 줄어들 수 있다. 이는 디버깅 점수 격차를 설명할 수 있는 한 가지 가능성이다.
속도도 중요하며 과제에 따라 답은 달라진다
다른 조건에서는 AI 보조가 코딩을 빠르게 하기도 했다. GitHub Copilot을 사용한 통제 실험에서 전문 프리랜서 95명은 JavaScript HTTP 서버를 만들도록 배정됐다. 과제를 끝낸 사람들만 보면 Copilot 집단은 평균 약 71분 만에 완료했고 대조 집단은 약 161분이 걸려 완료 시간이 55.8% 줄었다. 연구진은 그 프로그래머들이 이후 무엇을 배웠는지는 시험하지 않았다. 이 과제는 범위가 제한된 구현 작업이지, 낯선 라이브러리를 익힌 뒤 이해도를 묻는 퀴즈를 치르는 실험은 아니었다.
두 연구 결과는 관리자에게 각각 유용한 정보를 준다. 숙련된 개발자가 AI로 반복 작업을 줄인다면 시간 절약은 실제 성과일 수 있다. 새 시스템을 배우는 것이 목표라면 더 빠른 결과물과 더 깊은 이해도를 별도로 확인해야 한다. AI를 일괄 금지하면 잠재적 이점을 포기할 뿐, 사람이 작업을 감독하는 법을 어떻게 배울지에 답하지 못한다.
네델쿠의 에세이는 실험의 범위를 넘어선다. 그는 유지보수성이 수개월이나 수년에 걸쳐 드러나고 실수에 대한 책임을 맡으며 경험이 쌓인다고 주장한다. 이 연구는 장기적인 유지보수성을 측정하지 않았고 AI 사용자가 학습을 완전히 멈춘다는 점도 보여 주지 않는다. 그가 던지는 유용한 질문은 조직에 관한 것이다. 팀이 연습을 점점 더 많이 AI에 맡긴다면 미래의 문제 해결 담당자는 어디서 실전 경험을 쌓을까? 이 질문은 네델쿠의 에세이에서 제기됐다
코드가 실행된 뒤 학습자가 이해를 보여 줄 기회를 주자
실용적인 대응 방법 하나는 새로 온 직원에게 AI 보조 과제를 준 뒤 그 작업을 학습의 성과로 간주하기 전에 짧은 독립 점검을 요청하는 것이다. 이는 우리가 제안하는 연습이지 어느 연구에서 효과를 시험한 개입은 아니다.
- 설명하기: AI에게 묻지 말고 코드에서 낯선 부분이 왜 작동하는지, 무엇을 전제로 하는지, 어떤 조건에서 실패할 수 있는지 설명하게 한다. 선임 엔지니어는 실제 변경 내용에 관해 후속 질문을 하나 던질 수 있다.
- 진단하기: 안전한 테스트 브랜치에서 작고 현실적인 오류를 만든다. 학습자가 원인을 찾아내고, 그럴듯하지만 틀린 해결책을 어떤 관찰 결과가 배제했는지 말하게 한다. 목표는 명령어 암기가 아니라 추론이다.
- 수정하기: 요구 사항을 바꾼 다음 구현과 테스트를 수정하게 한다. AI를 사용해도 되지만 새로운 동작을 설명하고 무엇을 더 확인해야 하는지 말할 수 있어야 한다.
예를 들어 도우미가 비동기 작업을 새로 작성한 뒤 검토자는 작업이 중간에 취소되면 어떻게 되는지 물을 수 있다. 개발자는 실행 흐름을 짚고 변경된 요구 사항을 시험할 수 있어야 한다. 코드 검토만으로 결함을 찾더라도 학습자가 다음 문제를 해결할 수 없을 수 있다. 이 점검은 납품된 코드와 함께 지식도 전달되는지 묻는다.
그렇다고 모든 일상적인 작업 요청을 시험으로 만들 필요는 없다. 팀은 낯선 라이브러리, 반복되는 고장 유형 또는 나중에 주니어 동료가 책임질 업무에만 이 연습을 적용할 수 있다. 유급 시간과 시스템을 잘 아는 검토자가 필요하다. 경영진이 병합된 작업 수와 절약한 시간만 집계한다면 이런 비용부터 삭감할 수 있다. 그러면 오늘 결과물이 늘더라도 교육 문제는 더 어려워진다.
도제식 학습에 관한 질문은 채용과 제품 설계에도 이어진다
주니어 역할에는 업무 수행과 감독을 받는 연습이 함께 포함되는 경우가 많았다. 지원자가 추론 과정을 보여 주지 않고도 인상적인 기능 완성본을 제시할 수 있게 되면 AI는 그 교환 관계를 바꾼다. 고용주는 완성도 높은 저장소를 독립적인 역량의 증거로 여기기보다 지원자에게 작은 작업을 설명하고 수정하게 할 수 있다. 이는 제안하는 채용 방식이지 현재 채용 경향을 보여 주는 증거는 아니다. 모든 지원자에게 도구 없이 일하라고 요구할 것이 아니라 해당 직무에 필요한 능력을 평가해야 한다.
코딩 제품도 비슷한 선택에 직면한다. 도우미는 빠른 답변을 최적화할 수도 있고, 해법을 공개하기 전에 전제를 살펴보고 개념을 질문하고 변경을 시도하기 쉽게 만들 수도 있다. 연구에서 관찰된 상호작용 유형은 두 번째 설계를 시도해 볼 이유가 되지만, 특정 인터페이스가 학습 효과를 높인다는 점까지 입증하지는 않는다. 고용주가 도구를 구매할 때 물어야 할 것은 코드 생성량뿐 아니라 직원이 결과물을 검토하고 수정하는 법을 배우는 데 도움이 되는지다.
짧은 퀴즈만으로 5년 뒤 누가 전문가가 될지 알 수는 없다. 하지만 낯선 과제에서는 구현 결과를 받아들이는 일만으로 이해도를 입증하기 어렵다는 점을 보여 준다. 자동화와 유능한 차세대를 모두 원하는 팀은 연습할 시간을 마련하고 답이 바뀌었을 때 사람들이 무엇을 할 수 있는지 확인해야 한다.
