AI는 왜 소프트웨어 엔지니어를 대체하지 못했고, 앞으로도 못할까

코딩 에이전트를 ‘보통의 기술’로 바라보기

게시일: 2026년 7월 23일 | 원문 작성일: 2026년 6월 11일 | 저자: Arvind Narayanan & Sayash Kapoor | 원문 보기

AI가 일자리를 대체할 것이라는 불안과 불확실성이 크다. 막연한 경고와 과장된 예측을 넘어, 이 질문에 데이터를 들이대려면 어떻게 해야 할까? 좋은 방법 하나는 AI 역량이 가장 앞서 있고 도입 속도도 유난히 빨랐던 직군, 즉 소프트웨어 엔지니어링을 살펴보는 것이다.

이 글에서 우리는 AI 역량이 어떤 임계점에 도달하면 대규모 정리해고가 벌어질 것이라는 서사를 기각할 만큼 충분한 증거가 있다고 주장한다. 규제 장벽이 거의 없는 이 분야에서조차 이것이 사실이라면, 다른 대부분의 직군은 그보다 훨씬 더 보호받을 가능성이 높다.

우리는 왜 이런 현상이 나타나는지도 잘 이해하고 있다. 소프트웨어 개발을 비롯한 여러 지식노동을 “결정-실행-전달 샌드위치”로 생각해볼 수 있다. AI는 샌드위치의 중간층인 “실행” 계층을 압축하지만, 나머지 두 계층은 성능 향상만으로는 극복되지 않는 방식으로 자동화에 저항한다.

우리는 소프트웨어 엔지니어링 수요의 향후 흐름에 대해 조심스러운 낙관론으로 결론을 맺는다. 이 글은 연작의 첫 번째 글이며, 다음 글에서는 전체 수요가 건전하더라도 개별 소프트웨어 엔지니어의 커리어가 순탄치 않을 수 있는 이유를 살펴볼 것이다. 이 연작은 경제학 및 소프트웨어 엔지니어링 분야에서 발표된 문헌, AI 에이전트에 대한 우리 자신의 평가와 관찰, 그리고 자신의 직업에 AI가 미치는 현재와 미래의 영향에 대해 여러 소프트웨어 엔지니어들이 남긴 성찰(발표된 글과 커뮤니티와의 교류 양쪽에서 얻은)을 바탕으로 한다.

• • •

소프트웨어 업계의 “AI발 대량 해고” 이야기는 전형적인 “AI 워싱”으로 보인다

헤드라인을 장식했던 세 가지 사례와, 그것이 실제 현실과 어떻게 어긋났는지 살펴보자.

• 2월, 핀테크 기업 Block(Cash App, Square, Afterpay 등의 서비스를 만드는 회사)은 직원 4,000명을 해고한다고 발표했다. 창업자 Jack Dorsey에 따르면 AI가 “더 작고 수평적인 팀”으로 “새로운 업무 방식을 가능하게 하고 있다”는 것이 이유였으며, 그는 특히 2025년 말의 모델 성능 개선을 근거로 들었다.

  하지만 후속 보도는 전혀 다른 그림을 보여주었다. 팬데믹 기간 동안 인력을 세 배 넘게 늘린 뒤, 회사는 극심한 재정적 압박에 시달리고 있었다. Cash App 팀의 데이터 과학자 Naoko Takeda는 글을 올렸다:

  “[Block은] 모두에게 AI를 억지로 떠먹였다. 하지만 생산성 향상은 매우 제한적이었다.”

  그녀는 75% 급여 인상을 조건으로 한 잔류 제안을 거절하고 회사를 떠났다. 인터뷰에 응한 다른 직원들은 Block에서 AI가 실제로 무엇을 할 수 있었는지, 그리고 Dorsey가 이 문제를 제대로 이해하고 있었는지에 대해 현저히 다른 견해를 갖고 있었다.

  클라우드 스토리지 기업 Box의 CEO Aaron Levie가 지적했듯, CEO들은 AI의 유용성에 대해 착각에 빠지기 유독 쉬운 위치에 있다. 빠른 프로토타입은 직접 만들어 볼 수 있지만, 그것을 완성된 제품으로 바꾸는 데 드는 나머지 90%의 작업은 눈에 보이지 않기 때문이다. Dorsey가 AI에 대해 공개적으로 한 발언들도 정확히 이 패턴에 들어맞는 것으로 보인다.

