버거워도 Keep Pushing

메이저 버전 업데이트의 위험성 — 실무적 관점

준레논 — Thu, 16 Jul 2026 16:38:28 +0900

"최신 버전으로 깔았는데 예전 쿼리가 에러난다" — 실무에서 흔히 겪는 이 문제, 원인을 정리해봤다.

DB 메이저 버전의 업그레이드를 예시로 살펴본다.

1. 예약어 추가

버전이 올라가면 새 예약어가 생긴다. MySQL 8.0에서는 RANK, WINDOW, LEAD 같은 단어가 예약어가 됐다. 컬럼명으로 rank를 쓰던 테이블은 갑자기 문법 오류를 낸다.

→ 백틱으로 감싸거나 컬럼명을 바꿔야 한다.

2. Deprecated 기능의 완전 제거

경고만 뜨던 기능이 다음 메이저 버전에서 아예 사라지는 게 가장 흔한 사고 원인이다.

MySQL 8.0: PASSWORD() 함수 제거, GROUP BY의 암묵적 정렬 제거
PostgreSQL: 버전마다 옛 기능이 하나씩 사라짐

→ 업그레이드 전 "Deprecated Features" 문서를 꼭 읽어야 한다.

3. 인증 방식 변경

MySQL 8.0은 기본 인증 플러그인이 mysql_native_password에서 caching_sha2_password로 바뀌었다. 구버전 드라이버(JDBC, PHP 등)는 아예 접속이 안 된다.

이건 SQL 에러가 아니라 연결 단계에서 터지는 문제라 원인 찾기가 더 까다롭다.

4. 옵티마이저 변화 → 조용히 느려지는 쿼리

구문은 멀쩡한데 실행 계획이 바뀌어서 인덱스를 안 타는 경우. 에러 로그엔 안 남고 성능만 급락해서 발견이 늦다.

5. 문자셋/정렬 기본값 변경

MySQL 8.0은 기본 charset이 latin1에서 utf8mb4로 바뀌었다. 정렬 순서, 외부 시스템과의 인코딩 호환성이 미묘하게 어긋날 수 있다.

6. 확장/플러그인 호환성 깨짐

PostGIS 같은 확장이나 서드파티 백업·모니터링 툴이 신버전을 아직 지원하지 않아 장애로 이어지는 경우도 있다.

7. ORM Dialect 불일치

Hibernate 등에서 DB 버전에 맞는 Dialect를 안 바꾸면 신버전 문법을 못 쓰거나 예상 밖 SQL이 생성된다.

8. 롤백이 안 된다

대부분의 DB는 메이저 업그레이드 후 공식적인 다운그레이드를 지원하지 않는다. 문제가 생기면 백업 복구밖에 답이 없다.

예방 체크리스트

스테이징 환경에 먼저 신버전 설치 후 운영 쿼리 로그(슬로우 쿼리 로그 포함)를 재생(replay)해서 에러/성능 차이 검증
공식 문서의 "Upgrading" + "Deprecated/Removed Features" 섹션 필수 확인
드라이버/커넥터/ORM 버전도 DB 버전에 맞춰 동시에 업그레이드 대상에 포함
스냅샷/백업 확보 후 진행, 롤백 시나리오를 사전에 문서화

WAF / IPS

준레논 — Thu, 16 Jul 2026 16:33:47 +0900

WAF (Web Application Firewall)

웹 애플리케이션 계층(L7)을 보는 방화벽입니다.

비유하자면 "건물 입구의 짐 검사대" — 일반 방화벽이 "이 사람이 건물에 들어와도 되는 사람인가"(IP/포트 단위)를 본다면, WAF는 "이 사람 가방 안에 위험한 물건(악성 요청)이 있는가"를 들여다봅니다.
SQL Injection, XSS(크로스사이트 스크립팅), CSRF 같은 웹 애플리케이션 취약점을 노린 공격 패턴을 HTTP 요청 내용 자체에서 탐지·차단합니다.
일반 방화벽/네트워크 장비로는 못 막는 영역(정상 포트로 들어오지만 내용이 악성인 요청)을 커버하는 게 핵심 역할입니다.
AWS WAF, Cloudflare WAF 등이 대표적이며, 룰셋(Managed Rules)을 붙였다 뗐다 하는 방식으로 운영합니다.

IPS (Intrusion Prevention System)

네트워크 트래픽을 실시간으로 감시하다가 공격 패턴을 발견하면 자동으로 차단하는 시스템입니다.

비유하자면 "순찰하다가 수상한 사람을 즉시 제지하는 경비원" — 탐지만 하고 신고하는 게 아니라 그 자리에서 바로 막습니다.
비슷한 개념으로 IDS(Intrusion Detection System)가 있는데, 차이가 핵심입니다:
- IDS: 탐지 + 경고만 (사후 분석용, 트래픽 흐름을 막지는 않음)
- IPS: 탐지 + 실시간 차단 (인라인으로 트래픽 경로에 직접 위치)
시그니처 기반(알려진 공격 패턴 매칭) + 이상행위 기반(비정상 트래픽 탐지) 방식을 함께 씁니다.
WAF와 헷갈리기 쉬운데, WAF는 웹(L7) 애플리케이션 공격에 특화된 반면, IPS는 네트워크 전 계층(스캐닝, 익스플로잇, 프로토콜 이상 등)을 더 폭넓게 봅니다.

