가장 저렴한 MacBook에서의 빅데이터 – DuckDB
(duckdb.org)- 최신 MacBook Neo가 데이터베이스 워크로드를 얼마나 잘 처리하는지 ClickBench와 TPC-DS SF300 벤치마크로 측정한 결과를 제시
- 6코어 Apple A18 Pro 칩과 8GB 메모리, 512GB SSD를 탑재한 모델이 실험에 사용되었으며, DuckDB v1.5.0과 v1.4.4 LTS 버전으로 테스트 수행
- ClickBench에서는 콜드 런에서 MacBook Neo가 클라우드 인스턴스보다 빠른 결과를 보였고, 이는 로컬 NVMe SSD의 빠른 접근 속도 덕분으로 분석됨
- TPC-DS SF300 테스트에서는 일부 쿼리에서 디스크 스필링 80GB까지 발생했지만, 모든 쿼리를 79분 내 완료하며 안정적으로 수행
- 일상적인 빅데이터 작업용으로는 한계가 있으나, DuckDB 클라이언트용 노트북으로는 충분히 활용 가능함을 입증
MacBook Neo의 사양 및 테스트 목적
- Apple이 출시한 MacBook Neo는 학생·작가용으로 소개되었지만, DuckDB 팀은 이를 ‘노트북에서의 빅데이터’ 철학에 맞춰 성능을 검증함
- 유럽 판매 모델에는 충전기가 포함되지 않고, 노트북 본체와 USB-C 케이블만 제공
- 선택 가능한 옵션은 256GB 또는 512GB SSD뿐이며, 테스트에는 512GB 모델 사용
-
8GB 메모리와 Apple A18 Pro(6코어) 칩을 탑재
- 동일 칩이 사용된 iPhone 16 Pro는 이전 테스트에서 TPC-H SF100을 10분 내 완료한 바 있음
ClickBench 벤치마크
-
ClickBench는 1억 행의 단일 테이블에서 43개 쿼리를 수행하는 분석형 데이터베이스 벤치마크
- Parquet 형식으로 14GB, CSV로 75GB 크기
- DuckDB v1.5.0을 macOS용으로 포팅해 실행, 메모리 제한을 5GB로 조정하여 스왑 의존도를 줄임
- 비교 대상:
- MacBook Neo (2P+4E 코어, 8GB RAM)
- AWS c6a.4xlarge (16 vCPU, 32GB RAM)
- AWS c8g.metal-48xl (192 vCPU, 384GB RAM)
결과 및 분석
-
콜드 런 결과:
- MacBook Neo가 모든 쿼리를 1분 이내 완료, 중간값 0.57초로 가장 빠른 성능
- 클라우드 인스턴스는 네트워크 스토리지 지연으로 인해 느린 결과
-
핫 런 결과:
- MacBook Neo의 총 실행 시간은 약 10% 개선
- c8g.metal-48xl이 전체적으로 가장 빠르지만, MacBook Neo는 c6a.4xlarge보다 중간값 기준 우수
- 총 실행 시간은 c6a.4xlarge보다 약 13% 느림
TPC-DS 벤치마크
- DuckDB v1.4.4 LTS 버전 사용, 메모리 제한 6GB 설정
-
SF100:
- 중간 쿼리 시간 1.63초, 전체 15.5분 소요
-
SF300:
- 중간 쿼리 시간 6.90초
- 디스크 스필링 최대 80GB 발생
- 쿼리 67번이 51분 소요, 전체 79분 내 모든 쿼리 완료
구매 고려 사항
-
지속적인 빅데이터 처리용으로는 디스크 I/O(1.5GB/s) 와 8GB 메모리가 제약 요인
- Air·Pro 모델(3–6GB/s) 또는 다른 OS 기반 노트북이 더 적합
- 그러나 클라우드에서 DuckDB를 실행하고 로컬은 클라이언트로 사용하는 경우, MacBook Neo는 충분히 유용
- 간헐적 로컬 데이터 처리에도 안정적으로 대응 가능
결론
- MacBook Neo는 저가형 노트북임에도 불구하고 DuckDB 기반의 대규모 데이터 워크로드를 완주할 수 있음
- 클라우드 환경과의 비교에서도 로컬 SSD의 장점이 뚜렷하게 드러남
- 개발자나 데이터 분석가가 휴대성과 실험용 성능을 동시에 확보할 수 있는 최소 사양 기기로 평가됨
Hacker News 의견들
-
나는 이 작은 MacBook Neo로 ‘진짜 개발 작업’을 해보고 싶었음
M1 MacBook Air로 iOS 앱 여러 개를 만들고, 두 번의 스타트업 인수 과정을 거쳤음
FCP로 4K 레이스 영상을 30~45분짜리로 편집해도 문제없었고, Neo는 그 Air보다 더 나은 성능을 보여줌- 예전엔 노르웨이 키보드가 달린 중고 노트북으로 PHP 백엔드와 jQuery 프론트를 개발했음
그걸로 만든 프로젝트들이 첫 개발자 직장을 얻는 계기가 되었고, 그날 Hacker News를 처음 알게 되었음
결국 중요한 건 하드웨어가 아니라 실행력임 - 휴가 중에는 노트북 대신 Galaxy S22 + HDMI 어댑터 + 블루투스 키보드 조합으로 개발했음
TV에 연결해 neovim과 termux로 Elixir 개발을 했고, 테스트는 5초면 끝났음
Rust 빌드는 느렸지만, 휴대성과 배터리 효율 덕분에 꽤 즐거운 경험이었음 - 2019년형 Intel MacBook Pro(16GB) 를 아직도 쓰고 있음
Xcode 빌드, Docker, Claude Code, Codex를 동시에 돌려도 잘 버팀
다만 팬 소음이 제트기 수준이라 새 M5 Max 16" MBP(48GB) 를 주문했음
7년 주기로 업그레이드하니 이번에도 오래 쓸 듯함 -
M1 Mac Mini(8GB) 로 1년간 iOS 앱을 빌드했음
빌드 중엔 약간 버벅이고, Firefox 전환 시 탭 전환이 느려졌지만 충분히 가능했음
같은 작업을 Intel MacBook Pro(16GB) 에서 하면 훨씬 부드럽고 쾌적했음
체감상 OS의 반응성 차이가 컸음 - 사람들은 종종 8GB 메모리를 과소평가함
압축 메모리 덕분에 실제로는 2~3배 데이터를 담을 수 있고, NVMe SSD 덕분에 스왑 읽기도 빠름
오히려 진짜 아쉬운 건 키보드 백라이트가 없는 점임
- 예전엔 노르웨이 키보드가 달린 중고 노트북으로 PHP 백엔드와 jQuery 프론트를 개발했음
-
나는 강의할 때 데이터를 이렇게 구분함 — 한 머신 메모리에 다 들어가면 Small data, 디스크에 들어가면 Medium data, 그 이상은 Big data임
최근 20년 된 Python 앱을 현대화하면서 backend를 polars나 duckDB로 교체 가능하게 했는데, 속도가 40~80배 빨라졌음
이 작업에 이틀밖에 안 걸렸음- 요즘은 한 시스템에 64TB DDR5 RAM도 넣을 수 있어서, 데이터 레이크급이 아니면 거의 다 Small data임
-
polars로 그렇게 큰 속도 차이가 난 이유가 궁금함
올바르게 사용하면 빠르지만, 잘못 다루면 성능이 크게 떨어짐 - 고전이지만 여전히 유효한 링크 Your Data Fits in RAM
비싸긴 해도 대부분의 문제는 여전히 RAM 안에 들어감 - NVMe 덕분에 디스크 접근 속도가 빨라져서, ‘Medium data’ 정의도 애매해졌음
2000년대식 Big Data 인프라는 이제 구식이 된 것 같음
-
나는 DuckDB의 모바일 벤치마크 글을 보고 신뢰가 떨어졌음
Swift 앱과 CLI 앱을 비교하는 건 사과와 바나나 비교 같았음- 하지만 그 실험은 스마트폰에서 로컬 CLI 앱을 돌린 것이었음
iPhone과 Android 비교가 아니라, 벡터화 쿼리 처리 연구 논문 시스템과의 비교였음
- 하지만 그 실험은 스마트폰에서 로컬 CLI 앱을 돌린 것이었음
-
이건 AWS 컴퓨트 성능에 대한 비판이기도 함
- AWS는 EBS 네트워크 스토리지를 썼기 때문에, 로컬 PCIe 버스 대비 지연이 훨씬 큼
특히 랜덤 접근 부하에서는 큰 차이를 만듦 - 그래도 AWS가 노트북보다 빠르지 않았나?
네트워크 디스크가 느렸다고 해서 AWS 전체를 비판하긴 어려움
AWS에도 로컬 SSD 인스턴스가 있음 - 하지만 클라우드는 여전히 과도하게 비쌈
내 M1 Max 노트북이 대부분의 클라우드 인스턴스를 압도함
대역폭 가격은 1만 배 차이까지 나고, 이제 개발자 세대 대부분이 클라우드 SaaS만 알고 있음
그 흐름을 실시간으로 지켜봤음 - 사실 기사 내용은 반대임
“Big Data 작업을 매일 노트북에서 한다면 Neo는 적합하지 않다”
“하지만 클라우드에서 DuckDB를 돌리고, 노트북은 클라이언트로 쓴다면 훌륭하다”는 요지였음
- AWS는 EBS 네트워크 스토리지를 썼기 때문에, 로컬 PCIe 버스 대비 지연이 훨씬 큼
-
나는 가난한 생태학자지만, 이 작은 컴퓨터로 R과 Word 작업을 전부 처리할 수 있음
가격 대비 완성도 높은 빌드 품질에 매우 만족 중임- 혹시 조개 연구 중인가요?
우리 지역의 정부 지원 조개 연구 프로그램은 대부분 종료되어 아쉬움 - 근데 벌써 구입했음? 아직 사전 주문 단계인 줄 알았음
- 혹시 조개 연구 중인가요?
-
나는 DuckDB를 정말 좋아함
AWS Lambda에서 S3에 GZ로 저장된 데이터를 처리하는 PoC를 했는데,
400줄의 C# 코드를 10줄로 대체했음
놀라운 오픈소스 도구임- 최근 몇 년간 나온 가장 훌륭한 오픈소스 선물 중 하나라고 생각함
-
‘2026년에 8GB로 뭘 하냐’는 사람들은 이런 글을 꼭 읽어봤으면 함
-
이런 일반 하드웨어 성능 쇼케이스를 더 많은 회사가 했으면 좋겠음
실제로 어느 정도 부하를 감당할 수 있는지 보여주는 게 유익함 -
벤치마크를 할 때는 로컬 NVMe 인스턴스(c8gd.4xlarge) 로 했어야 함
- 좋은 지적이라, 실제로 c8gd.4xlarge(950GB NVMe)와 c5ad.4xlarge(RAID 0 구성)로 다시 테스트했음
내 로컬 MacBook M1 Max(64GB, 10코어) 결과도 함께 비교했음
결과적으로 M1 Max가 여전히 클라우드 인스턴스보다 빠름
최신 M5 Pro/Max라면 더 큰 차이가 날 듯함 - 하지만 AWS의 로컬 NVMe는 휘발성 저장소라, 매번 데이터를 미리 올려야 함
그래도 벤치마크 목적에는 오히려 이상적임 - 다만 지역 전체 정전 시 데이터 지속성 보장이 아직 불확실함
완전한 내구성을 원한다면 여전히 WAL 스트리밍이 필요함
- 좋은 지적이라, 실제로 c8gd.4xlarge(950GB NVMe)와 c5ad.4xlarge(RAID 0 구성)로 다시 테스트했음
-
클라우드 인스턴스가 네트워크 디스크를 쓴다는 걸 바로 짚어낸 건 좋았음
그렇다면 왜 로컬 스토리지 인스턴스(c8id.2xlarge, c8id.4xlarge) 로 다시 벤치마크하지 않았는지 궁금함