데이터로 쓴소리하는 엔지니어, 댄 루
Dan Luu(댄 루)라는 이름이 낯선 분도 있을 텐데요. 영어권 개발자들 사이에서는 '이 사람 글이 올라오면 일단 읽는다'는 말을 듣는 엔지니어예요. CPU 설계 회사를 거쳐 구글, 마이크로소프트, 트위터 같은 곳에서 일했어요. 그의 블로그 danluu.com은 꾸밈이 거의 없는 텍스트 페이지인데도 오랫동안 많이 읽혀 왔고요. 글은 대개 비슷한 방식으로 흘러가요. 업계에서 다들 당연하게 여기는 관행을 하나 골라서, 데이터와 실제 사례를 들이대며 '정말 그래?'라고 묻는 거죠.
이번 글 제목은 'We should be more ambitious with the software we build', 우리말로 하면 '우리는 더 야심 찬 소프트웨어를 만들어야 한다'예요. 메시지는 제목 그대로 단순해요. 그런데 이 질문이 하필 지금 나왔다는 게 꽤 의미가 있어요.
그의 이전 글로 보는 '야심'의 의미
댄 루가 말하는 야심은 거창한 비전을 세우자는 얘기가 아니에요. 그동안 쓴 글들을 같이 놓고 보면 뜻이 선명해지는데요. 핵심은 '훨씬 잘할 수 있는데 이 정도에 만족하고 있다'는 문제의식이에요.
유명한 글 중에 1977년부터 2017년까지 나온 컴퓨터들의 입력 지연(latency)을 직접 잰 글이 있어요. 키를 누르고 화면에 글자가 뜨기까지 걸리는 시간이요. 재보니 1983년에 나온 Apple IIe가 측정한 기기 중 가장 빠른 편에 들었어요. 성능이 수천 배 좋아진 최신 컴퓨터보다도 빨랐던 거예요. 하드웨어는 엄청나게 빨라졌는데, 그 성능이 소프트웨어 계층 어딘가에서 다 새어나간 거죠.
웹 페이지가 비대해지는 문제(web bloat)를 다룬 글도 같은 맥락이에요. 느린 인터넷에서는 웹사이트들이 쓸 수 없을 만큼 무거워졌다는 걸 보여주면서, 그게 기술의 한계가 아니라 신경을 안 써서 생긴 문제라고 짚었어요. 트위터 시절 경험을 바탕으로 쓴 글에서는 커널이나 JVM처럼 깊은 영역을 아는 사내 전문가 몇 명이 큰 비용 절감과 안정성 개선을 이끈 사례를 들었어요. 깊이 파고드는 역량이 과소평가되고 있다는 거였죠.
이 글들에 깔린 생각은 하나예요. 소프트웨어가 느리고 무겁고 자주 고장 나는 건 자연법칙이 아니라 선택의 결과라는 것. 그러니 기준을 높이면 실제로 더 좋은 걸 만들 수 있다는 거예요.
작은 팀이 큰 걸 만든 사례들
야심이라는 말이 현실성 없게 들린다면 역사를 보면 돼요. 사례가 생각보다 많거든요.
SQLite는 아주 적은 수의 개발자가 유지보수해요. 그런데 항공 소프트웨어 수준의 테스트를 목표로 삼았고, 지금은 전 세계 거의 모든 스마트폰과 브라우저에 들어가 있어요. WhatsApp은 페이스북에 인수될 때 엔지니어가 수십 명 정도였는데 수억 명의 사용자를 감당했어요. 당시 주류가 아니던 Erlang을 깊이 이해하고 끝까지 밀어붙인 결과였죠. Figma는 '디자인 툴은 브라우저에서 못 돌린다'는 통념과 반대로 갔어요. C++로 짠 렌더링 엔진을 웹어셈블리로 브라우저에서 돌렸고요.
세 곳 모두 남들이 '이 정도면 됐다'고 하는 선보다 훨씬 높은 곳에 기준을 뒀어요. 결과를 가른 건 인원이나 예산보다 기준을 얼마나 높게 잡았느냐였어요.
왜 하필 지금 이 질문일까
AI 코딩 도구가 일상이 되면서 이 질문은 더 날카로워졌어요. 코드 쓰는 비용이 확 떨어지면 조직이 갈 수 있는 길은 크게 두 가지예요. 같은 걸 더 적은 인원으로 만들거나, 같은 인원으로 훨씬 좋은 걸 만들거나. 지금 업계는 대체로 앞쪽으로 기울어 있어요. 비용 절감이나 인원 효율화 이야기가 먼저 나오잖아요.
더 야심 찬 소프트웨어를 만들자는 주장은 뒤쪽 길을 진지하게 고민해보자는 제안으로 읽을 수 있어요. 남는 시간과 여력을 성능 최적화, 예외 상황 처리, 접근성, 정말 어려운 기능에 쓰자는 거죠. 반대로 AI가 '그럭저럭 돌아가는 평범한 코드'를 쏟아낼수록 평범한 수준에 만족하는 습관이 더 쉽게 굳어질 수 있다는 점도 생각해볼 만해요.
한국 개발자에게 주는 시사점
우리 현실에 대입해보면 뜨끔한 데가 있어요. 요구사항 문서대로만 만들면 끝나는 프로젝트 구조, '일단 돌아가게 하고 나중에 고치자'의 나중이 끝내 오지 않는 문화, 장애가 나야 비로소 성능을 챙기는 분위기. 이런 환경에서 개인이 '더 야심 차게'를 외치기는 쉽지 않죠.
그래도 작게 시작할 방법은 있어요. 내가 맡은 기능의 응답 시간을 실제로 재고 목표치를 정해보는 거예요. 다들 '원래 그래'라고 넘기는 느린 빌드나 가끔 실패하는 테스트를 하나 골라 끝까지 파보는 것도 좋고요. 매일 쓰는 도구의 한 층 아래, 그러니까 DB 내부나 런타임, 네트워크를 깊이 공부해봐도 돼요. 댄 루의 글들이 거듭 보여주는 건, 큰 개선은 대단한 천재가 아니라 '이거 왜 이렇게 느리지?'를 끝까지 파고든 사람한테서 나온다는 거예요.
마무리
한 줄 정리: 소프트웨어가 지금 이 정도인 건 한계가 아니라 기준의 문제고, 도구가 강력해진 지금이야말로 기준을 올릴 때예요.
일하면서 '이건 훨씬 좋게 만들 수 있는데' 싶었던 소프트웨어가 있으셨나요? 그리고 AI 덕분에 생긴 여유를 여러분 팀은 '더 적은 인원'과 '더 좋은 결과' 중 어디에 쓰고 있나요?
🔗 출처: Hacker News