3-Tier 구조, 그리고 이게 VPC와 만나는 지점

준레논 — Thu, 16 Jul 2026 16:27:34 +0900

웹 서비스를 설계할 때 "왜 웹서버, 애플리케이션 서버, DB 서버를 따로 두는가?"라는 질문에서 시작하는 개념이 3-tier 구조다.

3-Tier 구조

Presentation Tier — 웹서버, 로드밸런서. 사용자가 직접 마주하는 곳이다. 매장의 카운터라고 보면 된다.

Application Tier — WAS, API 서버. 실제 비즈니스 로직을 처리한다. 손님은 못 들어오는 주방에 해당한다.

Data Tier — DB 서버. 데이터를 저장하는 창고다. 주방(Application Tier)만 드나들 수 있고, 카운터 직원조차 직접 못 들어간다.

트래픽은 항상 한 방향으로 흐른다.

사용자 → Presentation → Application → Data

왜 굳이 나누는가

계층을 나누는 이유는 네 가지로 요약된다.

보안: DB가 인터넷에 직접 노출되지 않는다. 웹서버가 뚫려도 공격자가 바로 DB까지 가지 못한다.
독립적 확장: 웹 트래픽만 몰리면 Presentation Tier만 늘리면 된다. DB까지 같이 키울 필요가 없다.
장애 격리: 한 계층에 문제가 생겨도 나머지 계층은 원칙적으로 영향을 덜 받는다.
유지보수: 계층별로 기술 스택과 담당자가 분리되어 있어 수정과 배포가 독립적이다.

VPC 위에서는 이렇게 구현된다

3-tier는 논리적인 설계 개념이고, 이걸 실제 클라우드 네트워크에 옮겨놓은 게 VPC의 Public/Private Subnet 구조다.

Presentation Tier → Public Subnet (외부 접근이 필요하니까)
Application Tier → Private Subnet (반드시 Presentation Tier를 거쳐야 접근 가능)
Data Tier → 가장 안쪽 Private Subnet (Application Tier에서 오는 트래픽만 허용)

각 계층 사이의 경계는 보안그룹으로 강제된다. 예를 들어 Data Tier의 보안그룹은 "Application Tier 보안그룹에서 오는 3306 포트 요청만 허용"처럼 설정해서, DB 서버가 인터넷과 통신할 물리적 경로 자체를 없애버린다.

정리

3-tier 구조는 "누가 무엇을 처리하는가"를 나누는 설계이고, VPC의 서브넷 분리는 그 설계를 네트워크 레벨에서 실제로 강제하는 장치다. 애플리케이션 아키텍처와 인프라 네트워크 설계가 결국 같은 그림을 그리고 있다는 걸 이해하면, 왜 DB 서버를 Private Subnet 깊숙이 넣는지가 자연스럽게 납득된다.

마이너 업데이트(Minor Update)란

준레논 — Thu, 16 Jul 2026 16:16:39 +0900

메이저 버전이 큰 골격(예: MySQL 5 → 8, Ubuntu 20 → 22)을 바꾸는 거라면, 마이너 업데이트는 그 골격 안에서 이루어지는 점진적 개선입니다.

버전 표기로 보면 8.0.35 → 8.0.36처럼 마지막 숫자가 올라가는 것 (Semantic Versioning 기준: MAJOR.MINOR.PATCH)
새로운 기능이 추가되기도 하지만, 대개는 버그 수정, 보안 패치, 성능 개선 위주
원칙적으로는 하위 호환성(backward compatibility)을 깨지 않는 것이 목표 → 예전 구문/설정이 그대로 동작해야 함
그래서 실무에서는 "마이너는 자동 적용해도 큰 문제 없다"는 인식이 있고, 실제로 클라우드 관리형 DB(RDS 등)는 마이너 자동 업데이트를 기본 옵션으로 켜두는 경우가 많음
다만 "원칙적으로 안 깨진다"이지, 100% 보장은 아닙니다 — 마이너 업데이트에서도 간혹 특정 엣지케이스 동작이 바뀌어 문제가 되는 경우가 있어서, 프로덕션에서는 스테이징 검증 후 적용하는 게 정석

구분	메이저 (Major)	마이너 (Minor)	패치 (Patch)
예	8.0 → 9.0	8.0 → 8.1	8.0.1 → 8.0.2
성격	구조적 변화, 호환성 깨질 수 있음	기능 추가, 호환성 유지 원칙	버그·보안 수정만
검증 필요도	높음 (스테이징 필수)	중간	낮음~중간

[OS] Ubuntu vs Rocky Linux

준레논 — Thu, 16 Jul 2026 15:55:44 +0900

둘 다 리눅스 배포판이지만 성격이 다릅니다.

구분	Ubuntu	Rocky Linux
계열	Debian 계열	RHEL(레드햇) 계열 — CentOS 후속
패키지 관리	APT (apt install)	DNF/YUM (dnf install)
특징	최신 기술 반영 빠름, 커뮤니티/생태계 넓음	안정성·장기 호환성 중심, 기업용 표준에 가까움
주 사용처	AI/ML, 데이터분석, 그래픽/워크스테이션, 클라우드(특히 AWS)	기업 백엔드 서버, 엔터프라이즈 인프라, RHEL 대체용
라이선스/지원 성격	Canonical이 무료+유료 지원 병행	RHEL 100% 바이너리 호환 무료 배포 지향

