AI가 소프트웨어 엔지니어를 대체하지 않은 이유, 그리고 앞으로도 대체하지 못할 이유
AI가 소프트웨어 엔지니어를 대체하지 않은 이유, 그리고 앞으로도 대체하지 못할 이유
원문: normaltech.ai — Why AI hasn't replaced software engineers, and won't (GeekNews 번역)
한 줄 요약
AI 코딩 도구가 아무리 발전해도 소프트웨어 엔지니어를 대체하지 못한 이유는, 코드 작성 자체가 소프트웨어 개발의 병목이 아니었기 때문이다. 진짜 병목은 '무엇을 만들지 결정하는 것', '만든 것을 검증하고 책임지는 것', '코드베이스와 비즈니스에 대한 깊은 인간적 이해'이며, 이 세 가지는 당분간 AI 단독으로 해결하기 어렵다.
핵심 내용
1. AI를อ้าง한 대규모 해고는 'AI 워싱'에 가까움
기업들이 AI 생산성 향상을 이유로 해고를 발표했지만, 실제 데이터는 이를 뒷받침하지 않는다.
- Block 사례: Block(구 Square)이 AI로 950명 해고를 발표했지만, 실제로 AI가 도입된 부서는 거의 없었고 대부분 기존 비용 절감 계획이었다.
- Snap 사례: Snap이 AI로 1000명 이상을 해고했다고 발표했지만, 실제 AI 도입은 제한적이었다.
- Intuit 사례: Intuit는 AI 도입과 해고를 동시에 진행했지만, AI 도입 부서는 오히려 인력을 늘렸다.
- WARN Act 데이터(미국 대량해고 신고법): 2024-2025년 미국에서 AI를 이유로 신고된 해고는 전체 대량해고의 2% 미만이었다.
즉, 기업들은 AI를 해고의 정당화 도구로 활용했지만, 실제 해고의 주된 원인은 여전히 비용 절감, 사업 구조 조정, 시장 환경 변화였다.
2. 코딩 에이전트가 노동 대체로 이어지지 않은 이유: decide-execute-deliver 샌드위치
소프트웨어 개발을 세 층으로 나누면 다음과 같다.
- 결정 층(decide): 무엇을 만들지, 어떻게 설계할지 결정
- 실행 층(execute): 실제 코드를 작성
- 전달 층(deliver): 완성된 코드를 검증하고 배포하고 유지보수
AI가 가장 잘 하는 것은 실행 층이다. 하지만 실행 층이 전체 작업의 작은 부분을 차지한다는 것이 여러 연구에서 나타났다.
실제 병목 세 가지:
- 무엇을 만들지 결정하고 명세하는 것 — AI는 요구사항을 명확히 정의하지 못한다. 사용자가 "이 기능을 만들어줘"라고 해도, 무엇을, 왜, 어떻게 만들어야 하는지는 인간이 결정해야 한다.
- 전달된 것을 검증하고 책임지는 것 — AI가 만든 코드가 실제로 작동하는지, 보안상 문제가 없는지, 비즈니스 요구사항을 충족하는지는 인간이 확인해야 한다. 그리고 문제가 생겼을 때 책임질 주체가 필요하다.
- 코드베이스, 비즈니스, 환경에 대한 깊은 인간적 이해 — AI는 현재 코드베이스의 맥락, 팀의 문화, 비즈니스의 우선순위를 완전히 이해하지 못한다.
3. "코드 작성 vs 코드 출시" 증거
GitHub Copilot 사용자 데이터를 분석한 연구에서, AI가 작성한 코드의 비율이 높아졌지만 실제 코드 출시 속도는 크게 변하지 않았다. 코드를 더 빨리 쓸 수 있게 되었지만, 코드를 검토하고 통합하고 배포하는 과정이 새로운 병목이 되었다.
4. 소프트웨어 엔지니어는 크레인 운전사에 가까워짐
미래의 소프트웨어 엔지니어는 직접 코드를 작성하는 사람이 아니라, AI가 생성한 코드를 검토하고 방향을 제시하고 최종 결정을 내리는 역할에 가까워진다. 마치 크레인 운전사가 직접 벽돌을 쌓지 않지만 건설 현장에서 핵심적인 역할을 하는 것처럼.
5. 프로그래밍 축소는 AI만의 현상이 아님
역사적으로 프로그래밍은 계속 추상화되어 왔다. 어셈블리 → C → Java → Python → 고레벨 프레임워크 → AI 코딩 도구. 매번 "이제 프로그래머가 필요 없다"는 주장이 나왔지만, 오히려 더 많은 소프트웨어가 만들어졌다.
6. Vibe 코딩은 에이전틱 엔지니어링이 아님
Vibe 코딩(분위기 코딩): 사용자가 대략적인 아이디어만 말하면 AI가 코드를 만들어내는 방식. 간단한 프로토타입이나 개인 프로젝트에는 유용하지만, 실제 프로덕션 환경에서는 제한적이다.
에이전틱 엔지니어링: AI가 자율적으로 작업을 계획하고 실행하고 검증하는 방식. 아직 초기 단계이며, 인간 감독이 필수적이다.
두 가지를 혼동하면 AI의 실제 능력을 과대평가하거나 과소평가할 수 있다.
7. 앞으로 어떤 일이 생길까
대규모 해고가 일어나기 어려운 이유:
- 소프트웨어 엔지니어 수요는 계속 늘고 있다. 생산성이 높아질수록 더 많은 소프트웨어가 필요해진다.
- 역사적 패턴을 보면, 자동화 기술은 일자리를 없애기보다 일자리의 성격을 변화시킨다.
- Big Tech만이 커지는 것이 아니다. AI 도구 덕분에 소규모 팀과 개인 개발자도 더 큰 것을 만들 수 있게 되었다.
개인 경력에 대한 구조 변화:
- 기술 폭이 좁고 특정 영역(예: 프론트엔드 웹 개발)에 집중된 개발자는 더 큰 영향을 받을 수 있다.
- 제너럴리스트가 지휘하고 AI가 실행하는 형태로 특정 도메인이 완전히 흡수될 가능성은 꽤 높다.
- 비판적 사고를 유지하고 도구를 효과적으로 활용하는 개발자가 살아남는다.
HN 커뮤니티 반응
(281 점, 321개 댓글)
찬성: AI는 증폭기일 뿐, 대체가 아님
- jdauriemma: "AI를 가장 무비판적으로 믿는 사람들은 땜질하는 사람들이었다. LLM 보조 코딩 덕분에 뭔가를 만지작거리는 속도는 놀라울 정도로 빨라졌으니 그럴 만함. 땜질은 과정이고, 사람들은 만들고 조정하는 행위 자체에서 큰 즐거움을 얻음. AI는 우리가 행동할 능력을 크게 넓혔지만, 스스로 의미 있는 영향(엔지니어링)을 만들어내지는 못함. 활동보다 영향이 중요함."
- SoftTalker: "AI는 가능성을 제시하는 데 훌륭하지만, 혼자 방치하면 자신감满满으로 잘못된 길로 빠짐. 충분한 경험이 있는 사람이 아니면 이것이 일어나는지조차 알아차리지 못할 것. AI는 향상된 검색 엔진에 가까움."
- tsunamifury: "컴퓨터가 비서를 대체했는가? 대체했지만, 그 대신 스프린트 플래너, 오피스 운영 등 더 고급화된 역할이 진화했다. 하지만 아직 어떤 AI 모델도 검토 없이 바로 출시 가능한 코드를 만들어내지 못함."
반대: AI는 이미 대체를 시작했음
- DarkVanilla: "아내가 AI에게 대체됨. 프로그래머였고, 회사가 공개적으로 아내와 몇 명을 대체할 목적으로 에이전트를 만들었음. 작동하기 시작한 지 약 한 달 뒤에 해고했음."
- mteoharov: "개발 에이전시에서 1년 반 동안 에이전트 기반 개발을 사용해옴. 예전에는 5명이 하던 프로젝트를 이제 1-2명이 함. 현실적으로 그린필드 프로젝트는 상당 부분 자동화됨. 머릿속으로 이해할 수 있다면 100분의 1 시간에 세상에 내놓을 수 있음."
- aenis: "AI를 수백~수천 시간 사용한 사람과 그렇지 않은 사람의 격차가 큼. 내 주변에서는 프로덕션 코드를 몇 달째 출시 중이며, 새로 시작하는 IT 프로젝트는 훨씬 작은 팀으로 진행됨."
핵심 논쟁: '대체'의 정의
- criley2: "비기술 사용자가 AI로 만든 프로젝트는 대체가 아니라 '순수하게 새로운 프로젝트'임. 그 친구들이 개발자를 고용했을 것이란 가정 자체가 잘못됨. 기술 효율성 향상이 소프트웨어의 총량 풀을 확장하는 것은 소프트웨어에서 흔한 현상임."
- fsloth: "그 친구들이 소프트웨어 엔지니어를 고용했거나, 고용했을 것이라고 증명해야 '대체'라고 말할 수 있음."
- pocksuppet: "AI가 너를 대체할 필요는 없음. 그냥 너의 상사가 AI가 대체한다고 믿게 하면 됨."
AI의 한계 지적
- nicce: "GPT 5.5로 날짜 정렬을 바이브 코딩했는데, 문자열 비교로默认排序을 해서 최신순이 아닌 알파벳순으로 정렬되는 버그가 발생. LLM은 여전히 문맥적 이해가 부족함."
- altern8: "vibe 코딩은 일회용 프로토타입에는 좋지만, 영구적으로 유지보수해야 하는 금융 앱이나 레거시 시스템에는 적합하지 않음."
- _the_inflator: "AI의 맹점이 코볼 같은 레거시 언어가 아니라, React나 JavaScript, Python은 AI에게 초보 수준 기술임. 2050년이 되어도 React 앱을 고칠 필요가 없을 것 — 새로 만드는 것이 더 쉽고, AI가 구닥다리를 이해하며, 누가 2050년의 기술을 알겠는가?"
책임과 검증의 중요성
- lonelyasacloud: "아직 어떤 벤더도 에이전트의 작업에 대한 보장을 제공하지 않음. 따라서 합리적인 조직은 에이전트가 한 일에 대해 검토하고 승인할 신뢰할 수 있는 사람이 필요함. 법률은 변호사, 의사는 의사, 소프트웨어는 소프트웨어 엔지니어."
- logicchains: "Anthropic이나 OpenAI는 AI 직원이 실수를 했을 때 너를 고소하게 해주지 않을 것임. 책임 소재가 명확한 사람이 핵심 위치에 있는 것은 조직 운영의 중요한 부분이며, 이는 강력한 경쟁 우위임."
새로운 시각: '매크로 제품 경제'
- mteoharov: "이제 모두가 초능력을 얻었음. 꼭 회사에서 일할 필요도 없고, 1인 개발자가 엄청난 것을 만들 수 있으니 다른 사람에게 의존할 필요도 예전만큼 없음. 어쩌면 미래는 각자가 세상에 고유한 무언가를 제공하는 '매크로 제품 경제'일지도 모름."
새로운 시각
1. '대체' vs '새로운 수요 창출'의 구분
HN 댓글에서 가장 흥미로운 논점은 AI가 만든 소프트웨어가 기존 개발자의 일을 '대체'한 것인지, 아니면 '새로운 수요'를 창출한 것인지이다. 비기술 사용자가 AI로 만든 프로젝트는 대체로 그 사람 자체가 개발자를 고용할 예산이나 의도가 없었던 경우가 많다. 이는 AI가 일자리를 뺏는 것이 아니라, 기존에 존재하지 않았던 소프트웨어를 만들어내는 것이라고 볼 수 있다. 마치 3D 프린터가 모든 제조업을 대체하지는 않지만, 개인이 소량 제작을 할 수 있게 해준 것과 같다.
2. 정확성 스펙트럼
웹 개발과 로켓 항법 코드는 완전히 다른 위험 수준을 가진다. 웹 개발은 '대충 돌아가면 됨'의 여지가 있지만, 항공우주나 의료 기기 코드는 절대 그렇지 않다. AI는 두 영역 모두에서 코드를 생성할 수 있지만, 후자를 바이브 코딩으로 만드는 사람은 당분간 없을 것이다. 이는 AI 대체가 모든 소프트웨어 분야에 균일하게 적용되지 않음을 의미한다.
3. 코딩이 저렴해지면 오히려 상류 검증이 느슨해질 수 있음
pramodbiligiri의 지적이 흥미롭다. 현재 '결정'과 '검증' 층이 두꺼운 이유는 코딩이 비싸서 코드의 입력과 출력을 철저히 관리했기 때문일 수 있다. 코딩이 빠르고 저렴해지면, 출력물을 버리고 다시 만드는 것이 더 싸질 수 있고, 따라서 상류에서 같은 수준의 감독이 필요하지 않게 될 수 있다. 즉, AI가 발전할수록 '결정 층'이 오히려 얇아질 가능성도 있다.
4. AI 코딩 도구의 '마법 슬롯머신' 현상
christkv가 지적하듯, 많은 개발자가深夜에 "한 번 더 시도해보자"는 마인드로 AI 코딩 도구를 사용하고 있다. 이는 도구의 실제 한계를 이해하지 못한 채 과대평가하는 현상이다. 관리자들은 이를 '마법 블랙박스'로 보고 한계를 이해하지 못한다. 이는 과거 '로커스타 개발자' 신화에 crack(과다자극)을 더한 것과 같다.
자녀/미래 영향
아인, 석현, 은한에게 주는 시사점
- 코딩 기술 자체보다는 '문제 정의 능력'이 중요해진다: AI가 코드를 작성할 수 있는 세상에서, 무엇을 만들어야 하는지, 왜 만들어야 하는지를 정의하는 능력이 가장 귀해진다. 아이들이 프로그래밍을 배운다면, 코드 작성 연습보다는 '문제를 어떻게 분해하고 명세할까'에 집중하게 하는 것이 더 유용할 것이다.
- 도메인 지식 + AI 활용 = 강력한 조합: 의료, 법률, 교육 등 특정 도메인에 대한 깊은 이해를 가진 사람이 AI 코딩 도구를 활용하면, 그 도메인에서 매우 강력한 위치를 차지할 수 있다. 예를 들어, 의사이면서 AI 코딩을 할 줄 아는 사람은 헬스케어 소프트웨어를 직접 만들 수 있다.
- 비판적 사고가 최우선: AI가 생성한 코드를 검토하고, 방향을 수정하고, 최종 결정을 내리는 능력이 핵심 역량이다. 아이들에게 'AI가 한 것을 무조건 믿지 말라'는 교육이 중요하다.
- 1인 개발자의 시대: AI 도구 덕분에 개인이 큰 소프트웨어를 만들 수 있게 되었다. 아이들이 소규모 프로젝트를 통해 자신의 아이디어를 세상에 내놓는 경험을 일찍부터 할 수 있다면, 이는 큰 경쟁력이 될 것이다.
- 특정 기술에 너무 집중하지 말 것: 프론트엔드 웹 개발처럼 AI가 쉽게 흡수할 수 있는 좁은 도메인보다는, 넓은 시야를 가지고 여러 도메인을 넘나드는 제너럴리스트가 더 안전할 수 있다.