창비의 엔지니어 일지

1. Hadoop을 시작하면서

Changby — Sun, 28 Jun 2026 20:00:16 +0900

안녕하세요 엔지니어 창비입니다.

오늘은 하둡에 대해서 알려드릴께요

하둡 클러스터 모니터링 중

오늘은 빅데이터 하면 절대 빠질 수 없는 핵심 기술, 하둡(Hadoop)에 대해 가볍게 정리해 보려고 합니다.

하둡은 한 문장으로 간단하게 요약할 수 있습니다.

"데이터를 여러 서버에 저장하고, 여러 서버에서 읽어와 처리한다."

오늘은 복잡한 디테일보다 전체적인 흐름과 핵심 개념 위주로 살펴보겠습니다.

1. 하둡의 탄생배경

하둡의 직접적인 기원은 구글이 발표한 두 개의 논문, GFS(Google File System)와 MapReduce에서 출발합니다.

GFS: 수천 대의 일반 서버에 데이터를 '분산 저장'하는 시스템입니다. 하드웨어 장애를 특별한 예외가 아니라 '언제든 일어날 수 있는 일상'으로 전제하고 설계했다는 점이 당시로선 아주 혁신적이었습니다.
MapReduce: 이렇게 여러 서버에 분산된 대규모 데이터를 동시에 '분산 처리(연산)'하는 프레임워크입니다.

당시 더그 커팅(Doug Cutting)과 마이클 카파렐라(Mike Cafarella)는 오픈소스 웹 검색엔진인 '너치(Nutch)'를 개발하고 있었습니다. 전 세계 웹페이지를 크롤링하고 인덱싱하려다 보니, 단일 머신으로는 도저히 감당할 수 없는 스토리지와 연산 장벽에 부딪힌 상태였죠.

때마침 구글의 논문을 접한 두 사람은 이를 기반으로 직접 구현에 착수합니다.

초기에는 너치 프로젝트 내부의 서브 시스템인 NDFS(Nutch Distributed File System) 형태로 시작되었습니다.

그러다 2006년, 더그 커팅이 야후(Yahoo)에 합류하면서 이 분산 저장·처리 부문이 독립 프로젝트로 분리되었고, 그것이 바로 지금의 하둡(Hadoop)이 됩니다. (하둡이라는 이름은 더그 커팅의 아들이 가지고 놀던 노란색 코끼리 인형 이름에서 따왔다는 유명한 일화가 있죠.)

하둡의 핵심 철학은 명확합니다.

"비싼 고성능 서버 한 대를 쓰느니, 값싼 범용 서버 수천 대를 묶어서 쓰자"는 것. 그리고 네트워크로 대용량 데이터를 이동시키는 비용을 아끼기 위해 "연산(코드)을 데이터가 있는 서버로 보낸다(Data Locality)"는 발상입니다. 이 직관적인 아이디어가 빅데이터 시대의 서막을 열었습니다.

2. 하둡의 핵심 구성 요소와 역할

HDFS (Hadoop Distributed File System)
- 파일을 저장할 때 '블록(Block)'이라는 큰 단위(기본 128MB)로 쪼개어 여러 서버에 나누어 저장합니다.
- 기본적으로 3 Copy(3중 복제) 설정을 주로 사용합니다. 똑같은 블록 복사본을 서로 다른 3대의 서버에 흩어놓는 방식이죠. 덕분에 서버 한두 대가 동시에 고장 나더라도 데이터 유실 없이 안전하게 시스템을 유지할 수 있습니다.
YARN (Yet Another Resource Negotiator)
- 하둡 클러스터의 '자원 관리자이자 스케줄러'입니다.
- 수많은 서버가 묶여 있는 환경에서는 "어느 서버의 CPU와 메모리가 여유 있는지", "지금 들어온 작업을 어떤 서버에 배정해야 효율적일지"를 통제하는 중앙 관리자가 필수적입니다. YARN이 바로 그 역할을 맡아 클러스터 전체의 자원을 효율적으로 분배해 줍니다.
MapReduce (맵리듀스)
- YARN이 나눠준 자원을 바탕으로, 데이터를 실제로 '분산 처리(연산)'하는 프레임워크입니다.
- 작업을 잘게 쪼개는 Map(맵) 단계와, 쪼개서 처리한 결과물을 다시 하나로 모으는 Reduce(리듀스) 단계로 나뉩니다.
- 예를 들어 10억 줄짜리 문서에서 단어 개수를 센다면, 서버 100대에 1,000만 줄씩 보내서 동시에 단어를 세게 한 뒤(Map), 그 결과만 한곳에 모아서 더하는(Reduce) 방식입니다. 앞서 언급한 'Data Locality(데이터가 있는 곳으로 연산을 보낸다)' 철학이 실제로 구현되는 핵심 메커니즘입니다.