• 4월, Snap은 약 1,000명을 해고했고, CEO Evan Spiegel은 해고 통지문에서 주된 이유로 AI를 꼽았다. 그는 또한 AI가 신규 코드의 65%를 생성했다고 말했다. 하지만 실제로는 이 해고가 비용 절감을 요구하는 행동주의 투자자의 압박 캠페인에 뒤이어 벌어진 일이었다. (Snap은 2017년 상장 이후 매 회계연도마다 순손실을 기록해왔고, 2026년 주가는 30% 넘게 하락했다.) 특기할 점은, 증강현실 부문 전반의 여러 직무에 걸친 150명 감원처럼 실제 감원의 양상이 AI로 인한 감원이라면 나타나야 할 패턴과 맞지 않는다는 것이다. 즉 AI로 인한 감원이라면 프로그래밍을 비롯해 “AI에 노출된” 직무 전반에서 고르게 감원이 일어나야 하는데, 특정 부서에 집중되어 있었다.

• 5월, 회계·세무 소프트웨어 기업 Intuit는 Anthropic 및 OpenAI와의 계약과 함께 3,000명 감원을 발표했다. 언론은 이 둘을 연결지어 해고를 AI 주도 구조조정으로 규정했다. 이례적으로 이번엔 CEO가 이 손쉬운 서사에 반박하며, “AI와는 아무 관련이 없다”고, 감원의 대상은 “조율 부담이 큰 직무”와 지나치게 많은 관리 계층이었다고 밝혔다.

우리가 이 사례들을 입맛대로 골라낸 것이 아니다. AI 주도 소프트웨어 엔지니어링 감원에 관해 우리가 조사한 모든 기사에서 이야기와 실제가 어긋나는 동일한 패턴이 드러났다. 알고 보니 해고를 둘러싼 “AI 워싱”은 여러 설문조사가 뒷받침하는, 경제 전반에 걸친 현상이었다.

• 미국 채용 담당자의 59%는 채용 동결이나 정리해고를 설명할 때 AI를 강조한다고 인정했다. 재정적 제약을 언급하는 것보다 이해관계자들에게 더 잘 먹히기 때문이다.

• Forrester의 수석 애널리스트 J. P. Gownder는 겉으로는 AI 때문인 것처럼 보이는 정리해고를 준비하는 기업들에 대해 이렇게 말한다. “우리가 그 자리를 채울 만큼 성숙하고 검증된 AI 애플리케이션을 갖추고 있느냐고 물으면, 열 번 중 아홉 번은 없다는 답이 돌아옵니다. 심지어 시작조차 하지 않은 경우도 많고요.”

• 전 세계 경영진 1,000명 이상을 대상으로 한 HBR 설문조사에 따르면, 21%는 AI를 “예상하여” 대규모 인력 감축을 단행했으며, 추가로 39%는 소규모 또는 중간 규모의 선제적 인력 감축을 실시했다고 답했다. 반면 실제 AI 도입과 관련해 이미 대규모 인력 감축을 단행한 비율은 2%에 불과했다. 이 10배의 격차는 경영진 역시 다른 모든 사람들과 마찬가지로 AI가 일자리를 대체한다는 오도된 서사에 쉽게 넘어간다는 사실을 시사한다.

또 하나 흥미로운 데이터는 WARN 법에서 나온다. 이 법은 100명 이상의 노동자에게 영향을 미치는 사업장 폐쇄 및 대규모 해고에 대해 일정한 공시를 요구한다. 2025년 3월, 뉴욕주는 미국 주 가운데 처음으로 WARN 법 신고서에 AI 관련 여부를 표시하는 체크박스를 추가했다. 시행 첫 해 동안 160개 이상의 기업이 WARN 신고서를 제출했다. 단 한 곳도 AI 항목에 체크하지 않았다.¹ 우리는 뉴욕주 노동부에 문의했고, 5월 말 기준으로 오직 한 기업, Nespresso만이 이 항목에 체크했다는 답변을 받았다.² 이 신고 내용이 정확하다면, 해당 기간 뉴욕주에서 해고된 약 25,000명의 노동자 가운데 AI의 영향을 받은 것으로 표시된 인원은 단 46명, 즉 약 0.2%에 불과하다.

