소프트웨어 환멸감

• 현대 소프트웨어는 하드웨어 발전을 효율·간결함·완성도로 되돌려주기보다, “컴퓨터가 충분히 빠르다”는 전제에 기대며 비효율을 정상화해 왔음
• 웹 스크롤, Google Inbox의 이메일 열기 13초, Windows 10 업데이트 30분, 텍스트 에디터 입력 지연처럼 기본 작업도 기대보다 느리게 느껴짐
• Android 시스템 6GB, Windows 10 4GB, Google Keyboard 150MB, Electron 앱과 Slack 사례는 앱과 플랫폼의 비대화가 성능·복잡성·신뢰성 비용으로 이어짐을 보여줌
• OS·앱·브라우저 업데이트와 iOS 11의 32비트 앱 지원 중단처럼, 한때 잘 동작하던 소프트웨어도 시간이 지나며 느려지거나 망가질 수 있음
• 더 나은 소프트웨어를 만들려면 엔지니어가 자신이 만든 시스템의 성능·구조·한계를 이해하고, 더 적은 리소스로 빠르고 예측 가능한 결과를 내야 함

---

성능을 낭비하는 소프트웨어

• 현대 소프트웨어는 가능한 성능의 1% 또는 0.01% 로 실행돼도 괜찮다고 받아들여지는 경우가 많음
• 자동차, 건축, 비행기는 물리적 한계나 최적 형태에 가까워지는 반면, 소프트웨어는 비효율을 “컴퓨터가 충분히 빠르다”는 말로 정당화함
• “프로그래머의 시간은 컴퓨터의 시간보다 비싸다”는 격언은 컴퓨터 시간이 전례 없이 낭비되는 현실을 가릴 수 있음
• 매일 실행하는 Python 프로그램을 Rust로 재작성해 1.5초에서 0.06초로 줄였지만, 6시간을 보상받는 데 41년 넘게 걸린다는 트윗은 효율 논의의 대표 사례로 쓰임

참을 수 없을 정도로 느린 기본 경험

• 최신 휴대용 컴퓨터는 달 착륙 시대의 컴퓨터보다 수천 배 강력하지만, 최신 MacBook Pro에서도 웹 페이지를 60fps로 부드럽게 스크롤하기 어려움
• Google이 만든 Inbox는 Google Chrome에서 이메일 하나를 여는 데 13초가 걸림
  • 콘텐츠 대신 빈 흰 상자를 애니메이션하는 방식은 웹 페이지가 낼 수 있는 성능 한계에 맞춘 타협에 가까움
  • 120Hz 디스플레이가 주류가 된 시점에도 웹 커뮤니티 응답 하나를 보는 데 60Hz조차 안정적이지 않다고 봄
• Windows 10 업데이트는 30분이 걸리며, 그 시간이면 SSD를 포맷하고 새 빌드를 받아 설치하는 일을 여러 번 할 수 있다고 비교함
• 현대 텍스트 에디터는 42년 된 Emacs보다 입력 지연이 큼
  • 키 입력마다 작은 사각 영역만 갱신하면 되는 작업도 16ms 안에 처리하지 못한다고 지적함
  • 3D 게임은 같은 16ms 안에 화면 전체 렌더링, 입력 처리, 월드 계산, 리소스 관리를 수행함
• 더 빠른 하드웨어는 더 나아진 소프트웨어보다, 같은 일을 더 느리게 하는 소프트웨어를 돌리는 데 쓰이는 상황이 됨

비대해진 앱과 플랫폼

• 웹 앱은 광고만 막아도 10배 빨라질 수 있으며, AMP는 새로운 기술이라기보다 비대한 부분을 제거하라는 상식적 해결책에 가까움
• Android 시스템은 아무 앱이 없어도 6GB이고, Windows 95는 30MB였으며 Windows 10은 4GB임
  • Windows 10은 Windows 95보다 133배 크지만 기본 기능은 크게 다르지 않다고 봄
  • Android는 Windows 10보다도 1.5배 큼
• Google Keyboard는 보통 150MB, Google 앱은 350MB, Google Play Services는 300MB를 차지함
  • Google Keyboard가 화면에 키 서른 개를 그리는 앱인데 Windows 95 전체보다 5배 복잡한지 묻는 방식으로 비판함
  • Google Play Services는 쓰지 않아도 지울 수 없음
• 기본 앱을 설치한 뒤 사진 저장 공간이 약 1GB만 남는 상황은, 플로피 디스크에 OS·앱·데이터를 모두 저장하던 시절과 대비됨
• Electron 기반 Todo 앱에는 Xbox 360 컨트롤러 드라이버, 3D 그래픽 렌더링, 음악 재생, 웹캠 촬영 기능까지 포함될 수 있음
• Slack은 채팅과 간단한 텍스트 에디터에 가까운 앱인데도, 로딩 속도와 메모리 사용량 때문에 무거운 앱으로 분류됨
• 앱이 커질수록 제어 상실, 복잡성 비용, 성능 손실, 신뢰성 채무가 커지며 과도하게 무거운 앱을 정상으로 받아들여서는 안 됨

시간이 지나며 썩는 소프트웨어

