Mt

← index

Loading contents...

Software disenchantment

소프트웨어 환멸감

I’ve been programming for 15 years now. Recently our industry’s lack of care for efficiency, simplicity, and excellence started really getting to me, to the point of me getting depressed by my own career and the IT in general.

저는 15년간 프로그래밍을 해왔습니다. 근데 요즘 우리 분야에서 효율과 간결함에 대한 추구, 그리고 제대로 만들려는 노력을 찾아보기가 어렵습니다. 이제까지 쌓아온 제 경력이나 IT 산업 전반에 대해 우울해질 지경이에요.

Modern cars work, let’s say for the sake of argument, at 98% of what’s physically possible with the current engine design. Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. All planes converged to the optimal size/form/load and basically look the same.

요즘 차들은 – 논쟁의 여지는 있지만 – 현재의 엔진 디자인에서 물리적으로 가능한 98% 수준으로 동작하고 있다고 합니다. 현대식 건축은 기능을 만족하는 재료를 충분히 사용하기만 한다면 주어진 조건에서 안전하게 서 있습니다. 모든 비행기는 크기/형태/중량 면에서 최적으로 수렴한 까닭에 기본적으로 다 비슷하게 생겼습니다.

Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”:

오직 소프트웨어만 달성 가능한 성능의 1%, 심지어 0.01%로 실행되는 경우에도 괜찮다고 여깁니다. 대부분 그 정도로도 괜찮다고 생각하는 것 같습니다. 심지어 얼마나 비효율적인가에 대해 “컴퓨터가 충분히 빠른데 우리가 뭔 걱정을 하지” 처럼 자랑스럽게 얘기하기도 합니다.

@tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I’ll make my time back in 41 years, 24 days :-)

@tveastman: 실행하는데 1.5초가 걸리는 매일 실행하는 파이썬 프로그램이 있다. 6시간을 들여 러스트로 재작성했더니, 이제 0.06초 만에 실행된다. 41년 하고 24일이 지난 후에야 효율을 개선하느라 쓴 시간을 보상받을 수 있겠군. :-)

You’ve probably heard this mantra: “programmer time is more expensive than computer time”. What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time.

이런 격언을 들어보신 적이 있나요? “프로그래머의 시간은 컴퓨터의 시간보다 비싸다.” 우리가 전례 없는 수준으로 컴퓨터를 낭비하고 있다는 얘기 아닙니까? 100 킬로미터를 가는데 100 리터의 기름을 퍼먹는 차를 사시겠어요? 1,000 리터라면 어때요? 컴퓨터에 대해서라면 우린 항상 그러고 있습니다.

Everything is unbearably slow

참을 수 없을 정도로 모든 것이 느리다

Look around: our portable computers are thousands of times more powerful than the ones that brought man to the moon. Yet every other webpage struggles to maintain a smooth 60fps scroll on the latest top-of-the-line MacBook Pro. I can comfortably play games, watch 4K videos but not scroll web pages? How is it ok?

둘러보세요. 우리가 쓰는 휴대용 컴퓨터는 사람을 달로 보내던 때에 비하면 수 천 배 이상 강력합니다. 그런데도 최신형 맥북 프로에서 웹 페이지를 초당 60 프레임으로 부드럽게 스크롤시키는 것조차 버겁죠. 편안하게 게임을 하고 4K 영상을 볼 수는 있지만, 웹 페이지는 스크롤하기 어렵다고요? 이게 정상인가요?

Google Inbox, a web app written by Google, running in Chrome browser also by Google, takes 13 seconds to open moderately-sized emails:

구글 Inbox는 구글이 만든 웹 앱이고, 역시 구글이 만든 크롬 브라우저에서 동작하는데, 이메일 하나 여는데 13초가 걸립니다.

It also animates empty white boxes instead of showing their content because it’s the only way anything can be animated on a webpage with decent performance. No, decent doesn’t mean 60fps, it’s rather “as fast as this web page could possibly go”. I’m dying to see web community answer when 120Hz displays become mainstream. Shit barely hits 60Hz already.

콘텐츠를 보여주는 대신 움직이는 빈 흰 상자를 애니메이션 시키는데, 그게 성능을 떨어트리지 않으면서 적당히 뭐라도 움직일 수 있는 유일한 방법이기 때문입니다. 사실, 괜찮다는 게 초당 60 프레임을 말하는 게 아니라 “웹 페이지가 낼 수 있는 최대 성능”에 가깝죠. 120Hz 디스플레이가 주류인 오늘날에도 웹 커뮤니티에서 답 하나 보려다 죽겠어요. 60Hz도 될까 말까에요.

Windows 10 takes 30 minutes to update. What could it possibly be doing for that long? That much time is enough to fully format my SSD drive, download a fresh build and install it like 5 times in a row.