왜 Ubuntu가 AI/그래픽/데이터분석에서 우위인가

NVIDIA 드라이버·CUDA 지원: NVIDIA가 공식 문서/패키지에서 Ubuntu를 1순위로 지원합니다. CUDA Toolkit, cuDNN 설치 가이드도 Ubuntu 기준으로 가장 먼저, 가장 자세하게 나옵니다.
AI 프레임워크 생태계: PyTorch, TensorFlow 등의 공식 Docker 이미지나 설치 가이드가 Ubuntu 기반으로 테스트되고 배포되는 경우가 압도적으로 많습니다.
최신 패키지 버전: APT 저장소와 PPA(개인 패키지 저장소)를 통해 최신 라이브러리를 빠르게 받을 수 있어, 빠르게 변하는 AI/데이터 툴체인과 궁합이 좋습니다.
클라우드 GPU 인스턴스 기본 이미지: AWS, GCP 등 클라우드의 GPU 인스턴스 기본/추천 이미지가 Ubuntu인 경우가 많아 AI 개발자 커뮤니티의 표준처럼 자리잡았습니다.

반면 Rocky Linux는 이런 최신 기술 추종보다는 "몇 년 동안 큰 변화 없이 안정적으로 돌아가는 것"에 초점이 맞춰져 있어서, 기업 내부 서버(DB 서버, 웹 서버, 인증 서버 등)처럼 변경을 최소화해야 하는 환경에 적합합니다.

인프라 용어 설명 — NAS, DSM, NTP

준레논 — Thu, 16 Jul 2026 15:05:12 +0900

Nas

NAS (Network Attached Storage)

네트워크에 연결된 "공용 저장소 서버"라고 생각하면 됩니다.

개인 PC 하드디스크와 달리, 네트워크(LAN)를 통해 여러 사람/서버가 동시에 접속해서 파일을 읽고 쓸 수 있습니다.
비유하자면 "사무실 한켠에 있는 대형 창고" — 각자 컴퓨터에 저장하는 대신 모두가 이 창고에 접근해서 물건(파일)을 넣고 꺼내는 방식입니다.
백업, 파일 공유, 미디어 서버, 가상머신 저장소 등으로 활용되며, RAID 구성을 통해 디스크 하나가 고장 나도 데이터를 보호하는 경우가 많습니다.
대표 제품군: Synology, QNAP 등

DSM (DiskStation Manager)

Synology NAS 장비의 운영체제(OS)입니다.

NAS라는 "창고"를 관리하는 관리자 소프트웨어라고 보면 됩니다. 창고 자체가 NAS라면, DSM은 창고 안 물건을 정리하고 출입을 통제하는 "관리 시스템"입니다.
웹 브라우저로 접속해서 파일 관리, 사용자 권한 설정, 백업 스케줄링, 패키지(앱) 설치 등을 GUI로 처리할 수 있습니다.
리눅스 기반이며, 보안팀 입장에서는 DSM 자체의 취약점(CVE)이나 관리자 계정 노출 여부가 중요한 점검 포인트입니다.

NTP (Network Time Protocol)

네트워크 상의 여러 장비들이 시간을 동기화하도록 해주는 프로토콜입니다.

비유하자면 "표준시계탑" — 모든 서버/장비가 각자 다른 시계를 갖고 있으면 로그 시간이 안 맞아서 문제 추적이 불가능해지는데, NTP 서버라는 표준 시계탑을 보고 다 같이 시간을 맞추는 것입니다.
인프라·보안 관점에서 특히 중요한 이유:
- 로그 분석/포렌식 시 여러 서버의 이벤트 순서를 정확히 맞추려면 시간 동기화가 필수
- Kerberos 인증처럼 시간 차이가 크면(보통 5분 이상) 인증 자체가 실패하는 프로토콜도 있음
- 인증서(SSL/TLS) 유효기간 판단도 정확한 시간에 의존
국내에서는 KISA나 각 기관에서 제공하는 NTP 서버(예: time.kriss.re.kr)를 많이 사용합니다.

세 개를 묶어서 예를 들면: NAS는 회사 창고, DSM은 그 창고를 관리하는 관리자, NTP는 모든 직원(서버)이 같은 시계를 보게 해주는 시스템

MAC 주소?

준레논 — Wed, 15 Jul 2026 16:22:56 +0900

맥도날드

노트북 네트워크 설정 들어가 보면 어딘가에 00:1A:2B:3C:4D:5E 같은 알 수 없는 문자열이 보인다. 그게 바로 MAC 주소이다. 오늘은 이 MAC 주소가 뭔지, 왜 필요한지, 어디서 쓰이는지, 그리고 어떻게 발전해왔는지 한번 정리해본다.

MAC 주소란?

MAC(Media Access Control) 주소는 랜카드, Wi-Fi 모듈 같은 네트워크 장비 자체에 부여된 고유 식별 번호이다. 쉽게 말하면 장비의 "주민등록번호" 같은 것이다. 보통 제조사에서 하드웨어를 만들 때 칩에 박아 넣어서 출고하기 때문에 "물리적 주소(Physical Address)"라고도 불린다.