3. 현재 하둡의 입지와 스토리지 트렌드

최근 인프라 트렌드를 보면 하둡(Hadoop)은 사실상 신규 도입이 거의 없는 레거시 단계로 들어선 게 맞습니다. 하지만 필드에서 완전히 지워진 건 아닌데, 현재 시장 구조를 크게 3가지 줄기로 요약해 볼 수 있습니다.

① 레거시로써 하둡

새로운 프로젝트의 아키텍처로 하둡을 선택하는 경우는 이제 거의 없습니다. 분석의 중심축은 이미 Spark, Trino, 그리고 현대적인 레이크하우스(Databricks 등)로 넘어갔기 때문이죠. 다만, 글로벌 통계를 보면 하둡 인프라의 약 60~62%는 여전히 온프레미스(On-Premise) 환경에 묶여 있습니다. 금융권이나 공공, 대기업처럼 데이터 주권(Data Sovereignty)과 보안 규제가 까다로운 곳들이 기존에 구축해 둔 수십~수백 페타바이트(PB) 규모의 HDFS 클러스터를 여전히 '운영 유지 및 점진적 이관(Modernization)' 형태로 들고 가고 있기 때문입니다.

② 고성능 AI/실시간 연산을 위한 Block Storage

전체 클라우드 스토리지 시장에서 매출 비중으로만 보면 블록 스토리지(EBS, NVMe 가상화 볼륨 등)가 약 68% 이상으로 여전히 가장 큰 파이를 차지합니다. 하지만 이걸 과거 하둡처럼 대용량 데이터 적재용 저장소로 쓰진 않습니다. 최근 트렌드는 AI/ML 모델 학습, LLM 서빙, 실시간 분산 DB 처리처럼 초고성능 IOPS와 극도의 저지연(Low-latency)이 필수적인 연산 전용 스토리지로 역할이 압축되고 있습니다.

③ 대형 데이터 레이크의 표준이 된 Object Storage

과거 HDFS가 담당하던 대용량 분산 저장의 지위는 완전히 오브젝트 스토리지(S3, MinIO 등)로 대체되었습니다. 매년 14~16%씩 가파르게 성장하는 영역이기도 합니다. 하둡 구조의 고질적 문제였던 '스토리지 늘릴 때 연산 노드도 같이 사야 하는 비효율'을 해결하기 위해, 시장은 Compute(연산)와 Storage(저장)를 완벽히 분리(Decoupling)하는 방향으로 정착했습니다. 비용이 저렴한 오브젝트 스토리지에 데이터를 다 던져두고, Iceberg나 Delta Lake 같은 오픈 테이블 포맷을 얹어서 Hive 카탈로그를 대체하는 방식이 현재 모던 데이터 아키텍처의 표준이 되었습니다.

4. 한 눈에 보는 아키텍처 요약 비교

과거 (Hadoop HDFS 구조)
- Storage + Compute 결합형 ➔ 데이터 위치 기반 연산(Data Locality)은 좋았으나 스토리지 확장 시 비용 부담이 같이 커지고, 3 Copy 복제로 인한 공간 낭비가 심함.
현재 (Modern Cloud-Native 구조)
- Storage(Object Storage) + Compute(Spark/Trino 등) 분리형 ➔ 무제한에 가까운 비용 효율적 저장이 가능하며, 필요할 때만 연산 자원(쿠버네티스 등)을 유연하게 띄워서 계산.

참고 자료 (References)

