13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[작성자:] admin

  • [Linux] Fedora Ubuntu 비교: 1년 써본 홈 서버 분석

    [Linux] Fedora Ubuntu 비교: 1년 써본 홈 서버 분석

    목차

    Fedora Ubuntu 비교: 1년 써본 홈 서버 분석

    홈 서버를 처음 올릴 때 제일 오래 붙잡고 고민했던 게 바로 배포판 선택이었습니다. 특히 Fedora Ubuntu 비교는 검색하면 자료가 정말 많거든요. 그런데 막상 24시간 켜 두는 장비에 올려서 1년 정도 굴려보면, 문서에서 보던 장점과 실제 체감이 조금 다르더라고요. 저도 처음엔 “둘 다 리눅스면 비슷한 거 아닌가?” 싶었는데, 업데이트 주기, 보안 정책, 패키지 관리, 컨테이너 운영 방식에서 성격 차이가 꽤 분명했습니다.

    이번 글은 제가 홈랩에서 직접 겪은 시행착오를 바탕으로, 홈 서버용으로 Fedora와 Ubuntu를 어떻게 봐야 하는지 정리한 내용입니다. 결론부터 짧게 말하면, 최신 흐름과 보안 정책을 더 적극적으로 다루고 싶다면 Fedora가 잘 맞았고, 자료량과 익숙한 운영 흐름이 필요하면 Ubuntu가 더 편했습니다. 다만 이건 누가 더 우월하다는 얘기가 아니라 운영 스타일이 다르다는 이야기예요. 결국 중요한 건 “내 홈 서버에서 어떤 서비스를 몇 년 동안 어떤 방식으로 굴릴 건가”였습니다.

    Fedora와 Ubuntu 홈 서버 운영 흐름을 한눈에 보여주는 비교 다이어그램

    Fedora와 Ubuntu를 홈 서버 관점에서 비교한 전체 구조 이미지입니다.

    왜 Fedora Ubuntu 비교가 홈 서버에서 중요할까요

    데스크톱에서는 조금 불편해도 금방 손으로 복구하면 되는데, 홈 서버는 얘기가 다릅니다. NAS(Network Attached Storage, 네트워크 저장소), 미디어 서버, 리버스 프록시(Reverse Proxy, 요청을 대신 받아 뒤쪽 서비스로 넘기는 서버), 백업 작업, 홈 오토메이션까지 한 박스에 몰아넣는 경우가 많잖아요. 한 번 꼬이면 밤에 알림 오고, 주말에 손이 많이 갑니다.

    실제로 써보니 배포판 선택은 단순한 UI 취향 문제가 아니었습니다. 특히 아래 항목에서 차이가 또렷하게 느껴졌습니다.

    • 업데이트 주기: 자주 바뀌는 환경이 편한지, 덜 바뀌는 환경이 편한지
    • 보안 정책: SELinux(강제 접근 통제)와 AppArmor(프로파일 기반 접근 통제) 운용 감각 차이
    • 패키지 관리: DNF(dnf, 패키지 관리자)와 APT(apt, 패키지 관리자) 사용 흐름
    • 문서 생태계: 문제 생겼을 때 검색해서 바로 답을 찾기 쉬운지
    • 컨테이너 운영: Podman(Podman, 데몬리스 컨테이너 엔진)이나 Docker(Docker, 컨테이너 런타임) 적용 습관

    1년 사용 후기 기준으로 보면, “설치는 쉬웠다”보다 “6개월 지나서도 덜 귀찮았나”가 더 중요하더라고요.

    Fedora Ubuntu 비교 핵심: 두 배포판의 성격

    쉽게 말해 Fedora는 새로운 흐름을 상대적으로 빠르게 받아들이는 배포판이고, Ubuntu는 익숙한 운영 방식과 풍부한 자료를 제공하는 배포판에 가깝습니다. 둘 다 서버 운영은 충분히 가능합니다. 다만 초반 적응 비용과 장기 유지보수의 감각이 꽤 다릅니다.

    항목 Fedora Ubuntu
    패키지 관리자 DNF APT
    보안 기본 흐름 SELinux 중심 AppArmor 중심
    업데이트/지원 성향 릴리스 주기가 빠르고 지원 기간이 상대적으로 짧음 LTS 기준 장기 유지보수에 유리함
    체감 성격 최신 흐름 반영이 빠름 자료와 예제가 풍부함
    홈 서버 적합도 컨테이너/보안 실험에 강점 안정적 운영과 문서 접근성에 강점
    초보자 체감 처음엔 약간 까다로움 비교적 진입 장벽이 낮음

    제가 직접 해보니 Fedora는 “왜 막히지?” 싶은 순간이 있었지만, 원인을 이해하고 나면 구조가 꽤 깔끔하다고 느꼈습니다. 반대로 Ubuntu는 일단 원하는 서비스가 빨리 올라갑니다. 이거 진짜 편하더라고요. 대신 시간이 지나면 패키지 버전이나 구성 방식에서 “조금 더 새것을 쓰고 싶은데” 하는 갈증이 생길 때가 있었습니다.

    패키지 관리: DNF vs APT

    APT는 워낙 익숙한 분이 많아서 자료 찾기가 쉽습니다. 반면 DNF는 명령 자체는 어렵지 않지만, 초반에는 저장소 구성이나 패키지 이름 차이 때문에 손이 한 번 더 가는 편이었습니다. 그래도 두 도구 모두 실사용에는 충분히 안정적이었습니다.

    # Fedora
sudo dnf upgrade -y
sudo dnf install -y podman nginx git

# Ubuntu
sudo apt update
sudo apt upgrade -y
sudo apt install -y docker.io nginx git

    명령 자체는 단순합니다. 다만 홈 서버에서는 명령어 한 줄보다도, 장애가 났을 때 검색해서 바로 이어서 해결할 수 있느냐가 더 크게 느껴졌습니다.

    보안 정책: SELinux vs AppArmor

    여기서 많이 갈립니다. Fedora 쪽은 SELinux가 기본 흐름에 깊게 들어와 있어서, 처음에는 서비스가 안 뜨면 “설정은 맞는데 왜 안 되지?” 싶은 일이 생깁니다. 저도 초반엔 로그도 제대로 안 보고 포트만 의심했는데, 알고 보니 보안 컨텍스트(context, 접근 허용 규칙의 문맥) 문제였던 적이 몇 번 있었습니다. 반면 Ubuntu는 AppArmor가 기본으로 활성화되어 있지만, 초반 운영에서는 상대적으로 덜 거슬리게 느껴졌습니다.

    SELinux와 AppArmor 동작 차이를 보여주는 홈 서버 보안 구성 다이어그램

    홈 서버에서 보안 정책이 서비스 접근에 어떤 영향을 주는지 설명하는 이미지입니다.

    제가 1년 동안 굴려본 홈 서버 구성

    환경을 간단히 설명드리면, 특정 하드웨어 모델에 기대는 이야기는 빼고 일반적인 홈랩 구성을 기준으로 말씀드릴게요. 서비스는 크게 이런 식이었습니다.

    • 리버스 프록시(Reverse Proxy)
    • 컨테이너 기반 애플리케이션
    • 파일 동기화 및 백업 작업
    • 간단한 모니터링(Monitoring, 상태 감시)
    • 주기적인 업데이트 및 재부팅 점검

    둘 다 처음 설치하고 네트워크 잡고 SSH(Secure Shell, 원격 접속) 붙이는 데까지는 큰 차이가 없습니다. 차이는 운영 루틴에서 벌어졌습니다. Fedora는 Podman을 중심으로 가져가면 꽤 자연스럽게 흘러갔고, Ubuntu는 Docker 예제가 워낙 많아서 필요한 구성을 붙이기가 빨랐습니다. 이 부분은 검색 생산성 차이도 꽤 컸어요.

    실전 구현: 같은 역할의 홈 서버를 두 배포판에 올릴 때

    비교를 위해 저는 최대한 비슷한 역할을 맡겼습니다. 핵심은 “업데이트, 웹 서비스, 컨테이너, 방화벽” 네 가지였습니다. 아래 절차는 현재 공식 문서 흐름과도 크게 어긋나지 않는 기본 예시입니다.

    1. 기본 업데이트와 필수 패키지 설치

    1. 시스템을 최신 상태로 올립니다.
    2. 웹 서버와 버전 관리 도구를 설치합니다.
    3. 방화벽 서비스를 확인하고 필요한 포트를 엽니다.
    # Fedora
sudo dnf upgrade -y
sudo dnf install -y nginx git curl
sudo systemctl enable --now nginx
sudo systemctl enable --now firewalld
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --reload

# Ubuntu
sudo apt update
sudo apt upgrade -y
sudo apt install -y nginx git curl
sudo systemctl enable --now nginx
sudo ufw allow 'Nginx Full'
sudo ufw enable

    여기서 중요한 포인트가 있습니다. Fedora는 firewalld(firewalld, 동적 방화벽 관리 도구) 흐름이 자연스럽고, Ubuntu는 UFW(UFW, 간편 방화벽) 예제가 많아서 접근성이 좋습니다. 다만 Ubuntu의 UFW는 기본적으로 비활성 상태인 경우가 많아서, 규칙 추가 뒤 실제 활성화 여부를 꼭 확인하는 게 좋습니다.

    2. 컨테이너 서비스 올리기

    홈 서버에서는 결국 컨테이너를 안 쓰기가 어렵더라고요. 서비스 격리도 좋고, 복구도 빠르거든요. Fedora는 Podman과 궁합이 좋았고, Ubuntu는 Docker 기준 예제가 워낙 풍부해서 초반 구축 속도가 빨랐습니다.

    # Fedora - Podman 예시
sudo dnf install -y podman
podman run -d --name hello-web -p 8080:80 docker.io/library/nginx:latest

# Ubuntu - Docker 예시
sudo apt install -y docker.io
sudo systemctl enable --now docker
sudo docker run -d --name hello-web -p 8080:80 nginx:latest

    실제로 써보니 Fedora는 Podman이 기본 흐름과 잘 맞는 느낌이 있었고, Ubuntu는 Docker 관련 문서와 예제가 많아서 트러블슈팅 속도가 빨랐습니다. 둘 다 장점이 분명했습니다.

    3. 자동 업데이트 점검 스크립트

    무턱대고 자동 업데이트를 켜는 건 조심해야 하지만, 점검 스크립트 정도는 꼭 두는 걸 추천드립니다. 저도 이걸 안 해놨다가 한동안 방치된 적이 있거든요. 최소한 업데이트가 얼마나 쌓였는지는 주기적으로 보는 편이 마음이 편했습니다.

    #!/usr/bin/env bash
set -euo pipefail

if command -v dnf >/dev/null 2>&1; then
  echo "[Fedora] Checking updates"
  sudo dnf check-update || true
elif command -v apt >/dev/null 2>&1; then
  echo "[Ubuntu] Checking updates"
  sudo apt update
  apt list --upgradable
fi

    이 스크립트는 어디까지나 점검용입니다. 실제 운영에서는 자동 재부팅 여부, 커널 업데이트 시점, 백업 상태까지 같이 보고 결정하는 편이 더 안전했습니다.

    4. 서비스 정의 파일 예시

    컨테이너든 스크립트든 부팅 후 자동 실행까지 묶어두면 운영이 확실히 편해집니다. 아래는 비교용으로 보기 쉬운 compose 형식 예시입니다.

    services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
    restart: unless-stopped

    물론 실제 운영에선 비밀값(secret)이나 볼륨(volume) 분리까지 같이 잡아야 합니다. 하지만 비교의 핵심은 여기서도 드러납니다. Ubuntu는 예제가 많아서 따라가기 쉽고, Fedora는 보안과 최신 도구 흐름을 이해하면 꽤 탄탄하게 쌓입니다.

    Fedora와 Ubuntu에서 웹 서비스와 컨테이너를 배치하는 구성 화면 또는 네트워크 다이어그램

    웹 서버, 방화벽, 컨테이너 구성을 실제 운영 흐름처럼 보여주는 이미지입니다.

    주의사항과 트러블슈팅: 제가 실제로 막혔던 지점들

    이 섹션은 정말 중요합니다. 검색 결과에서는 깔끔하게 끝나 보이는데, 실제 홈 서버 운영은 여기서 시간이 많이 들어갑니다. 저도 결국 문제를 푼 건 마법 같은 명령어보다 로그 확인 습관이었습니다.

    Fedora에서 자주 겪은 부분

    • SELinux 때문에 서비스 접근이 막힘: 포트를 열었는데도 연결이 안 되는 경우가 있었습니다.
    • 최신 패키지 흐름 적응: 문서 예제가 예전 방식일 때 명령이 조금씩 다를 수 있었습니다.
    • 외부 튜토리얼과 차이: Ubuntu 기준 가이드를 그대로 따라 하면 패키지명이나 서비스명에서 어긋날 수 있었습니다.

    이럴 때 저는 먼저 로그부터 봤습니다. 처음엔 이게 뭔가 싶었는데, 로그를 보기 시작하니까 삽질 시간이 확 줄더라고요.

    # 공통적으로 먼저 보는 로그
sudo systemctl status nginx
sudo journalctl -xeu nginx

# Fedora에서 보안 문맥 의심 시 확인에 도움 되는 명령 예시
getenforce
ls -Z /var/www

    Ubuntu에서 자주 겪은 부분

    • 문서가 너무 많아서 오히려 헷갈림: 같은 작업도 방법이 여러 개라 기준이 흐려질 수 있습니다.
    • 패키지/도구 버전 차이: 블로그 글마다 전제 조건이 달라서 그대로 복붙하면 안 맞는 경우가 있습니다.
    • 쉬워 보여서 구조를 대충 잡게 됨: 초반 속도는 빠른데, 나중에 정리 비용이 생기더라고요.

    제 경험상 Ubuntu는 “빨리 된다”가 장점이자 함정이었습니다. 급하게 올리다 보면 권한, 백업 경로, 로그 로테이션(log rotation, 로그 순환 관리) 같은 운영 기본기를 뒤로 미루게 되거든요.

    Fedora Ubuntu 비교 결과: 1년 사용 후기에서 체감된 차이

    그럼 결국 어떤 차이가 남았냐고 물으시면, 저는 이렇게 정리합니다.

    평가 항목 Fedora 체감 Ubuntu 체감
    초기 설치 속도 무난함 조금 더 빠름
    문서 검색 편의성 괜찮지만 편차 있음 매우 좋음
    보안 정책 이해 필요성 높음 중간
    최신 도구 활용 만족도 높음 무난함
    장기 운영 심리적 안정감 설정 이해 후 높음 익숙하면 높음

    제가 직접 해보니 Fedora Ubuntu 비교에서 가장 중요한 건 성능 수치가 아니라 운영 철학이었습니다. Fedora는 “구조를 이해하고 운영하라”는 느낌이 강했고, Ubuntu는 “일단 올리고 필요할 때 넓은 자료를 참고하라”는 방향이 강했습니다. 둘 다 홈 서버에 충분히 좋습니다. 다만 제 홈랩 기준으로는, 컨테이너와 보안 흐름을 진지하게 다루는 서비스는 Fedora가 재미있었고, 가족이 같이 쓰는 서비스나 빨리 안정화해야 하는 용도는 Ubuntu가 마음이 편했습니다.

    홈 서버 모니터링 대시보드와 서비스 상태가 안정적으로 표시되는 결과 화면

    서비스 상태, 리소스 사용량, 정상 동작 여부를 확인하는 검증 결과 이미지입니다.

    어떤 분에게 Fedora가 맞고, 어떤 분에게 Ubuntu가 맞을까요

    Fedora가 잘 맞는 경우

    • 최신 리눅스 흐름을 직접 익히고 싶은 분
    • SELinux를 포함한 보안 운영 감각을 키우고 싶은 분
    • Podman 중심의 컨테이너 운영을 해보고 싶은 분
    • 홈랩 자체를 공부와 실험의 장으로 쓰는 분

    Ubuntu가 잘 맞는 경우

    • 검색해서 빨리 구축하고 싶은 분
    • 문서와 커뮤니티 자료가 많은 환경을 선호하는 분
    • 처음 홈 서버를 시작하는 분
    • 운영 표준을 단순하게 가져가고 싶은 분

    혹시 이런 경험 있으신가요? 분명 설치는 쉬웠는데, 3개월 뒤 업데이트 한 번에 갑자기 손이 많이 가는 상황이요. 그래서 저는 이제 배포판을 고를 때 “첫날 편한가”보다 “여섯 달 뒤 덜 힘든가”를 더 보게 됐습니다.

    정리와 다음 단계

    이번 Fedora Ubuntu 비교를 1년 사용 후기 관점에서 정리하면 이렇습니다. Fedora는 배울 게 많고 구조적으로 단단한 느낌, Ubuntu는 빠르게 안정권에 진입하기 쉬운 느낌이었습니다. 저도 처음엔 Ubuntu가 더 편했는데, 홈랩에서 이것저것 실험하다 보니 Fedora 쪽의 매력도 분명히 크게 느꼈습니다. 결국 정답은 하나가 아니라, 내 서비스 성격에 맞는 선택이더라고요.

    1. 처음 홈 서버를 시작한다면 Ubuntu로 기본 운영 루틴을 익혀보세요.
    2. 보안 정책과 최신 도구 흐름이 궁금하다면 Fedora를 별도 장비나 VM(Virtual Machine, 가상 머신)에서 병행해 보세요.
    3. 둘 중 무엇을 선택하든 로그 확인, 백업, 업데이트 점검 자동화는 초반부터 잡는 걸 추천드립니다.

    다음 글에서는 홈 서버 운영에서 중요한 백업 전략과 리버스 프록시 구성 이야기를 다뤄볼 예정입니다. 이전 글의 모니터링 기본편이 있다면 함께 읽어보셔도 흐름이 잘 이어집니다.

    Fedora와 Ubuntu 선택 기준을 요약한 인포그래픽 스타일 비교표

    어떤 사용자가 어떤 배포판을 선택하면 좋은지 한눈에 정리한 요약 이미지입니다.

    자주 묻는 질문

    Q. 홈 서버 입문자는 Fedora보다 Ubuntu가 낫나요?

    대체로는 그렇습니다. 자료량과 예제 폭이 넓어서 초반 시행착오를 줄이기 쉽거든요. 다만 공부 목적이 강하면 Fedora도 충분히 좋은 선택입니다.

    Q. Fedora는 서버에서 불안정한가요?

    제가 써본 기준으로 무조건 그렇진 않았습니다. 다만 업데이트 흐름과 보안 정책을 이해하지 않으면 더 까다롭게 느껴질 수 있습니다.

    Q. Ubuntu가 무조건 더 쉬운가요?

    처음엔 쉬운데, 그래서 구조를 대충 잡고 넘어가면 나중에 정리 비용이 생길 수 있습니다. 쉬운 것과 잘 운영하는 것은 조금 다른 문제더라고요.

    Q. 결론적으로 무엇을 추천하나요?

    가족이 함께 쓰는 서비스, 빠른 구축, 문서 접근성이 중요하면 Ubuntu를 추천합니다. 홈랩 실험, 최신 흐름, 보안 학습이 중요하면 Fedora를 추천드립니다.

  • [Game] ROG Ally Steam OS 설치 후 6개월: 성능과 활용성 분석

    [Game] ROG Ally Steam OS 설치 후 6개월: 성능과 활용성 분석

    목차

    [리눅스 게임] ROG Ally Steam OS 6개월 사용기, 성능과 활용성 분석

    ROG Ally Steam OS 조합이 왜 이렇게 자주 검색되는지, 직접 만져보면 바로 이해가 되더라고요. Windows 기반 휴대용 게임기를 쓰다 보면 게임 자체보다 업데이트, 런처, 절전 복귀, 키보드 호출 같은 주변 작업이 더 거슬릴 때가 많거든요. 저도 이런 기기를 꽤 오래 써봤는데, ROG Ally에 SteamOS 계열 환경을 얹은 뒤 가장 크게 달라진 건 기기를 대하는 피로도였습니다. 세팅이 한 번 잡히고 나니까 손이 훨씬 자주 갔습니다.

    다만 먼저 짚고 갈 부분이 있습니다. 초기에 많은 사용자가 ROG Ally에서 경험한 건 Valve 순정 SteamOS만이 아니라, Bazzite 같은 SteamOS 스타일의 리눅스 게임 배포판까지 포함한 경우가 많았습니다. 그리고 2025년 이후 Valve가 AMD 기반 일부 휴대용 기기까지 SteamOS 지원 범위를 넓히는 흐름이 나오면서, 지금은 예전보다 이야기가 조금 달라졌습니다. 그래서 이 글은 ROG Ally에서 SteamOS 인터페이스와 사용 흐름을 6개월간 써본 실사용 관점에 가깝다고 보시면 됩니다.

    ROG Ally Steam OS 구성 개요를 보여주는 이미지

    ROG Ally에서 Steam 중심 게임 모드와 데스크톱 모드가 어떻게 나뉘는지 보여주는 개요 이미지입니다.

    ROG Ally Steam OS, 정확히 뭘 뜻할까요?

    쉽게 말해 SteamOS는 Valve가 Steam Deck을 위해 다듬어 온 리눅스 기반 운영체제입니다. 핵심은 Steam 게임 모드, Proton(프로톤, Windows 게임 호환 계층), 그리고 Gamescope(게임스코프, 핸드헬드용 세션/디스플레이 관리 계층) 같은 조합에 있습니다. 전원 켜고 바로 게임기로 진입하는 느낌이 강해서, 데스크톱 PC를 쓰는 감각과는 확실히 다릅니다.

    ROG Ally는 기본적으로 Windows 11 기반 기기라 자유도는 높습니다. 대신 휴대용 게임기로서의 매끈한 흐름은 사용자가 직접 챙겨야 하는 부분이 있죠. 반면 SteamOS 계열 환경은 자유도가 조금 줄더라도 게임기처럼 바로 쓰는 경험을 잘 만들어 줍니다. 그래서 스팀덱 대안을 찾는 분들이 ROG Ally Steam OS 조합에 꾸준히 관심을 갖는 겁니다.

    • 장점: 빠른 게임 진입, 컨트롤러 친화 UI, 절전 복귀 흐름이 단순함
    • 단점: 일부 안티치트 게임 제약, ASUS 전용 유틸리티 부재, 초반 세팅 난도
    • 핵심 변수: 내가 주로 하는 게임이 Proton 친화적인지, Windows 전용 런처 의존도가 높은지

    왜 Windows 대신 리눅스 게임 환경을 택했는지

    직접 써보니 성능 숫자 자체보다도 프레임 타임(Frame Time, 화면이 일정하게 나오는 느낌)과 사용 흐름에서 만족도가 컸습니다. 숫자만 보면 Windows와 큰 차이가 없어 보이는 게임도 있는데, 실제로는 실행부터 종료까지 훨씬 매끈하게 느껴질 때가 있더라고요. 전원 버튼 눌러서 자고, 다시 켜서 이어 하고, 패치하고, 컨트롤러로 설정 만지는 과정이 덜 번거롭습니다.

    특히 휴대용 게임기는 벤치마크 점수보다 아래 세 가지가 더 중요했습니다.

    1. 절전 복귀: 켜자마자 바로 이어서 할 수 있는가
    2. 런처 스트레스: 마우스와 키보드 없이도 대부분 처리 가능한가
    3. 저전력 구간 체감: 팬 소음과 발열을 억제하면서도 납득 가능한 플레이가 되는가

    여기서 ROG Ally는 하드웨어 여유가 있는 편이라, Steam Deck보다 높은 전력 구간에서 밀어붙일 수 있는 맛이 있습니다. 반대로 저전력 구간에서는 게임별 편차가 꽤 느껴졌고요. 결국 ROG Ally는 하드웨어 잠재력이 크고, SteamOS 계열은 그 잠재력을 게임기답게 정리해 주는 역할이라고 보는 게 가장 이해가 쉬웠습니다.

    ROG Ally Steam OS 설치 전에 꼭 체크할 것들

    저도 처음엔 무턱대고 USB부터 만들었다가 다시 손대는 시간이 더 들었습니다. 여기서는 정말 실전적으로 보셔야 합니다. 특히 설치 전에 자주 하는 게임의 Proton 호환성과 안티치트 이슈를 먼저 확인해 두면 시행착오가 크게 줄어듭니다.

    항목 체크 포인트 메모
    게임 호환성 자주 하는 멀티플레이 게임의 리눅스 지원 여부 안티치트 게임은 미리 확인
    저장공간 단일 부팅인지, 듀얼 부팅인지 듀얼 부팅이면 파티션 계획 필수
    복구 수단 원래 OS 복구 USB, 드라이버 백업 이거 안 챙기면 복귀가 번거롭습니다
    입력 장치 USB-C 허브, 키보드, 충전기 초기 설치 때 체감 차이 큼
    업데이트 전략 시스템 업데이트와 게임 런타임 분리 관리 문제 생기면 롤백도 고려

    개인적으로는 처음부터 메인 기기로 바꾸기보다, 주말 하루 잡고 테스트해 보는 걸 권합니다. 특히 Game Pass 중심이거나 특정 온라인 게임 비중이 높으면 Windows 병행이 더 현실적일 수 있습니다. 이전 글에서 다룬 것처럼 운영체제를 갈아엎는 작업은 항상 백업부터 시작하는 게 맞고, 게임 호환성이 걱정된다면 관련 글에서 Proton 체크 방법도 같이 확인해 두면 좋습니다.

    실전 구현: 제가 잡았던 기본 점검 루틴

    설치 방식은 배포판과 시기에 따라 조금씩 다르니, 여기서는 설치 직후에 공통으로 확인하기 좋은 루틴만 적어보겠습니다. 이 정도만 점검해도 초반 삽질 절반은 줄어듭니다.

    1. 부팅 후 운영체제와 커널 버전 확인
    2. 저장장치 마운트 상태 확인
    3. 메모리와 로그 상태 확인
    4. Flatpak 앱과 런타임 업데이트
    5. 절전 복귀와 컨트롤러 입력 테스트

    아래 명령은 과하게 복잡하지 않으면서도 상태 확인에 꽤 도움이 됩니다. 특히 듀얼 부팅이나 외장 저장장치를 함께 쓰는 경우에는 저장장치와 부팅 로그를 먼저 보는 습관이 중요하더라고요.

    cat /etc/os-release
