소프트웨어 최적화가 우선이라면, 더 많은 세상이 구형 하드웨어로 운영될 수 있음

• 소프트웨어 최적화를 진짜 우선순위로 두면, 예상보다 많은 시스템이 구형 하드웨어에서도 동작할 수 있음
• 희소한 컴퓨팅 자원에 시장 가격 신호가 작동하면, 더 효율적인 소프트웨어를 만들 압력이 커짐
• 해석형 언어와 마이크로서비스 기반 제품을 모놀리식 네이티브 코드베이스로 다시 만드는 방식이 한 예시가 됨
• 하지만 초저가·고확장 컴퓨팅이 없다면, 혁신적인 신제품을 실험하고 내놓는 일이 훨씬 드물어질 수 있음
• 성능 최적화만으로는 충분하지 않으며, 저렴하고 확장 가능한 컴퓨팅이 제품 실험과 출시 빈도를 좌우함

---

최적화 우선의 사고실험

• 소프트웨어 최적화가 진짜 우선순위라면, 예상보다 많은 시스템이 오래된 하드웨어 위에서도 운영될 수 있음
• 희소한 컴퓨팅 자원에 가격 신호가 강하게 작동하면, 시장은 더 효율적인 소프트웨어를 요구하게 됨

가능한 구현 방식과 제약

• 한 가지 예시는 해석형 언어와 마이크로서비스 기반 제품을 모놀리식 네이티브 코드베이스로 다시 만드는 것임
• 다만 초저가·고확장 컴퓨팅이 없다면 혁신적인 신제품은 훨씬 드물어질 수 있음

[GN⁺]

Hacker News 의견들

