AI 대체 실험이 대규모로 진행되었습니다. 결과가 나왔습니다. 하지만 아무도 그 결과에 대해 보도 자료를 작성하지 않고 있습니다.

누구도 이 계획을 공개적으로 발표하지 않았습니다. 하지만 2024년 어딘가에서, 수백 개의 기업이 동시에 동일한 결정을 내렸습니다. 개발자들은 비용이 많이 들었습니다. AI 코딩 도구들은 진정으로 인상적으로 변하고 있었습니다. 슬라이드 덱(slide deck) 상의 계산은 명확해 보였습니다.

인력을 감축하라. AI와 함께 제품을 출시하라. 마진을 보호하라. 간단합니다.

그해 업계 전반에 걸쳐 약 124,000명의 소프트웨어 개발자가 해고되었습니다. Amazon, Microsoft, Meta, Salesforce 등 명단은 길었고 발표는 빠르게 이어졌습니다. 내러티브(narrative)는 자신만만했습니다. AI가 코드를 작성할 것이고, 인간은 병목 현상(bottleneck)일 뿐이라는 것이었습니다.

그 내러티브는 이제 조용하고 어색하게 무너지고 있습니다.

Gartner는 최근 AI 때문에 직원을 해고한 기업의 50%가 2027년까지 정확히 동일한 역할로 직원을 재고용할 것이라고 추정했습니다. 일부 기업의 신규 채용 인원의 약 40%는 이미 AI 전환 이후 문밖으로 쫓겨났던 전직 직원들입니다. Google은 이전에 감축했던 인원 중에서 2025년 엔지니어링 채용 인원의 약 20%를 재고용했습니다.

이 일로 파티를 여는 사람은 아무도 없습니다. 개발자들의 복귀를 축하하는 보도 자료도 없습니다. "우리가 틀렸습니다"라고 말하는 CTO의 LinkedIn 게시물도 없습니다. 하지만 채용 데이터는 홍보(PR) 팀이 말하지 않는 이야기를 들려주고 있습니다.

요약(TL;DR): AI는 코드 작성자(code-writers)를 대체했습니다. 하지만 AI는 컨텍스트 보유자(context-holders), 즉 시스템이 왜 그런 방식으로 작동하는지, 어디에 문제가 숨겨져 있는지, 그리고 코드베이스(codebase)의 어느 부분을 금요일에 절대 건드리면 안 되는지를 아는 사람들은 대체할 수 없었습니다. 이제 그 사람들에게 다시 연락이 오고 있습니다.

이론은 깔끔했습니다. 코드베이스는 그렇지 않았습니다.

해고 뒤에 숨겨진 논리는 표면적으로는 합리적이었습니다. AI 도구는 코드를 빠르게 생성합니다. 코드를 작성하는 인간을 줄이고 AI가 작성하는 비중을 높이면, 산출량은 대략 동일하게 유지되면서 급여 항목은 줄어듭니다. 깔끔한 차익 거래(arbitrage)였습니다.

이 이론에는 약 18개월이 지나서야 부정할 수 없게 된 한 가지 결함이 있었습니다.

코드를 작성하는 것과 소프트웨어를 개발하는 것은 같은 것이 아닙니다.

AI는 코드를 생성할 수 있습니다. 그것은 빠르게, 그리고 아주 많이 생성합니다. 하지만 실제로 AI가 생성한 것은 고립된 상태에서는 작동하지만, 실제 시스템과 맞닿는 순간 조용히 폭발해 버리는 코드였습니다. IBM Research의 연구에 따르면, 개발 팀 10곳 중 4곳이 AI 생성 코드를 기존 인프라(infrastructure)에 통합할 때 호환성 문제를 보고했습니다. 단순히 "경고가 떴다"는 수준이 아닙니다. 서비스를 중단시키는 수준의 통합 실패(integration failures)였습니다.