uname -r
lsblk
free -h
flatpak update -y
journalctl -b -p 3

    /etc/os-release로 현재 올린 OS 계열을 확인하고, uname -r로 커널 버전을 봅니다. lsblk는 파티션과 저장장치 상태를 볼 때 유용하고, free -h는 메모리 여유를 빠르게 확인할 때 편합니다. journalctl -b -p 3는 현재 부팅 세션에서 우선순위가 높은 에러만 추려 보여줘서, 문제를 넓게 의심하기 전에 방향을 잡는 데 좋았습니다.

    게임 모드 쪽 안정성만 보지 말고 데스크톱 모드도 꼭 한 번 들어가 보세요. 실제로 써보면 브라우저 로그인, 런처 설치, 파일 이동 같은 사소한 작업이 은근 자주 생깁니다. 이때 키보드 호출이나 화면 배율이 불편하면 장기적으로 손이 잘 안 가더라고요.

    ROG Ally Steam OS 초기 설정과 점검 과정을 보여주는 이미지

    초기 부팅 후 저장장치, 업데이트, 게임 모드 진입 흐름을 점검하는 장면을 넣는 위치입니다.

    제가 따로 봤던 세부 포인트

    • Proton 버전: 특정 게임이 안 돌면 호환성 도구만 바꿔도 해결되는 경우가 많았습니다.
    • TDP/전력 프로파일: 같은 게임도 전력 제한에 따라 체감이 크게 달라집니다.
    • 해상도와 업스케일링: 휴대용 화면에서는 숫자보다 균형이 더 중요했습니다.
    • 외부 런처: Heroic이나 Lutris를 쓸지 처음부터 기준을 세워두면 훨씬 편합니다.

    ROG Ally Steam OS로 6개월 써보니 보인 성능 패턴

    가장 궁금한 부분이죠. 게임 성능만 놓고 보면 ROG Ally는 기본 하드웨어 체급이 있는 기기라서, Steam Deck보다 여유 있는 장면이 분명 있습니다. 그래픽 옵션을 약간 더 공격적으로 잡아도 버텨주는 구간이 있었고요. 다만 휴대용 게임기에서 중요한 건 최고 프레임보다도 어느 전력대에서 얼마나 안정적으로 유지되느냐였습니다.

    제가 느낀 패턴은 이랬습니다.

    • 가벼운 인디 게임: 거의 스트레스가 없었습니다. 수면 복귀와 즉시 실행 쪽 만족도가 특히 컸습니다.
    • 중간급 3D 게임: 해상도와 업스케일링만 잘 맞추면 가장 만족도가 좋았습니다.
    • 무거운 AAA 게임: 가능은 하지만, 설정 타협과 배터리 기대치를 현실적으로 잡아야 했습니다.
    • 멀티플레이/런처 의존 게임: 이쪽이 가장 변수였습니다. 게임보다 런처와 보안 모듈이 더 문제일 때가 있었습니다.

    흥미로웠던 건 배터리나 발열보다도 설정을 계속 만지는 빈도가 줄었다는 점입니다. Windows에서는 패드 입력, 절전 복귀, 백그라운드 업데이트 같은 사소한 일이 누적됐는데, SteamOS 계열 환경에서는 그런 순간이 상대적으로 적었습니다. 이거 진짜 편하더라고요.

    반대로 단점도 분명했습니다. ASUS가 제공하던 전용 유틸리티 흐름에 익숙했다면 초반엔 허전합니다. 그리고 특정 게임은 실행은 되는데 뭔가 하나가 불편한 식으로 남아 있기도 했습니다. 그래서 저는 이 조합을 만능이라고 보진 않지만, 스팀 라이브러리 중심이고 리눅스 게임 환경에 거부감이 없다면 꽤 설득력 있는 선택지라고 느꼈습니다.

    ROG Ally Steam OS 게임 성능과 절전 복귀 체감을 시각화한 이미지

    실사용 기준으로 게임 모드, 절전 복귀, 전력 프로파일 체감을 정리한 결과 이미지가 들어갈 자리입니다.

    ⚠️ 실제로 겪었던 문제와 해결 과정

    좋은 얘기만 하면 글이 너무 매끈해져서 오히려 현실감이 없죠. 실제로는 저도 꽤 손을 봤습니다.

    1. 절전 복귀는 되는데 가끔 입력이 꼬이는 경우

    이건 초기에 꽤 신경 쓰였습니다. 대부분은 업데이트 이후 줄어들었지만, 문제가 생기면 무조건 게임 자체 문제로만 보지 말고 입력 계층부터 의심해 보는 게 좋았습니다. Steam Input 설정을 초기화하거나, 문제 게임만 별도 레이아웃을 주는 식으로 해결되는 경우가 있더라고요.

    steam -shutdown
flatpak update -y
journalctl -b | tail -n 100

    2. 특정 게임이 실행 직후 튕기는 경우

    처음엔 드라이버 문제인 줄 알았는데, 실제로는 Proton 버전이나 런처 로그인 꼬임인 경우가 더 많았습니다. 여기서 중요한 포인트는 리눅스 게임에서는 게임 자체 문제와 호환성 도구 문제를 분리해서 봐야 한다는 점입니다. 게임 파일 검증, Proton 변경, 처음 실행 시 데스크톱 모드에서 한 번 열어보기 순서로 접근하면 생각보다 빨리 정리됐습니다.

    3. 듀얼 부팅 욕심이 커질수록 복잡도도 같이 올라감

    이건 정말 많이들 겪습니다. 처음엔 Windows도 남겨두고 리눅스도 쓰면 완벽할 것 같지만, 실제로는 부팅 순서, 저장공간 분배, 업데이트 충돌, 부트로더 문제까지 같이 따라옵니다. 저도 결국 기준을 단순하게 잡고 나서야 편해졌습니다.

    • 온라인 멀티 위주면 Windows 유지
    • 싱글플레이와 스팀 중심이면 SteamOS 계열 단독이 더 편함
    • 둘 다 놓치기 싫으면 듀얼 부팅, 대신 관리 비용을 감수

    스팀덱 대안으로서 ROG Ally는 어디까지 괜찮았나

    많이 물어보시는 질문이라 표로 정리해 보겠습니다. 숫자 스펙 싸움보다는 실제 사용 흐름 기준으로 보시면 이해가 빠릅니다.

    비교 항목 ROG Ally + SteamOS 계열 Steam Deck
    초기 세팅 난도 상대적으로 높음 낮음
    게임기 같은 일관성 세팅 후 만족도 높음 처음부터 안정적
    하드웨어 여유 더 공격적인 설정 여지 균형 중심
    Windows 병행 필요성 사용 패턴에 따라 큼 상대적으로 덜함
    튜닝 재미 높음 중간
    추천 대상 설정 만지는 걸 감수하는 사용자 바로 플레이하고 싶은 사용자

    정리하면 스팀덱 대안으로서의 ROG Ally는 충분히 매력적입니다. 다만 그 매력은 그냥 사면 끝나는 타입이 아니라, 하드웨어 잠재력과 리눅스 게임 최적화의 균형을 직접 맞출 때 살아납니다. 반면 Steam Deck은 처음부터 경험이 잘 정리돼 있어서 진입장벽이 낮고요. 그래서 누가 더 낫다고 단정하기보다, 누가 나한테 덜 귀찮은가를 기준으로 보는 게 맞았습니다.

    ROG Ally Steam OS와 스팀덱 대안 비교를 보여주는 이미지

    ROG Ally Steam OS와 Steam Deck의 사용 흐름 차이를 한눈에 보여주는 비교 인포그래픽 자리입니다.

    활용성: 게임기 이상으로도 쓸 만했나?

    생각보다 여기서 점수를 많이 줬습니다. 데스크톱 모드가 있어서 브라우저, 문서 확인, 간단한 원격 접속 정도는 충분히 됩니다. 물론 노트북 대체재로 보긴 어렵지만, 홈 서버나 NAS 상태를 잠깐 확인하고 파일 몇 개 옮기는 정도는 의외로 편했습니다. KDE Plasma에만 적응하면 활용 폭이 꽤 넓어집니다.

    저는 특히 게임 + 스트리밍 + 간단한 원격 작업을 하나의 기기로 처리하는 흐름이 만족스러웠습니다. 다음 글에서는 Moonlight나 원격 접속 도구를 붙여서, 휴대용 게임기를 홈랩 단말처럼 쓰는 방법도 정리해 보려고 합니다.

    정리: 6개월 후 결론과 추천 대상

    결론은 명확합니다. ROG Ally Steam OS 조합은 모든 사람에게 정답은 아니지만, 맞는 사람에게는 만족도가 꽤 높습니다. 실제로 써보니 핵심은 성능 숫자보다도 휴대용 게임기로서의 흐름이 정리되느냐였습니다. 이 부분에서 SteamOS 계열 환경은 분명 강점이 있었고, 어느 순간부터는 Windows로 다시 돌아가는 시간이 줄어들더라고요.

    이런 분께 특히 추천합니다.

    • 스팀 라이브러리 중심으로 즐기시는 분
    • 절전 복귀와 컨트롤러 UI를 중요하게 보시는 분
    • 약간의 세팅과 트러블슈팅을 감수할 수 있는 분

    반대로 아래 조건이면 한 번 더 고민해 보세요.

    • 특정 온라인 게임이 메인인 경우
    • 제조사 전용 기능과 Windows 생태계 의존도가 높은 경우
    • 문제 생겼을 때 직접 로그를 볼 생각이 전혀 없는 경우

    자주 묻는 질문

    ROG Ally에 SteamOS를 올리면 무조건 성능이 더 좋아지나요?

    무조건 그렇진 않습니다. 게임 종류, 전력 설정, Proton 버전, 드라이버와 커널 상태에 따라 다릅니다. 다만 체감상 더 편하고 일관된 흐름을 주는 경우는 분명 있었습니다.

    리눅스 게임 환경이 초보자에게도 가능한가요?

    가능은 하지만, 완전 무지성 설치는 추천하지 않습니다. 최소한 복구 방법, 저장공간, 자주 하는 게임의 호환성 정도는 먼저 확인하고 들어가는 게 좋습니다.

    스팀덱 대안으로 살 만한가요?

    네, 충분히 고려할 만합니다. 다만 성향을 탑니다. 설정을 만지는 재미와 하드웨어 여유를 원하면 ROG Ally 쪽이 맞고, 처음부터 정돈된 경험을 원하면 Steam Deck 쪽이 더 편합니다.

  • [k8s] Backstage 운영 후기: 개발자 포털 1년 회고와 정착 과정

    [k8s] Backstage 운영 후기: 개발자 포털 1년 회고와 정착 과정

    목차

    Backstage 운영 후기: 개발자 포털 1년 회고와 정착 과정

    Backstage 운영 후기를 정리해보려고 합니다. 개발팀이 커질수록 문서는 여기저기 흩어지고, 서비스는 늘어나고, 누구에게 뭘 물어봐야 하는지도 점점 모호해지더라고요. 저도 인프라 일을 오래 하면서 이런 상황을 정말 많이 봤습니다. 처음엔 위키만 잘 정리하면 되겠지 싶었는데, 실제로 써보니 위키만으로는 서비스 카탈로그(Service Catalog, 서비스 목록 체계), 템플릿(Template, 표준 생성 양식), 권한 관리(Permission, 접근 제어)까지 한 번에 풀기 어렵더라고요. 그래서 선택한 게 바로 Backstage였습니다.

    이 글은 화려한 성공담보다는, 실제에 가까운 Backstage 도입 사례 기록입니다. 도입 검토부터 초기 구축, 팀 정착, 그리고 1년 운영하면서 느낀 한계까지 솔직하게 적어보겠습니다. 지금 개발자 포털 구축을 고민 중이라면 시행착오를 줄이는 데 도움이 될 겁니다.

    Backstage 운영 후기를 설명하는 개발자 포털 전체 아키텍처 이미지

    Backstage를 중심으로 Git 저장소, CI/CD, 문서, 모니터링 도구가 연결되는 전체 구조를 한눈에 보여주는 이미지입니다.

    Backstage란 무엇이고 왜 도입했나

    쉽게 말해 Backstage는 개발자 포털을 구축할 때 쓰는 오픈소스 프레임워크입니다. 서비스 목록을 모아두는 화면이기도 하고, 팀 표준을 배포하는 플랫폼이기도 하고, 신규 서비스 생성 흐름을 자동화하는 입구이기도 하죠. 처음엔 “이거 그냥 내부 위키랑 뭐가 다르지?” 싶었는데, 막상 운영해보니 차이가 꽤 컸습니다.

    제가 체감한 가장 큰 차이는 세 가지였습니다.

    • 서비스를 문서가 아니라 엔티티(Entity, 관리 대상 객체)로 다룬다: 팀, 시스템, API, 컴포넌트를 관계로 연결할 수 있습니다.
    • 소유권(Ownership, 담당 주체)이 드러난다: 장애가 났을 때 누가 관리하는지 찾는 시간이 줄었습니다.
    • 표준화가 강제된다: 새 저장소를 만들 때부터 템플릿으로 기본 구조를 맞출 수 있거든요.

    특히 플랫폼 엔지니어링(Platform Engineering, 개발 생산성 플랫폼 설계) 관점에서 좋았던 건, 운영팀이 “지침”만 주는 게 아니라 “실행 가능한 기본값”을 제공할 수 있다는 점이었습니다. 말로만 표준을 외치면 잘 안 지켜집니다. 그런데 템플릿에 녹여두면 생각보다 잘 따라오더라고요. 이거 진짜 편했습니다.

    참고로 Backstage는 CNCF 인큐베이팅 프로젝트이기도 합니다. 그래서 CNCF Backstage라는 표현을 쓰더라도, 제품명이라기보다 CNCF 생태계에 속한 Backstage를 가리키는 말로 이해하는 편이 자연스럽습니다.

    Backstage 도입 전에 먼저 정한 기준

    Backstage는 기능이 많지만, 처음부터 다 하려 들면 거의 반드시 무너집니다. 저도 처음엔 카탈로그, 문서, 템플릿, 플러그인(Plugin, 확장 기능), 권한까지 한 번에 붙이려다가 시행착오를 꽤 겪었습니다. 그래서 기준을 다시 잡았습니다.

    1. 첫 3개월 목표는 검색성과 소유권 정리

    처음부터 모든 자동화를 노리진 않았습니다. 가장 먼저 해결한 건 “우리 서비스가 몇 개인지”, “이 서비스 담당 팀이 누구인지”, “배포 파이프라인이 어디 있는지”를 한 화면에서 보이게 하는 것이었습니다.

    2. 카탈로그 품질이 화면보다 먼저다

    Backstage는 화면보다 데이터가 중요합니다. <code>catalog-info.yaml이 엉망이면 나중에 검색도, 관계도, 문서 연결도 다 지저분해집니다. 그래서 초기에 메타데이터 규칙부터 정했습니다.

    3. 운영팀이 다 입력하지 않는다

    플랫폼은 중앙집중형으로 굴리면 오래 못 갑니다. 각 팀이 자기 서비스 메타데이터를 유지하게 하고, 운영팀은 템플릿과 검증 규칙을 관리하는 식으로 분리했습니다.

    항목 초기 목표 1년 뒤 목표
    서비스 카탈로그 핵심 서비스 등록 전 팀 기본 등록
    소유권 표시 팀 단위 매핑 온콜/문서 링크까지 연결
    소프트웨어 템플릿 1~2개 표준 템플릿 언어/런타임별 확장
    TechDocs 중요 서비스만 문서 작성 습관 정착
    권한 관리 최소 권한 팀/역할 기반 세분화

    Backstage 개발자 포털 구축: 첫 배포까지

    개발자 포털 구축 자체는 생각보다 빨리 됩니다. 문제는 그 다음부터입니다. 기본 앱을 만들고, 로컬에서 띄우고, 카탈로그 엔티티를 등록해보는 것까지는 공식 흐름이 꽤 잘 되어 있습니다.

    1. 새 Backstage 앱 생성
    2. 기본 실행 확인
    3. 카탈로그 엔티티 등록
    4. 인증과 조직 구조 연결
    5. 템플릿과 문서 기능 추가

    저는 초기에 아주 단순한 구조로 시작했습니다. 로컬에서 먼저 확인하고, 이후 컨테이너(Container, 실행 격리 환경)로 배포하는 흐름이었습니다. 현재 공식 시작 가이드 기준으로는 아래처럼 앱을 만든 뒤 yarn start로 프런트엔드와 백엔드를 함께 띄우는 방식이 가장 기본입니다.

    npx @backstage/create-app@latest