• 시장은 버그 많고 비효율적인 소프트웨어도 완성도 높은 소프트웨어만큼 잘 사는 편이고, 둘 중 하나는 만들 수 있는 가장 싼 소프트웨어라는 논리가 가능함
  이는 “레몬 시장” 이야기와 비슷함. 시장은 모든 상품이 고품질인 것처럼 팔지만, 한계비용을 줄이려고 은근히 품질을 낮춤. 구매자는 구매 전 고품질과 저품질을 구분할 수 없어서 수요가 인위적으로 비슷해지고, 원인은 정보 비대칭임
  AI에서는 이미 그렇고 앞으로 더 심해질 것임. 사용자는 정교한 기계학습 앱과 세탁기 탈수 코스를 AI라고 부르는 것을 구분하지 못함. AI 라벨 자체가 가격 프리미엄을 만들고, 사용자는 세탁기에 크게 과다 지불하게 됨
  엉망인 소프트웨어를 기술자와 전문가가 설계하고 작성했다고 믿고 과다 지불하는 것도 본질적으로 같음. 소프트웨어의 99%는 IC1~3이 작성하고, 대부분의 기술 회사에서 QA 한 명이 “인수 기준 충족” 이상 품질을 높이는 유일한 장치임. 가끔 인턴 무리가 “LGTM” 주문을 외우지만, 그마저도 드뭄
  https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...

  • 품질 차별화로 소프트웨어 스타트업을 만들려다 아주 뻔한 깨달음을 뒤늦게 얻었음
    더 나은 제품이면 사람들을 설득하고 바이럴하게 성장할 거라 확신했지만 그렇지 않았음. 성장하긴 했지만 너무 느려서 손익분기점에 도달하기 전에 몇 년 만에 자금이 바닥남
    깨달은 건 경쟁 시장에서는 낮은 비용, 따라서 낮은 품질이 경쟁우위라는 점임. 제품 규모가 커질수록 비용 절감 압력도 커지고, 사람들은 싼 것을 원하므로 누군가 “비용”, 즉 품질을 깎아 더 싸게 만듦. 회사는 살아남고 이익을 내는 데 필요한 최소한만 지불함
    젊은 회사가 고품질을 만들려 하거나 잠깐 지출을 늘리는 일은 있지만, 결국 안정적인 평범함으로 미끄러지는 흐름이 생김. 이건 레몬 시장과는 조금 다르고, 시장 붕괴보다는 곳곳의 평범함으로 귀결되는 듯함
  • 여기서 “고품질”이라는 표현이 많은 일을 하고 있음. 낮은 성능이 곧 낮은 품질이라는 함의가 보이지만, 이 스레드에서 성능이 낮다고 언급되는 Teams, Slack, Jira 등은 모두 훨씬 빠른 경쟁 제품이 있음
    하지만 평균적인 사람에게 Slack과 빠른 IRC 클라이언트인 Weechat 중 고르라고 하면, 터미널식 UI, 영상 통화 없음, 웹훅 연동 없음, 커스텀 아바타나 이모지 없음 쪽을 저품질로 볼 가능성이 큼
    성능도 기능 중 하나임. Internet Explorer가 Chrome에 밀린 큰 이유도 출시 당시 Chrome이 훨씬 빨랐기 때문이고, Python 개발자들이 uv/ruff로 빠르게 옮겨가는 것도 성능 개선 때문임. 다만 Slack 실행이 10ms가 아니라 5초 걸리는 수준으로 가면 신경 쓰는 사람은 매우 적어짐
  • 꼭 레몬 시장은 아니라고 봄. 레몬 시장에는 정보 비대칭이 필요함
    버그 많은 소프트웨어에서 그런 일이 일어나기도 하지만, 대체로 사람들은 더 적게 내고 싶어 하고 그 과정에서 버그 몇 개는 감수함. 모든 코드 줄을 여러 엔지니어가 검토하고 엄격한 QA에 많은 시간을 쓰는 절차를 밟으려면 얼마를 받아야 할지 생각해보면 됨
    Padova에 살 때 작은 서점용 소프트웨어를 만든 적이 있는데, 친구라서 빠르게 만들고 많이 받지 않았음. 완벽하진 않았지만 문제가 생기면 고쳤고, 문제도 많지 않았으며 친구는 그 거래에 만족했음. 싸게 받는다는 걸 알았기 때문에 인내심도 있었음
  • 대기업에서 끔찍한 HR, 비용 정산, 근태, 보험 포털을 강제로 쓰게 한 적이 있었고, 돈 내는 사람들이 제품을 실제로 본 적이 있는지 의심될 정도였음
    우리 팀이 고객에게 “프로젝트는 끝났지만 이 백오피스 플랫폼만큼 버그와 UI 악몽이 많다”고 말한다면 질책받고 강등되거나 해고될 거라고 여러 번 말했음
  • 시장이 실제로 사는 것은 버그 없는 소프트웨어가 아니라 지원임
    여기에는 인간 지원이 부족한 Google 같은 회사도 포함됨. 지원은 여러 형태로 나타남: 문서, 영상, 블로그 같은 정보가 있고, “엄마, Google은 이렇게 쓰는 거야”처럼 도와주는 사람이 있으며, 운영체제·브라우저·형식 같은 사용 대상에 대한 지원이 있고, Excel처럼 내 작업 방식 자체를 받쳐주는 것도 있음
    마지막으로 실제 사람이 있음. 이게 지구상 최악의 ERP도 살아남게 하는 1순위 요소임. 마케팅과 영업도 지원이 있다는 신호가 됨. 기업 고객에게 엔지니어만 보이면 나쁜 신호일 수 있음. 개발자는 다른 일을 못하는 경우가 많고, 그 다른 일이 중요한 지원이기 때문임
    좋은 제품이어도 지원이 없으면 죽음. 더 나쁜 제품과 싸우려면 내 팀의 비용을 줄이기 위해 버그, 성능 문제, 플랫폼 같은 지원 필요를 줄이는 게 현명하지만, 다른 차원의 지원은 반드시 더해야 함. 작은 팀에게 가장 쉬운 건 가장 희소한 지원 자원인 사람을 붙이는 것이고, 그다음은 창의력이 필요함
    또한 장점을 잘 전달해야 함. 어떤 사람은 “코드를 가질 수 있음 vs 독점 제품”처럼 특정 종류의 지원을 더 중시함. 많은 사람은 코드보다 지원이 있는 독점 제품을 더 선호함