• 3년 전에는 16GB Android 폰으로도 충분했지만, Android 8.1 시대에는 앱들이 특별한 이유 없이 두 배씩 커져 쓰기 어려워짐
• iPhone 4s는 iOS 5와 함께 발표됐지만 iOS 9 실행은 버겁고, iOS 9이 근본적으로 훨씬 뛰어난 것도 아니라고 지적함
• iOS 11은 32비트 앱 지원을 중단해 개발자가 없거나 업데이트하지 않는 앱은 다시 볼 수 없게 될 수 있음
• DOS 프로그램은 1980년대 이후 여러 컴퓨터에서 수정 없이 돌아가지만, JavaScript 앱은 다음 Chrome 업데이트에도 망가질 수 있다는 트윗을 인용함
• 오늘 멀쩡했던 웹 페이지도 10년 안에 어떤 브라우저에서도 제대로 돌아가지 않을 수 있음
• 같은 일을 하기 위해 새 전화기와 새 MacBook을 사지만, 결국 같은 앱을 더 느리게 실행하는 상황이 반복됨

낮아진 품질 기대치

• 웹 페이지는 문제가 생기면 원인을 살피기보다 새로고침을 누르라고 요구함
• 웹 앱은 호환되는 브라우저에서도 “무작위” JavaScript 오류를 쏟아낼 수 있음
• 웹 페이지와 SQL 데이터베이스 설계는 렌더링된 웹 페이지를 보는 동안 데이터가 바뀌지 않을 것이라는 희망 위에 세워져 있다고 비판함
• 공동 작업 기능은 “최선의 노력” 수준에 머무는 경우가 많아 데이터를 잃을 수 있는 일상적 시나리오를 품고 있음
  • “어떤 버전을 유지할까요?” 같은 다이얼로그는 작업물 중 하나를 파괴할 대상을 고르라는 뜻에 가까움
• Linux는 임의로 프로세스를 죽이는 설계를 갖고 있어도 서버에서 가장 인기 있는 운영체제임
• Dell 모니터, AirDrop, Bluetooth 사례는 장치 안의 소프트웨어와 복잡한 사양이 주기적 리셋이나 운에 의존하는 경험을 만든다는 점을 보여줌
• 안정적으로 작동하는 무언가를 전달하려면 만든 대상을 안팎으로 이해해야 하지만, 과하게 부풀려진 시스템에서는 그것이 어려움

프로그래밍 도구와 개발 관행의 혼란

• 패키지 관리, 빌드 시스템, 컴파일러, 언어 설계, IDE 같은 기본 요소에서도 빠르고 효율적이며 오래가는 완성도를 보기 어려움
• 빌드 시스템은 모든 변경 정보를 갖고도 주기적으로 전부 지우고 다시 하기를 요구함
  • 신뢰성 있고 예측 가능하며 재현 가능하게 만들 수 없을 이유가 없다고 봄
  • NPM은 수년간 “가끔 동작함” 상태에 머물렀다고 표현됨
  • rm -rf node_modules가 Node.js/JavaScript 개발에서 피할 수 없는 것처럼 보인다는 트윗을 인용함
• 컴파일러와 사전·사후 작업이 몇 분 또는 몇 시간씩 걸려도 받아들여지는 현실은 “프로그래머의 시간은 중요하다”는 말과 충돌함
• Hadoop을 PC 한 대에서 실행하는 것보다 느린 상황에서도 선택하는 사례는, 프로그래머가 항상 합리적 결정을 내리지는 않음을 보여줌
• 머신 러닝과 “인공지능”은 소프트웨어를 신뢰할 수 없는 추측의 시대로 옮겼다고 비판함
  • “인공지능”이나 “머신러닝”이 쓰인 앱·서비스는 신뢰성 없고 예측 불가능하며 결과 설명이 어렵다고 읽는다는 트윗을 인용함
• Linux 위에 VM을 올리고, VM 안에 Docker를 넣는 방식은 프로그램·언어·실행 환경을 깔끔히 치우는 방법을 모른다는 신호로 해석됨
  • Go의 단일 실행파일이 주요 장점으로 꼽히는 현실은, 엉망이지 않기만 해도 성공으로 간주되는 상황을 드러냄
• 의존성은 간단한 문제를 “전체 패키지 솔루션”으로 해결하려다 도입 비용과 또 다른 의존성을 함께 끌고 옴
• 프로그램을 재부팅 없이 몇 년 동안 쓰기 어렵고, 때로는 며칠도 어렵다고 지적함
  • 프로세스 재시작, 데이터베이스 재기동, 20분마다 앱을 재시작하는 워치독, 중복 리소스 포함과 압축 전송은 고치는 대신 빨리 넘어가는 방식임
• 이런 관행은 엔지니어링이 아니라 게으른 프로그래밍이며, 엔지니어링은 만든 것의 성능·구조·한계를 깊이 이해하는 일임

쌓여버린 복잡성과 시장의 무관심

• 현재 소프트웨어는 근근이 동작하는 코드 위에 다시 근근이 동작하는 코드가 쌓인 상태이며, 계속 커지고 복잡해져 바꿀 기회가 줄어듦
• 건강한 생태계에는 때때로 후퇴한 뒤 전진하는 과정이 필요하지만, 25년간 새로운 OS 커널을 보지 못했고 이제는 재작성하기에 너무 복잡해졌다고 지적함
• 브라우저도 엣지 케이스와 역사적 문제 때문에 레이아웃 엔진을 바닥부터 새로 작성하기 어려움
• 오늘날의 진전은 모놀리스 문제를 해결하려고 마이크로서비스를, 마이크로서비스 문제를 해결하려고 Docker를, Docker 문제를 해결하려고 Kubernetes를 도입하는 식으로 불 위에 연료를 더 붓는 것처럼 보임
• XML 기반 선언 설정에서 YAML 기반 마이크로서비스 설정으로 옮겨왔지만, 과거 XML에는 적어도 스키마가 있었다는 트윗을 인용함
• 사용자는 엔지니어가 제공하는 것을 받아들일 수밖에 없고, Android 앱 350MB, 끊기는 스크롤, “작동하지 않으면 재부팅” 같은 상황에도 선택지가 거의 없음
• 경쟁 제품들도 모두 느리고 크고 품질이 낮으면 경쟁 압력이 생기기 어려움
  • iPhone/iOS와 다른 스마트폰, Chrome과 다른 브라우저처럼 한때 긴장을 만드는 제품이 나오기도 하지만 오래가지는 않는다고 봄
