소프트웨어 환멸감

Translated from English by Park Hyunwoo et al.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

모든 것은 썩는다

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

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

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

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

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

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

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

나쁜 것이 그나마 나은 상황

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

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

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

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

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

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

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

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

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

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

프로그래밍도 혼란스럽다

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

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

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

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

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

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

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

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

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

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

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

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

우린 얽매여 있죠

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

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

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

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

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

2016 - 마이크로서비스의 문제를 해결하기 위해 #도커 를 도입해야 합니다.

2018 - 도커의 문제를 해결하기 위해 #쿠버네티스 를 도입해야 합니다.

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

@dr_c0d3: 2000: 100여 줄의 XML로 서블릿과 EJB의 “선언적인” 설정하기.

2018: 100 여줄의 YAML로 마이크로서비스의 “선언적인” 설정하기.

적어도 XML엔 스키마라도 있었죠…

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

시장은 신경도 쓰지 않죠

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

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

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

다 나쁘기만 한 건 아니죠

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

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

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

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

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

더 나은 세상을 위한 선언문

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

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

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

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