▲

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

 (twitter.com/ID_AA_Carmack)
1P by GN⁺ 21시간전 | ★ favorite | 댓글 1개
  • 많은 사람들이 상상하는 것보다 더 많은 시스템이 구형 하드웨어에서 충분히 동작 가능함
  • 진정한 소프트웨어 최적화가 이루어진다면 이러한 효율성 달성 가능성 높음
  • 희소한 컴퓨팅 자원의 시장 가격 신호가 소프트웨어 효율에 대한 동기를 부여함
  • 기존의 인터프리터 기반 마이크로서비스 제품들을 네이티브 코드로 구축된 모놀리식 아키텍처로 전환 필요성 있음
  • 반면, 매우 저렴하고 확장 가능한 연산 자원이 없다면 혁신적인 신제품 개발이 훨씬 드물게 이루어질 가능성 존재함
▲
GN⁺ 21시간전  [-]
Hacker News 의견

  • 시장에서는 버그가 많고 비효율적인 소프트웨어도 완벽한 소프트웨어만큼이나 잘 팔림을 주장할 수 있음, 둘 중 하나는 만드는 데 가장 저렴한 소프트웨어임, 이는 ‘레몬 마켓’ 이야기와 유사함, 즉, 시장은 모든 상품이 고품질인 것처럼 거래하지만 실제로는 품질을 희생해 비용을 줄임, 구매자는 사기 전에 고품질과 저품질을 구별할 수 없기 때문에 둘의 수요가 인위적으로 비슷해짐, 이는 정보 비대칭 때문임, 이러한 현상은 이미 사실이며, AI에서도 점점 더 현실이 됨, 사용자는 정교한 머신러닝 응용프로그램과 ‘AI’라는 이름만 붙은 세탁기 사이를 구분하지 못함, AI라는 라벨은 그 자체로 가격 프리미엄을 줌, 그래서 사용자는 세탁기를 과하게 지불함, 바이어가 ‘전문가가 설계·작성한 소프트웨어’라고 생각하며 형편없는 소프트웨어에 과금하는 것도 근본적으로 동일함, 거의 모든 소프트웨어는 IC1-3 레벨에서 작성되고, QA 담당자는 대다수 기업에서 혼자 품질 향상의 유일한 지표가 됨, 때때로 인턴들이 ‘LGTM’ 주문을 외우며 개선을 기대하지만, 실제론 그마저도 드뭄

    • 품질로 차별화된 소프트웨어 스타트업을 만들려 했는데, 더 나은 제품이면 사람들이 알아보고 성공할 것이라 확신했지만 실제로 그렇지 않았음, 성장했지만 너무 느려서 흑자도 전에 자금이 소진됨, 깨달은 점은 낮은 비용, 그리고 이에 따른 낮은 품질이 경쟁 시장에서 경쟁 우위가 된다는 것임, 대학 때부터 들었지만 이 경험을 통해 뼛속까지 체감함, 이것이 시장에서 모든 것이 평범해지는 이유이고, 인기가 많아질수록 고품질도 악화되는 까닭임, 제품이 규모가 커질수록 비용 줄이기에 대한 압력이 커짐, 사람들은 싸게 사길 원해서 누군가는 비용(품질)을 절감해 더 싸게 제공함, 기업들은 생존과 이익을 위해 최소한만 지급함, 물론 가끔은 예외가 있지만 결국 점진적인 비용 절감으로 흘러감, 아마 이 현상에도 이름이 있을 텐데, 레몬 마켓과 약간 다름, 시장이 붕괴되진 않지만 모든 곳에 안정적 평범함이 존재하게 되는 구조임

    • ‘시장’이 모든 상품을 고품질로 팔고 있다는 관점에 반론이 있음, 여기서 ‘고품질’의 의미가 중요함, 성능이 나쁘면 낮은 품질이라는 의미로 들리지만, 실제로 Teams, Slack, Jira 등 성능이 안 좋다고 평가된 앱들은 경쟁사에 비해 월등히 나은 성능을 가진 경쟁 제품이 있음, 하지만 사용자가 Slack 대신 터미널 UI, 화상채팅 없음, 이모지 없는 Weechat을 선택하라고 한다면 대부분은 후자를 더 저품질로 볼 것임, 성능도 하나의 기능일 뿐임, 이를테면 크롬의 초기 성공은 속도가 빨랐기 때문이고, Python 개발자들도 성능 향상 때문에 uv/ruff로 이동함, 하지만 Slack이 5초 만에 켜지는 대신 10ms 걸린다고 해도 대부분의 사용자는 신경 쓰지 않음

    • 비효율적인 소프트웨어가 시장의 레몬 마켓 구조에 의한 것이라는 데 동의하지 않음, 정보 비대칭이 있을 때만 해당함, 대부분의 경우 사람들은 약간의 버그쯤은 신경 안 쓰고 더 저렴한 가격을 원함, 매우 철저한 QA와 다중 엔지니어 코드 체크 절차를 거치면 요금을 비교해보면 명확함, 작게는 작은 서점의 소프트웨어를 만들어준 경험이 있는데 빠르게 만들었고 많이 받지도 않았음, 완벽하지 않더라도 문제를 나오면 바로 고쳤고, 고객도 좋은 거래임을 알아서 만족함

    • 대기업에서 끔찍한 HR, 경비처리, 시간추적, 보험 포털을 사용해본 경험이 있음, 너무 형편없어서 결제를 한 사람이 정말 이 제품을 써봤는지 의심스러웠음, 팀이 버그와 UI 악몽으로 가득한 제품을 고객에게 내민다고 하면 곧바로 꾸짖음이나 좌천, 심지어 해고감임

    • 시장이 ‘버그 투성이, 비효율적인 소프트웨어’를 잘 산다는 본질은 시장은 <i>지원</i>을 사는 것임, 이는 구글이나 인간 지원이 부족한 회사에도 해당함, ‘지원’이란 여러 형태로 나타남 — 문서, 동영상, 블로그 정보, 도움을 주는 사람, 내가 쓰는 환경(운영체제, 브라우저 등) 지원, 내가 원하는 작업 지원 등등, 최악의 ERP도 살아남게 만드는 1순위는 결국 실제 사람이 있음, 지원의 유무가 제품의 사망선을 결정함, 작은 팀이 싸움에서 이기려면 ‘지원 필요’를 줄이고 다른 차원에 지원을 넣는 게 현명함, 가장 쉬운 방법은 인간을 추가하는 것임, 그리고 강점을 제대로 소통해야 함, 지원의 종류마다 평가가 다르니 오픈소스 코드 vs 독점코드와 같이, 많은 사람은 코드보다는 지원이 더 있으면 독점 쪽을 선호함

    • 내가 Costco에서 쇼핑을 좋아하는 큰 이유 중 하나는 그들이 대체로 쓰레기 같은 물건을 팔지 않기 때문임, 필터가 항상 내 기준과 일치하진 않지만 나름 의미 있는 품질 필터임

    • 사용자가 소프트웨어 품질과 성능 기반으로 결정을 내릴 수 있다고 해도, 내 오픈 앱 리스트를 보면 어떤 앱도 단순히 성능이 더 좋다고 해서 대체할 수 없음, 예를 들어 Docker, iterm2, WhatsApp 등은 각기 구체적인 이유로 쓰는 것임, 단순히 가장 빠른 솔루션이 있더라도 바꿀 수 없는 구조임, 처음부터 내 요구를 충족시켜 주는 소프트웨어의 존재 자체가 성능 기준을 넘는 더 중요한 요소임

    • 99%의 소프트웨어는 성능을 고려하지 않고 작성되고 있음, HN에서도 성능 개선 자체가 터부시되는 경향이 많음, L4/5 레벨 이상의 엔지니어조차도 성능 감각이 부족한 경우가 많음, 비즈니스 관점에서도 하드웨어가 해당 소프트웨어를 돌리지 못할 때까지는 효율성을 신경 쓰지 않음, 그마저도 추가 하드웨어로 해결하는 게 우선임

    • 지금의 시장 구조는 언제든 하드웨어를 구매해 돌릴 수 있으니 버그 많고 비효율적인 소프트웨어가 지배함, 소프트웨어는 하드웨어의 처리 스펙을 채우며 팽창함 — “앤디가 주면 빌이 가져간다” 법칙임, 그래서 lean한 고품질 소프트웨어를 만들 유인이 없음, 하지만 최첨단 칩을 더 이상 구할 수 없는 세상이 온다면(예: 지정학적 위기, 대규모 공장 파괴 등등), 자원을 아껴쓰는 소프트웨어가 경제적으로 큰 가치가 생김 — 부풀려진 소프트웨어는 더는 실행할 수 없게 됨, 카맥은 이런 상황에서 최적화의 여유폭이 충분하니 결국 어떻게든 구시대 칩에서도 소프트웨어를 돌릴 수 있다고 말함

    • 잘 설계된 소프트웨어는 교체가 쉬운 것임, 반면 버그 투성이 스파게티 코드 집합은 아무도 손대고 싶지 않아 영원히 남음, 순수한 진화론만 놓고 보면, 나쁜 소프트웨어가 결국 지배하는 현상임

    • 중고차 시장이 레몬 마켓인 이유는 잘 관리된 차와 고장 직전 차를 구분하기 어렵기 때문임, 하지만 신차 시장은 엄격하게 관리되니 해당사항 없음, 소프트웨어는 언제나 신품임, 자동차 품질이 수십년간 증가한 것처럼 소프트웨어도 품질을 높일 수 있음, 일정 기준을 충족해야만 팔게 하고, 심각한 버그가 있으면 리콜, 고의로 불량 상품을 팔면 처벌, 다른 모든 산업이 이렇게 운영됨

    • 웹 2.0 ‘영구 베타’ 및 SaaS 모델 도입 덕분에 사용자 인내심 역시 변화함, Microsoft가 수 세대에 걸쳐 ‘소프트웨어는 당연히 망가진다’는 인식을 심어줌, 모두가 나쁜 소프트웨어에 길들여지다 보니 좋은 소프트웨어의 가치를 잘 모르게 됨

    • 나는 실제로 그 AI 마크가 붙은 세탁기를 사봤음, 마케팅에 웃음이 나왔지만 가격이 합리적이어서 샀음

    • 아마 보안 결함만 이야기하는 것일 듯함, 성능이나 다른 버그로 가득한 Excel이나 Photoshop은 금방 사용을 포기할 것임, 하지만 보안은 사용자가 문제 발생 때까지 인지 못하고, 해킹당해도 원인을 모름, 개발자에게 인센티브가 없음, 성능은 어느 정도만 쓰면 더 이상 최적화에 자원 투입이 꺼려짐, 수확 체감의 법칙임

    • 유저는 AI의 정교함과 허울뿐인 ‘AI 세탁기’를 구별 못해도, 좋은 AI는 사용자 스스로 정보 비대칭을 극복하게 해줄 수도 있음, 결국 좋은 AI를 선택하는 방법만 있다면 해결 가능임

    • 나는 ‘가장 저렴한 소프트웨어’를 만드는 게 무조건 싸다고 생각하지 않음, 스타트업 수준에선 대충 만든 게 싸게 먹히지만 규모가 크면 오히려 비용이 더 많이 듦, 항공사도 올리브 한 개 빼내며 비용 줄이려 하는데, 개발자에게 최적화 시키는 게 왜 효율적이지 않은지 의문임, 우리는 새로운 기능만 추가하지만 결국 사용자는 업뎃마다 느려짐을 체감함, 반대로 빨라지면 또 환호함, 엔지니어가 MBA처럼 행동하며 ‘가치가 없다’는 답만 반복함, 하지만 소프트웨어 버그 수정의 ‘가치’는 다분히 주관적임, 엔지니어의 임무는 버그를 고치는 것임, 브랜드도 중요한데 지금의 대형 브랜드들은 브랜드 가치를 무시함, 아마 소비자가 잘 바꾸지 않으니 그런 것 같지만, 바꿔봐야 새 UI만 늘어나고 익혀야 하는 문제만 늘어남(Apple마저 직관적이지 않음)

    • 지금 세상은 예전 구세대 하드웨어로도 돌릴 수 있겠지만, 어차피 CPU와 하드웨어는 계속 빨라지고 있으니 굳이 코드를 더 효율적으로 만들 이유가 없음

    • 정보 비대칭 문제는 FOSS 혹은 독점 ‘공유 소스’ 제품들에서 극복 가능함, 코드를 직접 보면 전반적으로 좋은 품질인지 확인할 수 있음, 실제 버그까지 찾지 못해도 함수길이, 주석, 네이밍 등에서 양심적 개발 문화를 파악 가능함, 진짜 보면 db 스키마가 엉망인 고가의 독점 제품엔 신뢰가 생기지 않음

    • 나쁜 소프트웨어는 장기적으로 보면 제작(유지) 비용이 더 비쌈

    • 그래서 브랜드가 품질의 수호자 역할임을 얘기함

    • 음식에서 독성, 만료, 중독성 첨가물 판매를 법으로 금지하는 것처럼 소프트웨어도 규제가 있어야 함, 하지만 GDPR 제정 전까진 규제가 거의 무의미하고, 지금도 위반은 일상임

  • 1980년 이후 컴퓨팅 파워가 약 1000배 증가했음, 만약 동적 배열 경계 체크로 인한 성능 저하가 5%로 잡으면(사실 이보다는 훨씬 적음), 체크를 켜도 우리는 950배 빨라진 컴퓨터를 쓸 수 있었음, 1980년으로 돌아가 ‘버그가 줄고, 디버깅이 쉬운 950배 빠른 컴퓨터’와 ‘그냥 1000배 빠르면서 여전히 버그 많고 디버깅 더 힘든 컴퓨터’ 중 고르라면, 대부분은 950배를 고를 것임, 하지만 우리는 결국 1000배를 선택함, 개인적으로 나는 1000배파(ers)가 상황을 망쳐놨다고 생각함

    • 하지만 그 1000배의 성능은 범위 체크가 아니라 끝없는 추상화와 비효율성에 낭비됨

    • 나는 공급사에게 느리고 버그 많은 소프트웨어를 강제로 Sparc 20에서 돌리라고 했던 경험이 있음, 그 결과 소프트웨어를 최적화했고, 회사가 시장에서 성공할 수 있는 기반이 됨, 최적화는 경쟁 우위임

    • 1980년 이후만 그럴 수 있음, 최근 영상에서 요약하자면 “오늘날 컴퓨터는 20년 전의 컴퓨터보다 그다지 빠르지 않으며, 특별히 최적화해야만 실감할 수 있음”이라고 함, 작가가 컴파일러 최적화 등은 무시했지만, 실제로 퍼포먼스 향상폭은 생각보다 미미했고, 15년 동안 두 배밖에 안 올랐다고 함

    • 배열 범위 체크가 5%만 든다고 했는데, 모든 알고리즘이 그리 단순하지 않음, 처리 횟수에 따라 체크 도입만으로 비용이 3~4배 늘어날 수도 있음, 특정 용도에선 체크 강제하면 언어 자체가 경쟁력을 잃음, 대부분의 경우 상관없지만, 안전/일반모드로 구분해 사용하는 게 바람직하다고 봄

    • 단순히 범위 체크만 생각하면 비용은 낮은 편이지만, 안전 언어 자체의 부하는 훨씬 큼, GC 언어는 메모리 사용량이 몇 배나 늘기도 함

    • 대수의 법칙을 잊지 말아야 함, 한 시스템에서 성능 5% 저하는 별 일 아니지만, 전 세계 컴퓨팅 환경 모두에 5% 손실이 누적되면 엄청난 영향임

    • 단기 이득을 선호하는 인간 본성엔 동의하지만, 동적 경계 체크가 보안 이슈 자체를 해결하는 것은 아님, 궁극적 솔루션은 아직 없음

    • 지금 우리가 이렇게 된 근본적인 원인은, 브라우저에 묶여 있기 때문임

    • 첫 번째 답글이 사실상 정답임, C가 여전히 널리 쓰인다는 점만으로도 본질은 스택 아래쪽에 효율성이 없는 구조임

    • ‘5%’라는 근거가 애매함, 어떤 기준으로 계산된 비용인지 신뢰가 안 감, 배열에 값 하나 넣을 때마다 체크하면 실제로 비용이 두 배 이상 들어갈지도 궁금함

    • 현재 대부분의 프로그래밍 언어는 배열 범위 체크를 기본적으로 지원함

    • Node.js가 처음 나왔을 때 양상이 떠오름, 클라이언트와 서버 코딩을 잇는 게 큰 장점이었지만, 지금은 보안 악몽이 됐으니, 코드 베이스가 적은 미니멀 언어도 장점이 있음

    • 문자열 한 개가 기가바이트급 데이터를 담을 수 있다는 사실만 빨리 알았어도, 널 종단 문자열이 사라져서 모두가 고통을 덜 겪었을 것임

    • 1000배 빠른 제품을 즐기는 1000Xers는 오히려 극소수임, 일반 사용자가 겪는 데스크톱 소프트웨어는 여전히 느림

    • 실은 10만 배쯤 더 빨라짐, 클럭만 1000배, 코어도 10배, 명령 자체도 AVX 등으로 10배, 구조적으로 1~2백만 배 더 빠름, 그런데도 체감 속도엔 영향이 없음

    • 로버트 바턴이 이런 사람들을 ‘저열한 교단의 고위 사제’라 칭한 말을 인용함

    • 1980년 이후는 빠르지만, 2005년 이후를 보면 약 5배 향상 정도임

    • 클럭은 2000배, SIMD 등 IPC까지 80배, 코어까지 곱하면 결국 1~2백만 배 빠름, 그런데 대부분의 프로그램은 작성자가 단순히 ‘작동만 하면 그게 그 속도’라고 생각함, 최적화 자체에 대한 생각이 매우 소수, HN 유저 중에서도 마찬가지임

    • 2001년도 기준 1GHz CPU를 기본 소프트웨어의 실행 기준으로 삼았어야 했는데, AI 경험도 상당히 실망스러웠음, LLM이란 게 언어 변환, 코드 최적화 등 충분히 할 수 있어야 한다고 기대했지만 현실은 그렇지 않음, 직접 AI에 Unix sed 코드를 jvm 언어로 포팅시킨 적도 있는데 기본적인 것 외엔 중급 이상은 아예 실패임, 결국 이 모든 흐름은 ‘일자리 축소’가 목적이지 소프트웨어 품질 향상이 목적이 아님, AI는 앞으로 더 많은 나쁜 소프트웨어를 만들어낼 것임

    • 이게 바로 JavaScript, 그리고 유저의 미래임

  • Google(그리고 Facebook)에서 일하며, 하드웨어 가격이 얼마나 저렴하고 코드 최적화가 대부분 가치가 없다는 점을 실감함, 10년도 전에 Google은 데이터센터 자원관리가 필수였고 프로젝트마다 예산이 있음, CPU, HDD, 플래시 등 자원을 서로 맞바꿔 상대적 비용을 계산함, 플래시가 하드보다 20배 비싸도 실제 병목을 고려해선 플래시가 더 저렴할 때가 많았음, 이런 자원은 소프트웨어 엔지니어 시간(1 SWE=1인1년 기준) 등으로 환산됨, 최적화로 5000 CPU 코어 이상을 아끼지 못하면 오히려 손해임, 대형 프로젝트일 때만 최적화가 의미 있었고, 그 외에는 코드가 어차피 금세 교체되니 최적화가 무의미했음, 또 Web 사용성 측면에서 마우스 인터페이스가 매우 비효율적이며, 30~40년 전 텍스트 기반 단말이 훨씬 효율적이었음, ‘웹이 표준화 되어 다음 단계로 나아갈 것’이라 기대했지만 그렇게 되지 않았음, 여전히 매주 새로운 프레임워크가 나오고, 같은 스크롤 바까지 하드웨어와 호환되지 않게 재구현 중임, 이 문제의 해법을 모르겠음

    • 본인은 엔지니어링 비용이 높은, 큰 마진과 여러 프로젝트를 가진 회사에서만 성립하는 판단이라고 봄, 정말로 남는 돈이 조금이라도 생기면 엔지니어를 최적화에 투입시키는 게 나음, 실제로는 각 회사가 Google만 따라하니 경제 논리와 무관한 결정을 하며, 이런 게 많은 문제를 설명해줌

    • 나도 Google 출신, Google은 CPU별 사용량 최적화를 주로 얘기하지만, 실제로는 두 가지를 매우 강조했음 — 레이턴시, 그리고 전체 서버 활용률, 둘 다 상위 조직의 중요한 KPI라 엄청난 엔지니어 리소스가 투입됨, 머신 수가 많아질수록 놀리고 싶지 않고, 레이턴시에 민감한 비즈니스는 단 몇 ms라도 줄이려고 노력함

    • 실제로 코어 한 개 당 비용이 큰 회사이기에 Google 기준이 성립함, 대다수 일반 기업에는 전혀 해당하지 않음, Facebook/Google/Netflix 등의 규모에서만 통하는 방식임

    • Google이 더 나은 압축, 바이너리 직렬화 포맷을 고안한 것도 자체 수익성 개선 때문임

  • 나는 기사 제목을 보고 Carmack이 저성능 하드웨어에서의 소프트웨어 최적화를 비판하는 줄 알았음, 실제로는 그렇지 않고, 하드웨어 발전이 멈춘 상상 실험을 얘기하며, 결론에선 “싸고 확장성 큰 컴퓨팅이 없으면 혁신 제품이 줄어든다”는 점을 밝힘

    • 어제 나온 스레드와 연관된 얘기임

    • “싸고 확장성 있는 컴퓨팅 없이는 혁신이 줄어든다”는 결론에 대해, 실제로 우리는 스마트폰 이후 거의 혁신이 없었고, 자본이 하드웨어 발전에만 의존해 있으니 신제품도 본질적으로 기존 제품과 다를 것이 없어졌음

    • 개인적으로는 그 주장에 동의하지 않음, 잠시 기능 개발을 멈춘다 해도 충분한 준비 후 다시 혁신이 돌아올 것임, 하락세가 있겠지만 지속되진 않음

    • 핵심은 “비대함(bloat)”이 단순 낭비가 아니라 경제적 동기에서 비롯된 개발 생산성 향상임, 덜 복잡한 언어로 생산성을 키우는 것이 더 많은 인력 채용, 비용 절감 효과가 있음

  • 하드웨어의 수명을 계획된 폐기보다 5, 10년 더 늘릴 수 있으면 엄청난 전자폐기물과 희귀광물 사용, 온실가스 배출을 줄일 수 있음, 그러나 소프트웨어 시장은 이런 외부 효과 비용을 부담하지 않음, 출시 후 테스트·수정·반복이 장기 설계보다 훨씬 저렴함, 게임 산업 일부는 고성능+매출의 공식을 찾았지만 널리 퍼진 건 아님, 엔터프라이즈/소비자 SW는 성능보다는 사용자가 ‘참아주는 한계’에 맞춰 최소 요건만 신경씀, 계속적인 새로운 기능 추가와 변화 때문에 성능에 신경 쓰기 어렵고, 예산에는 오류율을 감안해 남겨둠, 비교적 ‘준비된 상태’에서 출시하는 방식과 달리 복잡성과 변화 리스크가 큼

  • 지난 10년 넘게 우리는 거래소 전체 매칭 엔진을 단일 쓰레드에서 돌림, 직렬화된 거래 처리만큼은 컴퓨팅 파워가 그렇게 빨리 성장하지 않았음, 수백만 TPS가 아니면 클러스터로 확장할 필요조차 없음, 오히려 설계를 단순화해서 단일 머신으로 처리할 수 있음

    • 이 점이 정말 답답함, 많은 시스템 아키텍트가 자신만의 존재감을 각인하려 시스템을 복잡하게 만들었고 이에 따른 신규 이슈만 양산했음, 원래 설계로도 대다수 요구는 충족되고, 현 기준의 로컬 컴퓨팅 파워라면 단일 머신 처리도 무난함

    • 주문 매칭을 병렬로 하지 못하는 이유가 궁금함 — 소트와 유사한 로그 단축을 적용하면 병렬처리가 가능하지 않을지, 혹시 매칭 과정에 단순 정렬 외에 다른 계산이 별로 없기 때문인지 궁금함

    • 단순 처리만 하면 단일 스레드 가능하지만, 각 트랜잭션마다 복잡한 연산이 필요하면 불가능함, 근데 실제로 그 정도로 복잡한 처리가 뭔지 도메인 지식이 부족해서 감이 안 옴

  • 만약 개발 툴이 발전을 지속했다면, 과거에는 RAD에서 완전 네이티브 GUI를 쉽게 만들었지만 지금은 Electron이 대세임, 여러 개의 웹 브라우저가 각자 Chromium 기반 변종으로 깔려있는 상황임

  • 결국 이는 자원 배분의 경제 문제임, 개발자에게 소프트웨어 최적화에 시간을 쓰게 할지, 아니면 새 기능을 만들게 할지 고민임, 후자가 더 수익을 만든다면 그렇게 할 것임, 반대로 최적화가 더 중요하면 그에 맞춰 행동함

    • 경제 문제라는데엔 동의하지만, 본질은 소프트웨어 기업이 전체 사회에 부정적인 외부효과를 전가한 사례로 봄, 에너지 추가 소비, 낭비, 전자폐기물 증대 등을 신경 쓰지 않음

    • 기술적/금융 부채를 타인에게 떠밀고 엄청난 쓰레기만 늘리는 구조임, 최적화의 실익이 없는 경우도 많겠지만, 단순히 서버만 추가하는 관행은 애석함

    • ‘기능 추가가 더 중요’라는 것은 경우에 따라 다름, 나는 최신 macOS, Windows, Android의 신기능 대부분을 사용하지 않으며, 효율적 환경과 보안이 더 중시됨, 디자인 소프트웨어 역시 신기능보다는 효율 개선이 더 기대됨, 오히려 10년 전 Illustrator/Photoshop을 원할 때도 있음, 음악 작업 프로그램에서는 신기능이 욕구 개선에 필요하긴 하지만 효율을 해치면 거부감이 큼, 코드 에디터는 VSCode만으로 충분하고, 보다 빠르고 가벼워졌으면 하는 바람임

    • 내 삶에서 효율화는 매우 중요함, 예를 들어 부엌에 뭔가 가지러 갈 때 항상 쓰레기/식기를 같이 가져가 두 번 일하지 않음, SW도 유사함, 하지만 ‘비싼 엔지니어 시간을 들여 최적화’와 ‘RAM/자원 추가’ 중 후자는 항상 저렴함, 문제가 충분히 커질 때만 최적화가 이득임, 시장이 어떤 선택이 이로운지 최종 결정함, 만약 하드웨어 추가로 얻을 이득이 줄어든다면, 최적화로 전환할 것임, 모어의 법칙이 한계에 다다르지 않았기에 아직은 그렇지 않음

    • 궁극적으로는 수요 문제임, 소비자가 더 빠른 SW를 중요하게 여기면 기꺼이 돈을 더 지불하겠지만, 실제로는 성능이 떨어져도 가격이 더 싸면 오히려 그 쪽을 택함

    • 바로 이것이 ‘엔쉬티피케이션(enshitification)’의 정의임

  • Electron 앱은 성능 면에서 불만이 많지만, 리눅스 랩탑으로 직장 환경을 견딜 수 있게 만든 핵심 혁신임, 예를 들어 Teams 미팅에 설치 없이도 쉽게 참여할 수 있음, 모두가 Winamp의 코드 최적화를 그리워해도, 실제론 Electron 앱의 접근성이 편리함

    • 차라리 Windows 환경에서만 동작해도 윈도우 전용 성능 좋은 소프트웨어가 Electron보다 훨씬 낫겠음, Wine으로라도 돌아갈 수 있고, Electron은 어떤 플랫폼에서도 최악임

  • 최근 Balatro라는 게임을 하며 느낀 점은, 지금도 단순 연산, 간단한 그래픽만 처리하면 되는 게임인데, 실제론 90년대 하드웨어(펜티엄II+3dfx)에서도 돌아갈 법한 게임이 요구하는 최소 스펙이 계속 높아짐, 최신 노트북에서나 돌아갈 정도로 과도한 사양 요구에 놀라움

    • 해당 게임은 lua와 love2d 엔진으로 만들어졌음, 개발자에게는 편의지만, 최소사양 역시 자연스럽게 상승함
답변달기