• 엔지니어의 임무는 현대 컴퓨터로 성능, 신뢰성, 품질, 가용성 측면에서 무엇이 가능한지 보여주는 일이어야 함

그래도 보이는 대안

• Martin Thompson의 LMAX Disruptor, SBE, Aeron은 인상적이고 단순하며 효율적인 예로 꼽힘
• Raph Levien의 Xi editor는 올바른 원칙을 염두에 두고 만든 것으로 평가됨
• Jonathan Blow는 자신의 게임을 위해 언어를 만들었고, 그의 노트북에서 50만 줄 코드를 1초 만에 완전 새 컴파일할 수 있음
  • 증분 빌드도 중간 캐시도 아닌 전체 새 컴파일 결과임
• 빠른 프로그램을 작성하는 데 천재나 마술이 필요한 것은 아니며, 유행하는 툴체인 같은 거대한 쓰레기 더미 위에 만들지 않으면 된다고 봄

더 나은 소프트웨어를 위한 요구

• 소프트웨어 엔지니어링은 현 상태에 머무르지 않고 더 나아져야 하며, 같은 것을 반복해 더 느리고 큰 형태로 만들 필요가 없음
• 오늘날의 개발은 진전이라기보다 너덜거리는 도구 위에서 비즈니스 목표만 간신히 충족하는 상태에 가까움
• 지역 최적화에 얽매인 결과, 비대하고 비효율적인 상태에 익숙해졌다고 지적함
• 엔지니어는 더 나은 도구로 더 나은 앱을 몇 배는 적은 리소스로 빠르고 예측 가능하며 신뢰성 있게 만들 수 있고, 그렇게 해야 함
• 신뢰성 있고 예측 가능한 고품질 제품을 전달하려면 무엇을 왜 하는지 완전히 이해해야 하며, “주어진 게 이렇다”는 변명은 받아들일 수 없음

[xguru]

이 글은 한국어 번역이 예전에 나왔으니 그걸 보시면 됩니다.

https://tonsky.me/blog/disenchantment/ko/

아예 번역 링크로 바꿔두었습니다.

[GN⁺]

Hacker News 의견들

• 더 작고 깨끗하며 버그가 적고 안전하고 빠르며 오래 가는 코드는 당연히 가능함. 정보화 시대 초창기에도 해냈다면, 수십 년의 경험과 강력한 도구가 있는 지금 못 할 이유가 없음
  그렇게 하지 않는 이유는 거기에 돈이 없기 때문이고, 사실은 반대에 가까움. VC 투자 스타트업은 먼저 시장에 나가야 살아남고, 성숙한 조직에서도 비용과 비대화는 문제가 아니라 관리자 위신을 키우는 기능처럼 작동함. 결국 비용은 고객에게 전가됨
  “무자비한 시장 원리”가 이런 낭비를 바로잡지 않는 이유는, 더 나은 코드베이스가 언젠가 왕국의 열쇠를 얻을 수는 있어도 현실의 경쟁 환경은 병리와 유행에 너무 취약하기 때문으로 보임

  • Kagi는 VC 투자를 받지 않았지만, 그래도 최적이 아닌 코드와 많은 버그, 여기저기 이상한 성능 문제가 있음. 소프트웨어 개발을 아는 입장에서는 자금 출처나 회사 규모와 무관하게 피하기 어렵고, 소프트웨어의 복잡도·가용 자원·인센티브의 함수라고 봄
    다만 VC 투자 회사보다 쉽게 할 수 있는 건 리팩터링과 기술 부채 처리에 시간을 배정하는 것임. 실제로 지금 45일 동안 신규 기능 개발에 급브레이크를 걸고 주요 기술 문제를 다루는 중임. 내년에 인수될 거라고 기대하면 이런 투자는 하기 어렵고, 기술 부채는 남의 문제가 됨
    제품이 계속 개발되는 한 새 버그와 문제가 계속 생김. “완벽한 코드”는 새 기능이 더 이상 추가되지 않는 닫힌 맥락에서만 가능함
  • “거기에 돈이 없다. 사실은 반대다”라는 말은 반복할 가치가 있음. 이게 소프트웨어를 집어삼킨 병이고, 현대 소프트웨어를 가능한 최악의 버전으로 만들고 있음
    VC 투자 모델이 업계를 이렇게 몰고 왔다고 봄. 스타트업은 수백만 달러를 받고, 투자자에게 갚을 만큼 빨리 돈을 벌어야 하니 앱에서 최대한 빨리 돈을 짜내야 함. ROI 지표가 붙지 않는 일은 누구의 관심도 받지 못함
  • 예전 소프트웨어가 더 안전했다고 보진 않음. 컴퓨터 사용자들이 더 순진하고 신뢰가 많았을 뿐임. 네트워크에 더 많은 기계가 연결되면서 많은 걸 배웠음
    기본적으로 열린 접근, 비밀번호 없음 또는 짧은 비밀번호, 안전하지 않은 비밀번호 저장, 전부 평문, 입력 정제 무시, telnet 같은 것들이 있었음
    소프트웨어가 더 비대해진 또 다른 이유도 여기 있음. 상호작용과 위험을 보기 시작했고, 한 번 보면 못 본 척할 수 없음. 처리해야 할 경계 조건은 줄지 않고 늘고 있으며, 지원해야 할 하드웨어도 많아짐
    성능 좋은 코드를 작성하는 과정은 개선될 수 있지만, 동시에 기준선은 우리가 도달하는 속도보다 더 빠르게 올라가고 있음. 이제는 다시 비밀번호 없는 방향으로 조금씩 가고 있다는 점도 흥미로움
  • 인센티브가 맞지 않는다는 데 동의함. 성능과 정확성이 실제 가치를 갖는 산업 분야가 있음. 글쓴이처럼 소프트웨어 장인정신을 중요하게 여긴다면, 그런 분야로 옮기는 게 일을 즐기는 가장 좋은 방법임
  • 단순히 말하면 코드를 출시하는 게 아니라 기능을 출시하는 것임. 자동 의존성 주입, 우아한 추상화, 멋진 컴파일러 트릭을 출시하는 게 아니라 고객이 돈을 낼 새 기능을 출시함
    리팩터링을 고통스럽게 만드는 높은 단위 테스트 커버리지는 기능 출시를 방해할 때가 많고, 테스트 주도 개발 광신자들이 인정하려는 것보다 훨씬 자주 그렇다고 봄. 업계의 많은 “모범 사례”는 제품-시장 적합성을 이미 찾고 돈이 저절로 찍히는 회사에 있는 사람들이 만든 비현실적 교리에 가깝다

