"소프트웨어가 느릴 이유는 이제 없다" — 댄 루의 도발이 개발자 커뮤니티를 갈라놓은 이유

노트북 성능은 10년 전보다 몇 배는 빨라졌습니다. 그런데 메신저 앱을 켜면 여전히 3초를 기다립니다. 텍스트 편집기에서는 키를 누른 뒤 글자가 올라오기까지 반 박자가 뜹니다. 이 기묘한 모순을 정면으로 들이받은 글이 최근 개발자 커뮤니티에서 크게 돌았습니다.

다만 미리 밝혀둘 게 있습니다. 이번 주제는 커뮤니티 데이터 수집 범위에서 최근 30일 내 신규 논의가 거의 잡히지 않았습니다. 그래서 이 글은 실시간 반응을 중계하기보다 이 논쟁이 왜 몇 년째 같은 자리를 맴도는지를 짚는 쪽으로 갑니다.

“느린 건 어쩔 수 없다"는 말의 정체

댄 루는 오랫동안 소프트웨어 성능을 집요하게 파고든 엔지니어입니다. 대표적인 작업이 키보드 입력 지연 측정입니다. 결과가 충격적이었습니다. 1983년 애플 IIe의 입력 지연이 30밀리초였는데, 2017년의 최신 맥북과 최신 웹 기반 에디터는 그보다 느린 경우가 수두룩했습니다. 40년 사이 CPU는 수천 배 빨라졌는데, 사용자가 체감하는 반응 속도는 오히려 후퇴한 겁니다.

주장 자체는 간단합니다. 대부분의 느린 소프트웨어는 어려운 문제 때문이 아니라, 아무도 들여다보지 않아서 느리다는 겁니다. 최적화가 고난도 기술이라 못 하는 게 아니라, 프로파일러 한 번 돌리면 바로 나오는 문제가 그냥 방치돼 있다는 얘기죠.

정작 낮은 곳에 달린 열매가 썩고 있다

성능 개선 이야기가 나오면 늘 따라붙는 반박이 있습니다. “조기 최적화는 만악의 근원"이라는 도널드 커누스의 명언이죠. 그런데 이 문장은 원문에서 잘려나간 채 인용되기로 악명이 높습니다. 커누스가 실제로 한 말은 “97%의 경우 사소한 효율성은 잊어야 한다. 하지만 그 결정적인 3%에서 기회를 놓쳐서는 안 된다"였습니다. 뒷부분이 통째로 사라진 겁니다.

댄 루 진영의 반론은 이 지점을 찌릅니다. 현장에서 나오는 성능 문제 상당수가 정교한 알고리즘 튜닝과는 거리가 멀다는 겁니다. 가령 이런 겁니다.

• 루프 안에서 데이터베이스를 반복 호출하는 N+1 쿼리
• 한 번만 계산하면 되는 값을 렌더링마다 다시 계산하는 코드
• 인덱스가 빠진 테이블 풀스캔
• 필요 없는 의존성 수백 개가 딸려 들어온 번들

이건 어려운 문제가 아니라 안 본 문제입니다. 하루만 프로파일링해도 두 배 빨라지는 코드가 널려 있는데, 그 하루를 아무도 배정하지 않는 구조가 진짜 원인이라는 지적이죠.

그 시간은 어디서 나오나

물론 반박도 만만치 않습니다. 이쪽 논리에도 나름의 근거가 있고요.

첫째, 성능은 조직이 보상하지 않는 지표입니다. 새 기능을 출시하면 눈에 보이고 실적 평가에 적힙니다. 반면 앱 시작 시간을 800밀리초에서 400밀리초로 줄이면 아무도 모릅니다. 사용자는 원래 그랬던 것처럼 받아들이고 매니저는 “그래서 이번 분기에 뭐 만들었죠?“라고 묻습니다.

