모델 857건 · 국산 138 · 가격 690 추적 중
MLOps·개발도구

Python GC와 fork가 만나 생기는 Airflow 메모리 버그 해부

NAVER D2·2026-10-08

요약

네이버 D2 기술 블로그가 Apache Airflow를 CeleryExecutor·LocalExecutor로 PoC하는 과정에서 발견한 두 가지 문제를 다뤘다. 하나는 fork로 생성된 worker 프로세스의 메모리가 계속 증가하는 현상이고, 다른 하나는 MySQL 환경에서 dag-processor가 간헐적으로 재시작되는 현상이다. Memray와 weakref.finalize를 활용한 분석 결과, 두 문제 모두 CPython의 순환 참조 가비지 컬렉션(GC)이 fork로 생긴 자식 프로세스에서 부모로부터 물려받은 객체를 건드리면서 발생하는 것으로 확인됐다. 일부 문제는 Airflow 이슈로 보고돼 3.1.2에서 해결됐고, Memray 추적 기능과 관련 문서도 Airflow 코드베이스에 추가됐다.

큐레이터 노트

원문에 없는 맥락입니다

오픈소스 프로젝트에서 증상이 서로 다른 두 버그를 추적해 CPython의 fork·GC 상호작용이라는 공통 원인을 규명하고, 해결 과정을 Airflow 본체에 이슈·기능·문서로 기여까지 이어간 사례다.

깊이 읽기

이 기사 한 건이 아니라, 같은 사안을 다룬 이 사이트의 기록을 근거로 정리했습니다

이 일이 어디서 왔나

2026년 9월 1일 네이버 D2가 공개한 시리즈 1편은 Airflow 2.10.2에서 3.0으로 전환하는 PoC 과정에서 fork 방식이 spawn보다 빨랐지만 Copy-on-Write 한계가 있다고 설명하며 2편에서 실제 문제를 다루겠다고 예고했다. 이번 기사가 그 2편으로, CeleryExecutor·LocalExecutor PoC에서 실제로 드러난 두 가지 증상과 그 공통 원인을 다룬다.

짚어야 할 점

  • 증상은 worker 프로세스 메모리 증가와 MySQL 환경 dag-processor 재시작으로 서로 달랐지만, 둘 다 fork 자식 프로세스에서 CPython 순환 참조 GC가 부모로부터 물려받은 객체를 건드리는 동일한 원인으로 밝혀졌다는 점이 핵심이다.
  • 앞선 보도에서 fork의 장점으로 꼽힌 속도가, 이번에는 Copy-on-Write 특성 때문에 GC 동작이 메모리 증가로 이어지는 단점의 근원이 됐다는 점에서 1편과 2편이 트레이드오프의 양면을 보여준다.
  • Memray와 weakref.finalize로 원인을 추적해 Airflow 이슈 등록, 3.1.2 패치, Memray 추적 기능과 문서 기여까지 이어진 점은 사내 PoC가 오픈소스 본체 개선으로 환류된 사례다.

아직 확인되지 않은 것

  • fork 대신 spawn 방식을 썼다면 이 문제가 원천적으로 발생하지 않았을지, 네이버가 최종적으로 어떤 멀티프로세싱 방식을 채택했는지는 확인되지 않았다.
  • 3.1.2 패치가 성능이나 다른 동작에 부작용을 주는지에 대한 자료는 나오지 않았다.
  • 이 문제가 Airflow 3.x 전반 또는 2.x 버전의 LocalExecutor에도 동일하게 적용되는지는 확인되지 않았다.

이 사안의 흐름

같은 주제를 다룬 이 사이트의 기록 — 최신순

이 글에 나온 말

용어집 전체 →
추적
AI 에이전트나 LLM 애플리케이션이 작업을 처리하는 동안 거치는 호출, 입출력, 지연 시간 등의 실행 경로를 단계별로 기록하고 시각화하는 것을 말한다.

이 분야 브리핑

여러 매체가 함께 다룬 사안을 한 번에

이 페이지는 원문을 요약·재서술하고 이 사이트가 쌓은 기록을 덧붙인 큐레이션입니다. 원문 본문은 싣지 않으며, 수치와 표기는 원문 기준을 유지했습니다.

NAVER D2 원문 전체 보기 →

같은 분야의 다른 소식

전체 뉴스 →