지난 몇 년 동안 필자는 이사회 회의실에서 같은 이야기가 스스로 설득력을 얻는 장면을 지켜봤다. “소프트웨어는 곧 공짜가 될 것이다”라는 이야기이다. LLM은 코드를 작성할 수 있고, 코드 작성은 개발자가 하는 일의 대부분을 차지한다는 논리다. 이 논리에 따르면, 기업은 개발자를 줄이고 LLM에 백로그를 맡겨 필요한 속도에 맞춰 맞춤형 비즈니스 시스템을 찍어낼 수 있다. 이런 주장을 믿는다면, 사람을 AI로 가장 빨리 대체하는 기업이 승리한다는 결론에 도달한다.

이런 낙관적 야망은 기업 시스템이 실제로 작동하는 방식이라는 현실과 충돌하고 있다. 폭발하고 있는 것은 AI 코딩이라는 역량 자체가 아니다. AI를 개발자 증폭기가 아니라 개발자 대체재로 취급하는 기업의 의사결정이다. LLM은 분명히 유용하다. 하지만 LLM을 엔지니어링 판단의 대체재로 쓴 기업은 비용과 복잡성을 없앤 것이 아니라는 사실을 깨닫게 된다. 비용과 복잡성을 다른 곳으로 옮기고 더 키웠을 뿐만 아니라, 많은 경우 유지보수할 수도 없는 AI 생성 코드 계층 아래에 묻어버렸을 뿐이다.

혹하게 만들지만, 불완전한 이야기

이런 결정은 진공 상태에서 내려지지 않는다. 기업은 시장에서 가장 목소리가 큰 집단인 AI 업체의 최고 경영자와 클라우드 업체의 최고 경영자, 솔루션 업체, 인플루언서, 그리고 다음 예산을 정당화하려면 혁신 서사가 필요한 내부 옹호자의 독려와 영향을 받는다. 메시지는 노골적이다. 코더는 점점 환영받지 못하는 존재가 되고 있다. 프롬프트가 새로운 프로그래밍 언어이다. 기업의 AI 공장은 CI/CD 시스템이 빌드를 출력하듯 운영 소프트웨어를 출력할 것이라는 주장이다.

이런 서사에는 숙련된 아키텍트라면 누구나 아는 핵심 세부 사항이 빠져 있다. 소프트웨어는 단지 타이핑이 아니다. 진짜 어려운 부분은 충돌 없는 요구사항과 신뢰할 수 있는 데이터, 보안, 성능, 운영이다. 트레이드오프에는 책임이 따르며, 설계 결정에서 사람을 제거한다고 해서 위험이 사라지지 않는다. 오히려 문제를 조기에 발견하고 설명하고 수정할 수 있는 당사자를 없애는 결과를 낳는다.

어느 순간 작동하지 않는 코드

필자가 반복해서 본 패턴은 이렇다. 한 팀이 먼저 LLM을 단순 반복 업무에 사용하기 시작한다. 이 단계는 잘 돌아간다. 다음에는 모듈 생성에 사용한다. 적어도 처음에는 이 단계가 더 잘 되는 것처럼 보인다. 그러면 경영진은 당연한 질문을 던진다. AI가 모듈을 생성할 수 있다면 왜 서비스 전체와 워크플로우 전체, 애플리케이션 전체를 만들지 못하느냐는 질문이다. 곧 기업 내부에는 아키텍처 검토와 성능 엔지니어링, 운영 계획의 마찰 없이 전체 시스템을 만들 수 있는 권한을 가진 “미니 기업”이 생겨난다. 그 순간에는 속도처럼 느껴진다. 돌아보면 가격이 매겨지지 않은 부채일 뿐인 경우가 많다.

