언젠가는 풍성해질 개발블로그

[홈 서버 구축] Linux Node Exporter와 Prometheus·Grafana 설치

Hun's blog — Thu, 17 Sep 2026 08:50:12 +0900

들어가며

최근 서버로 활용하기 좋은 PC를 한 대 얻게 되어 직접 홈 서버를 구축해 보려고 한다.

주된 목적은 친구들과 함께 즐길 마인크래프트 서버를 운영하는 것이다. 하지만 직업이 직업인 만큼 단순히 게임 서버만 실행하는 데 그치지 않고, Ubuntu 기반 운영체제에 모니터링 스택까지 구성해 제대로 운영해 볼 생각이다.

나아가 기회가 된다면 Ansible을 이용해 서버 설정을 코드로 관리하고, 필요할 때 언제든 동일한 환경을 재현할 수 있도록 구성 자동화까지 진행해 보는 것이 이번 시리즈의 목표다.

이번 포스트에서는 Ubuntu가 설치된 PC에 Node Exporter를 구성하고, 시스템 메트릭을 Prometheus로 수집한 뒤 Grafana 대시보드로 시각화하는 과정까지 다룬다.

Node Exporter를 비롯한 각 구성 요소는 컨테이너가 아닌 Linux systemd 서비스 방식으로 설치할 예정이다. 특별한 기술적 이유가 있는 것은 아니다. 회사에서 Docker Compose와 Kubernetes를 주로 사용하고 있어서, 이번에는 호스트에서 서비스를 직접 구성하고 관리해 보고 싶었다. 결국 가장 큰 이유는 그냥 내 마음이다.

사용 장비

HP ProDesk 400 G7 소형 폼 팩터

모델: HP ProDesk 400 G7 SFF
CPU: Intel Core i5-10400 — 6코어 12스레드, 2.9GHz·최대 4.3GHz
메모리: DDR4 24GB — 16GB + 8GB
저장장치: 500GB
내장 그래픽: Intel UHD Graphics 630
운영체제: Ubuntu

Node Exporter 설치

먼저 홈 서버의 CPU, 메모리, 디스크, 네트워크 등의 상태를 수집하기 위해 Node Exporter를 설치한다.

Node Exporter는 Linux 시스템의 하드웨어 및 운영체제 정보를 Prometheus 형식의 메트릭으로 제공하는 Exporter다. 기본적으로 9100 포트를 사용하며, Prometheus는 이 엔드포인트에 주기적으로 접근해 메트릭을 수집한다.

전용 사용자 생성

Node Exporter를 별도의 사용자 권한으로 실행하기 위해 로그인할 수 없는 시스템 사용자를 생성한다. 이는 서비스를 불필요한 root 권한으로 실행하지 않기 위함이다.

sudo useradd \
  --system \                 # 일반 사용자가 아닌 시스템 계정
  --user-group \             # 같은 이름의 전용 그룹 생성
  --no-create-home \         # 홈 디렉터리를 만들지 않음
  --shell /usr/sbin/nologin \ # 직접 로그인하지 못하도록 제한
  node_exporter

생성된 사용자는 다음과 같이 확인할 수 있다.

Node Exporter 다운로드 및 설치

이 글에서는 1.12.1 버전을 설치할 예정이고, 서버의 CPU가 Intel x86-64 아키텍처이므로 linux-amd64 파일을 사용한다.

# 임시 디렉토리로 이동
cd /tmp

# Node Exporter 다운로드
wget "https://github.com/prometheus/node_exporter/releases/download/v1.12.1/node_exporter-1.12.1.linux-amd64.tar.gz"

# 압축 해제
tar -xzf "node_exporter-1.12.1.linux-amd64.tar.gz"

# 실행 파일 설치
sudo install \
  -m 0755 \
  "node_exporter-1.12.1.linux-amd64/node_exporter" \
  /opt/node_exporter/node_exporter

설치 경로(/opt/node_exporter)로 가서 설치되었는지 다음과 같이 확인한다.

Systemd 서비스 등록

Node Exporter가 서버 부팅 시 자동으로 실행되도록 systemd 서비스로 등록한다.

sudo nano /etc/systemd/system/node_exporter.service

서비스 파일에 다음 내용을 작성한다.

[Unit]
Description=Prometheus Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/opt/node_exporter/node_exporter
Restart=on-failure
User=node_exporter
Group=node_exporter

[Install]
WantedBy=multi-user.target

파일을 저장한 뒤 systemd 설정을 다시 불러오고 Node Exporter를 실행한다.

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

서비스 상태 확인

다음 명령으로 서비스가 정상적으로 실행되고 있는지 확인한다.

sudo systemctl status node_exporter

출력에 active (running)이 표시되면 서비스가 정상적으로 실행된 것이다.

Node Exporter는 기본적으로 9100 포트의 /metrics 경로를 통해 메트릭을 제공한다. 다음 명령으로 실제 응답을 확인한다.

curl http://localhost:9100/metrics

Prometheus 설치 및 연동

Node Exporter가 정상적으로 시스템 메트릭을 제공하는 것까지 확인했다. 이제 해당 메트릭을 주기적으로 수집하고 저장할 Prometheus를 설치한다.

Prometheus 역시 Node Exporter와 마찬가지로 전용 사용자와 systemd 서비스를 이용해 실행한다. Prometheus 버전은 현재 LTS인 3.13.3을 사용하고, 관련 파일은 모두 /opt/prometheus 아래에 구성한다.

전용 사용자 생성

Prometheus가 root 권한으로 실행되지 않도록 전용 시스템 사용자를 생성한다.

sudo useradd \
  --system \
  --user-group \
  --no-create-home \
  --shell /usr/sbin/nologin \
  prometheus

생성된 계정을 확인한다.

Prometheus 3.13.3 다운로드

# 임시 디렉터리로 이동
cd /tmp

# Prometheus 3.13.3 다운로드
wget "https://github.com/prometheus/prometheus/releases/download/v3.13.3/prometheus-3.13.3.linux-amd64.tar.gz"

# 압축 해제
tar -xzf "prometheus-3.13.3.linux-amd64.tar.gz"

실행 파일 설치

Prometheus를 설치할 디렉토리를 생성한다.

sudo mkdir -p /opt/prometheus
sudo mkdir -p /opt/prometheus/data

압축을 해제한 디렉터리에서 실행 파일을 설치한다.

sudo install \
  -m 0755 \
  "prometheus-3.13.3.linux-amd64/prometheus" \
  /opt/prometheus/prometheus

sudo install \
  -m 0755 \
  "prometheus-3.13.3.linux-amd64/promtool" \
  /opt/prometheus/promtool

기본 설정 파일도 /opt/prometheus로 복사한다.

sudo install \
  -m 0755 \
  "prometheus-3.13.3.linux-amd64/prometheus.yml" \
  /opt/prometheus/prometheus.yml

다음과 같이 뜨면 정상적으로 설치된 것이다.

Node Exporter 수집 설정

이제 Prometheus가 Node Exporter의 메트릭을 수집하도록 스크랩 설정을 진행한다.

sudo nano /opt/prometheus/prometheus.yml

Prometheus 자체 메트릭과 Node Exporter 메트릭을 수집하도록 다음과 같이 작성한다.

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets:
          - localhost:9090

  - job_name: node_exporter
    static_configs:
      - targets:
          - localhost:9100

