저는 잔류하는 이벤트 리스너(event listeners)로 인해 발생한 Node.js API 게이트웨이의 느리고 교활한 메모리 누수(memory leak)를 발견했습니다. 요청별로 에미터(emitters)의 범위를 지정하고, finally 블록에서 정리를 강제하며, 누수 인지 테스트(leak-aware tests)와 런타임 보호 장치를 추가함으로써 이를 해결했습니다. 그 결과 메모리 사용량이 평탄해졌고 OOM(Out Of Memory)으로 인한 재시작이 중단되었습니다.

사건 발생 (The Incident)

해당 게이트웨이는 많은 마이크로서비스(microservices)를 위해 TLS 종료(termination), 인증(auth), 그리고 요청 팬아웃(request fan-out)을 처리했습니다. 몇 주에 걸쳐 상주 집합 크기(resident set size, RSS)가 계단식 패턴으로 상승했고, 결국 부하가 걸린 상태에서 Kubernetes가 포드(pods)를 OOM-kill 하기 시작했습니다. 이 장애는 _점진적_이었습니다. 트래픽이 적을 때는 며칠 동안 작동했지만, 피크 트래픽 시에는 몇 시간 만에 충돌이 발생했기에 일상적인 모니터링을 피할 수 있었습니다.

조사 (Investigation)

힙 스냅샷(Heap snapshots)과 할당 프로파일(allocation profiles)을 분석한 결과, 하나의 거대한 할당보다는 작은 객체들(small objects)—클로저(closures), 요청 메타데이터(request metadata), 그리고 이벤트 리스너(event listeners)—의 개수가 증가하고 있음을 확인했습니다. 추적 결과, 요청 범위의 리스너(request-scoped listeners)가 부착되었으나 항상 제거되지는 않는 내부 이벤트 버스(event bus)가 발견되었습니다. 즉, 조기 종료되는 인증 경로(early-exit authentication path)가 정리 함수(cleanup function)가 실행되기 전에 반환되어, 요청 상태(request state)에 대한 참조를 유지하는 리스너들을 남겨두었습니다. 가비지 컬렉터(GC)는 해당 객체들을 살아있는(live) 것으로 간주하여 결코 회수하지 않았습니다.

해결 방법 (기술적 세부 사항) (The Fix (technical details))

1. 요청별 스코프가 지정된 에미터 (Scoped emitters per request). 요청 로컬(request-local) 관심사를 처리하기 위해 전역 에미터(global emitters)를 사용하는 대신, 요청 시작 시 생성되는 수명이 짧은 EventEmitter로 교체했습니다. 요청이 종료되면 에미터는 스코프(scope)를 벗어나게 되며, 전체 클로저 그래프(closure graph)가 가비지 컬렉션(collectible) 대상이 됩니다.

2. try/finally를 통한 확실한 정리 (Guaranteed teardown via try/finally). 전체 요청 파이프라인(request pipeline)을 감싸서 성공, 에러 또는 조기 반환(early return) 시에도 정리 작업이 실행되도록 했습니다. finally 블록은 남아있는 모든 리스너(listeners)를 분리하고, 타이머(timers)를 제거하며, 캐시(caches)를 해제합니다.

3. 누수 인지형 CI 테스트 및 런타임 메트릭 (Leak-aware CI tests and runtime metrics). 테스트 하네스(harness)를 통해 코드 경로 전반에 걸쳐 수천 개의 요청을 시뮬레이션하고, 힙 스냅샷(heap snapshots)을 캡처하며, 객체 수가 제한된 범위 내에 있는지 확인(assert)했습니다. 프로덕션 메트릭(Production metrics)은 리스너 수를 추적하고 임계값이 초과되면 경고(alerts)를 발생시켰습니다.

4. 운영상의 안전장치 (Operational safeguards). 수락 큐(accept queues)에 백프레셔(backpressure)를 추가하고, 비필수적인 트레이싱(tracing)을 비활성화하는 소프트 메모리 임계값(soft memory threshold)을 설정했으며, 과도한 크래시 루프(crash loops) 발생 시 롤아웃(rollout)을 중단하는 기능을 추가했습니다.

이러한 변경 사항은 수동 정리를 구조적 보장으로 전환하여, 누수를 유발했던 인적 오류(human-error) 경로를 제거했습니다. 메모리 그래프는 평탄해졌고, 포드(pod) 재시작은 중단되었으며, 오토스케일링(autoscaling)은 버그를 가리는 대신 부하를 처리하는 본연의 역할로 돌아갔습니다.

AI 내구성: 중요한 결함들 (AI endurance: the glitches that matter)

장기 운영되는 AI 시스템은 다른 방식으로 실패합니다. **행동 드리프트 (behavioral drift), 적대적 입력 (adversarial inputs), 그리고 오케스트레이션 리소스 누수 (orchestration resource leaks)**는 즉각적인 충돌보다는 내구성(endurance)을 위협하는 요소들입니다. 모델 자체에서 발생하는 실패(성능 저하, 편향, 환각)와 외부에서 유도된 실패(적대적 공격, 데이터 오염)는 서로 다른 대응 지침(playbook)을 필요로 하지만, 기업들은 종종 AI 특화 사고 대응 능력이 부족합니다. CSO Online

적대적 머신러닝 (Adversarial machine learning)은 회피 (evasion), 오염 (poisoning), 추출 (extraction) 공격과 이에 대응하는 적대적 학습 (adversarial training) 및 이상 탐지 (anomaly detection)와 같은 방어 기법을 기록하는 광범위하고 활발한 분야로 남아 있습니다. 강건성 (Robustness) 연구는 스트레스 테스트, 위협 모델링, 지속적인 평가와 같은 라이프사이클 규율을 강조합니다. IEEE Xplore ScienceDirect ijisrt.com

운영 측면에서는, 오케스트레이션에서의 리소스 누수 (세션 상태, 벡터 저장소, 로그)가 AI 서비스를 조용히 저하시킬 수 있습니다. 내구성을 위해서는 입력 분포 (input distributions) 모니터링과 다차원 평가 (multi-dimensional evaluation)가 필수적입니다. sustainablecatalyst.com

핵심 요약 (Takeaways)

자동 정리를 설계하고, 해제 (teardown)를 강제하며, CI에서 누수 테스트를 수행하십시오. AI의 경우, 내구성을 설계 목표로 취급해야 합니다. 즉, 분포를 모니터링하고, 적대적 테스트 및 드리프트 테스트를 실행하며, 오케스트레이션 리소스를 관리하십시오. 메모리 누수는 작고 보이지 않는 실패가 누적된다는 것을 가르쳐 주었습니다. 진정한 승리는 실패할 때 명확하게 신호를 보내고, 빠르게 복구하며, 사고 이후에 진화하는 시스템을 구축하는 것입니다.