AI 코딩 도구가 '전문성 붕괴' 부른다… 신입 개발자 딜레마

AI 코딩, '전문가만 더 전문가 되게' 만든다

라르스 파예가 자신의 블로그에 올린 글 'Coding expertise is going to collapse from AI reliance'가 해커뉴스에서 519점, 댓글 510개를 모으며 개발자 커뮤니티를 뒤흔들었다. 핵심 주장은 단순하다. AI 코딩 도구는 전문성을 '민주화'하는 게 아니라, 이미 전문성을 가진 사람만 더 잘 쓰게 만든다는 것이다.

파예는 이를 '숙련된 오케스트레이터의 역설'이라 부른다. AI 에이전트를 다루는 데 필요한 기술(아키텍처 설계, 코드 리뷰, 명세 작성)은 곧 AI를 오래 쓰면서 쇠퇴하는 기술과 같다. 경력자는 수년간 '마찰'을 겪으며 쌓은 '좋은 취향'이 있어 AI를 검증·보정할 수 있지만, LLM 등장 이후 입문한 주니어는 그 마찰을 겪어본 적 없다. 그런데 업계는 "AI 안 쓰면 도태된다"며 이들에게 AI 사용을 강요한다.

제트브레인즈가 인용한 연구, "AI는 튜터가 아니었다"

제트브레인즈가 최근 소개한 연구 'The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers'는 이 역설을 데이터로 뒷받침한다. 라이브 코딩 세션에서 초보 개발자 행동을 분석한 결과다.

• 참가자들은 AI를 '개인 튜터'처럼 쓸 거라 기대했다. 데이터는 정반대였다.
• AI를 무제한·자신 있게 쓴 그룹은 '문제 해결의 핵심 단계를 건너뛰고 길을 잃었다.'
• AI 사용을 크게 제한하거나 무시한 초보자가 가장 좋은 성과를 냈다.

연구진은 이를 '역전 학습(inverted learning)' 모델이라 불렀다. 학생이 멘토(LLM)를 이끌고, 멘토가 응답하면 학생이 다시 이끄는 구조다. 그런데 학생이 모르는 영역에서는 '무엇을 물어봐야 할지도 모른다.' 나침반이 사용자가 가리키는 쪽을 북쪽이라 우기는 꼴이다.

해커뉴스 반응: "기타 페달만 잔뜩 산 연주자" vs "보안 엔지니어는 일거리 넘친다"

댓글 510개 중 몇 가지 전형적 입장을 추린다.

회의론
"우리 팀 AI 맥시멀리스트는 화려한 루프 돌려가며 토큰을 태운다. 좋은 기타와 앰프만 있으면 더 좋은 소리가 나는데, 페달만 잔뜩 사는 기타리스트 같다. 그게 취향 아닐까?" — 해커뉴스 사용자

"체스(완전 정보 게임)랑 현실을 비교하지 말라. 현실은 복잡도에서 몇 자릿수 차이다." — 해커뉴스 사용자

"전기 기사도 볼트·암페어 모르면 일 못 한다. 기초 모르는 엔지니어가 좋은 엔지니어인 분야가 있나?" — 해커뉴스 사용자

수용·전환론
"내 정체성이던 기술이 끝장난다는 상실감, 수용, 그리고 올해부터 AI 생성 소프트웨어로 어디까지 가능한지 밀어붙이고 있다. 내가 만들고 싶은 걸 만드는 게 불확실성의 해독제였다." — 해커뉴스 사용자

"보안 엔지니어다. 싸워야 할 새로운 위험이 넘쳐난다." — 해커뉴스 사용자

두 진영은 **'기초 이해 없이 AI만 의존해도 되는가'**에서 갈린다. 전자는 "아니다"라고 단정하고, 후자는 "내 분야(보안·아키텍처·취향)는 AI가 대체 못 한다"며 영역을 좁힌다. 사실 다툼(초보 학습 효과)은 연구가 어느 쪽 손을 들어줬는지 분명한데, 가치관 다툼(어떤 직무가 살아남을지)은 아직 열려 있다.

쉽게 풀어보면

라르스 파예가 이 문제를 제기했습니다. 뷔페에 비유하면 이렇습니다. 요리사(경력 개발자)는 재료 맛을 아니까 뷔페에서 좋은 것만 골라 멋진 한 상을 차립니다. 요리 배운 적 없는 사람(주니어)은 접시가 큰 줄 알고 아무거나 담아 오다가 배만 부르고 영양은 못 챙깁니다. 제트브레인즈가 인용한 연구는 이 비유를 데이터로 확인해 준 셈입니다. 초보자가 AI를 '척척박사 튜터'로 믿고 맡겨두면, 정작 코드 짜는 법을 안 배우고 헤맨다는 겁니다.

나에게 미치는 영향

취준·주니어 개발자

• 확인: 지금 쓰는 AI 챗에서 '이 코드 왜 이렇게 짜?'라고 물어보고, 답이 이해 안 되면 그 부분만 따로 공부하기
• 동작: 오늘부터 사이드 프로젝트 한 가지는 AI 없이 처음부터 끝까지 직접 짜보기

현업 개발자(경력 3년 이상)

• 확인: PR 리뷰 때 AI가 생성한 코드 비중이 50% 넘는지 세어보기
• 동작: 이번 주 리뷰부터 '이 로직 모르면 승인 안 함' 규칙을 팀에 제안하기

팀 리드·채용 담당자

• 확인: 신입 온보딩 문서에 'AI 사용 가이드라인(언제 쓰지 말지)'이 있는지 보기
• 동작: 다음 스프린트 계획에 'AI 금지 태스크' 하나 넣고 회고에서 학습 효과 비교하기

비개발 직군(기획·마케팅·영업)

• 확인: 사내 노코드·로우코드 툴에 AI 기능이 붙었는지, 교육 자료가 있는지 보기
• 동작: 다음 툴 도입 회의 때 '초보자가 이 기능 쓰다 실수하면 누가 책임지나' 묻기

남은 쟁점: '마찰'을 어떻게 다시 설계할까

파예는 글 말미에서 "이 도구들이 전문성을 요구하면서도 전문성을 키우는 마찰을 우회한다면, 전문가가 되는 길은 무엇인가"라고 묻는다. 연구는 'AI 제한'이 답이라 암시하지만, 업계 흐름은 'AI 전면 도입'으로 간다. 이 간극을 메우는 건 도구가 아니라 교육 과정과 조직 문화다. 제트브레인즈 같은 도구사가 '학습 모드(AI 차단·힌트만 제공)'를 IDE에 기본 탑재할지, 대학·부트캠프가 'AI 없는 코딩 주간'을 의무화할지가 다음 분기 관전 포인트다.