하둡 시장 및 온프레미스 비중 데이터: Mordor Intelligence / Coherent Market Insights (2026) 기준, 기존 글로벌 하둡 인프라의 온프레미스 잔존 점유율 약 60~62% 선 유지 및 점진적 클라우드 이관 추세 분석 참고.
블록 스토리지 비중 데이터: Precedence Research / Research and Markets (2026) 보고서 내 가상화 및 초고성능 AI/DB 워크로드용 매출 포지션(약 68%) 및 연평균 성장률 데이터 참고.
오브젝트 스토리지 트렌드: The Business Research Company (2026) 클라우드 오브젝트 스토리지 글로벌 마켓 리포트의 Compute-Storage 분리 아키텍처 전환 동향 참고.

Kubernetes for Developers - 3장 정리

Changby — Sun, 13 Jul 2025 17:15:05 +0900

쿠버네티스 아키텍처

쿠버네티스는 VM(또는 베어메탈 머신) 및 로드 밸런서와 같은 거수준으 ㅣ컴퓨팅 기본 요소 위의 워크로드 레벨에 위치하는 추상화 계층

쿠버네티스에서는 이 VM을 노드(Node), 클러스터(Cluster) 형태로 배포됨.

파드(Pod)라는 스케줄링 단위로 그룹화.

네트워킹은 서비스(Service)를 통해 구성.

디플로이먼트(Deployment)와 같은 고차원적인 빌딩 블록이 존재하여 파드를 보다 쉽게 관리.

쿠버네티스 클러스터는 컨테이너가 실행되는 컴퓨트 인스턴스인 노드의 집합.

각 노드는 Kubelet이라고 하는 쿠버네티스 프로세스 실행.

Kubelet은 Control Plane과 통신하고 컨테이너 런타임을 통해 노드에서 실행되는 컨테이너의 라이프사이클 관리를 담당.

OS, Kubelet, Container Runtime외에 자체 워크로드 및 로깅 및 모니터링을 담당하는 일부 시스템 구성요소를 포함한 나머지 프로세스는 컨테이너 형태로 실행.

Control Plane의 역할

- 쿠버네티스 명령행 인터페이스(CLI, Command Line Interface)와 같은 도구를 사용하여 클러스터와 상호작용할 수 있도록 API 실행

- 클러스터의 상태를 저장

- 클러스터 내의 모든 노드와 조정을 통해 컨테이너 스케줄링(시작, 중지, 재시작)

Kind를 이용한 Kubernetes 사용하기

1. WSL2 설치하기 - Internet 검색 후 설치

2. Kind, Kubectl, Helm 등등 설치하기

# 기본 사용자 디렉터리 이동
cd $PWD
pwd

#
sudo systemctl stop apparmor && sudo systemctl disable apparmor

#
sudo apt update && sudo apt-get install bridge-utils net-tools jq tree unzip kubectx kubecolor -y

# Install Kind
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.29.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind
kind --version

# Install kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv ./kubectl /usr/bin
sudo kubectl version --client=true

# Install Helm
curl -s https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
helm version

# Source the completion
source <(kubectl completion bash)
echo 'source <(kubectl completion bash)' >> ~/.bashrc

# Alias kubectl to k
echo 'alias k=kubectl' >> ~/.bashrc
echo 'complete -o default -F __start_kubectl k' >> ~/.bashrc

# Install Kubeps & Setting PS1
git clone https://github.com/jonmosco/kube-ps1.git
echo -e "source $PWD/kube-ps1/kube-ps1.sh" >> ~/.bashrc
cat <<"EOT" >> ~/.bashrc
KUBE_PS1_SYMBOL_ENABLE=true
function get_cluster_short() {
echo "$1" | cut -d . -f1
}
KUBE_PS1_CLUSTER_FUNCTION=get_cluster_short
KUBE_PS1_SUFFIX=') '
PS1='$(kube_ps1)'$PS1
EOT

# .bashrc 적용을 위해서 logout 후 터미널 다시 접속 하자
exit

3. Kind 실행하기

# 클러스터 배포 전 확인
docker ps

# Create a cluster with kind
kind create cluster

# 클러스터 배포 확인
kind get clusters
kind get nodes
kubectl cluster-info

# 노드 정보 확인
kubectl get node -o wide

# 파드 정보 확인
kubectl get pod -A
kubectl get componentstatuses

