새 컴퓨터가 예전 컴퓨터보다 느린 진짜 이유 – 전직 MS 엔지니어의 쓴소리

📺 참고 영상: Why your NEW computer is SLOWER than your OLD computer! By a Retired Microsoft Engineer. — Dave's Garage

---

요즘 유튜브 알고리즘이 나한테 꽤 잘 맞는 영상을 자꾸 추천해준다. 그 중에서 이번에 Dave's Garage 채널 영상이 딱 걸렸는데, 보자마자 "아 이거다" 싶었다.

영상 주인공인 Dave는 전직 마이크로소프트 엔지니어다. 윈도우즈 Task Manager를 직접 만든 사람이라고 하니까, 그냥 이론가가 아니라 실제로 저사양 환경에서 코드를 쥐어짠 사람인 거다. 그 사람이 말한다. "왜 당신의 새 컴퓨터는 구형 컴퓨터보다 느린가"라고.

처음엔 낚시성 제목인가 싶었는데, 듣다보니까 꽤 뼈를 때리는 내용이 많아서 생각을 좀 정리해보고 싶었다.

 

https://www.youtube.com/watch?v=t992ul_IKtc

 

---

오해하지 말 것 – 옛날이 좋았다는 얘기가 아니다

Dave도 영상 초반에 분명히 선을 긋는다. 옛날 소프트웨어가 좋았다는 향수팔이 하려는 게 아니라고. 맞다. 옛날 드라이버는 수시로 터졌고, 인스톨러는 악몽이었고, 사운드카드 설정 한 번 잘못 건드리면 하루가 날아갔다. 나도 윈도우즈 98 쓰던 시절 기억이 어렴풋이 있는데, 솔직히 다시 돌아가고 싶진 않다.

근데 그 시절 소프트웨어가 딱 한 가지는 제대로 했다고 그는 말한다.

기계를 존중했다는 것.

메모리는 빠듯했고 CPU는 처참하게 느렸으니까, 코드 한 줄 한 줄에 무게가 있었다. 기능을 추가하고 싶으면 메모리 예산을 깎아야 했다. 디스크 사용량도 예산이 있었다. CPU 사용량도. 예산을 초과하면 기능이 빠졌다. 지금처럼 "일단 넣고 보자"가 통하지 않았다.

빌 게이츠랑 폴 앨런 얘기도 나오는데, 이 두 사람이 BASIC 인터프리터를 8KB에 욱여넣은 게 유명하다. 왜 8KB냐고? 12KB가 없었으니까. 진짜로 그게 전부다. 제약이 있으니까 창의성이 나왔다는 거다.

---

현대 소프트웨어는 왜 이렇게 무거워졌나

이게 사실 개발자로 일하면서 몸으로 느끼는 부분이다. 나도 가끔 PR 리뷰할 때 "이게 왜 이 라이브러리를 쓰지?" 싶을 때가 있다. 근데 묻기 귀찮으니까 그냥 넘어간다. 다들 그렇게 한다.

Dave가 지적하는 원인들을 정리해보면 크게 세 가지다.

1. 비용을 모르는 추상화

추상화 자체는 나쁜 게 아니다. 그 덕분에 우리가 매번 메모리 관리 코드를 직접 짜지 않아도 되고, 소수 팀이 대규모 서비스를 만들 수 있다. 근데 문제는 추상화가 공짜가 아니라는 걸 아무도 신경 쓰지 않는다는 거다.

그 비용이 어디로 가냐. CPU로, 메모리로, 배터리로, 네트워크로 간다. 그러니까 결국 사용자한테 간다.

간단한 유틸리티 앱 하나 실행하면 지금 뒤에서 뭐가 돌아가는지 알아? 자동 업데이터, 텔레메트리 파이프라인, 웹 렌더링 엔진, JS 런타임, 패키지 에코시스템, 샌드박스 레이어, GPU 컴포지터, 알림 브로커... 거기다 2021년에 드롭다운 메뉴 하나 예쁘게 만들려고 가져온 프레임워크가 또 다른 프레임워크 6개를 끌고 오고.

그 결과가 텍스트 필드 세 개짜리 버튼 앱이 RAM 800MB를 먹는 현실이다. Electron 기반 앱들 보면 딱 이 느낌이다. Slack, Discord, VS Code... 솔직히 VS Code는 쓸 만하지만 Slack이 저 정도 리소스를 먹을 이유가 있나 싶긴 하다.

2. 성과를 잘못 측정하는 조직

이건 개발자 개인 문제가 아니라 조직 문제다.

"기능 추가하면 박수 받는다. 시작 시간 반 줄여도 박수 못 받는다."

정말 공감 가는 말이다. 지금 대부분의 팀에서 성능 개선 작업은 스토리 포인트도 잘 안 쌓이고, 임팩트 측정도 애매하고, 리더십에 보고하기도 어렵다. 반면에 새 기능은 티가 난다. 릴리즈 노트에 쓸 수 있고, 데모할 수 있고, 사용자한테 보여줄 수 있다.

그러니까 결과적으로 팀은 기능을 만들고, 성능은 나중으로 밀린다. 근데 나중은 안 온다.

거기다 대형 조직에서는 성능 책임이 분산된다. UI 팀, 백엔드 팀, 프레임워크 팀, 실험 프레임워크 팀 각자가 조금씩 느리게 만들면, 아무도 책임지지 않지만 사용자는 그 합산을 고스란히 느낀다.