cd my-backstage-app
yarn install
yarn start

    처음 화면이 뜨면 “생각보다 금방 되네?” 싶습니다. 그런데 여기서 중요한 포인트가 있습니다. 로컬 실행 성공은 시작일 뿐입니다. 실제 운영에서 중요한 건 인증, 카탈로그 입력 규칙, 저장소 구조, 문서 관리 방식입니다.

    서비스 등록은 아래처럼 아주 기본적인 엔티티 파일부터 시작했습니다.

    apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-api
  description: Payment service for internal platform
  tags:
    - backend
    - critical
spec:
  type: service
  lifecycle: production
  owner: team-platform
  system: commerce-platform

    이 단계에서 중요한 건 멋진 화면이 아니라 명명 규칙(Naming Convention, 이름 규칙)입니다. 이름이 제각각이면 검색이 바로 망가집니다. 실제로 써보니까 team-, svc- 같은 접두사(prefix, 앞부분 식별자)를 과하게 쓰는 것도 오히려 헷갈리더라고요. 적당히 단순해야 오래 갑니다.

    Backstage 운영 후기의 핵심인 서비스 카탈로그와 엔티티 관계 구성 이미지

    Component, API, System, Group 엔티티가 서로 연결된 카탈로그 구조를 보여주는 이미지입니다.

    Backstage 운영 후기에서 편해진 지점: 카탈로그, 템플릿, 문서

    카탈로그(Catalog, 서비스 자산 목록)

    Backstage 운영 후기에서 빼놓기 어려운 핵심은 카탈로그입니다. 저는 처음에 이걸 “서비스 목록 화면” 정도로 생각했었는데, 1년 써보니 사실상 운영 기준점이더라고요. 서비스가 장애를 냈을 때 저장소와 문서, 대시보드, 소유 팀을 한 번에 찾을 수 있다는 게 큽니다.

    소프트웨어 템플릿(Software Templates, 표준 생성 템플릿)

    이 기능은 팀 표준을 퍼뜨릴 때 정말 강력했습니다. 신규 서비스 생성 시 README, 기본 디렉터리 구조, CI 설정, 카탈로그 파일까지 자동으로 넣어주게 만들면 편차가 많이 줄어듭니다.

    apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: simple-service-template
  title: Simple Service Template
spec:
  owner: team-platform
  type: service
  parameters:
    - title: Service Info
      required:
        - name
        - owner
      properties:
        name:
          type: string
          title: Service Name
        owner:
          type: string
          title: Owner Team
  steps:
    - id: fetch-base
      name: Fetch Base
      action: fetch:template
      input:
        url: ./template
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}

    처음엔 템플릿을 많이 만들수록 좋다고 생각했는데, 오히려 반대였습니다. 템플릿 종류가 많아지면 사용자가 뭘 선택해야 하는지 모르거든요. 그래서 1년 운영 후 기준은 명확해졌습니다. “가장 많이 쓰는 패턴부터 적게 만든다.” 이게 맞았습니다.

    TechDocs(테크독스, 문서 자동 게시)

    문서도 생각보다 영향이 컸습니다. 개발자 포털 구축에서 문서가 분리되어 있으면 결국 다시 검색 지옥으로 돌아갑니다. Backstage 안에서 문서가 보이게 만들면 적어도 “어디에 있는지”를 찾는 시간은 줄어듭니다. 다만 문서 품질 자체는 도구가 해결해주지 않습니다. 이건 운영 문화의 문제더라고요.

    1년 운영하면서 겪은 문제들

    여기부터가 진짜 운영 후기입니다. 설치보다 운영이 훨씬 어렵습니다.

    1. 카탈로그 등록률이 생각보다 안 올라갑니다

    플랫폼팀이 좋다고 생각하는 것과 현업팀이 귀찮다고 느끼는 건 늘 다릅니다. 특히 초기에는 “왜 이걸 또 적어야 하죠?”라는 반응이 있었습니다. 저도 처음엔 안내 문서를 길게 써놨었는데, 효과가 크지 않더라고요.

    해결은 단순했습니다.

    • 템플릿 생성 시 catalog-info.yaml 자동 포함
    • 필수 필드 최소화
    • 리뷰 체크리스트에 소유권 항목 추가
    • 등록 안 된 서비스는 운영 지표에서 제외

    강제와 편의의 균형이 중요합니다. 너무 세게 밀면 반감이 생기고, 너무 느슨하면 아무도 안 합니다.

    2. 조직도와 실제 책임 구조가 다릅니다

    Group(그룹, 팀 조직 엔티티)를 예쁘게 모델링해도 현실은 늘 예외가 있습니다. 명목상 팀과 실제 운영 담당이 다를 때가 있거든요. 그래서 저는 조직도 그대로만 넣지 않고, 서비스 기준 소유권을 별도로 정리했습니다. 여기서 중요한 건 HR 기준이 아니라 장애 대응 기준입니다.

    3. 플러그인 욕심이 커집니다

    Backstage는 플러그인이 많고 확장성이 좋아서, 운영하다 보면 이것저것 붙이고 싶어집니다. 그런데 여기서 많이 흔들립니다. 저도 한동안 대시보드, 품질 지표, 배포 이력, API 문서, 비용 정보까지 한 화면에 다 넣어보려 했는데요. 결과적으로는 정보 밀도가 너무 높아져서 오히려 안 보게 되더라고요.

    정말 자주 보는 정보만 전면에 두고, 나머지는 링크로 넘기는 구조가 오래 갑니다.

    4. 권한 관리가 늦어지면 나중에 더 아픕니다

    초기엔 내부 도구니까 대충 열어두자 싶을 수 있습니다. 저도 솔직히 그랬습니다. 그런데 문서, 운영 대시보드, 템플릿 액션이 늘어나면 접근 제어가 갑자기 중요해집니다. 특히 프로덕션 관련 링크나 자동화 액션이 연결되기 시작하면 더 그렇습니다.

    backend:
  auth:
    keys:
      - secret: ${BACKEND_SECRET}
permission:
  enabled: true

    다만 실제 운영에서는 설정만 넣는다고 끝나지 않습니다. 현재 공식 문서 기준으로는 app-config.yaml의 permission.enabled: true 설정과 함께, 백엔드에 permission policy를 연결하는 작업이 같이 필요합니다. 여기서는 방향만 보여드리는 예시로 봐주시면 됩니다.

    개발자 포털 구축 과정에서 인증과 템플릿 자동화 흐름을 보여주는 이미지

    SSO 로그인 이후 템플릿 실행, 저장소 생성, 카탈로그 등록으로 이어지는 운영 자동화 흐름을 보여주는 이미지입니다.

    검증: 무엇이 실제로 달라졌나

    정량 지표를 과하게 꾸미고 싶진 않습니다. 다만 1년 운영하면서 체감 변화는 분명했습니다.

    • 신규 입사자 온보딩 시 서비스 위치 파악이 빨라졌습니다.
    • 운영 중 “이 서비스 누가 보나요?”라는 질문이 줄었습니다.
    • 표준 저장소 구조가 어느 정도 정착됐습니다.
    • 문서 링크와 대시보드 링크를 찾는 시간이 줄었습니다.

    특히 장애 대응 때 차이가 컸습니다. 예전에는 메신저 검색부터 했거든요. 이제는 포털에서 서비스를 보고, 담당 팀을 보고, 관련 문서와 대시보드로 넘어가는 흐름이 꽤 자연스러워졌습니다. 이럴 때는 “아, 이거 도입하길 잘했네” 싶더라고요.

    반대로 기대보다 덜 바뀐 것도 있습니다.

    • 문서 최신화는 도구만으로 해결되지 않았습니다.
    • 카탈로그 품질은 각 팀의 습관에 크게 좌우됐습니다.
    • 포털 접속 빈도는 팀마다 차이가 컸습니다.

    그래서 CNCF Backstage를 만능 해결책으로 보면 실망할 수 있습니다. 이건 포털 소프트웨어이면서 동시에 운영 문화 도구입니다. 플랫폼 엔지니어링의 일부이지, 전부는 아니더라고요.

    Backstage 운영 후기 결과를 보여주는 대시보드와 성과 시각화 이미지

    서비스 소유권 가시성, 온보딩 속도 개선, 문서 연결 상태 등을 대시보드 형태로 요약한 이미지입니다.

    Backstage 도입 사례로 정리하는 운영 팁

    중요한 포인트만 추리면 이렇습니다.

    1. 카탈로그부터 시작하세요. 검색성과 소유권이 먼저입니다.
    2. 템플릿은 적게 만드세요. 제일 많이 쓰는 패턴 한두 개가 효과적입니다.
    3. 문서 품질 책임은 각 팀에 남겨두세요. 플랫폼팀이 대신 다 맡기는 어렵습니다.
    4. 권한 모델을 초기에 잡으세요. 뒤늦게 손보면 연결 범위가 너무 넓어집니다.
    5. 플러그인은 신중하게 늘리세요. 첫 화면은 단순해야 계속 보게 됩니다.
    상황 추천 접근 피해야 할 접근
    초기 도입 카탈로그 중심 MVP 모든 기능 동시 도입
    템플릿 설계 반복 패턴 우선 팀별 전용 템플릿 난립
    문서 운영 작성 책임 분산 플랫폼팀 단독 관리
    권한 관리 초기 정책 정의 운영 후반 일괄 정리
    플러그인 확장 핵심 정보만 노출 한 화면에 모든 정보 집약

    정리와 다음 단계

    Backstage 운영 후기를 한 줄로 줄이면 이렇습니다. “설치는 빠른데, 정착은 결국 운영 설계의 문제다.” 저도 처음엔 도구만 잘 깔면 해결될 줄 알았는데, 실제로 써보니 카탈로그 품질, 조직 책임, 템플릿 설계, 권한 정책 같은 기본기가 훨씬 중요했습니다.

    Backstage 도입 사례를 찾고 있다면 너무 크게 시작하지 않는 편이 낫습니다. 개발자 포털은 예쁜 화면이 아니라 팀의 작업 흐름을 바꾸는 도구입니다. 그래서 작게 시작해서, 자주 쓰는 흐름부터 붙이는 쪽이 훨씬 잘 되더라고요. 이전 글에서 다룬 홈랩 기반 GitOps 실험도 함께 읽어보시면 도입 배경을 더 자연스럽게 이어서 보실 수 있습니다.

    다음 글에서는 TechDocs 운영 방식이나 소프트웨어 템플릿 표준화 전략을 더 깊게 다뤄볼 예정입니다.

    도입 전후 차이, 추천 시작 순서, 운영 시 주의할 점을 한 장으로 정리한 요약 인포그래픽입니다.

    자주 묻는 질문

    Backstage는 작은 팀에도 필요할까요?

    작은 팀이라면 반드시 필요하다고 보긴 어렵습니다. 다만 서비스 수가 늘고, 팀이 분화되고, 온보딩 비용이 커지기 시작하면 가치가 확실히 보입니다.

    개발자 포털 구축에서 가장 먼저 해야 할 일은 뭔가요?

    서비스 목록과 소유권 정리입니다. 화려한 자동화보다 먼저, 누가 어떤 서비스를 책임지는지 보여야 합니다.

    플랫폼 엔지니어링과 Backstage는 같은 말인가요?

    같지는 않습니다. Backstage는 플랫폼 엔지니어링을 구현할 때 쓰는 여러 도구 중 하나에 가깝습니다. 운영 방식과 조직 합의가 더 중요합니다.

    CNCF Backstage를 도입하면 문서 문제가 해결되나요?

    문서 위치 문제는 꽤 좋아집니다. 다만 문서 최신화 문제까지 자동으로 해결되진 않습니다. 그건 팀 습관과 리뷰 문화가 같이 따라와야 합니다.

  • [k8s] Pod Security Standards 마이그레이션: Kubernetes PSP에서 안전하게 전환하기

    [k8s] Pod Security Standards 마이그레이션: Kubernetes PSP에서 안전하게 전환하기

    목차

    Pod Security Standards 마이그레이션: Kubernetes PSP에서 안전하게 전환하기

    Kubernetes 클러스터를 오래 운영했다면 PSP(PodSecurityPolicy) 때문에 한 번쯤 머리가 아팠을 겁니다. 저도 그랬습니다. 그런데 PSP는 Kubernetes 1.21에서 deprecated 되었고, Kubernetes 1.25에서 완전히 제거됐습니다. 그래서 Pod Security Standards 마이그레이션은 이제 선택이 아니라 업그레이드와 운영 안정성을 위해 꼭 챙겨야 할 작업이 됐습니다. 이번 글에서는 Kubernetes 보안 관점에서 PSP 대체 수단인 PSS(Pod Security Standards)와 Pod Security Admission으로 어떻게 안전하게 전환하는지, 실무 기준으로 차근차근 정리해보겠습니다.

    처음엔 저도 PSS가 너무 단순해 보여서 오히려 불안했습니다. PSP처럼 세부 필드를 다 적는 방식에 익숙하면 더 그렇게 느껴지거든요. 그런데 실제로 운영해보니 팀 공통 보안 기준을 맞추는 데는 훨씬 현실적이더라고요. 대신 전환 순서를 잘못 잡으면 배포가 갑자기 막힐 수 있습니다. 여기서 핵심은 처음부터 enforce로 가지 말고 warn, audit로 먼저 관찰하는 것입니다.

    Pod Security Standards 마이그레이션 개요를 보여주는 Kubernetes 보안 아키텍처 이미지

    PSP에서 PSS와 Pod Security Admission으로 넘어가는 흐름을 한눈에 보여주는 개요 이미지입니다.

    왜 Pod Security Standards 마이그레이션이 중요한가

    예전 방식인 PSP는 표현력은 강했지만 운영 피로도도 높았습니다. 반면 PSS는 Privileged, Baseline, Restricted라는 공통 보안 레벨을 제공해서 팀 간 기준을 맞추기 훨씬 쉽습니다. 여러 네임스페이스를 운영하는 환경에서는 긴 정책 객체를 계속 유지하는 것보다, 보안 수준을 레벨로 선언하는 편이 관리가 훨씬 단순합니다.

    제가 직접 겪어보니 Pod Security Standards 마이그레이션의 장점은 분명했습니다. 신규 팀원에게 설명하기 쉽고, 클러스터 업그레이드 때 정책 호환성 이슈가 크게 줄어듭니다. 다만 PSP처럼 아주 세밀한 예외 제어를 기대하면 아쉬울 수 있습니다. 그런 경우에는 OPA Gatekeeper나 Kyverno 같은 정책 엔진을 함께 쓰는 구성이 더 잘 맞습니다.

    Pod Security Standards 마이그레이션 기준: PSP와 PSS는 무엇이 다를까

    처음 보면 이름만 바뀐 것처럼 느껴질 수 있는데 구조는 꽤 다릅니다. PSP는 정책 리소스를 만들고 RBAC으로 사용자나 서비스어카운트와 연결하는 방식이었습니다. 반면 PSS는 네임스페이스에 보안 수준을 라벨로 선언하고, Pod Security Admission이 그 기준으로 파드를 검사합니다.

    항목 PSP PSS + Pod Security Admission
    정책 방식 세부 필드 기반 정책 객체 사전 정의된 보안 표준 레벨
    적용 범위 RBAC과 연결해 사용 네임스페이스 라벨 기반 적용
    운영 난이도 높은 편 상대적으로 단순
    이식성 클러스터별 편차 큼 표준화하기 좋음
    세밀한 예외 처리 강점 제한적, 필요 시 별도 정책 엔진 보완

    PSS의 핵심 레벨은 아래처럼 이해하면 편합니다.

    • Privileged: 사실상 제한이 거의 없는 수준입니다. 시스템 워크로드나 인프라성 컴포넌트에 가깝습니다.
    • Baseline: 일반 애플리케이션에 적용하기 좋은 현실적인 최소 보호선입니다.
    • Restricted: 현재 권장되는 강한 하드닝 기준입니다. 대신 기존 애플리케이션은 여기서 많이 걸릴 수 있습니다.

    Pod Security Admission 적용 방법: 전환 전에 꼭 확인할 것

    Pod Security Admission은 파드 생성 시점에 PSS 기준을 검사하는 내장 Admission Controller입니다. 다만 여기서 하나 짚고 갈 점이 있습니다. warn과 audit는 Deployment 같은 워크로드 리소스에도 경고를 보여주지만, enforce는 최종적으로 생성되는 Pod에 적용됩니다. 이 차이를 알고 있어야 배포 시 메시지를 덜 헷갈립니다.

    1. enforce: 정책을 어기면 Pod 생성이 거부됩니다.
    2. audit: 생성은 허용되지만 감사 로그에 위반 정보가 남습니다.
    3. warn: 생성은 허용되지만 클라이언트에 경고가 표시됩니다.

    실무에서 자주 하는 실수가 바로 여기입니다. 바로 enforce부터 켜버리면 그동안 관성적으로 돌아가던 워크로드가 한꺼번에 실패할 수 있거든요. 저도 테스트 환경에서 ingress controller가 안 떠서 꽤 오래 본 적이 있습니다. 알고 보니 hostNetwork와 securityContext 설정이 기준에 안 맞았더라고요. 이런 경험을 한 번 하면 warn, audit부터 가야 하는 이유가 확실히 보입니다.

    전환 전 체크리스트

    • 현재 클러스터에서 PSP를 실제로 쓰는 네임스페이스가 어디인지 확인합니다.
    • 권한 상승 허용 여부를 점검합니다.
    • root 실행, hostPath 마운트, hostNetwork 사용 여부를 확인합니다.
    • DaemonSet, CSI, 모니터링 에이전트처럼 예외가 필요한 워크로드를 분리합니다.
    • 애플리케이션 네임스페이스와 시스템 네임스페이스를 같은 기준으로 묶지 않습니다.

    실전 구현: Pod Security Standards 마이그레이션 순서

    여기서는 제가 실제로 권장하는 순서를 정리해보겠습니다. 핵심은 단순합니다. 관찰 먼저, 강제는 나중. 이 순서만 지켜도 사고 확률이 확실히 줄어듭니다.

    1. 현재 네임스페이스 라벨 상태 확인

    kubectl get ns --show-labels

    기존에 이미 pod-security 관련 라벨이 붙어 있는지 먼저 확인합니다. 다른 운영자가 먼저 설정해둔 경우도 생각보다 자주 있습니다. 이 상태를 모르고 덮어쓰면 원인 파악이 더 어려워집니다.

    2. 먼저 warn, audit 모드로 Baseline 적용

    kubectl label ns my-app \
  pod-security.kubernetes.io/warn=baseline \
  pod-security.kubernetes.io/audit=baseline \
  --overwrite

    처음부터 Restricted로 가고 싶어도 일단 Baseline부터 보는 편이 안전합니다. 여기서 어떤 워크로드가 경고를 내는지 파악해야 다음 단계가 보입니다. 이 단계가 생각보다 중요하더라고요.

    3. 버전 라벨도 함께 명시해 드리프트 줄이기

    kubectl label ns my-app \
  pod-security.kubernetes.io/warn-version=v1.36 \
  pod-security.kubernetes.io/audit-version=v1.36 \
  --overwrite

    버전 라벨은 선택 사항이지만 운영에선 거의 필수에 가깝습니다. PSS 해석 기준은 Kubernetes 마이너 버전에 따라 달라질 수 있어서, 테스트와 운영 클러스터의 결과가 어긋나는 일을 줄여주거든요. 다만 예시 값을 그대로 복붙하기보다는 현재 클러스터의 마이너 버전에 맞춰 적는 게 맞습니다.

    4. 경고 메시지로 문제 워크로드 찾기

    kubectl apply -f deployment.yaml

    배포 시 warn 메시지가 뜨면 그 내용을 기준으로 수정합니다. warn과 audit는 Deployment 같은 워크로드 리소스에도 적용되기 때문에, 이 단계에서 꽤 많은 힌트를 얻을 수 있습니다. 흔히 손보게 되는 포인트는 아래와 같습니다.

    • runAsNonRoot: non-root 실행 강제
    • allowPrivilegeEscalation: false 설정
    • seccompProfile: RuntimeDefault 적용
    • capabilities: 불필요한 Linux capability 제거
    Pod Security Admission과 네임스페이스 라벨 기반 PSS 적용 방법을 설명하는 이미지

    네임스페이스에 warn, audit, enforce 라벨을 붙이는 방식과 적용 흐름을 보여주는 이미지입니다.

    5. 매니페스트 보안 컨텍스트 정리

    아래 예시는 Restricted로 가기 전에 가장 자주 쓰는 기본 골격입니다.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: web-app
          image: nginx:stable
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL
          ports:
            - containerPort: 80

    이 예시는 아주 화려하지는 않지만, 실제로 많이 걸리는 조건을 담고 있습니다. 특히 runAsNonRoot는 이미지 자체가 non-root 실행을 지원해야 제대로 동작합니다. 오래된 이미지라면 매니페스트만 고쳐서는 해결이 안 되고, 컨테이너 이미지 베이스부터 손봐야 할 때가 있습니다.

    6. 문제 없으면 enforce 전환

    kubectl label ns my-app \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/enforce-version=v1.36 \
  --overwrite

    여기서도 한 번에 모든 네임스페이스를 바꾸는 건 추천하지 않습니다. 서비스 영향이 낮은 곳부터 묶어서 적용하고, 모니터링으로 이상이 없는지 확인한 뒤 확대하는 방식이 제일 덜 아픕니다. 이거 진짜 차이가 큽니다.

    Restricted까지 가려면 어떤 점을 더 봐야 하나

    Pod Security Standards 마이그레이션을 시작하면 많은 팀이 최종 목표를 Restricted로 잡습니다. 방향은 맞습니다. 다만 현실적으로 모든 워크로드가 바로 들어가지는 않더라고요. 특히 아래 항목은 자주 발목을 잡습니다.

    1. 레거시 이미지가 root 실행을 전제로 만들어져 있음
    2. initContainer에서 과한 권한을 사용함
    3. 모니터링, 스토리지, 네트워크 에이전트가 호스트 접근을 필요로 함
    4. hostPath 사용이 습관처럼 들어가 있음

    그래서 저는 보통 네임스페이스를 이렇게 나눕니다.

    네임스페이스 유형 권장 레벨 비고
    일반 애플리케이션 Baseline 또는 Restricted 신규 서비스는 Restricted 목표
    운영 도구 Baseline 필요 권한 확인 후 점진 강화
    시스템 워크로드 Privileged 또는 별도 예외 관리 CNI, CSI, 일부 에이전트 주의

    트러블슈팅: Pod Security Standards 마이그레이션에서 자주 막히는 지점

    문서만 보면 금방 끝날 것 같지만, 운영 환경에 붙이면 여기서 한 번씩 다 막힙니다. 저도 몇 번은 꽤 돌아갔습니다. 그래서 아래 포인트는 미리 보고 들어가는 편이 좋습니다.

    1. 배포가 갑자기 거부될 때

    enforce가 켜진 네임스페이스에 정책 위반 Pod가 들어가면 바로 거부됩니다. 이 경우 이벤트와 매니페스트를 같이 봐야 합니다.

    kubectl describe pod <pod-name> -n my-app