Prometheus와 Node Exporter가 같은 서버에서 실행되고 있으므로 수집 대상에는 localhost를 사용했다.

그리고 promtool 을 통해 설정 파일의 문법 오류를 검증할 수 있다.

sudo /opt/prometheus/promtool \
  check config /opt/prometheus/prometheus.yml

다음과 같이 SUCCESS가 표시되면 설정 파일에 문제가 없는 것이다.

SUCCESS: /opt/prometheus/prometheus.yml is valid prometheus config file syntax

systemd 서비스 등록

이제 Prometheus를 systemd 서비스에 등록해서 자동으로 관리되도록 하자.

sudo nano /etc/systemd/system/prometheus.service

다음 내용을 작성한다.

[Unit]
Description=Prometheus Monitoring
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/opt/prometheus/prometheus \
  --config.file=/opt/prometheus/prometheus.yml \
  --storage.tsdb.path=/opt/prometheus/data
Restart=on-failure
User=prometheus
Group=prometheus

[Install]
WantedBy=multi-user.target

설정을 적용하고 서비스를 실행한다.

sudo systemctl daemon-reload
sudo systemctl enable --now prometheus

실행 상태 확인

실행 상태를 확인할 예정인데, systemctl status 로 확인하는 것도 좋지만 바로 Prometheus 웹 UI로 들어가서 확인하겠다.

브라우저에서 다음 주소로 접속한다.

http://localhost:9090/targets

prometheus와 node_exporter가 모두 UP으로 표시되면 정상적으로 메트릭을 수집하고 있는 것이다.

이제 쿼리화면에서 다음 PromQL을 실행해서 정상적으로 쿼리를 보내는지도 확인한다.

up{job="node_exporter"}

결과가 1이면 Prometheus와 Node Exporter의 연동이 완료된 것이다.

Grafana 설치 및 Prometheus 연동

마지막으로 Prometheus에 저장된 메트릭을 시각화하기 위해 Grafana를 설치한다.

Grafana는 이전 두 서비스와 다르게 공식 APT 저장소를 이용해서 설치해야 한다. Grafana 패키지는 앞선 두 서비스와 달리 전체 사용자와 systemd 서비스까지 함께 구성해준다.

Grafana 저장소 추가

먼저 저장소를 추가하는 데 필요한 패키지를 설치한다.

sudo apt-get install -y \
  apt-transport-https \
  wget \
  gnupg

Grafana 저장소의 GPG 키를 내려받는다.

http://localhost:3000/login

sudo mkdir -p /etc/apt/keyrings

sudo wget \
  -O /etc/apt/keyrings/grafana.asc \
  https://apt.grafana.com/gpg-full.key

sudo chmod 644 /etc/apt/keyrings/grafana.asc

Grafana 공식 stable 저장소를 추가한다.

echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" \
  | sudo tee /etc/apt/sources.list.d/grafana.list

Grafana 설치 및 실행 확인

패키지 목록을 갱신하고 Grafana OSS를 설치한다.

sudo apt-get update
sudo apt-get install -y grafana

sudo systemctl daemon-reload
sudo systemctl enbale --now grafana-server

이제 다음 주소로 들어가서 설치를 확인할 수 있다.

http://localhost:3000/login

초기 비밀번호는 아래와 같고 UI 에서 변경이 가능하다.

Id: admin
Password: admin

Prometheus 데이터 소스 추가

Node Exporter 대시보드를 추가 하기에 앞서, Grafana 가 Prometheus를 데이터 소스로 쓰기위한 설치부터 진행한다.

사이드바에서 Connections -> Data sources 를 클릭한다.

Add new data source 버튼을 누른다.

Prometheus 를 검색 후 선택하고, Connection 항목에 http://localhost:9100 을 기입한뒤 save&test 버튼을 누른다.

Data source 설정이 완료되면 Explore 에 들어가서 Prometheus 와 메트릭이 불러와지는 모습을 볼 수 있다.

Linux Node Exporter 대시보드 설정

이제 Linux Node Exporter 의 대시보드를 만든다. 이미 남이 잘 만들어 놓은 대시보드를 그대로 가져 와서 쓰겠다.

먼저 사이드바에서 Dashboard 를 선택한뒤, New -> Import dashboard 버튼을 누른다.

Import 에는 JSON을 사용하는 방식, 이미 Grafana 커뮤니티에 공개된 대시보드 id 이렇게 두 가지가 있다. 우리는 대시보드 ID 를 사용해서 Import 하겠다. 1860을 기입하고 Load를 눌러준다

이후 Import 버튼을 누른다.

그러면 Linux Node Exporter 가 설치되고 Prometheus가 수집하기 시작한 이후의 데이터들을 대시보드에서 확인 가능하다.

각 요소들의 정보는 다음에 기회가 있을 때 정리해보고자 한다. 그리고 추후에 이 3요소를 한번에 설치 가능한 Ansible 플레이북을 만들까 싶다. 분명히 도움이 될 것 같다.

[쿠버네티스] Nginx Gateway Fabric 정리 및 설치

Hun's blog — Wed, 2 Sep 2026 21:00:49 +0900

Nginx Gateway Fabric 개요

NGINX Gateway Fabric(NGF)는 Gateway API를 구현한 구현체다. Kubernetes 커뮤니티가 유지하던 ingress-nginx의 지원 종료 이후, Gateway API로 전환하기 위한 대안으로 주목받고 있다.

NGF는 컨트롤 플레인과 데이터 플레인으로 역할을 확실히 나누고 있다. 컨트롤 플레인은 Gateway, HTTPRoute 등 Kubernetes 리소스를 지속적으로 감시하며, 데이터 플레인에 필요한 설정과 컴포넌트를 동적으로 구성한다. 데이터 플레인은 실제 트래픽 흐르고 처리하는 영역으로 Nginx 인스턴스 가 포함된다.

NGF는 기존 Ingress처럼 LoadBalancer나 NodePort 뒤에서 트래픽을 라우팅하지만, 라우팅 규칙과 컨트롤러 설정을 한 곳에 모아두는 모놀리식 한 구조가 아니라는 점에서 차이가 있다.

이번 글에서는 NGF의 기본 개념을 간단히 살펴본 뒤, Host 라우팅 방식으로 설정하고 MetalLB와 연결하는 과정, 마지막으로 /etc/hosts 설정까지 실습해 볼 예정이다.

Nginx Gateway Fabric 아키텍처

앞서 언급했듯이 NGF는 컨트롤 플레인(Control Plane)과 데이터 플레인(Data Plane)으로 나눌 수 있다. 인프라 담당자나 개발자가 Gateway, HTTPRoute와 같은 리소스를 적용하면, 컨트롤 플레인이 이를 지속적으로 감시하고 데이터 플레인 구성을 동적으로 반영한다.

클라이언트들의 요청은 데이터 플레인의 NGINX 인스턴스를 거쳐 라우팅 된다. 이 과정에서 Gateway는 NGINX 인스턴스를 구성하는 역할을, HTTPRoute는 실제 라우팅 규칙을 정의하는 역할을 담당한다고 보면 된다.

출처: https://www.f5.com/company/blog/nginx/announcing-nginx-gateway-fabric-release-1-2-0

Gateway API vs Ingress

Gateway API의 구현체인 NGF 와 Ingress의 구현체인 ingress-nginx는 리소스를 작성하는 방식에서 가장 큰 차이를 보인다.