불편한 사실은 AI 생성 코드가 대체로 비효율적이라는 점이다. AI 생성 코드는 대개 자원을 과도하게 할당하고 과도하게 추상화하고 로직을 중복시키고, 숙련된 엔지니어가 고통스러운 경험을 통해 배우는 미묘한 최적화 기회를 놓친다. 결과를 만들어낸다는 좁은 의미에서는 “정확할” 수 있다. 하지만 SLA를 충족할 수 있을까? 엣지 케이스를 처리할 수 있을까? 업그레이드를 견딜 수 있을까? 비용 제약 안에서 운영될 수 있을까? 이런 질문을 수십 개 서비스에 곱하면 결과는 뻔하다. 클라우드 비용은 매출보다 더 빠르게 증가하고 지연 시간은 릴리스가 거듭될수록 조금씩 늘어나며, 임시방편은 영구 의존성으로 굳어진다.

기술 부채는 사라지지 않는다

전통적인 기술 부채는 적어도 그 부채를 만든 사람이 볼 수 있다. 어떤 이유로 지름길을 택했는지, 어떤 가정을 했는지, 되돌리려면 무엇을 바꿔야 하는지 기억하고 있다. AI가 만든 시스템은 다른 종류의 부채를 만든다. 작성 주체가 없는 부채이다. 공유된 기억이 없고 일관된 스타일도 없다. 코드베이스 전체를 관통하는 일관된 근거가 없다. “테스트를 통과한” 결과물만 있을 뿐이다. 테스트가 실제로 작성됐다는 전제가 붙는다. “작동한” 배포만 있을 뿐이다. 가시성이 실제로 계측됐다는 전제가 붙는다.

여기에 운영 현실까지 더해보자. 기업이 이런 시스템을 견적 산출과 청구, 공급망 의사결정, 이상 거래 탐지 워크플로우, 보험금 청구 처리, 규제 보고 같은 핵심 기능에 의존하면 판돈은 생존 문제가 된다. 문제가 생겼다고 해서 모든 것을 간단히 다시 쓸 수는 없다. 이미 존재하는 것을 패치하고 최적화하고 보안 조치를 해야 한다. 하지만 코드가 대규모로 생성됐고 일관성 없는 패턴으로 이어 붙여졌고, 모델 자체가 수십 차례 반복하면서 다시 리팩터링했다면 누가 그런 일을 할 수 있을까? 어디서 시작해야 할지 아는 사람조차 없을 것이다. 시스템이 사람이 이해할 수 있게 설계되지 않았기 때문이다. 빨리 만들어내도록 설계됐을 뿐이다.

바로 이런 식으로 기업은 스스로 궁지에 몰린다. 기업은 동시에 미션 크리티컬하면서도 사실상 유지보수할 수 없는 소프트웨어를 떠안게 된다. 소프트웨어는 돌아간다. 가치를 만들어 내기도 한다. 동시에 돈이 새고, 위험이 쌓이고, 변화를 거부한다.

비용 청구서와 불안정성, 보안 위험

개발자 감축을 정당화하는 경제 논리는 흔히 가장 큰 비용을 인건비로 가정한다. 하지만 실제로 현대 기업에서 가장 큰 비용은 운영 비용인 경우가 많다. 클라우드 컴퓨트와 스토리지, 데이터 반출, 서드파티 SaaS 확산, 사고 대응, 그리고 불안정한 시스템이 만드는 조직적 마찰이 여기에 해당한다. AI 생성 코드가 비효율적이면, 단지 더 느리게 실행되는 데서 끝나지 않는다. 더 많이 실행되고 더 넓게 확장되며, 진단 비용이 비싼 기묘한 방식으로 장애를 일으킨다.

다음은 보안과 컴플라이언스 측면이다. AI 생성 코드는 라이브러리를 무심코 끌어오거나 비밀 정보를 잘못 처리하거나 민감한 데이터를 로그에 남기거나, 인증과 권한 부여 패턴을 미묘하게 잘못 구현할 수 있다. 거버넌스를 우회하는 섀도우 IT를 만들 수도 있다. 당장에는 작동하지만 기업의 장기 플랫폼 방향성과 충돌하는 코드형 인프라 변경을 만들어낼 수도 있다. 보안팀은 검토 역량보다 더 빠르게 돌아가는 코드 공장을 따라잡을 수 없다. 특히 기업이 더 안전한 기본값을 만들기 위해 원래 보안팀과 협업했어야 할 엔지니어링 인력을 동시에 줄였다면 더욱 그렇다.