윈도 10은 업데이트하는데 30분이나 걸립니다. 그 긴 시간 동안 뭘 하며 보내야 하나요? 그 시간이면 제 SSD를 완전히 포맷하고 새로 빌드를 받아 설치하는 걸 5번 하고도 남겠어요.

Pavel Fatin: Typing in editor is a relatively simple process, so even 286 PCs were able to provide a rather fluid typing experience.

Pavel Fatin: 에디터에서 타이핑하는 건 상대적으로 단순한 작업이라, 286 PC에서도 매끄럽게 입력하는 느낌을 받을 수 있었죠.

Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and also process input, recalculate the world and dynamically load/unload resources. How come?

요즘의 텍스트 에디터는 42년 된 이맥스보다도 입력 지연이 큽니다. 텍스트 에디터라고요! 키를 입력할 때마다 작은 사각 영역을 갱신하는 것뿐인데도 요즘 에디터는 16ms 내에 하질 못합니다. 긴 시간이에요. 정말 길어요! 3D 게임은 화면 전체를 수십만 폴리곤으로 16ms 내에 꽉 채워 그릴뿐 아니라 입력 처리도 하고 월드를 계산하며 동적으로 리소스를 올렸다 내렸다 한다고요. 어째서죠?

As a general trend, we’re not getting faster software with more features. We’re getting faster hardware that runs slower software with the same features. Everything works way below the possible speed. Ever wonder why your phone needs 30 to 60 seconds to boot? Why can’t it boot, say, in one second? There are no physical limitations to that. I would love to see that. I would love to see limits reached and explored, utilizing every last bit of performance we can get for something meaningful in a meaningful way.

일반적으로 더 많은 기능을 가진 소프트웨어는 더 빠르게 만들지 못합니다. 더 나을 것도 없는 느린 소프트웨어를 돌리기 위해 더 빠른 하드웨어를 쓰고 있습니다. 모든 것이 가능한 속도보다 저 한참 아래에서 느리게 돌아갑니다. 폰은 왜 부팅하는데 30에서 60초 정도가 걸리는지 이상하지 않으세요? 왜 1초 만에 부팅이 안될까요? 아무 물리적인 제한도 없는데요. 정말 보고 싶군요. 의미 있는 방법으로 우리가 얻을 수 있는 의미 있는 무언가를 마지막 모든 1비트의 성능까지 쥐어짜서 한계에 도달하고 탐구하는 모습을 정말로 보고 싶습니다.

Everything is HUUUUGE

모든 게 너무 커어어어다랗군요

And then there’s bloat. Web apps could open up to 10× faster if you just simply block all ads. Google begs everyone to stop shooting themselves in their feet with AMP initiative—a technology solution to a problem that doesn’t need any technology, just a little bit of common sense. If you remove bloat, the web becomes crazy fast. How smart do you have to be to understand that?

그리고 모든 게 지나치게 비대합니다. 웹 앱은 단순히 광고만 다 막아도 10배는 빠르게 동작할 겁니다. 구글은 모두에게 AMP를 제안하며 제살 깎아 먹기를 그만하라고 간청하고 있습니다. AMP는 문제 해결을 위해 그 어떤 새로운 기술도 필요 없는 상식적인 해결책입니다. 비대한 부분을 제거한다면, 웹은 미친 듯이 빨라질 겁니다. 이걸 이해하는데 더 설명이 필요한 만큼 어려운 얘긴가요?

Android system with no apps takes almost 6 Gb. Just think for a second how obscenely HUGE that number is. What’s in there, HD movies? I guess it’s basically code: kernel, drivers. Some string and resources too, sure, but those can’t be big. So, how many drivers do you need for a phone?

안드로이드 시스템은 아무 앱도 없는 상태에서 그 용량이 6 Gb나 됩니다. 도대체 얼마나 큰 숫자인지 잠깐 생각해보세요. 뭐 고화질 동영상이라도 들어있습니까? 커널, 드라이버 같은 기본 코드만 있을 것 같은데요. 뭐 문자열과 리소스도 좀 들어 있긴 하겠지만 그렇게 크진 않을 거예요. 그러니까, 폰을 위해서 도대체 얼마나 많은 드라이버가 필요한 거죠?

Windows 95 was 30Mb. Today we have web pages heavier than that! Windows 10 is 4Gb, which is 133 times as big. But is it 133 times as superior? I mean, functionally they are basically the same. Yes, we have Cortana, but I doubt it takes 3970 Mb. But whatever Windows 10 is, is Android really 150% of that?