Ingress 는 하나의 리소스 안에 라우팅 대상과 규칙을 함께 정의하는 방식이라, Controller가 이를 해석해 트래픽을 처리한다. 즉, 외부 요청이 어떤 서비스로 전달되어야 하는지에 대한 설정을 Ingress 리소스에 직접 작성해야 한다.

예를 들어 Ingress-nginx 는 아래와 같이 작성할 수 있다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80

이 방식은 중앙집중식으로 관리할 수 있다는 장점이 있다. 반면 협업 측면에서는 아쉬운 부분도 있다. 개발자 측에서 라우팅 규칙이 자주 바뀌는 경우, 인프라 엔지니어가 매번 설정을 수정해야 하기 때문이다.

또한 모놀리식한 구조에서는 작은 휴먼 에러도 큰 장애로 이어질 수 있다. 특히 클러스터의 진입점을 다루는 설정인 만큼, 더욱 민감하게 관리할 필요가 있다.

이러한 이유로 Gateway API 방식에서는 기능을 여러 리소스로 나누었고, NGF 역시 다음과 같은 리소스 구조를 따른다.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: sample-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: app.example.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: sample-httproute
spec:
  parentRefs:
  - name: sample-gateway
  hostnames:
  - app.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: app-service
      port: 80

이렇게 리소스의 역할을 나눔으로써, 인프라 엔지니어와 개발자 간의 책임과 역할을 확실히 할 수 있으며, 모놀리식 방식에 따른 리스크도 줄일 수 있다.

이해하기 쉽도록 다음 그림을 참고하기를 바란다.

출처: https://blog.nginx.org/blog/5-things-to-know-about-nginx-gateway-fabric

Nginx Gateway Fabric 실습

이번 실습은 Helm 으로 진행할 예정이며, 진입점을 위한 LoadBalancer 혹은 NodePort 가 필요하다. 필자는 MetalLB로 진행할 예정이다.

사전 준비

Gateway API 리소스는 쿠버네티스 표준으로 정의되어 있지 않으므로 따로 설치를 진행해야한다.

kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v2.6.7" | kubectl --kubeconfig .kube/config apply -f -

설치

helm chart를 설치하기에 앞서 Gateway 리소스 부터 정의하겠다. Gateway 를 정의하는 방법은 매니패스트를 만들고 kubectl apply 를 하든가, helm value에 gateways 배열에 기입하는 방법이 있다.

여기서는 후자로 진행한다.

# 데이터 플레인 Service 노출 방식.
# 기본값이 type: LoadBalancer 이므로 MetalLB 가 IP 를 할당한다.
# nginx:
#   service:
#     type: NodePort
#     nodePorts:
#       - port: 30080
#         listenerPort: 80

gateways:
  - name: nginx-gateway
    namespace: kube-system
    spec:
      gatewayClassName: nginx
      listeners:
        - name: http
          port: 80
          protocol: HTTP
          allowedRoutes:
            namespaces:
              from: All

이제 helm chart 를 배포해 보자. OCI 레지스트리로 배포되므로 레포를 추가할 필요는 없다.

helm upgrade --install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric `
  --version 2.6.7 `
  --namespace nginx-gateway `
  --create-namespace `
  --values helm/nginx-gateway-fabric/values.yaml

정상적으로 설치가 되었다면 kube-system 네임스페이스와 nginx-gateway 네임스페이스에 각각 다음과 같은 파드와 서비스가 생겼을 것이다.

서비스를 잘 보면 nginx-gateway-nginx에 외부 IP가 부여된 모습을 볼 수 있다. 즉 이 부분이 데이터 플레인이 되고 ngf-nginx-gateway-fabric이 컨트롤 플레인이 되는 것으로 이해하면 된다.

라우팅 규칙 정의

지금 까지는 외부 로드밸런서를 통해 외부에 진입점을 여는 Gateway를 만들었다면 지금부터는 내부 서비스로의 라우팅을 위한 라우팅 규칙을 정의할 것이다.

필자의 클러스터에는 이미 Grafana 대시보드가 설치되어 있으므로 Grafana에 라우팅 규칙을 만들어서 Host 기반 라우팅을 설정할 예정이다.

참고로 라우팅 규칙은 애플리케이션의 영역에 가까움으로 Grafana IaC와 함께 보관하면 좋다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: grafana-route
  namespace: monitoring
spec:
  parentRefs:
  - name: nginx-gateway
    namespace: kube-system
    sectionName: http
  hostnames:
  - "grafana.virtualbox.io"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: prometheus-grafana
      port: 80

설정을 마쳤다면, HTTPRoute 리소스로 다음과 같이 설정되었을 것이다.

접속 및 확인

Host 기반 라우팅으로 설정했으므로, DNS 서버 혹은 로컬 DNS 매핑이 필요하다.

필자의 실습환경은 윈도우 11 이므로 C:\Windows\System32\drivers\etc에 '192.168.56.20 grafana.virtualbox.io'를 추가했다.

이제 접속해 보니 정상적으로 Grafana에 접근이 되었다!

[쿠버네티스] MetalLB 정리 및 설치 방법

Hun's blog — Mon, 31 Aug 2026 21:00:01 +0900

MetalLB 개요

MetalLB는 베어메탈 환경(클라우드 환경은 거의 지원하지 않음)에서 클러스터 내부에 진입점을 마련하기 위한 LoadBalancer이다. 주로 Ingress Controller 혹은 API Gateway 와 같이 배치되며, LoadBalancer가 외부 트래픽을 진입시키면, Ingress Controller가 분배하는 개념이다.

MetalLB는 두 가지 모드(L2, BGP)를 지원하는데, 두 모드의 핵심 차이는 VIP(Virtual IP)를 외부 네트워크에 알리는 방식에 있다.

L2 모드

L2 모드는 서비스마다 speaker 하나가 리더로 뽑혀서 ARP로 응답, 그 노드로만 트래픽을 집중하는 방식이다.

L2 모드

L2 모드 장점

설정이 간단 (라우터 BGP 지원 불필요)
어떤 네트워크 환경에서도 동작

L2 모드 단점

로드 밸런싱 안 됨
리더 노드 대역폭이 병목
failover 느림 (ARP 캐시 갱신 대기)
클라이언트와 같은 L2 네트워크에 있어야 함

BGP 모드

BGP 모드는 서비스를 서빙하는 모든 노드의 speaker가 동시에 라우터와 BGP 세션을 맺고 동일 VIP를 광고하면, 라우터가 ECMP로 트래픽을 여러 노드에 분산하는 방식이다.

BGP 모드

BGP 모드 장점

로드밸런싱을 지원 (여러 노드로 트래픽 분산)
failover 빠름
L2 제약 없음 (다른 서브넷/라우팅 환경에서도 동작)

BGP 모드 단점

라우터가 BGP/ECMP를 지원해야 함
설정 복잡
네트워크 팀/장비 협조 필요

MetalLB 설치 실습

실습에서는 L2 방식만 설치할 예정이며, Nginx 를 띄워 접근이 되는지 까지 테스트 해볼 예정이다.

설치 방법

Kubernetes v1.14.2 이후에 kube-proxy 를 IPVS 모드로 사용중이라면 strict ARP mode를 켜준다.

kubectl edit configmap -n kube-system kube-proxy

# 해당 부분을 추가 혹은 설정 해준다.
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true