AI 주도 대량 해고 서사에 더 치명적인 지점이 있다. 애초에 해고는 AI의 잠재적 생산성 효과를 보여주는 잘못된 신호라는 점이다! 연구에 따르면 그 효과는 “퇴사 증가가 아니라 채용 둔화”를 통해 나타난다는 것이 명확하다. 기존 인력을 해고하면 바로 그 직원들이 AI를 효과적으로 운용할 수 있게 해주는 암묵지와 조직 자본을 잃게 된다. 게다가 퇴직금, 사기 저하, 재채용 리스크 측면에서 비용도 크다. 이런 비용을 감안하면, 자연 이직만으로도 몇 년 안에 같은 결과에 도달할 수 있으니 해고는 대체로 불필요하다.

그렇다면 해고를 넘어 전체 고용 추세를 살펴보면 데이터는 무엇을 말해줄까? 연방준비제도(Fed) 경제학자들의 중요한 논문이 미국 상황에 대한 증거를 종합했다. 소프트웨어 엔지니어 고용은 여전히 증가하고 있지만, 이들의 분석에 따르면 ChatGPT 등장 이후 AI가 없었을 경우의 반사실적 시나리오와 비교해 연간 약 3퍼센트포인트씩 더 느리게 증가하고 있다. 이 연구의 한 가지 중요한 한계는 방법론상 자영업을 포착할 수 없다는 점이다. 따라서 고용 증가 둔화의 일부가 창업으로 흡수되고 있을 가능성이 있다. 실제로 AI가 창업을 더 쉽게 만든다는 증거는 다른 연구들에서도 확인된다. 그러므로 실제 그림은 연준 연구가 시사하는 것보다 아마 더 건강할 것이다.³

마지막으로, AI가 소프트웨어 엔지니어를 직접 대체하는 것과는 다르지만 그럼에도 실재하는 간접적인 AI발 일자리 감소가 두 가지 있다. 이를 짚고 넘어갈 필요가 있다. 첫째, AI는 때때로 제품에 대한 수요 자체를 붕괴시킨다. 숙제 도우미 서비스인 Chegg나 기술 질의응답 서비스인 Stack Overflow가 그런 사례로, 둘 다 인력을 감축했다. AI가 이들 직원이 하던 일을 직접 수행하는 것은 아니지만, 그 일 자체의 필요성을 없애버린 것이다. 역사적으로도 비슷한 사례가 있다. 1950년 미국 인구조사에 등재된 270개 직업 중 자동화로 완전히 사라진 직업은 단 하나, 엘리베이터 운전원뿐이었다. 하지만 전신 기사(telegraph operator)처럼 새로운 기술로 인해 그 존재 의미 자체가 사라진 직업은 그 외에도 많았다.

또 하나 설득력 있는 AI발 감원 이야기는 AI를 구매하는 기업이 아니라 AI를 판매하는 기업들 사이에서 나온다. IBM이나 SAP 같은 기업이 AI를 이유로 감원을 발표할 때, 더 정확한 설명은 “우리는 레거시 부문에서 가장 빠르게 성장하는 제품 라인으로 인력을 재배치했다”는 것이다. 이는 기술이 노동자를 밀어낸 것이 아니라, 수익 기회를 좇은 통상적인 기업 구조조정에 가깝다.

• • •

코딩 에이전트가 노동 대체로 이어지지 않은 이유: 결정-실행-전달 샌드위치

앞서 언급한 Snap CEO처럼 많은 테크 업계 리더들은 정리해고 소식이나 향후 일자리 감소 전망과 함께 AI가 작성한 코드의 비율을 언급한다. 이는 AI가 모든 코드를 작성하게 되면 코더가 더 이상 필요 없다는 단순한 사고방식을 부추긴다. 다행히도 이 사고방식은 틀렸다. AI 작성 코드 비율이라는 지표는 노동 대체에서 실제로 중요한 것과 거의 완전히 무관하다. 그 이유를 살펴보자.

