AI가 소프트웨어 엔지니어를 대체하지 않은 이유, 그리고 앞으로도 대체하지 못할 이유

• 소프트웨어 엔지니어링은 AI 도입이 빠른 직군이지만, AI가 일정 능력에 도달하면 대규모 해고가 발생한다는 서사는 현재 증거로 지지되지 않음
• Block, Snap, Intuit 사례에서 AI는 해고 명분으로 등장했지만, 실제 배경은 재무 압박, 비용 절감 요구, 관리 계층 축소와 더 직접적으로 연결됨
• 소프트웨어 개발은 결정·실행·전달의 샌드위치 구조이며, AI는 실행 층을 압축하지만 무엇을 만들지 정하고 결과를 검증·책임지는 층은 자동화에 강하게 저항함
• “vibe coding”은 감독·검토 없이 에이전트에 맡기는 방식이고, 실제 엔지니어들은 인간이 통제와 책임을 유지하는 agentic engineering 방식으로 에이전트를 사용함
• AI로 소프트웨어 생산 비용이 낮아지면 더 많은 소프트웨어 수요가 생길 수 있으며, 개별 엔지니어의 경력은 흔들릴 수 있어도 전체 수요는 강하게 유지될 가능성이 있음

AI가 소프트웨어 엔지니어를 대체하지 않은 이유, 그리고 앞으로도 대체하지 못할 이유

• Coding agents as normal technology

  • AI가 일자리를 대체할지에 대한 불안과 불확실성은 크지만, 이 문제를 보려면 AI 능력과 도입이 빠르게 진행된 소프트웨어 엔지니어링 직군을 살펴볼 필요가 있음
  • AI 능력이 특정 임계점에 도달하면 대규모 해고가 발생한다는 서사는 충분한 증거로 기각할 수 있음
  • 규제 장벽이 거의 없는 부문에서도 대규모 해고 서사가 성립하지 않는다면, 다른 직업군은 더 큰 완충 장치를 가질 가능성이 있음
  • 지식 노동과 소프트웨어 개발은 decide-execute-deliver sandwich로 볼 수 있으며, AI는 실행 층을 압축하지만 결정과 전달 층은 능력 향상만으로 자동화되지 않음
  • 소프트웨어 엔지니어링 수요의 미래는 조심스러운 낙관이 가능하지만, 전체 수요가 건강해도 개인 엔지니어의 경력은 불안정할 수 있음

소프트웨어 분야의 AI발 대규모 해고 사례는 전형적인 “AI washing”에 가까움

• Block 사례

  • Block은 2월에 직원 4,000명 해고를 발표했고, Jack Dorsey는 AI가 “더 작고 평평한 팀”을 가능하게 한다고 말하며 2025년 말 모델 능력 향상을 언급함
  • 이후 보도는 Block이 팬데믹 기간 인원을 세 배 이상 늘린 뒤 강한 재무 압박을 받고 있었다는 다른 그림을 보여줌
  • Cash App 팀 데이터 과학자 Naoko Takeda는 Block이 AI를 모두에게 강요했지만 생산성 향상은 매우 제한적이었다고 썼고, 75% 잔류 인상안을 거절하고 퇴사함
  • 인터뷰에 응한 다른 직원들은 Block에서 AI가 무엇을 할 수 있는지와 Dorsey가 쟁점을 제대로 이해했는지에 대해 크게 다른 인식을 갖고 있었음
  • Aaron Levie는 CEO들이 빠른 프로토타입은 만들 수 있지만 완제품으로 만드는 데 필요한 90%의 작업을 보지 못해 AI 효용에 대한 착각에 빠지기 쉽다고 지적함

• Snap 사례

  • Snap은 4월에 약 1,000명을 해고했고, Evan Spiegel은 해고 메모에서 AI를 주요 이유로 들었음
  • Spiegel은 신규 코드의 65% 가 AI로 생성됐다고 말함
  • 실제 해고는 비용 절감을 요구한 행동주의 투자자의 캠페인 이후 발생함
  • Snap은 2017년 IPO 이후 매년 순손실을 냈고, 2026년 주가는 30% 이상 하락함
  • 감원 성격은 증강현실 부문에서 다양한 직무 150개를 줄이는 방식이었고, AI가 원인이라면 예상되는 전사적 프로그래밍·AI 노출 직무 감원과 맞지 않음