윈도 95는 30Mb였습니다. 오늘날의 웹페이지도 그것보단 크죠! 윈도 10은 133배나 큰 4Gb입니다. 133배나 뛰어난가요? 그러니까, 기본적으로 기능은 똑같단 말이죠. 아, 그렇죠, 코타나(Cortana)가 있긴 하지만 그게 3970 Mb나 되진 않을 것 같은데요. 윈도 10이 그러거나 말거나 안드로이드는 그것보다 1.5배나 큰데요 뭐.

Google keyboard app routinely eats 150 Mb. Is an app that draws 30 keys on a screen really five times more complex than the whole Windows 95? Google app, which is basically just a package for Google Web Search, is 350 Mb! Google Play Services, which I do not use (I don’t buy books, music or videos there)—300 Mb that just sit there and which I’m unable to delete.

구글 키보드 앱은 보통 150 Mb나 됩니다. 화면에 고작 키 서른 개 그리는 앱이 윈도 95 전체보다 5배나 복잡할까요? 구글 앱은 그저 구글 웹 검색을 감싼 앱일 뿐인데 350Mb입니다! 구글 플레이 서비스는 쓰지도 않는데 (전 거기서 책이나 음악, 영상을 안 삽니다) 300Mb를 먹고 앉아있지만 지울 수조차 없습니다.

All that leaves me around 1 Gb for my photos after I install all the essential (social, chats, maps, taxi, banks etc) apps. And that’s with no games and no music at all! Remember times when an OS, apps and all your data fit on a floppy?

기본적으로 필요한 것들(소셜, 채팅, 지도, 택시, 은행 등)을 설치하고 나면 고작 1Gb 정도가 사진을 저장할 수 있는 공간으로 남습니다. 게임이랑 음악이 하나도 없는데도요! 플로피 디스크에 운영체제랑 앱, 그리고 당신의 모든 데이터를 저장하던 시절을 기억하시나요?

Your desktop todo app is probably written in Electron and thus has userland driver for Xbox 360 controller in it, can render 3d graphics and play audio and take photos with your web camera.

데스크톱에서 쓰는 Todo 앱은 아마도 Electron으로 만들어져 있을 텐데, 그 안에는 Xbox 360 컨트롤러 드라이버뿐 아니라 3D 그래픽을 렌더링하고 음악을 틀며 웹캠으로 사진 찍는 기능까지 내장되어 있습니다.

A simple text chat is notorious for its load speed and memory consumption. Yes, you really have to count Slack in as a resource-heavy application. I mean, chatroom and barebones text editor, those are supposed to be two of the less demanding apps in the whole world. Welcome to 2018.

한 심플한 텍스트 채팅 앱은 로딩 속도와 메모리 퍼먹는 일로 악명이 높습니다. 그렇죠, Slack은 리소스를 많이 먹는 무거운 앱으로 분류하는 게 낫죠. 헌데, 채팅과 간단한 텍스트 에디터는 이 세상에서 덜 복잡한 앱에 속한다는 점을 말하고 싶군요. 2018년에 오신 것을 환영합니다.

At least it works, you might say. Well, bigger doesn’t imply better. Bigger means someone has lost control. Bigger means we don’t know what’s going on. Bigger means complexity tax, performance tax, reliability tax. This is not the norm and should not become the norm. Overweight apps should mean a red flag. They should mean run away scared.

뭐 동작은 한다고 얘기할 순 있겠죠. 근데, 크다고 더 낫다는 법은 없어요. 크다는 건 이미 제어를 상실했다고 볼 수도 있고, 크면 클수록 복잡함에 대한 비용과 성능에 대한 손실, 신뢰성에 채무를 지게 됩니다. 이건 일반적인 게 아니고, 절대 일반적인 일이 되어서도 안됩니다. 과도하게 무거운 앱은 빨간 카드를 받아야 마땅합니다. 혐오스러운 일로 여겨져야 한다고요.

Everything rots

모든 것은 썩는다

16Gb Android phone was perfectly fine 3 years ago. Today with Android 8.1 it’s barely usable because each app has become at least twice as big for no apparent reason. There are no additional functions. They are not faster or more optimized. They don’t look different. They just…grow?

3년 전에는 16Gb 안드로이드 폰으로도 괜찮았을 겁니다. 안드로이드 8.1이 돌아가는 요즘은 모든 앱들이 특별한 이유 없이 두 배씩 커졌기 때문에 사용하기가 어렵겠죠. 새로운 기능도 없는데 말이에요. 최적화되거나 더 빨라진 것도 아니고요. 딱히 달라 보이는 것도 없는데. 커지기만…한거죠?

iPhone 4s was released with iOS 5, but can barely run iOS 9. And it’s not because iOS 9 is that much superior—it’s basically the same. But their new hardware is faster, so they made software slower. Don’t worry—you got exciting new capabilities like…running the same apps with the same speed! I dunno.