• 아직 간신히 쓸 수 있는 HP MS200 올인원이 있음. 2017년에 차고 세일에서 싸게 샀고, Linux를 올리면 Chrome이 로드된 뒤에는 Skype 웹 버전 전체 화면 영상통화나 YouTube 전체 화면 시청도 가능했음
  최근 다시 받아서 아이용 컴퓨터로 만들기 전에 FC38과 최신 Chrome을 설치했더니 YouTube 영상이 슬라이드쇼가 됨. 설정을 아무리 만져도 안 돼서 RAM을 2GB에서 3GB로 늘렸더니, 6년 전과 같은 720p 전체 화면 재생 수준으로 돌아옴
  같은 일을 하는 데 메모리가 1.5배, 1GB 더 필요해진 셈임. 16GB가 최소라는 말도 알지만, 이 형편없는 기계에서도 Chrome은 거의 유휴 상태의 웹 브라우저인데 메모리 풋프린트를 30GB 정도로 보여줌. 대부분은 mmap된 파일이겠지만, 그래도 30GB임

  • YouTube는 성능 차이를 보여주는 좋은 예임. 영상 품질은 최신 코덱 덕분에 올라갔지만, 오래되거나 싼 기계는 최신 GPU가 없어 소프트웨어로 디코딩해야 하고, 때로는 JavaScript로 처리해 매우 낭비적이지만 모든 기계에서 동작함
    반대로 대부분의 기기에서는 배터리 수명 증가, 낮은 온도, 더 작은 RAM·디스크 요구량이 명백한 개선임. YouTube가 옛 인코딩 파일을 서버에 중복으로 남겨둘 수도 있지만, 최신 기기에서 접속하는 사용자가 대부분인 상황에서는 공간 낭비가 됨
    Chrome의 RAM 사용 증가 대부분은 샌드박스 아키텍처 발전에서 왔음. 공유 메모리와 프로세스 공간은 샌드박스를 탈출하는 공격에 쓰일 수 있어서 격리가 더 추가됐고, Chrome이 탭·확장마다 새 독립 프로세스를 띄우는 것도 큰 원인임
    요즘은 광고 차단기도 영향이 큼. 웹이 더 나빠지면서 효과적인 광고 차단기는 만들기 어려워졌고 더 많은 자원을 필요로 함. 느린 소프트웨어가 단지 사람을 괴롭히려고 느려진 건 아니고, 위험한 해킹을 좋은 구현으로 바꾸고 요구사항이 변한 결과인 경우가 많음. FLV는 더 이상 충분하지 않고, h264도 h265와 AV1이 퍼지면 5년 뒤엔 오래 버티기 어려워 보임
  • 웹 브라우저는 사실상 자체 운영체제가 됐음. “현대 웹”에는 너무 많은 기능이 있고, 같은 기능도 대여섯 가지 경쟁 방식으로 구현되는 경우가 흔함. 현대 하드웨어에서도 텍스트 렌더링만으로 큰 부담이 될 수 있음
    현대 도구 체인은 “바퀴를 재발명하지 말라”에 집중하지만, 각 의존성이 서로 다른 버전의 바퀴를 골랐다면 의존성 몇 개만 끌어와도 같은 저수준 기능 구현이 6개씩 들어오게 됨
  • 새 Linux를 설치할 때마다 기본 UI에 기회를 주지만 결국 MATE로 돌아가곤 함. 그런데 이 낡은 기계에서 Gnome Shell은 꽤 또렷하게 반응했고, 앱 스토어도 있었으며 Chrome도 있었음
    다만 설치된 건 Flatpak이었고 비대함이 느껴졌음. 다행히 Chrome은 아직 RPM으로 직접 네이티브 설치가 가능하고, OS의 공유 라이브러리를 실제로 사용함
  • Linux/X11에서 그래픽 웹 브라우저를 돌리려면 8MB가 필요하던 때가 기억남. 아마 Netscape Navigator였고, 8MB면 충분했으며 16MB면 조금 더 편했음