코드를 작성하는 일은 병목이 아니었고, 애초에 그런 적도 없다. 예를 들어 2019년 논문은 기존 연구들을 정리하며 “개발자들이 코딩에 쓰는 시간은 놀라울 정도로 적어서, 연구에 따라 9%에서 61% 수준”이라는 결론을 내렸다. 이 결과는 마이크로소프트 소속 개발자 6,000명을 대상으로 한 해당 논문 자체의 데이터와도 일치했다. 코딩 에이전트가 확산되기 시작하면서, 2025년 말에는 코드 작성이 병목이 아니었다는 점을 지적하는 블로그 게시물이 폭발적으로 늘어났다. 개발자들이 에이전트를 이용해 대부분의 코드를 작성하게 해봐도 전체 생산성에는 거의 영향이 없다는 사실을 실감했기 때문이다 [1, 2, 3, 4, 5, 6, 7, 8].

코드 작성이 병목이 아니라면, 무엇이 병목일까? 업무 세분화 설문들은 회의나 디버깅 같은 것들을 지목한다. 하지만 이는 더 많은 질문으로 이어질 뿐이다. 개발자들은 그 회의에서 대체 무엇을 하고 있으며, 왜 그것을 AI가 대신할 수 없는가? 디버깅도 AI 역량이 향상되면 결국 자동화되지 않을까? 진짜 병목을 이해하려면 정성적인 차원으로 들어가, 소프트웨어 엔지니어들이 스스로 파악하고 있는 자기 업무 중 자동화에 저항하는 부분이 무엇인지 파고들어야 한다.

이 분석을 진행하면서 진짜 병목은 다음 세 가지라는 사실이 드러났다. (1) 무엇을 만들지 결정하고 명세하는 일, (2) 전달된 결과물을 검증하고 그에 대해 책임지는 일, 그리고 (3) 이 두 가지를 수행하는 데 필요한 코드베이스, 비즈니스, 환경에 대한 깊은 인간적 이해다.

다시 말해, 소프트웨어 엔지니어의 업무는 “결정-실행-전달” 샌드위치로 구성되어 있다(이해는 이 세 가지 모두의 전제 조건이다). AI는 샌드위치의 가운데 층을 압축했지만, 양쪽 끝은 대체로 그대로 남겨두었다. 소프트웨어 개발 팀이 의사결정의 주체이자 전달 결과물에 대한 책임 주체로 남아 있는 한, 엔지니어는 여전히 시스템에 대한 깊은 이해를 쌓는 데 시간을 들여야 한다. 이것이 바로 세 가지 병목이다.

원문 보기

AI가 생산성에 미치는 영향을 설명하는 샌드위치 모델의 근거는 최근 발표된 논문 “Writing Code vs. Shipping Code”에서 찾을 수 있다. GitHub의 개발자 10만 명을 대상으로 한 이 연구에서, 연구자들은 AI 에이전트가 작성된 코드 줄 수를 8배 늘렸다는 사실을 발견했는데, 이는 AI가 샌드위치의 실행(Execute) 레이어를 거의 완전히 압축한다는 생각과 부합한다. 하지만 이로 인해 실제 릴리스는 겨우 30% 늘어나는 데 그쳤고, 이는 인간이 만드는 병목(결정과 전달 레이어)이 여전히 자리 잡고 있음을 강하게 시사한다.⁴

샌드위치를 더 압축할 수 있을까? 우리는 그렇지 않다고 본다. 파이프라인의 한쪽 끝에서 개발 팀은 무엇을 만들지 결정해야 한다. 주니어 소프트웨어 엔지니어가 배우는 가장 중요한 교훈 중 하나는, 요구사항 명세(이 업계 용어로는 이 레이어를 이렇게 부른다)를 작성하는 데 놀라울 만큼 오랜 시간이 걸리며, 이 과정을 압축하면 이후 단계에서 훨씬 큰 고통이 뒤따른다는 것이다. 이 레이어는 사용자 요구, 시장 신호, 조직의 우선순위, 그리고 경우에 따라 규제상의 제약까지 고려해야 하기 때문에 자동화하기 어렵다.

AI 역량이 향상됨에 따라 AI에 위임할 수 있는 결정의 종류는 시간이 지날수록 늘어난다. 하지만 그렇다고 해서 “결정” 층이 얇아지는 것은 아니다. 어떤 결정을 AI에 위임할 수 있게 되는 순간, 그 결정은 더 이상 경쟁 우위의 원천이 아니게 되고, 인간의 의사결정이 지니는 가치는 그보다 위쪽으로 이동한다. 소프트웨어는 시간이 지날수록 점점 더 복잡해지므로, 이 과정에는 한계가 없다.