# 컨트롤플레인 (컨테이너) 노드 1대가 실행
docker ps
docker images

# kube config 파일 확인
cat ~/.kube/config
혹은
cat $KUBECONFIG # KUBECONFIG 변수 지정 사용 시

# nginx 파드 배포 및 확인 : 컨트롤플레인 노드인데 파드가 배포 될까요?
kubectl run nginx --image=nginx:alpine
kubectl get pod -owide

# 노드에 Taints 정보 확인
kubectl describe node | grep Taints
Taints: <none>

# 클러스터 삭제
kind delete cluster

# kube config 삭제 확인
cat ~/.kube/config
혹은
cat $KUBECONFIG # KUBECONFIG 변수 지정 사용 시

Kubernetes for Developers - 2장 정리

Changby — Sun, 13 Jul 2025 14:54:35 +0900

Docker Container Build

개발 환경 설정

WSL2에 Docker install

sudo apt update -y
sudo apt upgrade -y

sudo apt install -y apt-transport-https ca-certificates curl software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update -y

sudo apt install -y docker-ce docker-ce-cli containerd.io

sudo usermod -aG docker $USER

sudo service docker start

Example 2.5

FROM python:3
COPY . /app
WORKDIR /app

※ 베이스 이미지란?

2.5 예제에서 사용된 베이스 이미지인 파이썬은 도커파일을 통해 빌드됐으며 파이썬 프로그램을 실행하는데 필요한 모든 것을 갖춘 환경을 제공. Docker Hub에서 제공하는 컨테이너 이미지의 경우 도커파일 출처가 연결돼 있어 구성방식을 확인할 수 있다. 베이스 이미지로 스크래치(Scratch)라는 아무 파일도 없는 완전히 비어있는 특별한 이미지를 사용할 수 도 있지만 일반적으로 기타 다른 베이스 이미지(예: 파이썬, 우분투 등)로 시작하는 경구가 대부분.

그 외

디펜던시 추가 가능 - 베이스 이미지 외 애플리케이션에서 필요한 모든 디펜더시를 설치하여 사용 가능.

도커 내부에서 코드 컴파일 - 자바, .NET, 스위프트(Swift) 및 C++와 같이 컴파일이 필요한 프로그램은 도커 내부에서 컴파일 가능.

OpenJDK를 베이스 이미지로 시작점에 활용하고 COPY 명령을 통해 애플이케이션을 복사.

다단계 빌드로 컴파일 가능 - Multi-Stage container build.

※자체 개발 애플리케이션 컨테이너화하기

직접 개발한 애플리케이션을 컨테이너화하는 경우 다음과 같은 일반적인 단계에 따라 수행한다.

1. 가능한 많은 설정 환경을 제공하는 이상적인 베이스 이미지를 찾는다. Ruby on Rails 애플리케이션의 경우 일반적인 우분투가 아닌 베이스 이미지로 루비를 사용하여 시작한다. Django의 경우 파이썬을 베이스 이미지로 사용한다.

2. 필요한 애플리케이션별 디펜던시를 구성한다.

3. 애플리케이션을 복사한다.

도커컴포즈 사용하기

논리그룹으로 구성된 여러 개의 컨테이너를 구성하거나 해제하고, 실행과정에서 런타임 설정을 보존할 수 있는 작은 규모의 오케스트레이터.

로컬 환경의 테스트에 매우 유용.

※메모

컴파일된 코드의 경우 볼륨 바인딩 기능이 별로 도움이 되지 않을 수 있다. 바이너리를 로컬에서 빌드하여 컨테이너에서 해당 바이너리를 교체할 수 있지만 도커를 통해 모든 것을 빌드하려고 하는 경우(또는 로컬 환경과 컨테이너 간에 아키텍처 차이가 존재하는 경우) 볼륨 바인딩은 큰 도움이 되지 않음.

Kubernetes for Developers - 1장 정리

Changby — Sun, 13 Jul 2025 12:14:37 +0900

컨테이너의 장점

1. 언어 유연성

컨테이너는 개발자들을 특정 언어에 종속되지 않음.

배포 시스템과 라이브러리 요구사항 분리, 다양한 언어와 패키지 쉬운 업데이트하거나 사용 가능
개발자들은 특정 언어나 버전에 얽매이지 않고 자유롭게 작업 가능