iPhone 4s는 iOS 5와 함께 발표되었는데, iOS 9을 돌리긴 버겁습니다. 그리고 iOS 9이 엄청 더 뛰어난 것도 아니고 기본적으로 같은데 말이죠. 하지만 하드웨어가 빨라졌으니 소프트웨어를 더 느리게 만들었습니다. 걱정하지 마세요 – 엄청난 새로운 기능을 얻게 될 테니까요. 예를 들자면… 같은 앱을 같은 속도로 돌릴 수 있죠! 잘 모르겠네요.

iOS 11 dropped support for 32-bit apps. That means if the developer isn’t around at the time of iOS 11 release or isn’t willing to go back and update a once-perfectly-fine app, chances are you won’t be seeing their app ever again.

iOS 11은 32비트 앱 지원을 버렸습니다. 즉, iOS 11이 릴리즈 되었을 때 개발자가 부재했거나, 한 때 완벽하게 멀쩡했던 앱을 업데이트하려고 하지 않는다면 다시는 그 앱을 볼 수 없을지도 모릅니다.

@jckarter: A DOS program can be made to run unmodified on pretty much any computer made since the 80s. A JavaScript app might break with tomorrow’s Chrome update

@jckarter: DOS 프로그램은 80년대 이래로 나온 수많은 컴퓨터에서 고치지 않고도 잘 돌아갑니다. 자바스크립트 앱은 당장 내일 있을 크롬 업데이트에도 망가질 수 있죠.

Web pages working today would not be compatible with any browser in 10 years time (probably sooner).

오늘 멀쩡했던 웹 페이지가 10년 내에 그 어떤 브라우저에서도 제대로 돌아가지 않을 수 있습니다 (아마도 그 이전에).

“It takes all the running you can do, to keep in the same place”. But what’s the point? I might enjoy occasionally buying a new phone and new MacBook as much as the next guy, but to do so just to be able to run all the same apps which just became slower?

“같은 곳에 있기 위해서는 있는 힘껏 달려야 하지”. 그런데 무슨 소용이 있죠? 내 옆 사람처럼 가끔 새 전화기와 새 맥북을 사면서 즐거울 수도 있겠지만, 그래서 할 수 있는 일이라는 게 그저 똑같지만 더 느려진 앱을 실행하는 것뿐인데요?

I think we can and should do better than that. Everyone is busy building stuff for right now, today, rarely for tomorrow. But it would be nice to also have stuff that lasts a little longer than that.

이보다는 더 잘할 수 있고 그래야 한다고 생각합니다. 모두가 당장 지금만 생각하며 만들고 있고, 내일을 생각하는 사람은 거의 없죠. 그보다는 좀 더 오래갈 수 있는 뭔가를 할 수 있으면 좋겠습니다.

Worse is better

나쁜 것이 그나마 나은 상황

Nobody understands anything at this point. Neither they want to. We just throw barely baked shit out there, hope for the best and call it “startup wisdom”.

이 시점에서는 이해하지 못할 수도 있습니다. 그러고 싶지도 않겠죠. 갓 구운 똥덩어리를 던져놓고 최고가 되길 바라며 “스타트업 교훈”으로 부르고 있으니까요.

Web pages ask you to refresh if anything goes wrong. Who has time to figure out what happened?

웹 페이지는 뭔가 잘못되면 새로고침을 누르라고 합니다. 어떤 일이 일어났는지 살펴볼 사람은 없는 건가요?

Any web app produces a constant stream of “random” JS errors in the wild, even on compatible browsers.

그 어떤 웹 앱이라도 “무작위” 자바스크립트 에러의 향연을 쏟아냅니다. 심지어 호환되는 브라우저 상에서도 그렇죠.

The whole webpage/SQL database architecture is built on a premise (hope, even) that nobody will touch your data while you look at the rendered webpage.

모든 웹 페이지와 SQL 데이터베이스 설계는 렌더링된 웹 페이지를 보는 동안 데이터가 달라지지 않을꺼라는 약속(이라 쓰고 희망이라고 읽습니다) 위에 만들어져 있습니다.

Most collaborative implementations are “best effort” and have many common-life scenarios in which they lose data. Ever seen this dialogue “which version to keep?” I mean, bar today is so low that your users would be happy to at least have a window like that.

대부분의 공동 작업 구현체는 “최선의 노력” 수준이라 데이터를 잃어버릴 수 있는 일상적인 시나리오를 품고 있습니다. “어떤 버전을 유지할까요?” 같은 다이얼로그를 보신 적 있죠. 그러니까, 오늘날의 기대가 너무 낮아서 이런 창을 보여주기만 해도 행복한 수준이라는거죠.