샌드위치의 다른 한쪽 끝에서는, 인간 팀이 자신이 전달하는 결과물에 대해 책임을 져야 한다. 언젠가 미래에는 팀이 미션 크리티컬한 코드를 완전히 테스트하거나 이해하지 못한 채로 그대로 출시하는 날이 올 수도 있다. 하지만 오늘날의 AI는 여전히 신뢰도가 낮아서, 그런 무모한 방식은 소프트웨어 팀과 그 고객들에게 존립을 위협하는 위험이 될 것이다.

설령 미래에 기술적 장벽이 사라지더라도, 우리가 AI에 통제권을 넘겨줄 필요는 없다. AI as Normal Technology의 핵심 통찰 중 하나는, 공유된 규범과 법률, 정책을 통해 인간에게 책임을 묻는 체계를 우리가 집단적으로 선택하여 유지할 수 있다는 것이다. 이는 기술 역량의 발전 자체를 늦추려는 시도보다 AI가 미치는 영향의 속도를 통제하고 안전성을 높이는 데 훨씬 더 견고한 방법이다. 이러한 속도 제어 장치는 배상책임법과 분야별 규제를 통해 이미 상당 부분 마련되어 있으며, 앞으로 더 강화할 수도 있다. (이 논증을 더 자세히 다룬 내용은 원문 에세이를 참고하라.)

이러한 미래상 속에서, 실행 계층이 점점 더 많이 AI에 위임될수록 소프트웨어 엔지니어의 역할은 크레인 기사와 비슷한 모습이 될 것이다. AI 에이전트가 인지 부담이 큰 작업 대부분을 처리하고, 인간은 에이전트를 감독하며 통제 아래 두는 일이 주된 업무가 된다.

일부 논평가들은 사람이 계속 통제권을 쥐는 미래가 실현되기 어렵다고 주장한다. 그렇게 하는 데 드는 인건비가 너무 크다는 이유에서다.

하지만 우리는 이런 사례들을 새롭게 자리 잡아가는 규범이라기보다는 “개가 사람을 물어야 뉴스가 아니라 사람이 개를 물어야 뉴스”인 이례적 사건으로 본다. 이런 사례들이 화제가 되는 것은 정확히 그것이 너무나 무책임하고 이례적인 행동이라 충격적이기 때문이다. 동시에 이런 사례들은 커뮤니티가 AI에 대한 과도한 의존을 스스로 경계하도록 돕는 정기적인 경고이자 학습의 계기로 작용한다. 격언에도 있듯이 “뉴스에 나올 정도면 걱정할 일이 아니다”. 그럼에도 고위험 작업에 AI를 제대로 감독하지 않고 사용하는 사례가 소프트웨어 엔지니어링 분야뿐 아니라 경제 전반에 걸쳐 늘고 있는지 감지할 수 있는 능력은 오늘날 우리가 가진 가장 중요한 데이터 공백 중 하나로 남아 있다.

그런데 이 샌드위치가 눌리는 현상은 새로운 흐름이 아니며, AI만의 문제도 아니다. 20년도 더 전에 미국 노동통계국(Bureau of Labor Statistics)은 프로그래밍을 소프트웨어 엔지니어링과 별도로 집계하기 시작했다. 대략적으로 말하면, 프로그래머는 오직 실행만을 담당하는 반면 소프트웨어 엔지니어는 샌드위치의 더 큰 부분을 관리한다. 프로그래밍은 그 비중이 줄어들고 있을 뿐 아니라, 단순 노동으로 여겨지기 때문에 보수도 훨씬 낮다. AI는 이렇게 오래전부터 존재해온 흐름을 가속할 뿐이며, 순수 기술 역량의 가치를 한층 더 떨어뜨리고 있다.

원문 보기

이처럼 AI가 중간 실행 계층을 점점 더 많이 자동화하는 와중에도 결정-실행-전달 샌드위치의 양 끝에는 여전히 인간이 깊숙이 관여한다. 이런 패턴은 소프트웨어 분야에서 가장 앞서 나타나고 있을 뿐, 대부분의 지식노동 전반에 폭넓게 적용될 것으로 보인다. 결국 복잡한 의사결정과 책임 소재는 대다수 분야에 공통적인 요소이기 때문이다. 이러한 현상을 제대로 인식하지 못한 탓에 임박한 실업에 대한 과신에 찬 주장들이 많이 나왔는데, AI가 영상의학과 전문의를 대체하리라는 예측이 그 한 예다.

