많은 이들이 AI가 소프트웨어 개발 비용을 훨씬 낮춰줄 것이라고 말합니다. 모델이 엔지니어를 대체하고 몇 분 만에 작업을 끝내는 모습을 상상하곤 합니다. 그 이야기는 매혹적이지만, 전적으로 사실은 아닙니다. 소프트웨어 구축의 경제학은 사라진 것이 아니라 변화했을 뿐입니다. 첫 번째 코딩 어시스턴트가 출시되었다고 해서 기술 부채가 증발한 것은 아닙니다. 우리는 단지 그 부채를 조달하는 새로운 방법을 찾았을 뿐입니다.
과거의 청구서: 인원수
수십 년 동안 기술 부채는 익숙한 파멸의 루프를 만들어냈습니다. 코드베이스는 점점 취약해졌습니다. 며칠이면 끝날 기능 구현에 몇 주가 걸리기 시작했습니다. 마감 기한이 밀리자 경영진은 더 많은 채용 공고를 냈습니다. 하지만 팀 규모가 커질수록 속도는 더욱 느려졌습니다. 협업 오버헤드는 급증하고 스탠드업 미팅은 늘어났으며, 콘웨이의 법칙(Conway’s Law)이 작용하기 시작했습니다. 즉, 소프트웨어가 이를 만드는 사람들의 소통 부재를 그대로 반영하기 시작한 것입니다. 더 많은 버그가 발생했고, 패치를 추가할 때마다 복잡성이 층층이 쌓였습니다. 기업들은 자신들이 아는 유일한 화폐인 인건비로 이 부패의 대가를 치렀습니다. 비용은 명확했습니다. 매 분기 예산 검토 때마다 그 비용이 눈에 띄게 나타났습니다.
새로운 청구서: 토큰과 컨텍스트
생성형 AI는 이 사이클을 끊어내지 못했습니다. 그저 대안적인 결제 방식을 도입했을 뿐입니다. 마찰을 돌파하기 위해 엔지니어 다섯 명을 채용하는 대신, 이제 기업은 더 많은 컴퓨팅 자원을 사용하기 위해 신용카드를 긁습니다. 증상은 달라 보일지 몰라도 근본적인 질병은 동일합니다.
모델이 내부 API를 환각(hallucination)하거나, 중요한 엣지 케이스를 놓치거나, 잘못된 이유로 통과되는 테스트를 생성하는 등 실패하기 시작할 때, 리팩터링을 하려는 반응은 드뭅니다. 대신 추론(inference)에 돈을 쓰는 것이 일반적인 반응입니다. 팀들은 컨텍스트 윈도우(context-window)를 업그레이드하거나, 멀티 에이전트 재시도 루프를 엮거나, 더 큰 프런티어 모델로 워크로드를 전환하거나, diff가 봐줄 만해질 때까지 재생성 버튼을 연타합니다. 이러한 전술은 한두 번의 스프린트 동안 겉보기 속도를 유지해 줍니다. Jira 보드는 초록색을 유지합니다. 하지만 그동안 실제 아키텍처는 그대로 방치됩니다. 엉킨 의존성, 변경 가능한 전역 상태, 그리고 현재 팀원 중 누구도 완전히 이해하지 못하는 거대한 모놀리스(monolith)가 그대로 남습니다.
더러운 코드가 토큰 비용을 높이는 이유
대규모 언어 모델은 깔끔한 추상화 구조 위에서 가장 잘 추론합니다. 하지만 대부분의 기업용 저장소(repository)는 고고학 유적지와 같습니다. 순환 패키지 의존성, 초기화 스크립트에 숨겨진 사이드 이펙트, 그리고 데이터베이스 트리거, 미들웨어 계층, 프런트엔드 컴포넌트에 흩뿌려진 비즈니스 로직이 가득합니다. 이런 환경에서 모델은 새로운 로직을 작성하는 데 에너지를 쓰는 것이 아니라, 시스템을 이해하는 데 토큰을 소모합니다.
128,000개 토큰의 컨텍스트 윈도우 중 상당 부분이 시스템의 구조를 메모리에 유지하는 데만 소비될 수 있습니다. 실제 문제 해결에 쓸 수 있는 부분은 아주 일부분뿐입니다. 이는 구조 엔지니어에게 매 계산마다 기존 건물의 설계도를 기억에 의존해 다시 그리게 하면서 새로운 층을 설계하라고 요구하는 것과 같습니다. 그 결과는 피상적인 해결책뿐입니다. 모델은 방을 먼저 청소할 권한이나 아키텍처적 컨텍스트가 없기 때문에, 눈앞에 보이는 난잡함을 그대로 복제할 뿐입니다.
빠른 출력, 느린 배포
단순한 생성 속도가 배포 속도로 이어지지는 않습니다. 아키텍처에 모듈성이 부족하다면, AI가 생성한 모든 변경 사항은 철저한 인간의 검토와 회귀 테스트(regression testing)를 요구합니다. 모델은 오후 한나절 만에 10개의 pull request를 만들어낼 수 있지만, 그 pull request들은 여전히 통합 환경, 보안 스캐너, 컴플라이언스 체크리스트, 프로덕션 카나리(production canaries)를 거쳐야 합니다. 명확한 모듈 경계가 없다면, AI는 기계적인 속도로 버그를 만들어냅니다. 공유 유틸리티를 수정하고, 미묘하게 잘못된 가정을 바탕으로 멀리 떨어진 세 곳의 호출 지점을 업데이트하며, 새벽 3시에 호출(page)을 받아야 겨우 발견할 수 있는 레이스 컨디션(race condition)을 유발할 수 있습니다. 병목 현상은 키보드에서 검증 파이프라인으로 이동하며, 그 파이프라인은 변경 사항의 양이 10배로 늘어나는 상황을 처리하도록 설계되지 않았습니다.
숨겨진 한계
AI 이전 시대의 명확한 한계는 채용 예산이었습니다. 적어도 그것은 스프레드시트에서 쉽게 확인할 수 있었습니다. 이제 제약 조건은 대부분의 재무 팀이 거의 추적하지 않는 세부 항목 속에 숨어 있습니다. 바로 추론 비용, 임베딩 저장소, 컨텍스트 윈도우 확장, 그리고 CI 러너를 마비시키는 자동화 테스트의 교착 상태입니다. 생산성 대시보드는 초록색으로 빛나지만, 새로운 기능 하나하나의 실제 비용은 조용히 복리로 쌓여갑니다.
아키텍처 엔트로피가 여기서 진정한 주범입니다. LLM은 코드 생산 규모를 훌륭하게 확장하지만, 복잡성을 줄여주지는 않습니다. 마이크로서비스를 정리하거나, 데드 코드를 제거하거나, 상속 계층 구조를 단순화하지 못합니다. 시스템이 인간이 논리적으로 파악하기 힘든 임계점을 넘어서면, AI 역시 어려움을 겪게 됩니다. 그 변곡점에서, 당신이