metalLB 시스템을 위한 기본 컴포넌트들을 세팅 해준다.

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.16.1/config/manifests/metallb-frr-k8s.yaml

이외에 추가적으로 VIP(Virtual IP Address)로 사용 될 IP 풀과 광고 방식을 설정하는 리소스를 만든다.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: sandbox
  namespace: metallb-system
spec:
  addresses:
    - 192.168.56.20-192.168.56.30
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: local
  namespace: metallb-system
spec:
  ipAddressPools:
  - sandbox

설치 결과

정상 설치가 완료되면 다음과 같이 확인할 수 있다.

각 파트를 정리하면 다음과 같다.

구성 요소	개수	리소스 타입	주 역할
controller	1	Deployment	LoadBalancer Service에 외부 IP를 할당하고 MetalLB CR을 조정
speaker	노드 당 1	DaemonSet	각 노드에서 광고 대상과 상태를 관리하고 FRR 설정을 연동
frr-k8s-daemon	노드 당 1	DaemonSet	실제 FRR/BGP 라우팅 데몬 실행
frr-k8s-statuscleaner	1	Deployment	FRR 관련 상태 리소스 정리
webhookservices	2	ClusterIpService	MetalLB/FRR 설정 CR 생성·수정 시 검증

로드 밸런서 서비스 연결

이제 nginx 하나 띄우고 LoadBalancer 타입으로 서비스를 만들어서 외부와 연결해보자

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-loadbalancer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-loadbalancer
  template:
    metadata:
      labels:
        app: nginx-loadbalancer
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: nginx-loadbalancer
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP

적용 후에, nginx-loadbalancer 서비스를 보면 EXTERNAL-IP가 잡혀있는 모습을 볼 수 있다.

curl 을 통해서 nginx 에 접근이 가능한지 확인을 하고 이번 실습을 마치고자 한다.

[쿠버네티스] Grafana Loki 정리

Hun's blog — Tue, 21 Jul 2026 18:55:58 +0900

사내 클러스터에서 로그를 중앙집중식으로 수집하기 위한 모니터링 플랫폼이 필요했다. 여러 대안 중 Loki가 괜찮은 선택지로 보여, 본격적인 도입에 앞서 사용자 관점에서 최소한으로 알아야 할 내용을 정리해보고자 한다.

이 글은 필자가 나중에 다시 읽었을 때 빠르게 기억을 되살릴 수 있도록 작성한 개인 맞춤형 정리 글이며, 개념 설명이나 내용에 빈틈이 있을 수 있다.

Loki 개요

Loki는 수평 확장 가능한, 고가용성, 멀티 테넌트 로그 집계 시스템이다.
보통 Promtail이나 Grafana Alloy와 같은 수집기를 통해 로그를 Loki에 저장하고, Grafana에서 쿼리하여 시각화한다.
Loki는 로그 내용을 인덱싱하는 대신 라벨만 인덱싱함으로써, 효율적이고 운영이 쉬운 로그 플랫폼을 제공한다.

무엇을 할 수 있는가?

여러 에이전트(Promtail, Grafana Alloy)를 통해 여러 서버, 클러스터에서 나오는 로그를 하나의 Loki로 모을 수 있다.
app, env, cluster, namespace 와 같은 라벨을 기준으로 특정 서비스, 환경, 클러스터의 로그만 빠르게 필터링할 수 있다.
Loki를 Grafana 데이터 소스로 붙이고 시간 단위로 쿼리해 로그를 조회할 수 있다.특정 조건(에러 등)을 만족하면 Aletermanager/Grafana Aletering 으로 알림을 받을 수 있다.

언제 도입하면 좋은가?

K8s 클러스터에서 로그가 노드별로 흩어져 있어, 장애 발생 시 각 서버에 접속해 로그를 찾아야 하는 환경일 때
K8s Pod가 재시작·스케일링을 자주하여, 특정 Pod의 로그를 한 번에 모아 보기가 어려울 때
K8s Pod 복제수를 2 이상으로 설정하여 로그가 여러 노드에 분산되어 있는 환경일 때
기존 ELK 사용 시 저장 비용이나 운영 복잡도 측면에서 부담을 느낄 때

아키텍처와 컨셉

Distributer

클라이언트(에이전트)로부터 들어오는 모든 로그 push 요청을 담당하는 쓰기 경로(write path)의 첫 엔드포인트이다. 요청 받은 스트림을 검증하고 전처리한 뒤, 일관 해싱 (consistent hashing)으로 대상 Ingester를 선택하여 복제 계수(replication factor)만큼 병렬 전송한다.

Distributor의 처리 흐름은 수신 -> 검증 -> 전처리 -> 처리율 제한 -> 대상 Ingester 선택 및 전달 -> 병렬 전달 -> 정족수 응답 확인 이 있다. 자세한 사항은 공식 문서를 참고하기를 바란다. 공식 문서

Ingester

Ingester 서비스는 쓰기 경로(write path)에서는 로그 데이터를 메모리에 청크 단위로 적재하고, 압축하여 S3, GC3 등 장기 스토리지로 전송하는 역할을 한다. 동시에 읽기 경로(read path)에서는 최근에 적재된, 아직 플러시되지 않은 인메모리 로그데이터를 쿼리에 응답하기 위해 사용된다.

Query frontend

Query frontend는 Loki의 읽기 경로(read path)를 가속하기 위해 사용하는 선택적(optional) 컴포넌트로, Querier 앞단에서 쿼리 요청을 받아 분산 처리하기 쉽게 만들어준다. 내부적으로는 쿼리를 큐에 적재하고, 필요한 경우 여러 구간으로 분할한 뒤, Querier가 이를 병렬로 처리할 수 있도록 중개한다.

Querier

Querier 서비스는 Loki에서 LogQL(Log Query Language) 쿼리를 실제로 실행하는 컴포넌트로, 읽기 경로(read path)의 핵심에 해당한다. Querier는 구성 방식에 따라 클라이언트의 HTTP 요청을 직접 받아 처리하거나, Query frontend/Query scheduler로부터 전달된 서브쿼리를 워커(worker)처럼 실행한 뒤 결과를 반환한다.

실행 모드

Loki는 규모에 따라 배포 구조를 다르게 가져갈 수 있다. 처음 도입할 때는 Monolithic으로 시작하고, 로그량이나 사용자가 늘어나면 SSD로 옮기는 흐름이 일반적이다.

Monolithic (SingleBinary)

Distributor, Ingester, Querier 등 Loki 컴포넌트를 하나의 프로세스/Pod로 실행하는 방식이다.
설정과 운영이 가장 단순하다. 개발 환경이나 로그량이 많지 않은 사내 클러스터에 적합하다.
Pod 하나에 장애가 나면 Loki 전체가 영향을 받으므로 고가용성 구성에는 맞지 않는다. 이 문서의 Helm 설치 예시는 이 방식을 기준으로 한다.

SSD (Simple Scalable Deployment)

컴포넌트를 `read`, `write`, `backend` 세 영역으로 나눠 배포하는 방식이다.
쓰기량이 많으면 `write`를, 조회 요청이 많으면 `read`를 각각 늘릴 수 있어 Monolithic보다 확장하기 쉽다.
데이터를 오브젝트 스토리지에 저장하는 구성을 전제로 하며, 운영 환경에서 가장 먼저 고려할 만한 배포 방식이다.
다만 저장소 설정과 운영할 Pod 수가 늘어나므로, 작은 환경에서는 Monolithic이 더 편할 수 있다.