전통적인 PaaS(Platform as a Service) 환경처럼 오래된 운영체제의 디펜던시를 지속적으로 사용할 필요가 없어짐

2. 오버헤드 없는 격리

과거에는 VM을 사용하여 애플리케이션을 격리했지만, VM은 OS 커널을 복제해야 하므로 리소스 오버헤드가 크고 이미지 크기도 매우 큼.
반면, 컨테이너는 VM보다 경량화되어 있으며, 동일한 리소스 격리 이점 제공.

쿠버네티스 환경에서는 컨테이너가 호스트 리소스를 효율적으로 사용할 수 있어, 인프라 비용을 절감가능.

3. 개발자 효율성

컨테이너는 디펜던시를 호스트 환경에서 분리하여 개발자가 애플리케이션을 더 효율적인 개발가능.

예를 들어, 도커를 사용하면 리눅스 애플리케이션을 윈도우나 macOS에서 개발 가능함.
설치 과정도 간단하여 도커 설치 후 코드 복사, 빌드 및 실행만으로 개발 환경을 빠르게 구축.

4. 재현성

컨테이너는 애플리케이션 환경을 쉽게 재현할 수 있게 해주어, 동일한 환경에서 애플리케이션을 실행하고 테스트.

이를 통해 개발 및 운영 환경 간의 차이를 최소화할 수 있습니다.

쿠버네티스

쿠버네티스(Kubernetes)는 컨테이너를 효율적으로 관리하고 오케스트레이션하는 시스템.

노드(서버)의 클러스터를 구성하여, 여러 컨테이너를 효과적으로 실행하고 관리할 수 있도록 도움.

1. 자동화된 운영

쿠버네티스는 자동으로 컨테이너를 모니터링하고 충돌이 발생하면 재시작.

Liveness Probe와 Readiness Probe를 통해 컨테이너의 상태를 지속적인 점검.
Pod Autoscaler는 사용량에 따라 파드의 수를 자동으로 증가시켜 시스템의 효율성을 높임.

2. 높은 확장성

쿠버네티스는 다양한 규모의 클러스터를 구성 가능.

소규모 클러스터에서부터 수만 개의 CPU를 가진 대규모 클러스터까지 모두 지원

확장성이 뛰어난 애플리케이션을 쉽게 배포.

3. 워크로드 추상화

IaaS(Infrastructure as a Service)와 다르게 쿠버네티스는 하드웨어 수준을 추상화.

개발자는 하드웨어와 직접 상호작용하지 않고 API를 통해 소프트웨어를 구성하고 관리.

4. 선언적 구성

쿠버네티스는 선언적 리소스 모델을 사용하여, 사용자가 설정 파일(YAML)을 통해 원하는 상태를 정의

쿠버네티스가 이를 자동으로 실행하고 관리합니다.
이는 명령형 방식과 다르게, 시스템이 스스로 원하는 상태를 유지하도록 도움.

5. 비용 효율성

쿠버네티스는 VM과 같은 물리적 자원 위에서 여러 애플리케이션 인스턴스를 효율적인 실행, 비용 측면에서 매우 유리.
다양한 애플리케이션을 동일한 호스트에서 실행할 수 있어, 인프라 비용을 크게 절감 가능함.

6. 확장성

쿠버네티스는 확장성이 뛰어난 API를 제공하여, 비즈니스 로직에 맞는 맞춤형 구성과 확장이 가능.
Custom Resource Definition(CRD) 및 Operator 패턴을 통해 쿠버네티스를 더욱 강력하게 확장할 수 있습니다.

7. 오픈소스

쿠버네티스는 CNCF(Cloud Native Computing Foundation)의 인증을 따르며, 이를 통해 이식성과 호환성이 뛰어난 시스템을 제공합니다.
오픈소스이므로 누구나 자유롭게 사용하고, 기여할 수 있습니다.

8. 맞춤형 워크플로

배포에서부터 복잡한 CI/CD 파이프라인, 보안 스캐닝까지 원하는 워크플로우를 구성 가능.
배포가 간단하지는 않지만, 다양한 빌딩 블록을 사용해 유연한 환경을 구축.