게으름(Laziness)을 잃어버리면 생기는 일 — Bryan Cantrill이 말하는 지연 평가의 중요성

시스템 프로그래밍에서 '게으름'이 사라질 때

Oxide Computer의 공동 창업자이자 DTrace의 아버지로 유명한 Bryan Cantrill이 흥미로운 글을 올렸어요. 제목부터 재밌는데요, "The Peril of Laziness Lost" — 직역하면 "잃어버린 게으름의 위험"이에요. 여기서 말하는 게으름(laziness)은 사람이 게으르다는 뜻이 아니라, 프로그래밍에서 말하는 지연 평가(lazy evaluation) 개념이에요.

지연 평가가 뭐냐면, 어떤 값이나 연산을 "진짜 필요한 순간까지 미루는 것"이에요. 카페에서 메뉴판을 보기만 하고, 실제로 주문은 목마를 때 하는 거랑 비슷해요. 반대 개념은 즉시 평가(eager evaluation)인데, 이건 카페에 들어가자마자 메뉴 전체를 다 주문해버리는 거예요. 당장 마시지도 않을 음료까지요.

왜 게으름이 중요한가

Cantrill이 강조하는 핵심은 이거예요. 시스템 프로그래밍에서 지연 평가는 단순한 최적화 기법이 아니라 설계 철학이라는 거예요. 운영체제나 하드웨어에 가까운 소프트웨어를 만들 때, 모든 걸 미리 계산하고 미리 할당하면 어마어마한 자원 낭비가 생기거든요.

예를 들어볼게요. 운영체제에서 프로세스가 메모리를 요청하면, OS는 실제로 물리 메모리를 바로 할당하지 않아요. 가상 메모리 주소만 먼저 내주고, 프로세스가 그 메모리에 실제로 접근하는 순간에야 물리 메모리를 매핑하죠. 이게 대표적인 lazy 전략이에요. 만약 이걸 eager하게 바꿔서 요청 즉시 물리 메모리를 할당한다면? 수천 개의 프로세스가 돌아가는 서버에서는 메모리가 순식간에 바닥날 거예요.

이런 게으름은 페이지 테이블, 파일 시스템 캐시, 커널의 COW(Copy-on-Write) 등 운영체제 곳곳에 녹아 있어요. COW가 뭐냐면, fork()로 프로세스를 복제할 때 메모리를 통째로 복사하는 게 아니라 "누군가 실제로 수정할 때까지는 같은 메모리를 공유"하는 기법이에요. 이것도 게으름의 한 형태죠.

게으름을 잃어버리는 순간들

Cantrill이 경고하는 건 이런 거예요. 코드를 리팩터링하거나 시스템을 재설계할 때, 기존의 lazy한 동작을 의도치 않게 eager하게 바꿔버리는 일이 생각보다 자주 일어난다는 거예요. 특히 "코드를 깔끔하게 만들자"는 명목 하에 일어나는 경우가 많아요.

누군가 "이 값을 미리 계산해두면 나중에 편하잖아"라고 생각하며 초기화 단계에서 모든 걸 로드하도록 바꾸면, 코드는 읽기 쉬워질 수 있지만 성능은 극적으로 나빠질 수 있어요. 특히 시스템 소프트웨어에서는 이 차이가 "동작함"과 "못 쓸 수준으로 느림" 사이의 차이가 되기도 하거든요.

Rust 같은 언어에서도 이 문제가 나타날 수 있어요. Rust의 소유권 시스템은 안전성을 보장하지만, 때때로 개발자가 borrow checker를 만족시키기 위해 lazy하게 유지하던 계산을 eager하게 바꿔버리는 경우가 있거든요. 컴파일은 되지만, 런타임 특성이 완전히 달라지는 셈이에요.

함수형 프로그래밍과의 연결

지연 평가 하면 Haskell을 빼놓을 수 없죠. Haskell은 언어 자체가 기본적으로 lazy해요. 모든 표현식이 필요할 때까지 평가되지 않거든요. 반면 대부분의 주류 언어(Java, Python, Go, Rust)는 기본이 eager이에요. 그래서 lazy 동작이 필요하면 개발자가 명시적으로 구현해야 하는데, 이 과정에서 실수가 생기거나, 나중에 다른 개발자가 의도를 모르고 바꿔버리는 일이 발생하는 거예요.

Java의 Stream API나 Python의 제너레이터도 lazy 패턴이에요. range(1000000) 대신 제너레이터를 쓰면 백만 개의 숫자를 메모리에 한꺼번에 올리지 않고 하나씩 생성하잖아요. 그런데 누군가 "가독성을 위해" list(generator)로 감싸버리면? 게으름이 사라지는 거예요.

한국 개발자에게 주는 시사점

이건 시스템 프로그래머만의 이야기가 아니에요. 백엔드 개발에서 데이터베이스 쿼리를 lazy하게 할 건지 eager하게 할 건지(ORM의 lazy loading vs eager loading), 프론트엔드에서 컴포넌트를 lazy하게 로드할 건지(React.lazy, dynamic import)는 매일 마주치는 설계 결정이에요.

특히 코드 리뷰할 때 이 관점을 가져보면 좋겠어요. "이 변경이 기존의 lazy한 동작을 eager로 바꾸는 건 아닌가?" 이 질문 하나만으로도 성능 문제를 사전에 잡을 수 있거든요.