• 1980년 이후 컴퓨팅 성능은 대략 1000배 증가했다고 보는 편임
  동적 배열 범위 검사가 5% 비용이 든다고 해도 실제로는 그보다 훨씬 적고, 모든 곳에 켜면 컴퓨터는 고작 950배 빠른 수준이 됨
  1980년으로 돌아가 “950배 빠르고 큰 부류의 메모리 안전 취약점이 없으며 디버깅이 몇 자릿수는 쉬운 컴퓨터”와 “1000배 빠르지만 소프트웨어는 여전히 버그투성이거나 더 나쁘고 디버깅은 악몽인 컴퓨터” 중 고르라고 하면, 사람들은 950배만으로도 충격을 받았을 것임
  그런데 우리가 고른 건 후자였고, 개인적으로는 1000배파가 나머지 사람들을 망쳤다고 봄

  • 다만 그 1000배를 범위 검사에 쓴 게 아니라 수많은 추상화 계층과 비효율에 낭비했음
  • 버그 많고 느린 벤더 소프트웨어를 Sparc 20에서 돌리게 했고, 벤더는 Ultra를 달라고 강하게 항의했음
    결국 그들이 Sparc 20에서 효율적으로 돌아가도록 최적화하자 회사가 더 넓은 시장에서 성공할 기반이 생김. 최적화는 경쟁우위로 다뤄야 하며, 어떤 경우에는 가장 중요한 경쟁우위일 수도 있음
  • 배열 범위 검사 비용이 그렇게 단순하게 작동하진 않음. 이미지 처리 알고리즘이 픽셀당 2개 명령어를 쓰는 경우, 접근마다 검사를 추가하면 비용이 3~4배가 될 수 있음
    그래서 범위 검사를 강제하면 특정 작업에서 그 언어가 경쟁력을 잃게 됨
    대다수 경우에는 전혀 중요하지 않고 5%보다 훨씬 작음. 안전/비안전 또는 일반/성능 범위를 나누는 방식이 좋은 해법이라고 봄
  • 클럭 속도는 80년대보다 2000배 높고, SIMD까지 고려하면 명령어당 처리량도 80배 높을 수 있으며 여기에 코어 수를 곱해야 함
    주류 CPU는 80년대 기계보다 100만~200만 배 빠른 쪽에 가까움. 몇백 달러면 여전히 100만 배 빠른 범주의 리퍼 사무용 컴퓨터를 살 수 있음
    지금 컴퓨터가 느리고 느리게 느껴지는 현상은 단순히 컴퓨터가 느려서가 아니며, 그럼에도 벌어지고 있음. 스크립트 언어가 작은 연산마다 메모리를 계속 할당하고 동적 타입 때문에 변수마다 포인터를 따라가는 것도 일부 원인이고, 이미 나쁜 환경에서 극도로 비효율적인 프로그램을 쓰는 사람들도 있음
    요즘 대부분의 프로그램은 사용자가 바라던 방식이 아니라 작성자가 일하고 싶은 방식으로 작성됨. 많은 사람은 최적화 개념이나 무엇이 더 빠르게 실행되는지 감이 없고, 작동하게 만든 뒤 “이 프로그램은 이 속도구나”라고 생각함
    같은 소프트웨어가 더 빨라질 수 있다는 생각 자체가 틈새 사고방식이며, Hacker News에서도 모두가 그렇게 생각하진 않음
  • 범위 검사 자체의 비용은 낮지만, 안전한 언어를 일반적으로 쓰는 비용은 훨씬 클 수 있음
    가비지 컬렉션 언어는 메모리를 몇 배 더 쓰는 경우가 많음. 더 이상 쓰지 않는 메모리를 즉시 해제하지 않고, 애초에 할당도 더 많이 필요로 하는 편임