형식은 12:34:56:78:9A:BC처럼 16진수 6쌍(총 48비트)으로 되어 있다. 앞의 3쌍(24비트)은 제조사 식별 코드(OUI, Organizationally Unique Identifier)고, 뒤의 3쌍은 그 제조사가 개별 장비마다 매기는 일련번호이다. 그래서 MAC 주소만 봐도 제조사를 유추할 수 있다.

왜 IP 주소만으로는 부족한 걸까?

여기서 헷갈리기 쉬운 포인트인데, IP 주소랑 MAC 주소는 담당하는 계층이 다르다.

IP 주소: 인터넷이라는 큰 세상에서 "어느 네트워크의 어느 기기"인지 찾아가는 주소. 상황에 따라 바뀔 수 있다
MAC 주소: 같은 네트워크 안에서 "이 케이블 반대편에 있는 물리적 장비가 정확히 어떤 놈이냐"를 특정하는 주소. 원칙적으로는 바뀌지 않는다.

비유하자면 IP 주소는 "택배 보낼 때 쓰는 집 주소"고, MAC 주소는 "그 집에 사는 사람의 지문" 같은 것이다. 주소(IP)로 동네까지는 찾아가지만, 마지막으로 문 앞에서 "진짜 이 사람이 맞나" 확인하는 건 지문(MAC)이 하는 일이라고 보면 된다.

실제로 데이터가 전달될 때도 동일하다. 인터넷 구간에서는 IP 주소로 목적지 네트워크까지 찾아가고, 같은 네트워크(같은 스위치/공유기 안) 안에서 최종적으로 "몇 번 포트의 이 장비"로 데이터를 넘겨줄 때는 MAC 주소를 쓴다. 그래서 통신 한 번 할 때 IP와 MAC이 같이 손발을 맞추는 구조이다.

그래서 어디에 쓰이는데?

맥앤치즈

네트워크 접속 제어: 회사나 공공 와이파이에서 "등록된 기기만 접속 허용" 같은 정책 쓸 때 MAC 주소로 필터링한다. 이걸 MAC 필터링이라고 부른다.
DHCP 임대: 공유기가 각 기기에 IP를 나눠줄 때, 내부적으로 "이 MAC 주소를 가진 기기한테는 항상 이 IP를 줘라" 하고 고정해주는 기능(고정 IP 할당)에 MAC 주소를 쓴다.
스위치의 MAC 주소 테이블: 스위치는 어느 포트에 어떤 MAC 주소를 가진 기기가 물려있는지 표(MAC 주소 테이블)를 만들어서, 데이터를 엉뚱한 포트로 뿌리지 않고 딱 필요한 곳으로만 전달한다.
자산관리/보안: 회사 인프라에서는 "이 자리에 있는 AP 장비 MAC 주소가 뭔지" 같은 걸 자산 대장에 적어두고 관리한다. 장비 교체나 장애 추적할 때 MAC 주소로 정확히 어떤 하드웨어인지 구분하기 위함이다.
Wi-Fi 인증: 802.1X 같은 인증 방식에서도 MAC 주소가 기기 식별 요소 중 하나로 활용된다.

그럼 MAC 주소는 계속 그대로였을까? — 발전 이야기

MAC 주소도 시대에 따라 나름 변화가 있었어.

시대에 따라 변화한다

원래는 "영구불변"이 원칙: 제조사가 하드웨어에 새겨넣은 값이니까 이론상 평생 안 바뀌는 게 정석이었다. 그래서 "물리 주소"라는 이름이 붙은 거고.
프라이버시 문제: MAC 주소가 고정돼 있다 보니, 카페나 공공장소 와이파이에서 내 스마트폰의 MAC 주소를 계속 추적하면 "이 사람이 어디를 언제 갔는지" 동선을 파악할 수 있는 부작용이 생겼다. 광고 회사나 매장에서 이걸 이용해서 유동인구 분석하는 데 쓰기도 했다.
그래서 나온 게 랜덤 MAC 주소(MAC Randomization): 최근 스마트폰·노트북 OS들은 와이파이 스캔하거나 새 네트워크에 접속할 때 진짜 MAC 주소 대신 매번 임시로 만든 가짜 MAC 주소를 쓰는 기능을 기본으로 넣기 시작했다. iOS, 안드로이드, Windows 최신 버전 다 이 기능이 있다. 그래서 요즘은 "MAC 주소 = 절대 안 바뀌는 값"이라는 공식이 완전히 성립하진 않다.
회사 와이파이에서 랜덤 MAC 때문에 골치 아픈 이유: 이 랜덤화 기능 때문에 회사에서 MAC 필터링이나 고정 IP 할당을 걸어놨는데 직원 기기가 계속 다른 MAC으로 인식돼서 인증이 안 되는 경우가 종종 생긴다. 그래서 실무에서는 회사 와이파이 SSID에 한해서는 랜덤 MAC을 끄고 진짜 MAC을 쓰도록 안내하는 경우가 많다.

정리하면

맥길 변호사

MAC 주소는 "네트워크 장비 하나하나에 붙는 고유 번호"고, 같은 네트워크 안에서 정확히 어떤 물리적 기기인지 구분하는 역할을 한다.

IP 주소가 "동네 찾아가는 주소"라면 MAC 주소는 "문 앞에서 확인하는 지문"인 셈이다.

