니클라우스 비르트의 ‘소프트웨어는 하드웨어가 빨라지는 것보다 더 빠르게 느려진다’는 주장과, 클라우드·LLM 시대에 되돌아본 효율과 복잡성의 거래에 대한 에세이.
URL: https://jmoiron.net/blog/wirths-revenge/
Title: Wirth's Revenge
1995년, 튜링상 수상자인 니클라우스 비르트(Niklaus Wirth)는 A Plea for Lean Software라는 에세이를 썼는데, 당시 소프트웨어의 현실에 대해 대체로 불평을 늘어놓는 내용이다. 그 불평들 가운데에는 비르트가 동료 마르틴 라이저(Martin Reiser)1의 말이라고 밝히긴 했지만, 이제는 비르트의 법칙(Wirth's Law) 으로 알려지게 된 다음과 같은 주장이 있다.
소프트웨어는 하드웨어가 빨라지는 속도보다 더 빠른 속도로 느려지고 있다.
그랜드파 심슨 흉내를 최대한 내며, 비르트는 이렇게 푸념한다.
약 25년 전에는 8,000바이트의 저장공간만으로도 대화형 텍스트 편집기를 설계할 수 있었다. (현대의 프로그램 편집기는 그 100배를 요구한다!) 운영체제는 8,000바이트로 버텨야 했고, 컴파일러는 32KB 안에 들어가야 했지만, 현대의 후손들은 메가바이트를 요구한다. 이렇게 부풀어 오른 소프트웨어가 더 빨라지기라도 했는가? 정반대다. 하드웨어가 천 배 빨라지지 않았다면 현대 소프트웨어는 도저히 쓸 수 없었을 것이다.
여기서 등장하는 수치들은 현대의 일반 독자에게는 터무니없게 들릴 수밖에 없겠지만, 공감할 만한 지점이 많다. 1995년 이후에만 이어진 나의 25년 소프트웨어 경력은 여러모로 비르트의 법칙에 관한 두 막짜리 이야기였다. 어떤 작용과, 그에 대한 반작용.
개인적으로 나는 비르트가 “효율을 잃었지만 얻은 가치가 없다”라고 결론 내린 데에는 동의하지 않는다. 그가 “윈도우의 등장, 잘라내기-붙여넣기 전략, 팝업 메뉴의 도래, [..] 의미 있는 명령어를 예쁜 아이콘으로 대체한 것”을 한탄할 때, 그는 이런 기능들이 컴퓨팅을 더 많은 사람들에게 접근 가능하게 만드는 데 기여한 가치를 제대로 평가하지 못했고, 런타임 비용에만 너무 집중하고 있다. 프로그래머들은 소프트웨어를 사회적 가치보다 기술적 장점으로만 너무 빠르게 판단하곤 한다.
비르트는 2년 전에 세상을 떠났지만, 그는 컴퓨터 과학 분야의 거인이었고 나와, 그리고 내가 영감을 받았던 다른 많은 사람들에게도 큰 영감의 원천이었다. 여러모로 단순함에 대한 내 집착과 시스템 설계 감각은 그에게서 비롯되었다.
비르트의 법칙은 너무도 자명해서, 지속적으로 연구되고 재발견되는 주제가 되어 왔다.
그 대표적 사례가 2017년 댄 루(Dan Luu)의 입력 지연(input lag)에 대한 훌륭한 글이다. 그는 시간이 지날수록 입력 지연이 악화되고 있다고 느꼈고, 고속 카메라를 구해 키를 누르는 순간부터 글자가 화면에 나타날 때까지의 지연을 다양한 하드웨어에서 측정했다. 가장 낮은 지연을 보인 컴퓨터는 1983년의 Apple 2e였다.
1983년 이후 입력 지연이 늘어난 이유는 입력을 처리하는 파이프라인에 훨씬 더 많은 소프트웨어가 끼어들었기 때문이다. Apple 2e가 가졌던 하드웨어 인터럽트 기반 입력 처리 방식은 현대의 요구사항을 만족시키기에는 유연성이 부족하다. 그래서 이런 추가 복잡성은 우리에게 많은 가치를 제공하지만… 물론 공짜는 아니다. 그리고 조심하지 않으면 그 비용 중 하나가 지연(latency)이 된다.
루는 이어서 복잡성과 단순성에 대해 많이 쓰며 흥미로운 관찰을 내놓는다. 지연 문제를 해결한 현대 시스템들은 대체로 복잡성을 제거해서가 아니라, 오히려 복잡성을 더해 해결한다는 것이다. 당시에는 복잡성과 단순성에 대한 이야기가 많았는데, 수많은 소프트웨어 개발자들이 이번에는 데이터센터에서 벌어진 또 하나의 거대한 트레이드오프, 즉 클라우드 컴퓨팅의 광범위한 채택이라는 변화를 겪고 있었기 때문이다.
1995년, 비르트가 에세이를 썼을 무렵에 새로운 인터넷 회사를 운영하고 싶다면, 컴퓨터 한 대를 구해서 바로 시작할 수 있었다. 아마존은 그 해 7월에야 출범했지만, 제프 베이조스의 차고에서 시작했다는 일화로 유명하다.
그 당시 인터넷 기업의 요구사항은 더 단순했다. 웹은 전 인구가 쓰는 보편적 기술이 아니었다. 당시 웹 사용자는 약 1,600만 명 정도였고, 인터넷 사용자보다 SNES를 가진 사람이 더 많았다. Slashdot 은 존재하지 않았다. 24/7/365에 99.999% 가용성(5 nines)을 기대하는 분위기도 없었고, “바이럴”로 터질 기회도 없었다.
2010년이 되자 상황은 달라졌다. 물론 그때도 Slashdot 을 맞을 수는 있었겠지만, 더 중요한 건 트위터와 페이스북이 하룻밤 사이에 엄청난 트래픽을 몰아줄 수 있었다는 점이다. 인터넷 사용자는 20억 명으로 불어났다.
회사의 소프트웨어를 돌리려면 자체 데이터센터를 지을 수도 있지만, 이는 많은 전문성이 필요한 복잡한 과업이다. 땅, 인허가, 시공사 등등이 필요하다. 나는 어디서부터 시작해야 할지조차 모르겠다.
기존 데이터센터를 살 수도 있지만, 여전히 전력, 비상 발전기/배터리, 냉방, 소화 설비, 랙, 유지보수, 네트워킹을 관리해야 한다. 역시 소프트웨어 업계에서 수십 년을 일했어도 요구사항 목록을 그럴듯하게 뽑아내기조차 어렵다. 큰 투자이고, 운영비(opex)도 많이 든다.
코로케이션(colo)에 랙을 임대해 컴퓨팅에만 집중할 수도 있지만, 그 수요는 순식간에 변할 수 있다. 사용자 10만 명을 기준으로 비용을 계획해놓고 결국 시장 반응을 얻지 못하면, 과지출을 한 채 쓸모없는 하드웨어에 현금을 태우는 꼴이 된다(그 돈은 제품 개발에 쓸 수도 있었는데). 반대로 관심이 폭발적으로 몰려오면, 사람들에게 수년간 fail whale을 보여주거나, 아예 성공 기회를 통째로 놓칠 수도 있다.
클라우드 컴퓨팅은 그 시대의 해답이었다. 2010년 무렵, 아마존은 제프의 지하실을 벗어나 자사 온라인 사업을 위해 거대한 데이터센터를 직접 운영하고 있었다. 2010년 스티브 예기(Steve Yegge)가 썼듯, 베이조스는 2002년에 모든 내부 팀이 서비스를 API로 제공하도록 요구하는 영향력 있는 API 의무화 메모를 배포했다. 2006년에는 그들이 유료 고객에게 공개할 수 있다고 판단한 플랫폼을 이미 구축했고, 그것이 EC2와 S3 형태로 등장했다. AWS는 웹 인터페이스나 직접 API 호출을 통해 아마존 데이터센터의 용량을 임대할 수 있게 해주었고, 세분화된 시간 단위로 과금했다.
이 파이프라인의 각 단계는 추가 비용을 가져오지만, 모두 상당히 가치가 있다. 특히 마지막 단계가 그렇다. 오늘날에는 그 파이프라인에 더 많은 단계가 추가되었는데, 예컨대 RDS나 IAM 같은 완전관리형 서비스는 소프트웨어 관리까지 추상화하고, Lambda는 하드웨어 요구사항을 한층 더 추상화하여 사용량 기반으로 확장(그리고 과금)할 수 있게 한다.
소프트웨어를 운영하는 비용이 올라갔음에도, 클라우드 플랫폼의 접근성 향상과 위험한 자본지출(capex)의 감소는 웹 소프트웨어의 폭발적 증가로 이어졌다. 그 사이 하드웨어는 계속 발전해 임대 용량을 단위 비용 대비 더 강력하게 만들었고, 사용자당 비용도 낮췄다.
하지만 모든 “비르트식 트레이드오프”가 건전한 엔지니어링은 아니다.
내 커리어 초반, 나는 콘데 나스트(Condé Nast) 소유의 신문 발행사에서 일했다. 나는 회사의 비교적 전향적인 개발 프로젝트 중 하나의 리드 엔지니어였는데, 수십 개 지역 신문사에 걸친 지역 스포츠 결과 데이터를 관리하는 Django 애플리케이션이었다. 이 애플리케이션은 매우 다양한 사용자와 유스케이스에 대해 단일한 진실의 원천(single source of truth)을 제공했다.
인쇄 신디케이션 시스템은, 각 신문의 인쇄 시스템이 이해할 수 있는 피드를 생성하기 위해 꽤 지저분한 템플릿을 작성하는 작업을 포함했다. 시간이 지나자 문제가 보이기 시작했다. 이 템플릿들이 렌더링에 수분 이 걸렸고, 매일 밤 데이터베이스를 불태우고 있었다.
소프트웨어 업계에서 좀 굴러봤다면, 이미 문제를 짐작할지도 모른다. 템플릿은 ORM을 사용하고 있었고, 이 ORM은 속성 접근 시 외래 키 필드를 동적으로 로드했다. 그래서 무해해 보이는 루프가 반복마다 데이터베이스 쿼리를 하나씩 날리고 있었다. 템플릿은 중첩 루프가 많은 복잡한 구조였고, 렌더링 한 번에 수십만 개의 쿼리를 보냈는데, 그중 상당수는 템플릿의 다른 부분에 있는 다른 루프에서 같은 쿼리를 반복해서 보내는 것이었다.
조인을 통해 해당 필드를 미리 로드(preload)하면 끔찍한 성능의 일부는 개선할 수 있었겠지만, 템플릿이 너무 많았고 복잡했으며 데이터베이스도 커서, 현실적으로 성공할 수 있는 길이 아니었다. 댄 루가 지연 연구에서 결론 내린 것처럼, 효과가 있었던 해결책은 더 많은 복잡성을 추가하는 것이었고, 그 형태는 똑똑한 캐싱 레이어였다.
템플릿 프로젝트를 시작할 때는 우리가 그런 선택을 하고 있다는 걸 몰랐지만, 이것은 “나쁜” 비르트식 트레이드오프였다. 물론 유용하긴 했다. 어떤 템플릿에서 어떤 데이터가 필요할지를 신중히 관리하는 대신, 최상위 객체 리스트만 가져오고 나머지 데이터는 ORM이 필요할 때 즉석에서 가져오게 할 수 있었기 때문이다.
프로젝트는 빠르게 출발했지만, 복잡성이 비교적 낮은 규모에서도 성공적으로 실행하는 것이 불가능해졌다. 문제가 뭔지 깨닫기 전까지 우리는 자동 로딩 필드의 편리함을, 그 진짜 비용을 이해하지 못한 채 사용했고, 그 결과 우리가 만든 소프트웨어는 낭비적인 괴물이 되어버렸다.
나는 지금 LLM과 관련해 더 큰 규모로 같은 일이 벌어지는 것을 보고 있고, 비르트가 지팡이를 흔들며 분노하던 심정에 점점 더 공감하게 된다.
프로그래밍은 컴퓨터가 내 대신 어떤 일을 하도록 만드는 행위다. 많은 사람들이 LLM 덕분에 처음으로 “컴퓨터에게 무언가를 해달라고 요청하면, 실제로 가서 해준다”는 경험을 하고 있다. 하지만 이 접근만으로 오로지 프로그래밍을 하려 하면 문제가 생긴다.
LLM이 비판자들이 말하듯 걷잡을 수 없는 생태 재앙은 아닐지라도, LLM이 계산적으로 몹시 비싸다는 사실은 변함없다. AI에게 2 * 3이 뭐냐고 물으면, 몇 초의 대기 시간, 몇 밀리리터의 물, 그리고 TV로 틱톡 영상 5%를 볼 정도의 전력을 대가로 6이라고 알려준다. 하지만 여러분 앞에 있는 컴퓨터는 이 계산을 초당 10억 번 할 수 있다.
내가 의도치 않게 데이터베이스에 서비스 거부(DoS)를 걸어버린 신디케이션 피드 문제의 원인이 ORM 사용 비용에 대한 무지였다면, LLM을 자동화에 통합하기 시작할 때 유사한 무지가 엄청난 의도치 않은 비용으로 이어질 수 있다는 건 너무나 명백하다.
나는 실제 현장에서 그런 사례를 몇 가지 보았고, 이 함정이 특히 피하기 어려울 수도 있겠다고 생각하게 됐다. LLM에는 교육하거나(혹은 교육을 시뮬레이션하거나), 최소한 관련 자료를 가리켜줄 수 있는 능력이 있지만(그 자료 중 일부는 진짜일지도 모르지만), 일반 사람들은 그렇게 사용하지 않는다.
사람들은 LLM에게 문제를 제시하고, 그 문제를 풀어달라고 한다.
그 예시는 나 자신 에게서도 찾을 수 있다. 처음 LLM을 써봤을 때 나도 그렇게 썼다. 나는 (안타깝게도 이제는 유지보수되지 않는) 훌륭한 레시피 사이트에서 덤프한 레시피 데이터를 셀프호스팅 레시피 관리 앱으로 가져오고 싶었다.
“음, 이거 귀찮겠는데, LLM에게 시켜야지”라고 생각했다. 그래서 로컬 LLM에게 대상 포맷의 명세를 주고 파일을 변환해달라고 했다. 결과는 10분에 파일 하나, 부정확하고 포맷도 엉망이었다. 느렸고 쓰레기를 생산했다.
엔지니어들이 프로그래밍 에이전트를 칭찬할 때, 그들이 사용하는 방식은 이런 게 아니다. LLM에게 반복적이고 정확해야 하는 일을 직접 수행하라고 시키는 게 아니라, 그 일을 수행하는 스크립트를 작성하라고 시킨다. 그리고 드문 경우를 제외하면, 그 스크립트는 LLM을 사용하지 않는다.
아이러니하게도, 이 문제를 큰 AI 모델에게 제대로 설명하고 “AI를 어떻게 써서 해결해야 하냐”고 물을 만큼의 선견지명이 있다면, AI는 바로 이 방법을 하라고 말할 것이다.
이 접근은 다른 많은 작업에서 LLM을 사용하는 방식과 미묘하게 다르지만, 컴퓨터가 내 대신 무언가를 하도록 ‘확실히’ 만드는 결과를 얻는 데는 결정적으로 중요하다. LLM은 신뢰성을 제공하지 못하고, 반복 가능성을 제공하지 못한다. 프로그램을 만들면 안정적인 진실의 원천을 가진 결정론적 해법을 반복적으로 개선할 수 있고, 결과로 남는 산출물은 쓸모없을 수도 있지만 실제로 동작한다. 내 경우에는 초당 70개 파일을 변환한다.
또 다른 예시는, 벤자민DEKR(BenjaminDEKR)의 이 트위터 스레드다. 나는 이 글이 bsky에서 조롱받는 걸 보고 접했다. 그는 개인 에이전트에게 우유 사는 걸 상기시켜달라고 했는데, 그 결과 에이전트가 계속해서 오퍼스(Opus)에게 “지금 낮이야?”를 물었다. 하트비트 파일의 컨텍스트까지 포함되면서, 하트비트 한 번당 $0.75가 청구되었고, 하룻밤 자는 동안 거의 $20가 나갔다.
해결책은 무엇일까?
당신의 목적에 맞게 00:00은 밤, 08:00은 낮이라고 정하고 로컬의 기본 gettimeofday 호출로 현재가 어느 구간인지 판단할 수도 있다. 또는 천문학적 의미의 낮/밤이 아니면 만족하지 못하겠다면, NOAA의 (유지보수되지 않는) 태양 계산기를 사용해 연간 일출/일몰 표를 생성하여 낮/밤 구간을 동적으로 만들 수도 있다.
이런 것들은 할 수 있다. 하지만 “LLM에게 물어봐서 문제를 해결하는 것”이 당신의 문제 해결 방식이라면, 이런 일은 하지 못한다. LLM에게 묻는 것이 유일한 해결 방식이라면, 당신이 최적화하는 것은 질문 방식이다. 그래서 하트비트 빈도를 낮추고 더 싼 모델을 쓰는 것으로 최적화한다. 문제 해결!
전반적인 우려는, 마법 상자가 답을 주는 환경이 결국 어떤 문제에 대해서든 사고를 멈추게 만드는(thought-terminating) 해법이 된다는 점이다.
내가 AI의 생태학적 영향을 썼을 때, 생태학적 영향이 아닌 것 중 하나로 “AI가 인간의 기술을 침식한다”는 가능성을 언급했다. Anthropic의 연구 펠로우들이 최근 공개한 “How AI Impacts Skill Formation”는 이런 두려움이 근거 없는 게 아님을 시사한다.
우리는 AI 사용이 개념적 이해, 코드 읽기, 디버깅 능력을 저해하며, 평균적으로 유의미한 효율 향상도 제공하지 못한다는 것을 발견했다.
몇 주 전, 가족 모임에서 아이들 몇 명이 조부모가 여러 번의 명절 동안 못 챙겨준 빨간 봉투들을 잔뜩 처리하는 모습을 보고 있었다. 아이들은 현금을 모두 꺼낸 뒤 총액을 계산해 똑같이 나누려고 했다.
어른들이 더 나은 계산 전략을 생각해보라고 하자, 그중 한 명이 돈을 바닥에 다 뿌리고 사진을 찍어서 ChatGPT에게 합계를 내달라고 하면 된다고 제안했다.
사람들의 본능은 AI에게 일을 ‘대신’ 시키는 것이지, AI로부터 그 일을 ‘하는 법’을 배우는 쪽이 아니다.
비르트의 법칙은 소프트웨어가 하드웨어의 발전으로 얻는 이득을 더 빨리 지워버릴 수 있다고 말하지만, 나는 현실이 그것보다 훨씬 더 나쁘다고 두렵다.
컴퓨터 과학을 공부했다면 바쁜 비버(Busy Beaver) 라는 함수를 들어봤을 수도 있다. 이름은 불행히도 좀 우스꽝스럽지만, 계산 가능성(computability)에서 꽤 중요한 사고 실험이다. BB(N)은 N개의 상태를 가진 종료하는 튜링 머신이 실행할 수 있는 최대 스텝 수로 정의된다.
이 함수는 계산 불가능(noncomputable) 한 것으로 알려져 있는데, 이를 계산할 수 있는 알고리즘이 있다면 정지 문제(halting problem) 를 풀 수 있게 되며, 정지 문제는 결정 불가능(undecidable) 하다고 알려져 있기 때문이다. BB(1..3)은 1960년대에 각각 1, 6, 21로 알려졌다. 댄 루의 실험과 기분 좋은 대칭을 이루는 사실로, BB(4)는 그의 Apple 2e가 만들어진 해와 같은 1983년에 107로 밝혀졌다. 2024년에는 BB(5)가 47,176,870임이 증명되었다.
N이 커질수록 BB는 결국 TREE() 같은 유명한 고속 성장 수열을 포함해, 어떤 계산 가능한 수열보다도 더 빠르게 성장하는 것으로 알려져 있다. BB(6)의 하한은 너무 커서, 상당한 수학적 배경이 없는 사람에게는 그 크기가 얼마나 큰지 설명하는 것 자체가 불가능하다.
소프트웨어는, 올바른 답을 ‘가능한 한’ 자원을 많이 쓰는 방식으로 만들어낼 수 있는 전례 없는 능력을 갖고 있다. 물론 틀린 답을 내거나, 아예 답을 내지 않는 것 또한 선택지다.
비르트의 법칙이 겉보기에는 분명히 참임에도, 엔지니어들은 수십 년간 이에 맞서 적극적으로 싸워왔다. 하지만 LLM과 함께라면, 우리가 전쟁에서 이미 졌을지도 모른다는 걱정이 든다.
나는 단지 프로그래밍의 새로운 민주화를 이해하지 못하는 엔지니어들의 긴 계보에 속한 최신 인물일 뿐일까? 아니면 우리는 “나쁜” 비르트식 트레이드오프, 즉 런타임 복잡성의 성장 곡선이 하드웨어 발전으로는 도저히 다시 파낼 수 없는 구덩이에 들어선 걸까?
2월 2일
jason moiron 작성, 2026