And no, in my world app that says “I’m gonna destroy some of your work, but you get to choose which one” is not okay.

하지만 아니요, 제 기준에서는 앱이 “이제 당신의 작업물 중 하나를 파괴할 예정인데, 뭘 부술지 골라보세요”라고 묻는 건 괜찮지 않습니다.

Linux kills random processes by design. And yet it’s the most popular server-side OS.

리눅스가 임의로 프로세스를 죽이는 건 설계된 것이죠. 그럼에도 서버에서는 가장 인기 있는 운영체제고요.

Every device I own fails regularly one way or another. My Dell monitor needs a hard reboot from time to time because there’s software in it. Airdrop? You’re lucky if it’ll detect your device, otherwise, what do I do? Bluetooth? Spec is so complex that devices won’t talk to each other and periodic resets are the best way to go.

제가 가진 모든 장치는 주기적으로 돌아가면서 실패합니다. 제 델 모니터는 가끔 완전히 껐다 켜야 하는데 그 안에 소프트웨어가 돌아가기 때문이죠. 에어드롭? 운이 좋아서 장치를 찾으면 좋겠지만, 그렇지 않으면 뭘 해야 하죠? 블루투스? 스펙이 너무 복잡해서 장치끼리 서로 통신할 수 없고 최고의 방법은 주기적으로 리셋하는 거죠.

And I’m not even touching Internet of Things. It’s so far beyond the laughing point I’m not even sure what to add.

Internet of Shit까지 갈 것도 없습니다. 웃음 포인트를 넘어서 뭘 더할 수 있을지도 모르겠네요.

I want to take pride in my work. I want to deliver working, stable things. To do that, we need to understand what we are building, in and out, and that’s impossible to do in bloated, over-engineered systems.

저는 제 일에 자부심을 가지고 싶습니다. 작동되는 안정적인 무언가를 전달하고 싶고요. 그러기 위해서는 우리가 뭘 만드는지, 안팎으로 이해해야 하는데 과하게 작업되어 부풀려진 시스템에서는 불가능합니다.

Programming is the same mess

프로그래밍도 혼란스럽다

It just seems that nobody is interested in building quality, fast, efficient, lasting, foundational stuff anymore. Even when efficient solutions have been known for ages, we still struggle with the same problems: package management, build systems, compilers, language design, IDEs.

아무도 완성도 있고, 빠르며, 효율적이고 오래가며 기본이 되는 요소를 만드는 데에는 관심이 없어 보입니다. 심지어 오랫동안 사용한 효율적인 솔루션에서도 같은 문제로 고군분투하고 있습니다. 패키지 관리, 빌드 시스템, 컴파일러, 언어 디자인, IDE 같은 것들요.

Build systems are inherently unreliable and periodically require full clean, even though all info for invalidation is there. Nothing stops us from making build process reliable, predictable and 100% reproducible. Just nobody thinks its important. NPM has stayed in “sometimes works” state for years.

빌드 시스템은 본질적으로 신뢰할 수 없고, 모든 변경 사항에 대한 정보가 멀쩡히 있는데도 불구하고 주기적으로 새롭게 다 지우고 다시 하기를 요구합니다. 이 과정을 신뢰성 있고 예측 가능하며 100% 재현 가능하게 못할 이유가 없습니다. 그저 이게 중요하다고 생각하는 사람이 없을 뿐이죠. NPM은 수년간 “가끔 동작함” 상태에 머물러 있습니다.

@przemyslawdabek: It seems to me that rm -rf node_modules is indispensable part of workflow when developing Node.js/JavaScript projects.

@przemyslawdabek: 내가 보기엔 rm -rf node_modules 은 Node.js/자바스크립트 프로젝트를 개발할 때 피할 수 없는 것으로 보인다.

And build times? Nobody thinks compiler that works minutes or even hours is a problem. What happened to “programmer’s time is more important”? Almost all compilers, pre- and post-processors add significant, sometimes disastrous time tax to your build without providing proportionally substantial benefits.

빌드 시간은 어떤가요? 컴파일러가 몇 분이나 심지어 몇 시간씩 돌아도 상관없는 듯 보입니다. “프로그래머의 시간은 중요합니다”는 대체 어디로 갔나요? 거의 대부분의 컴파일러와 사전, 사후 작업들이 절망적으로 많은 시간을 요구하는 반면 그에 비례하는 이익은 없는 편입니다.

You would expect programmers to make mostly rational decisions, yet sometimes they do the exact opposite of that. E.g. choosing Hadoop even when it’s slower than running the same task on a single desktop.

프로그래머라면 응당 합리적인 결정을 내릴 거라 기대할 수 있지만, 가끔은 완전 반대의 결정을 내리기도 합니다. 예) PC 한 대에서 돌리는 것보다 더 느림에도 불구하고 하둡을 선택함.