• 이 글은 핵심 고통인 버그를 건드리지도 않음. 거의 모든 소프트웨어가 가능한 한 버그투성이처럼 느껴짐. 흔하지 않은 경로나 비정상 흐름으로 소프트웨어를 쓰게 될 때마다 겁이 나고, 거의 항상 실패함
  얼마 전 Carvana에 차를 팔 때 Chrome과 Firefox를 오가며 겨우 처리했음. Chrome에서는 이미지 업로드 마법사가 JS 예외를 냈고, 그 부분은 Firefox에서만 기적적으로 됐지만 나머지 사이트는 Firefox 테스트를 안 한 게 뻔할 정도로 문제가 많았음
  더 나쁜 건 비기술 사용자들이 버그를 만나면 자기가 뭘 잘못했다고 생각한다는 점임. 비대하고 느리더라도 안정적이고 단단한 소프트웨어라면 이제는 기꺼이 받아들일 수 있음

  • 한편으로는 지금 있는 것들이 이렇게 잘 돌아간다는 게 믿기지 않음. 모든 계층이 덕트테이프와 껌으로 붙어 있는 것 같은데도 실제로 동작함. 인류가 이뤄낸 게 매일 놀라움
    다른 한편으로는 모든 게 얼마나 버그투성이인지 계속 보이고, 실제로 더 버그가 많아진 건지 아니면 내부 사정을 알게 된 나이가 들수록 대기업식 소프트웨어 개발에 참을성이 줄어든 건지 모르겠음. 명백한 UX 버그가 쉽게 잡히는데도 “기능 X를 당장 출시하라”고 하는 환상의 제품 담당자에게 화가 남
  • Jonathan Blow의 “세계의 종말” 강연을 본 뒤로 신경 써 보니, 매일 받아들이고 사는 형편없는 소프트웨어 경험이 놀랄 만큼 많음
    비용, 기회비용, 실용주의 같은 주장도 이해하고 일부 동의하지만, 때로는 반쯤 지어진 세계에서 사는 걸 우리가 그냥 받아들였다는 느낌을 지우기 어렵다
  • 10대 때 1세대 MacBook Air가 나왔을 때, 친구가 매장 데모 기기에서 Dock의 앱을 빠르게 연속으로 열기만 해도 안정적으로 크래시시킬 수 있다는 걸 알아냈음. 몇 초 클릭하면 기계가 크래시 후 재부팅됐음
    지금도 나아진 것 같지 않음. 어린 아이들이 휴대폰이나 노트북을 손에 넣으면, 버튼을 너무 빨리 누르거나 예상치 못한 순서로 누르는 것만으로도 현대 기기를 꽤 안정적으로 멈추고 얼리고 크래시시킴. 물리적으로 망가뜨리는 것도 아닌데 이게 현대 기술의 상태임
    왜 고쳐지지 않았는지는 이해됨. 사람들은 가끔 재시작이 필요하다고 기대하게 됐고, 이런 경우엔 아이 탓으로 돌리기 쉬우며 재시작하면 해결되기 때문임. 그래도 운영체제 수명 주기상 이제는 더 나아졌기를 바랐음
  • https://danluu.com/everything-is-broken/
  • 예전보다 소프트웨어가 훨씬 더 버그투성이라고 보진 않음. 90년대 말과 2000년대 초에 Windows 머신 지원을 해 본 사람들은 안다

• C에 대해 쓴 글에서는 말하지 않았지만, 내가 C를 쓰는 큰 이유 중 하나는 소프트웨어를 비대하게 만들기 어렵기 때문임. 기능을 추가할 수는 있지만, 단일 기능이 실행 파일에 100KB를 더하는 것도 쉽지 않음
  지금 고용된 상태는 아니지만 “작업”용으로 강력한 기계를 쓰고 있음. 그래도 IDE 대신 Neovim과 tmux를 쓰고, 일반적인 Linux 배포판이 아니라 크게 수정한 Gentoo와 systemd 대신 OpenRC를 쓰며, 전체 데스크톱 대신 Qtile이라는 타일링 창 관리자를 사용함
  부팅하고 막 로그인했을 때 프로세스가 40개뿐일 정도로 기계를 비대하지 않게 유지함. 지금은 정말로 소프트웨어를 엔지니어링하고 있음. C의 문제를 효과적으로 완화하면서도 소프트웨어를 작고 빠르게 유지하려고 노력 중이고, 언젠가 그 위에 사업을 만들 수 있기를 바람
  비대하지 않고 날렵한 소프트웨어에 아직 시장이 있는지 보게 될 것 같음
  https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
  https://gavinhoward.com/2020/12/my-development-environment-a...
  https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
  https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...

  • 흥미로운 관점임. 나는 C 언어가 어셈블리로 직접 쓰는 것에 비해 비대하다고 여겨지던 시절을 기억할 만큼 나이가 있음
    1980년대 WordPerfect, Lotus 123, MS-DOS 1.0, Microsoft가 인수하기 전 SubLogic Flight Simulator 같은 프로그램은 어셈블리로 작성됐음. 당시 업계 관찰자들은 MS Word와 MS Excel이 “비대한” C로 작성됐기 때문에 Microsoft가 WordPerfect와 Lotus 123보다 새 기능을 더 빨리 반복하고 다른 아키텍처로 더 빨리 이식했다고 봤음. 경쟁사들이 어셈블리에 너무 오래 머물렀기 때문임
    개인용 소프트웨어에서도 같은 절충을 봄. 더 날씬한 C/C++ 대신 더 고수준이고 “비대한” C#/Python을 쓰면 특정 작업을 훨씬 빨리 끝낼 수 있음. C++에 더 능숙하고 작은 실행 파일을 선호하지만, C#이 원하는 작업을 더 빨리 끝내면 그 장점은 의미가 없어짐. 나도 비대한 소프트웨어 문제의 일부임
  • “진짜 엔지니어링”은 이런 결정을 절충의 스펙트럼 위에 놓고, 만든 사람과 사용자의 제약에 맞춰 프로젝트를 배치하는 것이라고 봄. 그 결과 한쪽 극단에 갈 수는 있지만, 다른 제약 때문에 다른 위치에 있는 사람들이 “진짜 엔지니어링”을 하지 않는다는 뜻은 아님
    “세상에서 가장 강하고 가벼운 다리를 만들겠다”는 경이로운 일이고, “고객이 감당할 수 있는 비용으로 충분히 가볍고 충분히 강한 다리를 만들겠다”가 엔지니어링임
  • 단일 기능이 실행 파일에 100KB도 추가하기 어렵다고 했지만, Unicode 지원을 해 보면 달라짐
  • “C의 문제를 효과적으로 완화한다”는 부분을 더 설명해 줄 수 있는지 궁금함. 언어 자체의 문제를 해결하려는 건지, 새로운 C 방언을 쓰는 건지, glibc 정적 링크의 어려움 같은 생태계 문제인지, 아니면 완전히 다른 얘기인지 알고 싶음
  • “C++ 일자리 제안을 거절한 적이 있다”는 말에는 공감함

