LLM(Large Language Models)과 AI 에이전트에 대한 가장 흔한 주장 중 하나는 소프트웨어 개발 비용을 획기적으로 줄여줄 것이라는 점입니다. 더 많은 엔지니어를 고용하는 대신, 단순히 모델에 작업을 할당하고 몇 분 안에 완료할 수 있다는 것입니다.

저도 그 말에 상당한 진실이 있다고 생각합니다.

하지만 한 가지 중요한 주의 사항이 있습니다.

기술 부채가 확장되던 방식

수년 동안 많은 대규모 소프트웨어 프로젝트의 성장 패턴은 다음과 같았습니다:

기술 부채 (Technical debt) → 개발 속도 저하 → 더 큰 엔지니어링 팀 → 더 많은 커뮤니케이션 오버헤드 (Communication overhead) → 더 많은 회귀 (Regressions) → 훨씬 더 많은 기술 부채.

시스템이 복잡해짐에 따라 기업들은 더 많은 엔지니어를 고용했습니다. 하지만 팀이 추가될 때마다 조정 비용이 증가하고, 더 많은 커뮤니케이션 경로가 생겨나며, 점진적으로 개발 속도가 느려졌습니다.

기술 부채는 결코 사라지지 않았습니다.

기업들은 단순히 더 많은 인력을 통해 그 비용을 지불했을 뿐입니다.

LLM으로 인해 변한 것

LLM은 문제를 제거하지 않습니다.

그들은 자원 중 하나의 가격을 바꿀 뿐입니다.

이제 기업은 엔지니어 5명을 더 고용하는 대신, 수천 배 더 많은 컴퓨팅 자원 (Compute)을 "고용"할 수 있습니다.

모델이 어려움을 겪을 때, 우리는 컨텍스트 윈도우 (Context window)를 늘리거나, 더 많은 에이전트 루프 (Agent loops)를 추가하거나, 더 큰 모델로 교체하거나, 단순히 솔루션을 여러 번 재생성합니다.

이것은 한동안 개발 속도를 유지해 줄 수 있습니다.

하지만 근본적인 문제는 남아 있습니다.

LLM은 시스템 복잡성을 줄이지 않습니다.

저는 이렇게 표현하고 싶습니다:

우리는 과거에 기술 부채를 사람으로 지불했습니다. 이제 우리는 그것을 토큰 (Tokens)으로 지불할 수 있습니다. 부채는 사라진 것이 아니라, 단지 통화(Currency)가 바뀌었을 뿐입니다.

왜 개발 비용은 여전히 비싸지는가

몇 가지 요인이 우리를 동일한 결과로 몰아넣습니다.

컨텍스트가 점점 더 비싸집니다

프로젝트가 성장함에 따라, 모델이 정확한 변경을 수행하기 위해서는 더 많은 파일, 의존성 (Dependencies), 비즈니스 규칙, 그리고 과거의 컨텍스트 (Context)가 필요합니다.

결국, 작업을 해결하는 비용은 작업 그 자체에 의해 결정되는 것이 아닙니다.

시스템을 이해하는 비용에 의해 결정됩니다.

이해하기가 더 어려워집니다

LLM(Large Language Models)은 깨끗하고 잘 구조화된 코드베이스(codebases)에서는 놀라울 정도로 뛰어난 성능을 발휘합니다. 하지만 많은 기업용 시스템이 실제로 이러한 기준을 충족하고 있을까요?

프로젝트가 거대한 서비스, 순환 의존성(circular dependencies), 숨겨진 부작용(side effects), 그리고 수년간의 아키텍처 타협으로 가득 차 있다면, 모델은 단순히 무슨 일이 일어나고 있는지 파악하는 데 훨씬 더 많은 연산(computation)을 소비해야 합니다.

동시에, 실수가 발생할 확률도 높아집니다.

검증(Verification)이 병목 현상이 됩니다

