소프트웨어가 느릴 이유는 이제 없다
소프트웨어가 느릴 이유는 이제 없다
우리가 매일 만지는 소프트웨어의 느림은 하드웨어의 물리적 한계인가, 아니면 아무도 손대지 않아서 쌓인 방치의 결과인가. 그리고 최적화를 수행하는 비용이 무너진 지금, “그건 너무 비싸다”는 업계의 마지막 변명마저 사라진 것인가.
도입
danluu(Dan Luu)가 올린 글의 제목은 노골적으로 도발적이다. “소프트웨어가 느릴 이유는 이제 없다(There’s No Reason for Software to Be Slow Anymore)”. 지난 40년간 CPU는 수천 배 빨라졌고, 메모리와 저장장치의 대역폭도, 화면 주사율도 올랐다. 그런데 정작 사람이 손끝으로 느끼는 지연 — 앱이 뜨는 시간, 웹 페이지가 그려지는 시간, 키를 누르고 화면에 글자가 나타나기까지의 시간 — 은 좀처럼 줄지 않았고, 어떤 영역에서는 오히려 나빠졌다. 하드웨어가 준 이득이 어디로 새어 나갔는가.
danluu의 답은 오래전부터 일관됐다. 성능은 물리 법칙이 정한 천장이 아니라, 노력하면 상당 부분 되찾을 수 있는 자원이다. 대부분의 느린 소프트웨어는 “여기가 한계”라서 느린 게 아니라, 아무도 되찾으려 하지 않았기 때문에 느리다. 이번 글이 새로 얹은 각도는 경제학이다. 최적화라는 작업 자체의 비용이 AI 보조 코딩으로 급락했고, 그래서 지금까지 “성능 튜닝은 너무 비싸다”며 미뤄 온 결정들의 손익 계산이 통째로 뒤집힌다는 것이다. 이 글은 그 주장을 세 축으로 나눠 검토한다. 무엇이 느린가, 왜 느린가, 그리고 비용이 무너진 뒤에 무엇이 달라지는가.
되찾을 수 있었던 1초 — 느림의 해부
먼저 현상이다. danluu의 글에서 가장 구체적인 데이터는 자기 자신의 ripgrep 사용 로그다. 저자는 자기 머신에서 실제로 던진 검색 질의들을 계측했는데, 패턴 길이의 중앙값이 55개 유니코드 문자, 상위 10퍼센트(p90)가 119자였다. 질의 소요 시간의 분포는 더 극적이다. 상위 1퍼센트(p99)가 거의 1분, 상위 0.1퍼센트(p999)가 거의 10분, 최악의 단일 질의는 무려 2시간에 육박했다. 동시에 패턴의 94퍼센트는 딱 한 번만 등장했고, 99퍼센트가 정규식 질의였으며, 99.9퍼센트가 ASCII만 쓰는 검색이었다. 즉 워크로드는 놀랄 만큼 편향돼 있는데, 도구는 만인을 위한 범용 설계라 그 편향을 활용하지 못한다.
저자는 여기에 손을 댄다. AI 에이전트에게 자기 워크로드에 맞춘 정규식 엔진(FRE) 최적화를 시켰더니, 네이티브 AOT 컴파일만으로 긴 질의에서 2배에서 4배가 빨라졌고, 대표성 있는 홀드아웃 질의 집합에서 약 7퍼센트의 속도 향상이 나왔다. 자기 ripgrep 사용 패턴에 특화한 버전은 첫 패스만으로 표준 ripgrep보다 2퍼센트 빨랐고 계속 개선 중이었다. 주목할 것은 사람이 이 작업을 시작하는 데 든 시간이 약 2분이라는 점이다. 또 다른 사례로 저자는 보드게임 Azul의 AI를 든다. 속도를 두 배로 올릴 때마다 대략 100 Elo씩 강해졌고, 두 번째로 강한 AI보다 개발 시간이 약 100배 적게 들었는데도 더 나은 멀티스레딩과 10~20개의 추가 최적화를 얹어 압도적 1위를 차지했다.
여기까지는 저자 자신의 실측이다. 그런데 이런 “되찾을 수 있었던 성능”의 사례는 HN 토론에서 훨씬 광범위한 일상 소프트웨어로 확장된다. HN 토론에서는 한 참가자가 1989년 원자력 발전소 제어 UI가 화면을 1초 만에 갱신했는데 오늘날의 앱들은 그 응답성조차 재현하지 못한다는 취지의 지적을 내놨다(연대·사양은 개인 회고라 정확성은 확인되지 않는다). Apple Music이 하드웨어가 충분히 강력한데도 상호작용마다 네트워크 요청을 쏘느라 답답하게 느리다는 경험담, 어떤 유명 데스크톱 앱이 최고급 엔지니어들을 두고도 수십 기가바이트급 메모리 누수를 냈다는 사례도 오갔다(수치는 댓글 주장이라 그대로 받아들이기 어렵다). 반대로 개입이 통했다는 사례도 있었다. HN 토론에서는 개인 사이트의 로드 시간을 4초에서 750밀리초로 줄였다는 보고, Reddit의 백엔드 응답은 400밀리초인데 프런트엔드 렌더에 수 초가 걸린다는 관찰이 나왔다. 공통된 함의는 분명하다. 느림의 상당 부분은 물리가 아니라 선택이며, 되찾을 수 있는 자리에 방치돼 있었다는 것이다.
‘충분히 빠르다’의 경제학
그렇다면 왜 방치되는가. 첫 번째 이유는 추상화 계층의 누적이다. 오늘의 평범한 웹 앱은 브라우저 위에 프레임워크, 그 위에 상태관리, 그 위에 컴포넌트 라이브러리, 그 밑에 번들러와 트랜스파일러가 겹겹이 쌓인 구조 위에서 돈다. 각 계층은 개발 속도를 사서 실행 속도를 판다. HN 토론에서는 정적 지도 한 장을 그리려고 1메가바이트짜리 지도 라이브러리를 끌어오는 식의 낭비가 지목됐고, LLM에게 프레임워크를 아예 쓰지 말고 순수 Node에 Express, EJS, PostgreSQL 정도로만 짜라고 시켰더니 성능 차이가 엄청났다는 경험담도 나왔다. 이에 대해 다른 참가자는 그건 결국 에이전트에게 프레임워크를 인라인하고 죽은 코드를 제거하라는 요구이며, 충분히 똑똑한 컴파일러라면 자동으로 해줄 일이라고 응수했다. 계층 자체가 악은 아니지만, 계층의 비용을 아무도 정산하지 않는 문화가 문제라는 것이다.
두 번째 이유는 아키텍처다. HN 토론의 큰 축 하나는 “네트워크 지연이 주범인가, 백엔드 비효율이 주범인가”였다. 한쪽은 미국 밖 사용자가 상호작용마다 300밀리초씩 얹히는 네트워크 블로킹이 체감 느림의 핵심이라 봤고, 다른 쪽은 그건 표면일 뿐이며 개발자들이 “어차피 네트워크가 느리니까”라는 핑계로 백엔드에 또 100밀리초씩 낭비를 얹는다고 반박했다. 불필요한 중간 자료구조를 만드는 것 같은 기본기 부재가 진짜 문제라는 지적이다. 데이터를 물리적으로 떨어진 프로세서 사이에서 옮기는 비용이 로컬 계산보다 몇 자릿수 비싸다는 점, 그래서 벤치마크상으로는 5밀리초 응답이 쉬워 보여도 현실 서버는 원격 DB로 순진하게 왕복하느라 그 근처에도 못 간다는 관찰도 함께 나왔다. 로컬 우선(local-first) 설계로 이 범주의 문제를 통째로 없앨 수 있다는 처방까지 이어졌다.
여기서 과거의 최적화 문화와 견줘 볼 필요가 있다. 메모리가 킬로바이트 단위이고 CPU 사이클이 귀하던 시절, 성능은 선택이 아니라 제약이었다. 정해진 예산 안에 기능을 욱여넣으려면 손으로 어셈블리를 다듬고, 자료구조를 캐시 라인에 맞추고, 불필요한 할당을 세는 규율이 강제됐다. 데모신(demoscene)이 64킬로바이트 안에 실시간 3D를 우겨넣던 것도 같은 압력의 산물이다. 하드웨어가 넉넉해지면서 그 제약이 풀리자 규율도 함께 풀렸다. 문제는 규율이 사라진 자리를 채운 것이 “이젠 신경 안 써도 된다”는 안도였지, “남는 여유를 응답성에 재투자하자”는 판단이 아니었다는 점이다. 최적화가 필수에서 선택으로 바뀌는 순간, 외부효과의 논리가 그 선택을 지배하기 시작했다. HN 토론에서도 1980년대 어느 시점에 UI 속도가 “받아들일 만한” 수준에 도달한 뒤로는 하드웨어 이득이 응답성 유지가 아니라 겉모습과 새 기능으로 흘러갔다는 취지의 관찰이 나왔다.
세 번째, 그리고 가장 근본적인 이유는 유인 구조다. 성능은 개발자가 아니라 사용자가 비용을 치르는 외부효과다. 느린 앱의 대가는 배터리, 발열, 기다림의 형태로 수백만 사용자에게 얇게 흩어지는 반면, 최적화의 비용은 특정 팀의 이번 분기 일정에 집중된다. HN 토론에서는 이 비대칭이 조직 구조로 굳는다는 관찰이 여러 갈래로 나왔다. 티켓 단위로만 굴러가는 개발, 부서 간 사일로, 비용 귀속에 대한 집착이 합리적인 리팩터링을 경제적으로 정당화 불가능하게 만든다는 것이다. 어떤 기능의 사용 맥락을 한 팀이 이해하지 못하면 다른 팀이 그걸 보정하는 코드를 돌리게 되고, 그렇게 군더더기가 쌓인다. 그리고 어느 시점에 누군가 “이 정도면 충분히 빠르다”고 선언하고 나면, 남은 하드웨어 이득은 응답성 유지가 아니라 애니메이션과 미려함, 새 기능 쪽으로 재배분된다. HN 토론에서는 특히 macOS의 일부 애니메이션이 이미 끝난 작업을 보여주기 전에 인위적 지연을 강제해 파워 유저를 괴롭힌다는 불만이 반복됐다. 과거의 최적화 문화가 사라진 게 아니라, 그 문화가 값을 매기던 자원(사용자의 1초)이 조직의 손익계산서에서 빠졌을 뿐이다.
최적화 비용이 무너진 뒤
danluu의 핵심 주장은 바로 이 손익계산서를 다시 쓰는 것이다. 최적화 여부는 늘 두 값의 비교였다. 구현에 드는 사람 시간(N 인·일) 대 그로 얻는 성능 이득. 지금까지 대부분의 최적화가 “안 하는 게 낫다”로 판정된 건 이득이 없어서가 아니라 N이 너무 컸기 때문이다. 저자는 그 N이 어마어마한 배율로 떨어졌다고 본다. 사람 시간 기준으로는 1,000배에서 1,000,000배, 달러 기준 금전 비용으로는 대략 1,000배(전문 성능 엔지니어를 쓸 때 대비). 앞의 ripgrep 사례에서 사람의 개입이 2분이었다는 숫자가 이 주장의 축소판이다. N이 이렇게 작아지면, 예전엔 “이득은 있지만 그 이득이 N을 넘지 못한다”던 수많은 최적화가 갑자기 해볼 만한 일이 된다.
단, 이 주장에는 확인해 둘 조건이 붙는다. 저자 자신도 벤치마크와 실험 설계의 골격은 여전히 사람이 세워야 한다고 인정한다. 현재 최상위 모델도 무인 최적화 루프를 돌릴 만한 실험 설계 능력은 부족하다는 것이다. HN 토론의 회의론도 같은 곳을 짚는다. LLM은 명백히 망가진 코드를 프로파일링해 알려진 패턴으로 리팩터링하는 데는 탁월하지만 — 어떤 Java 코드를 350밀리초에서 60밀리초로 몇 시간 만에 줄였다는 사례처럼 — 이미 잘 최적화된 시스템에 새로운 개선을 얹는 데는 정체한다는 것이다. “네가 뭘 하는지 모르면 에이전트가 도와주고, 이미 잘 아는 사람에겐 정체된다”는 요약이 나왔다. 실제 인터뷰에서도 사람 성능 엔지니어는 열린 문제에서의 판단력은 지키지만, 시간 제한이 걸린 한정된 최적화 과제에서는 더 이상 우위를 지키기 어렵다는 관찰이 있었다. 저자가 인용한 Jamie Brandon은 모델의 해법에 자신이 떠올렸지만 미처 착수하지 못한 최적화가 들어 있었고, “몇 주를 매달리지 않는 한 시도조차 안 했을 미친 짓들”까지 포함돼 있었다는 취지로 말했다(원문 표현은 의역).
실무자에게 이것이 뜻하는 바는 무엇인가. 낙관 시나리오에서는 Marc Brooker의 말처럼 “워크로드 종류가 아니라 특정 워크로드에 맞춘 동적 맞춤 소프트웨어”가 표준이 된다. 범용 도구를 각자의 사용 패턴에 재단하는 일이 개인 프로젝트 수준에서도 경제성을 갖고, 기업은 고객별 최적화를 대규모로 파일럿할 수 있다. 비관 시나리오에서는 N이 떨어진 만큼 새 기능과 새 추상화도 그만큼 싸게 쌓여, 되찾은 성능이 곧바로 다시 방치로 흡수된다. 현실 시나리오는 그 사이 어디쯤이다. 개입 지점은 분명하다. 추측이 아니라 프로파일링으로 시작하고, 첫 패스에서 나오는 명백한 비효율(불필요한 왕복, 낭비적 자료구조)부터 잡으면 대개 수십에서 수백 배의 이득이 나온다는 게 HN 토론의 반복된 조언이었다. 마법 같은 미시 튜닝을 권하는 글들이 오히려 상황을 악화시킨다는 경고와 함께.
결론
그래서 느린 소프트웨어는 한계인가 방치인가. 두 사례의 데이터와 토론이 가리키는 답은 압도적으로 후자다. 우리가 매일 감내하는 지연의 대부분은 실리콘이 정한 천장이 아니라, 아무도 정산하지 않은 청구서다. 그리고 danluu의 논지가 옳다면, 그 청구서를 지불하지 않아도 되게 해 주던 마지막 변명 — “최적화는 너무 비싸다” — 의 유효기간이 끝나가고 있다. 최적화의 N이 무너진 세계에서는 느림이 더 이상 기술적 불가피가 아니라 명시적 선택이 된다. “충분히 빠르다”는 선언은 이제 사실 진술이 아니라, 사용자의 1초를 누구의 손익계산서에 올릴지에 대한 결정이다.
다만 비용이 싸졌다는 것과 실제로 지불된다는 것은 다르다. 성능이 외부효과인 한, 아무리 싸져도 그 비용을 스스로 떠안을 유인은 여전히 조직 안에 없다. 그러니 진짜 질문은 이제 기술이 아니라 의지로 옮겨간다. 당신의 팀이 다음에 하드웨어에서 얻은 이득을, 사용자의 응답성으로 돌려줄 것인가 아니면 또 하나의 계층으로 삼킬 것인가. 되찾을 수 있는 1초가 눈앞에 있는데, 2분이면 시작할 수 있는데, 그것을 안 하는 이유를 이제 뭐라고 설명할 것인가.
출처: