[연재] 전투 한 번에 메모리 30GB를 썼습니다 — 맥미니가 멈춘 날
10시 51분, 화면이 멈췄습니다
2026년 10월 8일 오전 10시 51분, 맥미니가 멈췄다가 저절로 다시 켜졌습니다. 커널 패닉이라고 부르는 것인데, 운영체제가 스스로 못 버티겠다고 판단해 껐다는 뜻이에요. 지도 계산을 돌리던 중이었습니다.
그날 오후는 통째로 못 썼습니다. 올리기로 한 쇼츠도 하나도 못 올렸고요. 계산이 날아간 것보다, 한나절이 사라졌다는 게 더 컸습니다.
패닉 기록을 열어 보면 두 줄이 눈에 띕니다. 하나는 「watchdogd 가 93초 동안 신호를 못 보냈다」, 시스템이 살아 있는지 확인하는 감시 프로세스가 93초 동안 응답을 못 했다는 말이에요. 다른 하나는 메모리 압축 공간이 100%이고, 스왑 파일이 26개까지 늘었는데도 여유가 없다는 줄입니다. 쉽게 말해 메모리가 바닥나자 맥이 디스크를 메모리 대신 쓰기 시작했고, 그 디스크마저 바닥나서 멈춘 겁니다.
범인은 파이썬 네 개였습니다
패닉 기록에는 그 순간 어떤 프로세스가 메모리를 얼마나 쓰고 있었는지도 남아 있습니다. 가장 큰 것부터 9.35GB, 8.5GB, 7.08GB, 6.67GB. 전부 파이썬이었고, 합치면 31.6GB였어요. 그다음으로 큰 크롬이 1.2GB였으니 비교도 안 되는 크기입니다.
이 맥미니의 메모리는 16GB입니다. 16GB짜리 기계에 31.6GB를 요구한 거예요. 맥이 멈추는 게 이상한 일이 아니었습니다.
패닉 기록에 남은 프로세스별 메모리. 파이썬 네 개를 더하면 31.6GB로, 맥이 가진 16GB의 거의 두 배입니다.
처음 짚은 원인은 틀렸습니다
제일 먼저 의심한 건 경로 계산이었습니다. 3편에서 말씀드린 지형 높이로 길을 찾는 단계요. 이 계산이 프로세스를 둘씩 띄우는데, 삼국지와 초한지 지도를 동시에 돌렸으니 정확히 2개씩 두 쌍, 모두 4개였습니다. 숫자가 딱 맞아떨어졌어요. 경로 결과 파일이 10시 36분과 41분까지 써진 걸 확인하고 10여 분 뒤에 패닉이 났다는 시각까지 맞췄습니다. 그래서 「프로세스 하나가 7~9GB씩 먹은 것」이라고 정리했어요.
반쯤은 맞고 반쯤은 틀렸습니다. 경로 계산 자체는 0.5GB도 쓰지 않았어요. 메모리를 먹은 건 같은 프로그램 안에서 이어서 돌던 다른 단계, 3편에서 본 고도 단면을 그리는 단계(build_profile)였습니다.
이 단계는 전투 지역의 지형 자료를 통째로 메모리에 올려놓고 계산합니다. 전투 하나에 3~3.6GB, 땅이 넓은 요동 전투는 약 30GB를 쓸 것으로 추산됩니다. 30GB는 측정한 값이 아니라 지형 크기로 계산한 추산이에요. 제가 처음 짚은 건 숫자가 맞는 다른 범인이었고, 측정하고 나서야 진짜 범인이 나왔습니다.
요동 공손연 토벌(238년)의 고도 단면. 전투 지역이 요동에서 낙양 근처까지 길게 이어져, 단면 계산에 필요한 지형 자료가 가장 큽니다.
나는 CPU만 막았습니다
사실 그 전에도 조심한다고는 했습니다. 무거운 계산을 돌릴 때는 우선순위를 낮추고 코어를 2개로 제한해 뒀거든요. 맥을 쓰는 사람의 손이 느려지지 않게요.
그런데 그건 CPU를 막는 장치입니다. 메모리는 막지 않아요. CPU를 2코어로 제한해도 프로세스 하나가 기억 장치 20GB를 쓰는 건 얼마든지 가능합니다. 저는 컴퓨터가 느려지는 것만 걱정하고 있었고, 컴퓨터가 멈추는 건 걱정하지 않고 있었어요.
계산에는 메모리 한도가 없었습니다. 한도가 없으면, 일이 커진 날 어디까지 커질지 아무도 모릅니다.
잃은 것
잃은 건 오후 한나절과 올리려던 쇼츠였습니다. 저녁까지 이어서 한 일은 원인을 찾고 고치는 것이었어요. 같은 일이 또 나지 않게 하는 방법은 둘이었습니다. 터지기 전에 끊는 감시자를 두는 것, 그리고 애초에 30GB씩 안 쓰게 계산 방식을 바꾸는 것. 다음 글에서 둘 다 이야기합니다.
오늘 해 보실 한 가지가 있습니다. AI에게 오래 걸리는 계산을 시키기 전에 「이 작업이 메모리를 최대 얼마나 쓰고, 동시에 몇 개가 돌지」를 먼저 물어보세요. 모른다고 하면 그게 위험 신호입니다.
삼국지 아틀라스는 여기서 볼 수 있습니다: https://victor-house.com/sanguo/