Machine learning and “AI” moved software to guessing in the times when most computers are not even reliable enough in the first place.

머신 러닝과 “인공지능”은 소프트웨어를 대부분의 컴퓨터를 애초에 신뢰할 수조차 없는, 추측하는 시대로 옮겨버렸습니다.

@rakhim: When an app or a service is described as “AI-powered” or “ML-based”, I read it as “unreliable, unpredictable, and impossible to reason about behavior”. I try to avoid “AI” because I want computers to be the opposite: reliable, predictable, reasonable.

@rakhim: 앱이나 서비스에 “인공지능”이나 “머신러닝” 같은 게 쓰여있으면, “신뢰성 없는, 예측 불가능한, 결과를 설명할 수 없는”이라고 읽는다. 가능하면 “인공지능”을 피하려고 하는데, 신뢰성 있고, 예측 가능하며, 합리적인 컴퓨터를 원하기 때문이다.

We put virtual machines inside Linux, and then we put Docker inside virtual machines, simply because nobody was able to clean up the mess that most programs, languages and their environment produce. We cover shit with blankets just not to deal with it. “Single binary” is still a HUGE selling point for Go, for example. No mess == success.

리눅스에 가상 머신을 넣은 다음, 도커를 가상 머신에 넣었는데, 그건 단지 프로그램과 언어, 그리고 실행 환경을 어떻게 깨끗하게 치울지 모르기 때문입니다. 거지 같은 상황을 이불로 덮어놓고 모른 체 하는 거죠. Go의 “단일 실행파일”이 아직도 주요한 장점으로 꼽히는 것을 보세요. 엉망이지 않으면 == 성공합니다.

And dependencies? People easily add overengineered “full package solutions” to solve the simplest problems without considering their costs. And those dependencies bring other dependencies. You end up with a tree that is something in between of horror story (OMG so big and full of conflicts) and comedy (there’s no reason we include these, yet here they are):

의존성 말인가요? 도입 비용을 염두에 두지 않고 과한 “전체 패키지 솔루션”으로 간단히 문제를 해결하려고 듭니다. 그리고 이 의존성은 또 다른 의존성들을 끌고 오죠. 결국 무서운 이야기(너무 크고 충돌로 가득 찬)와 코미디(이걸 포함할 이유도 없는데, 이렇습니다) 사이의 어딘가에 다다를 겁니다.

Programs can’t work for years without reboots anymore. Sometimes even days are too much to ask. Random stuff happens and nobody knows why.

더 이상 재부팅하지 않고 몇 년 동안 프로그램을 쓸 수 없습니다. 가끔은 며칠도 어렵죠. 아무도 이유를 모를 알 수 없는 일이 일어납니다.

What’s worse, nobody has time to stop and figure out what happened. Why bother if you can always buy your way out of it. Spin another AWS instance. Restart process. Drop and restore the whole database. Write a watchdog that will restart your broken app every 20 minutes. Include same resources multiple times, zip and ship. Move fast, don’t fix.

더 나쁜 건, 아무도 무슨 일이 일어나는지 멈춰 분석할 시간이 없다는 거예요. 새 걸 사면되는데 왜 그러냐는 식입니다. 다른 AWS 인스턴스를 띄우면 되죠. 프로세스를 재시작하고요. 데이터베이스 전체를 내렸다 올리죠. 워치독을 작성해서 20분마다 망가진 앱을 재시작하면 되니까요. 같은 리소스를 여러 번 포함하고 묶어서 압축해서 보냅니다. 고칠 필요 없어요, 그냥 빨리 가면 땡이죠.

That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.

이건 엔지니어링이라고 부를 수 없습니다. 게으른 프로그래밍일 뿐입니다. 엔지니어링은 당신이 만든 것의 성능, 구조, 한계를 깊이 이해하는 것입니다. 대충 만든 것을 그보다 더 거지같이 만든 것들과 함께 합치는 것은 그에 완전히 반하는 일입니다. 이걸 개선하기 위해서는 우리가 뭘, 그리고 왜 하는지 이해해야 합니다.

We’re stuck with it

우린 얽매여 있죠

So everything is just a pile of barely working code added on top of previously written barely working code. It keeps growing in size and complexity, diminishing any chance for a change.

그래서 모든 게 근근이 동작하는 코드 위에 근근이 동작하는 코드가 쌓여 있는 상태입니다. 계속해서 커지고 복잡도가 높아져, 바꿀 수 있는 기회는 사라져 갑니다.

To have a healthy ecosystem you need to go back and revisit. You need to occasionally throw stuff away and replace it with better stuff.