• Google과 Facebook에서 일해보니 하드웨어가 얼마나 싸고, 대부분의 경우 코드 최적화가 얼마나 가치가 낮은지 체감하게 됨
  Google은 10년도 더 전에 데이터센터 자원 사용량을 관리하기 시작했고, 프로젝트마다 CPU 코어, 하드디스크 공간, 플래시 저장소, 디스크 스핀들, 메모리 같은 예산이 있었음. 이 자원들은 대체로 서로 환산 가능해서 상대 비용을 볼 수 있었음
  당시 플래시 저장소는 하드디스크보다 약 20배 비쌌지만, 스핀들 병목 때문에 전체 비용으로는 더 싼 경우가 많았음
  이 모든 것은 “mili-SWE”, 즉 SWE 1명이 1년 일하는 노력의 1000분의 1로 환산될 수 있었음. 프로젝트는 하드웨어를 절약하고 사람을 더 뽑거나, 사람을 덜 뽑고 현재 예산 안에서 하드웨어를 더 받을 수 있었음
  CPU 코어 몇 개가 SWE 1명에 해당했는지는 정확히 기억나지 않지만 수천 개였던 듯함. 프로젝트 전체 최적화에 SWE 1년을 쓰고도 CPU 코어 5000개를 아끼지 못하면 순손실임
  매우 큰 프로젝트는 그보다 훨씬 많이 써서 최적화가 말이 됐지만, 특히 작성한 코드가 언젠가 교체될 가능성이 크다면 최적화가 맞지 않는 경우가 많았음
  한편 웹에는 일반적인 사용성 문제가 있음. 웹이 지금처럼 많은 자원을 써서는 안 됨. 데이터 입력 업무를 해본 사람을 알면 마우스가 꽤 비효율적이라는 걸 알 것임. 30~40년 전 텍스트 기반 터미널은 자원을 아주 조금 쓰면서도 매우 효율적인 인터페이스를 제공했음
  언젠가 웹은 일반적으로 기대되는 기술 스택이 정해지고 다른 문제로 넘어가는 식으로 “해결”될 줄 알았지만 그렇게 되지 않았음. 여전히 “이번 주의 프레임워크”가 있고, 마우스 휠과 제대로 맞지 않는 스크롤바를 사용자 코드에서 다시 구현하는 멍청한 일을 함. 이 문제를 어떻게 풀 수 있을지, 애초에 “해결”될 수 있을지도 모르겠음

  • 나도 거기서 일했지만, 여기서 말하는 성능은 프로젝트별 CPU 최적 사용 관점임
    Google은 다른 두 성능 측면인 지연 시간과 전체 장비 활용률에는 엄청난 노력을 쏟았음. 둘 다 위에서 내려온 지시였고 수천 명의 엔지니어 시간과 관심을 빨아들였으며 인건비도 컸음
    하지만 장비가 제약이면 개별 코어가 싸더라도 이유 없이 놀게 두고 싶지 않음. 새 데이터센터 구축을 기다리는 기회비용이 크기 때문임. 사용량이 지연 시간에 매우 민감하면 하드웨어 비용 절감이 아니라 사업 지표 때문에 밀리초를 깎는 게 말이 됨
  • Google처럼 엔지니어링 비용이 높고, 추가 하드웨어 같은 지출을 감당할 두꺼운 마진이 있으며, 엔지니어가 할 프로젝트가 많은 회사를 스스로 고른 사례임
    평가는 한계비용에서 이뤄져야 함. 1달러당 연간 몇 센트를 아끼는 수준이어도 엔지니어가 놀고 있는 것보다는 그 일을 하는 편이 나음
    문제는 거의 아무도 그렇게 하지 않는다는 점임. 의사결정 방식이 경제적 계산과 무관하고, 대부분은 그냥 “Google이 하는 것”을 따라 함. 그래서 많은 기능 장애가 설명됨
  • 이 논리는 Google 같은 조직에는 맞을 가능성이 큼. 규모 때문에 “코어 하나”가 평균보다 훨씬 싸고, 급여는 평균보다 훨씬 높기 때문임
    하지만 보통 기업, 심지어 큰 기업이라도 그 정도는 아님. “Facebook/Google/Netflix 등은 별도 계급이고 그들의 관행 대부분은 당신에게 통하지 않는다”는 전형적인 사례로 보임
  • 그 문제는 “해결”되지 않을 것임. 애초에 문제가 아니기 때문임
    인적 자원을 최적화에 몰아넣는 대체 우주를 상상할 수는 있지만, 그 우주는 지금과 전혀 다를 것임. 최적화에 엔지니어 한 명을 더 쓰면 기능 개발 엔지니어 한 명이 줄어듦. 무엇을 위해서인가? CPU 사이클 몇 개 아끼려고? 웃기지 말라는 느낌임
  • Google이 더 나은 압축과 바이너리 직렬화 형식을 만드는 건 재미로 하는 게 아니라 수익에 도움이 되기 때문임