• 구문(syntax)은 문제가 없었습니다. Gartner의 조사에 따르면, AI 생성 코드 오류의 50% 이상은 알고리즘 버그나 타입 오류(type errors), 오프 바이 원(off-by-one) 실수 때문이 아니라 비즈니스 컨텍스트(business context)의 부재와 관련이 있었습니다. 코드는 진공 상태에서는 기술적으로 정확했지만, 그것이 투입된 실제 시스템 내에서는 틀렸습니다.

AI는 결제 서비스가 왜 웹훅(webhooks) 대신 폴링(polling)을 사용하는지 알지 못했습니다. 그 결정이 몇 년 전 회사에 주말 내내 서비스 중단(downtime)을 초래했던 벤더(vendor)의 버그로부터 비롯되었다는 사실도 몰랐습니다. 두 서비스가 캐시(cache)를 공유한다는 점, 특정 테이블이 배치 작업(batch jobs) 중에 잠긴다는 점, 혹은 아무도 건드리지 않는 "레거시(legacy)" 모듈이 레거시인 데에는 다 이유가 있다는 사실도 알지 못했습니다.

AI는 코드베이스(codebase)를 읽었습니다. 하지만 코드베이스의 역사를 이해하지는 못했습니다. 이 둘은 완전히 다른 것입니다.

이것을 마치 설계도에는 없지만 건물의 하중을 지탱하는 내력벽이 있다는 사실을 전혀 모르는 채, 오직 명세서(spec)대로만 빠르고 저렴하게 건물을 짓는 계약업자를 고용하는 상황이라고 생각해보십시오. 그 벽은 2019년에 구조 엔지니어가 내린 결정 때문에 존재하지만 기록으로 남지 않은 것입니다. 계약업자는 그 벽을 제거합니다. 건물은 즉시 무너지지 않습니다. 6개월 뒤 누군가 2층에 무게를 더했을 때 무너집니다.

해고된 개발자들은 바로 그 벽의 존재를 알고 있었던 사람들이었습니다. AI는 설계도를 읽었지만, 그 벽이 존재한다는 사실은 전혀 몰랐습니다.

아무도 두 번 확인하지 않았던 생산성 계산법

개발자를 AI로 대체하는 것에 대한 ROI (투자 대비 수익) 사례는 특정한 가정 위에 세워졌습니다. 즉, AI 도구가 남은 엔지니어들을 극적으로 더 빠르게 만들거나, 혹은 그만큼의 인력이 아예 필요 없게 만들 것이라는 가정이었습니다. 어느 쪽이든 결과적으로 산출량은 늘어나고 비용은 줄어든다는 논리였습니다.

하지만 두 가지 가정 모두 성립하지 않았습니다.

한 연구에 따르면, 숙련된 엔지니어들은 AI 도구를 사용할 때 도구 없이 작업할 때보다 실제로는 19% 더 느려졌습니다. 업무에 압도당하는 주니어 개발자들이 아니었습니다. AI 도구로부터 가장 많은 가치를 끌어낼 것으로 기대되는 바로 그 사람들인 시니어 엔지니어들이, 오히려 그 도구 때문에 더 느려진 것입니다. 도구들은 겉보기에는 그럴싸해 보이는 제안을 생성했지만, 그 이면에는 시간이 많이 소요되는 검증 과정이 필요했습니다. AI의 결과물을 신뢰할 수 있을 만큼 주의 깊게 읽는 것은, 직접 코드를 작성하는 것보다 더 오래 걸린다는 사실이 밝혀졌습니다.

오류율이 문제를 더욱 악화시켰습니다.

• AI가 생성한 코드는 사람이 작성한 코드보다 최대 1.7배 더 많은 오류를 포함하고 있었습니다. 단순히 조금 더 많은 수준이 아니었습니다. 거의 두 배에 달했습니다. 그리고 그 오류들은 항상 명백한 것도 아니었습니다. 코드 리뷰를 통과하고, 테스트를 견뎌낸 뒤, 3주 후 특정 엣지 케이스 (edge case)가 마침내 트리거될 때 운영 환경 (production)에서 나타나는 그런 종류의 오류들이었습니다.
• AI 도구를 적극적으로 도입한 팀은 결과적으로 이전보다 38% 더 많은 코드를 유지보수해야 했습니다. AI는 빠르게 배포했습니다. 그리고 인간은 배포된 것을 정리하는 데 수개월을 보냈습니다.