• Intuit 사례

  • Intuit은 5월에 3,000명 감원을 발표했고, Anthropic 및 OpenAI와의 계약도 함께 알려짐
  • 언론은 이를 AI 중심 구조조정으로 연결했지만, CEO는 감원이 AI와 관련 없다고 반박함
  • 감원 대상은 “조정이 많은 역할”과 과도한 관리 계층이었다고 밝힘
  • Block, Snap, Intuit 사례는 AI가 해고의 표면적 명분으로 쓰이지만 실제 조직 사정과 비용 구조가 더 직접적인 배경이었음을 보여줌

• AI washing은 경제 전반의 현상임

  • 검토한 AI발 소프트웨어 엔지니어링 해고 이야기마다 같은 방식의 서사 불일치가 나타남
  • 미국 채용 관리자 59%는 채용 동결이나 해고를 설명할 때 재무 제약보다 AI를 강조하는 편이 이해관계자에게 더 잘 받아들여진다고 인정함
  • Forrester의 J. P. Gownder는 AI발 해고를 준비하는 기업에 성숙하고 검증된 AI 앱이 있는지 물으면 열에 아홉은 없고 시작도 하지 않았다고 말함
  • HBR 조사에서 전 세계 임원 1,000명 이상 중 21%는 AI를 “예상해” 대규모 인원 감축을 했고, 39%는 낮거나 중간 수준의 선제 감축을 했음
  • 실제 AI 구현과 관련해 이미 대규모 인원 감축을 한 비율은 2%였고, 이는 예상 기반 감축과 실제 구현 기반 감축 사이에 큰 간극이 있음을 보여줌

• WARN Act 데이터

  • WARN Act는 100명 넘는 노동자에게 영향을 주는 사업장 폐쇄와 대규모 해고에 특정 공시를 요구함
  • 뉴욕주는 2025년 3월 미국 주 가운데 처음으로 WARN Act 제출 양식에 AI 공시 체크박스를 추가함
  • 첫 1년 동안 160개 넘는 기업이 WARN 통지를 제출했지만, AI 박스를 체크한 기업은 하나도 없었음
  • 5월 말 기준 뉴욕 노동부 확인으로는 Nespresso 한 곳만 체크박스를 선택함
  • 제출 자료가 정확하다면 해당 기간 뉴욕주 해고자 약 25,000명 중 AI 영향을 받은 인원은 46명, 약 0.2%였음

• 해고는 AI 생산성 효과를 보는 잘못된 신호임

  • AI 생산성 효과는 기존 직원을 더 많이 해고하는 방식보다 채용 둔화를 통해 작동한다는 연구 결과가 있음
  • 기존 직원을 해고하면 AI를 효과적으로 쓰는 데 필요한 암묵지와 조직 자본을 잃게 됨
  • 해고는 퇴직금, 사기 저하, 재채용 위험 측면에서도 비용이 큼
  • 자연 감소만으로도 몇 년 안에 같은 결과를 얻을 수 있어 대규모 해고는 대체로 불필요함

• 고용 추세 데이터

  • Federal Reserve 경제학자들의 논문은 미국 맥락에서 관련 증거를 종합함
  • 고용은 여전히 증가하고 있지만, ChatGPT 이후에는 AI가 없었을 반사실적 경로보다 연간 약 3%포인트 느리게 성장함
  • 이 연구 방법론은 자영업을 포착하지 못해 성장 둔화 일부가 창업으로 흡수됐을 가능성이 있음
  • 다른 연구들은 AI가 창업을 더 쉽게 만든다는 증거를 제공함
  • 실제 그림은 Federal Reserve 연구가 보여주는 것보다 더 건강할 수 있음

• 실제로 존재하지만 다른 유형의 AI 관련 일자리 손실

  • AI가 제품 수요를 줄이는 경우에는 소프트웨어 엔지니어링 일자리 손실이 발생할 수 있음
  • Chegg와 Stack Overflow는 AI가 숙제 도움이나 기술 도움 제품 수요를 줄인 사례로 제시되며, 두 회사 모두 해고를 했음
  • 이 경우 AI가 노동자의 업무를 직접 수행한 것이 아니라 그 업무의 필요성을 줄였음
  • 1950년 미국 인구조사의 270개 직업 중 자동화로 사라진 직업은 엘리베이터 운전원 하나였지만, 전신 기사처럼 신기술로 불필요해진 직업은 여럿 있었음
  • AI를 구매하는 기업이 아니라 판매하는 IBM이나 SAP 같은 기업의 해고는 노동자 대체보다 기존 기능에서 빠르게 성장하는 제품 라인으로 인력을 재배치하는 일반적 기업 구조조정에 가까움

코딩 에이전트가 노동 대체로 이어지지 않은 이유: decide-execute-deliver sandwich