건강한 생태계를 이루기 위해서는 때론 후퇴했다 전진할 필요가 있습니다. 더 나은 것을 위해서는 종종 2보 전진을 위한 1보 후퇴가 필요합니다.

But who has time for that? We haven’t seen new OS kernels in what, 25 years? It’s just too complex to simply rewrite by now. Browsers are so full of edge cases and historical precedents by now that nobody dares to write layout engine from scratch.

근데 누가 그걸 할 여력이 있죠? 25년간 새로운 OS 커널을 본 적도 없는데요. 이제 와서 재작성하기에는 너무 복잡해져 버렸죠. 브라우저도 엣지 케이스와 역사적인 문제들로 레이아웃 엔진을 감히 바닥부터 새로 작성하려고 하지 않습니다.

Today’s definition of progress is either throw more fuel into the fire:

진전(progress)에 대한 오늘날의 정의는 불구덩이에 더 많은 연료를 붓는 것과 같습니다.

@sahrizv: 2014 - We must adopt #microservices to solve all problems with monoliths.
2016 - We must adopt #docker to solve all problems with microservices.
2018 - We must adopt #kubernetes to solve all problems with docker

@sahrizv: 2014 - 모놀리식의 문제를 해결하기 위해 #마이크로서비스 를 도입해야 합니다.
2016 - 마이크로서비스의 문제를 해결하기 위해 #도커 를 도입해야 합니다.
2018 - 도커의 문제를 해결하기 위해 #쿠버네티스 를 도입해야 합니다.

or reinventing the wheel:

아니면 바퀴를 새로 발명하던가요.

@dr_c0d3: 2000: Write 100s of lines of XML to “declaratively” configure your servlets and EJBs.
2018: Write 100s of lines of YAML to “declaratively” configure your microservices.
At least XML had schemas…

@dr_c0d3: 2000: 100여 줄의 XML로 서블릿과 EJB의 “선언적인” 설정하기.
2018: 100 여줄의 YAML로 마이크로서비스의 “선언적인” 설정하기.
적어도 XML엔 스키마라도 있었죠…

We’re stuck with what we have, and nobody will ever save us.

우리가 이미 가진 것에 사로잡혀 있으면, 아무도 우릴 구원하지 않을 겁니다.

Business won’t care

시장은 신경도 쓰지 않죠

Neither will users. They are only learned to expect what we can provide. We (engineers) say every Android app takes 350 Mb? Ok, they’ll live with that. We say we can’t give them smooth scrolling? Ok, they’ll live with a phone that stutter. We say “if it doesn’t work, reboot”? They’ll reboot. After all, they have no choice.

사용자도 마찬가지입니다. 사용자는 우리가 뭘 제공할지 기대하기만 합니다. 우리(엔지니어)가 모든 안드로이드 앱에 350Mb는 필요하다고 얘기하면, 그들은 그저 그런가 보다 합니다. 우리가 부드럽게 스크롤할 수 없다고 하면, 사용자는 그 덜덜거리는 폰을 그냥 쓸 겁니다. 우리가 “작동하지 않으면, 재부팅하세요” 하면, 재부팅하겠죠. 결국 사용자에겐 아무런 선택지도 남지 않습니다.

There’s no competition either. Everybody is building the same slow, bloated, unreliable products. Occasional jump forward in quality does bring competitive advantage (iPhone/iOS vs other smartphones, Chrome vs other browsers) and forces everybody to regroup, but not for long.

마찬가지로 경쟁할 만한 거리도 없습니다. 모두가 느리고, 쓸데없이 크기만 하고 구린 제품만 만들고 있으니까요. 가끔 경쟁 우위를 가지는 괜찮은 제품(아이폰/iOS vs 다른 스마트폰, 크롬 vs 다른 브라우저)이 튀어나와 다들 긴장하게 만들기도 하지만, 그리 오래 가진 않고요.

So it’s our mission as engineers to show the world what’s possible with today’s computers in terms of performance, reliability, quality, usability. If we care, people will learn. And there’s nobody but us to show them that it’s very much possible. If only we care.

그러니까 엔지니어들의 미션은 현대의 컴퓨터로 무엇이 가능한지 이 세상에 선보여주는 것이어야 합니다. 성능, 신뢰성, 품질, 가용성 측면에서 말이죠. 우리가 신경 쓰는 만큼 사용자도 알아갑니다. 우리가 아니라면 누가 이런 걸 보여줄 수 있을까요? 아마도 우리 밖에 없을 겁니다.

It’s not all bad

다 나쁘기만 한 건 아니죠

There are some bright spots indicating that improving over state-of-the-art is not impossible.

그래도 정말 업계를 뒤엎을 만한 새로운 한줄기 희망 같은 것들도 있습니다.