자산관리, 접속 제어, 스위치 동작 원리까지 폭넓게 쓰이는데, 요즘은 프라이버시 이슈 때문에 랜덤 MAC 기능도 널리 쓰이면서 예전처럼 "무조건 고정된 값"은 아니게 됐다는 것까지 알아두면 좋다.

운영비용 관점에서 본 docker의 Container

준레논 — Tue, 14 Jul 2026 09:56:07 +0900

컨테이너는 서버 자원과 무관하지 않다

컨테이너를 "가상화"라고 부르다 보니 마치 서버 성능과 무관하게 마법처럼 동작한다고 오해하기 쉽다.

하지만 컨테이너는 호스트 서버의 실제 CPU, 메모리, 디스크를 그대로 나눠 쓴다. 서버가 CPU 2코어, 메모리 4GB뿐이라면, 그 위에 컨테이너를 아무리 많이 띄워도 실제로 쓸 수 있는 자원의 총량은 그대로다.

컨테이너가 요구하는 자원(이미지 안 애플리케이션이 얼마나 무거운가)과 서버가 공급할 수 있는 자원(실제 하드웨어 역량), 이 둘이 맞아떨어져야 서비스가 제대로 돌아간다. 그리고 바로 이 관계가 운영비용에 직접 영향을 준다.

VM 시절의 비용 구조

컨테이너 이전, VM으로만 서비스를 운영하던 시절을 생각해보자. 애플리케이션 하나를 배포하려면 VM 한 대를 새로 띄워야 했다. VM은 OS 전체(커널 포함)를 통째로 새로 켜는 방식이라, VM 한 대가 최소한으로 필요로 하는 메모리와 디스크만 해도 상당하다. 작은 애플리케이션 하나를 돌리기 위해 VM 한 대를 통째로 할당하면, 그 VM의 자원 중 상당 부분은 실제로 쓰이지 않고 낭비된다.

예를 들어 실제로는 CPU 0.5코어, 메모리 512MB만 있으면 충분한 애플리케이션인데, VM 한 대의 최소 사양이 CPU 1코어, 메모리 2GB라면 이미 절반 이상의 자원이 그냥 놀고 있는 셈이다. 이 낭비된 자원도 결국 클라우드 사용료로 청구된다.

컨테이너가 비용 구조를 바꾸는 방식

컨테이너는 커널을 공유하기 때문에 이런 낭비가 크게 줄어든다. 서버 한 대(혹은 VM 한 대) 위에서 여러 애플리케이션을 각각 별도의 VM 없이 컨테이너 단위로 촘촘하게 밀어넣을 수 있다. 아까 예로 든 CPU 0.5코어짜리 애플리케이션이라면, 딱 그만큼의 자원만 컨테이너에 할당하고 나머지 자원은 다른 컨테이너가 쓰도록 남겨둘 수 있다.

즉 같은 물리 자원 위에 VM을 여러 대 띄우는 것보다, 컨테이너를 여러 개 띄우는 쪽이 자원 활용률이 훨씬 높다. 활용률이 높다는 건 "같은 돈으로 더 많은 애플리케이션을 돌릴 수 있다"는 뜻이고, 이는 곧 서버 대수(혹은 VM 대수) 자체를 줄일 수 있다는 의미로 이어진다.

오토스케일링과 결합했을 때의 비용 효과

여기에 Kubernetes 같은 오케스트레이션 도구가 더해지면 비용 효율은 한 단계 더 올라간다. 트래픽이 적을 때는 컨테이너 수를 최소한으로 줄여두고, 트래픽이 몰릴 때만 컨테이너를 자동으로 늘린다. 컨테이너는 VM보다 훨씬 빨리(수 초 이내) 뜨고 사라지기 때문에, "필요한 순간에만 자원을 쓰고 바로 반납하는" 유연함이 VM 기반 오토스케일링보다 훨씬 정교해진다.

VM 기반 오토스케일링은 새 VM이 완전히 부팅되기까지 수십 초에서 1분 이상 걸리는 경우가 많아, 트래픽 급증에 대응하는 속도에 한계가 있다.

반면 컨테이너는 이미 떠 있는 서버(VM) 위에서 즉시 늘어나기 때문에 대응 속도가 빠르고, 그만큼 "혹시 몰라서 미리 넉넉하게 띄워두는" 여유 자원을 줄일 수 있다. 이 여유 자원을 줄이는 것 자체가 곧 비용 절감이다.

다만 공짜는 아니다

자원을 필요 이상으로 여유 있게 잡은 대표적인 예시

물론 컨테이너가 비용 효율만 가져다주는 건 아니다. 여러 컨테이너가 자원을 촘촘하게 나눠 쓰다 보면, 한 컨테이너가 예상보다 자원을 많이 써버려 다른 컨테이너에 영향을 주는 상황(Noisy Neighbor)이 생길 수 있다. 이를 막기 위해 컨테이너마다 자원 사용 상한(리소스 limit)을 설정해줘야 하는데, 이 설정을 잘못하면 오히려 자원을 필요 이상으로 여유 있게 잡아 비용 절감 효과가 줄어들 수도 있다.

