AI 시대인데 왜 소프트웨어는 늘지 않았을까 — 보이지 않는 코드의 폭발

AI 시대인데 왜 소프트웨어는 늘지 않았을까

AI가 개발자의 생산성을 바꾸고 있다는 사실 자체는 이제 더 이상 논쟁거리가 아니다. 코드 자동 완성은 이미 기본 기능이 되었고, 자연어로 요구사항을 설명하면 동작하는 코드가 생성되는 경험도 낯설지 않다. 일부 개발자는 기존보다 두 배, 열 배, 심지어 그 이상 빠르게 작업할 수 있다고 말한다. 실제로 간단한 웹 애플리케이션이나 자동화 스크립트는 몇 시간 안에 완성되는 경우도 흔해졌다. 이러한 변화만 놓고 보면 우리는 이미 소프트웨어 생산의 패러다임이 완전히 바뀐 시대에 들어온 것처럼 보인다.

그렇다면 자연스럽게 따라오는 질문이 있다. 이렇게 생산성이 증가했다면, 그 결과물은 어디에 있는가라는 질문이다. 생산성이 두 배가 되었다면, 단순하게 생각해도 세상에는 두 배의 소프트웨어가 존재해야 한다. 새로운 라이브러리, 새로운 서비스, 새로운 도구들이 눈에 띄게 증가해야 한다. 그러나 현실을 보면 그런 변화는 쉽게 감지되지 않는다. 오히려 우리가 사용하는 주요 라이브러리나 서비스는 여전히 익숙한 이름들이 대부분이고, 생태계 전체가 폭발적으로 확장되었다는 느낌은 들지 않는다.

이 지점에서 흥미로운 긴장이 발생한다. 한쪽에서는 분명히 개발 경험이 달라졌다고 말하고 있고, 다른 한쪽에서는 그 변화의 결과가 눈에 보이지 않는다고 말한다. 이 둘 중 하나가 틀린 것일까. 아니면 우리가 잘못된 방식으로 결과를 찾고 있는 것일까. 이 글은 바로 이 질문에서 출발한다. 그리고 이 질문은 단순히 “AI가 생산성을 높였는가”를 넘어서, 우리가 무엇을 ‘소프트웨어 생산’이라고 정의하고 있는가라는 더 근본적인 문제로 이어진다.

PyPI 데이터가 보여주는 것 — AI 효과는 보이지 않는다