kubectl get events -n my-app --sort-by=.lastTimestamp

    경고 문구만 보고 대충 고치면 같은 문제를 반복하기 쉽습니다. 어떤 필드가 위반인지 정확히 확인하고, Pod 템플릿 기준으로 수정해야 합니다.

    2. 시스템 네임스페이스까지 묶어서 막힐 때

    이 부분은 정말 조심해야 합니다. kube-system 같은 곳에 일반 앱과 같은 Restricted를 걸면 예상치 못한 장애가 날 수 있습니다. 네트워크 플러그인, 스토리지 드라이버, 노드 에이전트가 영향을 받는 경우가 대표적입니다. 실제 운영에선 시스템성 워크로드를 별도 기준으로 다루는 게 훨씬 안전합니다.

    3. warn은 뜨는데 배포가 되니까 그냥 넘길 때

    처음엔 “배포는 되네” 하고 넘기기 쉽습니다. 그런데 나중에 enforce로 바꾸는 순간 한꺼번에 터집니다. 그래서 warn 단계에서 바로 티켓을 만들고, 팀별 수정 일정을 잡아두는 편이 훨씬 낫습니다.

    4. PSP 기능과 1:1 대응을 기대할 때

    PSP 대체라고 해서 완전히 같은 경험을 기대하면 실망할 수 있습니다. PSS는 표준 보안 레벨을 제공하는 방식이고, 세밀한 조직별 규칙은 별도 정책 도구가 더 적합합니다. 이 차이를 이해하고 설계해야 전환 이후 불만도 줄어듭니다.

    검증: Pod Security Admission이 제대로 동작하는지 확인하는 방법

    적용 후에는 라벨만 붙였다고 끝이 아닙니다. 검증이 꼭 필요합니다. 제가 보통 확인하는 항목은 아래와 같습니다.

    1. 네임스페이스 라벨이 의도한 값으로 들어갔는지 확인
    2. warn 메시지가 줄거나 사라졌는지 확인
    3. 문제 Pod 없이 롤링 업데이트가 완료되는지 확인
    4. 시스템 워크로드가 영향 없이 유지되는지 확인
    kubectl get ns my-app --show-labels
kubectl rollout status deploy/web-app -n my-app
kubectl get pods -n my-app

    조금 더 확실히 보려면 의도적으로 정책 위반 Pod를 하나 던져보는 것도 방법입니다. 다만 이 테스트는 운영 네임스페이스가 아니라 테스트 네임스페이스에서만 하는 편이 안전합니다.

    apiVersion: v1
kind: Pod
metadata:
  name: pss-test
  namespace: my-app
spec:
  hostNetwork: true
  containers:
    - name: busybox
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]
      securityContext:
        allowPrivilegeEscalation: true

    Baseline이나 Restricted enforce가 걸려 있다면 이런 Pod는 거부되는 게 정상입니다. hostNetwork는 Baseline부터 금지되고, allowPrivilegeEscalation은 Restricted에서 금지되기 때문에 테스트용으로 확인하기 좋습니다.

    Pod Security Standards 마이그레이션 검증 결과를 보여주는 Kubernetes 보안 이미지

    정책 위반 테스트와 정상 배포가 어떻게 다르게 보이는지 검증 결과를 시각화한 이미지입니다.

    운영 팁: 네임스페이스 전략을 먼저 정하면 훨씬 편합니다

    제가 여러 번 해보니, PSS 적용 방법에서 제일 중요한 건 YAML 문법보다 운영 기준이었습니다. 다시 말해 “어떤 네임스페이스를 어떤 신뢰 수준으로 볼 것인가”를 먼저 정해야 합니다. 이 기준이 없으면 팀마다 예외 요청이 쌓이고, 결국 정책이 누더기가 되더라고요.

    • 신규 서비스는 기본적으로 Baseline 또는 Restricted로 시작합니다.
    • 예외가 필요한 시스템성 워크로드는 별도 네임스페이스로 분리합니다.
    • warn과 audit 결과를 주기적으로 점검해 enforce 후보를 올립니다.
    • 정책 예외는 문서화하고 만료 시점을 정합니다.

    이런 방식으로 가면 Kubernetes 보안이 특정 담당자 감에 의존하지 않고 팀 표준으로 자리 잡습니다. 이전에 정리한 RBAC 글이 있다면 같이 연결해두는 것도 좋습니다. 내부 링크 흐름이 생기면 독자 입장에서도 이해가 더 빨라지고, SEO 측면에서도 분명 도움이 됩니다.

    정리: PSP에서 PSS로 갈아탈 때 기억할 것

    오늘 내용을 짧게 정리하면 이렇습니다. Pod Security Standards 마이그레이션은 단순한 기능 교체가 아니라, 보안 운영 방식을 표준화하는 작업입니다. PSP보다 세밀한 제어는 줄었지만, 네임스페이스 단위로 기준을 맞추기 쉬워졌고, Pod Security Admission으로 warn, audit, enforce를 단계적으로 운영할 수 있게 됐습니다.

    저도 처음엔 이 구조가 너무 단순한 것 아닌가 싶었습니다. 그런데 실제로는 팀 단위 운영에 더 잘 맞더라고요. 다만 무작정 enforce부터 걸면 안 됩니다. 꼭 warn, audit으로 현재 상태를 먼저 파악하고, Restricted는 목표로 두되 시스템 워크로드 예외를 현실적으로 분리해 가져가면 훨씬 수월합니다.

    지금 클러스터 업그레이드를 앞두고 있다면 이번 주에라도 테스트 네임스페이스 하나 만들어 Baseline warn부터 붙여보세요. 생각보다 빨리 문제가 보입니다. 그리고 이전에 다뤘던 RBAC 정리 글도 함께 보면 흐름이 더 잘 잡힐 겁니다. 다음 글에서는 Kyverno나 Gatekeeper로 PSS의 빈틈을 어떻게 보완하는지도 이어서 정리해보겠습니다.

    PSP 대체와 Pod Security Standards 보안 레벨 비교를 정리한 인포그래픽 이미지

    PSP와 PSS의 차이, 적용 순서, 운영 체크포인트를 한 장으로 정리한 요약 인포그래픽입니다.

    자주 묻는 질문

    PSS만으로 PSP를 완전히 대체할 수 있나요?

    기본적인 표준화 목적에는 충분한 경우가 많습니다. 다만 세밀한 조건 제어나 예외 검증이 많다면 Kyverno나 Gatekeeper 같은 정책 엔진을 함께 검토하는 편이 좋습니다.

    처음부터 Restricted로 가도 되나요?

    신규 서비스만 있고 이미지와 매니페스트를 처음부터 통제할 수 있는 환경이라면 가능합니다. 하지만 기존 워크로드가 있다면 Baseline warn, audit부터 시작하는 편이 훨씬 안전합니다.

    Pod Security Admission은 어디에 적용되나요?

    네임스페이스 라벨 기준으로 해당 네임스페이스의 Pod 생성에 영향을 줍니다. 또 warn과 audit는 Deployment 같은 워크로드 리소스에도 힌트를 주기 때문에, 네임스페이스 전략과 배포 검증 루틴을 함께 가져가는 게 중요합니다.

  • [k8s] Karpenter 오토스케일로 EKS 비용 절감 검증하는 방법

    [k8s] Karpenter 오토스케일로 EKS 비용 절감 검증하는 방법

    목차

    Karpenter 오토스케일로 EKS 비용 절감 검증하는 방법

    Karpenter 오토스케일을 검토하시는 분들은 비슷한 지점에서 막히곤 합니다. HPA로 파드 수는 잘 늘고 줄어드는데, 월말 청구서를 보면 노드가 생각보다 오래 남아 있어서 클라우드 비용 절감 체감이 약하거든요. 특히 AWS EKS를 운영하다 보면 파드 오토스케일링과 노드 비용 최적화가 완전히 같은 문제가 아니라는 점을 금방 느끼게 됩니다.

    저도 초반에는 “HPA만 잘 잡으면 끝나는 거 아닌가?” 싶었는데, 실제로는 노드 단위 빈 공간이 더 큰 병목이었습니다. 이럴 때 Karpenter 오토스케일은 파드 요구사항에 맞춰 노드를 더 유연하게 만들고, 유휴 노드를 정리하는 데 강점이 있습니다. 이번 글에서는 Kubernetes 오토스케일링 관점에서 Karpenter가 왜 비용 최적화에 유리한지, 그리고 AWS EKS 비용 최적화 효과를 어떤 지표로 검증해야 하는지 정리해보겠습니다.

    Karpenter 오토스케일 기반 EKS 아키텍처 개요 이미지

    Karpenter가 스케줄링되지 못한 파드를 감지하고 적절한 EC2 노드를 만들고, 유휴 노드를 정리하는 흐름을 보여주는 이미지입니다.

    Karpenter 오토스케일이 비용 절감에 유리한 이유

    쉽게 말해 Karpenter는 파드가 실제로 필요로 하는 리소스에 맞춰 노드를 바로 만들어주는 도구입니다. 기존 Cluster Autoscaler도 노드 수를 늘리고 줄일 수 있지만, 보통 미리 정의한 노드 그룹을 중심으로 확장하다 보니 리소스가 남는 구간이 생기기 쉽습니다.

    반면 Karpenter는 Pending 상태의 파드를 보고 CPU, 메모리, 아키텍처, 용량 유형(온디맨드/스팟) 같은 조건에 맞는 인스턴스를 더 유연하게 고릅니다. 운영에서 보면 이 차이가 꽤 큽니다. 특정 인스턴스 몇 개만 반복해서 늘리는 대신, 워크로드 특성에 맞춰 c 계열, m 계열, r 계열을 섞고 스팟까지 활용하기 쉬워지거든요.

    항목 Cluster Autoscaler Karpenter
    확장 기준 기존 노드 그룹 중심 파드 요구사항 중심
    인스턴스 선택 유연성 상대적으로 제한적 높음
    빈 리소스 최소화 노드 그룹 크기에 영향 받음 상황별 최적화에 유리
    스팟 활용 구성 복잡도 있음 정책 설계가 비교적 직관적
    비용 절감 포인트 노드 수 축소 노드 크기와 종류까지 최적화

    핵심은 단순히 노드를 빨리 만드는 데 있지 않습니다. Karpenter 오토스케일의 진짜 장점은 불필요하게 큰 노드를 오래 붙잡고 있지 않게 만드는 구조에 있습니다. 결국 비용은 시간당 단가와 실행 시간의 곱이라서, 둘을 같이 줄여야 체감이 나더라고요.

    Karpenter 오토스케일 도입 전에 먼저 봐야 할 비용 지표

    Karpenter를 붙였는데도 “그래서 얼마가 절감됐지?”를 설명하지 못하면 운영팀 설득이 어렵습니다. 감으로 보면 꼭 해석이 꼬입니다. 최소한 아래 지표는 같은 기간 기준으로 같이 보는 편이 좋습니다.

    • 노드 평균 사용률: CPU와 메모리 요청량 대비 실제 사용률
    • 유휴 시간: 야간 또는 비업무 시간에 노드가 얼마나 오래 남는지
    • 파드 Pending 빈도: 확장 지연이 발생하는지
    • 인스턴스 타입 다양성: 특정 타입에 과도하게 묶여 있는지
    • 스팟 비중: 안정성과 비용 균형이 맞는지

    메트릭은 CloudWatch, Prometheus, Grafana 조합으로 많이 보고, 비용은 AWS Cost Explorer 또는 CUR로 맞춰보면 됩니다. 포인트는 하나입니다. 메트릭과 비용 데이터를 반드시 같은 기간으로 맞춰서 비교해야 한다는 점입니다.

    Kubernetes 오토스케일링 구성, 이렇게 잡으면 시작이 편합니다

    실전 구현 자체는 아주 복잡하지 않습니다. 다만 EKS 클러스터가 이미 있어야 하고, IRSA 또는 EKS Pod Identity 같은 AWS 권한 구성이 가능해야 합니다. 그리고 Karpenter가 파드 요청값을 기준으로 판단하므로 워크로드의 resources.requests가 비어 있으면 기대한 최적화가 잘 나오지 않습니다. 이 부분은 정말 중요합니다.

    1. EKS 클러스터 이름과 리전을 환경 변수로 설정합니다.
    2. Karpenter 컨트롤러용 IAM 역할과 중단 이벤트용 큐를 준비합니다.
    3. Helm으로 Karpenter를 설치합니다.
    4. NodePool과 EC2NodeClass를 정의합니다.
    5. 워크로드의 requests/limits를 다시 점검합니다.
    export CLUSTER_NAME=my-eks
export AWS_DEFAULT_REGION=ap-northeast-2
export KARPENTER_NAMESPACE=karpenter
export KARPENTER_VERSION=1.14.0
export KARPENTER_IAM_ROLE_ARN=arn:aws:iam::123456789012:role/KarpenterControllerRole

aws eks update-kubeconfig --name $CLUSTER_NAME --region $AWS_DEFAULT_REGION
kubectl config current-context
kubectl get nodes

    클러스터 연결부터 먼저 확인해두세요. 여기서 컨텍스트가 꼬이면 다른 클러스터에 배포하는 사고가 의외로 자주 납니다. 한 번만 겪어도 이 단계가 왜 중요한지 바로 느껴지더라고요.

    Karpenter 설치 예시

    helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version $KARPENTER_VERSION \
  --namespace $KARPENTER_NAMESPACE \
  --create-namespace \
  --set settings.clusterName=$CLUSTER_NAME \
  --set settings.interruptionQueue=$CLUSTER_NAME \
  --set serviceAccount.annotations.eks\.amazonaws\.com/role-arn=$KARPENTER_IAM_ROLE_ARN \
  --wait

kubectl -n $KARPENTER_NAMESPACE get pods

    설치가 끝나면 컨트롤러 파드가 정상 기동하는지 먼저 확인합니다. 여기서 CrashLoopBackOff가 보이면 IAM 권한, 서브넷 태그, 보안 그룹 태그, 이벤트 큐 설정부터 보는 게 빠릅니다.

    Karpenter 오토스케일 설정과 NodePool 연결 구조 이미지

    Karpenter 컨트롤러, NodePool, EC2NodeClass, 워크로드 파드가 어떻게 연결되는지 보여주는 구성 다이어그램입니다.

    NodePool과 EC2NodeClass 예시

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["c6i.large", "m6i.large", "r6i.large"]
      expireAfter: 720h
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m
  limits:
    cpu: "200"
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  role: KarpenterNodeRole-my-eks
  amiSelectorTerms:
    - alias: al2023@latest
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-eks
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-eks

    여기서 핵심은 세 가지입니다. 첫째, NodePool에는 nodeClassRef가 필요합니다. 둘째, 최근 EKS 기준으로는 AL2보다 AL2023 계열 AMI 선택이 더 자연스럽습니다. 셋째, consolidation을 켜야 유휴 노드 정리가 제대로 일어납니다. 실제 비용 절감은 스케일 아웃보다 이 정리 단계에서 더 크게 체감되는 경우가 많습니다.

    테스트용 워크로드 배포

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 0
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      terminationGracePeriodSeconds: 0
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: 1

    kubectl apply -f inflate.yaml
kubectl scale deployment inflate --replicas 5
kubectl get pods -w

    이렇게 테스트하면 Pending 상태였던 파드 수요를 Karpenter가 보고 새 노드를 띄우는 흐름을 확인할 수 있습니다. 이후 replicas를 다시 줄이거나 배포를 삭제해보면 노드 통합 정리까지 관찰할 수 있습니다. 작은 워크로드부터 붙여보는 방식이 운영 리스크도 낮고 결과도 해석하기 편합니다.

    AWS EKS 비용 최적화를 위한 운영 포인트

    이 섹션은 꼭 짚고 넘어가야 합니다. Karpenter를 도입했다고 자동으로 클라우드 비용 절감이 되진 않습니다. 정책을 어떻게 잡느냐에 따라 결과가 꽤 다르게 나옵니다.

    • requests를 현실적으로 작성: 과장된 요청값은 큰 노드를 계속 부릅니다.
    • 스팟과 온디맨드 혼합: 서비스 성격에 따라 풀을 나누는 편이 안정적입니다.
    • 워크로드 분리: API 서버 계열과 배치 계열을 같은 NodePool에 몰지 않는 게 좋습니다.
    • 스케일 인 여유 시간 확인: 너무 공격적으로 줄이면 재기동이 잦아질 수 있습니다.
    • PodDisruptionBudget 검토: 축소가 막혀 노드가 안 내려가는 경우가 생각보다 많습니다.

    처음부터 모든 워크로드를 하나의 NodePool에 넣으면 정책 충돌이 생기기 쉽습니다. 최소한 안정성 우선 풀과 비용 우선 풀 정도는 분리해두면 운영이 훨씬 편합니다. 이거 진짜 편하더라고요.

    ⚠️ 실제로 많이 겪는 문제와 해결법

    문서만 보면 금방 될 것 같아도 운영 환경에서는 자잘한 함정이 많습니다. 특히 권한, 태그, 요청값 같은 기본 설정에서 많이 막힙니다.

    1. 노드가 아예 생성되지 않는 경우

    대부분은 IAM 또는 태그 문제입니다. 서브넷과 보안 그룹에 karpenter.sh/discovery 태그가 빠져 있으면 인프라 리소스를 찾지 못합니다.

    kubectl describe nodepool default
kubectl -n karpenter logs deploy/karpenter

    로그에서 subnet, security group, instance profile, access denied 관련 메시지를 먼저 확인하면 원인이 빨리 보입니다.

    2. 노드는 생기는데 비용이 생각보다 안 줄어드는 경우

    이 경우도 자주 나옵니다. 원인은 대개 세 가지입니다.

    • 파드 requests가 과하게 큼
    • PodDisruptionBudget 때문에 빈 노드를 못 비움
    • 스팟 허용 범위가 너무 좁음

    Karpenter가 덜 똑똑해서가 아니라 입력값이 비효율적인 경우가 많습니다. 결국 스케줄러와 오토스케일러도 선언된 요청값을 기준으로 움직이니까요.

    3. 스팟 중단 대응이 불안한 경우

    스팟은 비용 면에서 매력적이지만 서비스 성격에 따라 조심해야 합니다. 중단 알림을 받았을 때 드레이닝과 재스케줄링이 자연스럽게 되도록 준비가 필요합니다. 중요한 서비스는 무조건 스팟으로 몰기보다 온디맨드와 섞는 편이 안전합니다.

    Karpenter 오토스케일 비용 절감 결과 대시보드 이미지

    파드 수 증가에 따라 노드가 늘고, 유휴 시간대에 통합 정리로 노드 수가 줄어드는 메트릭 대시보드 예시입니다.

    Karpenter 오토스케일 비용 절감 효과, 어떻게 검증해야 할까

    여기서 중요한 건 “노드 수가 줄었다”로 끝내지 않는 겁니다. 노드 수는 줄었는데 더 비싼 타입을 오래 썼다면 의미가 없거든요. 저는 아래 순서로 비교하면 결과 해석이 가장 깔끔했습니다.

    1. 도입 전 2주와 도입 후 2주를 비교합니다.
    2. 같은 요일, 같은 시간대 기준으로 워크로드 패턴을 맞춥니다.
    3. EC2 비용, 노드 평균 개수, 평균 vCPU 사용률을 함께 봅니다.
    4. 배포 실패, Pending 시간, 재스케줄링 지연이 늘지 않았는지 확인합니다.
    5. 스팟 비중 증가가 장애로 이어지지 않았는지 점검합니다.

    특히 비용 / 요청 처리량 같은 지표가 설명력이 좋습니다. 같은 트래픽을 처리하는데 필요한 EC2 비용이 줄었는지 보면, 단순 총액보다 훨씬 설득력이 있습니다. 팀 내 공유 문서에도 이 지표를 같이 적어두면 의사결정이 빨라집니다.

    kubectl top nodes
kubectl top pods -A
aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-07-15 \
  --granularity DAILY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

    위 명령은 비용 추세를 보는 기본 예시입니다. 참고로 Cost Explorer의 종료일은 보통 마지막 날짜 다음 날로 잡아야 비교가 깔끔합니다. 운영에서는 CUR를 Athena로 조회하거나 Grafana에 연결해 시계열로 보는 쪽이 더 편합니다.

    해석할 때 주의할 점

    • 도입 직후 며칠은 캐시, 배포 주기, 스팟 수급 영향으로 흔들릴 수 있습니다.
    • 트래픽 자체가 줄어서 비용이 감소한 것을 Karpenter 효과로 착각하면 안 됩니다.
    • RI나 Savings Plans 영향도 함께 봐야 합니다.

    결국 비교 기준은 같은 부하 조건이어야 합니다. 이 기준만 지켜도 해석 오류가 꽤 줄어듭니다.

    정리: 이런 환경이라면 Karpenter 도입 가치가 큽니다

    다음 조건에 해당하면 Karpenter 도입 효과가 비교적 잘 나옵니다.

    • 트래픽 변동폭이 크다
    • 워크로드 종류가 다양하다
    • EKS에서 인스턴스 타입 선택 폭을 넓게 가져갈 수 있다
    • 스팟 활용 여지가 있다
    • 현재 노드 유휴 시간이 길다

    반대로 워크로드가 매우 단순하고 부하가 거의 고정되어 있다면 체감 효과가 크지 않을 수도 있습니다. 그래서 무조건 도입부터 하기보다, 현재 비효율이 어디서 생기는지 먼저 확인하는 편이 맞습니다. 그다음 작은 서비스에 시범 적용하고 결과를 비교하면 훨씬 덜 위험합니다.

    Karpenter 오토스케일과 기존 오토스케일링 비교 인포그래픽

    노드 그룹 기반 확장과 파드 요구사항 기반 확장의 차이를 한눈에 요약한 비교 이미지입니다.

    마무리

    이번 글의 핵심은 간단합니다. Karpenter 오토스케일은 단순한 증설 도구라기보다, AWS EKS 비용 최적화를 운영 레벨에서 밀어주는 도구에 가깝습니다. 다만 효과는 설치 여부보다 requests 품질, NodePool 정책, 스팟 전략, 검증 방식에 더 크게 좌우됩니다.

    지금 EKS 비용이 애매하게 새고 있다고 느끼신다면, 전면 도입부터 하기보다 작은 워크로드에 먼저 붙여보세요. 그리고 이전 글의 HPA/VPA 튜닝 가이드도 함께 보시면 파드 스케일링과 노드 스케일링을 한 흐름으로 이해하는 데 도움이 됩니다. 다음 글에서는 스팟과 온디맨드 혼합 정책을 어떻게 설계해야 장애 없이 비용을 줄일 수 있는지 이어서 다뤄보겠습니다.

    자주 묻는 질문

    Karpenter만 도입하면 비용이 바로 줄어드나요?

    아닙니다. requests 값, NodePool 정책, 스팟 허용 범위가 같이 맞아야 의미 있는 절감이 나옵니다.

    Cluster Autoscaler를 꼭 버려야 하나요?

    꼭 그렇진 않습니다. 다만 인스턴스 선택 유연성과 운영 단순성이 중요하다면 Karpenter가 더 잘 맞는 환경이 많습니다.

    비용 절감 효과는 무엇으로 확인하나요?

    총 EC2 비용만 보지 말고, 같은 트래픽 대비 비용, 노드 평균 사용률, 유휴 시간, Pending 감소 여부를 함께 보시면 됩니다.

  • [홈랩] 홈랩 VLAN 설정 완벽 가이드: 스위치와 라우터 연동

    [홈랩] 홈랩 VLAN 설정 완벽 가이드: 스위치와 라우터 연동

    목차

    [홈랩] 홈랩 VLAN 설정 완벽 가이드: 스위치와 라우터 연동

    홈랩 VLAN 설정, 한 번 제대로 잡아두면 네트워크가 정말 편해집니다. 서버는 서버끼리, IoT는 IoT끼리, 게스트 Wi-Fi는 내부망과 분리해서 굴릴 수 있거든요. 저도 처음 홈랩을 키울 때는 스위치에 선만 꽂으면 끝인 줄 알았는데, VM 하나 늘고 NAS 하나 붙고 카메라까지 들어오니까 금방 복잡해지더라고요. 결국 VLAN 구성으로 정리하고 나서야 드디어 됐다 싶었습니다. 특히 네트워크 분리와 보안 강화를 같이 챙기고 싶다면, 관리형 스위치와 라우터 VLAN 연동은 거의 필수에 가깝습니다.

    홈랩 VLAN 설정 전체 아키텍처를 보여주는 다이어그램

    관리형 스위치, 라우터, 서버, IoT, 게스트망이 VLAN별로 분리된 전체 구성 예시입니다.

    왜 홈랩 VLAN 설정이 중요한가요

    쉽게 말해 VLAN은 하나의 물리 네트워크를 여러 개의 논리 네트워크로 쪼개는 방식입니다. 선은 같은 스위치에 꽂혀 있어도, VLAN ID가 다르면 서로 다른 네트워크처럼 동작합니다. 이게 왜 좋으냐면요.

    • 관리망(Management)을 따로 빼서 스위치나 하이퍼바이저 관리 페이지를 안전하게 둘 수 있습니다.
    • 서버망(Server Network)과 개인 PC망을 분리해서 사고 범위를 줄일 수 있습니다.
    • IoT망을 따로 두면 카메라나 스마트 플러그가 내부 서버에 함부로 접근하지 못합니다.
    • 게스트망(Guest Network)을 만들면 손님 Wi-Fi를 줘도 마음이 좀 편해집니다.

    여기서 중요한 포인트! VLAN은 만능 보안 장비가 아니라 분리의 기본 단위입니다. 즉, 나누는 것만으로 끝나는 게 아니라 라우터에서 VLAN 간 통신 정책까지 같이 잡아야 진짜 의미가 있습니다.

    VLAN 구성 개념, 쉽게 말해 이렇게 이해하시면 됩니다

    저도 처음엔 태그니 언태그니 하면서 머리가 좀 아팠습니다 ㅎㅎ 그런데 아래 두 가지만 잡으면 금방 감이 옵니다.

    Tagged(태그드)와 Untagged(언태그드)

    Tagged(태그드)는 패킷에 VLAN 번호를 붙여서 보내는 방식입니다. 보통 스위치와 라우터 사이, 스위치와 하이퍼바이저 사이처럼 여러 VLAN을 한 선으로 같이 보낼 때 씁니다. 이 연결을 흔히 Trunk(트렁크)라고 부릅니다.

    Untagged(언태그드)는 패킷에 VLAN 태그를 붙이지 않는 방식입니다. PC 한 대, 프린터 한 대처럼 한 포트에서 한 네트워크만 쓰는 경우에 일반적으로 사용합니다. 이 포트를 흔히 Access(액세스) 포트라고 부르죠.

    PVID와 Native VLAN

    PVID(Port VLAN ID)는 태그 없이 들어온 트래픽을 어떤 VLAN으로 볼지 정하는 값입니다. 관리형 스위치에서 액세스 포트 설정할 때 자주 보게 됩니다. 제조사마다 표현은 조금 달라도 개념은 비슷합니다.

    항목 의미 주로 쓰는 곳
    Tagged VLAN 태그 포함 라우터-스위치, 스위치-서버 업링크
    Untagged VLAN 태그 없음 PC, 프린터, 단일 장비 연결 포트
    PVID 태그 없는 프레임의 기본 VLAN 액세스 포트 기본 소속 설정
    Trunk 여러 VLAN을 한 링크로 전달 업링크 포트

    실제로 써보니까, 홈랩 VLAN 설정에서 가장 많이 꼬이는 부분이 바로 여기였습니다. 스위치에서는 태그드로 보냈는데 라우터는 언태그드만 받고 있다거나, PVID가 엉뚱하게 남아 있다거나요. 증상은 인터넷 안 됨 하나로 보이는데 원인은 꽤 다양합니다.

    실전 설계: 먼저 VLAN 번호부터 정리해보겠습니다

    제가 홈랩에서 자주 쓰는 방식은 아래처럼 역할별로 VLAN을 나누는 겁니다. 꼭 이 숫자를 따라야 하는 건 아니지만, 일단 규칙을 정해두면 나중에 훨씬 덜 헷갈립니다.

    1. VLAN 10: 관리망 (스위치, 라우터, 하이퍼바이저 관리)
    2. VLAN 20: 서버망 (NAS, VM, 컨테이너 호스트)
    3. VLAN 30: IoT망 (카메라, 센서, 스마트 기기)
    4. VLAN 40: 게스트망 (외부 사용자용 Wi-Fi)

    예시 주소 체계도 같이 정해두면 좋습니다.

    vlans:
  10:
    name: mgmt
    subnet: 192.168.10.0/24
    gateway: 192.168.10.1
  20:
    name: servers
    subnet: 192.168.20.0/24
    gateway: 192.168.20.1
  30:
    name: iot
    subnet: 192.168.30.0/24
    gateway: 192.168.30.1
  40:
    name: guest
    subnet: 192.168.40.0/24
    gateway: 192.168.40.1

    이렇게 해두면 문서화도 쉽고, 방화벽(Firewall, 네트워크 접근 제어 장치) 규칙 만들 때도 편합니다.

    관리형 스위치와 라우터 VLAN 연동, 단계별로 해보겠습니다

    여기서는 특정 제조사 화면이 아니라, 대부분의 관리형 스위치와 Linux 기반 라우터에서 공통으로 이해할 수 있는 흐름으로 설명드릴게요. 모델마다 메뉴 이름은 달라도 핵심은 같습니다.

    1. 라우터 쪽에 VLAN 인터페이스 만들기

    라우터의 물리 인터페이스가 <code>eth0라고 가정해보겠습니다. 802.1Q(이더넷 VLAN 태깅 표준) 기반 서브인터페이스를 생성합니다.

    ip link add link eth0 name eth0.10 type vlan id 10
ip link add link eth0 name eth0.20 type vlan id 20
ip link add link eth0 name eth0.30 type vlan id 30
ip link add link eth0 name eth0.40 type vlan id 40

ip addr add 192.168.10.1/24 dev eth0.10
ip addr add 192.168.20.1/24 dev eth0.20
ip addr add 192.168.30.1/24 dev eth0.30
ip addr add 192.168.40.1/24 dev eth0.40

ip link set eth0 up
ip link set eth0.10 up
ip link set eth0.20 up
ip link set eth0.30 up
ip link set eth0.40 up

    이 작업은 재부팅해도 유지되도록 배포판 설정 파일이나 라우터 UI에 반영해야 하더라고요. CLI로 테스트한 뒤 영구 설정으로 옮기는 방식이 여러 번 배웠던 삽질을 줄여줍니다.

    2. DHCP 범위도 VLAN별로 분리하기

    라우터가 DHCP 서버 역할도 한다면, 네트워크별로 주소 풀을 따로 나눠서 줘야 합니다.

    dhcp:
  - interface: eth0.10
    range: 192.168.10.100-192.168.10.199
  - interface: eth0.20
    range: 192.168.20.100-192.168.20.199
  - interface: eth0.30
    range: 192.168.30.100-192.168.30.199
  - interface: eth0.40
    range: 192.168.40.100-192.168.40.199

    저는 예전에 이걸 빼먹어서, VLAN은 잘 나뉘었는데 IP가 안 붙는 바람에 한참 헤맸습니다. 핑도 안 되고, 장비는 링크 업인데 네트워크는 죽어 있고… 이런 경우 DHCP부터 보시면 됩니다.

    홈랩 VLAN 설정에서 관리형 스위치 포트 구성을 설명하는 이미지

    라우터-스위치 업링크는 트렁크, 단말 포트는 액세스 형태로 나뉘는 구성을 보여주는 예시입니다.

    3. 관리형 스위치 포트 역할 정하기

    예를 들어 포트 1번은 라우터와 연결, 포트 2번은 하이퍼바이저, 포트 3번은 NAS, 포트 4번은 IoT AP, 포트 5번은 관리용 PC라고 가정해보겠습니다.

    포트 연결 대상 설정 비고
    1 라우터 VLAN 10/20/30/40 Tagged 트렁크
    2 하이퍼바이저 VLAN 10/20 Tagged VM별 VLAN 사용
    3 NAS VLAN 20 Untagged, PVID 20 서버망 전용
    4 무선 AP VLAN 30/40 Tagged, VLAN 10 Untagged 또는 Tagged SSID 분리
    5 관리 PC VLAN 10 Untagged, PVID 10 관리망 접속

    여기서 중요한 포인트! 스위치 관리 IP를 어느 VLAN에 둘지 먼저 정하셔야 합니다. 저는 보통 관리망 VLAN 10에 둡니다. 나중에 장비 찾기가 훨씬 쉽거든요.

    4. 스위치에 VLAN 멤버십 적용하기

    제조사마다 화면은 다르지만 보통 이런 순서로 진행합니다.

    1. VLAN 10, 20, 30, 40 생성
    2. 포트 1을 각 VLAN의 Tagged 멤버로 추가
    3. 포트 3은 VLAN 20의 Untagged 멤버로 설정하고 PVID 20 지정
    4. 포트 5는 VLAN 10의 Untagged 멤버로 설정하고 PVID 10 지정
    5. AP 연결 포트는 SSID 설계에 맞춰 Tagged VLAN 추가

    혹시 메인 SSID는 직원망, 게스트 SSID는 손님망처럼 나누고 싶다면 여기서 라우터 VLAN과 무선 SSID 매핑까지 함께 설계하면 됩니다.

    5. VLAN 간 접근 정책 만들기

    VLAN을 나누는 것만으로는 부족합니다. 라우터에서 어디까지 통신을 허용할지 정해야 진짜 보안 강화가 됩니다. 저는 보통 이렇게 시작합니다.

    # 예시 개념
# guest(40) -> internet only
# iot(30) -> internet allowed, mgmt(10) blocked
# servers(20) -> mgmt(10) from admin PC only

iptables -A FORWARD -s 192.168.40.0/24 -d 192.168.10.0/24 -j DROP
iptables -A FORWARD -s 192.168.40.0/24 -d 192.168.20.0/24 -j DROP
iptables -A FORWARD -s 192.168.30.0/24 -d 192.168.10.0/24 -j DROP
iptables -A FORWARD -s 192.168.10.50 -d 192.168.20.0/24 -j ACCEPT

    물론 실제 환경에서는 기본 정책, 상태 기반(Stateful) 허용, DNS/NTP 예외도 같이 보셔야 합니다. 다만 처음에는 차단 먼저, 필요한 것만 허용 이 원칙으로 가는 게 훨씬 안전합니다.

    ⚠️ 제가 직접 겪은 트러블슈팅 포인트

    홈랩 VLAN 설정에서 많이 겪는 문제를 정리해보겠습니다. 이건 진짜 현장에서, 아니 제 방 서버실에서 삽질하면서 얻은 체크리스트입니다.

    • 인터넷은 되는데 내부 장비가 안 보임: 방화벽 규칙이 너무 강하거나, 반대로 라우팅은 됐는데 DNS가 VLAN별로 안 열려 있을 수 있습니다.
    • 아예 IP를 못 받음: DHCP가 해당 VLAN 인터페이스에 바인딩되지 않았거나, 스위치 포트 PVID가 틀렸을 가능성이 큽니다.
    • 스위치 관리 페이지 접속 불가: 스위치 관리 IP가 속한 VLAN과 접속 포트 VLAN이 안 맞는 경우가 많습니다. 이거 한 번 꼬이면 공장 초기화 유혹이 엄청 강해집니다.
    • 하이퍼바이저 VM만 통신 안 됨: 가상 스위치(vSwitch)나 브리지에서 VLAN 태깅을 따로 켜야 하는 경우가 있습니다.
    • 무선 AP의 게스트 SSID 분리가 안 됨: AP 업링크 포트가 트렁크가 아니거나, SSID별 VLAN ID 매핑이 다를 수 있습니다.

    저도 처음엔 라우터 문제인 줄 알고 라우터만 계속 봤었는데, 알고 보니 스위치 포트 하나가 Untagged로 남아 있더라고요. 이런 건 진짜 허무합니다. 그래서 저는 이제 변경할 때마다 포트별 역할을 메모해둡니다.

    빠르게 확인하는 점검 명령어

    ip -d link show
ip addr show
ip route show
ping 192.168.10.1
ping 192.168.20.1
arp -n

    ip -d link show는 VLAN 서브인터페이스가 제대로 올라왔는지 볼 때 꽤 유용합니다. 태그 ID까지 보여서 실수 잡기 좋습니다.

    홈랩 VLAN 설정 검증을 위한 라우터 VLAN 상태 점검 이미지

    라우터에서 VLAN 서브인터페이스와 접근 제어 정책을 점검하는 장면을 표현한 이미지입니다.

    검증: 네트워크 분리와 통신 결과는 어떻게 확인할까요

    구성이 끝나면 아래 순서로 검증해보시면 됩니다. 이 과정을 건너뛰면 나중에 어디가 잘못됐는지 찾기가 더 어려워집니다.

    1. 관리 PC를 VLAN 10 포트에 연결하고 스위치/라우터 관리 페이지 접속 확인
    2. 서버 장비가 VLAN 20 주소를 정상적으로 받는지 확인
    3. IoT 장비가 VLAN 30 대역에서 인터넷만 되는지 확인
    4. 게스트망 장비가 내부 NAS나 관리 페이지에 접근되지 않는지 확인
    5. 필요한 예외 통신만 허용되는지 로그로 점검

    예를 들어, 게스트망에서 아래 테스트를 해보는 식입니다.

    ping 192.168.10.1
ping 192.168.20.10
ping 8.8.8.8
nslookup example.com

    정상이라면 관리망/서버망 핑은 막히고, 외부 인터넷과 DNS는 동작해야겠죠. 이런 식으로 시나리오 기반으로 확인해보면 설정이 눈에 잘 들어옵니다. 🎉

    정리 표: 어떤 식으로 나누면 운영이 편한가요

    VLAN 용도 권장 정책 운영 팁
    10 관리망 관리자 PC만 접근 허용 장비 관리 IP 일관성 유지
    20 서버망 필요 포트만 외부/내부 허용 서비스별 방화벽 로그 확인
    30 IoT망 인터넷 허용, 내부망 최소화 제조사 클라우드 의존성 주의
    40 게스트망 인터넷 전용, 내부 접근 차단 DNS/NTP만 예외 허용 검토
    홈랩 VLAN 설정 결과와 네트워크 분리 상태를 요약한 이미지

    각 VLAN 간 허용/차단 관계와 인터넷 접근 여부를 한눈에 보여주는 요약 이미지입니다.

    자주 묻는 질문

    Q1. VLAN 하나만 써도 되는데 굳이 나눠야 하나요?

    장비가 3~4대 수준이면 당장은 괜찮을 수 있습니다. 근데 홈랩은 보통 점점 커지거든요. NAS 붙고, 미니 PC 붙고, AP 붙고, 카메라 들어오면 그때부터 한 네트워크에 다 섞여 있는 게 더 불편해집니다.

    Q2. 관리형 스위치가 꼭 필요한가요?

    홈랩 VLAN 설정을 제대로 하려면 사실상 필요합니다. 비관리형 스위치는 VLAN 태그 처리나 포트별 정책이 안 되니까, 라우터 VLAN만으로는 한계가 있습니다.

    Q3. 라우터 한 대로도 가능한가요?

    가능합니다. 라우터가 802.1Q VLAN 인터페이스와 방화벽 정책을 지원하면 됩니다. 다만 포트 수나 무선 SSID 분리까지 생각하면 관리형 스위치와 AP까지 같이 보는 편이 현실적입니다.

    마무리: 홈랩 VLAN 설정은 귀찮지만, 한 번 해두면 오래 갑니다

    처음엔 이게 뭔가 싶었는데, 막상 구성해두면 체감 차이가 큽니다. 관리망은 깔끔해지고, 서버는 좀 더 안전해지고, IoT 장비 때문에 찝찝한 마음도 줄어들거든요. 제가 직접 해보니 핵심은 딱 세 가지였습니다. VLAN 번호 규칙 통일, 스위치 포트 역할 문서화, 라우터 방화벽 정책 분리입니다.

    혹시 지금 홈랩이 점점 복잡해지고 있다면, 이번 기회에 VLAN 구성부터 정리해보셔도 좋겠습니다. 다음 글에서는 VLAN 위에 얹는 Inter-VLAN Routing(인터 VLAN 라우팅) 정책과 홈랩 방화벽 룰 설계 팁도 다뤄볼 예정입니다. 이전 글에서 다뤘던 백업 네트워크 분리 구성과도 연결되는 내용이라 같이 보시면 이해가 더 잘 되실 거예요. 💡

    구축 후 점검해야 할 체크리스트와 다음 확장 단계 아이디어를 담은 마무리 이미지입니다.

  • [HomeLabs] Unifi 컨트롤러 성능 비교: Cloud Key vs Docker vs VM

    [HomeLabs] Unifi 컨트롤러 성능 비교: Cloud Key vs Docker vs VM

    목차

    [네트워크] Unifi 컨트롤러 성능 비교: Cloud Key vs Docker vs VM

    홈랩 규모가 조금만 커져도 Unifi 컨트롤러 성능 차이가 은근히 체감됩니다. 처음에는 AP 몇 대, 스위치 한두 대라서 어디에 올려도 비슷할 줄 알기 쉬운데요. 막상 써보면 대시보드가 열리는 속도, 백업이 끝나는 시간, 기기 채택 반응, 업데이트 직후 안정화 구간이 호스팅 방식마다 제법 다르게 느껴지더라고요.

    저도 처음엔 Unifi Cloud Key면 끝이라고 생각했습니다. 그런데 Docker로 옮겨 보고, 다시 VM으로 분리해 보니 관점이 꽤 바뀌었습니다. 이번 글은 특정 수치를 과장해서 보여주기보다, 홈랩에서 실제로 어떤 항목을 기준으로 비교하면 덜 헤매는지, 그리고 어떤 운영 방식이 어떤 상황에 잘 맞는지 정리한 기록에 가깝습니다.

    Unifi 컨트롤러 성능 비교를 위한 Cloud Key, Docker, VM 아키텍처 이미지

    Cloud Key, Docker, VM에 UniFi Network Application이 배치된 구조를 한눈에 보여주는 개요 이미지입니다.

    왜 Unifi 컨트롤러 성능 비교가 중요한가

    UniFi Network Application은 단순히 웹 UI만 띄우는 도구가 아닙니다. 이벤트를 모으고, 장비 상태를 저장하고, 설정을 푸시하고, 백업도 만들고, 로그도 계속 다룹니다. 쉽게 말해 네트워크 관리의 중심점 역할을 하기 때문에 컨트롤러가 느리면 화면만 답답한 게 아니라 운영 전체 템포가 같이 느려집니다.

    특히 아래 상황에서 차이가 잘 드러납니다.

    • 장비 수가 늘어나서 대시보드 로딩이 길어질 때
    • 백업 파일을 자주 만들고 복원 테스트까지 할 때
    • 원격 접속으로 설정을 바꾸는데 UI 응답이 늦을 때
    • 업데이트 전후로 기기 재연결이 몰릴 때
    • 다른 서비스와 같은 서버 자원을 나눠 쓸 때

    여기서 중요한 포인트가 하나 있습니다. 벤치마크는 단순 CPU 점수 비교가 아닙니다. 관리형 장비와 상호작용하는 서비스라서 체감 응답성과 운영 편의성까지 같이 봐야 의미가 생기거든요.

    Unifi Cloud Key, Unifi Docker, Unifi VM 개념 정리

    이 부분은 이름은 쉬운데 경계가 헷갈리기 쉽습니다. 저도 처음엔 그랬거든요. 지금 기준으로는 아래처럼 이해하면 가장 편합니다.

    1. Cloud Key: UniFi 전용 관리 장치입니다. 현재는 CloudKey+ 같은 전용 콘솔 계열이 대표적이고, 설치가 단순하며 전력 효율이 좋은 편입니다.
    2. Docker: 기존 NAS나 리눅스 서버 위에 UniFi Network Application을 컨테이너로 올리는 방식입니다. 배포와 백업, 이관이 편해서 홈랩 유저가 많이 선택합니다.
    3. VM: Proxmox VE, ESXi 같은 하이퍼바이저 위에 별도 가상머신을 두고 운영하는 방식입니다. 격리와 스냅샷, 장애 분리 측면에서 장점이 큽니다.
    항목 Cloud Key Docker VM
    초기 설치 난이도 낮음 중간 중간~높음
    운영 유연성 낮음 높음 높음
    자원 격리 전용 장비 기준 양호 호스트 공유 강함
    백업/이관 편의성 보통 매우 좋음 좋음
    업데이트 실험 보수적으로 접근 이미지 교체로 비교적 쉬움 스냅샷 활용 쉬움
    홈랩 확장성 장비 의존 매우 좋음 좋음

    제 경험상 소규모 구성에서는 Cloud Key가 정말 편합니다. 반대로 홈서버를 이미 굴리고 있다면 Unifi Docker가 손에 익기 시작하고요. 여러 서비스와 운영 표준을 맞추고 싶다면 Unifi VM이 더 안정적으로 느껴질 때가 있습니다.

    Unifi 컨트롤러 성능 벤치마크 기준은 이렇게 잡는 게 덜 헷갈립니다

    많이 하는 실수가 있습니다. 로그인 화면 열리는 시간만 보고 결론 내리는 거예요. 그런데 실제 운영에서는 그걸로 부족합니다. 제가 직접 돌려보니 아래 다섯 가지는 꼭 봐야 비교가 되더라고요.

    1. 초기 기동 시간: 서비스 재시작 후 웹 UI가 실제로 접속 가능한 시점
    2. 대시보드 응답성: 로그인 후 주요 화면 전환 체감
    3. 백업 생성 시간: 설정 백업이 완료되기까지 걸리는 흐름
    4. 복원 후 안정화: 백업 복원 후 장비가 정상 표시되기까지 걸리는 시간
    5. 자원 점유 추이: CPU, 메모리, 디스크 I/O가 몰리는 구간 확인

    여기서는 숫자를 억지로 만들 필요가 없습니다. 오히려 같은 장비 수, 같은 설정, 같은 시간대, 같은 네트워크 조건에서 반복 가능한 비교 절차를 만드는 게 더 중요합니다. 결국 benchmark도 운영에 도움이 되어야 의미가 있으니까요.

    테스트 조건을 맞출 때 체크할 것

    • 동일한 사이트 설정과 비슷한 수의 장비를 사용합니다.
    • 자동 백업 주기나 DPI(Deep Packet Inspection, 심층 패킷 분석) 같은 부가 기능은 동일하게 맞춥니다.
    • 호스트에 다른 작업이 몰리는 시간은 피합니다.
    • 가능하면 같은 브라우저, 같은 클라이언트에서 접근합니다.
    • 한 번만 보지 말고 최소 여러 차례 반복합니다.
    Unifi 컨트롤러 성능 벤치마크 측정 흐름 다이어그램

    기동 시간, 로그인 응답, 백업 생성, 복원 안정화, 리소스 모니터링 순서를 정리한 벤치마크 흐름 이미지입니다.

    실전 구현: Docker와 VM에서 비교 환경 만들기

    Cloud Key는 전용 장비라 설치 과정 자체가 단순한 편입니다. 그래서 실전 비교는 Docker와 VM 쪽에서 재현 가능한 구조를 만들어두는 게 좋습니다. 저는 보통 동일한 백업 파일을 기준으로 각 환경을 맞춘 뒤, 그다음에 응답성과 운영 편의성을 비교합니다.

    1. Docker 환경 준비

    아래 예시는 Docker Compose 기준입니다. 최근 많이 쓰는 LinuxServer 이미지 방식에 맞춰 외부 MongoDB를 따로 두는 형태로 잡았습니다. 여기서는 개념 전달이 목적이라 최소 예시만 넣었고, 실제 운영에서는 DB 이미지 태그를 꼭 고정해 두는 편이 안전하더라고요.

    services:
  unifi:
    image: lscr.io/linuxserver/unifi-network-application:latest
    container_name: unifi-controller
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Seoul
      - MONGO_USER=unifi
      - MONGO_PASS=unifi-pass
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    ports:
      - "8443:8443"
      - "3478:3478/udp"
      - "10001:10001/udp"
      - "8080:8080"
    volumes:
      - ./unifi-config:/config
    depends_on:
      - unifi-db

  unifi-db:
    image: mongo:4.4
    container_name: unifi-db
    restart: unless-stopped
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=change-me
    command: ["--wiredTigerCacheSizeGB", "1"]
    volumes:
      - ./unifi-db:/data/db
      - ./init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro

    이 예시에서 중요한 건 두 가지입니다. 첫째, `mongo:latest`처럼 메이저 버전이 자동으로 바뀌는 태그는 피하는 게 좋습니다. 둘째, 최신 UniFi Network Application 계열은 외부 MongoDB 구성과 인증 설정이 맞지 않으면 처음부터 이상하게 느려지거나 아예 기동이 꼬일 수 있어서, 성능 비교 전에 구성 일치부터 잡아야 합니다.

    실제로 써보면 Docker 방식은 이관성과 반복 실험이 정말 좋습니다. 이미지 버전 비교, 구성 백업, 롤백이 빠르거든요. 홈랩에서는 이거 하나만으로도 체감 만족도가 꽤 큽니다.

    2. VM 환경 준비

    VM은 운영체제 레벨에서 분리되기 때문에 다른 서비스와 간섭을 줄이기 좋습니다. 저는 Proxmox VE 위에 Ubuntu Server 계열 VM을 올려서 비교했는데, 중요한 건 배포판 이름보다도 CPU, 메모리, 디스크 할당 정책이었습니다. 특히 스토리지가 느리면 VM이든 Docker든 생각보다 금방 답답해집니다.

    홈랩에서는 VM 안에 다시 Docker로 UniFi를 올리는 방식도 많이 씁니다. 엄밀히 말하면 VM과 Docker를 동시에 쓰는 구조죠. 그런데 운영 표준화 측면에서는 꽤 합리적입니다. 스냅샷도 되고, 컨테이너 이관도 되니까요.

    sudo apt update
sudo apt install -y curl ca-certificates gnupg
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

    위 명령은 VM 안에 Docker 실행 환경을 올리는 예시입니다. 즉, 이 단계 자체가 UniFi 설치 명령은 아니고, 비교 실험을 동일한 방식으로 재현하기 위한 기반 준비라고 보시면 됩니다.

    3. 측정 스크립트 예시

    응답 확인은 너무 복잡하게 갈 필요가 없습니다. 로그인 화면이 열리는지, HTTPS 관리 포트가 실제로 응답하는지부터 잡아도 큰 도움이 됩니다. 아래 스크립트는 재시작 직후 어느 쪽이 더 빨리 안정화되는지 감을 잡을 때 꽤 유용했습니다.

    #!/usr/bin/env bash
TARGET="https://unifi.example.local:8443"
for i in $(seq 1 30); do
  printf "[%02d] " "$i"
  curl -k -s -o /dev/null -w "code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" "$TARGET"
  sleep 2
done

    여기에 `docker stats`, `top`, `iostat` 같은 툴을 같이 보면 병목 구간이 더 잘 보입니다. 숫자가 예쁘게 나온다고 끝이 아니라, 어느 순간에 CPU가 튀고 디스크가 밀리는지 같이 봐야 해석이 훨씬 정확해지더라고요.

    Unifi Docker와 Unifi VM 설정 비교 이미지

    컨테이너 구성 파일과 VM의 CPU, 메모리, 디스크 할당 개념을 함께 설명하는 설정 이미지입니다.

    주의사항과 트러블슈팅: 여기서 많이 헷갈립니다

    이 부분은 정말 중요합니다. 저도 성능 차이인 줄 알았는데 알고 보니 설정 문제였던 적이 여러 번 있었거든요. 분명 같은 데이터인데 한쪽만 유독 느리다면, 생각보다 아래 항목에서 걸리는 경우가 많습니다.

    포트와 네트워크 경로 문제

    • 8080/TCP: 장비와 애플리케이션 간 통신에 쓰입니다. 막혀 있으면 Adoption이나 재연결 흐름이 꼬일 수 있습니다.
    • 8443/TCP: 관리 GUI/API 접근에 자주 쓰는 포트입니다. 리버스 프록시를 붙일 때 인증서나 HTTPS 처리 구성이 꼬이면 UI가 불안정해질 수 있습니다.
    • 3478/UDP: STUN 기반 통신에 사용됩니다. 장비 채택과 연결 상태 확인 때 자주 체크하게 되는 포트입니다.

    처음엔 컨트롤러가 느린 줄 알았는데, 실제로는 L2 브로드캐스트가 제대로 안 닿아서 장비 발견이 지연된 적도 있었습니다. 이건 성능 문제가 아니라 연결 경로 문제죠. 그래서 Unifi 컨트롤러 성능을 보기 전에 통신 경로부터 먼저 정상화하는 게 맞습니다.

    디스크 성능이 발목 잡는 경우

    Cloud Key든 Docker든 VM이든 결국 로그와 데이터베이스 쓰기가 발생합니다. 저장소가 느리면 UI도 같이 답답해집니다. 특히 저전력 장비나 공유 스토리지를 쓸 때 체감 차이가 커요. CPU보다 디스크 I/O가 먼저 병목이 되는 경우도 생각보다 많더라고요.

    백업 복원 후 장비 상태가 바로 안 맞는 경우

    복원은 됐는데 장비가 오프라인처럼 보이거나 사이트 정보가 바로 반영되지 않는 경우가 있습니다. 이럴 땐 성능 탓부터 하지 말고 아래 순서로 보는 게 훨씬 빠릅니다.

    1. 장비가 새 컨트롤러 IP 또는 호스트명을 제대로 인식했는지 확인합니다.
    2. DNS(Domain Name System, 도메인 이름 해석)와 게이트웨이 경로를 점검합니다.
    3. 인증서 경고나 브라우저 캐시 문제를 제거합니다.
    4. 컨트롤러 재기동 후 로그를 다시 확인합니다.

    보통 비교 대상의 상태를 최대한 동일하게 맞추는 작업을 끝내고 나서야 진짜 성능 차이가 보입니다. 이 순서를 건너뛰면 숫자는 그럴듯해도 결론이 자꾸 흔들리더라고요.

    Unifi 컨트롤러 성능 결과 해석: 숫자보다 운영 감각이 더 중요합니다

    이제 결과를 어떻게 읽을지 정리해보겠습니다. 이 글에서는 특정 모델별 점수를 임의로 적지는 않겠습니다. 대신 홈랩에서 반복적으로 느끼는 경향을 기준으로 정리하면 아래 표에 가깝습니다.

    비교 포인트 Cloud Key 경향 Docker 경향 VM 경향
    설치 직후 진입 장벽 가장 낮음 낮음 중간
    호스트 자원 공유 영향 낮음 있음 관리 가능
    백업/이관 실험 제한적 매우 편함 편함
    문제 분리 난이도 단순 호스트 영향 고려 필요 OS 단위로 분리 쉬움
    장기 운영 유연성 보통 높음 높음

    제가 직접 굴려보니 결론은 꽤 명확했습니다.

    • 간단하고 안정적인 전용 운영이 목표면 Cloud Key가 편합니다.
    • 홈서버, NAS, 자동화, 백업까지 묶어서 운영할 생각이면 Docker가 실용적입니다.
    • 격리, 표준화, 스냅샷, 복구 훈련까지 챙기려면 VM이 운영자 친화적으로 느껴질 가능성이 큽니다.

    즉, Unifi 컨트롤러 성능은 단순 처리속도만이 아니라 운영 방식과 함께 봐야 합니다. 같은 웹 응답이라도 장애 대응 시간, 이관 편의성, 실험 가능성까지 포함하면 체감 순위가 달라지거든요.

    Unifi 컨트롤러 성능 결과를 보여주는 대시보드 이미지

    기동 시간, 응답 지표, CPU/메모리 추이를 그래프 형태로 보여주는 결과 요약 이미지입니다.

    Unifi 컨트롤러 성능 기준으로 어떤 환경을 고르면 좋을까

    정답은 하나가 아닙니다. 여기서 중요한 기준은 장비 수만이 아니라 현재 운영 습관입니다. 저도 돌이켜보면 장비 숫자보다 백업 습관, 장애 대응 방식, 업데이트 빈도가 선택에 더 큰 영향을 줬습니다.

    1. 처음 시작하는 경우: 전용 장비 기반의 Cloud Key가 가장 부담이 적습니다.
    2. 이미 Docker를 잘 쓰는 경우: Unifi Docker 구성이 가장 가성비 좋게 느껴질 가능성이 큽니다.
    3. 여러 서비스와 분리 운영이 필요한 경우: Unifi VM이 추후 확장과 장애 분리에 유리합니다.
    4. 백업과 복원 훈련을 자주 하는 경우: Docker 또는 VM이 훨씬 편합니다.

    지금 제 기준으로 홈랩이라면 Docker를 먼저 추천하고, 조금 더 엄격하게 운영할 때는 VM으로 분리할 것 같습니다. Cloud Key도 여전히 좋은 선택지지만, 실험을 자주 하는 사람에게는 유연성이 살짝 아쉽더라고요.

    정리와 다음 단계

    이번 글의 핵심은 간단합니다. Unifi 컨트롤러 성능을 비교할 때는 Cloud Key, Docker, VM을 단순 빠르기 경쟁으로 보지 말고 운영 편의성과 복구 가능성까지 같이 보자는 겁니다. 실제로 써보면 Docker는 반복 실험이 편하고, VM은 격리가 좋고, Cloud Key는 셋업이 단순해서 각자 강점이 분명합니다.

    혹시 지금 컨트롤러가 느리다고 느끼신다면 바로 마이그레이션부터 하지 마세요. 먼저 기동 시간, 백업 속도, 포트 상태, 디스크 I/O를 체크해보는 게 훨씬 낫습니다. 생각보다 원인은 호스팅 방식보다 주변 설정에 있는 경우가 많습니다. 저도 처음엔 성능 문제인 줄 알고 꽤 헤맸거든요.

    다음 글에서는 Unifi Docker를 실제 운영 환경에 올릴 때 볼륨 백업, 리버스 프록시, 업데이트 전략을 더 깊게 다뤄볼 예정입니다. 이전 글에서 다룬 홈랩 스토리지 구성과 함께 보면 흐름이 더 잘 잡힐 거예요. 백업 전략 관련 글도 같이 보면 마이그레이션 실수 줄이는 데 도움이 됩니다.

    Unifi Cloud Key, Docker, VM 선택 기준 요약 이미지

    용도별 추천 시나리오와 장단점을 한 장으로 정리한 비교 요약 이미지입니다.

    자주 묻는 질문

    Q1. 소규모 네트워크에서도 VM이 필요할까요?

    반드시 그렇지는 않습니다. 소규모라면 Cloud Key나 Docker로도 충분한 경우가 많습니다. 다만 다른 서비스와 충돌을 줄이고 싶다면 VM이 더 편하게 느껴질 수 있습니다.

    Q2. Docker가 항상 더 빠른가요?

    항상 그렇지는 않습니다. 호스트 자원 경쟁, 스토리지, 네트워크 구성에 따라 체감은 달라집니다. 그래서 benchmark는 환경 통제가 핵심입니다.

    Q3. 마이그레이션 전에 가장 먼저 뭘 해야 하나요?

    백업 검증입니다. 백업 파일이 만들어지는 것과 실제로 복원해서 정상 동작하는 것은 다른 문제거든요.

  • [HomeLabs] PoE 스위치 체크리스트: 홈랩 전원·호환성·케이블링 점검

    [HomeLabs] PoE 스위치 체크리스트: 홈랩 전원·호환성·케이블링 점검

    목차

    PoE 스위치 체크리스트: 홈랩 전원·호환성·케이블링 점검

    홈랩을 꾸리다 보면 어느 순간 PoE 스위치 체크리스트가 꼭 필요해지는 때가 옵니다. AP(Access Point, 무선 접속 장치), IP 카메라, VoIP 전화기, 소형 SBC(Single Board Computer, 단일보드 컴퓨터) 같은 장치가 하나둘 늘어나면 어댑터도 같이 늘어나거든요. 저도 처음에는 포트 수만 보고 스위치를 골랐다가 전력 예산이 모자라 장치가 들쭉날쭉 꺼진 적이 있었습니다. 그때 확실히 느꼈어요. PoE 스위치 선택은 포트 개수보다 전원, 장치 호환성, 그리고 네트워크 케이블링을 먼저 봐야 합니다.

    이번 글에서는 제가 홈랩에서 실제로 점검하는 기준을 바탕으로, 도입 전에 꼭 확인해야 할 항목을 정리해보겠습니다. 숫자만 외우는 방식보다 왜 체크해야 하는지까지 같이 보면 훨씬 오래 남더라고요. 스위치는 샀는데 장치가 안 켜지거나, 링크는 잡히는데 속도가 애매하게 떨어졌던 경험이 있다면 특히 도움이 될 겁니다.

    PoE 스위치 체크리스트를 설명하는 홈랩 전체 구성도

    PoE 스위치에서 AP, 카메라, NAS 관리망, 업링크가 어떻게 연결되는지 한눈에 보여주는 전체 구성 예시입니다.

    1. PoE 스위치 체크리스트의 출발점: PoE 규격 이해

    PoE(Power over Ethernet, 이더넷 전원 공급)는 랜 케이블 한 가닥으로 데이터와 전원을 함께 보내는 방식입니다. 배선이 깔끔해지고, 천장 AP나 벽면 카메라처럼 전원 콘센트가 애매한 위치에 장치를 둘 때 특히 편합니다. 다만 여기서 중요한 점이 하나 있습니다. 모든 PoE가 같은 방식으로 동작하는 건 아닙니다.

    • IEEE 802.3af: 일반적으로 PoE라고 부르는 기본 규격입니다.
    • IEEE 802.3at: 보통 PoE+라고 부르며, 802.3af보다 더 높은 전력을 요구하는 장치에 쓰입니다.
    • IEEE 802.3bt: 그보다 더 높은 전력을 제공하는 확장 규격으로, 장치와 스위치가 모두 지원해야 의미가 있습니다.

    많이 헷갈리는 부분이 바로 여기입니다. 스위치에 PoE라고 적혀 있다고 해서 아무 장치나 바로 연결되는 건 아닙니다. 실제로는 PoE 전원 공급 방식과 장치가 요구하는 규격이 맞아야 합니다. 반대로 일부 장치는 패시브 PoE(Passive PoE, 비표준 고정 전압 방식)를 쓰기도 해서 더 조심해야 하고요. 표준 기반인지, 비표준 방식인지 확인하지 않으면 전원이 아예 들어오지 않거나 장치 쪽 보호 회로 이슈가 생길 수 있습니다.

    2. PoE 스위치 체크리스트의 핵심은 전력 예산입니다

    제가 홈랩 장비를 늘릴 때 제일 먼저 보는 건 포트 수가 아니라 총 전력 예산(Power Budget, 전체 공급 가능 전력)입니다. 8포트 PoE 스위치라고 해서 8개 포트가 동시에 충분한 전력을 낼 수 있다는 뜻은 아니거든요. 이 부분이 생각보다 자주 헷갈립니다.

    전력 예산을 보는 방법

    1. 연결할 장치 목록을 먼저 적습니다.
    2. 각 장치가 요구하는 PoE 규격과 최대 소비 전력을 확인합니다.
    3. 동시 사용 기준으로 합산합니다.
    4. 확장과 순간 부하를 고려해 여유 전력을 남깁니다.

    실제로 써보면 홈랩은 처음 계획보다 장치가 늘어날 가능성이 높습니다. 오늘은 AP 2대만 연결해도 몇 달 뒤에는 카메라나 추가 노드가 붙는 경우가 많더라고요. 그래서 현재 사용량에만 딱 맞춰 사면 금방 답답해집니다. 저는 대체로 계산값보다 20~30% 정도 여유를 두는 편입니다.

    점검 항목 왜 중요한가 제가 보는 기준
    총 PoE 예산 여러 장치 동시 구동 가능 여부 현재 합계보다 20~30% 여유 확보
    포트당 최대 전력 고전력 장치 지원 여부 AP, 카메라, 미니 장치 요구치 확인
    업링크 속도 장치가 늘면 병목 발생 기가비트 이상, 필요 시 멀티기가 확인
    팬 소음 홈랩 환경 체감 품질 서재·거실 설치면 특히 중요
    관리 기능 VLAN, LLDP, 포트 상태 확인 문제 추적이 훨씬 쉬워짐

    PoE 스위치 체크리스트를 문서로 적어두면 실수가 크게 줄어듭니다. 머리로만 계산하면 꼭 하나 빠지더라고요.

    3. 장치 호환성은 규격 이름만 보지 마세요

    PoE 스위치 선택에서 두 번째로 중요한 건 장치 호환성입니다. 여기서는 세 가지를 같이 봐야 합니다.

    • PoE 표준 일치 여부: 802.3af, 802.3at, 802.3bt 중 무엇을 요구하는지
    • 전원 입력 방식: 표준 PoE인지, 어댑터 전용인지, 패시브 PoE인지
    • 데이터 링크 속도: 100Mbps면 충분한지, 1Gbps 이상이 필요한지

    저도 처음엔 전압만 맞으면 되는 줄 알았는데, 실제로는 포트당 공급 가능한 전력이 부족해서 장치가 반복 부팅되는 경우가 있었습니다. 또 어떤 장치는 전원은 들어오는데 협상(auto-negotiation)이 깔끔하지 않아 링크가 100Mbps로만 잡히기도 했고요. 결국 홈랩 구축에서는 스위치 사양표와 장치 사양표를 나란히 놓고 보는 습관이 제일 중요합니다.

    호환성 점검용 간단 표

    장치 유형 확인할 것 놓치기 쉬운 부분
    무선 AP PoE 규격, 포트 속도 무선 성능보다 유선 업링크 병목
    IP 카메라 PoE 지원 여부, 실외 배선 거리와 케이블 품질 영향
    소형 SBC PoE HAT 또는 스플리터 필요 여부 부팅 시 순간 전력
    VoIP 장치 표준 PoE 지원 여부 VLAN 필요성

    4. 네트워크 케이블링은 생각보다 더 중요합니다

    네트워크 케이블링은 그냥 연결만 되면 끝이라고 보기 쉽지만, PoE 환경에서는 더 민감합니다. 오래된 케이블, 직접 압착한 커넥터, 중간에 품질이 불안한 패치 패널이 있으면 문제 추적이 꽤 까다로워집니다. 링크는 살아 있는데 장치가 재부팅되거나 속도가 낮게 잡히는 식으로 애매하게 증상이 나오거든요. 이런 문제가 제일 피곤합니다.

    제가 홈랩에서 기본으로 체크하는 건 아래 정도입니다.

    • Cat5e 이상 케이블 사용 여부
    • 케이블 길이가 과도하게 길지 않은지
    • 피복 손상, 접점 불량, 재압착 흔적 확인
    • 패치 패널이나 키스톤 잭을 포함한 전체 경로 점검
    • 전원선과 과도하게 밀착 배선하지 않았는지 확인

    체감상 가장 빠른 진단 방법은 의외로 단순합니다. 스위치를 의심하기 전에 검증된 짧은 케이블로 먼저 교차 테스트해보는 거예요. 저도 이상 증상이 나오면 제일 먼저 케이블부터 바꿔봅니다. 이게 진짜 시간을 많이 아껴주더라고요.

    PoE 스위치 체크리스트 중 네트워크 케이블링 점검 장면

    패치 패널, 랜 케이블, 천장 AP 라인을 점검하면서 문제 구간을 분리하는 모습을 표현한 이미지입니다.

    5. 실전에서 제가 쓰는 PoE 스위치 체크리스트

    이제부터는 제가 실제로 신규 장비를 붙일 때 점검하는 순서입니다. 복잡해 보여도 한 번 체크리스트로 만들어두면 다음부터는 훨씬 편합니다.

    1단계. 장치 인벤토리 작성

    devices:
  - name: living-room-ap
    type: access-point
    poe_standard: "802.3at"
    uplink_speed: "1G"
    note: "천장 설치 예정"
  - name: entry-camera
    type: ip-camera
    poe_standard: "802.3af"
    uplink_speed: "100M or 1G 확인"
    note: "실외 배선 구간 점검 필요"
  - name: lab-sbc
    type: sbc
    poe_standard: "PoE splitter or HAT 확인"
    uplink_speed: "1G"
    note: "부팅 안정성 확인"

    문서화가 사소해 보여도 나중에 장치 추가할 때 큰 도움이 됩니다. 처음엔 귀찮은데, 결국 시간을 아껴주는 쪽은 이 방법이더라고요.

    2단계. 링크 상태와 속도 확인

    ip link show