또한 Kubernetes 같은 오케스트레이션 도구 자체를 운영하는 데도 별도의 인력과 학습 비용이 들어간다. 컨테이너 기반 구조가 무조건 저렴한 게 아니라, "자원 활용률을 얼마나 세밀하게 관리할 수 있느냐"에 따라 절감 효과가 크게 갈린다는 뜻이다.

정리

컨테이너의 운영비용 절감 효과는 결국 세 가지에서 나온다.

첫째, VM보다 가벼워서 같은 자원으로 더 많은 애플리케이션을 밀도 있게 돌릴 수 있다는 점.

둘째, 빠르게 뜨고 사라지기 때문에 트래픽 변화에 맞춰 자원을 정교하게 조절할 수 있다는 점.

셋째, 그만큼 "혹시 몰라서" 미리 잡아두는 여유 자원을 줄일 수 있다는 점이다.

다만 이 절감 효과는 자동으로 따라오는 게 아니라, 컨테이너별 자원 제한을 적절히 설정하고 오케스트레이션을 제대로 운영해야 실제로 실현된다.

이제야 알 것 같은 — Docker와 Kubernetes를 인프라 관점에서 보기

준레논 — Tue, 14 Jul 2026 09:36:00 +0900

왜 이 둘을 같이 이야기할까

Docker와 Kubernetes는 늘 세트처럼 언급되지만, 사실 하는 일이 완전히 다르다.

Docker는 컨테이너를 "만들고 실행하는" 도구고, Kubernetes는 그 컨테이너들을 "여러 대의 서버에 걸쳐 관리하는" 도구다.

인프라 관점에서 보면 이 둘은 "포장"과 "물류"의 관계에 가깝다.

Docker — 애플리케이션을 상자에 포장하기

문제 상황: "제 컴퓨터에서는 됐는데요?"

개발자가 자기 컴퓨터에서는 잘 돌아가던 프로그램이, 서버에 올리면 안 되는 경우가 흔하다. 이유는 다양하다. 서버의 Python 버전이 다르거나, 특정 라이브러리가 안 깔려 있거나, 설정 파일 경로가 다르거나. 결국 "실행 환경"이 서로 다른 게 문제다.

Docker의 해결 방식

Docker는 애플리케이션과 그걸 돌리는 데 필요한 모든 것(코드, 라이브러리, 설정, 실행 환경)을 이미지(Image)라는 하나의 상자에 통째로 포장해버린다. 이 상자를 어느 서버로 옮기든, 안에 필요한 게 다 들어있으니 "제 컴퓨터에서는 됐는데요" 문제가 사라진다.

이 이미지를 실제로 실행한 상태를 컨테이너(Container)라고 부른다.

이미지가 설계도라면, 컨테이너는 그 설계도로 실제로 돌아가고 있는 프로세스인 셈이다.

인프라 관점에서 Docker가 바꾼 것

예전에는 서버 하나에 애플리케이션을 배포하려면, 그 서버에 직접 접속해서 필요한 프로그램들을 하나하나 설치하고 설정해야 했다. Docker를 쓰면 "이미지 하나 내려받아서 실행"만 하면 끝난다.

서버가 물리 서버든, 클라우드의 가상 서버든 상관없이 똑같은 방식으로 배포할 수 있다는 점에서, Docker는 "온프레미스와 클라우드를 가리지 않는 표준 배포 단위"를 만들어준 셈이다. 앞서 다룬 벤더 락인 완화 전략 중 하나로 컨테이너 기술이 언급되는 이유가 바로 여기 있다.

Kubernetes — 컨테이너를 관리하는 오케스트라 지휘자

Docker만으로는 부족한 이유

컨테이너 하나를 서버 한 대에서 돌리는 건 Docker만으로 충분하다. 그런데 실제 서비스는 다르다. 트래픽이 몰리면 컨테이너를 여러 개 더 띄워야 하고, 서버 한 대가 죽으면 다른 서버에서 대신 컨테이너를 살려야 하고, 수십 개의 컨테이너가 서로 통신할 수 있도록 네트워크도 관리해야 한다. 이걸 사람이 손으로 다 챙기기는 불가능하다.

Kubernetes가 하는 일

Kubernetes(줄여서 K8s)는 여러 대의 서버(클러스터)에 걸쳐 수많은 컨테이너를 자동으로 배치하고, 감시하고, 필요하면 되살리는 오케스트레이션 도구다.

자동 배치: "이 컨테이너 10개를 띄워줘"라고 하면, Kubernetes가 클러스터 안의 여러 서버 중 자원이 남는 곳을 골라 알아서 나눠 배치한다.
자가 치유(Self-healing): 컨테이너 하나가 갑자기 죽으면, Kubernetes가 이를 감지하고 자동으로 새 컨테이너를 다시 띄워 원래 상태로 되돌린다.
오토스케일링: 트래픽이 늘어나면 컨테이너 수를 자동으로 늘리고, 트래픽이 줄면 다시 줄인다. 앞서 다룬 Scale-out을 컨테이너 단위로 자동화한 것이라고 보면 된다.
로드밸런싱: 여러 컨테이너에 요청을 고르게 분산해준다.

클러스터 구조를 인프라 관점에서 보면

Kubernetes 클러스터는 크게 두 종류의 서버로 나뉜다. 클러스터 전체를 지휘하는 컨트롤 플레인(Control Plane)과, 실제로 컨테이너가 돌아가는 워커 노드(Worker Node)다.