이 질문에 대해 가장 직관적인 접근은 데이터를 보는 것이다. 실제로 소프트웨어가 늘어났다면, 그것은 어딘가에 기록되어 있을 것이다. 이때 자주 참고되는 지표 중 하나가 Python 생태계의 중심 저장소인 PyPI다. PyPI는 공개된 패키지의 수와 업데이트 내역을 지속적으로 축적하는 플랫폼이기 때문에, 장기적인 변화를 관찰하기에 적절한 대상이다. 이러한 이유로 Answer.AI에서 공개한 분석 글(https://www.answer.ai/posts/2026-03-12-so-where-are-all-the-ai-apps.html)은 이 문제를 이해하는 데 중요한 출발점이 된다.

이 분석에서 가장 먼저 확인한 것은 전체 패키지 수의 증가 추세였다. 결과는 예상과 달랐다. ChatGPT와 같은 생성형 AI가 등장한 이후에도, PyPI의 패키지 수 증가 곡선에는 뚜렷한 변화가 나타나지 않았다. 곡선은 여전히 완만하게 증가하고 있었고, 특정 시점을 기준으로 급격히 상승하는 구간은 존재하지 않았다. 즉, AI 등장 이후에 소프트웨어 생산이 폭발적으로 증가했다는 흔적은 보이지 않는다는 것이다.

그렇다면 패키지의 ‘수’가 아니라 ‘활동성’을 보면 어떨까. 분석은 여기서 한 단계 더 나아가, 실제로 많이 사용되는 상위 패키지들의 업데이트 빈도를 살펴본다. 여기서는 약간의 변화가 보인다. 최신 패키지일수록 첫 해에 더 많은 업데이트를 수행하는 경향이 나타난다. 하지만 이 변화 역시 AI 등장 이후에 갑자기 나타난 것이 아니라, 이미 몇 년 전부터 이어져 온 추세의 연장선에 가깝다. 지속적 통합(CI) 도구의 확산과 같은 다른 요인으로도 충분히 설명 가능한 수준이다.

흥미로운 지점은 따로 있다. 전체 패키지에서는 큰 변화가 없지만, AI와 관련된 패키지에 한정하면 업데이트 빈도가 눈에 띄게 증가한다는 것이다. 특히 인기 있는 AI 패키지의 경우, 연간 릴리스 횟수가 기존의 두 배 이상으로 증가한 사례도 확인된다. 이 결과는 단순히 “AI가 생산성을 높였다”는 서사를 지지하는 것처럼 보이지만, 동시에 다른 질문을 만들어낸다. 왜 이 효과는 전체가 아니라 특정 영역에만 집중되어 나타나는가.

이 지점에서 우리는 단순한 결론을 내리기 어렵게 된다. 데이터는 분명히 어떤 변화를 보여주고 있지만, 그것이 우리가 기대한 형태의 변화는 아니다. 전체 소프트웨어가 증가한 것이 아니라, 특정 영역에서만 활동이 강화되었기 때문이다. 따라서 이제 질문은 한 단계 더 깊어진다. 우리가 보고 있는 데이터는 과연 ‘전체 소프트웨어’를 제대로 반영하고 있는 것인가라는 질문이다.

직관과 데이터가 충돌하는 이유

이제 상황은 더욱 흥미로워진다. 한쪽에서는 개발자들이 실제로 더 빠르게 코드를 작성하고 있다고 말하고 있고, 다른 한쪽에서는 전체 소프트웨어 생산량이 크게 변하지 않았다고 말하고 있다. 이 두 주장 중 하나가 틀렸다고 단정하는 것은 쉽지만, 그렇게 결론을 내리기에는 양쪽 모두 충분히 설득력이 있다. 실제로 AI 도구를 사용해 본 경험이 있다면 생산성 향상을 체감하기 어렵지 않다. 동시에, 공개 생태계의 규모가 갑자기 두 배로 늘어난 것처럼 보이지 않는 것도 사실이다.

이 모순을 이해하기 위해서는 먼저 “무엇을 측정하고 있는가”를 분리해야 한다. 개발자가 느끼는 생산성은 개별 작업 단위에서의 효율이다. 코드 작성 속도, 디버깅 시간, 반복 작업 자동화와 같은 요소들이 여기에 포함된다. 반면 PyPI와 같은 지표는 공개된 패키지의 수와 유지 활동을 측정한다. 이 둘은 서로 연결되어 있지만, 동일한 것은 아니다. 즉, 생산 과정의 변화와 결과물의 분포는 반드시 같은 방식으로 나타나지 않는다는 것이다.

또 하나 중요한 차이는 “완성도의 기준”이다. 개발자가 AI를 통해 빠르게 만들어내는 것은 대부분 프로토타입 수준의 결과물이다. 특정 문제를 해결하기 위한 스크립트, 개인적인 생산성을 높이기 위한 도구, 혹은 짧은 시간 안에 검증을 위한 실험 코드가 여기에 해당한다. 이러한 결과물은 충분히 유용하지만, PyPI에 올라가는 패키지처럼 장기적으로 유지되고 재사용되는 형태와는 성격이 다르다. 따라서 생산성이 증가하더라도, 그 결과가 동일한 형태로 집계되지 않을 수 있다.

이 지점에서 중요한 통찰이 나온다. 우리는 지금까지 “소프트웨어 생산량”을 하나의 단일한 개념으로 생각해 왔지만, 실제로는 그렇지 않다. 공개되고 유지되는 소프트웨어와, 개인적으로 사용되고 사라지는 소프트웨어는 서로 다른 층위에 존재한다. 그리고 AI는 이 두 층위에 동일한 방식으로 영향을 주지 않는다. 오히려 변화는 특정 영역에 집중되어 나타난다.

따라서 지금 우리가 목격하고 있는 충돌은, 단순히 데이터와 체감의 불일치가 아니라 측정 대상의 불일치에서 발생하는 구조적 현상이다. 이 사실을 이해하는 순간, 문제의 방향이 바뀐다. 이제 더 이상 “AI가 생산성을 높였는가”를 묻는 것이 아니라, “그 생산성은 어디에 반영되고 있는가”를 추적해야 한다는 것이다. 그리고 이 질문은 다음 단계로 이어진다. PyPI와 같은 지표가 포착하지 못하는 영역은 무엇이며, 그 영역에서 실제로 어떤 변화가 일어나고 있는가.

측정의 한계 — PyPI는 무엇을 측정하지 못하는가

앞선 논의를 통해 드러난 것은 단순하다. PyPI 데이터는 틀리지 않았지만, 그 데이터가 전체를 설명하고 있지도 않다는 사실이다. 이제 질문은 더 명확해진다. PyPI는 무엇을 보고 있고, 동시에 무엇을 놓치고 있는가. 이 질문에 답하지 않으면 우리는 계속해서 잘못된 결론을 반복하게 된다. 왜냐하면 측정의 대상이 제한되어 있다면, 그 결과 역시 제한될 수밖에 없기 때문이다.

PyPI는 기본적으로 “공개된 패키지”를 중심으로 구성된 생태계다. 단순히 코드를 작성하는 것만으로는 여기에 포함되지 않는다. 패키지로 구조화되어야 하고, 배포 가능한 형태로 정리되어야 하며, 다른 사람이 사용할 수 있는 수준의 안정성과 문서를 갖춰야 한다. 이 과정은 코드 작성 자체와는 전혀 다른 종류의 작업이다. 다시 말해, PyPI에 올라온다는 것은 단순한 생산이 아니라 생태계에 편입되는 과정을 의미한다.

문제는 AI가 주로 영향을 미치는 영역이 이 지점이 아니라는 것이다. AI는 코드 작성 속도를 극적으로 개선하지만, 코드가 “공개 가능한 형태”로 정리되는 과정에는 제한적인 영향을 미친다. 개인이 빠르게 만들어낸 수많은 스크립트나 도구는 대부분 이 단계에 도달하지 않는다. 그들은 문제를 해결하는 순간 그 역할을 다하고, 다시 수정되거나 확장되지 않는 경우가 많다. 이러한 코드들은 분명 존재하지만, PyPI와 같은 지표에는 전혀 반영되지 않는다.

이 지점에서 우리는 중요한 구조를 이해하게 된다. 소프트웨어는 하나의 층위에서만 존재하지 않는다는 사실이다. 위쪽에는 공개되고 유지되는 코드가 있고, 아래쪽에는 개인적으로 생성되고 사라지는 코드가 있다. PyPI는 이 중 상단의 일부만을 포착한다. 따라서 그 데이터만으로 전체를 설명하려는 시도는 필연적으로 왜곡을 낳는다.

결국 우리가 마주한 문제는 데이터의 부족이 아니라, 데이터의 범위가 좁다는 것이다. 그리고 이 사실을 받아들이는 순간, 앞서 보았던 “AI 효과가 보이지 않는다”는 결론은 전혀 다른 의미를 갖게 된다. 그것은 변화가 없다는 증거가 아니라, 변화가 다른 층위에서 일어나고 있다는 신호일 수 있다. 이제 시선은 자연스럽게 다음으로 이동한다. 그렇다면 PyPI가 포착하지 못하는 그 영역에서는 실제로 어떤 일이 벌어지고 있는가.

보이지 않는 증가 — 개인용 소프트웨어의 폭발

PyPI가 포착하지 못하는 영역을 들여다보기 시작하면, 전혀 다른 풍경이 나타난다. AI 도구의 가장 직접적인 효과는 대규모 오픈소스 프로젝트가 아니라, 개인 단위의 코드 생산에서 드러난다. 이전에는 작성하기 번거로웠던 자동화 스크립트나, 굳이 만들지 않았던 작은 도구들이 이제는 쉽게 만들어진다. 데이터 정리, 반복 작업 처리, 간단한 웹 인터페이스 생성과 같은 작업들이 훨씬 낮은 비용으로 가능해졌다. 이 변화는 눈에 띄지 않지만, 실제로는 매우 광범위하게 일어나고 있다.

이러한 코드의 특징은 명확하다. 대부분은 특정한 문제를 해결하기 위해 만들어지며, 그 문제를 해결하는 순간 더 이상 확장되지 않는다. 누군가에게 배포될 필요도 없고, 일반화될 필요도 없다. 따라서 자연스럽게 공개 저장소나 패키지 레지스트리에 올라가지 않는다. 이들은 GitHub의 private repository에 머무르거나, 심지어 로컬 환경에서만 존재하다가 사라진다. 하지만 이 코드들은 분명히 “생산된 소프트웨어”이며, AI가 만들어낸 생산성 증가의 직접적인 결과다.

여기서 중요한 점은 소프트웨어의 생산 방식 자체가 바뀌고 있다는 것이다. 과거에는 소프트웨어를 만든다는 것은 곧 “배포 가능한 형태로 만드는 것”을 의미하는 경우가 많았다. 하지만 지금은 다르다. 문제를 해결하기 위한 일회성 코드도 충분히 가치 있는 결과물이 되었다. AI는 이 영역을 폭발적으로 확장시키고 있다. 즉, 우리는 더 이상 “모두에게 쓰이는 소프트웨어”만을 만드는 것이 아니라, “나만을 위한 소프트웨어”를 대량으로 생산하는 시대에 들어선 것이다.

이 변화는 겉으로 드러나지 않기 때문에 더욱 오해를 낳는다. 외부에서 보면 소프트웨어 생태계는 크게 변하지 않은 것처럼 보인다. 하지만 내부에서는 수많은 코드가 생성되고, 사용되고, 사라지고 있다. 이 과정은 기록되지 않고, 집계되지 않으며, 따라서 기존의 지표로는 관찰할 수 없다. 결국 우리가 처음에 던졌던 질문, “소프트웨어는 어디에 있는가”에 대한 답은 여기서 드러난다. 그것은 보이지 않는 곳에 존재한다는 것이다.

이제 문제는 한 단계 더 구체화된다. 소프트웨어는 늘었지만, 왜 그것이 “제품”으로 이어지지 않는가. 왜 이 많은 코드들이 생태계의 일부로 편입되지 않고 사라지는가. 이 질문은 자연스럽게 다음 단계로 이어진다.

진짜 병목 — 코드는 쉬워졌지만 제품은 아니다

AI가 바꾼 것은 분명하다. 코드 작성은 더 이상 큰 장벽이 아니다. 자연어로 요구사항을 설명하면 기본 구조가 생성되고, 반복적인 구현 작업은 자동화된다. 개발자는 더 이상 빈 화면에서 시작하지 않는다. 이 변화는 특히 초기 단계에서 압도적인 속도 차이를 만들어낸다. 아이디어를 떠올리고 그것을 동작하는 형태로 구현하는 데 걸리는 시간이 극적으로 줄어들었다.

하지만 이 지점에서 중요한 착각이 발생한다. 많은 사람들이 “코드를 만들 수 있다”는 것과 “제품을 만들 수 있다”는 것을 동일하게 생각한다. 그러나 이 둘은 전혀 다른 문제다. 제품은 단순히 기능이 동작하는 것을 넘어, 사용자가 지속적으로 사용할 수 있는 형태로 완성되어야 한다. 여기에는 사용자 경험 설계, 오류 처리, 성능 최적화, 배포 환경 구성, 운영 및 유지보수와 같은 요소들이 포함된다. AI는 이 영역에서도 도움을 줄 수 있지만, 그 복잡성을 근본적으로 제거하지는 못한다.

결국 구조는 이렇게 나뉜다. 아이디어에서 프로토타입까지의 거리는 짧아졌지만, 프로토타입에서 제품까지의 거리는 거의 변하지 않았다. 이 간극이 바로 지금의 병목이다. 많은 코드가 생성되지만, 그중 극히 일부만이 제품으로 발전한다. 나머지는 특정 목적을 달성한 뒤 더 이상 발전하지 않고 사라진다. 이 현상은 단순히 기술적인 문제가 아니라, 시간과 비용, 그리고 동기 부여의 문제이기도 하다. 제품을 유지한다는 것은 지속적인 투자와 책임을 의미하기 때문이다.

이 구조를 이해하면, 왜 PyPI와 같은 지표에서 변화가 제한적으로 보이는지 자연스럽게 설명된다. PyPI에 올라오는 것은 대부분 “제품 수준의 코드”다. 반면 AI가 폭발적으로 증가시킨 것은 “프로토타입 수준의 코드”다. 두 영역은 서로 연결되어 있지만, 동일한 속도로 증가하지 않는다. 따라서 우리는 지금까지 잘못된 질문을 던지고 있었을 가능성이 높다.

문제는 더 이상 “왜 소프트웨어가 늘지 않았는가”가 아니다. 오히려 “왜 이렇게 많은 소프트웨어가 제품으로 이어지지 않는가”가 핵심 질문이 된다. 그리고 이 질문에 답하기 위해서는, 우리가 관찰하는 지표 자체를 다시 검토해야 한다.

왜 앱스토어 데이터도 답이 되지 않는가

지금까지의 흐름을 따라오면 자연스럽게 하나의 반론이 떠오른다. PyPI가 아니라면, 더 “실제 사용자에게 도달한 결과물”을 보면 되는 것 아닌가. 즉, 앱스토어나 플레이스토어와 같은 플랫폼에서 출시되는 앱 수를 보면 AI 시대의 생산성을 더 정확하게 측정할 수 있지 않겠느냐는 생각이다. 겉으로 보기에는 이 접근이 훨씬 합리적으로 보인다. 왜냐하면 앱은 실제 사용자에게 전달되는 최종 결과물이기 때문이다.

그러나 이 직관은 중요한 전제를 놓치고 있다. 앱스토어에 올라간다는 것은 단순히 코드를 작성했다는 의미가 아니다. 그것은 이미 일정 수준 이상의 완성도를 요구하는 제품화의 최종 단계에 도달했다는 것을 의미한다. UI와 UX가 갖춰져야 하고, 플랫폼 정책을 만족해야 하며, 배포와 업데이트 프로세스를 유지할 수 있어야 한다. 다시 말해, 앱스토어는 “코드 생산량”이 아니라 “제품 완성도”를 기준으로 필터링된 결과물만을 보여주는 공간이다.

이 구조는 AI의 영향 범위와 정확히 어긋난다. 앞서 살펴본 것처럼 AI는 코드 작성과 초기 구현 단계에서 큰 효과를 발휘하지만, 제품 완성 단계에서는 상대적으로 제한적인 영향을 미친다. 따라서 코드 생산성이 증가하더라도, 그것이 앱 출시 수 증가로 직결되지 않는 것은 자연스러운 결과다. 오히려 많은 코드가 제품 단계에 도달하지 못하고 중간에서 멈춘다면, 앱스토어에서는 변화가 거의 보이지 않을 수도 있다.

또 하나의 중요한 요소는 시장의 포화 상태다. 앱스토어는 이미 수백만 개의 앱이 존재하는 환경이다. 새로운 앱이 추가된다고 해서 그것이 사용자에게 도달할 가능성은 매우 낮다. 이 상황에서 개발자는 단순히 “만들 수 있다”는 이유만으로 앱을 출시하지 않는다. 노출 가능성과 유지 비용, 사용자 확보의 어려움이 모두 고려된다. 결과적으로 AI로 인해 코드 작성이 쉬워졌더라도, 출시 자체는 여전히 높은 비용을 요구하는 선택으로 남아 있다.

이제 결론은 분명해진다. 앱스토어 데이터는 “AI로 얼마나 많은 코드를 만들었는가”를 보여주는 지표가 아니라, “그 중 얼마나 많은 것이 제품으로 완성되었는가”를 보여주는 지표다. 따라서 우리는 여전히 같은 문제에 머물게 된다. 코드 생산성의 증가를 측정하려면, 제품이 아니라 그 이전 단계의 변화를 포착해야 한다. 그리고 그 지점에서 우리는 다시 한 번 질문을 재정의할 필요가 있다.

AI 효과의 실제 모습 — ‘전체 증가’가 아니라 ‘집중 현상’

이제 다시 원점으로 돌아가 보자. PyPI 데이터에서 관찰된 가장 뚜렷한 변화는 전체적인 증가가 아니라, 특정 영역에 집중된 변화였다. 특히 AI와 관련된 패키지에서만 업데이트 빈도가 급격히 증가하는 현상이 나타났다. 이 결과는 단순히 “AI가 생산성을 높였다”는 설명으로는 충분히 해석되지 않는다. 왜냐하면 그 효과가 전체가 아니라 특정 영역에만 나타나기 때문이다.

이 현상을 이해하기 위해서는 생산성을 “균등하게 증가하는 힘”으로 보는 관점을 버려야 한다. AI는 모든 개발자에게 동일한 영향을 미치는 도구가 아니다. 오히려 특정 문제 영역, 특히 AI 자체를 활용하는 영역에서 훨씬 더 강하게 작동한다. AI 모델을 다루고, 이를 기반으로 서비스를 만드는 개발자들은 AI 도구를 가장 적극적으로 활용할 수 있는 집단이다. 이들은 단순히 생산성이 조금 향상된 것이 아니라, 작업 방식 자체가 바뀌는 수준의 변화를 경험한다.

그러나 이 설명만으로는 여전히 부족하다. 만약 단순히 “AI를 잘 사용하는 개발자”의 문제였다면, 모든 AI 관련 패키지에서 유사한 증가가 나타나야 한다. 하지만 실제 데이터에서는 인기 있는 AI 패키지에 변화가 집중되는 경향이 보인다. 이 지점에서 우리는 기술적 요인 외에 다른 요소를 고려해야 한다. 바로 자본과 관심, 그리고 시장 수요다.

AI는 현재 가장 많은 투자와 주목을 받고 있는 영역 중 하나다. 이로 인해 특정 프로젝트에는 더 많은 인력과 시간이 투입되고, 더 빠른 반복과 업데이트가 가능해진다. 즉, 우리가 관찰하는 “업데이트 증가”는 순수한 생산성 향상이라기보다, 집중된 자원이 만들어낸 결과일 가능성이 높다. 이는 AI가 개발자를 초인적으로 만든 것이 아니라, 특정 영역에 더 많은 개발자가 몰리게 만들었다는 해석으로 이어진다.

결국 우리가 보고 있는 것은 “전체적인 확산”이 아니라 “국소적인 폭발”이다. AI는 소프트웨어 생산을 균등하게 증가시키지 않았다. 대신 특정 영역에 에너지를 집중시키며, 그 영역에서만 눈에 띄는 변화를 만들어냈다. 이 사실은 우리가 처음에 기대했던 그림과는 다르지만, 동시에 현재의 현실을 더 정확하게 설명해준다.

새로운 관점 — 우리는 무엇을 잘못 보고 있었나

지금까지의 논의를 종합하면, 문제는 단순한 데이터 해석의 오류가 아니라 질문 자체의 설정 방식에 있었음을 알 수 있다. 우리는 “AI가 소프트웨어 생산량을 늘렸는가”라는 질문을 던졌고, 그 답을 찾기 위해 PyPI나 앱스토어와 같은 지표를 살펴보았다. 그러나 이 질문은 처음부터 중요한 전제를 포함하고 있었다. 소프트웨어는 공개되고, 배포되며, 생태계에 편입된 형태로 존재해야 한다는 전제다.

하지만 AI는 이 전제를 흔들고 있다. 소프트웨어는 더 이상 반드시 공개될 필요가 없다. 특정 문제를 해결하기 위한 코드도 충분히 가치 있는 결과물이 된다. 개인의 생산성을 높이기 위한 도구, 내부 시스템을 보완하기 위한 스크립트, 일회성 분석을 위한 코드 등은 모두 소프트웨어지만, 기존의 지표에서는 거의 포착되지 않는다. 즉, 우리는 여전히 “공개된 소프트웨어”만을 기준으로 전체를 판단하고 있었던 것이다.

이 관점에서 보면, 지금까지의 혼란은 자연스러운 결과다. 우리는 생산성의 변화를 관찰하려고 했지만, 그 변화가 나타나는 위치를 잘못 설정했다. AI는 기존의 생태계를 단순히 확장한 것이 아니라, 새로운 층위를 만들어냈다. 그 층위는 빠르게 생성되고, 빠르게 소비되며, 기록되지 않고 사라지는 코드들로 구성된다. 그리고 이 영역은 기존의 어떤 지표로도 제대로 측정되지 않는다.

이제 질문은 다시 정의되어야 한다. 더 이상 “소프트웨어는 얼마나 늘어났는가”를 묻는 것이 아니라, “어떤 형태의 소프트웨어가 어디에서 생성되고 있는가”를 물어야 한다. 이 질문은 단순히 양적인 증가를 넘어, 소프트웨어의 존재 방식 자체를 다시 바라보게 만든다. 그리고 이 지점에서 우리는 비로소 AI 시대의 변화를 제대로 이해할 수 있는 출발선에 서게 된다.

현실적인 한계 — AI가 바꾸지 못하는 것들

지금까지의 논의를 통해 우리는 AI가 소프트웨어 생산의 일부를 크게 바꾸고 있다는 사실을 확인했다. 하지만 동시에 분명해진 것이 있다. 이 변화는 전체 시스템을 재구성할 정도의 변화가 아니라, 특정 구간을 강하게 밀어주는 형태의 변화라는 점이다. 특히 코드 작성 단계에서는 압도적인 효율 향상이 일어났지만, 그 이후의 단계에서는 여전히 기존의 구조가 유지되고 있다. 이 지점에서 우리는 한 가지 중요한 사실을 직면하게 된다. AI는 개발의 모든 문제를 해결하는 도구가 아니라, 특정 문제를 매우 잘 해결하는 도구라는 것이다.

가장 대표적인 한계는 제품화 과정에서 드러난다. 소프트웨어가 실제 사용자에게 도달하기 위해서는 단순히 동작하는 코드 이상의 것이 필요하다. 사용자는 기능이 아니라 경험을 소비하고, 그 경험은 코드만으로 완성되지 않는다. 인터페이스의 설계, 사용자 흐름의 최적화, 오류 상황에서의 대응 방식, 지속적인 업데이트와 운영까지 포함된 복합적인 과정이 요구된다. AI는 이러한 영역에서도 도움을 줄 수 있지만, 여전히 최종적인 판단과 구조 설계는 인간의 몫으로 남아 있다. 따라서 코드 작성이 쉬워졌다고 해서 제품을 만드는 일이 동일하게 쉬워지는 것은 아니다.

또 다른 한계는 책임과 지속성의 문제다. 개인이 AI를 활용해 만든 수많은 도구들은 특정 순간에는 매우 유용하지만, 장기적으로 유지되지는 않는다. 누군가가 지속적으로 관리하고 개선하지 않는다면, 그 코드는 금방 낡아버린다. 반면 PyPI에 올라오는 패키지나 앱스토어의 제품은 일정 수준 이상의 유지보수를 전제로 한다. 이 차이는 단순한 기술적 차이가 아니라, 책임의 범위와 비용 구조의 차이에서 비롯된다. AI는 코드를 빠르게 만들어줄 수 있지만, 그 코드를 책임지는 구조까지 만들어주지는 않는다.

여기에 더해 조직과 협업의 문제도 남아 있다. 개인 단위에서는 AI를 활용한 생산성 향상이 명확하게 드러나지만, 팀 단위나 조직 단위에서는 그 효과가 단순히 배가되지 않는다. 코드의 품질을 유지하고, 일관된 아키텍처를 설계하며, 여러 사람이 협업하는 과정에서는 여전히 많은 조율이 필요하다. AI가 생성한 코드를 어떻게 검증하고 통합할 것인지에 대한 문제도 쉽게 해결되지 않는다. 결국 AI는 개인의 속도를 높이지만, 시스템 전체의 복잡성을 줄이지는 않는다.

이 모든 한계는 하나의 방향으로 수렴한다. AI는 개발의 일부를 가속화했지만, 소프트웨어를 “완성된 상태”로 만드는 과정은 여전히 인간 중심 구조를 유지하고 있다는 것이다. 따라서 우리는 AI를 과대평가할 필요도 없지만, 과소평가할 필요도 없다. 중요한 것은 이 도구가 어디까지 영향을 미치고, 어디에서 멈추는지를 정확히 이해하는 것이다. 그리고 이 이해를 바탕으로, 지금까지의 논의를 다시 정리할 수 있는 지점에 도달하게 된다.

결론 — AI는 소프트웨어를 늘리지 않았다

이제 처음으로 돌아가 보자. AI는 개발자의 생산성을 크게 향상시켰다고 말한다. 그리고 실제로 많은 개발자가 그 변화를 체감하고 있다. 하지만 동시에 우리는 PyPI와 같은 지표에서 기대했던 변화가 나타나지 않는다는 사실도 확인했다. 이 두 가지 사실은 서로 모순되는 것처럼 보였지만, 지금까지의 논의를 통해 그것이 단순한 모순이 아니라 서로 다른 층위를 설명하는 현상이라는 점이 드러났다.

AI는 소프트웨어를 더 많이 만들게 했다. 하지만 그 소프트웨어는 우리가 기존에 측정하던 방식으로 나타나지 않는다. 그것은 패키지로 배포되지 않고, 앱스토어에 등록되지 않으며, 공개 생태계에 편입되지 않는다. 대신 개인의 작업 환경, 내부 시스템, 일회성 문제 해결 과정 속에서 생성되고 소비된다. 즉, AI는 소프트웨어의 “양”을 늘린 것이 아니라, 소프트웨어가 존재하는 “방식”을 바꾸었다고 보는 것이 더 정확하다.

이 변화는 우리가 소프트웨어를 바라보는 기준 자체를 다시 생각하게 만든다. 과거에는 공개되고 재사용되는 코드가 중심이었다면, 이제는 개인화되고 즉각적으로 생성되는 코드가 중요한 역할을 한다. 이 두 영역은 서로 경쟁하는 것이 아니라, 서로 다른 목적을 가진 채 공존한다. 그리고 AI는 이 중 후자를 폭발적으로 확장시키고 있다. 이 사실을 이해하지 못하면, 우리는 계속해서 “왜 변화가 보이지 않는가”라는 질문에 머물게 된다.

결국 이 글의 핵심은 단순하다. AI는 소프트웨어를 늘리지 않았다. 대신 세상에 나오지 않는 소프트웨어를 폭발적으로 늘렸다. 이 문장은 직관에 반하는 것처럼 보이지만, 지금까지의 모든 관찰을 가장 정확하게 설명한다. 그리고 이 결론은 하나의 방향을 제시한다. 앞으로 우리는 더 이상 공개된 결과물만을 통해 변화를 판단할 수 없다. 대신 보이지 않는 영역에서 일어나는 변화를 이해해야 한다.

이 지점에서 비로소 처음의 질문은 새로운 형태로 돌아온다. AI 시대에 우리는 무엇을 만들어야 하는가, 그리고 그것은 어디에 존재해야 하는가. 이 질문에 대한 답은 아직 완전히 정리되지 않았지만, 한 가지는 분명하다. 소프트웨어는 여전히 늘어나고 있다. 다만, 우리가 그것을 보는 방식이 아직 따라가지 못하고 있을 뿐이다.