• AI가 작성한 코드 비율은 노동 대체와 거의 연결되지 않음

  • 일부 기술 리더들은 AI가 작성한 코드 비율을 해고나 미래 일자리 감소 전망과 함께 제시함
  • 이 방식은 AI가 모든 코드를 쓰면 코더가 필요 없어진다는 단순한 사고방식을 강화함
  • 하지만 AI 작성 코드 비율은 노동 대체를 판단하는 핵심 지표와 거의 무관함
  • 코드 작성은 병목이 아니었고, 과거에도 병목이 아니었음

• 코드 작성은 병목이 아니었음

  • 2019년 논문은 기존 연구를 종합해 개발자가 코딩에 쓰는 시간이 연구에 따라 9%에서 61%로 놀랄 만큼 적다고 결론 내림
  • 이 결과는 Microsoft 개발자 6,000명의 자체 데이터와도 일치함
  • 코딩 에이전트 도입이 시작된 뒤 2025년 말 여러 글은 코드 작성이 병목이 아니라고 지적함
  • 개발자들은 에이전트가 코드 대부분을 쓰게 해도 전체 생산성에 미치는 영향이 작다는 점을 인식함

• 실제 병목 세 가지

  • 실제 병목은 무엇을 만들지 결정하고 명세화하는 일임
  • 전달된 결과를 검증하고 책임지는 일도 핵심 병목임
  • 코드베이스, 비즈니스, 환경에 대한 깊은 인간 이해는 결정과 전달 모두에 필요함
  • 소프트웨어 엔지니어의 일은 결정·실행·전달의 샌드위치이며, 이해는 세 층 모두의 전제 조건임
  • AI는 샌드위치의 가운데를 압축했지만 양끝은 대체로 그대로 남겼음

• “Writing Code vs. Shipping Code” 증거

  • Writing Code vs. Shipping Code는 GitHub 개발자 100,000명을 대상으로 AI 생산성 효과를 분석함
  • AI 에이전트는 작성된 코드 줄 수를 8배 늘렸고, 이는 실행 층이 크게 압축된다는 설명과 일치함
  • 릴리스 증가는 30%에 그쳤고, 이는 결정과 전달 층의 인간 병목이 여전히 남아 있음을 강하게 시사함

• 결정 층은 더 얇아지기 어려움

  • 개발팀은 무엇을 만들지 결정해야 함
  • 주니어 소프트웨어 엔지니어가 배우는 중요한 교훈 중 하나는 요구사항 명세가 예상보다 오래 걸린다는 점임
  • 요구사항 명세를 압축하면 이후 단계에서 더 큰 고통이 발생함
  • 이 층은 사용자 요구, 시장 신호, 조직 우선순위, 경우에 따라 규제 제약을 고려해야 하므로 자동화가 어려움
  • AI 능력이 향상되면 AI에 위임할 수 있는 결정의 종류는 늘어나지만, 위임 가능한 결정은 더 이상 경쟁우위의 원천이 되지 않음
  • 인간 의사결정의 가치는 더 상위 단계로 이동하며, 소프트웨어 복잡성은 시간이 지날수록 증가하므로 이 과정에 명확한 천장은 없음

• 전달 층은 책임과 검증 때문에 남아 있음

  • 인간 팀은 자신들이 전달하는 결과에 대해 책임져야 함
  • 미래 어느 시점에는 팀이 충분히 테스트하고 이해하지 않은 미션 크리티컬 코드를 배포할 수도 있음
  • 현재 AI는 매우 불안정해 그런 무질서한 방식은 소프트웨어 팀과 고객에게 실존적 위협이 됨
  • 기술 장벽이 사라져도 인간이 AI에 통제를 넘길 필요는 없음
  • 공유 규범, 법, 정책을 통해 인간 책임을 유지하는 선택이 가능함
  • 책임법과 부문별 규제는 이미 속도 장벽으로 작동하고 있으며, 더 강화될 수 있음

• 미래 소프트웨어 엔지니어는 크레인 운전사에 가까워짐

  • 실행 층이 더 많이 AI에 위임될수록 소프트웨어 엔지니어의 역할은 크레인 운전사와 비슷해짐
  • AI 에이전트는 인지적 무거운 작업 대부분을 수행하고, 인간은 에이전트를 감독하고 통제하는 일이 핵심 업무가 됨
  • 일부는 인간이 통제하는 미래가 비용 때문에 가능하지 않다고 주장함
  • 감독이 부족한 코딩 에이전트가 운영 데이터베이스를 삭제하거나 다른 피해를 낸 사례들이 이미 화제가 됨
  • 이런 사례들은 새 규범이라기보다 충격성 때문에 퍼지는 예외적 사건이며, AI 과의존을 경계하게 만드는 학습 계기가 됨
  • 고위험 작업에서 감독 부족 AI 사용이 증가하는지 감지하는 일은 소프트웨어 엔지니어링뿐 아니라 경제 전반의 중요한 데이터 공백임