여기서 워커 노드는 대부분 AWS EC2 같은 VM으로 만들어지고, 그 VM 안에서 여러 개의 컨테이너(Kubernetes 용어로는 Pod)가 실행된다. 즉 앞서 다룬 "VM 위에 컨테이너를 올리는 이중 구조"가 바로 Kubernetes 클러스터의 실제 모습이다.

클라우드는 왜 이 둘을 반긴다

클라우드 업체 입장에서 Docker와 Kubernetes는 궁합이 아주 좋다. Kubernetes가 알아서 트래픽에 맞춰 컨테이너 수를 늘리고 줄이면, 그 밑에서 VM(워커 노드) 자체도 오토스케일링으로 함께 늘고 줄일 수 있다.

그래서 AWS(EKS), Google Cloud(GKE), Azure(AKS) 같은 클라우드 업체들은 전부 Kubernetes를 관리형 서비스로 제공하며, 사용자는 복잡한 클러스터 구축 과정 없이 바로 컨테이너를 올릴 수 있게 됐다.

정리

Docker는 애플리케이션을 어디서든 똑같이 돌아가게 포장하는 도구고, Kubernetes는 그렇게 포장된 컨테이너 수백, 수천 개를 여러 서버에 걸쳐 자동으로 배치하고 관리하는 도구다.

인프라 관점에서 보면 둘의 조합은 "표준화된 배포 단위(Docker)"와 "그걸 자동으로 운영하는 관제탑(Kubernetes)"의 결합이며, 이 조합 덕분에 클라우드 환경에서 서비스를 확장하고 장애에 대응하는 과정이 크게 자동화될 수 있었다.

사무실 네트워크, 어떻게 흘러가는 걸까? — 모뎀부터 Wi-Fi까지

준레논 — Tue, 14 Jul 2026 08:52:34 +0900

회사에 출근해서 노트북을 켜고 Wi-Fi에 접속하는 순간, 우리 눈에는 보이지 않는 여러 장비들이 순서대로 일을 하고 있습니다. 인턴으로 사내 인프라 업무를 하면서 "대체 이 신호가 어디서 어디로 흘러가는 거지?"라는 의문을 정리해본 글입니다.

모뎀, AP, POE, VLAN까지 — 사무실 네트워크의 전체 흐름을 단계별로 따라가 보겠습니다.

전체 흐름 한눈에 보기

[ISP 회선] → [모뎀/ONT] → [코어 라우터/방화벽] → [코어 스위치] → [POE 스위치] → [AP] → [무선 단말]
                                                      ↓
                                      [일반 PC, 프린터, IP폰 등 유선 단말]

이 한 줄짜리 다이어그램 안에 사무실 네트워크의 거의 모든 것이 담겨 있습니다. 하나씩 뜯어보겠습니다.

1. 모뎀(Modem) — 외부와 내부를 잇는 첫 관문

모뎀은 Modulator(변조기)와 Demodulator(복조기)의 합성어로, KT·SKB·LGU+ 같은 통신사가 건물까지 끌어온 광케이블·케이블TV선·전화선 신호를 사내망에서 쓸 수 있는 디지털 신호로 바꿔주는 장비입니다. "외부 인터넷 세계"와 "내부 사내망"이 처음 만나는 지점이라 볼 수 있죠.

요즘은 광랜(FTTH) 환경이 늘면서 별도 모뎀 없이 ONT(광 단말장치)가 바로 라우터로 연결되는 경우도 흔해졌습니다. 사내 인프라 관점에서는 이 장비가 가장 바깥단(Edge)에 위치합니다.

2. AP(Access Point) — 유선을 무선으로

AP는 유선 신호를 Wi-Fi 신호로 바꿔주는 장비입니다. 다만 가정용 공유기와는 역할이 좀 다릅니다.

가정용 공유기는 라우팅·DHCP·무선 송출을 한 장비가 다 처리하지만, 사무실용 AP는 보통 순수하게 무선 신호 송출만 담당하고, 라우팅과 DHCP는 별도 스위치나 컨트롤러가 맡는 구조가 많습니다.
AP가 여러 대 깔린 사무실이라면 개별 설정 대신 중앙 컨트롤러(또는 클라우드)에서 일괄 관리합니다. 채널을 자동으로 최적화하고, 직원이 이동할 때 끊김 없이 다음 AP로 넘어가는 로밍도 여기서 지원됩니다.
자산관리 대장에는 설치 위치(층/구역), 모델명, MAC 주소, 관리 SSID를 함께 기록해두는 게 일반적입니다.

3. POE(Power over Ethernet) — 랜선 하나로 전원까지

POE(Power over Ethernet)는 랜케이블 한 가닥으로 데이터 전송과 전력 공급을 동시에 해결하는 기술입니다. 원래 이더넷 케이블은 데이터만 실어 날랐지만, POE는 여기에 DC 전원까지 함께 흘려보냅니다.

왜 필요할까요? AP, IP 전화기, CCTV, 출입통제 리더기처럼 천장이나 벽 안쪽처럼 콘센트를 따로 빼기 어려운 곳에 설치할 때, 전원선 없이 랜선 하나로 설치와 전원 공급을 동시에 끝낼 수 있기 때문입니다.

