공공데이터포털(data.go.kr)이나 지자체, 공공기관 시스템과 연동하는 백엔드 시스템에서는 전국 단위의 사업자 등록 내역, 건축물대장, 병의원 및 약국 인허가 정보, 부동산 실거래가 등의 대용량 데이터셋을 정기적으로 수집하여 데이터베이스에 동기화하는 ETL(Extract, Transform, Load) 파이프라인을 운영합니다.
이러한 공공데이터는 단일 XML 또는 JSON 파일의 크기가 적게는 수백 메가바이트(MB)에서 많게는 수 기가바이트(GB)에 달하는 경우가 흔합니다. 초기 개발 시 xml.etree.ElementTree.parse()나 json.load() 같은 표준 라이브러리 함수를 사용하여 파일을 한 번에 메모리로 읽어 들이면, 로컬 테스트에서는 정상 동작하던 파이프라인이 컨테이너(Docker/Kubernetes) 배포 환경에서 OOM(Out of Memory, OOMKilled)으로 강제 종료되는 장애가 빈번히 발생합니다.
본 글에서는 대용량 XML/JSON 파싱 시 메모리가 폭증하는 근본적인 원인을 살펴보고, 이벤트 기반 스트리밍 파서(iterparse, ijson)와 Python 제너레이터(Generator)를 결합하여 수 기가바이트의 데이터도 일정한 메모리(50MB 이하)로 안전하게 처리하는 아키텍처 설계법을 체계적으로 분석합니다.
1. 대용량 문서 파싱 시 메모리 고갈(OOM)의 근본 원인
파일 크기가 250MB인 XML 파일을 ElementTree.parse()로 파싱할 때, 파이썬 프로세스가 소비하는 메모리는 단순히 250MB에 그치지 않습니다. 실제 메모리 프로파일링을 수행해 보면 파일 크기의 6배에서 10배에 달하는 1.8GB ~ 2.5GB 이상의 메모리를 순간적으로 점유하게 됩니다.
- 인메모리 DOM(Document Object Model) 트리 구축: 표준 파서는 문서의 부모-자식-형제 관계를 모두 메모리에 보관하는 완전한 트리 구조를 생성합니다.
- 파이썬 객체(PyObject) 오버헤드: C 언어의 원시 문자열과 달리 파이썬의 모든 데이터는 타입 정보, 참조 카운트(Reference Count), 속성 딕셔너리 등을 포함하는 무거운 객체입니다. 수백만 개의 태그와 속성이 각각 별도의
Element객체로 인스턴스화되면서 메모리 사용량이 기하급수적으로 팽창합니다. - 컨테이너 Cgroup 메모리 제한 트리거: 마이크로서비스 환경에서 워커 컨테이너의 메모리 리밋이 통상 512MB~1GB 수준으로 설정되어 있다면, 리눅스 커널의 OOM Killer가 즉시 프로세스를 강제 종료(SIGKILL)시킵니다.
2. XML 스트리밍 파싱: iterparse와 메모리 클리어링 패턴
XML 문서를 메모리에 전부 올리지 않고 처리하는 정석적인 기법은 SAX(Simple API for XML) 방식의 이벤트 기반 파서인 xml.etree.ElementTree.iterparse를 사용하는 것입니다. 그러나 단순히 iterparse를 호출하는 것만으로는 메모리 누수를 막을 수 없습니다.
iterparse는 순회 중에도 루트 노드(Root Node)로부터 하위 노드로 이어지는 참조를 계속 유지하기 때문에, 파싱이 진행될수록 메모리 사용량이 지속해서 증가합니다. 따라서 처리가 완료된 자식 노드는 명시적으로 참조를 제거(clear)해야 가비지 컬렉터(Garbage Collector)가 메모리를 즉시 회수할 수 있습니다.
import xml.etree.ElementTree as ET
from typing import Generator, Dict, Any
def stream_public_xml_records(file_path: str, target_tag: str = "item") -> Generator[Dict[str, Any], None, None]:
"""
대용량 XML 파일을 스트리밍 방식으로 읽어 지정된 태그 단위의 딕셔너리를 반환합니다.
메모리 누수를 방지하기 위해 처리가 끝난 요소는 트리에서 즉시 제거합니다.
"""
# end 이벤트만 감지하여 닫는 태그 시점에 완전한 요소 객체를 획득
context = ET.iterparse(file_path, events=("start", "end"))
_, root = next(context) # 루트 요소 획득
for event, elem in context:
if event == "end" and elem.tag == target_tag:
# 1. 대상 태그의 하위 텍스트 데이터를 딕셔너리로 추출
record = {child.tag: (child.text or "").strip() for child in elem}
yield record
# 2. 핵심 메모리 해제: 처리된 노드의 내부 데이터 및 루트 참조 정리
elem.clear()
root.clear()
3. JSON 스트리밍 파싱: ijson 라이브러리의 반복자 패턴
최근 공공데이터 API는 XML 외에도 대용량 JSON 포맷을 널리 지원합니다. 최상위 루트가 수십만 개의 객체를 담은 대형 배열(Array)인 경우, ijson 라이브러리를 사용하면 파일 전체를 메모리로 역직렬화하지 않고 이터레이터(Iterator) 방식으로 단일 레코드씩 스트리밍할 수 있습니다.
import ijson
from typing import Generator, Dict, Any
def stream_public_json_records(file_path: str, array_prefix: str = "data.item") -> Generator[Dict[str, Any], None, None]:
"""
대용량 JSON 파일에서 특정 경로의 배열 요소를 스트리밍 방식으로 순회합니다.
(예: {"response": {"body": {"items": [ ... ]}}} 구조에서 items.item 경로 추적)
"""
with open(file_path, "rb") as f:
# ijson.items는 C 백엔드(YAJL) 또는 순수 파이썬 파서를 통해 버퍼 단위로 파싱
objects = ijson.items(f, f"{array_prefix}")
for record in objects:
yield record
4. 제너레이터 기반 청크 벌크 적재 파이프라인
스트리밍 파서가 방출(yield)하는 개별 레코드를 1건씩 데이터베이스에 INSERT하면 수만 번의 네트워크 라운드트립으로 인해 극심한 지연이 발생합니다. 반대로 모든 레코드를 하나의 리스트로 취합하면 다시 메모리 고갈 문제가 재발합니다.
가장 효율적인 해결책은 제너레이터를 결합하여 일정 크기(예: 1,000건)의 청크(Chunk) 단위로 묶어 벌크 적재(Bulk Insert)하는 파이프라인을 구축하는 것입니다.
from itertools import islice
from typing import Generator, List, Dict, Any
from sqlalchemy.orm import Session
from sqlalchemy import insert
def chunked_generator(iterable: Generator, chunk_size: int = 1000) -> Generator[List[Dict[str, Any]], None, None]:
"""
스트리밍 제너레이터로부터 데이터를 받아 지정된 chunk_size 단위의 배치 리스트를 방출합니다.
"""
iterator = iter(iterable)
while True:
chunk = list(islice(iterator, chunk_size))
if not chunk:
break
yield chunk
def execute_bulk_etl_pipeline(db_session: Session, xml_file_path: str, target_model):
"""
대용량 XML 파싱부터 청크 분할 및 DB 벌크 적재까지의 엔드투엔드 파이프라인
"""
raw_stream = stream_public_xml_records(xml_file_path, target_tag="item")
chunk_stream = chunked_generator(raw_stream, chunk_size=2000)
total_inserted = 0
for chunk in chunk_stream:
# 데이터베이스 벌크 인서트 실행 (트랜잭션 단위 제어)
db_session.execute(
insert(target_model),
chunk
)
db_session.commit()
total_inserted += len(chunk)
return total_inserted
5. 메모리 프로파일링(tracemalloc) 벤치마크 비교
실제 250MB 크기의 전국 공공데이터 XML 파일(약 45만 건의 레코드)을 대상으로 파이썬 3.11 환경에서 tracemalloc을 사용하여 메모리 사용량과 수행 시간을 측정한 결과입니다.
| 파싱 방식 | 피크 메모리(Peak RAM) | 소요 시간 | 컨테이너 안정성 |
|---|---|---|---|
| 기본 ElementTree.parse() | 약 2,150 MB (2.1 GB) | 약 18.2 초 | 위험 (512M/1G 환경 OOM Crash) |
| iterparse (clear 미호출) | 약 1,890 MB (1.8 GB) | 약 17.5 초 | 위험 (루트 노드 참조 누적) |
| iterparse + elem.clear() 스트리밍 | 약 38 MB | 약 14.8 초 | 완전 안정 (Flat Memory Profile) |
| ijson JSON 스트리밍 | 약 42 MB | 약 19.3 초 | 완전 안정 (Flat Memory Profile) |
측정 결과에서 알 수 있듯이, elem.clear()와 root.clear()를 결합한 스트리밍 파서는 메모리 피크를 기존 대비 98% 이상 절감하여 38MB 수준으로 플랫하게 유지합니다. 데이터 파일의 크기가 10GB로 커지더라도 메모리 소비량은 늘어나지 않고 일정한 한도 내에서 수렴합니다.
6. 실무 엔지니어링 체크리스트
- HTTP 응답 스트림 직접 연결: 대용량 파일을 디스크에 임시 저장하지 않고,
requests.get(url, stream=True).raw객체를iterparse에 직접 전달하면 디스크 I/O 오버헤드를 완전히 제거할 수 있습니다. - 비정형 인코딩 및 XML 엔티티 예외 처리: 공공데이터에는
&기호가&로 이스케이프되지 않거나, EUC-KR과 UTF-8이 혼용된 불량 문서가 빈번합니다. 파서 유입 전 바이트 스트림 필터를 통해 불량 문자를 선제 정제해야 파싱 중단을 방지할 수 있습니다. - Pydantic DTO 검증 분리: 파싱 루프 내부에서 무거운 검증 로직을 매 행마다 동기적으로 수행하면 CPU 병목이 발생합니다. 파싱 제너레이터와 데이터 검증/정제 단계를 파이프라인 형태로 분리하여 멀티프로세싱 또는 비동기 큐로 위임하는 구조가 바람직합니다.
7. 결론
대용량 데이터를 다루는 백엔드 아키텍처에서 전체 데이터를 메모리에 올려놓고 처리하려는 시도는 시스템 안정성을 저해하는 원인이 됩니다. 공공데이터와 같은 대규모 XML/JSON 문서를 처리할 때는 iterparse와 ijson 기반의 스트리밍 파서를 도입하고, elem.clear()를 통한 적극적인 참조 해제와 제너레이터 청킹을 연계함으로써 저사양 컨테이너 환경에서도 중단 없는 고탄력 ETL 파이프라인을 완성할 수 있습니다.
