16GB RAM 지옥 (그리고 클러스터 없이도 탈출할 수 있는 이유)

발행: (2025년 12월 3일 오전 09:08 GMT+9)
12 min read
원문: Dev.to

Source: Dev.to

Introduction: When Your Laptop Says “Enough”

데이터 엔지니어링의 일상 전선에서 나는 끊임없이 복잡한 기술적 과제에 직면한다. 아이러니하게도 내가 마주치는 가장 높은 장벽은 페타바이트 규모의 빅데이터가 아니라 “미드 데이터”다.

나는 5 천만 – 1 억 건 레코드를 처리해야 하는 그 어색한 지점을 말한다. 엑셀은 크래시 없이 감당하기엔 너무 크고, 스파크 클러스터를 띄워 클라우드 크레딧을 소모하기엔 너무 작다.

그리고 하드웨어 현실이 있다. 우리 모두가 5,000 달러짜리 워크스테이션을 가지고 있는 건 아니다. 많은 계약자나 컨설턴트는 Lenovo ThinkPad Core i5와 16 GB RAM 혹은 운이 좋다면 같은 메모리를 가진 M1 MacBook Air를 배정받는다.

이 기계들은 웹 서핑과 이메일에는 훌륭하지만, 3 GB CSV 파일을 Pandas에 로드하려 하면 RAM이 사라진다. Java를 시도하면 JVM이 “Hello”라고 인사하기만 해도 4 GB를 잡아먹는다. 그리고 화면이 멈춘 채로 “서버를 새로 달라고 상사에게 물어볼 수 없는 방법이 있을 거야”라고 생각하게 된다.

pardoX는 실리콘밸리 화이트보드에서 벤처 캐피털을 구하기 위해 탄생한 것이 아니다. 그 i5 노트북 위에서 좌절과 호기심으로 탄생했다.

나는 여기서 가벼운 소프트웨어를 팔려는 것이 아니다. 현재 코드를 버리라고 말하려는 것도 아니다. 파이썬이 나쁘다거나 당신의 스택이 쓸모없다고 말하려는 것도 아니다. 오히려 그 반대다.

나는 내 머리 아픔을 해결하려다 50 백만 행을 몇 초 안에 처리할 수 있는 러스트 엔진을 같은 노트북에 구축하게 된 이야기를 전하고 싶다. 이것이 pardoX다: MVP 단계에 접어든 개인 프로젝트로, 로컬 머신에 힘을 되돌려 주기 위해 설계되었다.

보편적인 ETL을 향한 탐험에 오신 것을 환영한다.

I Come Not to Kill Your Stack, But to Save It (The Peace Treaty)

기술 분야에서 누군가 “혁신적인 새로운 엔진”을 발표하면, 경험 많은 엔지니어들은 본능적으로 코드를 방어한다. 우리는 다음을 예상한다: 트렌디한 언어로 모든 것을 다시 작성하라는 컨설턴트의 제안.

그래서 pardoX의 첫 번째 규칙은 내가 **“평화 조약”**이라고 부르는 것이다.

  • 당신의 PHP 백엔드를 러스트로 다시 쓰길 원하지 않는다.
  • 당신의 파이썬 자동화 스크립트를 Go로 마이그레이션하길 원하지 않는다.
  • 아무도 눈을 마주치고 싶어 하지 않는 COBOL 메인프레임을 건드리길 원하지도 않는다.

pardoX는 당신의 스택을 대체하려는 것이 아니라, 보완하려는 것이다.

The True Story Behind the Name: The Holy Trinity

마케팅에서는 pardoX가 성능 vs 비용의 “패러독스”(실제 맞다)를 해결한다고 말할 수 있다. 하지만 이름에는 더 geeky하고 개인적인 유래가 있다.

데이터를 다루는 사람이라면 두 거인을 안다:

  • Pandas – 클래식하고 유연한 파이썬 표준(팬더).
  • Polars – 새롭고 빠르며 러스트로 작성된 존재(폴라).

하지만 나는 언제나 가족을 완성시키는 무언가가 부족하다고 느꼈다. We Bare Bears를 좋아한다면 큰 형이 없다는 것을 알 수 있다 – 모두를 묶어두려는 시끄러운 리더.

우리는 Pardo(그리즐리)를 놓치고 있었다.

pardoX는 데이터 엔지니어링에서 그 “그리즐리”가 되기 위해 탄생했다. Pandas가 편안함을 제공하고 Polars가 순수 분석 속도를 제공한다면, pardoX는 연결과 무자비한 힘의 엔진이다. 레거시 PHP 서버에 뛰어들거나 C++ 바이너리와 대화할 때 손을 더럽히는 것을 두려워하지 않는 곰이다.

The “X”: The Intersection Factor

Pardo가 근육(러스트 엔진)이라면, X는 마법이다. “X”는 보통 서로 대화하지 않는 언어들이 교차하는 보편적인 교차점을 의미한다.