• • •

바이브 코딩은 에이전틱 엔지니어링이 아니다

소프트웨어 엔지니어링이 얼마나 변화하고 있는지에 대한 혼란이 생기는 한 가지 이유는, “바이브 코딩”이라는 용어가 매우 폭넓은 관행들을 지칭하는 데 부정확하게 쓰이고 있기 때문이다. 이 스펙트럼의 양극단은 개념적으로 서로 다르며, 비슷한 점보다 다른 점이 더 많다.

진정한 바이브 코딩에서는 사용자가 에이전트에게 할 일을 지시하기만 할 뿐, 실행되는 동안 감독하지 않고, 코드를 검토하지도 않으며(애초에 그럴 능력이 없을 수도 있다) 결과물을 평가하지도 않는다. 기껏해야 눈에 띄게 뭔가 고장 났을 때 알아차리는 정도다.

이는 대다수 소프트웨어 엔지니어가 실제로 에이전트를 사용하는 방식과는 대조적이다. 이들은 에이전트를 하나의 도구로 사용하며, 인간이 통제권을 유지하고 결과물에 책임을 진다. 다행히 이러한 관행을 가리키는 용어로 에이전틱 엔지니어링이 점차 널리 쓰이고 있다.

에이전틱 엔지니어링이 표준이 되면서, 엔지니어들은 코딩 에이전트를 감독하는 일이 의외로 시간을 많이 잡아먹는다는 사실을 깨닫고 있다. 예를 들어 저명한 개발자이자 AI 전환기를 기록해온 Simon Willison은 에이전트를 감독하다 보면 오전 11시면 이미 정신적으로 지쳐버린다고 말한 바 있다. 이는 우리의 경험과도 일치한다.

더 정량적인 증거는 로깅 도구 사용에 동의한 오픈소스 개발자들의 코딩 에이전트 상호작용 데이터셋인 SWE-chat에서 나온다. 이 연구에 따르면 에이전트가 생성한 코드 중 사용자의 커밋에 살아남는 비율은 44%에 불과했고, 바이브 코딩으로 작성된 커밋은 사람이 직접 작성한 코드에 비해 9배 높은 비율로 취약점을 유발했으며, 가장 흔한 사용자 의도는 새 코드를 생성하는 것이 아니라 기존 코드를 이해하는 것이었다(19% 대 13%). 이 데이터셋은 자기 선택적(self-selected) 표본이라는 한계가 있어 이 연구 하나만으로 강한 결론을 내릴 수는 없지만, 바이브 코딩과 에이전틱 엔지니어링 패턴이 상당히 다르다는 다른 여러 증거들을 뒷받침한다.

원문 보기

다시 한번 강조하자면, 이 둘은 서로 다른 두 범주가 아니다. 하나의 스펙트럼의 양 끝일 뿐이며, 그 사이에는 경계가 흐릿한 중간 지대가 존재한다. 모든 프로젝트가 일회성이거나 아니면 미션 크리티컬인 것은 아니다. 모든 워크플로우가 표의 왼쪽 열이나 오른쪽 열에 정확히 들어맞는 것도 아니다. 하지만 일자리 문제에 대한 핵심적인 함의는 여전히 확고하다. 기업은 자격을 갖추지 못한 바이브 코더를 소프트웨어 엔지니어 대신 고용해서는 프로덕션 소프트웨어를 출시할 수 없다.

• • •

앞으로는 어떻게 될까?

AI 낙관론자들은 대규모 해고가 곧 닥칠 것이라고 주장할지 모른다. 인간 수준의 소프트웨어 엔지니어링 능력이 등장한 지 얼마 되지 않았기 때문에(혹은 아직 달성되지 않았기 때문에) 아직 그런 일이 일어나지 않았을 뿐이라는 것이다. 하지만 샌드위치 모델이 옳다면, 이런 예측은 실현되지 않을 것이다. AI는 이미 샌드위치의 중간층을 대부분 압축해 놓았다(그리고 이 압축은 사실 수십 년 전에 시작되었다). 따라서 실행 계층을 완전히 즉각적이고 완벽하게 만든다 해도, 현재 상태에서 크게 달라지지 않을 것이다. 나머지 두 계층이 AI에 저항해 온 이유는 능력의 한계 때문이 아니다.