여기서 인턴 비유는 거의 지나칠 정도로 정확합니다. 당신은 매우 빠르게 타이핑하고, 절대 지치지 않으며, 엄청난 양의 결과물을 만들어내는 누군가를 고용했습니다. 문제는 이제 시니어 엔지니어가 무언가를 구축하는 대신, 하루의 대부분을 그 결과물을 검토하는 데 쓰고 있다는 점입니다. 당신은 시니어 엔지니어의 업무량을 줄인 것이 아닙니다. 그 업무를 덜 가치 있고 더 소모적인 방향으로 재지정했을 뿐입니다.

축하합니다. 이제 당신에게는 40% 더 많은 코드와, 새로운 기능은 전무하며, 매우 지친 스태프 엔지니어(staff engineer) 한 명이 남았습니다.

GitHub의 한 연구에 따르면

AI는 그러한 루프 (loop)를 가지고 있지 않습니다. AI는 출력값이 올바른지 여부와 상관없이 동일한 신뢰 수준 (confidence level)으로 결과물을 생성합니다. 프로젝트 첫날에 저지르는 실수와 90일째에 저지르는 실수는 구조적으로 동일합니다. AI는 실패를 경험하지 않기 때문에 실패로부터 경험을 축적하지 않습니다. 그저 다음 토큰 (token)을 생성할 뿐입니다.

당신의 팀에서 4년 동안 근무한 시니어 개발자 (senior dev)를 생각해 보십시오. 그들에게 왜 인증 서비스 (auth service)에 그런 이상한 재시도 로직 (retry logic)이 있는지 물어본다면, 그들은 연쇄 장애 (cascade failure), 새벽 3시의 장애 대응 호출 (incident call), 압박 속에서 내렸지만 결과적으로 옳았던 결정, 그리고 지금이라면 다르게 했을 세 가지 일에 대한 이야기를 들려줄 것입니다. 그 이야기는 코드베이스 (codebase)에 없습니다. 문서 (docs)에도 없습니다. 그것은 전적으로 그들의 머릿속에 존재하며, 그들이 내리는 모든 결정의 형태를 결정합니다.

AI는 README를 읽었습니다. 하지만 장애 상황 (incidents)을 겪으며 살아남지는 못했습니다.

이는 AI가 생성한 코드에 영구적인 인간의 감독 (human supervision)이 필요함을 의미합니다. 도구가 성숙해지는 동안 거쳐 가는 과도기적 단계로서가 아닙니다. 모델이 개선됨에 따라 나아질 무언가도 아닙니다. 판단력을 만들어내는 피드백 루프 (feedback loop)를 닫지 않은 채 확신에 찬 출력물을 생성하는 시스템의 근본적인 특성입니다.

누군가는 그 루프를 닫아야 합니다. 그 누군가는 바로 개발자 (developer)입니다.

개발자들을 해고한 기업들은 루프를 닫아야 할 필요성을 없앤 것이 아닙니다. 그들은 단지 루프를 열어둔 채, 분기 실적이 나올 때까지 아무도 눈치채지 못하기를 바랐을 뿐입니다.

재고용이 실제로 드러내는 것

그 누구도 잘못을 인정하지 않고 있습니다. 헤드라인을 장식했던 전략이 틀렸을 때 대기업들이 대처하는 방식은 그렇지 않습니다. 대신 그들이 하고 있는 일은 그 어떤 인정보다 더 많은 것을 드러내고 있습니다. 바로 채용 공고를 통해 보여주고 있는 것입니다.

