libc 없이 리눅스 위에서 홀로 돌아가는 Lisp, 그 심장 '힙'을 들여다보다

'libc 없이 돌아가는 언어'라는 발상

우리가 C로 프로그램을 짜면 당연하다는 듯 printf나 malloc을 씁니다. 이게 다 libc, 즉 C 표준 라이브러리가 우리와 운영체제 사이에서 다리를 놔주기 때문이에요. 메모리를 달라고 하면 알아서 받아다 주고, 화면에 출력하라면 알아서 처리해주죠. 그런데 만약 이 다리를 통째로 걷어내면 어떻게 될까요? 메모리 할당도, 입출력도 전부 운영체제의 시스템 콜(syscall)을 직접 두드려야 합니다. 이렇게 표준 라이브러리 없이 맨몸으로 도는 걸 "freestanding(독립형)"이라고 불러요.

lone은 바로 그런 Lisp 인터프리터예요. libc에 의존하지 않고 리눅스 커널 위에서 직접 돌아가도록 만들어진, 말 그대로 "홀로 선(lone)" Lisp이죠. 이번 글은 그중에서도 가장 핵심인 메모리 관리, 즉 힙(heap) 이야기입니다.

힙이 뭐고, 왜 직접 만들어야 하나

힙이 뭐냐면, 프로그램이 실행 중에 "필요할 때마다 빌려 쓰는 메모리 창고"예요. 평소엔 malloc이 이 창고를 알아서 관리해주는데, lone은 libc가 없으니 malloc도 없어요. 그래서 직접 커널에게 메모리를 달라고 해야 합니다. 보통 mmap이라는 시스템 콜로 커널에서 큰 메모리 덩어리를 통째로 받아온 다음, 그 안을 자기가 알아서 잘게 쪼개 쓰는 거예요.

Lisp은 특히 이게 중요해요. Lisp 프로그램은 cons cell이라는 자그마한 객체(값 두 개를 묶은 칸)를 어마어마하게 많이 만들거든요. 매번 커널을 부르면 너무 느리니까, 큰 땅을 한 번에 받아두고 그 위에서 작은 칸들을 빠르게 나눠주는 자체 할당기(allocator)를 짜는 거죠. lone의 힙은 바로 이 "내가 받은 땅을 내가 관리한다"는 구조예요.

가비지 컬렉션 — 안 쓰는 메모리를 자동으로 치우기

Lisp 하면 떠오르는 게 가비지 컬렉션(GC), 즉 쓰레기 메모리 자동 수거죠. 객체를 잔뜩 만들다 보면 더 이상 아무도 안 쓰는 메모리가 생기는데, 이걸 그냥 두면 창고가 꽉 차버려요. 가장 고전적인 방법이 "mark-and-sweep(표시하고 쓸어담기)"인데, 이게 뭐냐면 먼저 지금도 쓰이는(어딘가에서 참조되는) 객체에 표시를 해두고(mark), 그다음 표시 안 된 것들을 싹 쓸어서 회수하는(sweep) 방식이에요. lone도 이렇게 자기 힙 위에서 직접 GC를 돌려, 안 쓰는 칸을 다시 빈 칸으로 만들어 재활용합니다. libc도 없는 환경에서 이걸 손수 구현했다는 게 이 프로젝트의 묘미예요.

업계 맥락 — freestanding의 매력

이런 "표준 라이브러리 없이 맨바닥에서" 정신은 운영체제 커널을 짜거나, 러스트의 no_std 환경에서 임베디드 코드를 짤 때와 결이 같아요. 굳이 왜 이 고생을 하느냐면 이유가 분명합니다. 의존성이 사라지니 바이너리가 아주 작아지고, 어디든 정적으로 들고 다니기 좋아지고요. 외부 코드가 없으니 공격 표면(보안 취약점이 숨을 곳)도 줄어들죠. 무엇보다 평소 라이브러리가 가려주던 밑바닥을 직접 마주하면서 컴퓨터가 실제로 어떻게 돌아가는지를 배우는 교육적 가치가 큽니다.

한국 개발자에게

대부분은 libc 없는 세계를 직접 만질 일이 없어요. 그래도 이런 글을 읽으면, 평소 무심코 쓰던 malloc 한 줄이 사실 얼마나 복잡한 일을 대신해주고 있었는지 체감하게 됩니다. 메모리 할당, GC, 시스템 콜의 밑바닥 원리를 한 번 이해해두면 어떤 고수준 언어를 쓰든 메모리 누수 디버깅이나 성능 튜닝을 할 때 자신감이 확 달라져요. 당장 써먹는 기술은 아니어도, '내 도구의 바닥'을 들여다보는 경험으로는 최고급 교재인 셈이죠.

마무리

한 줄 정리 — malloc과 GC는 마법이 아니라 누군가 손으로 짜둔 코드일 뿐이고, 그 바닥을 들여다보면 언어를 보는 눈이 달라진다. 여러분은 평소 쓰는 언어의 메모리 관리가 내부에서 어떻게 돌아가는지 들여다본 적 있으세요? 가장 '마법처럼' 느껴지는 부분은 어디인가요?