AI 코딩 도구가 전문성을 파괴한다
Coding expertise is going to collapse from AI reliance

AI 코딩 도구가 개발자의 전문성 형성을 어떻게 저해하는지 분석한 글입니다. JetBrains 연구와 UPenn의 1,000명 대상 연구를 인용하며, AI에 과도하게 의존한 주니어 개발자들이 '착각된 자신감'에 빠지고 문제 해결 능력이 저하된다고 주장합니다. 반면 AI를 제한적으로 사용한 개발자들은 더 나은 성과를 보였습니다. 저자는 AI를 '답변 생성기'가 아닌 '소크라테스식 대화 파트너'로 활용해야 진정한 학습이 가능하다고 강조합니다.
AI 코딩 도구로 가장 생산적인 학습이 일어나는 순간은 바로 그것이 코드를 거의 생성하지 않을 때라는 점에는 아이러니가 있다.
HN 토론
533- ryandvm
100% 맞는 말입니다.
우리는 이미 엔터프라이즈 레벨에서 이런 현상을 목격하고 있습니다. 회사들은 리더십 차원에서 "코드를 수작업으로 작성한다면 잘못하고 있는 것"이라는 지침을 내리고 있습니다.
좋아요, 그건 한동안은 효과가 있습니다. 우리는 확실히 엄청난 양의 코드를 생산하고 있지만, 현실은 엔지니어들이 인간이 이해하고 (솔직히) 검토할 수 있는 속도보다 더 빠르게 코드를 쏟아내고 있다는 것입니다. "이봐 Claude, 이 Jira 티켓 읽고 이 코드베이스에 기능을 구현해줘"가 정말로 연봉 20만 달러의 가치가 있다고 생각하기 전까지는 그럴듯해 보입니다.
이 모든 것은 반대 방향에서도 현실 감각을 잃어가고 있다는 사실로 인해 더 복잡해집니다. 리더십이 AI 생성 선언문을 제품 오너에게 에어드롭하고, 제품 오너는 AI를 사용하여 그 모든 것을 10%는 필요한 기능 작업이고 90%는 LLM 보일러플레이트인 1,500단어짜리 Jira 티켓으로 변환해야 하기 때문입니다.
그래서 이제 소프트웨어 엔지니어의 직업은 급격하게 바뀌어서, 소프트웨어 엔지니어가 되는 데 가장 어려운 부분은 단지 기능 하나를 출시하기 위해 모든 방향에서 쏟아지는 AI 생성 산출물을 걸러내는 일이 되었습니다.
- xyzelement
// 장기적인 기술 형성에 있어 지속적인 마찰의 필요성.
기사의 부제목이 모든 것을 말해줍니다.
어떤 사람들은 마찰을 찾아다닙니다. 운동선수나 하드코어 덕후를 생각해 보세요.
최고의 엔지니어들은 어린 시절 컴퓨터와 학습에 매료되어 모든 기회를 통해 그것을 추구한 사람들입니다. 즉, 스스로 마찰을 찾은 사람들입니다.
그런 사람들에게 마찰 추구는 상수이며, LLM이 한 일은 마찰이 발생하는 지점을 옮긴 것입니다.
예를 들어, 제가 함께 일한 최고의 엔지니어들은 반드시 어셈블리 코딩 경험이 많지는 않았습니다. 그런 종류의 마찰은 더 이상 필요하지 않았기 때문입니다. 하지만 그들은 어려운 문제를 해결할 수 있었습니다 (그리고 문제가 정말로 어셈블리를 요구한다면 배울 수 있었습니다).
AI가 훨씬 더 크게 타격을 줄 것이라고 생각하는 것은 하위 티어 엔지니어입니다. 진정으로 호기심이 없고 헌신적이지 않아서 그저 직업으로만 여겼던 사람들, 예를 들어 전형적인 오프쇼어 티켓 처리 담당자 같은 사람들입니다. 그런 사람들은 결코 마찰을 찾아 나서지 않았고, 그런 종류의 사람은 다시는 통하지 않을 것입니다. 평범하거나 평균적인 수준을 원한다면 LLM으로 충분합니다.
- LandoCalrissian
LLM 소프트웨어 개발에서 뱀이 자기 꼬리를 먹는 상황은 언급될 때마다 어깨를 으쓱하는 반응을 얻고 있습니다. 기껏해야 AI로 뇌를 태우지 않는 소수의 개발자 그룹이 있을 뿐인데, 그들의 보상은 뇌를 태운 사람들이 작성한 끔찍한 AI 코드를 검토해야 하는 일인 것 같습니다.
완전히 지속 불가능합니다.
- TonyAlicea10
기술 교육자로서 저는 100% 동의합니다. LLM은 우리가 더 이상 코드에 대해 걱정할 필요가 없는 "새로운 컴파일러"가 되지 않을 것입니다. 결정적 시스템을 신뢰하는 데는 이유가 있습니다.
저는 이것에 대해 많이 걱정해 왔고, 실제로 do-i-understand라는 에이전트 스킬을 만들었습니다. 이는 초보 개발자(그리고 위축 때문에 경험자도)를 위해 설계된 것으로, LLM이 제출하려는 PR에 대해 질문을 던집니다. 많은 도움이 된다는 것을 발견했습니다: https://github.com/AnthonyPAlicea/skills/blob/main/skills/do...
어떤 식으로든, 스킬에 대한 재앙이 올 것입니다.
- aledevv
인지적 마찰이 학습의 원동력이라는 개념에 강력히 동의합니다.
무엇보다도, 이것은 "의존성"의 문제입니다: 논리와 추론의 "근육"을 훈련하지 않으면 사용하지 않는 신체 근육처럼 점차 위축됩니다. 한때 자신이 가졌던 능력을 대체하는 외부 도구에 의존하게 되는 것입니다.
비슷한 변화를 가져온 역사적 예가 있습니다: 생산 과정이 장인의 머리와 손에서 포드주의 공장(및 조립 라인)으로 옮겨갔을 때, 무언가를 만드는 기술은 인간의 장인 정신에서 익명의 구조화된 프로세스로 옮겨갔습니다.
조금씩, 전통 장인들은 그들의 지식과 "노하우"를 잃었습니다. 오늘날 우리 집에 가구가 있다는 것은 대규모 생산 및 공급망에 의존합니다. "평범한" 사람은 더 이상 스스로 그것을 만들 능력이 없습니다.
소프트웨어에도 정확히 같은 일이 일어나고 있습니다.
우리는 (이제 "전직"이 된) 소프트웨어 장인들입니다.
- oscillonoscope
저는 AI의 가장 가능성 있는 결과는 제너럴리스트를 촉진하는 것이라고 믿습니다: 도메인 전문성을 가지고 있고, 학제 간 작업을 할 수 있으며, LLM을 올바른 방향으로 유지할 수 있을 만큼의 프로그래밍 지식을 가진 사람들입니다. 지난 10년만큼 '순수' 소프트웨어 엔지니어의 가치가 높게 평가되지는 않을 것이라고 생각하지만, 다른 분야에서도 마찬가지일 것이라고 생각합니다. 예를 들어, 신호 처리에서는 일반적인 알고리즘을 설계하는 사람과 임베디드 시스템에 알고리즘을 구현하는 데 전념하는 사람이 따로 있는 것이 드문 일이 아닙니다. 코딩 에이전트의 품질로 인해 더 이상 두 사람 모두 필요하지 않게 되었습니다. 두 분야 모두에 적당히 경험이 있는 사람이 이제 그 일을 할 수 있습니다.
- vain
슬프게도 매우 사실인 것 같습니다.
바로 어제 저는 약간 까다로운 자바스크립트(제 주 언어가 아님)를 구현하고 있었습니다. 호버 시 각 측면에 n개의 이웃을 표시하고, 한쪽에 부족이 있으면 다른 쪽으로 확장하는 것이었습니다. 오프셋을 정확히 맞추는 데 약 20분을 헤맨 끝에 에이전트에게 시키기로 했습니다.
저는 여전히 할 수 있다고 확신하지만, 예전 같으면 더 빨리 했을 텐데 그렇게 하지 못한 것에 대해 슬펐습니다. 위축이 이미 시작된 것 같습니다.
- 01100011
솔직히 말하면 이미 꽤 심각했습니다. 제 경험상 최고와 평균 사이에는 뚜렷한 차이가 있습니다. 상위 10% 정도의 코더는 보일러플레이트 접착 코드(여전히 필요하고 평균적인 코더가 하는 것이 더 나은)를 제외한 모든 면에서 다른 사람들보다 훨씬 뛰어납니다.
이것은 시스템/C/C++ 개발자로서의 제 경험에서 나온 말입니다. JS 웹 프론트엔드나 파이썬 개발자라면 이것이 당신에게 적용되는지 모르겠습니다.
- xtracto
네, 그리고 그것은 중요하지 않습니다.
프로그래밍 언어로 코드를 작성하는 것은 우리가 컴퓨터에게 원하는 것을 지시하기 위해 만든 기술/필요성입니다.
처음에는 60년대에 회로를 어떤 식으로든 연결하는 방식으로 이루어졌습니다 (ENIAC을 생각해 보세요). 그런 다음 우리는 "프로그래밍 가능한" 컴퓨터를 고안하고 그 케이블들을 추상화한 일련의 코드(컴퓨터 코드 명령)를 고안했습니다.
그런 다음 우리는 하드웨어 복잡성을 더 추상화하고, 인간 사이에서 더 전달 가능하지만 여전히 기계가 계산할 수 있는 방식으로 우리의 바람을 적을 수 있도록 프로그래밍 언어를 만들었습니다.
하지만 LLM과 신경망으로 인해 언젠가는 이러한 추상화가 필요 없게 될 것입니다.
컴퓨터는 여전히 계산을 수행하겠지만, 우리가 원하는 것을 전달하는 방식은 진화할 것입니다.
매우 흥미롭습니다.
- adamddev1
우리는 다양한 모델, 에이전트, 하네스, 오케스트레이션에 대한 연금술과 같은 실험에 대한 논의에 너무 많은 지적 시간과 에너지를 소비하고 있습니다.
그리고 AI에 대해 논쟁하거나 위험성이나 문제점을 설득하려는 데 엄청난 시간, 에너지, 글쓰기가 투자되고 있습니다.
슬프게도 이 모든 것이 실제 진전과 코딩/FP/PL/알고리즘/타입 이론 등에 대한 학습에 쏟을 수 있는 시간을 빼앗고 있습니다.