둘째, 느린 소프트웨어를 낳은 도구 선택도 대체로는 합리적이었습니다. 일렉트론으로 만든 데스크톱 앱은 무겁습니다. 하지만 웹 개발자 한 팀이 맥과 윈도우와 리눅스용 앱을 동시에 내놓을 수 있게 해줍니다. 네이티브로 세 개를 따로 만들 여력이 없는 회사에 이건 성능 대 개발비용의 거래이지, 게으름이 아닙니다.

여기에 계층이 쌓인 이유도 있습니다. 추상화 레이어는 매번 조금씩 느려지지만 그 대가로 보안 패치와 유지보수, 인력 대체 가능성을 얻습니다. 개별 결정은 다 합리적인데 열 개가 쌓이면 앱이 느려지는, 전형적인 구성의 오류입니다.

AI가 코드를 쏟아내는 시대, 성능은 어디로 가나

그런데 2026년에 이 논쟁을 다시 꺼내면 무대가 달라집니다.

지금 상당수 코드는 사람이 한 줄씩 고민해서 쓰지 않습니다. AI 코딩 도구가 초안을 만들고 사람은 검토합니다. 그런데 AI가 생성하는 코드는 동작하는 코드에 최적화돼 있지, 빠른 코드에 최적화돼 있지는 않습니다. 학습 데이터가 세상의 평균적인 코드이기 때문입니다. 그리고 세상의 평균적인 코드는 그다지 빠르지 않습니다.

문제는 속도입니다. 예전에는 느린 코드가 한 사람 손을 거쳐 한 줄씩 쌓였습니다. 지금은 같은 품질의 코드가 몇십 배 빠르게 쌓입니다. 댄 루가 지적한 “아무도 안 본 문제"의 총량 자체가 폭증하는 구조인 셈이죠.

반대 시나리오도 가능합니다. 프로파일링과 병목 분석은 지루하고 반복적인 작업입니다. 정확히 AI가 잘하는 일이죠. 사람이 하루를 못 내주던 작업을 에이전트가 밤새 돌릴 수 있다면, 성능 최적화의 진입 장벽은 오히려 무너집니다. 문제는 여전히 누가 그 작업을 시키기로 결정하느냐입니다. 도구가 아니라 우선순위의 문제라는 점은 하나도 안 바뀌었습니다.

그래서 어느 쪽이 맞나

솔직히 양쪽 다 절반씩 맞습니다.

댄 루가 옳은 부분은 진단입니다. 성능 문제 대부분이 기술적 난제가 아니라 관심의 부재라는 지적은 반박하기 어렵습니다. 프로파일러를 한 번도 안 돌려본 프로덕션 서비스가 얼마나 많은지 생각해보면 더 그렇습니다.

반대편이 옳은 부분은 처방입니다. “이제 변명은 없다"는 말은 개인 개발자를 향한 도덕적 요구처럼 들리는데, 실제 원인은 조직의 인센티브 구조에 있습니다. 성능을 측정하지 않고, 회귀를 감지하지 않고, 개선을 평가에 반영하지 않는 회사에서 개인의 각성만으로는 아무것도 안 바뀝니다.

현실적인 접점은 이겁니다. 성능을 기능이 아니라 기준선으로 다루는 것. 테스트 커버리지를 CI에서 강제하듯 응답 시간 예산을 정해두고 넘으면 빌드를 깨는 방식입니다. 개인의 의지가 아니라 시스템이 지키게 만드는 거죠.

마무리

지금 여러분이 만드는 서비스의 첫 화면 로딩 시간을 밀리초 단위로 알고 계신가요. 답이 바로 안 나온다면, 그건 그 숫자를 아무도 안 보고 있다는 뜻입니다.

댄 루의 주장에서 가장 뼈아픈 대목은 “느릴 이유가 없다"가 아니라 그 앞에 생략된 문장입니다. 우리는 대체로 빠르게 만드는 법을 몰라서 못 하는 게 아니라, 빠르게 만들 이유를 못 찾아서 안 하고 있습니다. AI가 코드를 쏟아내는 속도가 빨라질수록 그 이유를 누가 만들어주느냐가 관건이 됩니다.