결국 기업은 속도라는 환상에 대한 대가를 더 높은 컴퓨트 비용과 더 많은 장애, 더 큰 업체 종속, 더 큰 위험으로 치르게 된다. 아이러니가 아닐 수 없다. 기업은 비용을 줄이겠다며 개발자 인력을 감축한 뒤, 절감한 돈과 그 이상을 클라우드 자원과 화재 진압식 대응에 쓰게 된다.

피해는 현실이다

지금 많은 기업에서 예측 가능한 다음 장면이 펼쳐지고 있다. 개발자를 다시 채용하고 있다. 조용히 채용하는 경우도 있고 공개적으로 채용하는 경우도 있으며, 초기 인력 전략이 잘못됐다는 사실을 인정하지 않으려고 플랫폼 엔지니어 또는 AI 엔지니어라는 이름으로 채용하는 경우도 있다. 이렇게 돌아온 팀은 IT에서 가장 화려하지 않은 일을 맡는다. 생성된 시스템을 이해 가능하고 관찰 가능하고 테스트 가능하고, 비용 효율적으로 만드는 일이다. 처음부터 있었어야 할 가드레일을 구축하라는 주문도 받는다. 코딩 표준과 참조 아키텍처, 의존성 통제, 성능 예산, 배포 정책, 데이터 계약이 그런 가드레일이다.

하지만 문제는 여기서 끝나지 않는다. 이미 발생한 피해를 언제나 빠르게 되돌릴 수 있는 것은 아니다. AI가 생성한 시스템이 매출 운영의 중추가 되면, 기업은 가동 시간과 비즈니스 연속성 요구에 묶이게 된다. 리팩터링은 마라톤을 뛰고 있는 환자를 수술하는 일과 비슷해진다. 조직은 회복할 수 있다. 그러나 엉망진창을 만들어낸 초기 AI 전환보다 회복에 훨씬 더 오랜 시간이 걸리는 경우가 많다. 비용 곡선도 잔인하다. 기다리는 시간이 길수록 비즈니스 의존도는 더 커지고, 시정 비용도 더 비싸진다.

기술 업계의 가장 오래된 교훈

너무 좋아 보여서 믿기 어려운 것이 있다면, 대부분 사실이 아니다. 그렇다고 AI 코딩이 막다른 길이라는 뜻은 아니다. 기업이 자동화와 대체를 혼동하는 일을 멈춰야 한다는 뜻이다. AI는 작업 자동화에는 탁월하다. 결과를 책임지는 데는 적합하지 않다. AI는 코드 초안을 만들고 패턴을 번역하고 테스트를 생성하고 로그를 요약하고, 반복 업무를 더 빠르게 처리할 수 있다. 뛰어난 엔지니어가 더 빨리 움직이고 더 많은 문제를 조기에 잡도록 도울 수도 있다. 하지만 아키텍처와 데이터 모델링, 성능 엔지니어링, 보안 태세, 운영 우수성에 대한 인간의 책임까지 대체할 수는 없다. 이런 문제는 타이핑 문제가 아니다. 판단의 문제이다.

2026년 이후 승리할 기업은 개발자를 없앤 기업이 아닐 것이다. 개발자와 AI 도구를 짝지어 쓰고 플랫폼 규율에 투자하고 측정 가능한 품질과 유지보수성, 비용 효율성, 복원력, 보안을 요구하는 기업이 승리할 것이다. 그런 기업은 모델을 직원이 아니라 전동 공구로 다룰 것이다. 그리고 소프트웨어는 단순히 생산되는 것이 아니라 보살펴지고 관리되는 것이라는 사실을 잊지 않을 것이다.

dl-itworldkorea@foundryco.com