소프트웨어가 느린 이유는 느린 언어가 아니라 나쁜 설계 때문이다

AI로 프로그램을 C나 Rust로 다시 쓰기보다 설계를 개선하는 편이 큰 성능 향상으로 이어지는 경우가 많음 데이터베이스와 네트워크를 기다리는 시간이 길다면 언어를 바꿔도 효과가 제한되며, 요청 시간의 절반이 DB 조회라면 나머지 코드를 아무리 빠르게 해도 전체 속도는 최대 2배 Python도 계산 집약적인 작업은 이미 최적화된 네이티브 라이브러리에 맡기는 경우가 많아, 언어를 바꿔도 핵심 연산이 빨라지지 않을 수 있음 캐싱, 비동기 처리, 병렬화, 불필요한 SQL 쿼리 제거처럼 수행할 작업을 줄이거나 재구성하는 것이 주요 최적화 방법 AI에는 먼저 프로파일링과 병목 분석, 설계 개선을 맡기고, 작업량을 줄일 수 없는 CPU 병목이 확인되면 해당 부분을 빠른 언어로 재작성하는 방식이 효과적 언어 속도 차이가 프로그램 전체의 속도 차이는 아님 AI로 빠른 언어로 재작성하면 소프트웨어가 빨라질 것이라는 기대와 달리, 대부분의 프로그램은 C나 Rust로 옮기는 것만으로 유의미하게 빨라지기 어려움 C가 Python보다 50배 빠를 수 있어도, Python 프로그램을 C로 옮겼을 때 전체 실행 속도가 50배 빨라지는 것은 아님 소프트웨어 성능은 보통 I/O에 좌우되며, 언어 속도가 중요한 부분에는 이미 C 수준의 속도를 활용하는 라이브러리가 널리 쓰임 성능 개선에서는 언어 선택보다 설계가 더 중요한 경우가 많음 I/O 병목과 성능 향상의 상한 데이터베이스를 사용하는 CRUD 웹사이트에서 요청 시간의 50%가 데이터베이스 조회에 쓰인다고 가정하면, C로 재작성해도 나머지 50%만 가속할 수 있음 현재 사용자, 요청한 레코드, 사용자 소속이나 설정 등을 조회하는 시간은 그대로 남음 이 경우 최대 속도 향상은 2배이며, 실제로는 1.5배에 더 가까울 수 있음 이러한 상한은 암달의 법칙에 해당함 50%라는 비중은 보편적인 측정값이 아니라 인터프리터 언어를 다룬 경험에 기반한 예시임. 주로 다루는 언어와 작업에 따라 매우 높거나 낮게 느껴질 수 있음 I/O 병목 프로그램은 실제 계산보다 데이터를 주고받기를 기다리는 데 시간을 많이 쓰며, CPU 병목 프로그램은 연산 자체에 시간을 많이 씀 데이터베이스뿐 아니라 외부 API, 디스크 읽기와 쓰기도 대기의 원인이 됨 curl 코드를 100배 빠르게 만들어도 네트워크 대기가 대부분이라면 차이를 거의 느끼지 못할 수 있음 느린 언어도 이미 빠른 코드에 작업을 위임함 위키의 Markdow...