요약
요즘 소프트웨어가 나빠진다지만, 툭하면 멈추던 옛 소프트웨어로 돌아가고 싶지는 않습니다.
제이크 보이트코가 개인 블로그에 쓴 글입니다. 그는 코드를 10배 더 만들면서 오류율을 10배 줄이지 못하면 서비스가 더 불안정해진다며 품질 저하를 걱정해 왔습니다. 그래도 옛 소프트웨어가 더 좋았다는 향수는 착각이라고 봤습니다.
왜 중요한가
- 에이전트가 코드를 쏟아내는 지금의 품질 논쟁에서, 비교 기준인 과거가 생각만큼 좋지 않았다는 반론을 더합니다.
- 자동 저장, 온라인 업데이트, 프로세스 격리처럼 당연해진 장치들이 예전의 고질병을 없앴다는 점을 일깨웁니다.
핵심 내용
- 윈도는 블루스크린(시스템 오류로 멈추는 파란 화면)이 잦았고, 버그 있는 장치 드라이버와 자원 누수가 주원인이었습니다.
- 자동 저장이 없어 몇 시간 작업이 날아가곤 했고, 2010년 Google Docs 실험에서도 아무 기능 없는 Ctrl+S가 자주 눌렸습니다.
- CD에 흠집이 나면 프로그램을 쓸 수 없었고, 출시한 뒤에는 패치할 방법도 없었습니다.
- Diablo II는 클라이언트 해킹과 아이템 복제에 시달렸고, 이 문제는 Diablo III에서야 해결됐다고 했습니다.
- 저자는 지금 소프트웨어가 비대하고 이해하기 어려워졌다고 인정하면서도 옛 방식으로는 돌아가지 않겠다고 했습니다.
HN 반응
- 게임 업계 출신 이용자는 옛 게임이 거칠어도 더 과감했고, 팀과 비용이 커지며 실험이 억눌렸다고 반박했습니다.
- 원문이 응답 지연을 빠뜨렸다는 지적이 많았고, 지연은 나빠진 게 아니라 나아지지 않았을 뿐이라는 반론도 나왔습니다.
그런데 글쓴이가 Diablo 2와 Diablo 3(그리고 Quake)을 예로 든 건 흥미롭습니다. 이런 논쟁이 왜 이렇게 날카로워지는지를 그대로 보여 주는 사례라고 생각하거든요.
저는 90년대 후반에 초창기 AAA 게임 업계에서 일했는데, 그 시절 게임이 곳곳이 거칠었던 건 사실입니다. 하지만 그때는 감당하기 어려울 만큼 욕심을 부리고, 장르를 만들어 내고, 미친 듯이 혁신하던 시기이기도 했습니다. 그게 늘 매끄럽게 되지는 않았고요. 그래서 대작 게임에서도 플레이어가 새로운 경험에 진짜로 놀라는 일이 흔했습니다.
글쓴이는 Diablo 2에 비해 Diablo 3에서 고쳐진 편의성과 밸런스 문제를 쭉 늘어놓습니다. 하지만 Diablo 2는 Diablo 3이 갖지 못한 방식으로 분명히 중요한 게임이었습니다. 훨씬 위대한 게임이죠.
그리고 그 뒤에는 냉정한 현실이 도사리고 있습니다. 소프트웨어(특히 게임 소프트웨어)가 나아졌다는 건 대개 훨씬 나은 소프트웨어 공학 기준을 따르고, 훨씬 나은 외부 라이브러리나 훨씬 큰 팀이 만든 게임 엔진을 쓰고, 그 거친 부분들을 잡아내고 걸러 내는 절차에 훨씬 더 의존하게 됐다는 뜻이었습니다. 그러면서 팀이 훨씬 커지고 돈이 타들어 가는 속도도 훨씬 빨라지니, 예전의 실험과 혁신은 훨씬 위험한 일이 되어 통제하고 가두고 대부분 억눌러야 합니다. 개발비가 치솟는 만큼 게임 설계는 무엇보다 먼저 사업 모델, 소액결제 구조, 라이브 서비스에 맞춰질 수밖에 없고요. 현금 흐름 문제가 게임·소프트웨어 설계의 핵심이 되는 구석에 스스로를 몰아넣은 셈입니다.
(저는 FPS 쪽에서 이 변화를 직접 겪었습니다.)
제 말은, 평가할 축이 여러 개 있고 그중 일부에서는 과거의 소프트웨어가 훨씬 나빴다고 말하는 게 분명히 공정하겠지만 전부는 아니라는 겁니다. 그 축들 사이에는 깊은 긴장과 맞바꿈 관계가 있을 가능성이 높고요.
게다가 이 논쟁 전체가 흐려지는 이유가 하나 더 있습니다. 이 기간 동안 하드웨어도 극적으로 좋아졌다는 점입니다. 과거에 소프트웨어를 더 불안정하고 충돌하기 쉽게 만들던 프로그래밍 기법 중 상당수는 메모리와 연산 최적화에 달려 있었고, 이는 당시든 지금이든 소프트웨어 문화와는 사실 아무 상관이 없었습니다. 그저 하드웨어 현실에 대한 대응이었을 뿐이죠.
더 나아가 Diablo 4가 Diablo 3의 문제를 또 한 번 '해결'했다고 말할 수도 있습니다. D2나 D3보다 훨씬 폭넓은 사람들이 접근할 수 있게 됐으니까요.
D2와 D3를 수천 시간 한 사람에게 D4는 대체로 끔찍하게 느껴집니다. 접근성을 위해 치른 대가가, 예전 작품에서 즐기던 꼼수 같은(그리고 재미있던) 전략들을 더는 쓸 수 없게 된 겁니다. 수치 난이도를 알아서 맞춰 주는 시스템이 너무 노골적으로 캐주얼하거든요. 큰 장비를 얻을 때마다 곧바로 김이 빠져서 의미가 없어집니다. D3와 D2는 이런 문제가 없지만, 대신 난이도 곡선이 불연속적이고 여러 구간에서 가차 없습니다.
WoW의 난이도 레벨링은 당시엔 정말 좋아 보였지만, 돌이켜 보면 그 게임에 일어난 최악의 일이었어요. 차이를 없애 버리니까요. 모든 게 늘 나에게 맞춰 조정된다면 실력을 키울 이유가 없죠.
게임 스튜디오가 AAA 타이틀 하나에 들어가는 돈을 잘게 나눠서, 훨씬 작은 팀 여러 개에 주면 어떨까 싶습니다. 한정된 자원으로 타협해 가며 어떻게든 만들어 내야 하는 구조에서 나오는 극단적인 집중력을 활용하는 거죠.
한 팀이 아니라 10개 팀에 거는 겁니다.
3천만 달러짜리 예산이라도 제대로 집중하면 충분히 잘 돌아가고 보기에도 훌륭한 게임이 나올 거라고 확신합니다.
그중 1~2개만 터져도 전체적으로는 더 낫지 않겠습니까?
Factorio는 누가 봐도 완성도가 엄청나게 높은데, 개발 인원은 웬만한 AAA 타이틀보다 훨씬 적습니다.
비슷한 사례가 몇 개 더 있어요. Stardew Valley, 어찌 보면 마인크래프트(아니면 GTNH, 헤헤)도 그렇고요.
스튜디오들의 문제는 3천만 달러짜리 게임을 어떻게 만드는지 모른다는 거라고 봅니다. 3억 달러짜리는 아주 잘 만들지만요. 게다가 이들은 이용자에게 파는 게 아니라 기업(마이크로소프트나 플레이스테이션, 타깃 같은 곳)에 팝니다.
(마인크래프트, Factorio, Stardew Valley처럼 계속 개선될 수 있도록 허락받는 게임은 드물기도 합니다. '대박이 나던 시점'의 빌드나 릴리스로 돌아가 플레이해 보면 정말 거칠어요. 저는 Minecraft 1.7.10을 좋아하지만, GT:NH의 편의성 모드 없이는 도저히 오래 못 하겠더라고요.)
솔직히 이게 제일 어려운 부분이라고 생각합니다. 저도 인디가 어떻게 돌아가는지 한동안 들여다봤고 작은 팀을 꾸려 뭔가 만들어 보기도 했는데, 투자를 받거나 아니면 정말 고된 길을 가야 합니다.
작게 천천히 꾸준히 만들어 갈 수는 있지만, 돈이 떨어져 프로젝트가 무너지는 걸 피하려면 운 좋게 시대 흐름을 타야 합니다.
아니면 누군가 뒷받침해 줘야 하죠. Stardew Valley도 출시 전까지 4년 동안 만들었는데 파트너가 생활을 지원해 줬다는 게 유명하잖아요. 엄청난 생존자 편향입니다.
Project Zomboid도 떠오르는데, 헌신적인 커뮤니티를 위해 아주 오래 만들어 온 게임입니다. 자금난에다 불운도 꽤 겪었지만 그래도 유료 프로토타입을 일찍 내놓는 데는 성공했죠.
생각해 보니 Factorio는 어떤 사연이 있었는지 잘 모르겠네요.
Factorio도 얼리 액세스 성공담으로 꽤 괜찮은 사례입니다. 정식 출시 전까지 오랫동안 개발했고 다듬을 시간도 넉넉했죠. 개발자들이 질리지 않고 계속 플레이할 수 있는 종류의 게임이었던 것도 도움이 됐다고 봅니다. 그래서 개발하는 내내 설계를 반복해서 고칠 기회가 많았을 거고요. 플레이어가 지을 수 있기를 바라는 규모나 멀티플레이에 필요한 안정적인 시뮬레이션을 생각하면, 코드 품질이 좋을수록 게임 자체에 큰 이점이 되는 종류의 게임이기도 합니다. 핵심 게임 설계 자체를 하나의 '모드'로 개발한다는 원칙도 좋았는데, 덕분에 모딩 인터페이스가 꽤 강력해졌습니다.
제가 든 예시들도 전부 딱 맞는 시기에 엄청나게 운 좋게 대박이 난 경우입니다(3D 드워프 포트리스 채굴 시뮬레이터에는 얼마든지 '그 한 방'이 될 수 있었던 동시대 경쟁작이 여럿 있었고, 'PC용 Harvest Moon'이라는 아이디어는 진작 나왔어야 했는데 자리를 못 잡고 있었고, Factorio는 그 층을 사로잡는 데 필요한 완벽한 완성도(헤헤)를 갖췄죠. 비슷한 게임은 그때도 있었고 지금도 있습니다).
이런 건 어느 것도 그걸 기반으로 성공하는 사업 전략을 짜기 어렵습니다. 이런 종류의 게임 대다수는 성공하지 못하니까요.
맞아요, 그게 인디 게임 시장의 속성이죠. 다만 Factorio는 당시에 훨씬 독특했다고 생각합니다(완전히 그렇지는 않았지만요). Factorio에 영감을 준 마인크래프트 모드팩이 사실상 가장 가까운 플레이였는데, 모드라는 성격 때문에 노출이 다소 제한적이었습니다. 자동화 게임이 하나의 장르로 폭발한 건 대체로 Factorio의 성공 덕분이고요.
좋은 예로, Hearthstone의 초기 버전은 10명 남짓한 팀이 만들었습니다. 인디는 이런 걸 늘 해내는데, 대형 스튜디오가 해내는 경우는 상대적으로 드뭅니다.
제가 아는 곳 중에서는 닌텐도만 꾸준히 그러는 것 같은데요?
그런데 왜 그런지 모르겠습니다. 새로운 IP를 만들어서 다듬는 일을 가끔은 하는 게 좋을 것 같고, 적어도 몇 년에 한 번쯤은 새로운 걸 내놓을 법한데 말이죠.
아니면 외부 IP를 사들이는 쪽을 선호하는 걸까요.
프로젝트 운영 방식이 가끔 이상할 때가 있습니다. 예를 들어 Hi-Fi Rush는 잘 되고 있는 것처럼 보였는데도 마이크로소프트가 접어 버렸죠.
https://arstechnica.com/gaming/2024/05/microsoft-shuts-down-bethesdas-hi-fi-rush-redfall-studios/
https://en.wikipedia.org/wiki/Hi-Fi_Rush
지금 일하면서 Diablo 2 사운드트랙을 들으며 앉아 있는데(ㅋㅋ), D2에 문제가 많았던 기억은 별로 안 나네요... 대부분 문제는 제 전화 접속 인터넷 연결이었어요.
^F로 Latency(지연 시간)를 찾아봤는데 검색 결과가 없네요.
지연 시간은 컴퓨팅이 수년간 눈에 띄게 나빠진 지표 중 하나입니다.
저는 매일 여러 번, 뭔가를 하면(버튼 클릭, 텍스트 입력란에 타이핑 등) 반응이 눈에 보일 만큼 늦는 상황을 겪습니다. 몇백 밀리초에서 몇천 밀리초까지요.
예전엔 웹사이트에서만 그랬는데 요즘은 컴퓨터에 설치한 앱에서도 그렇습니다. 원인이 뭘까요? 제 가설은 이제 모든 게 React 같은 괴물 같은 웹 앱이고 브라우저 프로세스 안에서 돌아가는 데다, 심지어 로컬 앱조차 추적, 감시, 동기화 같은 걸 하려고 본사 서버까지 데이터를 왕복시키고 있을 수 있다는 겁니다.
게다가 UX가 끔찍합니다. 이럴 때 오래된 데이터가 그대로 보이거나, 작업이 진행 중이라는 표시가 전혀 없는 경우가 많거든요.
저는 지연 시간에 관해서는 완전히 까탈스러운 사람이에요. 컴퓨터 앞에서는 병적으로 참을성이 없고요. iOS의 느린 애니메이션도 그렇고, 수십 개짜리 이메일 주소 목록 하나 보여 주겠다고 빌어먹을 람다 함수가 몇 초씩 깨어나길 기다리는 것도 그렇습니다. LAN 화면 공유에서 생기는 몇 초의 지연만으로도 벽을 타고 올라갈 지경이에요.
이제 저한테는 소프트웨어가 쓰기 힘든 물건이 됐어요.
디지털 장비에 대해서는 음악가들과 얘기해 보셔야 합니다. 이분들은 지연 시간을 악기가 얼마나 멀리 있는 것처럼 느껴지느냐로 표현해요. 대단한 게, 실력 좋은 음악가들은 십수 ms 수준의 지연 시간도 말로 설명할 수 있습니다. 더 놀라운 건 거기에 적응하는 능력이 얼마나 뛰어나냐는 거고요. 저는 Rock Band 같은 게임을 할 때 영상과 오디오 지연을 보정하지 않으면 아예 플레이를 못 합니다.
게다가 장비를 이어 붙이면 더 심해집니다. 웻 채널에 몇 ms 이상 더하면 그게 누적되고, 웻 신호를 다시 드라이 신호로 되먹이는 경우엔 정말 골치 아파질 수 있습니다.
출처: 디지털 페달을 여러 개 출시해 본 사람입니다.
대학 시절 Rock Band 모임에 일부러 낡은 CRT TV를 끌고 갔어요. 휴게실에 있던 LCD 평면 TV와 비교하면 지연이 아예 없었거든요.
좋은 시절이었죠...
애니메이션 때문에 미치겠어요. 컴퓨터는 예전엔 생각하는 속도로 반응했는데, 이제는 아무 이유 없이 일부러 느리게 만들어 놨잖아요. 그냥 보여 달라고요!
예전엔 키보드 단축키를 서너 개씩 눈 깜짝할 새에 연달아 눌러도 컴퓨터가 따라왔어요. 그게 80MHz짜리 기계에서였다고요. 지금은 슈퍼컴퓨터를 쓰는데도 거의 모든 동작마다 0.25초에서 0.5초씩 걸리는 확대/이동/슬라이드 같은 걸 기다려야 합니다. 정말 환장하겠어요.
어떻게 대처하세요? 저는 앱을 직접 만들어 쓰려고 합니다. 예를 들어 영화 상영 시간표는 순수 HTML에 최소한의 CSS와 JS(함수 한두 개가 한계)로 만든 스크레이퍼를 쓰는데요. 모양은 1994년 같지만 빠르고 깔끔해요... 하지만 소프트웨어가 워낙 많아서 전부 다시 만들 수는 없으니 그냥 조용히 참고 삽니다.
저도 정확히 그렇게 했습니다. 젊을 때 모든 걸 다시 구현하기 시작해서 다행이에요. 안 그랬으면 그 고된 과정을 버틸 인내심이 없었을 수도 있거든요. 그런데 7년 동안 그렇게 하고 나니 추진력이 붙어서 점점 더 쉬워집니다. 좋은 아키텍처 원칙을 갖추는 것도 도움이 되고요. 저는 취미 프로젝트를 쓰고 버리는 물건처럼 다루지 않습니다. 그렇게 하면 결국 좌절하게 되니까요.
그 결과 버전 변화에도, 오르내리는 프로그래밍 유행(자바스크립트든 파이썬이든, 그쪽 동네에서 무슨 일이 벌어지든 저한텐 상관없습니다)에도 전혀 영향을 받지 않게 됐습니다.
저는 2011년경 대학 시절에 1.0 이전부터 Rust를 쓴 초기 사용자라서 구현 언어가 비교적 안정적이었던 것도 도움이 됐습니다. 지금은 그것과 C, Luajit을 합친 게 제 영구 스택인데, 제가 만든 프로그래밍 언어로 옮기는 작업을 진행 중입니다.
말씀하신 길의 자연스러운 종착점은 전부 다시 구현하는 것입니다. 지금은 LLM이 곁에 있어도 먼 길이 될 각오를 하셔야 합니다. LLM은 사람 마음을 읽지 못하니까 원하는 걸 대신 설계해 줄 수 없습니다.
안정적인 걸 원하시면 Common Lisp를 써 보세요.
일찍부터 Lisp에 빠지지 않은 게 후회됩니다. 버클리 EECS에서 CS61A 정규 커리큘럼은 Scheme 기반이었는데, 우리 때는 구글에서 온 초청 강사가 Python으로 가르쳤어요. A+를 받았고 Python 내부도 잘 알지만, 아, 정말 놓친 기회였습니다. 저는 함수형 쪽이 훨씬 취향에 맞거든요.
경험이 아주아주 많은 프로그래머가 지금 Common Lisp를 시작하는 가장 좋은 방법이 뭘까요?
저도 보통은 그냥 조용히 참고 삽니다. 바이브 코딩으로 고쳐 볼 시간도 없고요. 그래서 가능한 한 터미널에서 시간을 많이 보내려고 합니다.
GUI도 유용하지만, 제 특정 문제를 풀어 주는 CLI 스크립트를 금방 짤 수 있는데도 완벽한 GUI를 찾느라 너무 많은 시간을 썼습니다. 요즘은 문제의 핵심을 해결해 주는 라이브러리와 유틸리티를 찾는 데 집중하고, 그걸 제 작업 흐름에 맞게 엮어 씁니다. 한동안 그렇게 하다 보면 컴퓨터로 필요한 일 대부분이 해결되어 있다는 걸 알게 됩니다.
아니요, 지연 시간은 나빠지지 않았어요.
그냥 나아지지 않았을 뿐이죠.
근본적으로 개발자들은 지연이 너무 심해지면 고칩니다. 그런데 대개 그때까지는 손대지 않아요. 그래서 늘 간신히 참을 만한 경계선에 걸쳐 있습니다. 그 경계는 칩 속도 같은 게 아니라 사람의 행동으로 정해지고요.
2000년대 iTunes가 사용자 동작에 몇 초씩 걸려 반응하던 게 기억나요. 1980년대에 PageMaker 같은 소프트웨어를 쓸 때는 반응이 한참 걸렸고요. 1990년대 Lotus Notes는 끔찍했습니다. 백신을 돌리면 시스템이 거북이처럼 느려졌고요. 2000년대의 다른 것들, Acrobat Reader나 Outlook도 그랬죠.
컴퓨터 앱에서는 언제나 문제였어요.
https://danluu.com/input-lag/
확실히 나빠진 부분도 있습니다. 예를 들어 키를 누르고 나서 화면에 글리프가 나타날 때까지의 지연이 그렇습니다.
여기서 다루는 건 수백 밀리초에서 몇 초 단위로 측정되는 더 넓은 UX 지연이라고 봅니다.
저는 40년 넘게 컴퓨터를 써 왔지만, 전자잉크 화면을 빼면 키를 누른 뒤 글자가 그려지기까지의 지연 때문에 불편했던 적이 평생 한 번도 없어요. 그걸 두고 불평하는 사람도 본 적이 없고요.
저는 요즘 꾸준히 겪습니다. 특히 Teams 같은 애플리케이션에서요. 제가 충분히 빠르게 타이핑하면 글자가 버퍼에 쌓이는 일이 드물지 않고, 지연이 누적된 결과 문장을 다 치고 나서 2~3초 뒤에야 화면에 다 표시됩니다.
그렇군요! 저는 다행히 Teams를 안 쓰는 환경이라서요. 무서운 이야기는 들었지만 그렇게까지 심한 줄은 몰랐네요.
2017년 글이긴 한데, 여기에 따르면 입력 지연이 가장 낮은 개인용 컴퓨터 두 대는 Apple //e(1983)와 TI-99/4a(1979)라고 합니다.
https://danluu.com/input-lag/