[쿠버네티스] Longhorn 정리

Hun's blog — Sun, 5 Jul 2026 15:33:28 +0900

Longhorn 개요

LongHorn은 가볍고, 신뢰성 있고, 쉽게 사용할 수 있는 쿠버네티스 기반 분석 블럭 스토리지이다.
Rancher Labs 라는 회사에서 만들어 졌으나 현재는 CNCF에 기증되어 incubating 프로젝트이다.

무엇을 할 수 있는가?

여러 노드의 로컬 디스크를 하나의 풀로 관리하며, 데이터를 여러 노드에 복제할 수 있다.
노드에 데이터가 replica 되어 노드로 인한 단일 실패 지점을 해소 (고가용성)
NFS 혹은 S3를 통해 데이터를 백업할 수 있다.

언제 도입하면 좋은가?

스토리지 관련 리소스가 없을 때 (클라우드, SAN 포함)
온프레미스 환경에서 중소규모로 스토리지 환경이 필요할 때
동일한 데이터의 다중 접근이 드문 상황일 때 (다중 접근을 위해 블록 스토리지 위에 NFS 레이어를 얹기 때문에 성능 저하 발생)
간편하고 신속한 백업 및 재해 복구가 필요할때 (간편하게 nfs 혹은 s3 저장소에 볼륨 백업 가능)
쿠버네티스 네이티브한 스토리지 관리를 원할 때 (쿠버네티스의 동적 프로비저닝을 통해 볼륨 생성 및 사용 가능)
Local PVC 를 사용하자니 노드 장애로 인한 데이터 유실 및 가용성 저하가 우려될 때

Local PVC vs Longhorn 장단점 비교

Longhorn의 장점

노드 장애 시 데이터 자동 복구: Local PVC는 해당 노드가 죽으면 파드가 다른 노드로 이동해도 데이터에 접근할 수 없음
자유로운 파드 스케줄링: Local PVC는 특정 파드에 종속되지만, Longhorn은 어느 노드에서나 자유롭게 띄우고 이동가능
편리한 운영 기능 기본 제공: 볼륨 크기 자동 확장, 스냅샷 생성, 외부 저장소 백업 등 기능 제공

Longhorn의 단점

I/O 성능저하: Longhorn 은 데이터 쓰기 동작 시 모든 레플리카에게 동기적으로 적용함으로 I/O 성능이 Local PVC 보다 저하됨
추가 리소스 소모: 분산 스토리지 유지를 위한 CPU, 메모리를 일정 부분 소모

아키텍처와 컨셉

Longhorn은 크게 data plane과 control plane으로 나눌 수 있는데, Longhorn Engine이 data plane에 해당하고 Longhorn Manager가 control plane에 해당한다.

Longhorn Data read/write Flow

Longhorn CSI Plugin

쿠버네티스의 동적 프로비저닝 기능을 Longhorn과 연동 시켜주는 플러그인이다.
사용자가 storageClassName: longhorn 으로 PVC를 만들면 longhorn 과 연동시킨다.

Longhorn Manager

모든 노드에 하나씩 상주하며 Longhorn 클러스터 전체를 제어하는 데몬셋이다.
CSI Plugin 혹은 UI에 의한 요청에 맞춰 Longhorn ㅂ로륨 리소스 생성을 지시한다.
볼륨 생성이 확정되면 Engine(컨트롤러)과 Replica(복제본)을 띄우도록 지시한다.
사용자가 접속하는 Longhorn UI 나 쿠버네티스의 CSI 플러그인이 보내는 명령을 가장 앞단에서 받아 처리한다.

Longhorn Engine

볼륨 1개 만을 전담 관리하는 스토리지 컨트롤러이다.
애플리케이션 파드에 있는 노드에 가상의 블록 디바이스를 만들어 노출하여 kubelet 이 애플리케이션 파드와 바인드 마운트 해준다.
애플리케이션에 의해 볼륨에 쓰기(Write) 동작이 발생하면 Replica들에게 동기적으로 복제한다.
특정 노드의 Replica에 장애가 발생해도 다른 노드의 정상 Replica를 통해 애플리케이션에 중단 없이 고가용성을 제공한다.

Longhorn Replica

볼륨의 데이터를 노드의 물리적 디스크에 저장한다.
Longhorn Engine 에게 물리적인 데이터를 제공한다.
데이터 고가용성을 위해 설정된 복제본 개수(예: 3개)만큼 여러 노드에 분산되어 생성된다.

[트러블 슈팅] Docker 가 의문사 했다?

Hun's blog — Sat, 20 Jun 2026 16:43:40 +0900

사내 서비스를 운영 중인데 Docker 컨테이너가 죽어버렸다. 원인을 파악 해보자.

docker cli는 정상으로 보이나 docker.sock에 연결이 안 되는 걸로 봐서 docker daemon에 문제가 생긴것으로 보인다.

확실히 이상하다 Docker CLI는 있고 버전 확인도 되는데 서비스 인식이 불가능한 상황이다.

dpkg 로 확실히 docker 와 관련된 패키지들을 확인해 봐야겠다.

눈에 띄는 건 containerd.io와 docker-ce가 rc 상태라는 점이다. rc는 패키지는 제거됐지만 설정 파일은 남아있다는 뜻으로, 어떤 이유에서인지 이 두 패키지가 삭제된 것으로 확인된다.

참고로 containerd는 컨테이너 런타임인데, Docker는 이를 직접 패키징해서 containerd.io라는 이름으로 따로 배포하고 있다. Ubuntu 공식 저장소의 containerd와 소프트웨어 자체는 동일하지만 패키징 주체가 다르다.

해결 방법은 너무 간단하다 docker-ce 를 다시 설치해주면 되고 정상 동작한다.

하지만 containerd.io 와 docker-ce 가 삭제된 이유를 알지못하면 반복될 수 있으니 원인을 제대로 파악해보자.

일단 apt 패키지 매니저의 히스토리 로그를 열어서 docker-ce와 관련된 변경이 있는지 확인하자.

로그를 보면 containerd 가 설치되면서 containerd.io 와 docker-ce 가 함께 제거됐다. 최근 해당 서버를 K8s에 편입하는 작업을 준비하면서 컨테이너 런타임으로 containerd 를 설치했고, 이 과정에서 apt가 충돌 패키지인 containerd.io 를 자동으로 제거했으며 이제 의존하던 docker-ce 까지 연쇄적으로 삭제된 것으로 추측된다.

3줄 요약

docker ps 실패 원인을 추적한 결과, docker-ce와 containerd.io 패키지가 제거된 상태(rc)였다.
apt history 로그에서 containerd 설치 시 충돌로 인해 apt가 containerd.io와 docker-ce를 자동 제거한 것이 확인됐다.
해당 서버의 Kubernetes 편입 작업 중 컨테이너 런타임 교체가 원인으로 추측된다.

[파이썬] GIL: 무엇이고, 왜 필요하고, 왜 못 없애나

Hun's blog — Mon, 1 Jun 2026 10:21:26 +0900

파이썬을 처음 배울 때 파이썬은 멀티 스레드를 사용해도 병렬처리가 되지 않는다고 배웠다. 이것을 GIL이라고 배웠고, 단순히 인터프리터가 멀티스레드 환경에서 한 개의 스레드만 사용하도록 강제했고 우회할 대안으로는 multiprocessing 라이브러리를 사용해서 멀티 프로세스로 접근하라고 외웠다.