부메랑은 이미 움직이고 있습니다. 일부 기업에서는 신규 채용 인원의 약 40%가 AI 피벗 (AI pivot) 이후 해고되었던 전직 직원들입니다. Google은 2025년 엔지니어링 신입 인원의 약 20%를 이전에 해고했던 인원들로 다시 채용했습니다. 공식적인 발표도, 인정도 없었습니다. 그저 리크루터의 이메일과 약간은 어색한 복귀 첫 주가 있었을 뿐입니다.

하지만 실제로 흥미로운 점은 '누가' 재채용되고 있는가 하는 점입니다.

• 새로운 기능을 출시할 주니어 엔지니어 (junior engineers)가 아닙니다. 기존 시스템을 이해하고, AI의 결과물을 지능적으로 감독할 수 있으며, AI가 확실하게 생성하지만 스스로는 잡아낼 수 없는 유형의 오류들을 포착할 수 있는 시니어 엔지니어 (senior engineers)입니다.
• 자리를 채우기 위한 단순 인력이 아닙니다. 기업의 54% 이상이 주니어 직무를 줄이는 동시에 시니어 개발자 채용을 구체적으로 늘릴 계획이라고 밝혔습니다.

엔지니어링 팀의 구조가 변하고 있지만, 이는 원래의 가설이 예측했던 것과는 정반대 방향으로 움직이고 있습니다. AI는 숙련된 엔지니어를 대체하고 있지 않습니다. 대신 미래의 숙련된 엔지니어를 길러내는 파이프라인 역할을 했던 엔지니어링 초급 업무 (entry-level work)를 대체하고 있습니다. 이는 나무를 심는 것을 멈춘 뒤, 그늘이 없다는 사실에 놀라는 상황이 되기 전까지는 해결된 문제처럼 들릴 것입니다.

부메랑 채용 (boomerang hires)이 성공하는 데에는 한 가지 구체적인 이유가 있습니다. 그들은 AI가 코드베이스 (codebase)를 읽어서는 배울 수 없는 맥락 (context)을 이미 알고 있다는 점입니다. 그들은 왜 특정 아키텍처 결정 (architectural decisions)이 내려졌는지, 시스템이 대규모 환경 (at scale)에서 무엇을 처리하도록 설계되었는지, 위험한 가정들이 어디에 숨어 있는지, 그리고 잘못된 설정 값 (config value)을 변경했을 때 어떤 서비스가 조용히 오작동할지를 알고 있습니다. 그러한 지식은 AI가 접근할 수 있는 그 어떤 파일에도 존재하지 않습니다. 그것은 시스템의 역사를 함께해 온 사람들의 머릿속에 존재합니다.

조직의 기억 (Institutional memory)이 실제적인 경쟁 자산임이 드러난 것입니다. 누가 알았겠습니까.

개발자를 AI로 가장 빠르게 대체하려 했던 기업들이 이제는 그들을 다시 채용하기 위해 가장 빠르게 움직이고 있습니다. 이는 AI 코딩 도구가 제대로 작동하지 않기 때문이 아닙니다. 그것들은 잘 작동합니다. 코드를 빠르게 생성하고 반복적인 작업을 잘 처리하며, 개발 워크플로 (workflow)의 특정 부분을 진정으로 가속화합니다. 하지만 그것들은 인간의 판단 (human judgment)을 대체하는 것이 아니라, 그 위에 얹혀지는 레이어 (layer)로서 작동합니다.

이 실험은 실제적인 결과와 함께 대규모로 진행되었습니다. 그 결과는 보도 자료 어디에도 나타나지 않더라도 채용 데이터에서는 명확히 확인됩니다.

그래서 이 사실로 실제로 무엇을 해야 할까요?

몇 년 전 유행했던 "90% 대체" 이론은 구체적이고 교훈적인 방식으로 틀렸습니다. 그 이론은 코드를 작성하는 것이 엔지니어가 제공하는 핵심 가치라고 가정했습니다. 하지만 알고 보니 핵심 가치는 이름을 붙이기 더 어렵고 복제하기 훨씬 더 어려운 무언가였습니다.