# 명령줄 도구가 Hadoop 클러스터보다 235배 빠를 수 있다 (2014) > Clean Markdown view of GeekNews topic #25948. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25948](https://news.hada.io/topic?id=25948) - GeekNews Markdown: [https://news.hada.io/topic/25948.md](https://news.hada.io/topic/25948.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-19T09:59:41+09:00 - Updated: 2026-01-19T09:59:41+09:00 - Original source: [adamdrake.com](https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html) - Points: 9 - Comments: 2 ## Summary **명령줄 도구 조합이 Hadoop 클러스터보다 235배 빠른 처리 속도를 보여줍니다.** 1.75GB 규모의 체스 경기 데이터를 `grep`, `awk`, `xargs`, `mawk` 등 기본 셸 명령으로 스트리밍 처리한 결과, 단일 노트북에서 12초 만에 분석이 완료되었습니다. 복잡한 분산 환경 없이도 CPU 병렬화와 파이프라인 최적화만으로 고성능을 달성하며, 불필요한 **Big Data 인프라 의존**에 대한 현실적인 대안을 제시합니다. ## Topic Body - 약 **1.75GB의 체스 경기 데이터**를 Hadoop 대신 명령줄 도구로 처리한 결과, **12초 만에 완료**되어 Hadoop의 26분 대비 235배 이상 빠른 성능을 보임 - **grep, sort, uniq, awk, xargs, mawk** 등 기본 셸 명령을 조합해 **스트리밍 처리 파이프라인**을 구성, 메모리 사용을 거의 0으로 유지 - **xargs 병렬 처리**와 **mawk 최적화**를 통해 CPU 코어 활용도를 높이고, IO 병목을 최소화함 - 동일한 데이터셋을 Hadoop 클러스터(7대의 c1.medium 인스턴스)로 처리할 때보다 **비용과 유지보수 부담이 현저히 낮음** - 단일 머신에서도 효율적인 데이터 분석이 가능함을 보여주며, **불필요한 Big Data 도구 사용에 대한 경각심**을 제시함 --- ### 서론: Hadoop보다 빠른 명령줄 처리 - 약 2백만 건의 체스 경기 데이터를 Amazon EMR과 mrjob으로 분석한 사례를 보고, 동일 데이터를 **명령줄 기반 스트리밍 처리**로 재현 - Hadoop 클러스터(7대 c1.medium)에서 26분 소요, **1.14MB/sec 처리속도** - 로컬 노트북에서는 12초 만에 완료, **270MB/sec 처리속도** - 단순한 결과 집계 작업은 **Hadoop보다 셸 파이프라인이 훨씬 효율적**임을 입증 - 셸 명령을 조합하면 **Storm과 유사한 병렬 스트림 처리 구조**를 단일 머신에서 구현 가능 ### 데이터 구조와 준비 - 데이터는 **PGN(Portable Game Notation)** 형식의 체스 경기 기록으로, 각 경기의 결과는 `"Result"` 라인에 표시됨 - `"1-0"`은 백 승, `"0-1"`은 흑 승, `"1/2-1/2"`는 무승부 - GitHub의 **rozim/ChessData** 저장소에서 약 **3.46GB 데이터셋** 확보 - Tom Hayden의 실험 데이터(1.75GB)의 약 두 배 규모 ### 기본 파이프라인 구축 - IO 한계 측정을 위해 `cat *.pgn > /dev/null` 실행 시 약 **13초(272MB/sec)** 소요 - 기본 분석 파이프라인: ```bash cat *.pgn | grep "Result" | sort | uniq -c ``` - 실행 시간 약 **70초**, Hadoop 대비 약 **47배 빠름** - `sort | uniq` 대신 **AWK**를 사용해 결과를 직접 집계 - 실행 시간 **65초**, 메모리 사용 거의 없음 - `grep`이 단일 CPU 코어를 점유하며 병목 발생 ### 병렬화 및 최적화 - **xargs**를 이용해 `grep` 병렬화 ```bash find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ... ``` - 실행 시간 **38초**, 약 **77배 속도 향상** - `grep`을 제거하고 **AWK 단독 필터링**으로 단계를 단순화 - 각 파일별 결과를 통합하기 위해 **이중 AWK 파이프라인** 구성 - 실행 시간 **18초**, 약 **174배 빠름** - **mawk**로 교체 시 추가 최적화 ```bash find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ... ``` - 실행 시간 **12초**, **Hadoop 대비 235배 빠름**, 처리속도 **270MB/sec** ### 결론: 단순함의 효율성 - 대규모 분산 처리가 필요한 경우를 제외하면, **단일 머신의 셸 도구 조합이 더 빠르고 경제적** - Hadoop은 종종 **관계형 DB나 단순 스크립트로 충분한 작업**에도 과도하게 사용되고 있음 - 명령줄 기반 스트리밍 분석은 **성능, 구현 비용, 유지보수성** 측면에서 우수한 대안임 ## Comments ### Comment 49532 - Author: dongho42 - Created: 2026-01-20T13:17:05+09:00 - Points: 1 예전에 타코벨 프로그래밍이란 말이 있었는데 비슷한 철학 같네요 ### Comment 49449 - Author: neo - Created: 2026-01-19T09:59:41+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46666085) - 이 글이 2014년 것이라는 게 가장 슬픈 점임 지금은 **Airflow, dbt, Snowflake** 같은 더 많은 추상화 계층이 생겨서, 사실상 RAM에 다 들어가는 데이터셋에도 이런 걸 덧씌우는 상황임 스타트업들이 하루 10GB도 안 되는 로그를 처리하려고 분산 클러스터에 월 5천 달러를 태움. 이유는 ‘Modern Data Stack’을 쓰면 승진이 되지만, **bash 스크립트**로 해결하면 ‘비확장적’이라며 무시당하기 때문임. 효율성과 인센티브가 완전히 어긋나 있음 - 최근 면접에서 ‘스케일링 문제’라며 이야기하지만, 실제로는 한 대의 머신에 충분히 들어가는 경우가 많았음 하루 1GB의 JSON을 ingest하는 사례도 있었는데, 내가 “한 대로 충분하다”고 설명했더니 “기술적으로 맞지만 우리가 원하는 답이 아니다”라며 탈락시킴 요즘 머신은 **TB 단위 RAM**과 수백 개의 코어를 갖고 있음. 한 대의 머신이 이미 어마어마하게 큼 - 이건 단지 승진뿐 아니라 **채용 구조**의 문제이기도 함 DevOps 경력자를 뽑을 때 화려한 프레임워크 경험을 강조하니, 결국 그들이 회사에 와서도 똑같은 걸 반복함 아무도 반대하지 않으니, 결국 데스크탑 한 대로 충분한 일을 복잡하게 만들어버림 - 지난 20년간 ‘멋져 보이는 기술’ 대신 ‘맞는 기술’을 써왔는데, 결국 해고당했음 **최신 프레임워크**가 거의 없는 이력서로 1년 넘게 구직 중이라 스스로 바보 같다는 생각이 듦 - 회사에서도 비슷한 걸 봄. 하루 몇 GB의 데이터를 여러 시스템으로 돌리느라, 예전엔 파이썬 스크립트로 일주일 만에 끝내던 걸 이제는 몇 달씩 걸리고 자주 깨짐 - 요즘은 **128GB RAM 노트북**도 흔하고, 서버는 훨씬 더 큼 2014년엔 4GB가 일반적이었지만 지금은 SSD 스트리밍 속도도 빨라서, 로컬 SSD에서 읽는 게 클러스터보다 나을 때도 많음 - 글쓴이임! 예전 글이 여전히 도움이 된다니 기쁨임 상황이 더 나빠졌다는 의견에 동의하지만, 한편으로는 **microservices 맹신**에서 벗어나는 움직임도 보여서 다행임 성능 개선을 위해 노력하는 모든 분들께 응원 보냄. 아직 **희망**이 있음 - Adam, 고마움! 글을 여러 번 다시 읽었고, 영감을 받아 **Waters-Series**를 JavaScript로 포팅해서 스트림 파이프라이닝을 구현했음 - 요즘 업계는 **Spark나 분산 툴**이 데이터 엔지니어링의 정답이라는 인식이 너무 강함 웹 개발에서 SPA 프레임워크를 과하게 쓰는 현상과 비슷함 내 조언은 이러함: - 매니저는 특정 기술(Spark, React)을 요구하지 말고, **문제 해결 능력** 있는 엔지니어에게 맡길 것 - 기술 리드는 “우리 파이프라인은 20GB까지 처리 가능하고, 더 커지면 X/Y/Z로 확장할 계획”이라고 솔직히 말할 것 매니저가 듣고 싶은 건 ‘모든 게 무한 확장된다’가 아니라 ‘안정적으로 돌아간다’는 확신임 - 대부분의 회사는 **소규모 데이터**를 다룸 데이터 크기는 멱법칙을 따르기 때문에, 페타바이트급 데이터를 다루는 엔지니어는 극소수임 하지만 연봉 상승을 위해 그런 경험을 이력서에 넣으려다 보니 **과도한 엔지니어링**이 생김 - 예전에 유명 유니콘에서 일할 때, 매니저가 “다음 분기에 Spark를 써야 한다”고 했음 이유를 물었더니 “그냥 써야 한다”였음. 아마도 **이력서용** 혹은 누군가의 정치적 이유였던 듯함 - 글과 관련된 역사 이야기임 **mrjob**이라는 툴은 Hadoop 없이 로컬 모드로도 실행 가능했음 작은 데이터셋에서는 클러스터보다 훨씬 빠름. 특히 AWS EMR 같은 임시 클러스터보다도 빠르게 끝남 하지만 저자의 접근법이 그보다도 더 효율적이었을 것 같음 MapReduce는 대규모 확장을 쉽게 해주는 대신, 작은 데이터에는 **비효율적인 제약**이 많았음 2010년대 초반엔 mrjob으로 페타바이트급 데이터를 처리했지만, 지금은 거의 쓰이지 않음 - 데이터 엔지니어로 일할 때, **Bash/Python 스크립트**를 C#으로 다시 써서 JSON 처리 속도를 1GB/s까지 끌어올렸음 단순히 **스트리밍 파싱** 같은 최적화만으로도 큰 차이를 냈음 그래서 궁금함 — 도대체 어느 정도 데이터부터 클러스터링이 진짜 의미가 있을까? - 반대로 15년 전엔 복잡한 C# 시스템을 **bash + Python**으로 바꿔서 훨씬 빨라졌던 적도 있음 내 기준으로는 하루 이상 걸리는 작업이면 분산 처리를 고려할 만함 - 예전에 PyCon 패널에서 유명 데이터 과학자가 “**Excel이 Pandas보다 낫다**”고 말했음 데이터가 크면 샘플링해서 Excel로 분석했다고 함. 요즘은 LLM 덕분에 간단한 Python/Bash 스크립트도 쉽게 작성 가능함 - 처리 시간 외에도, **로컬 디스크에 안 들어가는 데이터**가 또 다른 기준임 S3 같은 오브젝트 스토리지에서 직접 읽고 쓰는 게 가능하고, 요즘은 100GB/s 속도도 가능함 - [이 댓글](https://news.ycombinator.com/item?id=46667287)에 나온 체스 데이터셋은 약 14TB임 디스크엔 들어가지만 일반 노트북엔 불가능한 크기임 - JSON을 스트리밍으로 파싱하는 방법이 궁금함. 대부분의 파서는 전체를 읽어야 문법 검증이 가능한데, 이걸 어떻게 해결했는지 알고 싶음 - 데이터의 ‘크기’는 **무엇을 하느냐**에 따라 달라짐 예를 들어 수술 데이터에서 단순 통계는 bash로 충분하지만, 의사 경험과 성공률의 상관관계를 계산하려면 복잡도가 급격히 증가함 그래서 기업 입장에서는 “우린 Spark를 쓴다”고 말하는 게 “질문마다 맞춤 엔진을 만든다”고 말하는 것보다 훨씬 쉬움 - 하지만 **SQLite**만으로도 50GB~2TB 데이터를 처리할 수 있음 언급된 모든 문제를 단일 서버에서 간단한 도구로 해결 가능함 - 이 글은 예전에 여러 번 HN에 올라왔음 [2018년 버전](https://news.ycombinator.com/item?id=17135841), [2022년 버전](https://news.ycombinator.com/item?id=30595026), [2024년 버전](https://news.ycombinator.com/item?id=39136472) 모두 같은 제출자가 올렸음 - 예전 **Shakti** 웹사이트의 소개 문구가 떠오름 “1K 행: Excel / 1M 행: Pandas / 1B 행: Shakti / 1T 행: Only Shakti” [출처](https://web.archive.org/web/20230331180931/https://shakti.com/) - 많은 개발자가 **Windows 환경**에서 배워서 CLI 도구에 익숙하지 않음 하지만 CLI는 암묵적 루프, 필드 자동 분리, 정규식 병렬 적용 등 강력한 기능을 제공함 덕분에 빠르게 **ad-hoc 솔루션**을 만들 수 있고, 대규모 시스템을 쓰기 전의 좋은 출발점이 됨 - 체스 데이터를 더 크게 확장해 벤치마크를 다시 해보면 어떨까 생각함 요즘 **Lichess 데이터셋**은 약 7B 게임, 2.34TB 압축(14TB 비압축)임 이런 규모에서 Hadoop이 이길 수 있을까 궁금함 - 빠른 SSD 여러 개를 한 서버에 넣으면 여전히 EMR+S3보다 빠를 것 같음 다만 그만큼 **전용 서버 관리**가 필요함 EMR은 데이터 접근 빈도가 낮을 때(하루 1~10회) 병렬 처리를 위해 설계된 모델임 - 압축된 데이터는 로컬 SSD에 충분히 들어가고, **스트리밍 압축 해제**도 가능함 - 이런 데이터로 뭘 계산할지 궁금함. NVL72에서 실험해보면 재미있을 듯함