사실 AI 때문에 소프트웨어 엔지니어링 일자리가 사라지지 않을 뿐 아니라, 오히려 소프트웨어 엔지니어에 대한 수요가 늘어날 수도 있다. 기술적 생산성 향상으로 소프트웨어(또는 그 무엇이든)를 만드는 비용이 저렴해지면, 사람들은 소프트웨어를 훨씬 더 많이 구매하게 된다(경제학 용어로는 소프트웨어가 “가격 탄력성”이 매우 높다고 말한다). 그리고 우리가 앞서 주장했듯 AI는 소프트웨어 엔지니어를 대체하지 않으므로(“대체 탄력성”이 낮으므로), 소프트웨어 수요 증가는 소프트웨어 엔지니어에 대한 파생 수요 증가로 이어진다. 이 개념을 설명할 때 AI 담론에서 자주 언급되는, 느슨하게 관련되어 있지만 더 화려한 경제학 용어로 “제번스 역설”이 있다.

역사적으로도 이런 패턴이 반복되어 왔다. 미국의 프로그래머 고용은 1950년경 거의 0에서 오늘날 수백만 명 규모로 성장했다. 이는 기계화와 자동화로 인해 노동 수요가 크게 줄어든 것으로 유명한 농업 같은 직종과는 뚜렷이 다른 양상이다. 그 차이는, 사람이 섭취하는 칼로리의 양은 비교적 고정되어 있어 25% 증가만으로도 비만이 만연하는 결과를 낳은 반면, 생산되는 소프트웨어의 양은 백만 배나 늘어났다는 데 있다. 요즘 자동차는 각종 탑재 컴퓨터에서 1억 줄에 달하는 코드를 돌리고 있다.

코드에 대한 수요에 천장이 있다면, 우리는 아직 그 근처에도 가지 못했다. 사실상 모든 지적 노동이 소프트웨어의 혜택을 받는다. AI가 코딩 비용을 낮추면서, 사람들은 업무용이든 개인용이든 지금까지는 만들 이유가 없었던 온갖 종류의 일회성 유틸리티를 만들어내고 있다.

분명히 해두자면, 앞으로 소프트웨어가 훨씬 더 많아지고 소프트웨어 엔지니어도 더 늘어날 것이라고 생각하지만, 그렇다고 해서 빅테크 기업이 지금보다 더 커진다는 뜻은 아니다. 오늘날 소프트웨어 엔지니어 대다수는 이미 소프트웨어 회사가 아닌 기업 내부에서 일하고 있으며, 그 비중은 앞으로 더 커질 수도 있다. 그리고 “AI 롤업”이라는 개념도 있다. 이는 벤처캐피털이나 사모펀드가 치과, 회계법인 등 “동네 상권” 비즈니스를 인수한 뒤, 소프트웨어 엔지니어나 AI 엔지니어를 그 안에 배치해 “AI 네이티브”로 밑바닥부터 재구축한다는 아이디어다. 물론 결국 이것도 그저 과장된 유행으로 끝날 수 있다. 아직은 판단하기 이르다.

일각에서는 “민주화” 때문에 소프트웨어 엔지니어링 스킬에 대한 수요가 줄어들 것이라고 예측한다. 이들은 그 어느 때보다 많은 소프트웨어가 만들어질 것이고, 그 어느 때보다 많은 인간 시간이 소프트웨어 제작에 투입될 것이라는 점은 인정하면서도, 소프트웨어 엔지니어가 아닌 사람들이 그 작업을 하게 될 것이라고 본다. 즉, AI가 소프트웨어 엔지니어링을 민주화해서, 예컨대 법률 소프트웨어라면 소프트웨어 공학 훈련을 받은 사람보다 법학 훈련을 받은 사람이 더 쉽게 만들 수 있게 되리라는 발상이다.

