소프트웨어가 계속 느린 데는 이유가 있다

LLM이 최적화 구현 비용을 낮춰도 성능 예산·우선순위와 프로덕션 출시 비용까지 해결하지는 못하므로, 소프트웨어가 더 이상 느릴 이유가 없다는 전제는 현실에서 자주 무너짐 에이전트 작업이 비동기화되고 기능이 늘면서 사용자가 지연을 받아들이는 범위는 넓어지는 반면, 기업은 개발을 비용 센터로 보거나 LLM 도입을 이유로 일정을 줄여 성능 예산을 축소할 수 있음 최적화에는 코드 작성뿐 아니라 정확성 검증, 회귀 방지, 데이터 재구성, 마이그레이션, 유지보수가 필요하며, Zig 병렬 컴파일 사례처럼 빠른 구현이 비결정적 동작을 일으킬 수도 있음 pgrust는 ClickBench와 유사한 쿼리를 PGO에 사용해 벤치마크 과적합 가능성이 있고, FRE는 일반 성능이 뛰어나지 않으면서 구현 규모가 약 67만 SLOC로 추정돼 성능 수치만으로 LLM 생성 코드의 실용성을 판단하기 어려움 성능 도구와 하드웨어가 발전해도 평균적인 소프트웨어는 더 느리고 무거워질 수 있으며, LLM은 숙련된 전문가의 최적화 역량을 확대할 수 있지만 조직적 제약과 장기 비용까지 없애지는 못함 LLM이 바꾸는 비용 공식의 한계 성능, 테스트, 형식 검증 같은 바람직한 속성 X가 과거에는 비용 A로 예산 B를 초과했지만, LLM 이후 비용이 A/N < B로 낮아지면 사람들이 X에 투자할 것이라는 논리가 사용됨 이 논리는 사람들이 합리적 경제 행위자이고 완전한 정보를 가졌다고 가정하더라도, 모든 전제가 실제로 유지될 때만 성립함 깊은 도메인 지식을 가진 숙련자는 LLM으로 더 많은 최적화를 수행하거나, 이전보다 많은 최적화를 출시하는 팀에서 일할 수 있음 하지만 실제 환경에서는 비용 감소 외의 조건이 바뀌거나 숨은 비용이 커져 이 공식이 성립하지 않는 경우가 더 많음 느린 작업을 받아들이는 기준의 변화 에이전트 루프의 반복 지연 때문에 과거의 동기 작업이 비동기 작업으로 바뀌면서 ‘느리지 않아야 한다’는 요구 수준 자체가 낮아질 수 있음 업무용 모노레포의 현재 git 성능은 2022년에 같은 수치가 나왔다면 받아들이기 어렵다고 여겼을 수준이지만, 지금은 허용되고 있음 초기 LLM 자동 완성은 일반 IDE 자동 완성보다 느려 개발자가 제안을 기다리며 잠시 멈춰야 했음 과거 자동 완성의 장점은 즉각적인 피드백이었음 이후 Cursor 등은 작고 특화된 모델을 도입해 완성 지연을 줄였음 같은 현상은 컴파일·링크·테스트 시간에도 적용되며, 사용자는 동기 ...