• 제목만 보면 Carmack이 제대로 최적화되지 않은 소프트웨어를 비판하고 오래된 하드웨어에서 성능을 개선하자고 주장하는 줄 알았음
  실제 트윗은 둘 다 전혀 아니고, 하드웨어 발전이 멈춘 사고 실험을 다루면서 “초저가에 확장 가능한 컴퓨팅이 없으면 혁신적인 신제품은 당연히 훨씬 드물어질 것”이라고 결론냄

  • 어제 스레드와 관련된 내용 같고, 아마 그걸 못 본 듯함
    https://news.ycombinator.com/item?id=43967208
    https://threadreaderapp.com/thread/1922015999118680495.html
  • “초저가에 확장 가능한 컴퓨팅이 없으면 혁신적인 신제품은 훨씬 드물어질 것”이라는 결론은 흥미로움
    오히려 스마트폰 이후 18년 동안 큰 혁신을 별로 보지 못했고, 자본이 소비자에게는 본질적으로 이미 가진 것과 같은 제품을 팔기 위해 하드웨어 발전에 기대고 있기 때문이라고 봄
    물론 첫 트윗 이후는 읽을 수 없었음
  • 그 주장은 나쁘다고 봄. 한동안 기능 추가를 멈추고 숨 돌릴 공간을 만들면, 기능은 다시 거세게 돌아올 것임
    침체는 있겠지만 지속적인 침체는 아닐 것임
  • 바로 그게 핵심임. 사람들은 “비대화”가 단순한 낭비가 아니라, 경제적 동기로 생긴 개발자 생산성 증가라는 점을 무시함
    덜 복잡한 언어로 사람을 뽑아 생산적으로 만들 수 있으면 노동자 시장이 넓어지고 비용이 내려감
  • 여기에는 Carmack의 현재 AI 작업이 깔려 있을 수 있음
    원문에서 Carmack은 본질적으로 “좋고 똑똑한 개발자는 비싸고, 더 큰 일이 있으니 코드와 시스템을 끝까지 최적화하게 돈을 쓰지 않아서 소프트웨어가 느리다”고 주장하는 셈임
    따라서 좋은 개발자가 갑자기 아주 싸지면, 모두가 그들을 사서 최적화에 쓰면서 많은 소프트웨어가 갑자기 빨라질 수 있다는 함의가 있음. 그렇다면 왜 좋은 개발자가 갑자기 싸게 풀릴 수 있을까?

• 하드웨어 수명을 “계획적 진부화” 이후 5년, 10년 더 늘릴 수 있다면 좋겠음
  그러면 전자폐기물을 많이 줄이고 희토류를 땅속에 남겨두며, 온실가스 배출도 크게 낮출 수 있음
  하지만 소프트웨어 생산의 시장 힘은 그런 외부효과에 비용을 지불하지 않음. 성능을 위해 계획하고 설계하는 것보다 빨리 출시하고 테스트하고 반복하는 편이 훨씬 쌈. 게임 산업 일부 조직은 좋은 성능과 판매량을 동시에 얻는 공식을 찾았지만 고르게 퍼지진 않았음
  기업용·소비자용 소프트웨어에서는 요구사항에 성능 기준을 넣을 동기가 크지 않음. 사용자가 견딜 수준에 맞춰 설계하고, 변경과 기능을 계속 출시해야 하므로 최대한 여유를 둠. 모든 변경은 성능과 사용자 만족에 영향을 줄 수 있는 부채라서 오류율을 감당할 예산 여유를 확보함
  “준비될 때까지” 닫힌 문 뒤에서 설계하고 개발하던 방식과는 많이 다름

  • 첫 번째 포인트가 장기적으로 성장/부채 경제 모델이 좋지 않은 이유임
    우리는 돌봄과 유지보수 중심 경제를 가져야 하고, 소수의 인지된 부가 아니라 인류 전체의 선을 중심으로 거시적 노력을 맞춰야 함
    오래된 차량 유지, 오래된 컴퓨터 재사용 등에 집중했다면 성장 대비 매립지는 더 작았을 것임
    물론 보존주의자가 객관적으로 열등한 전략임을 보여주는 게임이론 구성도 있을 것 같음