이것은 PHP 스크립트(보통 1 GB CSV를 처리하면 막히는)가 배턴을 그리즐리 엔진에 넘겨주고, SIMD를 이용해 밀리초 단위로 데이터를 으깨고, 정제된 결과를 파이썬에 다시 전달하도록 하는 도구다.

The Paradox We Solve (Even If It’s Not Our Name)

이름은 곰에서 유래했지만, 사명은 우리 업계의 오래된 모순을 해결하는 것이다. 우리는 두 가지만 선택할 수 있다고 들었다:

  1. 속도 (잔인한 성능)
  2. 단순성 (작성 용이)
  3. 저비용 (저사양 하드웨어에서 실행)

pardoX는 그 삼각형을 깨뜨린다. 클러스터 수준의 속도, 로컬 라이브러리 수준의 단순성, 그리고 컨설팅 회사가 준 저렴한 노트북에서도 동작한다.

The Real Problem: The Migration Lie

우리는 “데이터 엔지니어링”이 현대 파이썬과 동등시되는 거품 속에 살고 있다. 전선 속 현실은 다르다.

  • 은행은 여전히 COBOL로 중요한 거래를 처리한다.
  • 거대 전자상거래 사이트는 WooCommerce(PHP) 위에서 8천만 행 테이블을 운영하며, 보고서를 요청할 때마다 고통받는다.

업계는 오만하게 말한다: “모두 버리고 마이크로서비스로 마이그레이션하라.”

pardoX는 이렇게 말한다: “스택을 유지하라. 이 엔진만 끼워라.”

오래된 세단에 핵 배터리를 달아보라. 익숙한 차를 계속 운전하면서도, 엔진(“그리즐리”)이 5천만 행을 약 12초에 처리한다.

그리즐리 시대에 오신 것을 환영한다.

The Valley of Data Death (Where Laptops Go to Die)

데이터 엔지니어링에는 어두운 곳이 있다 – 전통 도구가 멈추고 “엔터프라이즈” 솔루션은 비용이나 복잡성 때문에 정당화되지 못하는 림보. 나는 이를 **“5천만 행의 죽음의 계곡”**이라 부른다.

그것은 어색한 데이터 범위다: 5천만 ~ 5억 행 사이. 더블 클릭하기엔 너무 크고, Databricks 클러스터를 띄워 클라우드 예산을 소모하기엔 너무 작다. 전쟁터는 128코어 서버가 아니라 당신의 책상이다.

The Scenario: The “Lenovo i5” Reality

하드웨어에 대해 솔직해지자. LinkedIn에서는 모두가 Netflix나 Uber 아키텍처를 자랑한다. 현실에서는 컨설팅 회사에 입사하거나 계약자로 프로젝트에 투입될 때 왕국 열쇠를 받지 않는다.

당신이 받는 것은 표준 기업 노트북이다:

  • Intel Core i5(또는 운이 좋다면 M1/M2 Mac)
  • 16 GB RAM(실제 사용 가능한 것은 보통 ~12 GB, Chrome, Teams 등이 나머지를 잡아먹음)
  • 이미 절반이 찬 SSD

그리고 그 무기로 지난 5년간의 판매 기록을 처리하라는 과제가 주어진다.

The Pain: Pick Your Poison

16 GB 노트북으로 이 계곡을 건너려 하면 세 가지 치명적인 운명이 기다린다:

  1. Excel에 의한 사망 – Excel은 1,048,576 행을 초과하면 멈춘다.

  2. Spark에 의한 사망 (모기를 향한 바주카) – 로컬에 Spark를 설치하면 Java, Hadoop 환경 변수와 수 기가바이트의 RAM을 잡아먹는 JVM과 씨름해야 한다.

  3. MemoryError에 의한 사망 – Pandas 사용 시:

    df = pd.read_csv('giant_sales.csv')

    진행 바가 멈추고, 마우스가 응답을 멈추며, 결국 MemoryError 혹은 OS의 OOM 킬러가 프로세스를 종료한다.

The Mission: Respect RAM Like It’s Gold

여기서 pardoX에 대한 집착이 시작되었다.

놀라운 도구들이 있다는 것을 알았다. Polars는 환상적이며 종종 금본위제 표준이지만, 제한된 머신에서 실행 전략이나 복잡한 조인이 메모리를 과도하게 사용해 16 GB 노트북이 감당하지 못한다.

DuckDB는 기술적 경이이지만 본질적으로 OLAP 데이터베이스다. 나는 데이터를 “로드”한 뒤 쿼리하는 데이터베이스가 아니라, 데이터를 잡고 있지 않고 흐르게 하는 파이프라인, 즉 처리 튜브가 필요했다.

우리는 기본적인 진실을 이해하는 엔진이 필요했다:

(이하 내용은 원문에 이어집니다…)

Back to Blog

관련 글

더 보기 »

계정 전환

@blink_c5eb0afe3975https://dev.to/blink_c5eb0afe3975 여러분도 알다시피 저는 다시 제 진행 상황을 기록하기 시작했으니, 이것을 다른…