Work Martin Thompson has being doing (LMAX Disruptor, SBE, Aeron) is impressive, refreshingly simple and efficient.

Martin Thompson이 진행 중인 작업(LMAX Disruptor, SBE, Aeron)들은 인상적이고, 신박하게 단순하며, 효율적입니다.

Xi editor by Raph Levien seems to be built with the right principles in mind.

Raph Levien이 만든 Xi editor는 올바른 원칙을 염두에 두고 만든 것 같습니다.

Jonathan Blow has a language he alone develops for his game that can compile 500k lines per second on his laptop. That’s cold compile, no intermediate caching, no incremental builds.

Jonathan Blow는 자신의 게임을 위해 언어를 만들었는데, 그의 랩탑에서 50만 줄의 코드를 1초 만에 컴파일할 수 있습니다. 증분 빌드도 아니고, 중간 캐시가 있는 것도 아닌, 완전한 새 컴파일 결과가 그렇습니다.

You don’t have to be a genius to write fast programs. There’s no magic trick. The only thing required is not building on top of a huge pile of crap that modern toolchain is.

빠르게 작동하는 프로그램을 작성하기 위해 천재일 필요는 없습니다. 마술을 부리는 것도 아니고요. 요즘 유행하는 툴체인과 같이 거대한 쓰레기 더미 위에서 만들지만 않으면 됩니다.

Better world manifesto

더 나은 세상을 위한 선언문

I want to see progress. I want change. I want state-of-the-art in software engineering to improve, not just stand still. I don’t want to reinvent the same stuff over and over, less performant and more bloated each time. I want something to believe in, a worthy end goal, a future better than what we have today, and I want a community of engineers who share that vision.

진전을 보고 싶습니다. 바꾸고 싶습니다. 소프트웨어 엔지니어링이 현재의 최신 기술에 머무르는 것이 아니라 향상되는 것을 바랍니다. 같은 것을 계속 반복해서 더 느리고 덩치만 커지게 만들고 싶지 않습니다. 믿을 만하고, 목표로 삼을만한, 오늘날보다 더 나은 미래를 위한 그 무언가를 원합니다. 이러한 비전을 나누는 엔지니어들의 커뮤니티를 원합니다.

What we have today is not progress. We barely meet business goals with poor tools applied over the top. We’re stuck in local optima and nobody wants to move out. It’s not even a good place, it’s bloated and inefficient. We just somehow got used to it.

오늘날 우리가 하고 있는 것들은 진전이라고 할 수 없습니다. 너덜거리는 도구 위에서 간신히 비즈니스 목표만 충족시킬 뿐입니다. 지역 최적화에만 얽매여 아무도 나아가지 못합니다. 비대하고 비효율적인 그런 곳에서요. 여기에 익숙해진 겁니다.

So I want to call it out: where we are today is bullshit. As engineers, we can, and should, and will do better. We can have better tools, we can build better apps, faster, more predictable, more reliable, using fewer resources (orders of magnitude fewer!). We need to understand deeply what are we doing and why. We need to deliver: reliably, predictably, with topmost quality. We can—and should–take pride in our work. Not just “given what we had…”—no buts!

그래서, 이렇게 외치고 싶습니다. 지금 우리 현실은 완전 헛소리라고요. 엔지니어로서의 우리는 할 수 있고, 해야 하며, 더 잘할 겁니다. 더 나은 도구로 더 나은 앱을 더 적은 리소스(몇 배는 적게!)로 빠르고, 예측 가능하며, 신뢰성 있게 만들 수 있습니다. 우리가 뭘 하고 있는지, 그리고 왜 그렇게 하는지 완전히 알 필요가 있습니다. 우리는 최고의 품질로 신뢰성 있고 예측 가능한 제품을 전달해야 합니다. 우리는 우리 일에 자부심을 가질 수 있으며, 또 그래야만 합니다. “우리에게 주어진 게…” 같은 변명 말고요. 예외는 없습니다!

I hope I’m not alone at this. I hope there are people out there who want to do the same. I’d appreciate if we at least start talking about how absurdly bad our current situation in the software industry is. And then we maybe figure out how to get out.

저 혼자만 이러는 것이 아니길 빕니다. 저와 같은 행동을 할 이가 저기 어딘가 있기를 바랍니다. 지금의 소프트웨어 산업의 상황이 얼마나 곪아있는지 얘기라도 할 수 있으면 좋겠습니다. 그래야 이 상황에서 어떻게 벗어날지 궁리라도 할 테니까요.

September 17, 2018 · Discuss on HackerNews Reddit

2018년 9월 17일 · HackerNews Reddit에서 토론 보기

Translators

Latest update at 2019-08-13T00:01:06Z

In alphabetical order