• 절반 조금 넘게 읽고 멈췄지만, 핵심 주장은 소프트웨어가 빨라야 한다는 것처럼 보였고, 그 철학에 대한 정당화는 “그냥 진리”라는 암시 말고는 기억나지 않음. 효율 향상분이 효율을 좇는 시간 비용을 결코 상쇄하지 못하는 경우가 있다는 반론은 인정했지만, 그 논증과 제대로 씨름하지 않고 넘겼음
  글의 또 다른 핵심 특징은 데이터를 체리피킹하고 영역을 과도하게 단순화하는 것이었음. “도대체 소프트웨어가 그 시간과 공간을 써서 뭘 하길래?”라는 감정적 호소를 여러 번 하지만, 그 질문에 진지하게 답하려 하지 않고 답이 없다는 사실을 잘못된 답의 증거처럼 사용함. 기능 동등성이 없는 여러 소프트웨어를 성능만 다른 것처럼 비교하기도 함
  비효율의 사회적·환경적·비즈니스 비용과 더 효율적인 소프트웨어에 대해 할 말은 많지만, 현대 소프트웨어가 원래 아무것도 못 만들 사람도 자기에게 필요한 “나쁜” 것을 만들 수 있게 해 준다는 점도 논의할 만함. 구조 엔지니어가 “충분히 강한” 것을 고르듯 현대 개발자들도 “충분히 빠른” 것을 목표로 하는 경우가 많음
  풍부한 논쟁거리가 많지만 이 글은 감정적 분노에 머물렀고 실제 이성과 논증을 다루지 못했음. 일부 주장에는 진실이 있지만, 글 자체는 토론할 생각이 없다는 걸 분명히 했다고 봄

  • 사용자 관점에서 보면 소프트웨어는 빨라야 한다는 건 사실임. 이 댓글을 iPhone 4로 썼는지 14로 썼는지, 워크스테이션이 RAM 4GB짜리 Pentium인지 생각해 보면 됨
    네트워크도 수 kbps의 2G가 아니라 수백 Mbps의 5G나 광회선일 가능성이 큼. 결국 행동이 말보다 크고, 사회 전체가 “더 빠른 소프트웨어”라는 공리를 따른다면 사실로 받아들여도 됨
    특히 “개발자 시간이 더 가치 있다”는 주장과 같은 곳에서 나온 공리이고, 차이는 누구의 시간을 아끼느냐뿐임
  • 비싼 M1 Mac에서 코드가 몇 초 걸린다면, 잠재 사용자 중 꽤 큰 비율은 몇 분을 기다려야 할 수 있음. 비기술 사용자들은 성능이 새 하드웨어를 사지 않고도 크게 개선될 수 있다는 걸 모르기 때문에 그런 부조리를 그냥 받아들이는 경우가 많음
    개발자가 저사양 기기에서도 테스트하지 않으면 이 문제를 전혀 알 수 없음. 진짜 문제는 기술적 측면보다, 코드가 너무 느리다는 불편한 진실을 마주했을 때 일부 개발자가 방어적으로 변하고 논쟁부터 하는 태도임. 제품 관리자와 앉아서 프로파일링과 최적화 시간을 잡고, 처음부터 다시 만들지 않고 성능 문제를 어떻게 완화할지 봐야 함
  • 감정적인 분노가 좋았음. 때로는 데이터가 이미 알고 있는 진실을 흐릴 뿐임. 최고의 소프트웨어를 만들기 위해 최선을 다해야 한다는 걸 데이터가 말해 줄 필요는 없고, 이 글이 그걸 상기시켜 줌
  • “현대 소프트웨어가 사람들에게 나쁜 무언가를 만들 수 있게 해 준다”에서 현대 소프트웨어가 정확히 뭐가 특별한지 모르겠음. 무엇을 기준으로 현대적이라고 판단하는지도 불명확함
    BASIC과 SQL도 오래전부터 사람들이 “나쁜” 무언가를 만들 수 있게 하려는 목적이 있었고, Fortran과 지금은 사라진 여러 언어·기술도 마찬가지였음
    Python이나 Java는 후하게 봐도 보수적이고, 70년대의 프로그래밍 언어 발전을 생각하면 사실 시대착오적이라고 불러야 함. J나 Prolog는 Rust나 Go보다 개념적으로 훨씬 앞서 있지만 더 일찍 만들어졌음. C89부터 C23까지 누적된 C는 현대 언어인지, C23만 현대적인지, C89와 C23 사이에 정말 큰 차이가 있는지도 애매함
    만들어진 시점이나 상상 속 진화나무가 아니라면, 현대성을 정의할 다른 방법이 있는지 궁금함
  • 글 초반의 “소프트웨어에서만 프로그램이 가능한 성능의 1%나 0.01%로 돌아도 괜찮다. 모두가 괜찮아하는 것 같다”는 문단에서 저자가 자기 질문에 답했다고 봄. 모두가 괜찮아한다면 넘어가면 됨