관련 표준도 함께 알아두면 좋습니다.

표준	최대 전력	주 용도
IEEE 802.3af (POE)	약 15.4W	일반 IP폰 등
IEEE 802.3at (POE+)	약 30W	일반 AP
IEEE 802.3bt (POE++/4PPoE)	60~100W	고성능 AP, PTZ 카메라

공급 방식은 크게 두 가지입니다.

POE 스위치: 스위치 자체에 POE 포트가 있어 스위치 → 장비로 바로 전원과 데이터를 함께 공급
POE 인젝터(미드스팬): 일반 스위치를 그대로 쓰면서 중간에 인젝터를 끼워 전원만 별도 주입

4. 전체 흐름 상세 — 단계별로 따라가기

1단계: 모뎀/ONT → 코어 라우터(방화벽)

모뎀에서 나온 신호는 보통 라우터 겸 방화벽(UTM) 장비로 먼저 들어갑니다. 이 구간에서 다음과 같은 일들이 처리됩니다.

NAT(Network Address Translation): 내부 사설 IP와 외부 공인 IP를 서로 변환
방화벽 정책 적용
VPN 터널링: 재택근무자 접속을 위한 통로 마련

규모가 있는 회사라면 이 구간에 이중화(HA)를 두는 경우도 많습니다. 주회선이 장애를 일으키면 LTE/5G 백업 회선으로 자동 전환되는 식입니다.

2단계: 코어 스위치 → VLAN 분리

실무에서 가장 중요한 설계 포인트가 바로 이 지점입니다. 물리적으로는 케이블 한 가닥이지만, 논리적으로는 VLAN을 통해 네트워크를 여러 갈래로 쪼갤 수 있습니다.

VLAN 10: 사내 업무망 (PC, 서버)
VLAN 20: 게스트 Wi-Fi (외부 방문자, 인터넷만 허용, 내부망 접근 차단)
VLAN 30: IP 전화기/화상회의 장비
VLAN 40: CCTV/출입통제
VLAN 99: 관리용 (스위치/AP 관리 인터페이스)

AP는 보통 트렁크 포트로 스위치와 연결되어, 케이블 한 가닥으로 업무용 SSID(VLAN 10)와 게스트 SSID(VLAN 20)를 동시에 서비스합니다. 즉 AP 한 대가 SSID별로 서로 다른 VLAN을 태깅해서 신호를 뿌려주는 구조입니다.

3단계: POE 스위치 → AP

POE 스위치는 포트별로 쓸 수 있는 전력에 더해, 스위치 전체의 전력 예산(Power Budget)이 정해져 있다는 점이 중요합니다. 예를 들어 48포트 POE 스위치의 전체 전력 예산이 370W라면, AP 한 대당 802.3at(약 25.5W)을 소비할 경우 이론상 14대 정도만 풀파워로 지원할 수 있습니다. 그래서 스펙을 볼 때는 "포트당 최대 전력"뿐 아니라 "스위치 전체 전력 예산"도 함께 확인해야 합니다.

AP는 802.1Q 트렁크로 스위치와 연결되고, LLDP/CDP 같은 프로토콜을 통해 스위치가 AP를 자동으로 인식해 필요한 전력 클래스를 협상합니다.

실무 팁: 신규 AP를 증설할 때 "포트는 남는데 전력이 부족해서 AP가 안 켜지는" 문제가 종종 생깁니다.
이럴 땐 스위치 교체 없이 POE 인젝터로 임시 대응하기도 합니다.

4단계: AP → 무선 단말

여러 AP를 배치할 때는 채널 겹침(Co-channel Interference)을 막는 것이 관건입니다. 2.4GHz 대역은 1/6/11 채널만 서로 간섭 없이 쓸 수 있고, 5GHz 대역은 채널 폭이 넓어 상대적으로 유리합니다.

로밍: 직원이 A 구역 AP에서 B 구역 AP로 이동해도 세션이 끊기지 않고 자동으로 전환됩니다. 이건 개별 AP가 아니라 컨트롤러·클라우드 관리 시스템이 조율합니다.
인증 방식: 사내망은 보통 WPA2/3-Enterprise + 802.1X(RADIUS 서버 연동, 사번·사내 계정 인증)를 쓰고, 게스트망은 단순 WPA2-PSK나 약관 동의 후 접속하는 캡티브 포털 방식을 씁니다.

자산관리 문서를 만든다면

이 구조를 매뉴얼에 정리할 때는 "장비 – 설치 위치 – IP 대역/VLAN – 연결 상위 장비"를 표로 매핑해두는 것을 추천합니다. 그러면 나중에 장애가 발생했을 때 어느 구간이 문제인지 빠르게 추적할 수 있습니다.

예를 들어 특정 층 Wi-Fi가 안 될 때는 다음과 같은 순서로 트러블슈팅을 진행할 수 있습니다.

해당 층 POE 스위치 포트 상태 확인
AP 링크라이트 확인
상위 코어 스위치까지 순차적으로 확인

마무리

결국 사무실 네트워크는 "외부 신호를 받아들이고(모뎀) → 안전하게 걸러내고(방화벽/NAT) → 용도별로 나누고(VLAN) → 전원과 데이터를 함께 실어 나르고(POE) → 무선으로 뿌려주는(AP)" 일련의 흐름입니다.