22년 전 리눅스 메일링리스트의 OOM 킬러 토론, 지금도 유효한 이유

가끔 옛날 리눅스 커널 토론을 읽다 보면 시간이 멈춘 듯한 묘한 재미가 있어요. 2004년 LWN에 올라온 "OOM_pardon, a.k.a. don't kill my xlock" 패치 토론도 그런 사례인데, 지금 다시 봐도 메모리 관리라는 주제가 얼마나 까다로운지 잘 보여주는 좋은 교재예요.

OOM 킬러가 뭐예요?

먼저 배경부터 짚을게요. 리눅스는 좀 특이한 메모리 정책을 써요. 메모리를 할당해달라는 요청을 받으면 "있어요!" 하고 일단 약속해주거든요. 실제로 그 메모리가 다 있는지는 확인 안 해요. 이게 오버커밋(overcommit)이에요. 비유하자면 항공사가 좌석 200개짜리 비행기에 220장 표를 파는 거랑 비슷해요. 어차피 다 안 올 거니까 더 많이 팔아도 보통은 문제가 없는 거죠.

그런데 진짜로 다 와버리면 어떡해요? 리눅스는 이때 OOM 킬러(Out-Of-Memory Killer)라는 녀석을 호출해요. 가장 메모리를 많이 쓰는 것 같고, 가장 죽여도 덜 아플 것 같은 프로세스를 찾아내서 강제로 종료시켜요. 시스템 전체가 멈추는 것보다는 한 프로세스가 죽는 게 낫다는 판단이죠. 누구를 죽일지는 휴리스틱 스코어로 계산해요. 메모리 사용량, 실행 시간, 우선순위 등을 종합해서요.

그런데 왜 내 xlock이 죽어요?

xlock은 리눅스 화면잠금 프로그램이에요. 잠깐 자리를 비울 때 화면 잠그는 그거요. 문제는 OOM 킬러가 이 xlock을 죽여버리는 일이 자주 있었던 거예요.

자리 비운 사이에 무슨 일이 일어났는지 한 번 상상해보세요. 무거운 컴파일 돌리고 왔는데 메모리가 터지면서 화면 잠금이 풀려있는 거예요. 보안 측면에서 끔찍한 일이죠. xlock 입장에선 메모리를 많이 쓰지도 않는데 "스코어 계산" 알고리즘이 자기를 찍어버리니까 억울할 따름이고요. 패치 제목에 들어간 "don't kill my xlock" 이라는 말에 당시 개발자들의 짜증이 그대로 묻어나요.

패치의 핵심 아이디어

Andrea Arcangeli 등 커널 개발자들이 토론한 해법은 "사용자가 직접 보호하고 싶은 프로세스를 표시할 수 있게 해주자"는 거였어요. 지금 우리가 쓰는 /proc/<pid>/oom_score_adj 인터페이스의 원형이 이 시기 토론에서 다듬어진 거예요. 음수 값을 주면 OOM 킬러가 그 프로세스를 마지막에 죽이려고 하고, 양수 값을 주면 우선적으로 죽이려고 해요. 범위는 -1000부터 1000까지고요.

물론 토론은 단순하지 않았어요. "그러면 모든 사람이 자기 프로세스를 절대 죽지 않게 설정해버리면 어떡하나", "근본적으로 오버커밋을 끄는 게 맞지 않나", "휴리스틱을 개선하는 게 먼저다" 같은 다양한 주장이 오갔어요. 결국 합의는 "기본 정책은 그대로 두되, 명시적으로 우선순위를 조정할 수 있는 노브를 추가하자"였고요. 이게 좋은 시스템 설계의 한 패턴이에요. 정책은 단순하게 두고, 예외를 위한 정직한 노브를 따로 제공하는 거죠.

지금도 살아있는 이슈

22년이 지난 지금도 OOM 킬러는 컨테이너 시대에 다시 골칫거리가 됐어요. 쿠버네티스에서 Pod이 갑자기 죽는 이유를 추적하다 보면 결국 OOM 킬러가 범인인 경우가 많거든요. cgroup v2에서는 메모리 한계가 컨테이너마다 따로 걸리니까, 컨테이너 안의 프로세스 하나가 OOM에 걸리면 그 컨테이너가 통째로 재시작되는 식이죠.

요즘은 그래서 systemd-oomd, earlyoom 같은 사용자 공간 OOM 데몬도 나왔어요. 커널이 OOM 상황까지 가기 전에 메모리 압박이 심해지면 미리 개입해서 덜 중요한 프로세스를 정리하는 방식이에요. 옛날엔 커널이 모든 걸 알아서 하던 게, 이제는 사용자 공간이 더 똑똑하게 정책을 결정하는 쪽으로 흐름이 옮겨갔다고 볼 수 있죠.

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

서버 운영하시는 분이라면 한 번쯤 dmesg | grep -i oom 명령으로 자기 서버에서 OOM 킬러가 누굴 죽였는지 확인해보세요. 그리고 정말 중요한 프로세스가 있다면 oom_score_adj로 보호해두는 것도 좋아요. 데이터베이스, 메시지 큐 같은 핵심 인프라는 절대 OOM에 당하면 안 되거든요.

또 한 가지, 옛날 메일링리스트 토론을 읽는 건 그 자체로 좋은 공부예요. 지금 우리가 당연하게 쓰는 기능들이 어떤 고민과 논쟁 끝에 만들어졌는지 보면, 시스템 설계의 트레이드오프를 자연스럽게 익힐 수 있어요. "왜 이렇게 만들었지?" 라는 질문에 대한 답이 거기 다 있거든요.

정리

OOM 킬러는 "메모리가 부족할 때 누구를 희생시킬 것인가"라는 어려운 질문에 대한 리눅스의 답이에요. 완벽한 답은 없고, 22년이 지난 지금도 여전히 개선되고 있고요.

여러분은 서비스 운영하면서 OOM에 한 번이라도 시달려보셨나요? 어떻게 해결하셨는지 댓글로 공유해주시면 다른 분들한테도 도움이 될 거예요.