ethtool eth0

    ethtool은 Linux 환경에서 링크 속도, 듀플렉스, 자동 협상 상태를 확인할 때 유용합니다. 스위치에서 1Gbps로 될 줄 알았는데 실제 서버 NIC(Network Interface Card, 네트워크 인터페이스 카드)는 100Mbps로 잡히는 경우가 종종 있습니다. 인터페이스 이름은 환경마다 eth0가 아니라 enp1s0처럼 다를 수 있다는 점도 같이 확인해두세요.

    3단계. LLDP로 연결 정보 점검

    sudo lldpcli show neighbors

    관리형 스위치와 지원 장치 조합이라면 LLDP(Link Layer Discovery Protocol, 링크 계층 장치 탐색 프로토콜)가 꽤 유용합니다. 어느 포트에 무엇이 연결됐는지 추적하기 쉬워지거든요. 다만 이 명령은 보통 lldpd 같은 LLDP 데몬이 설치되고 실행 중이어야 동작합니다. 처음엔 없어도 되겠지 싶었는데, 장치가 5대만 넘어가도 체감 차이가 꽤 큽니다.

    4단계. 실제 통신 테스트

    ping -c 4 192.168.1.10
iperf3 -c 192.168.1.20

    장치에 전원이 들어왔다고 끝은 아닙니다. 데이터 경로가 안정적인지도 같이 봐야 합니다. 특히 AP나 카메라는 전원만 들어오고 네트워크 품질은 애매한 상태가 남는 경우가 있습니다. 참고로 iperf3는 상대편 장치나 서버에서 미리 iperf3 -s로 대기 중이어야 제대로 측정됩니다.

    PoE 스위치 선택 시 확인하는 포트 상태와 장치 호환성 점검 이미지

    포트 업 상태, 속도, 연결 장치 식별 정보를 함께 확인하는 관리형 스위치 점검 화면을 표현한 이미지입니다.

    6. 실전에서 자주 겪는 문제와 해결법

    이 섹션은 문서보다 현장에서 더 자주 만나는 문제를 정리한 부분입니다. 홈랩에서는 사양표보다 증상이 먼저 보일 때가 많거든요.

    문제 1. 장치는 켜지는데 자꾸 재부팅됩니다

    전력 부족이거나 케이블 품질 문제일 가능성이 큽니다. 저는 우선 다른 포트로 바꿔보고, 짧고 검증된 케이블로 교체합니다. 그다음 장치 스펙과 포트당 공급 가능 전력을 다시 대조합니다.

    문제 2. 링크는 잡히는데 속도가 낮습니다

    자동 협상 문제나 배선 품질 이슈일 수 있습니다. 특히 직접 만든 케이블이면 더 의심해볼 만합니다. 생각보다 케이블 교체만으로 해결되는 경우가 많았습니다.

    문제 3. 어떤 장치는 PoE가 아예 안 들어옵니다

    표준 PoE가 아니라 패시브 PoE 기반 장치일 수 있습니다. 이때는 무리해서 연결하지 말고 장치 문서를 다시 확인하는 게 우선입니다. 표준 장비와 비표준 전원 방식을 섞는 건 리스크가 큽니다.

    문제 4. 스위치는 조용할 줄 알았는데 생각보다 시끄럽습니다

    홈랩은 서버실이 아니라 생활 공간에 있는 경우가 많습니다. 그래서 팬 소음과 발열도 꼭 체크해야 합니다. 성능만 보고 들여왔다가 책상 옆에서 상시 팬 소음을 듣게 되면 꽤 괴롭더라고요.

    • 전력 예산 부족: 장치 수가 늘수록 흔합니다.
    • 비표준 PoE 혼용: 사전 문서 확인이 필수입니다.
    • 불량 케이블: 증상이 애매하게 나타나서 더 까다롭습니다.
    • 관리 기능 부재: 원인 추적 시간이 길어집니다.

    7. 검증은 전원과 데이터 둘 다 봐야 끝입니다

    최종 검증 단계에서는 단순히 전원이 들어오는지만 보지 말고, PoE 전원 공급과 데이터 통신이 동시에 안정적인지 확인해야 합니다. 저는 보통 아래 순서로 점검합니다.

    1. 스위치 포트 상태 LED 또는 관리 화면 확인
    2. 장치 부팅 완료 여부 확인
    3. 링크 속도 확인
    4. 핑과 실제 서비스 응답 확인
    5. 부하가 걸릴 때도 안정적인지 재확인

    설치 직후엔 멀쩡해 보여도 몇 시간 뒤 문제가 드러나는 경우가 있습니다. 그래서 가능하면 하루 정도는 로그와 상태를 지켜보는 편입니다. 바로 정리했다가 다음 날 카메라가 오프라인으로 떠 있으면 허탈하거든요.

    PoE 전원 공급이 안정적으로 동작하는 홈랩 구축 결과 이미지

    모든 장치가 온라인 상태로 표시되고 링크 상태가 안정적인 홈랩 모니터링 결과를 보여주는 이미지입니다.

    8. 정리: PoE 스위치 체크리스트에서 꼭 볼 것

    PoE 스위치 체크리스트를 한 줄로 줄이면 이겁니다. 포트 수보다 전력 예산, 스펙표보다 실제 장치 호환성, 그리고 마지막은 케이블링입니다. 저도 여러 번 시행착오를 겪고 나서야 이 순서가 몸에 붙었습니다. 처음엔 스위치만 바꾸면 해결될 줄 알았는데, 실제로는 케이블 하나가 원인이었던 적도 있었고요.

    정리하면 아래 네 가지를 먼저 보시면 됩니다.

    1. 총 전력 예산이 충분한가
    2. 장치 호환성이 표준 기준으로 맞는가
    3. 네트워크 케이블링 품질이 받쳐주는가
    4. 관리 기능과 소음 같은 운영 요소가 괜찮은가

    이 체크만 해도 불필요한 재구매를 많이 줄일 수 있습니다. 다음 글에서는 관리형 스위치에서 VLAN(Virtual LAN, 가상 LAN)과 AP를 묶어 홈랩 네트워크를 분리하는 방법도 다뤄볼 예정입니다. 이전 글에서 다룬 랙 정리나 UPS(Uninterruptible Power Supply, 무정전 전원 장치) 구성 글과 함께 보면 흐름이 더 잘 잡힙니다.

    전력 예산, 규격 호환성, 케이블링, 검증 절차를 한 장으로 정리한 요약형 이미지입니다.

    9. 자주 묻는 질문

    Q1. 홈랩이면 무조건 관리형 스위치가 좋을까요?

    반드시 그런 건 아닙니다. 다만 장치가 늘어나고 문제 추적이 필요해지면 관리형 스위치가 훨씬 편합니다. VLAN, LLDP, 포트 상태 확인 기능이 운영 난도를 꽤 낮춰주거든요.

    Q2. PoE 인젝터(PoE Injector, 개별 전원 주입 장치)로 대체해도 될까요?

    소수 장치라면 가능합니다. 다만 장치 수가 늘어나면 배선과 어댑터 관리가 다시 복잡해집니다. 일정 규모 이상이면 스위치로 정리하는 편이 더 깔끔합니다.

    Q3. 케이블이 오래돼도 일단 링크만 잡히면 괜찮은가요?

    그렇지 않은 경우가 많습니다. 특히 PoE는 전원과 데이터가 함께 지나가서 애매한 불량이 숨어 있을 수 있습니다. 문제 생기면 가장 먼저 교체 테스트를 해보세요.

  • [HomeLabs] MikroTik 홈랩: VLAN과 방화벽 설정 사례

    [HomeLabs] MikroTik 홈랩: VLAN과 방화벽 설정 사례

    목차

    MikroTik 홈랩: VLAN과 방화벽 설정 사례

    MikroTik 홈랩을 조금만 키워도 결국 부딪히는 지점이 있습니다. 처음에는 공유기 하나에 스위치 하나만 붙여도 잘 돌아가지만, 장비와 서비스가 늘어나면 “이 장비를 같은 네트워크에 둬도 되나?”라는 고민이 꼭 생기거든요. 저도 관리용 장비, 서버, IoT, 일반 사용자 PC를 한 네트워크에 몰아넣고 쓰다가 브로드캐스트 트래픽이 늘고, 방화벽 규칙은 꼬이고, 문제 생기면 원인 찾기가 꽤 힘들었습니다. 그래서 MikroTik 홈랩 구조를 다시 짜면서 VLAN 설정과 방화벽 규칙을 정리했는데, 이거 진짜 관리가 훨씬 편해지더라고요.

    이번 글은 이론만 훑는 글이 아니라, 제가 실제로 MikroTik 라우터 기준으로 홈랩 네트워크를 분리하고 보안을 다듬었던 흐름을 정리한 사례입니다. 특히 MikroTik 라우터를 이미 쓰고 있거나, 홈 네트워크 보안을 한 단계 올리고 싶은 분이라면 바로 적용 포인트를 잡는 데 도움이 될 겁니다. 예시는 RouterOS 7 계열 기준으로 봐 주세요.

    MikroTik 홈랩 전체 네트워크 아키텍처 다이어그램

    관리망, 서버망, IoT망, 사용자망으로 분리된 MikroTik 홈랩 전체 구조 예시입니다.

    MikroTik 홈랩에서 VLAN이 왜 중요한가

    쉽게 말해 VLAN(Virtual LAN, 가상 랜)은 물리적으로는 같은 스위치와 케이블을 쓰지만 논리적으로는 다른 네트워크처럼 분리하는 방식입니다. 예를 들어 NAS, Proxmox, 관리용 노트북은 신뢰도가 높은 관리망에 두고, 스마트 플러그나 카메라 같은 IoT 장비는 별도 망으로 빼는 식이죠.

    처음엔 좀 번거로워 보여도, 실제로 나눠 놓으면 장점이 꽤 분명합니다.

    • 보안: IoT 장비에 문제가 생겨도 서버망으로 바로 넘어오기 어렵습니다.
    • 운영 편의성: 장비 성격별로 IP 대역이 나뉘니 장애 범위를 빨리 좁힐 수 있습니다.
    • 정책 적용: VLAN별로 방화벽 규칙, DHCP, DNS 정책을 다르게 줄 수 있습니다.
    • 확장성: 나중에 가상화 서버나 무선 AP를 추가해도 구조가 덜 흔들립니다.

    특히 MikroTik 홈랩에서는 RouterOS가 브리지와 VLAN 필터링을 잘 지원해서, 장비 수가 조금만 늘어나도 체감 차이가 큽니다.

    MikroTik 홈랩 네트워크 구성 사례

    이번 사례는 데이터센터급으로 복잡한 구조는 아니고, 집에서 충분히 따라 할 수 있는 수준입니다. 저는 관리 편의성과 보안 사이에서 균형을 맞추는 방향으로 잡았습니다.

    VLAN 용도 예시 대역 접근 정책
    10 관리망 192.168.10.0/24 라우터 관리, 스위치/AP 관리 허용
    20 서버망 192.168.20.0/24 내부 서비스 운영, 필요한 포트만 허용
    30 IoT망 192.168.30.0/24 인터넷 허용, 내부망 접근 제한
    40 사용자망 192.168.40.0/24 일반 PC/모바일, 서버 일부 접근 허용

    포트 역할은 이렇게 잡았습니다.

    • ether1: WAN(Uplink, 외부 회선 연결)
    • ether2: 관리용 Access 포트
    • ether3: 서버용 Access 포트
    • ether4: IoT용 Access 포트
    • ether5: 무선 AP 또는 관리형 스위치로 가는 Trunk(여러 VLAN 태그를 동시에 전달하는 포트)

    여기서 중요한 포인트는 처음부터 모든 포트를 트렁크로 만들지 않는 것입니다. 홈랩에서는 필요한 포트만 트렁크로 두고, 나머지는 명확하게 Access 포트로 두는 편이 훨씬 덜 헷갈립니다.

    MikroTik 홈랩 VLAN 포트 매핑과 트렁크 구성 이미지

    각 이더넷 포트가 어떤 VLAN에 연결되는지 보여주는 포트 매핑 예시입니다.

    MikroTik 홈랩 VLAN 설정 전에 먼저 정리할 개념

    VLAN 설정에서 많이 헷갈리는 게 Tagged와 Untagged입니다. 저도 여기서 한참 헤맸습니다.

    • Tagged: VLAN 번호 태그를 붙여서 전달합니다. 스위치 간 연결이나 AP 업링크에 주로 씁니다.
    • Untagged: 일반 장비가 그대로 연결되어도 되도록 태그 없이 보냅니다. PC나 프린터 같은 단말 포트에 씁니다.
    • PVID: 포트로 들어오는 언태그드 트래픽을 어느 VLAN에 넣을지 정하는 기본 VLAN ID입니다.

    쉽게 말해, 트렁크 포트는 여러 VLAN 트래픽을 라벨 붙여서 보내는 길이고, 액세스 포트는 한 종류만 받는 문이라고 생각하면 이해가 빠릅니다.

    MikroTik 라우터에서 VLAN 설정하기

    이제 실전입니다. 아래 예시는 RouterOS CLI 기준입니다. 인터페이스 이름과 포트 구성은 장비마다 다를 수 있으니 그대로 붙여 넣기 전에 꼭 확인하세요. 특히 VLAN 필터링은 제일 마지막에 켜는 편이 안전합니다.

    1. 브리지를 만들고, 처음에는 VLAN 필터링을 끈 상태로 구성합니다.
    2. 각 포트를 브리지에 넣고 PVID를 지정합니다.
    3. 브리지 위에 VLAN 인터페이스를 만들고 IP를 할당합니다.
    4. 브리지 VLAN 테이블을 작성합니다.
    5. 마지막에 VLAN 필터링을 켭니다.
    /interface bridge
add name=br-lan vlan-filtering=no comment="HomeLab bridge"

/interface bridge port
add bridge=br-lan interface=ether2 pvid=10 comment="Mgmt access"
add bridge=br-lan interface=ether3 pvid=20 comment="Server access"
add bridge=br-lan interface=ether4 pvid=30 comment="IoT access"
add bridge=br-lan interface=ether5 comment="Trunk to AP or managed switch"

/interface vlan
add interface=br-lan name=vlan10-mgmt vlan-id=10
add interface=br-lan name=vlan20-server vlan-id=20
add interface=br-lan name=vlan30-iot vlan-id=30
add interface=br-lan name=vlan40-user vlan-id=40

