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를 억지로 떠먹였다. 하지만 [내가 본] 생산성 향상은 매우 제한적이었다.”

  Takeda는 급여를 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를 효과적으로 운용하는 데 필요한 바로 그 암묵지와 조직 자본을 잃게 된다. 게다가 퇴직금, 사기 저하, 재채용 리스크 측면에서 비용도 크다. 이런 비용을 감안하면, 자연 이직만으로도 몇 년 안에 같은 결과에 도달할 수 있으니 해고는 대체로 불필요하다.

그렇다면 해고에서 눈을 돌려 전체 고용 추세를 살펴보면 데이터는 무엇을 말해 줄까? 연방준비제도(연준) 경제학자들은 중요한 논문에서 미국의 관련 증거를 종합했다. 소프트웨어 엔지니어 고용은 여전히 증가하고 있지만, 이들의 분석에 따르면 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배로 늘었다. 샌드위치의 실행(Execute) 층을 AI가 거의 완전히 압축한다는 생각과 들어맞는 결과다. 하지만 릴리스는 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배 높은 비율로 생겨났으며, 가장 흔한 사용자 의도는 새 코드 생성(13%)이 아니라 기존 코드 이해(19%)였다. 이 데이터셋은 자기 선택적(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에게 감사드린다.