• 오래된 불평임. 우리가 당연하게 여기는 많은 편의에는 비용이 있고, 그 비용은 크게 누적됨. 4K 화면은 800x600보다 픽셀이 17배 많고 32비트 색을 쓰므로, 현대 디스플레이용 그래픽의 원시 크기는 약 68배 커짐
  예전에는 정적 이미지가 충분했지만 이제는 고품질 고프레임 애니메이션이 표준임. Arial Unicode는 15MB짜리 글꼴이고, Windows 95를 돌리던 대부분의 컴퓨터 메모리에는 들어가지도 않았을 것임
  어디서나 맞춤법 검사가 당연해졌고, 이런 것들이 쌓임. 그래도 컴퓨터를 훨씬 더 쾌적하게 만들어 줌. 16색 비디오 모드나, 매우 짜증나는 우회 없이 영어가 아닌 두 언어를 동시에 못 쓰던 시절은 그립지 않음

  • 같은 4K와 Unicode 제약 안에서도 몇 자릿수 더 효율적인 앱들이 있으므로, 이것만으로는 설명이 안 됨
  • 비용이 있는 건 맞지만, 항상 그 비용이 가치 있는 건 아님. 4K 화면은 원하고 그 픽셀 값은 낼 의향이 있음
    하지만 기다리는 시간을 덜 지루하게 보이려는 이유밖에 없는 애니메이션은 원하지 않음. Unicode도 비용을 낼 만함
    그래도 1981년에 그랬듯 글리프를 한 자릿수 밀리초 안에 화면에 그릴 수 있어야 함. 픽셀과 글리프가 더 많아졌지만 가능하고, 단지 우선순위가 아닐 뿐임
  • 모든 산출물이 훨씬 더 많은 자원을 먹는 건 알겠지만, 100배 더 많은 계산 자원을 쓰고도 왜 소프트웨어는 여전히 고통스러울 정도로 느린지 설명이 필요함
    성능형 BMW에 10만 달러를 냈는데 엔지니어가 0-60mph에 30초 걸린다고 말하고, 사용자가 성능 전문가가 아니니 그대로 받아들여야 하는 것과 비슷함

• 현재 조직에서도 비슷한 흐름을 봤음. 초기에 팀이 작을 때는 세부사항이 중요했음. 느리면 안 되고, 애니메이션은 부드러워야 하고, 스크롤 속도와 로딩 시간이 중요했으며, 사용자 효율을 높이기 위해 가장 효율적인 제품을 만들려 했음
  팀이 커지면서 가치는 개발자 효율을 높이는 쪽으로 바뀌었음. 더 많은 추상화, 계층, 프레임워크가 들어왔고, 개발자 하루를 아끼는 대가로 사용자 전체의 수백만 초를 쓰는 절충이 받아들여졌음
  차이는 가시성에 있음. 경영진은 개발 측 비용은 볼 수 있지만, 조금 더 빠른 실행 시간, 더 나은 캐싱, 더 부드러운 스크롤의 이익은 보지 못함. 측정되지 않기 때문임. 조직이 측정 가능한 숫자만 신경 쓰는 지점에 가면 이런 흐름은 자연스러워 보임

  • 앞으로 몇 년 동안 LLM이 코드 품질과 성능에 끼칠 참담한 영향을 기다려 보면 됨. 새 프로그래머 물결은 “GPT 속삭임꾼”이고, IDE 안에서까지 챗봇에 매달려 대부분의 시간을 보내며 챗봇이 대신 프로그래밍하게 함
    물론 AI가 우리가 잘못 짠 것, 또는 AI가 잘못 짠 것, 그리고 원글이 예측하듯 매우 비효율적인 AI 자체까지 모두 고칠 수 있는 지점에 도달하기 전까지의 얘기임
  • 측정 가능성뿐 아니라 수익성의 문제임. 자본주의는 효율적인 제품이 아니라 효율적인 생산을 낳음. 생산 시스템에서 이윤을 추출하는 데만 관심이 있기 때문임
    자동차는 외부의 석유 충격이 온 뒤에야 최적화됐고, 그조차 매우 불균일했음. 실제로 비효율적인 제품은 고객이 더 자주 교체해야 하므로 더 수익성이 높은 경우가 많음. 1년 뒤 갈라지는 형편없는 iPhone 케이블은 Apple이 다시, 또 다시 교체품 비용을 청구할 수 있게 해 줌. 백색가전은 더 자주 고장 나지만 더 싸게 만들어져 단위당 이익을 높임. 중요한 건 판매 후 사용 효율이 아니라 생산 효율임
    소프트웨어에서 자본주의는 새 자동화를 최대한 빨리 쏟아내고, 소비자가 에너지와 시간 낭비를 떠안게 만드는 방식으로 작동함. 생산 체인은 점점 표준화되고 최적화되어 React 개발자나 Kubernetes 관리자를 창고 노동자처럼 교체할 수 있게 됐고, 그에 따른 임금 압박도 생김. 일부 자동화는 회계 용어를 난해하게 만들어 직업을 정당화하는 것처럼 자기정당화에 가깝고, 나머지는 이윤에 관한 것임