실무에서 파이썬을 다루면서 실제 내부 구조를 깊게 파악하고 싶다는 호기심이 생겼다. 특히 최근에 화두가 되고 있는 파이썬의 GIL 제거 시도부터 공부하면서 파이썬 내부를 분석해보고자 한다.

이번 포스트에서는 GIL의 정의와 역사, 그리고 초기 제거 시도에 대해서 다루고자 한다.

GIL(Global Interpreter Lock) 이란?

인터프리터 프로세스가 멀티 스레드 환경에서 하나의 스레드에게만 Lock을 부여하고 나머지는 대기시키는 방식

GIL이 필요한 이유

파이썬 인터프리터인 CPython은 참조 횟수(Reference Count)를 통해 메모리를 정리
특정 객체(문자열, 튜플, 리스트 등)가 변수에 할당되거나, 다른 함수 혹은 메소드의 인자로 전달되면 참조 + 1, 해제되면 -1 되는 참조 횟수 증감 연산을 하고 있음
참조 횟수가 0이 될 경우, 객체를 메모리에서 제거(free)
하지만 참조 횟수는 멀티 스레드 환경에서 동시 접근에 의해 경쟁 상태(Race Condition)에 빠질 수 있으며 각 스레드 참조 횟수의 정합성을 훼손할 수 있음
그래서 멀티 스레드 상황에서도 인터프리터당 하나의 스레드가 동작하도록 Lock을 부여하여 동시 접근을 방지함
이 외에도, 멀티스레드 환경에서 동기 접근에 안전한 Thread-Safe 한 조건을 요구하는 C Extension을 만족시키기 위함

GIL을 도입할 수 밖에 없는 현실적인 이유

파이썬이 첫 개발 되던 시절에는 단일 코어 중심의 하드웨어었고, 운영 체제 차원에서도 스레드라는 개념을 지원하지 않거나, 지원하더라도 구현 방식이 달랐음
파이썬의 주요 기능들은 C 언어로 구현되거나 C 라이브러리를 가져와서 사용
C Extension은 Thread-Safe 한 메모리 관리를 요구했고 GIL이 가장 적합하여 적용
시간이 지나 멀티 스레드 기술이 성숙해지고 하드웨어 사양이 충분해졌을 때, GIL로 인한 문제가 수면 위로 드러남
하지만 오랜 기간 동안 쌓인 레거시들의 하위 호환성을 고려했을 때 GIL을 제거하고 다른 방안을 도입하기 어려운 상황이 됨

GIL이 파이썬에게 의미있는 도입일 수도 있는 이유

Python이 개발 되던 당시 주류 언어는 C언어
Python이 GIL을 통해 C Extension을 사용할 수 있게 되고, 기존 C를 사용하던 개발자들이 Python으로 쉽게 넘어올 수 있도록 만듬
결과적으로 Python 커뮤니티는 성장할 수 있었고, 현재 AI, 데이터 분야에 대표적인 언어로 정착

GIL을 제거하려는 노력

GIL을 제거하려는 노력은 꾸준히 있어왔다. 크게는 1996년 Greg Stein의 free-threading 패치부터 PEP 703, PEP 779, PEP 803 같이 현재에도 시도를 하고 있지만 완전한 제거는 이루지 못했고, 선택적인 비활성화 수준의 기능을 제공하고 있다.

이번 글에서는 Greg Stein의 free-threading(1996)와 Larry Hasting의 Gilectomy(2016)을 먼저 다루고, 이후 포스팅에서 실제로 파이썬 운영위원회(Steering Council)에서 승인받은 PEP703와 이후 최신 현황에 대해서 다룰 예정이다.

Greg Stein의 free-threading

1996년 Greg Stein 은 Python 1.4 버전을 기반으로 GIL을 제거하고 멀티스레딩을 구현하기 위한 최초의 'free-threading' 패치를 시도했다. 그는 인터프리터 전체를 묶고 있던 거대한 Lock을 없애는 대신 다음과 같은 구조적 변화를 제안했다.

핵심 아키텍처

스레드 상태 격리
- 인터프리터의 전역 상태를 스레드의 독립된 상태로 편입
- 스레드 상태를 연결 리스트로 연결
- 스레드 상태를 조회 시, 리스트를 순회하며 스레드 ID를 탐색하고 리스트 맨 앞으로 이동시킨 후에 반환
참조 횟수 연산의 세분화된 자금 (Fine-Grained Locking)
- 참조 횟수 증감연산을 할 때 Lock을 부여
- 멀티 스레드 환경에서 동시 작업이 가능하지만 동시에 증감연산은 금지
- A 스레드가 I 객체의 참조 횟수를 증감연산 할 때 B 스레드가 J 객체의 참조 횟수를 증감 불가
가변(mutable) 객체들의 잠금
- 참조 횟수 연산에서는 전역 자물쇠를 사용하지만, 리스트나 딕셔너리 같은 가변 객체들은 개별적으로 Lock 부여
- 중첩 리스트에서는 Lock 해제를 재귀적으로 수행

결론

결과는 처참했다. 단일 스레드 작업은 1.9초에서 12.7초로, 멀티스레드 작업은 2.5초에서 18.5초로 늘어나며 기존 대비 약 6~7배의 성능 저하(속도 기준 85% 감소)를 기록했다 [1]. 성능이 급감한 결정적인 이유는 참조 횟수를 증감할 때마다 스레드별로 뮤텍스(Mutex) Lock을 매번 수행하면서 발생한 오버헤드 때문이었다. 비록 패치는 실패로 끝났지만, 이 시도를 계기로 파이썬 커뮤니티에는 'GIL을 제거하더라도 싱글 스레드의 성능을 희생시켜서는 안 된다'라는 철칙이 깊게 새겨지게 된다."

Larry Hasting의 Gilectomy

2016년 Larry Hasting은 Pycon에서 Gilectomy를 소개했다(Gilectomy는 GIL + ectomy (절제술)을 합친 합성어). 기존의 Greg Stein이 참조 횟수 연산을 할 때 모든 스레드가 접근 가능하되, 연산 시에 Lock을 부여하는 것과 달리, 한 스레드에 모든 참조 증감 연산의 책임을 위임하는 아이디어를 제안했다.

핵심 아키텍처

Buffered reference counting

하나의 스레드에 참조 횟수 증감 연산의 책임을 위임
다른 스레드들은 자신의 상태에 증감 연산 로그를 추가
증감 연산 담당 스레드가 모든 스레드의 로그를 취합하여 참조 횟수 연산을 수행

특이사항

처음에는 한 스레드에 증감 연산과 로그 상태 보관을 담당시켜, 다른 스레드들이 직접 로그를 작성시키려 함
이 과정에서 스레드끼리 쓰기 경쟁이 발생하여, 각 스레드에 로그를 분산 시킴
분산된 로그는 타임스탬프가 없어서 취합 시에 순서 문제가 발생
특히, 감소 -> 증가 환경에서는 문제가 심각 (0 -> -1 -> 0) <- 이미 객체가 삭제됨
그래서 모든 로그들 중 증가 연산을 먼저 수행하도록 수정
이 방법은 참조 횟수의 실시간성을 보장하지 못한다는 단점이 존재

결론

