[카테고리:] 홈서버구축

  • 홈서버 로컬 LLM 구축 Ollama Docker로 소형 모델 올리기

    홈서버 로컬 LLM 구축 Ollama Docker로 소형 모델 올리기

    홈서버에서 로컬 LLM을 돌려보는 이유

    책상 위에 놓인 작은 서버가 문서 요약이나 간단한 질의응답까지 해주면 생각보다 쓸모가 많습니다. 거창한 GPU 서버가 아니어도 1B~3B급 소형 LLM부터 올려보면, 홈서버에서 어디까지 가능한지 감을 잡을 수 있습니다.

    이번 구성은 Rocky Linux 9.x / Docker Engine 28.x / Docker Compose v2.x / Ollama Docker 이미지 조합을 기준으로 정리했습니다. Oracle Cloud Free Tier ARM 같은 저전력 서버나 시놀로지에서 Docker를 쓰는 환경도 큰 흐름은 비슷합니다.

    홈서버 로컬 LLM 구성 참고 이미지

    Ollama를 Docker로 올리기

    Ollama는 리눅스 설치 스크립트도 제공하지만, 홈서버에서는 나중에 지우거나 옮기기 쉬운 Docker 방식이 관리하기 편했습니다. 공식 Docker Hub 기준으로 Ollama 컨테이너는 11434 포트를 사용합니다.

    mkdir -p ~/services/ollama
    cd ~/services/ollama
    
    services:
      ollama:
        image: ollama/ollama:latest
        container_name: ollama
        restart: unless-stopped
        ports:
          - "127.0.0.1:11434:11434"
        volumes:
          - ollama:/root/.ollama
    
    volumes:
      ollama:
    
    docker compose up -d
    docker exec -it ollama ollama --version
    

    포트를 127.0.0.1로 묶은 이유는 단순합니다. LLM API를 인터넷에 바로 노출하지 않기 위해서입니다. 내부망 밖에서 접근해야 한다면 VPN, Tailscale, 리버스 프록시 인증 같은 보호 장치를 먼저 붙이는 편이 낫습니다.

    작은 모델부터 테스트하기

    처음부터 7B, 14B 모델을 받으면 다운로드도 오래 걸리고 메모리도 금방 부족해집니다. 홈서버에서는 1B~3B 모델로 시작하는 편이 현실적입니다.

    docker exec -it ollama ollama pull llama3.2:1b
    docker exec -it ollama ollama run llama3.2:1b
    

    간단한 호출은 curl로 바로 확인할 수 있습니다.

    curl http://127.0.0.1:11434/api/chat \
      -d '{
        "model": "llama3.2:1b",
        "messages": [
          {
            "role": "user",
            "content": "홈서버에서 로컬 LLM을 돌릴 때 장점 3가지만 짧게 정리해줘."
          }
        ],
        "stream": false
      }'
    

    응답이 느리더라도 일단 동작하면 기본 구성은 된 셈입니다. CPU만 쓰는 서버라면 속도보다 상시 실행 가능 여부와 메모리 여유를 먼저 확인하는 게 좋습니다.

    로컬 서버와 인공지능 구성을 떠올리게 하는 이미지

    홈서버용 소형 LLM 후보

    Ollama 라이브러리 기준으로 llama3.2는 1B와 3B 모델을 제공하고, qwen2.5는 0.5B부터 3B까지 작은 선택지가 넓습니다. gemma3도 270M, 1B처럼 가벼운 모델이 있어 테스트용으로 부담이 적습니다.

    순위 제품명 핵심 강점 총평 평점
    1 llama3.2:1b 가볍고 시작이 빠름 CPU 홈서버에서 첫 테스트용으로 무난합니다 4.5
    2 qwen2.5:1.5b 크기와 답변 품질의 균형 한국어 질문도 간단한 용도라면 꽤 버팁니다 4.3
    3 qwen2.5:3b 조금 더 나은 답변 품질 메모리 여유가 있으면 1B급보다 만족도가 올라갑니다 4.2
    4 gemma3:1b 작은 용량과 빠른 테스트 가벼운 질의응답, 요약 실험에 맞습니다 4.0

    이 점수는 절대 성능표가 아니라 홈서버에서 굴려볼 때의 체감 기준에 가깝습니다. 특히 CPU 서버라면 3B 모델부터 답변 대기 시간이 꽤 느껴질 수 있습니다.

    모델 파일과 저장공간 관리

    모델 파일은 생각보다 빨리 쌓입니다. 내려받은 모델은 ollama list로 확인하고, 잘 쓰지 않는 모델은 정리하는 편이 좋습니다.

    docker exec -it ollama ollama list
    docker exec -it ollama ollama rm qwen2.5:3b
    

    시놀로지나 미니PC처럼 저장공간이 넉넉하지 않은 장비라면 모델을 여러 개 받아두기보다 하나씩 비교하고 지우는 방식이 낫습니다. 백업 대상에도 모델 볼륨을 꼭 포함할 필요는 없습니다. 다시 받을 수 있는 파일이라면 설정만 따로 관리해도 충분합니다.

    로컬 LLM과 홈서버 운영을 연상시키는 이미지

    어디까지 기대할 수 있을까

    소형 LLM은 대형 모델처럼 긴 추론이나 복잡한 코딩을 매끄럽게 처리하진 못합니다. 대신 개인 메모 요약, 짧은 문장 다듬기, 로그 설명, 내부 문서 초안 정리 같은 작업에는 꽤 현실적인 재미가 있습니다.

    나중에 Open WebUI 같은 웹 인터페이스를 붙이면 개인 장비나 가족용 브라우저에서도 접근하기 편합니다. 다만 이때도 인증 없이 외부에 열어두는 구성은 피해야 합니다.

    공식 안내는 아래 링크에서 확인했습니다. 모델 크기와 태그는 바뀔 수 있으니 실제 설치 전에는 한 번 더 확인하는 편이 안전합니다.

    • Ollama Linux 설치: https://ollama.com/download/linux
    • Ollama Docker 이미지: https://hub.docker.com/r/ollama/ollama
    • Ollama 모델 라이브러리: https://ollama.com/library
  • 홈서버 소프트웨어 라이선스 오픈소스와 상용 제품 차이

    홈서버 소프트웨어 라이선스 오픈소스와 상용 제품 차이

    홈서버에서 라이선스를 먼저 봐야 하는 이유

    홈서버를 구성하다 보면 하드웨어보다 먼저 막히는 지점이 의외로 소프트웨어 라이선스입니다. 설치 자체는 금방 끝나지만, 개인 사용만 가능한지, 외부 접속을 열어도 되는지, 가족이나 팀원과 함께 써도 되는지는 따로 확인해야 합니다.

    Rocky Linux 9.x, Docker Compose v2, MinIO 같은 S3 호환 스토리지, 리버스 프록시, 모니터링 도구를 엮어 쓰는 구성이라면 더 그렇습니다. 홈서버라고 해도 여러 소프트웨어가 함께 돌아가는 운영 환경이기 때문에, 라이선스 범위를 대충 넘기기는 어렵습니다.

    홈서버와 소프트웨어 구성을 떠올리게 하는 서버 이미지

    오픈소스라고 전부 자유로운 것은 아닙니다

    오픈소스는 소스코드가 공개되어 있고, 정해진 조건 안에서 사용·수정·배포할 수 있는 소프트웨어입니다. 여기서 중요한 기준은 무료 여부가 아니라 사용 조건입니다.

    MIT, Apache 2.0 같은 라이선스는 개인 홈서버에서 쓰기 비교적 부담이 적은 편입니다. Docker로 서비스를 올리고 내부망이나 개인 도메인으로 접속하는 정도라면 대체로 큰 문제가 생기지 않습니다.

    다만 GPL 계열은 조금 더 신경 써야 합니다. 직접 수정한 프로그램을 외부에 배포하거나 공개 서비스에 붙일 때는 소스 공개 의무가 따라올 수 있습니다. 집에서 설치해 혼자 쓰는 수준이라면 부담이 크지 않지만, 수정본을 나눠주거나 상업 서비스에 연결하면 해석이 달라질 수 있습니다.

    라이선스 제품은 기능보다 사용 범위가 먼저입니다

    라이선스 제품은 구매하거나 구독해서 쓰는 상용 소프트웨어를 말합니다. 홈서버에서는 NAS 운영체제, 백업 솔루션, 가상화 관리 도구, 보안 제품에서 자주 마주칩니다.

    이런 제품은 기능표만 보면 매력적으로 보이지만, 실제로는 개인용·비상업용·상업용·사용자 수·장치 수 같은 조건이 더 중요합니다. 무료 플랜이라고 해도 서버 설치가 제한되어 있거나, 기업망 사용이 금지되는 경우가 있습니다.

    특히 홈서버를 가족용에서 소규모 팀, 동호회, 외부 사용자용으로 넓히면 개인 사용 범위를 벗어날 수 있습니다. 이때는 “돈을 받지 않으니 괜찮다”보다 약관에 적힌 사용 범위를 확인하는 쪽이 안전합니다.

    네트워크와 서버 운영을 연상시키는 기술 이미지

    홈서버에서 자주 만나는 선택지

    홈서버에서 자주 비교하게 되는 소프트웨어 유형을 정리하면 다음과 같습니다.

    구분 장점 주의할 점
    오픈소스 소프트웨어 비용 부담이 낮고 수정·자동화·Docker 배포가 자유로운 편입니다 라이선스별 의무가 다르며, 문제 발생 시 직접 해결해야 하는 경우가 많습니다
    무료 상용 제품 설치가 쉽고 UI가 정리되어 있어 입문자가 접근하기 좋습니다 개인용 제한, 기능 제한, 사용자 수 제한이 붙을 수 있습니다
    유료 라이선스 제품 공식 지원, 업데이트, 관리 기능이 안정적인 편입니다 장치 수나 사용자 수에 따라 비용이 늘고, 홈랩 규모에서는 과할 수 있습니다

    설치 전에 확인할 핵심 항목

    개인적으로는 설치 전에 라이선스 전문을 처음부터 끝까지 읽기보다, 먼저 세 가지를 확인합니다. 개인 사용 허용 여부, 외부 공개 가능 여부, 수정·배포 조건입니다.

    MinIO 같은 S3 호환 스토리지를 올리고, 리버스 프록시로 여러 서비스를 묶고, 대시보드까지 붙이면 외부 접속 구조가 자연스럽게 생깁니다. 이때 단순 내부 테스트인지, 실제 사용자에게 열어두는 서비스인지에 따라 라이선스 해석이 달라질 수 있습니다.

    Docker 이미지도 따로 봐야 합니다. 컨테이너로 배포된다고 해서 라이선스 조건이 사라지는 것은 아닙니다. 이미지 안에 포함된 애플리케이션, 플러그인, 폰트, 데이터베이스에도 각각 다른 조건이 있을 수 있습니다.

    흔히 헷갈리는 부분

    오픈소스와 무료 소프트웨어를 같은 의미로 쓰는 경우가 많지만, 실제로는 다릅니다. 무료지만 소스가 닫힌 제품도 있고, 오픈소스지만 특정 조건을 지켜야 하는 제품도 있습니다.

    홈서버에서는 “혼자 쓰니까 괜찮겠지” 하고 넘어가기 쉽습니다. 개인 메모, 사진 백업, 미디어 서버 정도라면 대체로 부담이 적지만, 외부 계정을 만들어주거나 커뮤니티용 서비스로 확장하면 확인할 항목이 늘어납니다.

    상업용 여부도 단순히 매출 발생만 뜻하지는 않습니다. 회사 업무 자료를 올리거나, 사무실 장비에서 운영하거나, 업무용 계정으로 접속하게 하면 개인 홈랩과 다르게 볼 여지가 있습니다.

    서버 운영과 개발 환경을 떠올리게 하는 작업 이미지

    오래 운영하려면 기록이 필요합니다

    홈서버 구축 초반에는 기능이 먼저 눈에 들어오지만, 오래 운영하려면 라이선스 메모를 남겨두는 편이 좋습니다. 서비스 이름, 버전, 라이선스 종류, 공식 링크 정도만 정리해도 나중에 교체하거나 공개 범위를 바꿀 때 판단이 빨라집니다.

    특히 백업, 스토리지, 인증, 모니터링처럼 서버 핵심에 붙는 소프트웨어는 업데이트 정책과 라이선스 변경 가능성도 함께 봐두는 것이 좋습니다. 예전에는 자유롭게 쓰던 기능이 어느 순간 유료 플랜으로 이동하는 경우도 있습니다.

    정리하면, 홈서버에서 오픈소스는 자유도가 큰 대신 조건을 직접 확인해야 하고, 라이선스 제품은 편의성이 있는 대신 사용 범위가 더 명확하게 제한됩니다. 처음부터 모든 항목을 완벽하게 따질 필요는 없지만, 외부 공개나 공동 사용으로 넘어가는 시점에는 한 번 멈춰서 라이선스를 확인하는 습관이 필요합니다.

  • Rocky Linux 9 SSH 포트 변경과 SELinux 접속 오류 해결

    Rocky Linux 9 SSH 포트 변경과 SELinux 접속 오류 해결

    서버를 처음 열어둘 때 가장 긴장되는 순간은 설치보다 SSH 설정을 바꾼 직후입니다. Rocky Linux 9에서 sshd_config의 포트만 바꾸고 재시작했다가 접속이 막히면 복구가 번거로워집니다. SSH 포트 변경은 단순히 숫자 하나를 바꾸는 작업이 아니라 sshd 설정, SELinux, firewalld 세 군데를 함께 맞추는 작업입니다.

    홈서버 SSH 설정 참고 이미지

    먼저 끊지 말아야 할 것

    Rocky Linux 9.x에서 작업할 때 가장 먼저 지켜야 할 것은 명령어 순서보다 현재 SSH 세션을 유지하는 것입니다. 설정을 바꾼 뒤 기존 터미널을 바로 닫으면, 새 포트 접속이 실패했을 때 되돌아갈 통로가 사라질 수 있습니다.

    오라클 클라우드 같은 VPS 환경에서는 서버 내부의 firewalld만 열어서는 부족합니다. 콘솔의 Security List 인바운드 규칙에서도 새 SSH 포트를 허용해야 합니다. 집에서 운영하는 홈서버라면 공유기 포트포워딩도 함께 확인해야 합니다.

    확인 항목 해야 할 일
    기존 SSH 세션 닫지 않고 유지
    새 터미널 변경 포트로 접속 테스트
    클라우드 방화벽 Security List 인바운드 허용
    홈서버 공유기 포트포워딩 확인
    비상 접속 콘솔, IPMI, 시리얼 콘솔 확보

    1단계, sshd_config에서 포트 지정

    예시는 2222 포트로 진행하겠습니다. 기본 설정 파일을 직접 수정해도 되고, Rocky Linux 9에서는 /etc/ssh/sshd_config.d/ 아래에 별도 설정 파일을 두는 방식도 사용할 수 있습니다.

    기본 파일을 수정한다면 아래처럼 엽니다.

    sudo vi /etc/ssh/sshd_config
    

    그리고 Port 값을 지정합니다.

    Port 2222
    

    drop-in 방식으로 관리하고 싶다면 별도 파일을 만들어도 됩니다.

    sudo vi /etc/ssh/sshd_config.d/10-custom-port.conf
    
    Port 2222
    

    여기까지만 하고 sshd를 재시작하면 접속이 막힐 수 있습니다. Rocky Linux 계열에서는 SELinux가 해당 포트를 SSH용 포트로 허용하는지를 따로 확인해야 합니다.

    2단계, SELinux 포트 컨텍스트 추가

    이 글에서 가장 중요한 부분입니다. SELinux를 enforcing 상태로 유지하면서 새 포트를 SSH용으로 등록해야 합니다. setenforce 0으로 넘기는 방식은 당장은 편해 보여도, 서버 운영 기준으로는 권장하기 어렵습니다.

    먼저 semanage 명령이 없다면 패키지를 설치합니다.

    sudo dnf install policycoreutils-python-utils
    

    새 SSH 포트를 등록합니다.

    sudo semanage port -a -t ssh_port_t -p tcp 2222
    

    이미 같은 포트가 등록되어 있거나 기존 항목을 수정해야 한다면 -a 대신 -m을 사용합니다.

    sudo semanage port -m -t ssh_port_t -p tcp 2222
    

    등록 여부는 아래 명령으로 확인합니다.

    sudo semanage port -l | grep ssh
    

    정상이라면 ssh_port_t 항목에 2222가 포함되어 있어야 합니다. Rocky Linux 9에서 SSH 포트 변경 후 접속이 안 되는 문제는 이 SELinux 포트 컨텍스트에서 걸리는 경우가 많습니다.

    3단계, firewalld에서 포트 열기

    SELinux까지 맞췄다면 이제 OS 방화벽을 열 차례입니다. Rocky Linux 9 기준으로는 firewalld를 사용합니다.

    sudo firewall-cmd --permanent --add-port=2222/tcp
    sudo firewall-cmd --reload
    

    기존 22번 포트를 닫을지는 바로 결정하지 않는 편이 안전합니다. 새 포트 접속이 확실히 되는 것을 확인한 뒤 닫아도 늦지 않습니다.

    sudo firewall-cmd --permanent --remove-service=ssh
    sudo firewall-cmd --reload
    

    이 명령은 선택 사항입니다. 운영 중인 서버라면 새 포트 접속 성공 확인 후 기존 SSH 서비스 제거 순서로 진행하는 것이 안전합니다.

    4단계, 적용하고 새 터미널에서 검증

    설정이 끝났다면 sshd를 재시작합니다.

    sudo systemctl restart sshd
    

    기존 터미널은 그대로 둔 상태에서 새 터미널을 열고 변경한 포트로 접속합니다.

    ssh -p 2222 user@host
    

    접속이 안 된다면 설정을 다시 감으로 고치기보다, 어디서 막혔는지 나눠서 확인하는 편이 빠릅니다.

    sudo ss -tlnp | grep 2222
    sudo journalctl -u sshd -n 50 --no-pager
    sudo firewall-cmd --list-ports
    sudo semanage port -l | grep ssh
    

    ss에서 2222 포트가 보이지 않으면 sshd 설정을 먼저 봐야 합니다. journalctl에서 SELinux 관련 거부 흔적이 보이면 포트 컨텍스트를 다시 확인해야 합니다. 클라우드 서버라면 이 단계에서 클라우드 보안 목록 인바운드 규칙도 함께 확인해야 합니다.

    정리해두면 덜 당황합니다

    SSH 포트 변경은 간단한 보안 설정처럼 보이지만, Rocky Linux 9에서는 sshd_config, SELinux, firewalld가 함께 맞아야 정상적으로 동작합니다. 특히 SELinux를 끄지 않고 포트 컨텍스트를 등록하는 것이 핵심입니다.

    포트 변경만으로 보안이 끝나는 것은 아닙니다. 이후에는 SSH 키 인증, 비밀번호 로그인 차단, fail2ban 같은 설정까지 이어가면 홈서버 운영을 더 안정적으로 가져갈 수 있습니다.

  • Rocky Linux 9 Docker 설치와 첫 컨테이너 실행 방법

    Rocky Linux 9 Docker 설치와 첫 컨테이너 실행 방법

    Rocky Linux 9 서버에 Docker를 올릴 때는 명령어 몇 줄보다 저장소를 어떻게 잡을지가 더 중요했습니다. 예전 습관대로 yum을 치기 쉬운데, Rocky Linux 9에서는 dnf 기준으로 정리해두는 편이 나중에 서버를 다시 만들 때도 덜 헷갈립니다.

    이번 구성은 Rocky Linux 9.x / Docker Engine 공식 RHEL 저장소 / Docker Compose v2 플러그인 기준으로 확인했습니다. Docker 설치 흐름은 공식 문서의 RHEL 계열 설치 안내를 참고했습니다.

    참고: https://docs.docker.com/engine/install/rhel/

    홈서버 구축 참고 이미지

    설치 전에 정리한 기준

    Rocky Linux 9에서는 기본 저장소에 있는 패키지보다 Docker 공식 repo를 추가해서 설치하는 쪽으로 잡았습니다. 홈서버는 한 번 올려두면 업데이트를 계속 따라가야 하므로, 처음부터 공식 저장소 흐름으로 맞춰두는 편이 관리하기 좋습니다.

    항목 Rocky Linux 9 기준
    패키지 관리자 dnf 사용
    저장소 Docker 공식 RHEL repo 추가
    설치 패키지 docker-ce, docker-ce-cli, containerd.io, buildx, compose plugin
    서비스 시작 systemctl enable –now docker
    일반 유저 실행 docker 그룹 추가 후 재로그인

    먼저 예전 Docker 관련 패키지가 남아 있다면 정리합니다. 새 서버라면 대부분 없다고 나오지만, 이미지 템플릿을 여러 번 바꿔 쓴 서버라면 한 번 확인하는 편이 낫습니다.

    sudo dnf remove docker \
      docker-client \
      docker-client-latest \
      docker-common \
      docker-latest \
      docker-latest-logrotate \
      docker-logrotate \
      docker-engine \
      podman \
      runc
    

    Docker 공식 repo 추가하기

    핵심은 기본 repo만으로 바로 설치하지 않는 것입니다. dnf config-manager --add-repo로 Docker 공식 저장소를 먼저 추가합니다.

    sudo dnf -y install dnf-plugins-core
    
    sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
    

    그다음 Docker Engine과 Compose v2 플러그인까지 함께 설치합니다. 요즘은 docker-compose 단독 바이너리보다 docker compose 형태의 v2 플러그인을 쓰는 경우가 많아서, 처음부터 같이 넣어두는 편이 편합니다.

    sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    

    설치 중 GPG 키 확인이 뜨면 Docker 공식 문서에 나온 fingerprint와 맞는지 확인하고 진행합니다. 제가 확인한 공식 문서 기준 fingerprint는 060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35입니다.

    서비스 시작과 부팅 자동 실행

    설치가 끝났다고 Docker가 바로 실행되는 것은 아닙니다. 이 부분을 놓치면 docker ps부터 막히기 쉽습니다.

    sudo systemctl enable --now docker
    

    상태와 버전은 아래처럼 확인했습니다.

    systemctl status docker
    docker version
    docker compose version
    

    enable --now부팅 자동 실행 등록과 즉시 시작을 한 번에 처리합니다. 홈서버에서는 재부팅 뒤 서비스가 올라오지 않아 당황하는 일이 있으니, 처음부터 enable까지 같이 걸어두는 편이 좋습니다.

    sudo 없이 Docker 쓰기

    처음에는 sudo docker ps로 확인해도 되지만, 매번 sudo를 붙이는 것은 번거롭습니다. 일반 유저를 docker 그룹에 넣으면 됩니다.

    sudo usermod -aG docker $USER
    

    다만 이 명령을 실행해도 현재 SSH 세션에 바로 반영되지는 않았습니다. 재로그인이 필요합니다. 급하면 아래처럼 새 그룹을 적용할 수 있지만, 저는 보통 SSH를 끊었다가 다시 접속해서 확인합니다.

    newgrp docker
    docker run hello-world
    

    주의할 점도 있습니다. Docker 공식 문서에서도 docker 그룹은 사실상 높은 권한을 갖는다고 안내합니다. 혼자 쓰는 홈서버라면 편의성이 크지만, 여러 사람이 접속하는 서버라면 아무 유저나 넣지 않는 것이 맞습니다.

    참고: https://docs.docker.com/engine/install/linux-postinstall/

    첫 컨테이너 띄워보기

    설치 확인용으로는 hello-world가 가장 가볍습니다.

    docker run hello-world
    

    조금 더 실제 서비스에 가까운 형태로 보려면 Nginx를 하나 띄워볼 수 있습니다.

    docker run -d --name web-test -p 8080:80 nginx
    

    확인은 이렇게 했습니다.

    docker ps
    curl http://localhost:8080
    

    외부 브라우저에서 접속하려면 서버 방화벽과 클라우드 보안 규칙까지 같이 봐야 합니다. Oracle Cloud 같은 환경에서는 OS 안의 방화벽만 열었다고 끝이 아니라, 콘솔 쪽 인바운드 규칙도 맞아야 합니다.

    firewalld에서 한 번 막힌 부분

    Rocky Linux 계열은 firewalld가 켜져 있는 경우가 많습니다. Docker가 bridge 네트워크와 iptables/nftables 쪽을 만지다 보니, 컨테이너는 떠 있는데 외부 접속이 애매하게 안 되는 상황을 만날 수 있습니다.

    먼저 상태부터 확인합니다.

    sudo systemctl status firewalld
    sudo firewall-cmd --state
    

    단순 테스트용으로 8080 포트를 열어야 한다면 이렇게 처리할 수 있습니다.

    sudo firewall-cmd --add-port=8080/tcp --permanent
    sudo firewall-cmd --reload
    

    저는 여기서 컨테이너 문제라고 생각하고 docker run 옵션만 계속 바꿨는데, 실제로는 방화벽과 클라우드 보안 규칙을 함께 봐야 했습니다. 홈서버에서 Docker 네트워킹이 꼬였다고 느껴질 때는 컨테이너 로그보다 방화벽 상태를 먼저 확인하는 것이 시간을 줄여줍니다.

    마무리 메모

    Rocky Linux 9에 Docker를 올리는 흐름은 단순합니다. yum이 아니라 dnf를 쓰고, Docker 공식 repo를 추가한 뒤 설치하고, systemctl enable --now docker로 서비스까지 올리면 됩니다.

    마지막으로 일반 유저를 docker 그룹에 넣었다면 재로그인까지 해야 실제로 반영됩니다. 첫 컨테이너는 hello-world로 확인하고, 실제 서비스는 포트와 firewalld, 클라우드 인바운드 규칙까지 같이 맞춰두면 다음 컨테이너부터는 훨씬 수월하게 올릴 수 있습니다.

  • WireGuard ipTIME VPN으로 외부에서 홈네트워크 접속하기

    WireGuard ipTIME VPN으로 외부에서 홈네트워크 접속하기

    밖에서 집 안 NAS나 홈서버에 접속해야 할 때가 있습니다. 서비스별로 포트를 하나씩 열 수도 있지만, 직접 운영해보면 관리가 금방 복잡해집니다. 그래서 저는 외부 접속은 먼저 VPN으로 집 네트워크 안에 들어오는 방식을 기준으로 잡습니다.

    작업 기준은 Rocky Linux 9.x / Docker Compose v2 / ipTIME 공유기 / WireGuard 클라이언트 조합입니다. ipTIME은 모델과 펌웨어에 따라 WireGuard 지원 여부가 다르니, 관리 화면에서 VPN 메뉴를 먼저 확인하는 편이 좋습니다.

    홈네트워크 외부 접속 참고 이미지

    외부 접속을 VPN으로 묶는 이유

    집 안에서만 쓰는 NAS, 홈서버, 프린터, 내부 대시보드는 보통 192.168.0.10, 192.168.0.20 같은 사설 IP 대역에 있습니다. 외부에서는 이 주소로 바로 접근할 수 없기 때문에, 집 공유기나 VPN 서버가 중간 통로 역할을 해야 합니다.

    포트포워딩으로 서비스를 직접 열면 처음 설정은 쉬워 보입니다. 하지만 서비스가 늘어날수록 열어둔 포트와 인증 방식을 따로 관리해야 합니다. 반면 WireGuard를 쓰면 외부 기기가 집 안 네트워크에 들어온 것처럼 동작해서, 내부 IP로 NAS나 서버에 접근할 수 있습니다.

    방식 주요 특징 추천 대상
    WireGuard 직접 구성 홈서버나 NAS에 VPN 서버 설치 Linux 서버나 Docker를 다루는 사용자
    ipTIME VPN 기능 공유기 관리 화면에서 설정 간단한 원격 접속이 필요한 사용자
    포트포워딩 직접 개방 서비스 포트를 외부에 노출 임시 테스트 정도에 적합

    WireGuard 구성 흐름

    WireGuard는 서버와 클라이언트가 서로의 공개키를 등록하는 구조입니다. 서버에는 집 안으로 들어올 클라이언트 정보를 넣고, 노트북이나 휴대폰에는 집으로 접속할 서버 정보를 넣습니다.

    Linux 서버에서 직접 구성한다면 기본 흐름은 아래처럼 시작합니다.

    sudo dnf install wireguard-tools
    wg genkey | tee privatekey | wg pubkey > publickey
    

    서버 설정은 다음과 같은 형태입니다.

    [Interface]
    Address = 10.8.0.1/24
    ListenPort = 51820
    PrivateKey = 서버_개인키
    
    [Peer]
    PublicKey = 클라이언트_공개키
    AllowedIPs = 10.8.0.2/32
    

    클라이언트 쪽 설정에서는 집 공인 IP나 DDNS 주소를 Endpoint에 넣습니다.

    [Interface]
    Address = 10.8.0.2/24
    PrivateKey = 클라이언트_개인키
    DNS = 192.168.0.1
    
    [Peer]
    PublicKey = 서버_공개키
    Endpoint = example.iptime.org:51820
    AllowedIPs = 192.168.0.0/24, 10.8.0.0/24
    PersistentKeepalive = 25
    

    여기서 핵심은 AllowedIPs입니다. 집 내부망만 VPN으로 보내려면 192.168.0.0/24처럼 내부 대역을 넣습니다. 외부 인터넷 트래픽까지 모두 집을 거치게 하려면 0.0.0.0/0을 쓰지만, 홈서버 접속 목적이라면 내부망만 보내는 구성이 보통 더 간단합니다.

    네트워크 보안 참고 이미지

    ipTIME에서 확인할 설정

    ipTIME을 사용한다면 먼저 DDNS, 포트포워딩, VPN 메뉴를 확인합니다. 집 인터넷은 공인 IP가 바뀔 수 있으므로 DDNS를 설정해두면 외부 접속 주소를 고정된 것처럼 쓸 수 있습니다.

    WireGuard 서버를 홈서버에 올렸다면 ipTIME에서는 UDP 포트 하나만 서버로 넘겨주면 됩니다.

    항목 설정 위치 값 예시 확인할 점
    ipTIME DDNS 고급 설정 또는 특수 기능 메뉴 example.iptime.org 외부 접속 주소로 사용
    포트포워딩 NAT/라우터 관리 UDP 51820 → 서버 IP TCP가 아니라 UDP로 설정
    내부 서버 IP DHCP 고정 할당 192.168.0.10 서버 IP가 바뀌면 접속이 끊김
    WireGuard 클라이언트 모바일 앱 또는 PC 앱 설정 파일 import QR 등록이 가능하면 편함

    공유기 자체에서 WireGuard 서버 기능을 지원한다면 홈서버에 따로 설치하지 않아도 됩니다. 다만 ipTIME은 모델별 차이가 있으니, 관리 페이지에 해당 메뉴가 없다면 펌웨어 업데이트와 지원 모델 여부를 확인해야 합니다. 이 부분은 현재 사용하는 공유기 모델 기준으로 확인하는 것이 안전합니다.

    외부망에서 접속 테스트하기

    설정을 마친 뒤에는 집 와이파이에 붙은 상태로 테스트하면 결과가 헷갈릴 수 있습니다. 휴대폰을 LTE나 5G로 바꾼 다음 WireGuard를 켜고 내부 IP로 접속해보는 편이 확실합니다.

    예를 들어 NAS가 192.168.0.20이면 브라우저에서 해당 내부 주소로 접속해봅니다. SSH 서버라면 아래처럼 확인할 수 있습니다.

    ssh [email protected]
    

    접속이 안 될 때는 보통 공유기 포트포워딩, 서버 방화벽, AllowedIPs 대역에서 막힙니다. 특히 Rocky Linux 계열은 firewalld가 켜져 있는 경우가 많아서 UDP 51820 허용 여부를 함께 확인해야 합니다.

    sudo firewall-cmd --add-port=51820/udp --permanent
    sudo firewall-cmd --reload
    

    운영할 때 주의할 점

    VPN이라고 해서 아무렇게나 열어두면 안 됩니다. 클라이언트 설정 파일에는 개인키가 들어가므로 메신저나 공개 저장소에 올리면 안 됩니다. 가족 기기나 노트북마다 키를 따로 만들고, 분실한 기기는 서버 설정에서 해당 Peer만 지우는 방식이 관리하기 좋습니다.

    VPN 접속 보안 참고 이미지

    집 밖에서 홈네트워크에 접근하는 목적이라면 처음부터 모든 서비스를 외부에 공개할 필요는 없습니다. WireGuard + ipTIME DDNS + UDP 포트포워딩 하나만 잡아도 NAS, 홈서버, 내부 웹페이지 접근은 꽤 깔끔하게 정리됩니다. 설정 후에는 외부망에서 실제 접속 테스트를 해두고, 공유기 펌웨어와 서버 방화벽 상태를 주기적으로 확인하는 정도면 일상적인 홈서버 운영에는 충분합니다.

  • 서버 뜻과 클라이언트 관계로 이해하는 홈서버 기본 개념

    서버 뜻과 클라이언트 관계로 이해하는 홈서버 기본 개념

    처음 서버를 공부할 때 가장 헷갈렸던 건, 서버가 꼭 거대한 장비를 뜻한다고 생각한 점이었습니다. 그런데 홈서버를 조금씩 만져보면 서버는 장비 이름이라기보다 요청을 받고 응답을 돌려주는 역할에 가깝다는 걸 알게 됩니다.

    서버 개념 참고 이미지

    서버는 기다렸다가 응답하는 쪽입니다

    서버를 단순하게 말하면, 누군가의 요청을 기다리고 있다가 필요한 데이터를 보내주거나 작업 결과를 돌려주는 컴퓨터 또는 프로그램입니다. 여기서 중요한 점은 서버가 물리적인 컴퓨터일 수도 있고, 그 안에서 실행되는 소프트웨어일 수도 있다는 것입니다.

    예를 들어 집에서 NAS를 켜두고 스마트폰으로 사진을 확인한다면, NAS는 사진 파일을 제공하는 서버 역할을 합니다. 블로그에 접속했을 때 글과 이미지를 보여주는 웹서버도 같은 구조입니다.

    홈서버를 구성하다 보면 이 개념이 더 현실적으로 다가옵니다. 남는 미니PC에 Docker를 설치하고 파일 공유, 미디어 서버, 백업 서비스를 올려두면 그 장비는 여러 가지 서버 역할을 동시에 하게 됩니다. 서버는 꼭 데이터센터에 있는 랙 장비만을 뜻하지 않습니다.

    클라이언트와 서버는 요청과 응답으로 이어집니다

    클라이언트는 서버에 무언가를 요청하는 쪽입니다. 스마트폰, 노트북, 웹브라우저, 앱처럼 사용자가 직접 만지는 쪽이 대부분 클라이언트가 됩니다. 반대로 서버는 그 요청을 처리하고 결과를 보내주는 쪽입니다.

    클라이언트와 서버의 관계는 식당에 비유하면 이해하기 쉽습니다. 손님이 메뉴를 주문하면 주방이 음식을 만들어 내보내는 구조와 비슷합니다. 손님이 클라이언트, 주방이 서버에 가깝습니다. 손님은 주방 안에서 어떤 순서로 조리되는지 몰라도 되고, 원하는 결과만 받으면 됩니다.

    클라이언트와 서버 관계 참고 이미지

    클라이언트와 서버 역할 정리

    구분 하는 일 예시 핵심 포인트
    클라이언트 서버에 요청을 보냄 웹브라우저, 스마트폰 앱, PC 사용자가 직접 조작하는 쪽
    서버 요청을 처리하고 응답함 웹서버, NAS, 홈서버, DB 서버 서비스를 제공하는 쪽
    네트워크 요청과 응답이 오가는 통로 인터넷, 공유기, 내부망 둘 사이를 연결함

    이 관계를 이해하면 웹사이트 접속도 다르게 보입니다. 브라우저 주소창에 주소를 입력하면 브라우저가 서버에 페이지를 요청하고, 서버는 HTML, 이미지, 데이터 등을 다시 보내줍니다. 우리는 화면만 보지만, 뒤에서는 요청과 응답이 계속 오가고 있습니다.

    서버는 역할에 따라 이름이 달라집니다

    서버라는 단어 앞에 붙는 말은 대부분 “무엇을 제공하느냐”를 뜻합니다. 파일을 제공하면 파일 서버, 웹페이지를 제공하면 웹서버, 데이터를 저장하고 조회해주면 데이터베이스 서버라고 부릅니다.

    홈서버를 만들 때 자주 만나는 것도 이런 구조입니다. 사진과 문서를 보관하면 파일 서버처럼 쓰고, Jellyfin 같은 서비스를 올리면 미디어 서버가 됩니다. Nginx나 Caddy를 앞단에 두면 외부 접속을 정리해주는 리버스 프록시 서버 역할도 맡길 수 있습니다.

    헷갈리기 쉬운 부분도 있습니다. 한 대의 컴퓨터가 하나의 서버 역할만 하는 것은 아닙니다. 한 장비 안에서 여러 서버 프로그램이 동시에 실행될 수 있습니다. 그래서 “서버 한 대”라고 말할 때는 물리 장비를 뜻할 수도 있고, 특정 서비스를 뜻할 수도 있습니다. 문맥을 함께 봐야 합니다.

    홈서버와 네트워크 참고 이미지

    홈서버 관점에서 보면 더 쉬워집니다

    홈서버를 기준으로 생각하면 서버 개념이 훨씬 손에 잡힙니다. 집 안에 켜둔 작은 PC가 있고, 거기에 파일 공유 서비스를 올려둔다고 해보겠습니다. 이때 노트북이나 스마트폰은 클라이언트가 되고, 그 작은 PC는 서버가 됩니다.

    외부에서 접속하려면 공유기, 포트, 도메인, SSL 인증서 같은 요소도 함께 등장합니다. 처음에는 복잡해 보이지만 기본 구조는 변하지 않습니다. 결국 핵심은 클라이언트가 요청하고, 서버가 응답한다는 흐름입니다.

    서버를 공부할 때 장비 스펙부터 외우기보다 이 관계를 먼저 잡아두면 이후 개념이 덜 흔들립니다. NAS, 웹서버, DB 서버, 리버스 프록시가 서로 다르게 보여도 바탕에는 같은 구조가 깔려 있습니다. 홈서버를 하나씩 구성해보는 과정도 결국 이 흐름을 직접 확인하는 데서 시작됩니다.

  • NAS란 무엇인가 홈서버에서 필요한 이유와 역할

    NAS란 무엇인가 홈서버에서 필요한 이유와 역할

    홈서버를 이야기하다 보면 결국 한 번은 NAS로 넘어오게 됩니다. 처음에는 파일 저장용 장비 정도로 보이지만, 실제로 구조를 잡아보면 홈서버의 데이터를 오래 보관하는 중심축에 가깝습니다.

    Rocky Linux 9.x에서 Docker Compose v2로 서비스를 올리고, 별도 저장소로 Synology DSM 계열 NAS나 S3 호환 스토리지인 MinIO를 함께 두는 구성을 생각해볼 수 있습니다. 제품이나 OS가 달라도 NAS가 맡는 역할 자체는 크게 달라지지 않습니다.

    홈서버와 네트워크 저장소를 떠올리게 하는 장비 이미지

    NAS를 한 줄로 정리하면

    NAS는 Network Attached Storage의 줄임말입니다. 말 그대로 네트워크에 연결해서 쓰는 저장소입니다.

    외장하드는 PC에 직접 꽂아야 하고, 클라우드는 외부 서비스 업체의 저장 공간을 빌려 쓰는 방식입니다. NAS는 집이나 사무실 네트워크 안에 저장소를 두고, 여러 기기에서 접속해 파일을 읽고 쓰는 구조에 가깝습니다.

    그래서 NAS를 단순한 하드디스크 박스로만 보면 부족합니다. 요즘 NAS는 파일 공유뿐 아니라 백업, 미디어 서버, 사진 정리, Docker 서비스, CCTV 저장, 개인 클라우드 역할까지 함께 맡는 경우가 많습니다.

    홈서버에서 NAS가 필요한 이유

    홈서버를 처음 만들 때는 서버 한 대에 모든 것을 넣어도 됩니다. 웹 서비스, DB, 파일 저장을 같은 디스크에서 처리하는 방식입니다. 테스트용이라면 이 구성이 가장 빠르고 단순합니다.

    문제는 시간이 지나면서 나타납니다. 서비스는 다시 설치할 수 있지만, 사진, 문서, 백업 파일은 사라지면 곤란합니다. 이때 연산을 담당하는 서버와 데이터를 보관하는 저장소를 분리하는 관점이 필요해집니다.

    NAS는 이 분리의 출발점입니다. 서버가 고장 나거나 OS를 다시 설치해야 하는 상황에서도 데이터 저장 위치가 따로 있으면 복구가 훨씬 수월합니다. 홈서버를 취미로 운영하더라도 이 차이는 꽤 크게 느껴집니다.

    NAS와 다른 저장 방식 비교

    홈서버에서 NAS를 고민할 때는 보통 외장하드, 클라우드 스토리지, 미니PC 내부 디스크와 비교하게 됩니다. 각각 장단점이 뚜렷하기 때문에 목적에 맞춰 보는 편이 좋습니다.

    항목 NAS 외장하드 클라우드 스토리지 서버 내부 디스크
    접근 방식 네트워크 접속 USB 직접 연결 인터넷 접속 서버 내부 경로
    여러 기기 사용 좋음 불편함 좋음 설정 필요
    초기 비용 중간~높음 낮음 낮음 낮음~중간
    장기 비용 전기요금·디스크 비용 디스크 비용 월 구독료 디스크 비용
    백업 구성 RAID·스냅샷 가능 수동 백업 위주 서비스 정책 의존 직접 구성
    홈서버 궁합 좋음 제한적 보조용 적합 단순 구성에 적합

    NAS가 항상 정답은 아닙니다. 파일이 적고 한 대의 PC에서만 쓴다면 외장하드가 더 현실적일 수 있습니다. 반대로 가족 사진, 문서, 미디어 파일, 서버 백업이 계속 쌓인다면 NAS 쪽이 관리하기 편해집니다.

    NAS가 홈서버에서 맡는 역할

    NAS의 가장 기본적인 역할은 파일 공유입니다. SMB, NFS 같은 방식으로 PC, 노트북, 서버가 같은 저장소를 바라보게 만들 수 있습니다. 윈도우에서는 네트워크 드라이브처럼 연결하고, 리눅스 서버에서는 마운트해서 쓰는 방식이 흔합니다.

    여기에 백업이 붙으면 활용도가 더 올라갑니다. 홈서버의 설정 파일, Docker 볼륨, 데이터베이스 덤프를 NAS로 주기적으로 보내두면 서버 장애가 나도 다시 시작하기가 수월합니다. 다만 핵심은 NAS도 백업 대상이지, 백업의 전부는 아니라는 점입니다.

    RAID를 구성했다고 해서 백업이 끝난 것은 아닙니다. RAID는 디스크 하나가 고장 났을 때 버티기 위한 장치에 가깝습니다. 실수로 삭제한 파일, 랜섬웨어, 장비 자체 고장까지 막아주지는 못합니다. 중요한 자료라면 외부 디스크나 클라우드에 한 번 더 복사해두는 편이 낫습니다.

    데이터 저장과 백업을 연상시키는 저장 장치 이미지

    NAS가 필요한 경우와 아닌 경우

    NAS가 필요한지 판단할 때는 장비 욕심보다 데이터 흐름을 먼저 보는 것이 좋습니다. 집 안 여러 기기에서 같은 파일을 보고, 서버 백업을 따로 보관하고 싶고, 사진이나 영상이 계속 늘어난다면 NAS는 자연스러운 선택입니다.

    반대로 Docker 몇 개를 올려보는 정도라면 처음부터 NAS를 살 필요는 없습니다. 미니PC 내부 SSD나 외장 SSD로 시작해도 충분합니다. 이후 데이터가 늘어나고, 백업 주기가 생기고, 가족이나 여러 기기에서 함께 접근해야 할 때 NAS를 붙여도 늦지 않습니다.

    정리해두면 좋은 기준

    NAS는 홈서버에서 화려한 주인공이라기보다, 데이터를 안정적으로 붙잡아주는 장비에 가깝습니다. 웹 서비스나 컨테이너는 다시 올릴 수 있지만, 쌓아둔 파일과 백업은 그렇지 않습니다.

    처음부터 큰 장비를 사기보다 내가 지켜야 할 데이터가 무엇인지, 그 데이터를 어느 기기에서 얼마나 자주 쓰는지부터 보는 편이 낫습니다. 홈서버를 오래 운영할 생각이라면 NAS는 단순 저장소가 아니라 운영 구조를 안정적으로 만드는 한 축으로 보는 것이 맞습니다.

  • 리눅스 종류 비교와 홈서버 배포판 선택 기준

    리눅스 종류 비교와 홈서버 배포판 선택 기준

    홈서버에서는 안정성이 먼저입니다

    홈서버를 처음 구성할 때 생각보다 오래 고민하게 되는 부분이 리눅스 배포판 선택입니다. 화면은 비슷해 보여도 업데이트 방식, 패키지 버전, 지원 기간이 달라서 운영 습관까지 달라집니다.

    홈서버는 한 번 설치하고 끝나는 환경보다, 몇 달씩 켜두면서 조금씩 손보는 경우가 많습니다. 그래서 저는 최신 기능보다 업데이트 부담이 적고 오래 관리하기 쉬운 배포판을 먼저 봅니다.

    서버와 리눅스 환경을 떠올리게 하는 작업 이미지

    Ubuntu Server는 자료가 많아 입문자가 접근하기 편합니다. 공식 페이지 기준 서버 LTS는 Ubuntu 26.04 LTS이며, LTS는 기본 5년 보안 및 유지보수 업데이트를 제공합니다. Docker, Nginx, Tailscale, Samba 같은 홈서버 조합도 검색 사례가 많습니다.

    Debian은 조금 더 조용한 성격입니다. 공식 릴리스 페이지 기준 현재 stable은 Debian 13 trixie입니다. 패키지가 빠르게 바뀌는 느낌은 덜하지만, 그만큼 장기 운영 서버로 쓰기에는 부담이 적습니다.

    리눅스 배포판은 계열로 보면 쉽습니다

    리눅스 종류를 볼 때는 이름만 외우기보다 계열을 먼저 보는 편이 이해하기 쉽습니다. Ubuntu와 Debian은 DEB 계열, Rocky Linux와 Fedora는 RPM 계열로 묶어 볼 수 있습니다. 계열이 다르면 패키지 설치 명령, 저장소 관리 방식, 운영 습관도 달라집니다.

    개발과 서버 관리 분위기의 노트북 작업 이미지

    홈서버 후보로 자주 언급되는 배포판을 장단점 기준으로 정리하면 다음과 같습니다.

    배포판 장점 단점
    Ubuntu Server 자료가 많고 Docker, 홈서버 예제가 풍부합니다. LTS 지원 덕분에 입문용으로 무난합니다. Snap 관련 호불호가 있고, 가볍게 쓰려면 일부 설정을 손볼 수 있습니다.
    Debian 구조가 단순하고 안정적입니다. 장기 운영 서버에 잘 맞습니다. 패키지 버전이 보수적이라 최신 기능을 바로 쓰고 싶을 때 답답할 수 있습니다.
    Rocky Linux RHEL 계열에 익숙한 사람에게 편합니다. 기업 서버 방식을 연습하기 좋습니다. Ubuntu나 Debian보다 홈서버 초보 자료는 상대적으로 적게 느껴질 수 있습니다.
    Fedora Server 새 커널과 패키지를 빨리 접할 수 있습니다. 최신 기술 테스트에 좋습니다. 릴리스 주기가 짧아 장기 방치형 홈서버에는 관리 부담이 있습니다.
    Arch Linux 필요한 것만 직접 구성하기 좋고 문서가 강합니다. 학습용 홈랩에 재미가 있습니다. 롤링 릴리스라 업데이트 후 점검을 꾸준히 해야 합니다.

    처음 구성한다면 Ubuntu나 Debian이 편합니다

    홈서버 첫 설치라면 Ubuntu Server LTSDebian stable 중에서 고르는 편이 덜 피곤합니다. 둘 다 Docker Compose 기반으로 서비스를 올리기 쉽고, 문제가 생겼을 때 검색으로 해결할 가능성도 높습니다.

    Fedora Server는 공식 다운로드 페이지 기준 Fedora Server 44가 안내되고, 릴리스 날짜는 2026년 4월 28일로 표시됩니다. 빠른 업데이트가 장점인 만큼 새 기능을 시험하는 별도 장비나 VM에 더 잘 어울립니다. 운영 중인 NAS나 가족이 함께 쓰는 서비스라면 조금 더 신중하게 보는 편이 좋습니다.

    용도별로 고르면 선택이 단순해집니다

    홈서버 용도에 따라 배포판 선택 기준도 달라집니다. 파일 공유, 사진 백업, 미디어 서버처럼 오래 켜둘 서비스는 안정성이 중요합니다. 반대로 쿠버네티스나 최신 런타임 테스트처럼 실험 성격이 강하면 최신성이 더 중요합니다.

    리눅스와 서버 구성을 떠올리게 하는 데스크 작업 이미지
    용도 어울리는 배포판 이유
    Docker 홈서버 입문 Ubuntu Server LTS 자료가 많고 설치 흐름이 익숙합니다.
    NAS, 백업 서버 Debian stable 변화가 적고 장기 운영에 편합니다.
    RHEL 계열 학습 Rocky Linux dnf, SELinux, RHEL 계열 운영 감각을 익히기 좋습니다.
    최신 패키지 테스트 Fedora Server 새 기능 반영이 빠릅니다.
    리눅스 깊게 공부 Arch Linux 직접 구성하는 과정에서 배우는 게 많습니다.

    결론은 관리 가능한 배포판입니다

    홈서버에서는 멋진 배포판을 고르는 일보다, 나중에 내가 계속 관리할 수 있는 환경을 고르는 일이 더 중요합니다. 처음이면 Ubuntu Server LTS, 조용히 오래 굴릴 생각이면 Debian stable, 서버 운영 방식까지 연습하고 싶다면 Rocky Linux 쪽이 무난합니다.

    버전과 지원 기간은 바뀔 수 있으니 설치 직전에는 공식 다운로드 페이지를 한 번 더 확인하는 게 좋습니다. 특히 장기 운영할 서버라면 ISO를 받기 전에 릴리스 날짜, 지원 종료일, ARM 지원 여부를 함께 확인해두면 이후 관리가 훨씬 편해집니다.

  • SSH란 무엇인가 홈서버 보안과 기본 포트 변경 이유

    SSH란 무엇인가 홈서버 보안과 기본 포트 변경 이유

    내 환경 기준

    제가 홈서버에서 SSH를 다룰 때 기준으로 보는 환경은 Rocky Linux 9.x, Docker + Compose v2, Oracle Cloud Free Tier ARM 인스턴스입니다. NAS는 Synology DSM 7.x 계열을 함께 쓰는 경우가 많습니다. SSH의 기본 개념은 운영체제가 달라도 비슷하지만, 설정 파일 위치나 방화벽 명령은 환경에 따라 달라질 수 있습니다.

    SSH 터미널 아이콘

    SSH는 서버에 접속하는 안전한 통로입니다

    SSH는 Secure Shell의 줄임말입니다. 내 컴퓨터에서 원격 서버에 접속해 명령어를 실행할 수 있게 해주는 보안 접속 방식입니다. 홈서버를 운영하다 보면 서버에 모니터와 키보드를 매번 연결하지 않고, 노트북이나 데스크톱의 터미널에서 바로 관리하는 일이 많습니다. 이때 가장 기본적으로 쓰는 접속 방식이 SSH입니다.

    예를 들어 Rocky Linux 서버에 접속할 때는 보통 이런 형태로 입력합니다.

    ssh 사용자명@서버IP

    접속이 되면 로컬 터미널을 쓰는 것처럼 서버 안에서 파일을 확인하고, Docker 컨테이너를 재시작하고, 로그를 보거나 업데이트를 진행할 수 있습니다. 홈서버 운영에서는 사실상 기본 도구에 가깝습니다.

    비밀번호보다 키 인증을 먼저 생각합니다

    SSH 접속에는 비밀번호 로그인과 공개키 기반 인증 방식이 있습니다. 처음에는 비밀번호 로그인이 편해 보이지만, 외부 인터넷에 서버를 열어두면 무작위 로그인 시도가 들어오는 경우가 많습니다. 개인 홈서버라도 가능하면 SSH 키 인증을 사용하는 편이 낫습니다.

    키 인증은 내 PC에 개인키를 두고, 서버에는 공개키를 등록해 접속하는 방식입니다. 비밀번호를 계속 입력하는 방식보다 관리가 깔끔하고, 비밀번호 대입 공격에 대한 부담도 줄일 수 있습니다. 다만 개인키 파일을 아무 곳에나 복사해두거나 권한을 느슨하게 관리하면 효과가 떨어지므로, 키 파일 관리도 함께 신경 써야 합니다.

    기본 포트 22번을 바꾸는 이유

    SSH의 기본 포트는 22번입니다. 문제는 공격자나 자동화된 스캔 도구도 이 사실을 알고 있다는 점입니다. 서버를 인터넷에 공개하면 22번 포트로 접속을 시도하는 로그가 금방 쌓이는 경우가 많습니다. 실제로 홈서버를 열어두면 내가 접속하지 않은 시간에도 낯선 IP에서 로그인 시도가 찍히는 일을 어렵지 않게 볼 수 있습니다.

    물론 기본 포트를 바꾼다고 보안이 완성되는 것은 아닙니다. 포트 변경은 보안을 보장하는 설정이라기보다 노출을 줄이는 조치에 가깝습니다. 그래도 자동화된 무차별 대입 시도 중 상당수는 기본 포트부터 건드리기 때문에, 불필요한 로그와 공격 시도를 줄이는 데 도움이 됩니다.

    포트 변경은 보안의 시작입니다

    예를 들어 SSH 포트를 22번에서 2222번으로 바꾸면 접속 명령은 이렇게 달라집니다.

    ssh -p 2222 사용자명@서버IP

    Rocky Linux 9.x 기준으로는 보통 /etc/ssh/sshd_config 파일에서 Port 값을 조정합니다. 이후 sshd 서비스를 재시작하고, 방화벽에서도 새 포트를 열어줘야 합니다.

    여기서 중요한 점은 기존 22번 접속을 바로 끊지 않는 것입니다. 새 포트로 접속이 되는지 반드시 다른 터미널에서 먼저 확인해야 합니다. 원격 서버에서 SSH 설정을 잘못 바꾸면 스스로 접속 경로를 막는 상황이 생길 수 있습니다.

    같이 챙겨야 할 기본 설정

    SSH 보안을 생각한다면 포트 변경과 함께 root 직접 로그인을 막는 설정도 자주 적용합니다. 일반 사용자로 로그인한 뒤 필요한 경우 sudo를 사용하는 방식이 관리 측면에서 더 낫습니다. 비밀번호 로그인을 끄고 키 인증만 허용하는 방식도 많이 씁니다.

    다만 이런 설정은 접속 준비가 완전히 끝난 뒤 적용해야 합니다. 공개키 등록이 제대로 되지 않은 상태에서 비밀번호 로그인을 꺼버리면 접속이 막힐 수 있습니다. 직접 만질 수 있는 홈서버라면 복구가 비교적 쉽지만, 클라우드 인스턴스는 콘솔 접근 방법까지 미리 확인해두는 편이 안전합니다.

    홈서버에서 SSH를 다루는 기준

    SSH는 화려한 기능이라기보다 서버 운영의 기본 손잡이에 가깝습니다. 접속이 안정적이어야 업데이트를 하고, 장애가 났을 때 로그를 확인하고, Docker 서비스도 다시 올릴 수 있습니다. 그래서 홈서버를 처음 구성할 때 웹 서비스보다 먼저 SSH 접속 방식을 정리해두면 이후 관리가 훨씬 편해집니다.

    기본 포트 변경만으로 충분한 보안이 되는 것은 아닙니다. 하지만 키 인증, 방화벽 제한, root 로그인 차단과 함께 적용하면 의미 있는 기본 관리가 됩니다. SSH는 한 번 설정하고 잊는 기능이라기보다, 서버에 들어가는 첫 번째 문이라는 기준으로 다루는 것이 좋습니다.

  • 도커란 무엇인가 홈서버 초보자를 위한 쉬운 설명

    도커란 무엇인가 홈서버 초보자를 위한 쉬운 설명

    도커란 무엇인가 쉬운설명

    내 환경 기준

    Rocky Linux 9.x / Docker Engine / Docker Compose v2 / Oracle Cloud Free Tier ARM 또는 Synology DSM 홈서버 구성을 기준으로 정리했습니다. 이 글은 설치 명령어보다 도커가 무엇인지 이해하는 데 초점을 맞췄습니다.

    홈서버를 처음 만지다 보면 도커라는 말을 자주 보게 됩니다. Nextcloud, Jellyfin, Nginx Proxy Manager, Portainer 같은 서비스를 설치하려고 검색하면 거의 빠지지 않습니다. 처음에는 서버 안에 또 다른 서버를 만드는 것처럼 느껴질 수 있지만, 실제로는 프로그램을 실행하기 좋은 상태로 묶어서 올리는 방식에 가깝습니다.

    도커 개념 참고 이미지

    도커를 쉽게 말하면 프로그램 전용 실행 상자입니다. 일반적으로 프로그램을 설치하려면 운영체제에 맞는 패키지, 라이브러리, 설정 파일을 하나씩 맞춰야 합니다. 도커는 이런 실행 환경을 컨테이너라는 단위로 묶어 둡니다. 그래서 같은 이미지를 사용하면 제 노트북, 집 미니PC, 클라우드 서버에서도 비교적 비슷한 방식으로 서비스를 실행할 수 있습니다.

    여기서 이미지와 컨테이너를 구분하면 이해가 훨씬 쉬워집니다. 이미지는 실행 전의 설계도나 설치 파일에 가깝습니다. 컨테이너는 그 이미지를 실제로 실행한 상태입니다. 예를 들어 nginx 이미지를 내려받아 실행하면 nginx 컨테이너가 하나 만들어집니다. 이미지는 보관된 재료이고, 컨테이너는 지금 돌아가고 있는 서비스라고 보면 됩니다.

    홈서버에서 도커가 편한 이유는 서비스 정리와 복구가 단순해지기 때문입니다. 예전 방식처럼 여러 서비스를 운영체제에 직접 설치하면 설정 파일이 여기저기 흩어지고, 어떤 패키지를 수정했는지 나중에 추적하기 어렵습니다. 도커로 구성하면 서비스별로 컨테이너를 나눌 수 있고, 설정 파일과 데이터 저장 위치를 분리해 관리하기도 좋습니다.

    다만 도커가 모든 문제를 자동으로 해결해주지는 않습니다. 컨테이너 안에만 저장된 데이터는 컨테이너를 삭제할 때 함께 사라질 수 있습니다. 그래서 볼륨 설정이 중요합니다. 포트 충돌, 파일 권한, 네트워크 설정처럼 홈서버에서 자주 만나는 문제도 결국 직접 이해해야 합니다. 도커는 서버 관리를 편하게 해주는 도구이지, 서버 기본 개념을 완전히 건너뛰게 해주는 도구는 아닙니다.

    처음 배우는 단계라면 Docker Compose도 같이 보는 편이 좋습니다. 긴 실행 명령어를 매번 입력하는 대신 compose.yaml 파일에 서비스 이름, 이미지, 포트, 볼륨 같은 설정을 적어두고 실행하는 방식입니다. 홈서버에서는 여러 컨테이너를 함께 운영하는 경우가 많아서 Compose를 쓰면 현재 구성을 다시 확인하거나 다른 서버로 옮길 때 훨씬 편합니다.

    처음부터 여러 서비스를 한꺼번에 올리기보다는 nginx나 uptime-kuma처럼 비교적 단순한 컨테이너 하나부터 실행해보는 것을 권합니다. 실행하고, 중지하고, 로그를 확인하고, 볼륨을 연결해보는 과정을 한 번 거치면 도커가 어떤 흐름으로 움직이는지 감이 잡힙니다. 데이터가 중요한 서비스는 그 다음에 천천히 올려도 늦지 않습니다.

    도커를 이해하면 홈서버 구축에서 선택지가 넓어집니다. 운영체제에 직접 설치하는 방식보다 정리가 쉽고, 실패했을 때 다시 시도하기도 수월합니다. 대신 데이터 저장 위치와 백업 방식은 처음부터 신경 써야 합니다. 도커를 배운다는 것은 명령어 몇 개를 외우는 것보다, 내 서버에서 서비스를 어떻게 나누고 관리할지 감을 잡는 과정에 더 가깝습니다.