/ip address
add address=192.168.10.1/24 interface=vlan10-mgmt
add address=192.168.20.1/24 interface=vlan20-server
add address=192.168.30.1/24 interface=vlan30-iot
add address=192.168.40.1/24 interface=vlan40-user

/interface bridge vlan
add bridge=br-lan vlan-ids=10 tagged=br-lan,ether5 untagged=ether2
add bridge=br-lan vlan-ids=20 tagged=br-lan,ether5 untagged=ether3
add bridge=br-lan vlan-ids=30 tagged=br-lan,ether5 untagged=ether4
add bridge=br-lan vlan-ids=40 tagged=br-lan,ether5

/interface bridge
set br-lan vlan-filtering=yes

    여기서 중요한 건 CPU 포트 역할을 하는 브리지 자체를 tagged에 넣는 것입니다. 이걸 빼먹으면 라우터가 해당 VLAN 트래픽을 제대로 처리하지 못해서, 설정은 맞는 것 같은데 IP도 안 붙고 DHCP도 안 되는 상황이 나올 수 있습니다.

    DHCP까지 같이 구성하려면 이렇게 이어가면 됩니다. RouterOS에서는 DHCP 서버가 기본적으로 비활성 상태로 추가되므로, 예시처럼 disabled=no를 넣어 주는 편이 확실합니다.

    /ip pool
add name=pool-mgmt ranges=192.168.10.100-192.168.10.199
add name=pool-server ranges=192.168.20.100-192.168.20.199
add name=pool-iot ranges=192.168.30.100-192.168.30.199
add name=pool-user ranges=192.168.40.100-192.168.40.199

/ip dhcp-server
add name=dhcp-mgmt interface=vlan10-mgmt address-pool=pool-mgmt disabled=no
add name=dhcp-server interface=vlan20-server address-pool=pool-server disabled=no
add name=dhcp-iot interface=vlan30-iot address-pool=pool-iot disabled=no
add name=dhcp-user interface=vlan40-user address-pool=pool-user disabled=no

/ip dhcp-server network
add address=192.168.10.0/24 gateway=192.168.10.1 dns-server=192.168.10.1
add address=192.168.20.0/24 gateway=192.168.20.1 dns-server=192.168.20.1
add address=192.168.30.0/24 gateway=192.168.30.1 dns-server=192.168.30.1
add address=192.168.40.0/24 gateway=192.168.40.1 dns-server=192.168.40.1

/ip dns
set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8

    여기서 한 가지 더 챙길 부분이 있습니다. DHCP에서 각 VLAN의 게이트웨이 주소를 DNS 서버로 내려줄 거라면, 라우터 자체 DNS 리졸버도 같이 켜줘야 합니다. 이걸 빼먹으면 방화벽은 멀쩡한데 웹 접속만 안 되는 묘한 상황이 생기더라고요.

    MikroTik 라우터 VLAN 설정 작업 장면

    브리지, VLAN 인터페이스, 포트 PVID를 설정하는 실제 구성 흐름을 보여주는 장면입니다.

    MikroTik 홈랩 방화벽 규칙 설계: 막을 건 막고, 열 건 열기

    VLAN만 나눠 놓으면 끝이 아닙니다. 진짜 핵심은 방화벽 규칙입니다. VLAN을 나눠도 라우터가 그 사이를 라우팅해 주기 때문에, 규칙을 안 잡으면 서로 통신이 됩니다. 이 부분이 초보 때 가장 많이 놓치는 포인트였습니다.

    저는 아래 원칙으로 갔습니다.

    • 라우터 자체 관리 접근은 관리망에서만 허용
    • IoT망은 인터넷만 허용하고 내부망 접근은 기본 차단
    • 사용자망은 필요한 서버 서비스만 접근 허용
    • Established/Related 연결은 먼저 허용
    • 마지막에는 명시적 Drop 규칙으로 정리

    그리고 일반적인 가정용 회선이라면 인터넷 연결을 위해 NAT(srcnat/masquerade)도 같이 필요합니다. 이 규칙이 빠지면 VLAN 분리는 됐는데 외부 인터넷이 안 되는 경우가 많습니다.

    /interface list
add name=WAN
add name=LAN

/interface list member
add interface=ether1 list=WAN
add interface=vlan10-mgmt list=LAN
add interface=vlan20-server list=LAN
add interface=vlan30-iot list=LAN
add interface=vlan40-user list=LAN

/ip firewall address-list
add list=internal-nets address=10.0.0.0/8
add list=internal-nets address=172.16.0.0/12
add list=internal-nets address=192.168.0.0/16

/ip firewall filter
add chain=input action=accept connection-state=established,related comment="Allow established, related"
add chain=input action=drop connection-state=invalid comment="Drop invalid"
add chain=input action=accept protocol=icmp in-interface-list=LAN comment="Allow ICMP from LAN"
add chain=input action=accept in-interface=vlan10-mgmt src-address=192.168.10.0/24 comment="Allow router management from mgmt VLAN"
add chain=input action=drop in-interface-list=WAN comment="Drop all input from WAN"
add chain=input action=drop in-interface-list=LAN comment="Block router access from non-mgmt VLANs"

add chain=forward action=accept connection-state=established,related comment="Allow established, related forward"
add chain=forward action=drop connection-state=invalid comment="Drop invalid forward"
add chain=forward action=accept src-address=192.168.10.0/24 comment="Mgmt VLAN full access"
add chain=forward action=accept src-address=192.168.40.0/24 dst-address=192.168.20.0/24 protocol=tcp dst-port=80,443,22 comment="User VLAN to selected server services"
add chain=forward action=drop src-address=192.168.30.0/24 dst-address-list=internal-nets comment="Block IoT to internal networks"
add chain=forward action=accept src-address=192.168.30.0/24 out-interface-list=WAN comment="IoT to internet only"
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="Allow LAN to internet"
add chain=forward action=drop in-interface-list=LAN out-interface-list=LAN comment="Default deny inter-VLAN"

/ip firewall nat
add chain=srcnat out-interface-list=WAN action=masquerade comment="Home internet NAT"

    여기서 실무적으로 중요한 건 순서입니다. 방화벽 규칙은 위에서 아래로 평가되기 때문에, 허용 규칙보다 Drop을 먼저 올려버리면 열어 둔 줄 알았던 서비스가 전부 막혀 버릴 수 있습니다. 저도 SSH 하나 열겠다고 손봤다가 왜 안 되지 싶어서 한참 들여다본 적이 있습니다.

    추천하는 방화벽 접근 방식

    1. 먼저 Established/Related 허용
    2. 그다음 라우터 자체 보호용 input 규칙 정리
    3. 서비스별 예외 허용 추가
    4. 마지막에 기본 차단(Default Deny)

    이 구조로 가면 나중에 규칙이 늘어나도 덜 망가집니다. MikroTik 홈랩을 오래 굴릴 생각이면 이게 꽤 중요합니다.

    ⚠️ 실제로 겪었던 문제와 해결법

    여기서는 제가 실제로 많이 헷갈렸던 부분만 적어보겠습니다. 문서만 보면 간단해 보이는데, 현장에서는 꼭 한 번씩 걸리더라고요.

    1. VLAN 필터링을 너무 빨리 켠 경우

    증상: 설정하다가 갑자기 접속이 끊깁니다.

    원인: 브리지 VLAN 테이블이 덜 잡힌 상태에서 vlan-filtering=yes를 먼저 켠 경우입니다.

    해결: Safe Mode에서 작업하거나, 콘솔 접속 가능한 상태에서 마지막 단계에 켜는 게 안전합니다.

    2. 트렁크 포트인데 상대 장비가 태그를 못 받는 경우

    증상: AP나 관리형 스위치 뒤쪽 VLAN이 전부 안 뜹니다.

    원인: 반대편 장비 포트가 Access로 되어 있거나 Native VLAN 설정이 다를 때가 많습니다.

    해결: 양쪽 장비에서 Tagged/Untagged 정책을 맞추고, 필요한 경우 관리 VLAN을 따로 지정합니다.

    3. IoT는 막았는데 Chromecast류 장비 검색이 안 되는 경우

    이건 꽤 자연스러운 현상입니다. 멀티캐스트나 브로드캐스트 기반 탐색은 VLAN 경계에서 그대로 끊기는 경우가 많거든요. 그래서 mDNS Repeater나 별도 예외 정책이 필요할 수 있습니다. 저는 보안 우선으로 두고 꼭 필요한 장비만 따로 예외를 넣었습니다.

    4. 방화벽은 맞는데 DNS 때문에 인터넷이 안 되는 경우

    의외로 자주 만납니다. 포워드 규칙은 열었는데 DNS 질의가 막혀 있거나, DHCP에서 DNS를 잘못 내려주면 사용자는 그냥 “인터넷 안 됨”으로 느낍니다. 이럴 땐 핑과 DNS 조회를 분리해서 보는 게 훨씬 빠릅니다.

    5. NAT를 빼먹어서 외부 인터넷이 안 되는 경우

    이것도 많이 나옵니다. 특히 집에서 MikroTik 라우터가 인터넷 경계 장비 역할을 한다면, 일반적으로 masquerade 규칙이 필요합니다. 상위 장비가 각 VLAN 대역으로 되돌아오는 정적 라우트를 알고 있지 않다면 NAT 없이 바로 인터넷이 되긴 어렵습니다.

    MikroTik 홈랩 방화벽 규칙과 트래픽 흐름 시각화

    관리망, 서버망, IoT망 사이에서 허용되는 경로와 차단되는 경로를 한눈에 보여주는 이미지입니다.

    검증 방법과 실제 결과

    설정을 끝냈다면 반드시 검증을 해야 합니다. 저는 보통 아래 순서로 확인합니다.

    1. 각 VLAN 포트에 장비를 하나씩 연결해서 DHCP 주소가 제대로 나오는지 확인
    2. 게이트웨이 핑이 되는지 확인
    3. 인터넷 접근이 필요한 VLAN은 외부 접속 확인
    4. 차단해야 하는 VLAN 간 접근이 실제로 막히는지 확인
    5. 허용해야 하는 서비스 포트만 열리는지 확인
    # 클라이언트 측 점검 예시
ping 192.168.10.1
ping 192.168.20.1
nslookup example.com
curl http://192.168.20.10
ssh [email protected]

    제가 이 구조로 옮긴 뒤 가장 크게 느낀 변화는 두 가지였습니다. 첫째, 문제 원인을 찾는 시간이 확실히 줄었습니다. “이 장비는 VLAN 30 IoT망”이라고 딱 정리되어 있으니 문제 범위가 바로 좁혀지더라고요. 둘째, 홈 네트워크 보안이 눈에 띄게 안정됐습니다. 적어도 IoT 장비 하나 이상해졌다고 NAS나 하이퍼바이저까지 바로 노출되는 구조는 아니게 된 거죠.

    물론 단점도 있습니다. VLAN이 늘어나면 규칙 관리가 귀찮아집니다. 다만 초반 설계를 잘해 두면 이 불편은 꽤 줄어듭니다. 주소 대역 규칙, 인터페이스 리스트, Address List를 적극적으로 쓰면 나중에 정말 편합니다.

    정리: MikroTik 라우터로 홈랩을 나눌 때 기억할 것

    • VLAN 분리만으로 끝나지 않습니다. 방화벽 규칙이 같이 가야 진짜 분리입니다.
    • 관리망은 별도로 두는 게 좋습니다. 라우터, 스위치, AP 관리는 한 구역으로 모아 두면 운영이 편합니다.
    • IoT망은 기본 차단이 안전합니다. 필요할 때만 예외를 여는 방식이 덜 위험합니다.
    • 트렁크와 액세스 개념을 명확히 구분해야 합니다. 여기서 대부분 꼬입니다.
    • 인터넷 연결 검증에는 DNS와 NAT까지 같이 봐야 합니다. 이 둘이 빠지면 원인 파악이 더 어려워집니다.

    혹시 지금 MikroTik 홈랩을 운영 중인데 네트워크가 점점 복잡해지고 있다면, 가장 먼저 VLAN 2~3개만 나누는 것부터 시작해 보세요. 한 번 구조가 잡히면 이후에 무선 AP, Proxmox, NAS, 리버스 프록시 같은 요소를 붙일 때 훨씬 편합니다. 다음 글에서는 MikroTik 라우터와 무선 AP를 연동해서 SSID별 VLAN을 태우는 방법도 다뤄볼 예정입니다. 이전 글의 홈랩 IP 설계 원칙 글과 함께 보면 흐름이 더 잘 잡힐 겁니다.

    MikroTik 홈랩 VLAN 분리 전후 비교 인포그래픽

    VLAN과 방화벽 적용 전후의 차이를 요약한 비교 인포그래픽입니다.

    자주 묻는 질문

    Q1. 집에서 VLAN까지 꼭 해야 하나요?

    장비가 5~6대 이하이고 성격이 비슷하면 당장은 아닐 수도 있습니다. 하지만 서버, NAS, CCTV, IoT, 재택근무 PC가 섞이기 시작하면 분리해 두는 게 확실히 편합니다.

    Q2. MikroTik 라우터가 초보자에게 너무 어렵지 않나요?

    솔직히 쉽지는 않습니다. 저도 처음엔 메뉴 구조와 용어 때문에 꽤 헷갈렸습니다. 그래도 한 번 브리지, VLAN, 방화벽 흐름을 이해하면 아주 세밀하게 제어할 수 있다는 장점이 큽니다.

    Q3. 방화벽 규칙은 얼마나 세분화해야 하나요?

    처음에는 너무 잘게 나누지 않는 편이 낫습니다. 관리망 전체 허용, IoT망 인터넷만 허용, 사용자망에서 서버 특정 포트 허용 정도로 시작한 뒤 점진적으로 다듬는 방식이 현실적입니다.

  • [HomeLabs] 홈랩 미니PC, NUC vs ASUS PN vs GMKtec 3년 총소유비용 분석

    [HomeLabs] 홈랩 미니PC, NUC vs ASUS PN vs GMKtec 3년 총소유비용 분석

    목차

    [홈랩] 홈랩 미니PC 비용, NUC vs ASUS PN vs GMKtec 3년 총소유비용 분석

    홈랩을 오래 굴려보신 분들은 아시겠지만, 장비를 살 때 제일 무서운 건 초기 구매가만 보고 판단하는 겁니다. 저도 처음엔 작은 미니PC 하나쯤이야 싶어서 덜컥 들였었는데, 24시간 켜두는 홈서버(Home Server, 집에서 상시 운영하는 개인 서버) 특성상 나중에 전기요금이랑 업그레이드 비용이 은근히 쌓이더라고요. 그래서 오늘은 홈랩 미니PC 비용을 좀 더 현실적으로 보려고 합니다. Intel NUC, ASUS PN, GMKtec 같은 미니PC 계열을 놓고, 3년 총소유비용(TCO, Total Cost of Ownership) 관점에서 어떻게 비교하면 좋은지 정리해보겠습니다.

    중요한 점부터 말씀드리면, 이 글은 특정 모델의 실시간 가격표를 들고 와서 승부 보는 글은 아닙니다. 그런 숫자는 시기마다 너무 많이 바뀌거든요. 대신 초기 구매비 + 메모리/스토리지 확장비 + 전력 소비 + 장애 대응 시간까지 같이 보는 방식으로 접근합니다. 실제로 써보니까, 홈랩에서는 이 방식이 제일 덜 후회하더라고요.

    홈랩 미니PC 3종과 전력비용 흐름을 보여주는 개요 다이어그램

    NUC, ASUS PN, GMKtec 계열 미니PC와 전기요금, 스토리지, 운영 시간을 함께 보여주는 홈랩 비용 개요 이미지입니다.

    왜 홈랩 미니PC 비용은 구매가만 보면 안 되나

    쉽게 말해 미니PC는 작아서 싸 보이지만, 오래 돌릴수록 구조적인 차이가 드러납니다. 예를 들어 CPU 세대 차이, 유휴전력(idle power, 대기 상태 전력), 팬 소음, 발열, NVMe SSD(엔브이미 SSD, 고속 저장장치) 슬롯 수, 메모리 확장성 같은 부분이요. 처음엔 이게 뭔가 싶었는데, 홈랩 장비는 결국 한 번 사서 오래 묵히는 경우가 많아서 여기서 체감 차이가 크게 납니다.

    제가 직접 해보니 비용은 대략 아래 다섯 항목으로 나뉘더군요.

    • 초기 구매비: 본체 가격, 어댑터 포함 여부, 운영체제 포함 여부
    • 확장 비용: RAM(메모리), SSD, 추가 NIC(Network Interface Card, 네트워크 인터페이스) 필요 여부
    • 전력 소비: 24시간 상시 구동 시 누적 전기요금
    • 운영 비용: 팬 청소, 발열 관리, 장애 대응 시간
    • 재활용 가치: 3년 뒤 다른 용도로 돌리기 쉬운지

    여기서 중요한 포인트! 홈서버로 Proxmox(프록스목스, 가상화 플랫폼), Docker(도커, 컨테이너 실행 환경), Kubernetes(쿠버네티스, 컨테이너 오케스트레이션) 같은 걸 올릴 계획이면, 단순히 싸게 사는 것보다 확장성과 안정성이 더 큰 비용 절감으로 이어질 수 있습니다.

    Intel NUC, ASUS PN, GMKtec를 어떤 기준으로 봐야 하나

    브랜드별로 딱 잘라서 누가 무조건 낫다고 말하긴 어렵습니다. 다만 홈랩 기준으로는 성격 차이가 좀 있습니다. 저도 처음엔 스펙표만 보고 골랐었는데, 실제로 운영해보니까 체감 포인트가 다르더라고요.

    구분 Intel NUC ASUS PN GMKtec
    포지션 검증된 레퍼런스 성격 균형형 가성비 지향
    홈랩 적합성 안정성 중시 구성에 유리 사무/서버 겸용에 무난 예산 제한 있는 입문자에게 매력적
    확장성 체크포인트 세대별 차이 큼 포트 구성 확인 필요 모델별 편차 확인 필수
    주의할 점 중고/리퍼 비중 높을 수 있음 세부 SKU 확인 필요 발열/소음/펌웨어 후기 체크

    Intel NUC는 오래 홈랩 하신 분들한테 익숙한 이름입니다. 자료도 많고, 케이스 개조나 가이드도 잘 쌓여 있어서 문제 생겼을 때 검색이 잘 되는 편이죠. ASUS PN은 무난하게 잘 만든 사무용 미니PC 느낌인데, 홈서버로도 충분히 쓸 만한 경우가 많습니다. GMKtec은 예산을 줄이려는 분들이 많이 보게 되는 쪽인데, 대신 모델별 편차를 더 꼼꼼하게 봐야 합니다.

    즉, 이 비교의 핵심은 브랜드 전쟁이 아니라 내 홈랩 워크로드에 맞는 비용 구조를 찾는 겁니다.

    3년 총소유비용 계산식, 어렵지 않습니다

    총소유비용(TCO)은 말만 거창하지 계산은 단순합니다. 저는 보통 아래 식으로 잡습니다.

    3년 총소유비용 = 초기 구매비 + 업그레이드 비용 + 3년 전기요금 + 유지보수에 들어간 체감 비용

    여기서 유지보수에 들어간 체감 비용은 정확히 숫자로 박기 어렵습니다. 그래서 실무적으로는 아래처럼 두 단계로 나눠 보시면 편합니다.

    1. 확정 비용: 본체, RAM, SSD, 전기요금
    2. 비확정 비용: 장애 대응 시간, 발열로 인한 스트레스, 재설치 빈도

    사실 홈랩은 취미이기도 해서 시간 비용을 100% 돈으로 환산하긴 어렵거든요. 근데 삽질이 너무 잦으면 결국 장비를 안 켜게 됩니다. 이게 제일 비싼 비용이더라고요 ㅎㅎ

    전기요금 계산 예시

    평균 소비전력을 기준으로 계산하면 됩니다.

    # 평균 소비전력(W), 사용시간(h), 전기요금 단가(원/kWh)를 넣어 계산
AVG_WATT=15
HOURS_PER_DAY=24
DAYS=1095
PRICE_PER_KWH=150

echo "scale=2; ($AVG_WATT / 1000) * ($HOURS_PER_DAY * $DAYS) * $PRICE_PER_KWH" | bc

    위 방식은 아주 단순한 계산입니다. 실제로는 유휴 상태와 부하 상태가 섞이기 때문에, 가능하면 스마트 플러그(smart plug, 전력 측정 가능한 콘센트)로 1주일 정도 측정해 평균값을 잡는 게 낫습니다.

    실전 구현: 홈랩 미니PC 비용 계산 템플릿 만들기

    여기서는 제가 실제로 자주 쓰는 방식대로, 전력 로그를 모으고 3년 TCO를 계산하는 간단한 템플릿을 보여드릴게요. 홈랩 미니PC 비용 비교는 감으로 하면 꼭 후회합니다. 숫자를 남겨야 합니다.

    1. 후보 장비 3개를 정합니다.
    2. 각 장비의 예상 초기 비용을 적습니다.
    3. RAM/SSD 업그레이드 비용을 따로 분리합니다.
    4. 평균 전력 소비를 측정하거나 보수적으로 추정합니다.
    5. 3년 기준으로 같은 공식에 넣어 비교합니다.
    devices = [
    
    {
    
        "name": "Intel NUC\