• 거래소 전체의 주문 매칭 엔진을 단일 스레드에서 돌릴 수 있게 된 지 이미 10년이 넘었음
  엄격하게 직렬화된 트랜잭션 처리라는 특정 부류의 계산 능력은 다른 지표가 암시하는 만큼 빠르게 성장하지 않았다고 봄. 코어 31개를 추가한다고 주문 매칭 엔진이 더 빨라지지는 않으며, 오히려 느려질 수 있음
  제품이 초당 수백만 건 미만의 트랜잭션을 처리하면서도 머신 클러스터를 찾고 있다면, 15단계쯤 뒤로 물러나 처음부터 다시 시작해야 함

  • 이 부분이 정말 열받게 함. 시스템 “아키텍트”들이 자기 가치를 증명하고 흔적을 남기려고 너무 애쓴 나머지 많은 시스템을 과도하게 복잡하게 만들었고, 그 결과 새로운 문제를 잔뜩 풀어놨음
    원래 설계만으로도 사용 사례의 99%는 여전히 만족했을 것이고, 요즘 로컬 컴퓨팅 능력을 고려하면 시장 전체를 단일 장비에서 돌릴 수도 있음
  • 병렬 정렬처럼 로그 축소를 써서 주문을 병렬로 매칭할 수는 없는지 궁금함
    시간과 가격으로 정렬하는 것 외에 다른 계산이 충분하지 않아서 그런가?
  • 각 트랜잭션에서 단순한 처리를 하기 때문에 가능한 것임
    트랜잭션마다 더 복잡한 처리를 해야 했다면 그렇게 많은 건수를 처리할 수 없었을 것임. 다만 어떤 더 복잡한 처리가 필요한지는 해당 도메인 사람이 아니라 상상하기 어려움

• 맞는 말임. 이건 경제 문제, 즉 자원 배분 문제임
  누군가에게 소프트웨어 최적화에 시간을 더 쓰게 할 것인지, 아니면 더 많은 기능을 만들게 할 것인지의 선택임. 후자가 더 많은 현금을 만들면 그 일을 시킬 것이고, 전자가 현금흐름에 중요해지면 그 일을 시킬 것임

  • 경제 문제라는 점은 맞지만, 어떤 경제 문제인지가 다르다고 봄
    이건 소프트웨어 회사가 대중에게 부과하는 부정적 외부효과의 명확한 사례임. 대부분의 소프트웨어 회사는 에너지, 잃어버린 시간, 추가 전자폐기물의 실제 비용을 내지 않기 때문에 최적화에 신경 쓰지 않음
  • 이 경제는 금융 부채를 쌓이는 쓰레기와 기술 부채로 옮기고, 그 비용을 다른 사람이 내게 만드는 방식임. 사실상 도둑질에 가까움
    철저한 최적화가 별 의미 없는 경우도 많지만, 다시 작성하는 대신 서버만 더 추가한다는 발상은 슬픈 상태임
  • 일반적으로는 단지 변화를 위한 새 기능을 추가하기보다 개발자가 소프트웨어를 최적화하는 편이 더 좋음
    macOS, Windows, Android의 새 기능 대부분은 쓰지 않음. 원하는 건 앱을 돌릴 효율적인 환경과 보안 개선임. macOS의 설정 앱 같은 여러 개선도 그다지 만족스럽지 않음
    디자인 소프트웨어도 마찬가지임. Adobe가 넣은 새 기능 대부분을 쓰지 않고, 10년 전 Illustrator나 Photoshop으로도 충분히 행복할 수 있음. 원하는 건 덜 비대한 소프트웨어임
    오디오와 음악 제작에서는 작업 흐름이 아직 개선 중이라 새 기능을 원하지만, 효율을 희생하면서까지는 아님
    코드 편집기는 VSCode의 기능이면 충분함. 더 필요한 건 없고, 더 나은 LSP는 원하지만 편집기 핵심은 아님. 다만 VSCode가 더 빠르고 메모리를 덜 먹었으면 함
  • 효율은 일상에서도 중요함. 예를 들어 간식을 가지러 주방에 갈 때 쓰레기나 그릇을 같이 들고 가서 한 번의 이동 이득을 두 배로 만듦
    소프트웨어 최적화도 비슷하게 매력적임. 하지만 문제가 “비싼 엔지니어링 시간을 몇 시간 들여 최적화”와 “싼 RAM을 더 넣기”라면 더 싼 선택이 이김. 때로는 문제가 충분히 커서 최적화할 가치가 있음
    시장이 어떤 선택을 추구할 만한지 결정할 것임. 하드웨어를 더 던지는 방식의 수확체감에 도달하면 소프트웨어를 최적화하게 됨. 무어의 법칙은 느려지고 있지만, 아직 그 지점에는 도달하지 않은 듯함
  • 결국 수요 문제임. 소비자가 더 성능 좋은 소프트웨어를 요구한다면 프리미엄을 지불할 것임
    하지만 현실은 반대에 더 가까움. 더 싼 가격표가 붙는다면 성능이 더 낮은 버전도 선호할 것임