그럴 수도 있다. 하지만 우리는 그렇지 않은 쪽에 걸겠다. 우리가 보기에 이 주장은 바이브 코딩과 에이전틱 엔지니어링을 혼동하고, 실행 레이어를 결정-실행-전달 샌드위치 전체와 혼동하는 것과 같은 함정에 빠져 있다. 실제로 프로그래밍의 역사를 돌아보면, 우리가 민주화의 문턱에 서 있다는 주장은 늘 있어왔다. FORTRAN, COBOL, SQL 같은 옛 언어들도 등장 당시에는 하나같이 그런 거창한 희망을 동반했다. 하지만 그런 일은 일어나지 않았다. 진짜 장벽은 문법을 배우는 데 있지 않다. 문제는 책임을 유지하면서 좋은 결정을 내릴 수 있을 만큼 숙련된 판단력을 갖추는 것이다.

결국 이 구분은 의미론적인 문제일 수 있다. 사람들이 컴퓨터로 새로운 일을 하게 만드는 데 쓰는 시간의 총량은 시간이 지날수록 늘어날 것이 분명해 보인다. 이는 소프트웨어를 만드는 형태일 수도 있고, 에이전트를 활용해 복잡한 워크플로를 관리하는 형태일 수도 있고, 또 다른 무언가일 수도 있다. 어느 쪽이든 소프트웨어 역량, AI 역량, 그리고 도메인 전문성이 뒤섞인 능력이 필요할 것이다. 오늘날의 소프트웨어 엔지니어들이 이 새로운 역할을 가장 잘 채울 적임자가 될지는 아직 두고 볼 일이다.

적응이 필요하다는 이 마지막 지점은 이 시리즈의 다음 글로 이어진다. 소프트웨어 분야의 전체 노동 수요가 계속 견조할 가능성이 높다는 사실이, 대다수의 개별 노동자가 영향을 받지 않으리라는 뜻은 아니다. 우리는 AI가 소프트웨어 생산 방식에 거대한 구조적 변화를 일으킬 것이며, 이것이 어떤 소프트웨어 엔지니어가 이득을 보고 어떤 소프트웨어 엔지니어가 손해를 볼지에(그들이 속한 기업의 유형, 지리적 위치, 연차, 적응 속도에 따라) 큰 영향을 미칠 것이라고 주장할 것이다.

더 읽어보기

Deena Mousa는 “AI 노출도” 같은 지표에 기반한, 경제 전반을 아우르는 AI 영향 분석이 피상적이라고 지적하며, 그 대신 “직군별로 세심하게 파고드는 작업”을 요구한다. 우리는 이 연작 에세이가 AI의 소프트웨어 엔지니어링 변혁을 정교하게 이해하는 데 일조하기를 바란다. 우리는 이전에 Justin Curl과 공저로, 그 직군을 독특하게 만드는 규제 등의 병목 요인을 진지하게 다룬 법률 서비스 분야 AI 분석 논문을 발표한 바 있다. 앞으로도 직군별 심층 분석을 더 이어갈 계획이다.

40년 전 프레드 브룩스(Fred Brooks)는 *No Silver Bullet*이라는 뛰어난 에세이에서 소프트웨어의 ‘본질적 복잡성(essential complexity)‘과 ‘부수적 복잡성(accidental complexity)‘을 구분했다. 그는 소프트웨어의 복잡성 중 일부는 프로그래밍 언어의 투박함 같은 현재 기술의 한계에서 비롯된 부수적인 것이며, 도구가 발전함에 따라 시간이 지나면 완화될 수 있다고 주장했다. 하지만 일부는 본질적인데, 소프트웨어의 올바른 동작을 명시하는 일 자체가 어렵기 때문이다. 그는 샌드위치의 ‘결정’ 층이 왜 두껍고 자동화에 저항하는지를 강력하게 논증한다. 흥미롭게도, AI를 통해 프로그래머의 생산성을 높이려는 기대는 당시에도 이미 두드러졌다! 브룩스는 AI든 다른 어떤 기술이든 부수적 복잡성만 줄일 뿐이므로, 생산성을 자릿수 단위로 끌어올리지는 못할 것이라고 주장한다. (브룩스는 *The Mythical Man Month*의 저자로, 이 에세이집은 소프트웨어 엔지니어링에 관한 글 중 역대 가장 유명하고 영향력 있는 저작이라 해도 과언이 아니다. No Silver Bullet은 이후 이 에세이집에 수록되었다.)

초고에 대한 피드백을 준 Felix Chen에게 감사드린다.