3. 의존성 폭발

요즘 소프트웨어는 "만든다"기보다 "조립한다"는 표현이 더 맞는 것 같다. 날짜 선택기 하나, 마크다운 파서 하나, 로깅 프레임워크 하나... 실행 전에 이미 npm install로 수십 MB를 받는다.

물론 바퀴 재발명이 미덕은 아니다. 근데 예전에는 라이브러리를 가져올 때 그게 가져올 만한 이유가 있는지 따졌다. 지금은 반대다. 일단 가져오고 나중에 생각한다. 그러면 기능만 가져오는 게 아니라 시작 비용, 메모리, 보안 노출, 업데이트 노이즈, 호환성 문제, 그리고 내가 절대 다 파악 못 할 중첩 의존성 트리가 같이 따라온다.

---

AI가 기름을 붓는다

이 부분에서 좀 뜨끔했다.

Dave는 AI 자체를 반대하는 건 아니라고 한다. 스캐폴딩, 보일러플레이트, 테스트 생성, 낯선 API 파악... 이런 데서는 진짜 유용하다고 인정한다. 나도 매일 쓰니까 그건 동의한다.

근데 그가 지적하는 건 이거다. AI는 학습 데이터의 중간값 패턴을 반영한다. 중간값 코드는 성능을 치열하게 고민한 코드가 아니다. 그냥 "작동하는" 코드다. 너무 추상적이고, 너무 방어적이고, 레이어가 많고, 알아보기는 쉬운데 최선은 아닌 코드.

Dave가 직접 경험한 얘기도 나온다. 아케이드 게임 Robotron을 AI로 푸는 프로젝트를 하면서, UI에 영상 미리보기를 달았는데 AI가 짠 코드가 느린 거다. 들여다보니까 영상 데이터를 Base64 인코딩한 JSON으로 소켓에 쏘고 있더란다. 상상할 수 있는 가장 비효율적인 방식으로.

"AI가 끔찍한 루틴 하나를 쓰는 게 위험한 게 아니다. 각자는 합리적으로 보이지만, 합쳐보면 메모리 잡아먹고 배터리 태우고 느린 제품을 만드는 수천 개의 조각들을 AI가 만드는 게 위험하다."

나도 AI 코드 리뷰할 때 이런 거 느낀다. 각 함수는 멀쩡한데 전체 흐름을 보면 불필요한 데이터 복사가 있거나, 루프 안에서 할당이 반복되거나. 코드는 동작하고 테스트도 통과하는데, 뭔가 무거운 느낌. 근데 그걸 딱 꼬집어 지적하기가 애매해서 그냥 머지되는 경우가 있다.

---

그래서 어떻게 해야 한다는 건가

Dave의 해법은 크게 두 가지다.

첫째, 성능을 빌드 아티팩트로 만들어라.

단위 테스트가 실패하면 빌드가 터지듯이, 시작 시간이 18% 늘어나도 빌드가 터져야 한다. 아이들 메모리가 300MB 늘어나도 마찬가지. 성능 지표가 매 빌드마다 추적되고, 히스토리로 보이고, 게이팅되어야 한다.

둘째, 예산을 명시적으로 정해라.

"이 기능은 콜드 스타트에 X 밀리초 이상 추가하면 안 된다." "이 백그라운드 서비스는 분당 Y회 이상 CPU를 깨우면 안 된다." 막연한 목표가 아니라 실제 예산. 예산이 있어야 트레이드오프를 의식적으로 결정하게 된다.

이게 비낭만적으로 들릴 수 있는데, 사실 예전 좋은 소프트웨어들이 바로 이렇게 만들어졌다는 거다.

---

개인적으로 느끼는 것

나는 지금 맥북을 쓰는데, 하드웨어는 분명 예전보다 훨씬 빠르다. 근데 Slack 열 때 가끔 버벅이고, 브라우저 탭 30개 넘으면 슬슬 팬이 돌기 시작한다. Chrome 혼자 RAM을 몇 GB씩 먹는 건 이제 당연한 일처럼 됐다.

개발자로서 보면 더 눈에 잘 보인다. 우리 팀 프로젝트도 처음엔 빠릿했는데, 기능이 붙을수록 시작 시간이 늘어났다. 어느 순간부터 로컬 개발 서버 뜨는데 10초 넘게 걸리기 시작했고, 아무도 이걸 이슈로 안 올렸다. 그냥 다들 기다렸다.

Dave의 말 중에 제일 인상 깊은 대목이 있다.

"오래된 소프트웨어가 잘 한 것이 있다면, 현실이 취향을 강요했다는 거다. 지금 우리는 그 취향을 스스로에게 강요해야 한다."

제약이 없으니까 규율도 없어졌다. 그 결과가 지금의 무거운 소프트웨어 생태계다.

물론 나도 빠른 배포를 위해 라이브러리 가져다 쓰고, AI 코드 어느 정도 검토하고 머지하고, 성능보다 기능 먼저 챙기는 경우가 있다. 솔직히 다 해봤다. 근데 이 영상 보고 나서 적어도 "내가 지금 어디서 타협하고 있구나"는 인식하게 됐다.

인식이 시작이니까.

---

#새컴퓨터느린이유 #소프트웨어블로트 #개발자일상 #성능최적화 #마이크로소프트 #프로그래밍 #소프트웨어개발 #기술블로그 #DavesGarage #AI코딩 #개발자생각 #앱최적화 #전직MS엔지니어 #테크유튜브