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

 (normaltech.ai)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 소프트웨어 엔지니어링은 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는 소프트웨어 생산 방식에 큰 구조 변화를 만들고, 어떤 엔지니어가 이득을 보거나 손해를 볼지는 근무 기업 유형, 지역, 경력 수준, 적응 속도에 따라 달라짐

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 컴퓨터 산업 역사 내내 우리는 소프트웨어 엔지니어링 자동화를 공격적이고 열정적으로 해왔고, 그때마다 더 크고 좋은 것을 더 빨리 만들 수 있게 됐음
    그렇게 생산성이 오르면 일의 가치도 커지고 기대치도 같이 올라갔으며, 지금까지 세계의 소프트웨어 수요는 끝이 없었음
    AI가 소프트웨어 엔지니어를 대체하지 못한 이유는 생산성이 올라갈 때마다 목표 지점도 함께 이동했기 때문임
    이 흐름이 끝나는 경우는 두 가지인데, 첫째는 마침내 세계의 소프트웨어 수요를 다 채울 만큼 생산성이 높아지는 것임
    아직 그런 증거는 보이지 않고, 이번이 컴퓨터 산업 전체 역사와 왜 다른지 명확히 설명해야 함
    둘째는 AI가 자율적으로 행동할 때 인간보다 뛰어난 소프트웨어 엔지니어가 되는 경우임
    즉 AI+인간 개발자가 AI 단독보다 더 낫지 않은 상태인데, 지금까지 증거는 AI가 개발자의 증폭기이며 좋은 결과를 내려면 전문가가 방향을 잡고 AI가 최대 90%를 하는 정도로 보임
    가까운 미래에 둘 중 하나가 일어날 강한 증거는 없어서 소프트웨어 엔지니어는 당분간 안전하다고 봄
    다만 기술 폭이 좁고 특정 영역, 예컨대 프런트엔드 웹 개발에 집중한다면 더 걱정해야 함
    AI가 소프트웨어 엔지니어 전체를 대체하지 못해도, 제너럴리스트가 지휘하는 형태로 특정 도메인을 완전히 흡수할 가능성은 꽤 높음

    • 소프트웨어의 종착점이 그리 멀지 않았다고 봄
      이미 전체적으로는 사람들이 정말 원하는 것보다 더 많은 소프트웨어를 만들고 있고, 그 상당수는 쓰레기에서 노골적 사기, 심지어 악성에 가까운 것까지 있음
      최종적으로는 할 일 목록 관리나 파일 동기화처럼 일반인이 필요한 작은 소프트웨어를 각자의 AI가 맞춤형으로 작성하게 될 것 같고, 소프트웨어 엔지니어는 큰 기업 프로젝트에만 남게 될 듯함
      지난 수십 년간 상용 소프트웨어의 압도적 추세는 극단적인 반사용자적 비맞춤화였음
      하나의 행복 경로만 남기고, 필요에 맞지 않으면 알아서 하라는 식이 됐음
      일상적인 사람들을 위한 상용 소프트웨어는 거의 없고, 오픈소스조차 일반 사용자에게서 멀어지는 중임
      곧 평범한 사람들이 자기 방식대로 문제를 해결하는 소프트웨어를 직접 만들 수 있게 될 것임
      대부분의 경우 품질과 정확성은 크게 중요하지 않고, 맞춤형이며 무료이고 침습적인 감시·광고 플랫폼이 아니라는 점이 더 중요함
    • 프런트엔드 웹 개발 예시는 좀 웃기게 느껴짐
      프런트엔드 개발자로서 현재 최첨단 모델은 내가 신경 쓰지 않는 지루한 뒤쪽 배관 작업은 잘하지만, 실제 고객이 원하는 맞춤형 디자인 작업은 아직 잘 못한다고 봄
      누가 확실히 맞고 틀렸다는 뜻은 아니고, 더 일반적인 기술 폭이 새 시대에 성공하는 최선의 방법이라는 데는 동의함
      다만 LLM이 스택의 어느 한 부분을 완전히 장악해서 그 분야 전문가가 사라질 정도는 아직 아님
    • “이런 일이 일어나는 증거가 보이지 않는다”는 말과 달리, 적어도 모바일 앱 스토어에서는 이미 비슷한 현상이 보임
      최근 분석에 따르면 출시 앱 수는 크게 늘었지만, 전체 리뷰 수와 다운로드 수는 정체되어 있음
      즉 앱은 훨씬 많아졌지만 사용자는 그다지, 혹은 거의 늘지 않았다는 뜻임
      "WRITING CODE VS. SHIPPING CODE: PRODUCTIVITY EFFECTS ACROSS GENERATIONS OF AI CODING TOOLS"의 p40 / figure 12를 보면 됨: https://www.nber.org/system/files/working_papers/w35275/w352...
      분석은 42~43쪽에 있음
      파이가 고정됐다는 걸 증명할 수는 없지만, 반대로 파이가 무한하다는 것도 증명할 수 없음
      소프트웨어의 경제 성장 이야기를 할 때 사람들이 놓치는 핵심은 돈이 어딘가에서 와야 한다는 점임
      계속 성장하려면 지금 소프트웨어에 돈을 내지 않는 누군가가 새로 지불을 시작해야 하는데, 그들이 누구이고 얼마를 갖고 있으며 어떤 다른 비용과 경쟁하는지 봐야 함
    • “세계의 소프트웨어 수요는 끝이 없었다”는 말이 모두가 최신 최고 기술을 찾는다는 뜻은 아님
      많은 기업은 여전히 맞춤 스프레드시트나 Microsoft Access 같은 기술에 의존함
      원하는 일을 정확히 해주고, 비용이 고정적이며, 추가 수정이나 유지보수가 거의 필요 없기 때문임
      우리가 갇힌 거품 밖으로 나가 보면 많은 사람이 업그레이드에 관심이 있는 게 아니라, 이미 아는 낡은 것이 그냥 계속 작동하길 원한다는 걸 알게 됨
    • AI가 전문가 지휘 아래 90%의 작업을 할 수 있다면, 그건 개발자의 90% 를 일자리에서 밀어낸다는 뜻임
      그리고 그 비율이 99%가 되지 못할 이유도 잘 모르겠음

  • AI는 분명 소프트웨어 엔지니어를 대체할 것임
    빠진 부분은 글에서 말하듯 전달·운영이고, 그건 소프트웨어 엔지니어보다 DevOps/SRE/Cloud 엔지니어의 영역임
    클라우드 엔지니어로 일하는데, 비엔지니어 친구 여러 명이 이제 각자 사이드 프로젝트를 처음부터 여러 언어로 만들고 로컬, 웹앱, 네이티브 앱으로 실행할 수 있게 됐다고 연락해옴
    그들에게 부족한 건 “보통 개발자”처럼 쉽게 배포하고 유지할 플랫폼임
    지금은 이 발판을 만드는 일이 꽤 번거롭지만, AGENTS.md, skills, 엄격한 종합 테스트로 충분히 가능함
    한 번 만들어두면 비기술 사용자는 claude/codex에 원하는 것을 말하는 방식으로 소프트웨어 엔지니어를 고용하지 않고도 계속 개발할 수 있음
    claude/codex는 미리 정한 아키텍처를 바탕으로 판단하고 비기술 사용자를 안내할 수 있음
    내 일화적 사례에서는 AI가 이미 여러 소프트웨어 엔지니어를 대체했음
    이런 발판이 제품화되면 그린필드 프로젝트는 에이전트 코더와 플랫폼 엔지니어링을 통해 제품 관점에서만 관리될 수 있다고 봄
    이것이 지금이고, 5년 뒤를 상상해보면 됨

    • 이런 추론은 잘 이해되지 않는데도 널리 퍼져 있음
      비엔지니어가 만든 앱을 들고 온다고 해서 AI가 소프트웨어 엔지니어를 대체했거나 대체할 것이라는 뜻은 아님
      증상을 Dr. Google로 찾아보고 생활습관 변화, 약초 요법, 일반의약품을 시도해서 실제로 효과를 볼 수 있지만, 그렇다고 의사가 사라지는 건 전혀 아님
      생성형 AI로 음악 이론도, 음악 감각도, 창의성도 없이 음악을 만들 수 있지만, 음악적 재능이 있는 사람들이 사라지는 것도 아님
      AI 도움으로 집안 DIY를 할 수 있어도 엔지니어가 사라지는 것은 아님
      도메인 전문가가 실제로 필요한 것을 프로토타입-개선 반복으로 명확히 하도록 누가 도울 것인가
      취미 소프트웨어 제작자들이 의존하는 운영체제, 언어, 버전 관리 시스템, 편집기와 터미널 에뮬레이터, 지식·문서 관리 시스템, PaaS 플랫폼 등은 누가 작성하고 유지할 것인가
      그들이 만든 것을 견고하다고 보장할 만큼 제대로 테스트했는가
      생길 수 있는 경계 조건을 이해하고 있는가
      보안은 괜찮은가
      프롬프트로 빠르게 뭔가를 만들어내는 것은 엔지니어링과 같지 않음
      소프트웨어 엔지니어링의 가치가 주로 산출된 코드, 즉 비트 배열 자체에 있다고 보는 오류 때문에 이렇게 보지 못하는 것일 수 있음
      프로젝트의 주된 가치는 이론과 추상화를 만들어가는 과정에 있음: https://pages.cs.wisc.edu/~remzi/Naur.pdf
    • 생성과 유지보수는 완전히 다른 짐승임
      2주짜리 앱을 만들고 다시는 손대지 않는 엔지니어도 있겠지만, 그런 걸로 생계를 유지하는 사람은 잘 모르겠음
      “당신의 사업을 위한 WordPress 사이트” 같은 일은 가능할지 모름
      문제는 기능이 432개 있는데 433번째 기능을 추가하면서 나머지를 건드리지 않아야 할 때 생김
      조금이라도 틀리면 안 되는 경우도 있고, 기능 하나가 엔지니어가 감당하는 속도보다 더 빠르게 복잡도를 늘려 시간이 지나며 프로젝트가 관리 불가능한 크기가 되는 경우도 있음
    • 우리 회사에서는 비기술 팀이 기술 팀의 과부하 때문에 스스로 도구를 만들기 시작했음
      큰 시스템과 연동되는 작은 애플리케이션 아이디어였고, 2~3일 만에 3~4커밋으로 개념 증명이 만들어졌음
      인상적이긴 했지만 만든 사람이 지난 3개월 동안 그 프로젝트에 400커밋을 더 했고, 수정이 이어지면서 사실상 그 앱을 만들고 유지하는 일이 파트타임 또는 풀타임 일이 됐음
      그 사람은 훈련받지 않은 소프트웨어 개발자가 됐고, 보안이나 모범 사례는 이해하지 못함
      Claude가 더 좋아지면 부담이 줄어 하루를 잡아먹지 않을 수도 있지만, 현재 우리 회사의 이런 초기 “바이브 앱”들은 모두 유지보수 업무가 되어 점점 더 많은 시간을 먹고 있음
      사람들은 소프트웨어를 덜 원하는 게 아니라 더 원한다는 게 분명함
      전통적 소프트웨어 엔지니어링은 사라질 수 있어도, 확장되는 플랫폼 관리, 보안, 복잡성, 문서화, 비즈니스 로직은 여전히 우리 회사 앞에 남아 있음
      텍스트로 프로젝트를 만들 수 있다는 말은 맞지만, 가장 단순한 소프트웨어가 아닌 이상 “설정하고 잊기”는 없었다고 느낌
      여전히 누군가는 전체를 관리해야 함
      그 사람이 소프트웨어 엔지니어링 훈련을 받았든 아니든 말임
      경험 있는 개발자는 여전히 훈련받지 않은 사람보다 더 잘할 가능성이 큼
      물론 호기심 많은 빌더들은 빠르게 따라잡겠지만, 전통적 개발자에게는 큰 우위가 있음
      우리는 늘 내부가 어떻게 작동하는지 알고 싶어 했기 때문임
      그들이 몇 달 걸려 만든 현재 바이브 앱은 AI를 쓰면 내가 한 시간 안에 만들 수 있었음
    • 소프트웨어 배포는 터미널에서 vercel을 실행하는 수준까지 내려왔고, 에이전트도 요청만 받으면 아무 문제 없이 할 수 있음
      데스크톱 소프트웨어 배포는 플랫폼에 따라 조금 더 어렵긴 함
      그래도 사이드 프로젝트와 훌륭한 소프트웨어 사이의 간극은 여전히 매우 넓고, 그 간극이 언젠가 메워질 거라고 믿기 어려움
      AI 이전에도 이미 풀린 문제가 먼저 대체되지 않을 이유가 뭔지 모르겠음
      개인 프로젝트에 복잡한 인프라가 필요하다고 믿기도 어렵다
    • AI 보조 코딩은 훌륭하지만, 바이브 코딩은 폐기 가능한 프로토타입에나 좋다고 봄
      무기한 유지해야 하는 금융 앱을 바이브 코딩으로 만들지는 않을 것임
      레거시 시스템도 건드리지 않을 것임
      AI가 일부 엔지니어를 대체한 것은 분명하지만, 비엔지니어 친구들이 사이드 프로젝트를 만든 사례는 관련성이 낮음
      이제 가능해졌기 때문에 만든 것이지, 원래 누군가를 고용해서 만들 예정은 아니었을 가능성이 큼
      지금까지 고용하지 않았던 것처럼 말임

  • 개발 에이전시에서 일하고, 고객 대부분은 빠르게 시장에 나가야 하는 스타트업임
    약 1년 반 동안 에이전트 기반 개발을 써왔고, 그동안 우리의 역할은 크게 바뀌었음
    프로젝트 유입량은 정확한 숫자를 몰라 말하기 어렵지만, 보이는 변화는 전달 가능 범위에 대한 기대치가 달라졌다는 점임
    예전에는 5명이 하던 프로젝트를 이제 보통 1~2명이 함
    현실적으로 그린필드 프로젝트는 상당 부분 자동화됐음
    UX/UI 디자인 반복, 시스템 아키텍처 반복, 명확한 측정 지표가 없는 어려운 문제에 여러 접근을 시도하는 등의 많은 수작업이 이제 즉시 일어남
    머릿속으로 이해할 수 있다면, 100분의 1 시간에 세상에 내놓을 수 있는 셈임
    이 기간 동안 일하는 방식과 시스템을 생각하는 방식도 많이 바뀌었음
    LLM과 공생하게 됐고, 이제 없이는 정말 어렵다
    그렇다고 LLM이 쓰는 코드를 이해하지 못한다는 뜻은 아니고, 모든 변경을 따라가며 코드베이스도 LLM보다 훨씬 크게 이해하고 있음
    다만 수동으로 코드를 작성하는 능력은 크게 퇴화했고, 그 점은 괜찮다고 생각함
    현재는 비즈니스 목표와 그것을 가장 잘 뒷받침하는 기술 사이의 번역 계층처럼 느껴짐
    여전히 문제 해결이지만 훨씬 높은 수준의 문제 해결이고, 여전히 흥미롭고 재미있음
    개발자에게 이 시대의 최선 전략은 비판적 사고를 유지하고 도구를 유리하게 쓰는 것 같음
    이제 모두가 초능력을 얻었음
    꼭 회사에서 일할 필요도 없고, 1인 개발자가 엄청난 것을 만들 수 있으니 다른 사람에게 의존할 필요도 예전만큼 없음
    어쩌면 미래는 각자가 세상에 고유한 무언가를 제공하는 매크로 제품 경제일지도 모름

    • “이제 모두가 초능력을 얻었다”는 식의 해석은 AI 열광론자들이 상황을 이상하게 오해하는 것 같음
      에이전트 코딩으로 그린필드 프로젝트를 만들 만큼 충분히 좋아진다면, 개발자뿐 아니라 회사 전체와 산업 부문 전체에도 영향을 줌
      개발 에이전시 사업 모델은 기술이 약한 회사들이 소프트웨어를 다루는 법을 모르기 때문에 존재하고, 어떤 경우에는 초기 인력 집약 작업을 외주화하려는 기회주의도 있음
      그런데 이제 그 기술이 에이전시 고객 손끝에 이미 있으니, CEO와 관리자들이 바이브 코딩을 시작하고 “기술 감각이 조금 있는 개발자 한 명”만 필요하다고 깨닫는 건 시간문제임
      이것은 많은 SaaS 사업에도 확장될 수 있음
      여전히 많은 소기업이 수작업을 없애려고 맞춤 소프트웨어를 원하지만, 진지한 소프트웨어 개발자는 항상 너무 비쌌음
      그래서 누군가의 조카가 만든 엉성한 코드나 겨우 작동하는 SaaS를 쓰곤 했음
      이제는 여전히 꽤 엉성하겠지만 자기 맞춤 솔루션을 만들고 더 많은 것을 얻을 수 있음
      빅테크가 하는 일은 경기침체에 맞춘 재조정에 가깝고, 더 걱정되는 건 중소 기술 부문의 혼란임
    • 회사에서 일하는 이유가 개발자가 혼자 결과물을 낼 수 없어서만은 아님
      고객을 따낼 연결망이 없기 때문임
      대부분의 개발자는 자신이 잘하는 일에 집중할 수 있도록 회사가 적어도 마케팅을 맡아주길 필요로 함
    • 코드 작성 능력의 퇴화는 이미 느끼고 있음
      코드 생성과 코드 판별은 뇌에서 다른 능력임
      프로그래밍에는 주로 작은 문법적 세부사항이 많기 때문에, 코드를 쓰는 데 어려움을 겪어도 리뷰는 잘할 수 있음
      https://xcancel.com/karpathy/status/2015883857489522876
    • 이론적으로 가능한 것과 현실적으로 가능한 것을 혼동하면 안 됨
      실제 세상에서 성공한 회사들은 데이터, 특허·지식재산, 네트워크 효과 등으로 해자를 갖고 있음
      개발 시간이 100분의 1이 됐다고 해서 곧바로 새 사업을 만들 수 있는 것은 아님
      지금 기술 업계를 둘러보면 민첩한 AI 기반 빌더에게 와해될 수 있어 보이는 회사가 많지만, 잠금 효과 때문에 실제로는 그렇게 되지 않고 있음

  • “1950년 미국 인구조사의 270개 직업 중 자동화로 사라진 것은 엘리베이터 운전원 하나뿐”이라는 주장은 오해를 부름
    같은 기간 농업 일자리는 노동력의 15%에서 2%로 줄었음

    • 글에서도 그 부분을 다루는 것 같음
      농업처럼 기계화와 자동화로 노동 수요가 크게 줄어든 직업과는 다르다고 함
      사람들이 소비하는 칼로리 양은 비교적 고정되어 있고 25% 증가만으로도 비만 유행이 생겼지만, 생산되는 소프트웨어의 양은 백만 배 커졌다는 차이임
    • 농장 고용 자체는 1950년 대비 4분의 1로 줄었음
      비율 수치는 전체 노동력이 커졌기 때문에 감소를 과장함
      하지만 더 넓은 식품 산업 고용을 보면 상당히 늘었음
      그래서 “코더” 고용은 줄어도 더 넓은 “소프트웨어/기술” 산업 고용은 늘어날 수 있음
    • 벌목 산업을 찾아보면 됨
      그 일자리의 95% 정도는 이미 자동화됐지만, 그들은 올빼미 탓을 하곤 함
    • 통계를 선택적으로 쓰는 전형적인 방식임
      공장, 컨베이어 벨트도 마찬가지임
      자동화가 들어올 때마다 사람들은 계속 일자리를 잃고, 우리는 그들이 다른 일을 찾길 “희망”하거나 “제너럴리스트가 돼라”, “전문가가 돼라”, “서비스업으로 가라”, “코딩을 배워라”, “석탄을 캐라” 같은 극단적이고 앞뒤 안 맞는 희망론을 오감
      @pmarca만 들어봐도 기술 리더십이 얼마나 길을 잃고 incoherent한지 보임
      산업 자동화에 관한 Stripe Press 최신 책도 참고할 만함: https://press.stripe.com/origins-of-efficiency

  • 가장 순진하게 AI를 믿는 사람들은 대체로 땜질하는 사람들이었음
    LLM 보조 코딩 덕분에 뭔가를 만지작거리는 속도는 놀라울 정도로 빨라졌으니 그럴 만함
    땜질은 과정이고, 사람들은 만들고 조정하는 행위 자체에서 큰 즐거움을 얻음
    결과는 2차나 3차 고려사항임
    AI는 우리가 행동하고 따라서 만지작거릴 능력을 크게 넓혔지만, 스스로 의미 있는 영향, 즉 “엔지니어링”을 만들어내지는 못함
    활동보다 영향이 중요함

    • 땜질은 조직이 그 주변에 프로세스를 만들기 전의 엔지니어링처럼 보일 때가 많음
      프로토타이핑, 디버깅, 테스트 등은 빨리 일어난다고 해서 가짜 일이 아님
      컴파일러도 스스로 영향을 만들지는 않음
      CI, IDE, 프레임워크, 클라우드 인프라도 마찬가지임
      그것들은 사용하는 사람의 레버리지를 높여줌

  • 아내는 AI에게 대체됐음
    프로그래머였고, 회사가 공개적으로 아내와 몇몇 사람을 대체할 목적으로 에이전트를 만들었으며, 작동하기 시작한 지 약 한 달 뒤에 해고했음

    • 아직 남아 있는 동료들의 사기는 나쁠 것 같음
      우리 팀은 18개월 전에 새 상사를 맞았는데, 노골적인 편애가 있었고 그가 좋아하는 사람은 팀플레이어가 아닌 유일한 사람이었음
      그는 18개월 동안 원격 근무자를 과거 성과와 무관하게 모두 해고할 방법을 찾아냈음
      그중 한 명은 상사보다 높은 레벨의 상도 여러 번 받았지만, 상사는 항상 그 유해한 사람만 인정했음
      AI 대체는 아니었지만, 사람들이 가치 없다고 느끼는 분위기는 AI로 대체될 때와 비슷할 것 같음
      내 감독자를 포함해 그 팀의 모두가 다른 직장에 지원 중임
      감독자는 고기능 자폐가 있고, 상사에게 자주 조롱당함
      그들의 정신 건강을 위해 꼭 성공하길 바람
      HR에 문제를 몇 번 제기했고, 업무 규정에서 상사가 위반하는 조항도 찾았지만, 적어도 여기서는 그런 규정이 그냥 글자일 뿐이라는 걸 배웠음
      오히려 내 등에 표적을 그리는 셈이라 떠나야 했음
      다른 여러 명도 우려를 제기했고, 그중 대부분은 이후 다른 일을 찾은 사람들임
      다행히 곧 갈 새 직장을 구했고 기대하고 있음
    • 힘들겠다
      괜찮길 바람
      이후 어떻게 됐는지, 새 직장을 구했는지, 여전히 소프트웨어 쪽인지 궁금함

  • AI 해고에 관한 기업 커뮤니케이션이 가짜라고 해서 위험이 무효화되지는 않음
    기업 쪽 이야기가 거짓일 수 있어도 기술의 영향은 실제가 될 수 있고, 이 맥락에서는 잡음일 뿐임
    글의 버거 도표처럼 실행 단계는 줄어드는데 다른 모든 단계가 커져서 전체 버거 크기가 그대로라는 가정도 그다지 그럴듯하지 않음
    다만 소프트웨어 엔지니어링의 일부 영역은 아직 위협받기 매우 먼 것 같음
    특히 정확성이 핵심인 영역이 그렇다
    웹 개발은 대충 밀어붙일 여지가 훨씬 많지만, 로켓 항법 코드는 다름
    LLM은 둘 다 할 수 있겠지만, 후자를 조만간 바이브 코딩하는 사람은 없을 것 같음

  • AI는 말 그대로 이미 일부를 대체했고 앞으로 더 그럴 것임
    모든 소프트웨어 엔지니어를 대체하지는 않겠지만, 판도라의 상자가 열린 이상 저노력·저위험 작업은 AI가 하게 됨
    Lovable 같은 서비스에는 실제 운영 중인 프로젝트가 매우 많고, 대안은 사람이 만드는 것이었음

    • Lovable에서 비소프트웨어 전문가가 작성하거나 프롬프트한 것 중, 완전한 SaaS 도구로 유용할 만한 “훌륭한” 프로젝트를 보여줄 수 있나
    • 대안이 사람이 만드는 것이 아니라, 아예 존재하지 않는 것이었을 수도 있음

  • 일자리를 대체하는 것은 언제나 사업주임
    그래픽카드 묶음을 의인화하지 말아야 함

    • 그 그래픽카드 묶음이 정말 더 효율적이 된다면, 인간을 고용하려는 사업주는 경쟁할 수 없게 됨

  • 글의 이 부분은 확신이 안 듦
    “진짜 병목은 (1) 무엇을 만들지 결정하고 명세하는 것, (2) 전달된 것을 검증하고 책임지는 것, (3) 코드베이스·비즈니스·환경에 대한 깊은 인간적 이해”라는 주장임
    코딩이 비싸고 병목으로 여겨졌기 때문에, 그 입력이 맞고 출력물을 버리지 않도록 상류와 하류 모두에서 많은 노력이 들어갔던 것일 수 있음
    코딩이 빠르고 싼 단계로 여겨진다면, 출력물을 버려도 되므로 상류에서 같은 수준의 감독이 필요하지 않을 수도 있음

    • 잘못된 코드를 버리는 비용이 잘못된 것을 만드는 주된 비용은 아님
      소프트웨어가 오작동했을 때의 영향과 하위 호환성 유지가 훨씬 더 나쁨
답변달기