성능은 기존 CPython에 근접했다고 주장했으나 이를 뒷받침할 벤치마크 근거는 없었다. 게다가 C API와의 호환성 문제로 귀도 반 로섬과 의견 대립을 겪으며 결국 채택되지 못했다. 하지만 이 제안은 CPython 내부의 병목 지점을 구체화하고, C API 구조 개편의 필요성을 대두시키는 계기가 되었다.

다음 글 예고

Greg Stein과 Larry Hasting의 시도는 비록 반려되었지만, 파이썬 내부의 병목 지점을 확인하고 C API 개편의 필요성을 공론화하는 중요한 밑거름이 되었다.

다음 글에서는 이들의 한계를 극복하고 마침내 파이썬 표준에 채택된 PEP 703과 최신 No-GIL 동향을 다룬다. 과연 어떤 기술적 돌파구를 통해 싱글 스레드의 성능 저하 없이 GIL을 선택적으로 비활성화할 수 있었는지, 그 핵심 아키텍처를 자세히 알아볼 예정이.

[회고] 사용자가 아닌 나를 위한 설계였다

Hun's blog — Tue, 26 May 2026 17:41:25 +0900

이번 포스트는 웹 서비스를 유지보수하다 든 생각을 주저리주저리 적어볼 생각이다.

웹 서비스를 개발하고 운영하다 보면, 기획 단계에서 '많이 쓰이겠지' 싶었던 기능이 막상 출시 후엔 거의 사용되지 않는 경우가 있다. 그렇다고 없애버리기엔 가뭄에 콩 나듯 찾는 사용자가 있어, 애매하게 살아남은 기능들이 생기기 마련이다.

서비스에는 두 가지 동작 방식이 있는데, 데이터베이스에 연동해 결과를 저장하고 관리하는 DB 모드와, 별도 저장 없이 사용 후 휘발되는 Standalone 모드다.

문제의 기능은 Standalone 모드에만 존재했는데, 이 기능을 쓰려고 Standalone을 켜는 수준이었다. 이 기능 하나를 위해 4~5개의 페이지를 따로 만들고, API 쿼리 파라미터 분기 처리도 하면서 기술 부채도 심했다. 결국 Standalone 모드를 deprecated하고, 해당 기능을 DB 모드에 편입하기로 팀내 결정되었다.

문제는 다음이었는데 기존 DB는 애초에 이 기능을 크게 고려하지 않고 설계된 터라, 사용량도 많지 않은 기능 하나를 위해 DB를 준-재설계 수준으로 손봐야 할지, 아니면 로직으로 어떻게든 온몸 비틀기를 해야 할지 고민을 했다.

두 방식의 트레이드오프는 명확했다. DB 테이블을 수정하면 기존 DB 모드에서 제공하는 서드파티 기능들을 추가로 활용할 수 있지만, 변경 범위가 코드베이스의 절반에 가까울 만큼 방대했다. 반면 로직으로 온몸 비틀기를 택하면 코드량은 줄일 수 있지만, 서드파티 연동이 불가능해져 미래 요구사항에 유연하게 대응하기 어려워진다. 머릿속으로는 트레이드오프를 정리해두고 있었지만, 막상 결론을 내리려니 쉽지 않았다.

그때 팀장님이 한 가지 조언을 해주셨다. 실제 사용자에게 직접 물어보라는 것이었다. 이에 따라 현 사용자들을 대상으로 간단한 설문을 진행했다. 기능을 앞으로도 사용할 의향이 있는지, DB 모드로 편입될 경우 사용 빈도가 늘어날 것 같은지, 서드파티 기능에 대한 수요가 있는지를 물었다.

결과는 서드파티 기능에 대한 니즈는 아예 없었고, 사용자들이 가장 기대하는 건 이 기능이 DB 모드로의 편입, 그 자체였다. 설문 전까지만 해도 '확장성'과 '사용성'을 명분 삼아 DB 테이블을 수정하는 쪽으로 마음이 거의 기울어 있었는데, 그 선택이 아무도 쓰지 않는 거대하고 복잡한 서비스로 이어질 뻔했다는 걸 깨달았을 때 적잖이 충격이었다.

돌이켜보면, 그 결정의 이면에는 주니어로서 DB 스키마 수정 같은 굵직한 작업을 경험해보고 싶다는 욕심이 있었던 것 같다. '확장성'과 '사용성'이라는 그럴듯한 명분을 내세웠지만, 그 밑에는 그냥 해보고 싶다는 개인적인 동기가 깔려 있었다. 사용자가 원하는 것과 무관한 이유로 기술적 방향을 정하려 했던 셈이다. 합리적인 의사결정과는 거리가 멀었다. 뭐, 그런 기회는 나중에 더 적절한 때가 오겠지.

[자바스크립트] Math 객체

Hun's blog — Mon, 25 May 2026 17:08:38 +0900

실무에서 React를 다루며 관련 문법은 익숙해졌으나, 자바스크립트 기본기는 등한시했음을 느꼈다.

AI 생성 코드를 리뷰할 때도 React나 JSX보다 자바스크립트 로직에서 병목이 발생했다.

이를 보완하고자 프로그래머스 기초 문제를 풀며 자바스크립트 구현 스킬을 향상하려 한다. 앞으로 문제 풀이와 타인의 코드를 참고해 유용한 함수와 메소드를 기록할 예정이며, 이번 편에서는 Math 객체를 정리한다.

1. 올림·내림·반올림 (소수점 처리)

Math.ceil(x): 소수점 아래를 올림
Math.floor(x): 소수점 아래를 내림 (음수를 다룰 때, Math.floor(-12.4) => -13)
Math.trunc(x): 소수점 아래 버림 (음수를 다룰 때, Math.trunc(-12.4) => -12)
Math.round(x): 소수점 아래를 반올림 (단, y째 소수점에서 반올림은 지원하지 않음)

console.log(Math.ceil(10.15))
// 결과: 11
console.log(Math.floor(10.15))
// 결과: 10
console.log(Math.trunc(10.15))
// 결과: 10
console.log(Math.round(10.15))
// 결과: 10

// 두번째 자리 소수점에서 반올림은 아래와 같이 구현해야함
console.log(Math.round(10.15 * 10) / 10)
// 결과: 10.2

// 소수점 세 번째 자리에서 반올림하여 두 번째 자리까지 남기기
console.log(Math.round(10.156 * 100) / 100)
// 결과: 10.16

2. 최댓값·최솟값 구하기

Math.max(...array): 전달받은 인수 중 가장 큰 값 변환
Math.min(...array): 전달받은 인수 중 가장 작은 값 변환

let array = [1, 2, 3, 4, 5];

console.log(Math.max(...array));
// 결과: 5

console.log(Math.min(...array));
// 결과: 1

3. 절대값 및 제곱·루트

Math.abs(x): 절대값 반환
Math.pow(base, exponent): 거듭제곱 계산
Math.sqrt(x): 제곱근(루트) 계산

console.log(Math.abs(-10));
// 결과: 10

console.log(Math.pow(2, 3));
// 결과: 8
console.log(2 ** 3);
// 결과: 8

console.log(Math.sqrt(16));
// 결과: 4

[자바스크립트] Array 객체 정리

Hun's blog — Sun, 24 May 2026 17:16:20 +0900

실무에서 React를 다루며 관련 문법은 익숙해졌으나, 자바스크립트 기본기는 등한시했음을 느꼈다.