코드가 단 몇 초 만에 생성된다 하더라도, 여전히 검토(review)와 테스트를 거쳐야 하며 안전하게 통합(integration)되어야 합니다. 만약 아키텍처가 형편없다면, 검증 비용은 생성 속도보다 더 빠르게 증가하기 시작합니다.

이것이 바로 코드를 더 빨리 생성한다고 해서 소프트웨어를 더 빨리 출시할 수 있다는 의미가 아닌 이유입니다.

회귀(Regressions)는 사라지지 않습니다

시스템에 모듈성(modularity)과 강력한 테스트 커버리지(test coverage)가 부족하다면, AI는 인간보다 훨씬 더 빠르게 회귀(regressions)를 유발할 수 있습니다.

이유는 간단합니다. 단위 시간당 훨씬 더 많은 코드를 생성하기 때문입니다.

복잡한 시스템에 더 많은 변경 사항을 적용할수록, 무언가 고장 날 확률은 더 커집니다.

왜 문제를 알아차리기 더 어려운가

이 지점이 AI 시대가 이전 세대와 다른 부분입니다.

과거에는 기업들이 채용 예산과 가용 엔지니어 수에 의해 제약을 받았습니다.

오늘날 그 제약은 눈에 덜 보입니다.

조직은 팀을 확장하는 대신, 추론(inference), 더 큰 컨텍스트 윈도우(context windows), 에이전트 루프(agent loops), 반복적인 생성(repeated generations), 자동화된 테스트(automated testing), 그리고 추가적인 검증(validation)에 대한 지출을 점진적으로 늘려갑니다.

외부에서 보기에는 생산성이 높게 유지되는 것처럼 보입니다. 하지만 실제로는 각 추가 기능의 비용이 조용히 증가하고 있습니다.

문제는 사라진 것이 아닙니다. 단지 더 잘 위장되었을 뿐입니다.

AI 시대의 진정한 희소성
가장 흥미로운 결론은 토큰 비용과는 거의 관련이 없습니다.

진정한 희소 자원은 코드 생성이 아닙니다.

그것은 바로 **아키텍처 엔트로피(architectural entropy)**입니다.

LLM은 코드 생산량을 놀라울 정도로 잘 확장(scale)합니다.

하지만 시스템 자체의 복잡성을 줄이는 데에는 거의 기여하지 못합니다.

그리고 시스템이 인간이 이해하기에 너무 복잡해지면, 점차 AI가 이해하기에도 너무 복잡해집니다.

그때부터 모든 새로운 변경 사항에 대한 비용이 선형적(linearly)이 아니라 지수적(exponentially)으로 증가하기 시작합니다.

그 시점에는 비용을 개발자의 급여로 측정하든, 수백만 개의 소모된 토큰(tokens)으로 측정하든 상관이 없습니다.

AI 시대의 가능한 법칙

저는 이를 다음과 같이 요약하겠습니다:

과거에 엔지니어링 인력의 선형적 증가를 요구했던 모든 기술 부채(technical debt)는, 이제 우선 토큰 소비의 선형적 증가를 요구하게 될 것이며, 결국 동일한 결과로 이어질 것입니다: 즉, 변경 비용의 지수적 증가입니다. 유일한 차이점은 제한 요인이 엔지니어의 수에서 시스템을 이해하는 데 필요한 컴퓨팅(compute) 양으로 전환된다는 것입니다.

만약 이 가설이 맞다면, AI 시대의 가장 큰 경쟁 우위는 코드를 더 빠르게 생성하는 것이 아닐 것입니다.

그것은 인간과 AI 모두가 이해할 수 있을 만큼 충분히 단순함을 유지하는 아키텍처(architecture)를 유지하는 것이 될 것입니다.

향후 10년 동안, 단순한 코딩 속도보다 MHO에게는 바로 그것이 소프트웨어 개발의 진정한 병목 현상(bottleneck)이 될 수 있습니다.