# 가장 저렴한 MacBook에서 빅데이터 처리하기

> Clean Markdown view of GeekNews topic #27469. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27469](https://news.hada.io/topic?id=27469)
- GeekNews Markdown: [https://news.hada.io/topic/27469.md](https://news.hada.io/topic/27469.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-13T22:34:48+09:00
- Updated: 2026-03-13T22:34:48+09:00
- Original source: [duckdb.org](https://duckdb.org/2026/03/11/big-data-on-the-cheapest-macbook)
- Points: 4
- Comments: 2

## Topic Body

- 최신 **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의 장점**이 뚜렷하게 드러남  
- **개발자나 데이터 분석가가 휴대성과 실험용 성능을 동시에 확보할 수 있는 최소 사양 기기**로 평가됨

## Comments



### Comment 52975

- Author: neo
- Created: 2026-03-13T22:34:48+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47349277) 
- 나는 이 작은 **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 덕분에 스왑 읽기도 빠름  
    오히려 진짜 아쉬운 건 **키보드 백라이트가 없는 점**임

- 나는 강의할 때 데이터를 이렇게 구분함 — 한 머신 메모리에 다 들어가면 **Small data**, 디스크에 들어가면 **Medium data**, 그 이상은 **Big data**임  
  최근 20년 된 Python 앱을 현대화하면서 backend를 **polars**나 **duckDB**로 교체 가능하게 했는데, 속도가 40~80배 빨라졌음  
  이 작업에 이틀밖에 안 걸렸음
  - 요즘은 한 시스템에 **64TB DDR5 RAM**도 넣을 수 있어서, 데이터 레이크급이 아니면 거의 다 Small data임
  - **polars**로 그렇게 큰 속도 차이가 난 이유가 궁금함  
    올바르게 사용하면 빠르지만, 잘못 다루면 성능이 크게 떨어짐
  - 고전이지만 여전히 유효한 링크 [Your Data Fits in RAM](https://yourdatafitsinram.net/)  
    비싸긴 해도 대부분의 문제는 여전히 RAM 안에 들어감
  - NVMe 덕분에 디스크 접근 속도가 빨라져서, ‘Medium data’ 정의도 애매해졌음  
    2000년대식 **Big Data 인프라**는 이제 구식이 된 것 같음

- 나는 [DuckDB의 모바일 벤치마크 글](https://duckdb.org/2024/12/06/duckdb-tpch-sf100-on-mobile#a-song-of-dry-ice-and-fire)을 보고 신뢰가 떨어졌음  
  Swift 앱과 CLI 앱을 비교하는 건 **사과와 바나나 비교** 같았음
  - 하지만 그 실험은 스마트폰에서 **로컬 CLI 앱**을 돌린 것이었음  
    iPhone과 Android 비교가 아니라, **벡터화 쿼리 처리 연구 논문 시스템**과의 비교였음

- 이건 **AWS 컴퓨트 성능**에 대한 비판이기도 함
  - AWS는 **EBS 네트워크 스토리지**를 썼기 때문에, 로컬 PCIe 버스 대비 지연이 훨씬 큼  
    특히 **랜덤 접근 부하**에서는 큰 차이를 만듦
  - 그래도 AWS가 노트북보다 빠르지 않았나?  
    네트워크 디스크가 느렸다고 해서 AWS 전체를 비판하긴 어려움  
    AWS에도 **로컬 SSD 인스턴스**가 있음
  - 하지만 클라우드는 여전히 **과도하게 비쌈**  
    내 **M1 Max** 노트북이 대부분의 클라우드 인스턴스를 압도함  
    대역폭 가격은 1만 배 차이까지 나고, 이제 개발자 세대 대부분이 **클라우드 SaaS**만 알고 있음  
    그 흐름을 실시간으로 지켜봤음
  - 사실 기사 내용은 반대임  
    “Big Data 작업을 매일 노트북에서 한다면 Neo는 적합하지 않다”  
    “하지만 클라우드에서 DuckDB를 돌리고, 노트북은 클라이언트로 쓴다면 훌륭하다”는 요지였음

- 나는 가난한 생태학자지만, 이 작은 컴퓨터로 **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 스트리밍**이 필요함

- 클라우드 인스턴스가 **네트워크 디스크**를 쓴다는 걸 바로 짚어낸 건 좋았음  
  그렇다면 왜 **로컬 스토리지 인스턴스(c8id.2xlarge, c8id.4xlarge)** 로 다시 벤치마크하지 않았는지 궁금함

### Comment 53001

- Author: dkang
- Created: 2026-03-14T13:29:08+09:00
- Points: 1
- Parent comment: 52975
- Depth: 1

가난한 생태학자분 아이디가 clamlady라서 조개 연구자인지 물어보는 댓글이 달렸네요(조개가 오역인 줄 알고 원문이 궁금해서 들어가봤습니다)