[260709] 몇 일째 미스터리였던 새벽 크래시의 진짜 범인을 찾았다

메모리 문제의 진짜 원인을 찾아 고치는 김에, 프로덕션을 실수로 죽여버리기도 한 하루

오늘은 몇 주간 미궁이었던 문제 하나를 드디어 근본 원인까지 찾아 고쳤습니다. 다만 그 과정에서 실수도 두 건 겪었습니다.

몇 일째 미스터리였던 새벽 크래시, 진짜 범인을 찾았다

얼마 전부터 매일 새벽 특정 시각마다 개발 환경이 죽는 문제가 있었습니다(그래서 핵심 프로세스들을 개발 환경과 분리된 별도 서비스로 옮겨두기도 했었는데, 이건 증상 완화였지 원인 해결은 아니었습니다). 오늘 다른 AI와 함께 로그를 더 깊이 파본 끝에 드디어 진짜 원인을 찾았습니다.

무거운 데이터 계산을 하는 라이브러리가 다 쓴 메모리를 파이썬 코드 상으로는 분명히 반납했는데, 운영체제 입장에서는 그 메모리가 실제로 회수가 안 되고 있었습니다(메모리 파편화라고 부르는 현상입니다). 이게 매일 반복되면서 조금씩 쌓여 결국 시스템이 메모리 부족으로 새벽에 죽었던 것이었습니다. 게다가 파다 보니 부수적인 문제도 하나 더 나왔는데, 하루에 한 번만 필요한 계산을 하루에도 여러 번 아무 이유 없이 반복하고 있었다는 것도 드러났습니다.

세 가지를 고쳤습니다 — 이미 계산해둔 결과가 있으면 절대 다시 계산하지 않고 캐시만 읽게 하고, 무거운 계산이 끝나면 메모리를 명시적으로 강제 반납하도록 하고, 날짜가 안 바뀌었으면 계산 자체를 건너뛰게 했습니다. 수정 전후로 메모리 사용량을 실측해봤는데, 한 프로세스는 사용량이 20배 넘게 줄었습니다. 몇 주간 "일단 껐다 켜면 낫는다" 수준으로 덮어두고 있던 문제를 제대로 잡은 셈입니다.

실수 1: 절대 끊으면 안 되는 프로세스를 정확히 그렇게 끊어버림

위 수정을 배포하려고 관련 서비스를 재시작했는데, 하필 그 순간에 매일 밤 도는 핵심 분석 작업이 한창 진행 중이었습니다. 코드 안에 "이 작업은 최우선이고 어떤 이유로도 끊지 않는다"고 스스로 적어놓기까지 했는데, 정작 배포하면서 그 원칙을 정면으로 어긴 셈입니다. 다행히 몇 분 뒤 자동으로 재개되는 안전장치가 있어서 큰 손실은 없었지만, 배포 타이밍 자체를 더 신경 써야 한다는 걸 다시 배웠습니다.

실수 2: "쉬고 있음"과 "잠깐 멈춤"을 못 구분한 자동화

다른 작업을 하나 고치려고 분석 작업을 잠깐 몇 분간 일시정지시켰는데, 그 틈을 타서 "지금 아무것도 안 돌고 있으니 지금이 기회"라고 판단하는 자동화 하나가 발화해서 GPU를 크게 쓰는 별도 작업을 시작해버렸습니다. 잠깐 뒤 분석 작업이 재개되면서 둘이 같은 GPU 자원을 두고 부딪혔고, 결국 하나를 정리해야 했습니다. "지금 안 돌고 있다"와 "오늘 할 일을 다 끝냈다"는 다른 판단 기준이라는 걸 놓친 게 원인이었습니다.

그 밖에

• 증권사 시세 조회 API를 종목 하나당 여러 번(최대 6번까지) 중복으로 부르고 있던 것도 발견해서, 한 번만 부르고 재사용하도록 캐시를 추가했습니다. 그동안 API 요청 제한에 종종 걸렸던 원인 중 하나였습니다.
• 예전에 로컬 모델이 "자기 학습 마감 시점 이후의 진짜 뉴스는 지어낸 이야기다"라고 오판했던 적이 있었는데, 오늘은 다른 모델의 결과물을 검증하는 역할을 맡긴 모델에서도 똑같은 함정을 겪었습니다. 실제로 있었던 최신 뉴스를, 검증 담당 모델이 "이건 실재하지 않는다"고 자신 있게 판정했는데, 확인해보니 진짜였습니다. 검증을 맡기는 모델이라고 이 함정에서 자유롭지 않다는 걸 알게 된 셈이라, 앞으로는 사실관계 판정은 어떤 모델 말도 그대로 안 믿고 직접 찾아보기로 했습니다.
• 새로운 확장 아이디어 하나를 페이퍼(모의) 트랙으로 더 추가해서, 계속 실거래 리스크 없이 검증 중입니다.

---

오늘 두 실수 다 심각한 피해로 이어지진 않았지만, 몇 주짜리 미스터리를 잡은 날 바로 새 실수 두 개를 만든 게 좀 아이러니했습니다. 배포/자동화를 다룰 땐 "지금 뭐가 돌고 있는지"를 항상 먼저 확인해야 한다는 교훈을 이렇게 두 번이나 다시 배웠습니다.