AI 생성 코드를 리뷰할 때도 React나 JSX보다 자바스크립트 로직에서 병목이 발생했다.

이를 보완하고자 프로그래머스 기초 문제를 풀며 자바스크립트 구현 스킬을 향상하려 한다. 앞으로 문제 풀이와 타인의 코드를 참고해 유용한 함수와 메소드를 기록할 예정이며, 이번 편에서는 Array 객체를 정리한다.

1. 기본 조작 및 탐색

push() / pop()

배열 맨 끝에 요소를 추가하거나 제거하는 가장 기초적인 기능

let arr = [];

arr.push(1);
console.log(arr); // [ 1 ]

arr.pop();
console.log(arr); // []

includes() / indexOf() / lastIndexOf()

특정 값이 배열에 있는지 확인하고 위치를 찾는 기본 탐색 기능

let arr = [0, 1, 2, 1];

console.log(arr.includes(1)); // true (1 값 포함 여부)
console.log(arr.indexOf(1)); // 1 (앞에서 부터 찾음)
console.log(arr.indexOf(1, 2) // 3 (2번 인덱스 부터 찾음)
console.log(arr.lastIndexOf(1)); // 3 (뒤에서 부터 찾음)

2. 순회 및 필터링

forEach()

단순 반복 조작용으로 for 루프를 대체하는 기본 순회 메소드

let arr = [[1, 2], [3, 4], [5, 6]];

// value: 배열에 담긴 요소 (옵션) -
// index: 순회중인 인덱스 번호 (옵션)
// array: 원본 배열 (옵션)
// 아무 인자를 포함하지 않으면 arr.length 만큼 순회
arr.forEach((value, index, array) => console.log(value, index, array));
// [ 1, 2 ] 0 [ [ 1, 2 ], [ 3, 4 ], [ 5, 6 ] ]
// [ 3, 4 ] 1 [ [ 1, 2 ], [ 3, 4 ], [ 5, 6 ] ]
// [ 5, 6 ] 2 [ [ 1, 2 ], [ 3, 4 ], [ 5, 6 ] ]

map()

요소를 가공해 새로운 배열을 만드는 메소드

let arr = [1, 2, 3, 4, 5];

// value: 배열에 담긴 요소 (옵션) -
// index: 순회중인 인덱스 번호 (옵션)
// array: 원본 배열 (옵션)
let new_arr = arr.map((value, index, array) => value * index);
console.log(new_arr);
// [0, 2, 6, 12, 20]

filter()

조건을 만족하는 요소만 걸러내어 새로운 배열을 만드는 메소드

const numbers = [1, 2, 3, 4, 5];

// 짝수만 필터링
const evens = numbers.filter((value) => value % 2 === 0);
console.log(evens);
// 출력: [2, 4]


const words = ["사과", "바나나", "수박", "파인애플"];

// 글자 수가 3글자 이상인 단어만 필터링
const longWords = words.filter((word) => word.length >= 3);
console.log(longWords);
// 출력: ["바나나", "파인애플"]

3. 배열 잘라내기 및 수정

slice()

원본 배열은 건드리지 않고, 필요한 부분만 복사해서 가져오는 메소드

const months = ["1월", "2월", "3월", "4월", "5월"];

console.log(months.slice(2));
// ["3월", "4월", "5월"]

console.log(months.slice(2, 4));
// ["3월", "4월"]

console.log(months.slice(1, 5));
// ["2월", "3월", "4월", "5월"]

console.log(months.slice(-2));
// ["4월", "5월"]

console.log(months.slice(2, -1));
// ["3월", "4월"]

console.log(months.slice());
// ["1월", "2월", "3월", "4월", "5월"]

splice()

원본 배열을 직접 수정(요소 삭제 및 삽입)함.

const months = ["1월", "3월", "4월", "5월"];

// 인덱스 1번 자리에 아무것도 지우지 않고(0) "2월"을 추가
months.splice(1, 0, "2월");
console.log(months);
// 출력: ["1월", "2월", "3월", "4월", "5월"]

// 인덱스 4번 자리(현재 "5월")의 요소 1개를 지우고(1) 그 자리에 "5월"을 다시 넣음 (결과적으로 교체)
// 만약 "5월"을 지우고 다른 걸 넣고 싶다면 세 번째 인자를 바꾸면 돼.
months.splice(4, 1, "5월");
console.log(months);
// 출력: ["1월", "2월", "3월", "4월", "5월"]

// 인덱스 2번 자리부터 모든 요소를 지움
months.splice(2);
console.log(months);
// 출력 : ["1월", "2월"]

// 인덱스 0번 자리의 요소 1개를 지움
months.splice(0, 1);
console.log(months);
// 출력 : ["2월"]

4. 정렬 및 반전

sort()

배열 요소를 정렬하는 메소드

// 문자열 배열을 정렬할 때
const fruits = ["바나나", "딸기", "사과", "아보카도"];
fruits.sort();

console.log(fruits);
// 출력: ["딸기", "바나나", "사과", "아보카도"]

// 숫자르 정렬할 때
const numbers = [4, 2, 5, 1, 3, 10];
numbers.sort();

console.log(numbers);
// 출력: [1, 10, 2, 3, 4, 5]

// 숫자를 올바르게 정렬하려면 비교 함수를 제공해야 함
numbers.sort((a, b) => a - b);
console.log(numbers);
// 출력: [1, 2, 3, 4, 5, 10]

numbers.sort((a, b) => b - a);
console.log(numbers);
// 출력: [10, 5, 4, 3, 2, 1]

reverse()

배열 순서를 뒤집는 메소드

const directions = ["동", "서", "남", "북"];
directions.reverse();

console.log(directions); 
// 출력: ["북", "남", "서", "동"]

// reverse 는 원본 배열도 뒤집어 버림
const original = ["a", "b", "c"];
const reversed = original.reverse();

console.log(original);
// 출력: ["c", "b", "a"]

console.log(reversed);
// 출력: ["c", "b", "a"]

// 원본을 유지하고 싶을 경우에는 다음과 같은 방식을 활용할 것
const reversed = [...original].reverse();

5. 가공 및 최종 연산

join()

배열을 하나의 문자열로 결합하는 메소드

const elements = ["Fire", "Air", "Water"];

// 1. 인자를 생략하면 기본값으로 쉼표(,)로 연결됨
const result1 = elements.join();
console.log(result1); 
// 출력: "Fire,Air,Water"

// 2. 빈 문자열('')을 넣으면 공백 없이 싹 다 붙음
const result2 = elements.join('');
console.log(result2); 
// 출력: "FireAirWater"

// 3. 원하는 구분자(공백, 대시 등)를 자유롭게 넣을 수 있음
const result3 = elements.join(' - ');
console.log(result3); 
// 출력: "Fire - Air - Water"

reduce()

배열을 하나의 값으로 축소(누적 연산) 하는 메소드

const numbers = [1, 2, 3, 4];

// 초기값 0에서 시작해서 배열의 숫자를 하나씩 더해나감
// previousValue(누적값): 이전 콜백 함수가 반환한 누적값. acc 로 줄여 사용
// currentValue (현재값): 현재 배열에서 순회하며 처리중인 요소의 값. cur로 줄여 사용
// currentIndex: 현재 인덱스
// array: 원본배열
const total = numbers.reduce((previousValue, currentValue, currentIndex, array) => {
  return previousValue + currentValue;
}, 0);

console.log(total);
// 결과: 10