• 모든 것에는 비용이 있음. 계산 비용이나 나빠진 사용자 경험이 충분히 크면 효율을 최적화함. ML 모델이 예임. 다른 경우에는 최적화하지 않는데, 최종 사용자가 더 적은 기능을 감수하면서까지 그걸 원하지 않기 때문임
  자동차도 예전에는 연료를 많이 먹었지만, 연료비와 환경 우려 때문에 고객이 다른 걸 원하게 되면서 바뀌었음. 많은 엔지니어는 자신이 고객을 위한 제품을 만들라고 돈을 받는다는 사실을 잊음
  또 원글 작성자는 오래된 Windows나 Linux 머신이 완전히 부팅될 때까지 기다려 본 적이 없는 듯함. 현대 버전은 고객이 원했기 때문에 훨씬 빨리 부팅함. 휴대폰은 24시간 켜져 있으니 몇 달에 한 번 부팅이 오래 걸리는 건 고객이 신경 쓰지 않음

  • 부팅 시간은 여전히 끔찍함. 특히 최신 AM5/DDR5 시스템에서 그렇음
    내 BIOS는 POST에 20초 정도 걸리고, 이게 정상이라고 함. 그 뒤 OS 부팅은 약 10초임
  • 고객에게 의미 있는 선택권이나 선호 표현 수단이 언제 있었는지 모르겠음. 오래전부터 공급 주도 시장이었고, 공급자가 만들고 싶은 걸 만들면 고객은 시장에 나온 걸 사는 구조였음
  • 학교 PC에서 WordPerfect를 부팅하는 데 말 그대로 몇 분이 걸렸음
  • “엔지니어는 고객을 위한 제품을 만들라고 돈을 받는다”는 말은 어느 정도 맞지만, 소프트웨어는 여러 면에서 전기나 의료 서비스처럼 인간 삶의 핵심 요소가 됐음
    의사나 엔지니어도 새 약이나 새 전력원을 개발하라고 돈을 받는다고 말할 수 있지만, 이런 분야는 민감하고 중요하기 때문에 정부 통제가 여러 층으로 존재함. 소프트웨어에는 아직 그런 수준의 통제가 없음
  • 부분적으로 맞지만, Google이나 Apple 규모의 회사가 흐름을 정할 때도 작은 회사나 중견 회사처럼 고객 의지를 따르는 척해서는 안 됨
    이들은 환경 자체를 형성할 힘이 있어서 “고객 요구”의 결과를 크게 방향 전환시킬 수 있음

• 이 글은 2018년 글이고, 예전 논의가 몇 번 있었음
  https://news.ycombinator.com/item?id=18012334 (Sep 2018)
  https://news.ycombinator.com/item?id=21929709 (Jan 2020)
  https://news.ycombinator.com/item?id=31798580 (Jun 2022)

• 깊이 공감함. 개발자로서 우리에게 선택권이 있다는 걸 기억하는 게 중요함. 모든 것에 대해 선택할 수는 없지만, 덜 나쁜 대안을 고를 수는 있음
  Node를 꼭 쓸 필요는 없음. .NET이나 JVM 생태계에서도 훌륭하고 하위 호환되는 소프트웨어를 작성할 수 있고, 10년 뒤에도 수정 없이 돌아갈 거라고 기대할 수 있음
  단일 페이지 웹페이지를 꼭 만들 필요도 없음. 클릭할 때마다 페이지를 완전히 다시 로드하는 구식 HTML도 잘 동작하고, 이 시점에서는 오히려 지연시간이 더 낮을 수 있음
  데스크톱 앱을 Chromium으로 꼭 만들 필요도 없음. UI 프레임워크를 시작하는 데 일이 조금 더 들지만 품질은 그만한 가치가 있음. 결정권이 항상 있는 건 아니지만, 있을 때는 나쁜 선택에서 빠져나와야 함

  • 요즘 “모든 것이 SPA여야 한다”는 사고방식이 슬픔. GMail처럼 복잡한 앱이 SPA에서 이익을 얻는 건 이해하지만, 너무 많은 곳에서 기본 CSS/HTML과 약간의 jQuery만으로 훨씬 적은 시간과 훨씬 적은 버그로 같은 기능을 만들 수 있는데도 프런트엔드 복잡성을 고집함
  • .NET 생태계에서 하위 호환 소프트웨어를 잘 쓸 수 있다는 말에는 기침이 나옴. .NET Core 이니셔티브는 정말 많은 코드를 깨뜨렸고, Microsoft는 많은 라이브러리를 폐기했음. 물론 그중 일부는 아주 타당한 이유가 있었고, 많은 레거시 .NET 라이브러리는 설계 선택이 꽤 나빴음