• 프로그래밍 축소는 AI만의 현상이 아님

  • 샌드위치가 눌리는 추세는 새롭지만 AI만의 결과는 아님
  • 20년 넘게 전부터 Bureau of Labor Statistics는 프로그래밍과 소프트웨어 엔지니어링을 분리해 추적하기 시작함
  • 대략 프로그래머는 실행만 맡고, 소프트웨어 엔지니어는 샌드위치의 더 큰 부분을 관리함
  • 프로그래밍은 축소됐고, 단순 실행 업무로 여겨져 보수도 훨씬 낮음
  • AI는 오래된 추세를 가속하며 순수 기술 실행 능력의 가치를 더 낮춤
  • 인간이 결정과 전달 양끝에 깊이 관여하고 AI가 중간 실행층을 자동화하는 패턴은 지식 노동 전반에 넓게 적용될 수 있음

Vibe coding은 agentic engineering이 아님

• 용어 혼란

  • “vibe coding”이라는 용어가 넓은 범위의 관행을 가리키는 데 부정확하게 쓰이면서 소프트웨어 엔지니어링 변화에 대한 혼란이 생김
  • 실제 vibe coding에서는 사용자가 에이전트에게 할 일을 말한 뒤 실행 중 감독하지 않고 코드를 검토하지 않음
  • 이 사용자는 코드를 검토할 역량이 없을 수도 있고, 눈에 띄게 망가진 경우를 제외하면 결과를 평가하지 않을 수도 있음
  • 이는 대부분의 소프트웨어 엔지니어가 에이전트를 쓰는 방식과 다름

• Agentic engineering

  • 대부분의 소프트웨어 엔지니어는 인간이 결과에 대한 통제와 책임을 유지한 채 에이전트를 도구로 사용함
  • 이런 관행을 가리키는 용어로 agentic engineering이 확산되고 있음
  • agentic engineering이 표준이 되면서 엔지니어들은 코딩 에이전트 감독이 예상보다 시간이 많이 든다는 점을 발견함
  • Simon Willison은 에이전트를 감독하다 오전 11시쯤 정신적으로 지친다고 말했으며, 이는 실제 경험과도 일치함

• SWE-chat 데이터

  • SWE-chat은 로깅 도구에 자발적으로 참여한 오픈소스 개발자의 코딩 에이전트 상호작용 데이터셋임
  • 이 연구에서 에이전트가 만든 코드 중 사용자 커밋까지 살아남은 비율은 44%였음
  • vibe-coded 커밋은 인간만 작성한 커밋보다 취약점을 9배 높은 비율로 도입함
  • 가장 흔한 사용자 의도는 새 코드 생성이 아니라 기존 코드 이해였고, 비율은 19% 대 13%였음
  • 데이터셋이 자기선택 표본이므로 이 연구만으로 강한 결론을 내릴 수는 없음
  • 그래도 vibe coding과 agentic engineering이 서로 다른 패턴이라는 다른 증거들을 강화함

• 핵심 차이

  • vibe coding과 agentic engineering은 완전히 분리된 두 범주가 아니라 스펙트럼의 양끝임
  • 모든 프로젝트가 일회성 프로젝트나 미션 크리티컬 프로젝트로 나뉘지는 않음
  • 모든 워크플로가 표의 왼쪽 열이나 오른쪽 열에 정확히 맞지는 않음
  • 일자리 문제에서 중요한 함의는 기업이 검증되지 않은 vibe coder를 소프트웨어 엔지니어 대신 고용해 프로덕션 소프트웨어를 배포할 수 없다는 점임

앞으로 어떤 일이 생길까

• 대규모 해고 전망이 성립하기 어려운 이유

  • AI 옹호자들은 대규모 해고가 아직 오지 않았을 뿐이라고 주장할 수 있음
  • 하지만 샌드위치 모델이 맞다면 이런 예측은 실현되지 않음
  • AI는 이미 샌드위치의 중간 층을 크게 압축했고, 이 압축은 실제로 수십 년 전부터 시작됐음
  • 실행 층이 즉각적이고 완벽해져도 현재 상태에서의 변화는 작음
  • 결정과 전달 층이 AI에 저항하는 이유는 능력 한계 때문이 아님