• Carmack에 대한 반박이라기보다 가끔 생각하는 구체적 사례가 있음
  Electron 앱은 소비자에게 성능 문제로 참거나 혐오되는 대상 사이 어딘가에 있지만, 직장에서 Linux 노트북을 실용적으로 쓸 수 있게 만든 단일 혁신일 가능성이 큼. 예를 들어 설치 없이 MS Teams 회의에 들어갈 수 있는 건 진짜 유용함
  그래서 모두가 요즘은 Winamp처럼 촘촘하게 코딩된 것이 없다고 한탄하지만, 앞의 세 글자를 잊고 있음

  • Wine이 있으니 성능 좋은 Windows 전용 소프트웨어가 오늘날의 Electron 잡탕보다 훨씬 낫다고 봄
    Linux에서도 실행될 가능성이 꽤 있지만, Electron 소프트웨어는 어떤 플랫폼에서도 형편없음

• 2010년에 청소부로 일하면서 IT 책임자 일을 부업처럼 했음
  당시 회사에 지난 5년간의 노트북, 대략 Nehalem 이후 제품이면 스프레드시트 작업에는 충분한 성능이 있다고 말했음. 그들이 하는 일은 사실상 그게 전부였고, 코어 2개, RAM 16GB, 500GB SATA SSD면 충분했음. 마케팅 몇 명만 조금 더 강한 장비가 필요했지만 큰 차이는 아니었고, 최신 최고급 노트북을 사지 않아 많은 돈을 아꼈음
  지금은 거기서 일하지 않지만, 오늘도 그 컴퓨터들은 스프레드시트용으로 충분히 훌륭해야 한다고 확신함. 업무 흐름은 크게 바뀌지 않았고 바뀐 건 소프트웨어임. 계속 업데이트했다면 지금 MS Windows 10이나 11을 “돌릴” 수 있는지도 모르겠지만, 비대화와 특히 온라인 전용 스프레드시트로 생산성이 크게 떨어졌을 가능성이 큼
  그곳의 인터넷도 형편없었음. 선택지는 “비즈니스”라는 이유로 월 300달러인 약 16Mbit 비대칭 DSL, 또는 월 500달러인 Comcast 120Mbit 케이블뿐이었음. 120Mbit도 온라인 전용 스프레드시트에는 겨우 버틸 정도고, 16Mbit는 확실히 부족함. 더 나쁜 건 인터넷이 끊기면 사업이 멈춘다는 점임
  다른 댓글이 말한 도둑질의 실체가 바로 이것이고 전적으로 동의함. 사무실에서 스프레드시트를 편집하고 업데이트하는 노트북이 인터넷이나 터무니없는 계산·저장 자원, 큰 대역폭을 요구할 이유는 전혀 없음
  오늘날 컴퓨터의 끔찍한 성능에는 고객, 즉 개인과 기업 모두에게 비용을 떠넘기는 것 말고는 변명거리가 없음
  https://news.ycombinator.com/item?id=43971960