• 소프트웨어 엔지니어 수요는 늘어날 수 있음

  • AI 때문에 소프트웨어 엔지니어링 일자리가 사라지지 않을 뿐 아니라 수요가 늘어날 수도 있음
  • 기술 생산성 향상으로 소프트웨어를 만드는 비용이 낮아지면 사람들은 더 많은 소프트웨어를 구매함
  • 소프트웨어는 경제학 용어로 가격 탄력성이 높음
  • AI가 소프트웨어 엔지니어를 대체하지 않는다면, 더 많은 소프트웨어 수요는 더 많은 소프트웨어 엔지니어 파생 수요로 이어짐
  • “Jevons’ paradox”는 AI 담론에서 이 개념을 설명하는 데 자주 쓰이는 경제학 용어임

• 역사적 패턴

  • 미국의 프로그래머 고용은 1950년 무렵 거의 0에 가까웠지만 오늘날 수백만 명으로 증가함
  • 이는 기계화와 자동화로 노동 수요가 크게 줄어든 농업 같은 직업과 크게 다름
  • 사람의 칼로리 소비량은 상대적으로 고정되어 있지만, 생산되는 소프트웨어 양은 백만 배 증가함
  • 현대 자동차에는 여러 온보드 컴퓨터에서 작동하는 약 1억 줄의 코드가 들어감
  • 코드 수요에 천장이 있다 해도 현재는 그 근처에 있지 않음
  • 거의 모든 인지 업무는 소프트웨어의 혜택을 받으며, AI가 코딩 비용을 낮추면서 업무용·개인용 일회성 유틸리티가 만들어지고 있음

• Big Tech만 커진다는 뜻은 아님

  • 미래에 소프트웨어가 훨씬 많아지고 소프트웨어 엔지니어도 늘 가능성이 있지만, 대형 기술 기업이 더 커진다는 뜻은 아님
  • 오늘날 소프트웨어 엔지니어의 다수는 이미 비소프트웨어 기업의 내부 조직에서 일함
  • 이 비중은 앞으로 더 커질 수 있음
  • “AI rollups”는 벤처캐피털이나 사모펀드가 치과, 회계법인 같은 Main street 사업을 사들인 뒤 소프트웨어 엔지니어나 AI 엔지니어를 넣어 AI-native로 다시 만드는 구상을 가리킴
  • 이 구상은 단순한 과대광고로 끝날 수도 있으며, 아직 판단하기 이름

• 민주화 예측에 대한 반론

  • 일부는 AI가 소프트웨어 엔지니어링을 민주화해 소프트웨어 엔지니어링 수요가 줄어들 것이라고 예측함
  • 이들은 생산되는 소프트웨어와 소프트웨어 생산에 쓰이는 인간 시간이 모두 늘지만, 그 일을 소프트웨어 엔지니어가 아닌 사람이 할 것이라고 봄
  • 예를 들어 법률 소프트웨어는 소프트웨어 엔지니어링 훈련보다 법률 훈련을 받은 사람이 더 쉽게 만들 수 있다는 생각임
  • 이런 주장은 vibe coding과 agentic engineering, 실행 층과 전체 샌드위치를 혼동하는 함정에 빠짐
  • FORTRAN, COBOL, SQL 같은 과거 언어도 등장 당시 프로그래밍 민주화 기대를 동반했지만, 그런 일은 일어나지 않았음
  • 장벽은 문법 학습이 아니라 책임을 유지하면서 좋은 결정을 내릴 숙련된 판단력임

• 개인 경력에는 큰 구조 변화가 올 수 있음

  • 시간이 지날수록 사람들이 컴퓨터로 새로운 일을 하게 만드는 데 쓰는 시간은 늘어날 가능성이 큼
  • 이 활동은 소프트웨어 구축, 에이전트를 활용한 복잡한 워크플로 관리, 또는 다른 형태를 취할 수 있음
  • 필요한 역량은 소프트웨어 기술, AI 기술, 도메인 전문성의 조합이 됨
  • 오늘날의 소프트웨어 엔지니어가 이런 새 역할에 가장 잘 적응할지는 아직 알 수 없음
  • 전체 소프트웨어 노동 수요가 강하더라도 개인 노동자가 영향을 받지 않는다는 뜻은 아님
  • AI는 소프트웨어 생산 방식에 큰 구조 변화를 만들고, 어떤 엔지니어가 이득을 보거나 손해를 볼지는 근무 기업 유형, 지역, 경력 수준, 적응 속도에 따라 달라짐