• 세상은 우아하고 빠르고 버그 없는 소프트웨어가 아니라 기능 위에서 돌아감
  최종 사용자에게 기능이 없는 것과 버그는 차이가 없음. 성능이 나빠 어떤 작업을 완료하는 데 5분 걸리는 것과, 기능이 없어서 사용자가 같은 일을 수동으로 5분 해야 하는 것도 의미 있는 차이가 없음. 둘 다 “느림”임
  최종 사용자 가치를 계속 극대화하면 필연적으로 느리고 버그 많은 소프트웨어를 만들게 됨. 게다가 사용자에게 더 빠르고 버그가 적은 대신 기능이 줄어드는 걸 원하느냐고 물으면 놀랍게도 아니라고 함. 더 중요한 건 기업 세계에서 소프트웨어 구매자는 최종 사용자가 아닌 경우가 많고, 그들은 기능을 더 원하고 성능과 우아함은 더 덜 원함
  기능 집합이 같다면 사용자와 구매자는 가장 빠르고 버그가 적고 우아한 소프트웨어를 고를 것임. 하지만 기능이 하나라도 빠지면 짐. 소프트웨어를 빠르고 우아하게 유지해야 하는 이유는 그렇게 해야 기능을 계속 추가하면서 기능이 적은 제품이 되지 않을 가능성이 가장 높기 때문임
  빠르고 우아한 해법은 좋은 리뷰를 받고 사용감이 좋다는 칭찬을 들을 수 있음. 그래서 그게 중요한 요소처럼 보일 수 있음. 하지만 결국 원하는 일을 못 하면 아예 사지 않음. 필요한 핵심 기능이 있다면 느리고 짜증 나고 버그 많은 난장판을 선택함

  • 비기술자 친구와 가족 대부분이 어느 시점엔가 반드시 써야 하는 비대하고 과도하게 복잡한 소프트웨어에 불평한 적이 있음
    Microsoft가 이제는 사용자를 발로 차고 비명을 지르게 하면서 다음 Windows 버전으로 끌고 가야 한다는 점도 기억해야 함. 사용자가 스스로 결정하게 두었다면 많은 사람은 Windows XP 이후로 업그레이드하지 않았을 것임. 이후 버전에 예쁜 새 기능이 많았는데도 그랬음
    기업과 투자자가 기능 자체를 원한다는 데는 동의하지만, 사용자는 확실히 아님
  • 완전히 반대임. 회사가 원하지 않는 기능을 사용자에게 밀어붙이는 건 구버전을 중단하고 강제 업그레이드로 판매하기 위해서임
    가능하다면 아무도 더 이상 아무것도 업그레이드하지 않을 것임. Microsoft가 사람들을 업그레이드시키려고 얼마나 애쓰는지 보면 됨. Windows, Office, Slack, Zoom 등의 새 버전을 원했다는 사람은 들어본 적이 없음
    Photoshop 같은 모든 것이 클라우드로 강제되는 이유도 이것임. 대다수 사람은 제공되는 새 기능을 원하지 않고, 기업 구매자도 포함됨. 매출을 유지하는 답은 기능 제공 여부와 관계없이 사람들이 사게 만드는 것임
  • 기능과 우아함의 절충에는 동의함
    다만 기존 사용자는 이미 소프트웨어로 필요한 일을 하고 있으므로, 새 기능은 다른 소프트웨어를 없애게 해주거나 새로운 일을 가능하게 할 수 있음. 하지만 정말 엄청나게 중요한 새 일이라면 이미 다른 소프트웨어를 찾아 썼을 것이고, 지금까지 없이도 버텼다는 뜻임. 그래서 기존 사용자가 정말 성찰적이라면 먼저 성능 개선을 요구하고, 작은 개선 몇 개 정도를 원할 것이라고 봄
    반대로 잠재 사용자는 아직 소프트웨어를 모르거나, 유용하다고 느끼기 전에 뭔가 다른 기능이 필요함. 새 기능을 합리적으로 찾는 쪽은 이들임
    따라서 “기능 vs 성능” 결정은 개발자의 우선순위가 신규 사용자 추가인지 기존 사용자 만족인지 보여주는 신호이기도 함. 기술자가 후자를 선호하는 건 당연함. 이미 이 게임을 해봤고, 획득되는 동안이 아니라 실제로 오래 쓰는 시간에 우선순위가 되고 싶다는 걸 알기 때문임
    버그 많고 느리지만 기능 풍부한 소프트웨어가 시장을 지배하는 것도, 기업이 성장을 먼저 우선하기 때문임. 역사는 사용자가 그리워하는 아름답고 우아한 소프트웨어로 가득하지만, 회사가 지속될 만큼 널리 퍼지지 못했음
    절충은 양방향으로 실재함. 대부분의 사람은 잠재 사용자보다 사용자로 보내는 시간이 더 많음. 이것이 요즘 소프트웨어와 컴퓨터가 믿을 수 없게 형편없다는 일반적 인식의 큰 원인일 가능성이 큼
  • 정확한 표현임. 소프트웨어 성능 개선에 더 많은 시간을 써야 한다고 주장하는 사람들은 누가 그 비용을 낼지 생각하지 않는 듯함
    가정용·사무용 컴퓨터에서 RAM과 더 나은 CPU에 쓰는 돈은 그 위에서 도는 모든 소프트웨어를 더 싸고 더 많은 기능을 갖춘 상태로 출시할 수 있게 해줌