[카테고리:] it

  • 홈서버 로컬 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 사진 저장소로 폰 용량 줄이는 동기화 방법

    폰 사진첩을 열 때마다 비슷한 장면이 몇 장씩 쌓여 있으면, 이제 사진도 단순한 추억이라기보다 관리해야 하는 데이터에 가깝다는 생각이 듭니다. 원본 사진과 영상 용량은 계속 커지고, 휴대폰 저장공간을 키우려면 기기 가격 부담도 같이 올라가니까요.

    NAS 사진 저장소 참고 이미지

    사진을 폰에만 두기 애매한 이유

    요즘 스마트폰 사진은 기본 화질만으로도 꽤 큽니다. 라이브포토, 4K 영상, 여행 사진까지 쌓이면 256GB도 생각보다 금방 차는 편이에요.

    폰에만 사진을 두면 가장 간단하긴 합니다. 다만 기기를 잃어버리거나 고장 났을 때 위험이 큽니다. 클라우드는 편하지만 용량이 늘어날수록 매달 비용이 붙고요. 그래서 사진을 오래 모으는 사람이라면 NAS를 개인 사진 저장소처럼 쓰는 방식도 한 번쯤 고민해볼 만합니다.

    최근에는 메모리와 저장장치 가격도 오르는 흐름이라는 이야기가 많습니다. 이게 모든 소비자 제품 가격에 바로 똑같이 반영된다고 보긴 어렵지만, 폰 저장공간을 무조건 큰 용량으로 해결하는 방식은 전보다 부담스럽게 느껴질 수 있어요.

    사진 백업과 저장공간 참고 이미지

    NAS에 원본을 두고 폰은 가볍게

    핵심은 단순합니다. 중요한 원본은 NAS에 올려두고, 폰에는 자주 보는 사진이나 필요한 파일만 남기는 방식입니다. NAS는 집에 두는 개인 서버처럼 쓰고, 밖에서는 앱으로 접속해 사진을 확인하는 구조에 가깝습니다.

    다만 NAS가 폰 안의 원본을 자동으로 저용량 사진으로 바꿔주는 기능이라고 보면 애매합니다. 보통은 원본을 NAS에 백업한 뒤, 폰에서는 필요 없는 원본을 정리하고 앱으로 다시 보는 방식에 가깝습니다.

    항목 폰에만 저장 일반 클라우드 NAS 사진 저장소
    초기 비용 낮음 낮음 높은 편
    월 비용 없음 용량별 발생 보통 없음
    원본 보관 기기 상태에 의존 서비스 정책에 의존 내 장비에 보관
    접근성 가장 빠름 편함 설정에 따라 다름
    용량 확장 새 폰 구매 요금제 변경 HDD 추가 또는 교체
    어울리는 사용 방식 가볍게 촬영 설정 없이 편하게 사용 사진을 오래 모으는 사람

    Synology Photos로 할 수 있는 것들

    시놀로지 NAS를 기준으로 보면 사진 관리 기능으로 Synology Photos를 많이 씁니다. 모바일 앱에서 사진과 영상을 NAS로 백업할 수 있고, 자동 백업을 켜두면 새로 찍은 사진도 업로드하는 방식으로 사용할 수 있습니다.

    공식 안내 기준으로는 자동 백업, 공유 링크, 앨범, 얼굴·사물 인식, 위치·태그 기반 정리 같은 기능을 제공합니다.

    참고: Synology Photos 공식 안내

    개인 사진 저장소 참고 이미지

    좋은 점은 사진을 폴더 구조로 볼 수도 있고, 시간순 타임라인으로 넘겨볼 수도 있다는 점입니다. 가족 사진처럼 같이 봐야 하는 자료는 공유 링크로 보낼 수 있고, 링크에 비밀번호나 만료일을 거는 방식도 안내되어 있습니다.

    다만 기능은 NAS 모델, DSM 버전, 앱 버전에 따라 조금씩 다를 수 있습니다. 특히 얼굴 인식이나 HEIC, HEVC 같은 포맷 처리는 환경을 타는 경우가 있어서, 처음부터 모든 게 매끄럽게 된다고 확답하긴 어렵습니다.

    처음 한 번은 차분히 설정하기

    큰 흐름은 어렵지 않습니다. NAS에 Synology Photos를 설치하고, 폰에 모바일 앱을 깐 뒤, 계정으로 로그인해서 백업 대상을 지정하면 됩니다. 이후 와이파이에서만 업로드할지, 모바일 데이터도 쓸지, 기존 사진까지 올릴지 같은 옵션을 정하면 되고요.

    여기서 중요한 건 백업 완료 여부를 확인한 뒤 폰 사진을 정리하는 것입니다. 원본이 NAS에 다 올라갔는지 확인하지 않고 폰에서 먼저 지우면 복구가 애매해질 수 있습니다. 처음에는 사진 몇십 장만 테스트로 올려보고, 앱에서 정상적으로 열리는지 확인하는 편이 낫습니다.

    NAS 동기화 참고 이미지

    폰 용량을 줄이고 싶다면 백업 후 자주 안 보는 원본 영상부터 정리하는 게 체감이 큽니다. 사진보다 영상이 훨씬 빠르게 공간을 차지하니까요. 자주 보는 사진은 폰에 남기고, 오래 보관할 원본은 NAS에서 보는 식으로 나누면 부담이 꽤 줄어듭니다.

    NAS도 백업의 끝은 아닙니다

    NAS에 넣었다고 완전히 끝난 건 아닙니다. 하드디스크도 고장 날 수 있고, 실수로 파일을 지울 수도 있습니다. 중요한 사진이라면 NAS 안에서도 RAID 구성이나 스냅샷, 외장하드 추가 백업, 다른 위치로의 백업을 같이 생각하는 게 좋습니다.

    시놀로지 쪽도 NAS 백업을 다른 위치로 확장하는 방식을 안내하고 있습니다. 사진이 정말 소중하다면 NAS 한 곳에만 원본을 두는 방식도 조금 불안할 수 있다고 보는 편이 현실적입니다.

    사진 보관과 백업 참고 이미지

    정리해보면

    사진을 많이 찍는 사람에게 NAS는 단순한 저장장치라기보다, 내 사진을 내 방식대로 쌓아두는 공간에 가깝습니다. 폰은 촬영과 가벼운 감상용으로 쓰고, 원본은 NAS에 모아두면 저장공간 관리가 훨씬 편해질 수 있습니다.

    물론 처음 비용과 설정 과정은 있습니다. 그래서 NAS가 무조건 정답이라기보다는, 사진 원본을 오래 보관하고 싶고 월 구독 비용을 줄이고 싶은 사람에게 잘 맞는 선택지로 보는 게 좋겠습니다.

  • 컴퓨터 가격 상승 이유 AI 수요와 메모리 부족 영향

    컴퓨터 가격 상승 이유 AI 수요와 메모리 부족 영향

    왜 요즘 견적이 무거워졌나

    책상 위에 부품 몇 개만 올려놓고 견적을 짜봐도 예전이랑 체감이 꽤 다릅니다. CPU나 그래픽카드만 보고 “왜 이렇게 비싸졌지?”라고 보기엔, 요즘은 메모리와 저장장치 쪽 부담이 생각보다 크게 들어오는 분위기예요.

    컴퓨터 부품 참고 이미지

    AI가 메모리를 많이 쓰는 시대

    요즘 컴퓨터 가격 이야기를 할 때 AI 수요를 빼놓기는 어렵습니다. 생성형 AI, 데이터센터, AI 서버 쪽에서 쓰는 메모리 수요가 늘면서 HBM, DRAM, NAND 같은 부품 가격 흐름에도 영향을 주는 것으로 보입니다.

    HBM은 고성능 AI 가속기 옆에 붙는 고대역폭 메모리라고 보면 됩니다. 일반 PC에 꽂는 DDR5 램과 같은 제품은 아니지만, 생산 투자와 물량 우선순위가 서버 쪽으로 기울면 소비자용 메모리 공급도 넉넉해지기 어렵습니다.

    그래서 요즘 조립 PC 견적을 보면 램 32GB, SSD 1TB 정도가 예전처럼 가볍게 넣는 옵션이라기보다, 전체 가격을 꽤 끌어올리는 요소로 느껴질 때가 있습니다.

    체감 가격이 올라가는 부분

    항목 일반 소비자 PC AI 서버·데이터센터
    주요 메모리 DDR4·DDR5 램 HBM·서버용 DRAM
    수요 흐름 게이밍, 작업용, 사무용 AI 학습, 추론, 클라우드
    가격 영향 램·SSD 업그레이드 부담 증가 고성능 메모리 물량 우선 확보
    소비자 체감 완제품 PC와 조립 견적 상승 직접 체감은 적지만 시장 전체에 영향

    예전에는 컴퓨터 가격이 비싸지면 그래픽카드부터 의심하는 경우가 많았습니다. 물론 GPU도 여전히 큰 비중을 차지합니다. 다만 최근에는 램과 SSD 가격까지 같이 버티는 느낌이라, 중급형 PC에서도 부담이 생깁니다.

    특히 입문형 노트북이나 사무용 데스크톱은 원래 가격 여유가 크지 않습니다. 이런 제품들은 메모리 단가가 조금만 올라가도 제조사가 가격을 올리거나, 같은 가격에 램 용량을 줄이는 식으로 조정할 가능성이 있어 보여요.

    램만이 아니라 SSD도 봐야 합니다

    컴퓨터를 살 때 메모리라고 하면 보통 램을 먼저 떠올리지만, 실제 견적에서는 SSD도 중요합니다. NAND 플래시 역시 데이터센터 수요와 연결되는 부품이라 저장장치 가격도 함께 흔들릴 수 있습니다.

    요즘은 게임 하나 용량도 커졌고, 영상 편집이나 사진 작업을 조금만 해도 512GB는 금방 답답해집니다. 그래서 1TB SSD를 기본처럼 생각하게 됐는데, 이 부분이 비싸지면 완제품 PC 가격에도 바로 반영될 수밖에 없습니다.

    컴퓨터 작업 환경 참고 이미지

    지금 PC를 맞춘다면

    지금 시점에서 무조건 기다리는 게 답이라고 말하긴 어렵습니다. 메모리 가격은 시장 상황에 따라 다시 내려갈 수도 있고, 반대로 한동안 높은 수준을 유지할 수도 있으니까요.

    다만 견적을 볼 때는 램 32GB와 SSD 1TB를 먼저 기준으로 잡고, 그다음 CPU와 그래픽카드를 맞추는 쪽이 현실적일 수 있습니다. 나중에 업그레이드하면 된다고 생각해도, 그때 부품 가격이 더 좋아질지는 확답하기 어렵습니다.

    완제품 PC나 노트북은 같은 모델이라도 시기별로 구성이 달라질 수 있습니다. 램 용량, SSD 용량, 업그레이드 가능 여부를 같이 확인하는 게 좋습니다. 특히 온보드 메모리 노트북은 나중에 램 추가가 안 되는 경우가 많아서 처음 선택이 더 중요해요.

    정리해두면 좋은 포인트

    요즘 컴퓨터 가격 상승은 단순히 “부품값이 올랐다” 정도로만 보기엔 조금 복잡합니다. AI 사용량이 늘면서 서버용 메모리 수요가 커졌고, 그 흐름이 소비자용 PC의 램과 SSD 가격에도 영향을 주는 쪽으로 이어지는 분위기입니다.

    그래서 당장 PC를 맞춘다면 최저가만 보기보다 메모리 용량, SSD 용량, 업그레이드 가능성을 같이 보는 편이 낫습니다. 가격이 언제 안정될지는 단정하기 어렵지만, 지금은 메모리 쪽이 전체 견적에서 꽤 중요한 변수로 올라온 건 분명해 보입니다.

    참고한 자료: IDC 관련 보도, Gartner 관련 보도, TechRadar 메모리·SSD 시장 보도

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

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

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

    서버 개념 참고 이미지

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

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

    예를 들어 집에서 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는 단순 저장소가 아니라 운영 구조를 안정적으로 만드는 한 축으로 보는 것이 맞습니다.

  • 기계식 키보드 장점과 개발자 선택 기준 정리

    기계식 키보드 장점과 개발자 선택 기준 정리

    책상 위 키보드 하나만 바꿔도 작업할 때의 분위기가 꽤 달라집니다. 요즘 키보드는 단순 입력 장치라기보다, 하루에 몇 시간씩 손이 닿는 작업 도구에 더 가깝게 느껴져요.

    블랙 그레이 톤의 기계식 키보드가 놓인 데스크 셋업

    기계식 키보드가 끌리는 이유

    기계식 키보드의 장점은 역시 타건감이 또렷하다는 점입니다.

    멤브레인 키보드처럼 눌렀는지 애매하게 느껴지는 경우가 상대적으로 적고, 키 하나하나가 따로 반응하는 감각이 있습니다. 글을 오래 쓰거나 코드를 자주 치는 사람이라면 이런 입력 피드백이 꽤 크게 다가올 수 있어요.

    물론 누구에게나 무조건 편하다고 보기는 어렵습니다. 손가락 힘, 타이핑 습관, 소음 민감도에 따라 만족도가 달라질 수 있습니다.

    사진처럼 블랙과 그레이 톤의 키보드는 데스크 셋업에도 자연스럽게 섞이는 편입니다. 화려한 RGB보다 은은한 백라이트 정도가 들어간 구성은 밤에 작업할 때도 부담이 덜해 보입니다.

    개발자들이 많이 쓰는 이유

    개발자들이 기계식 키보드를 많이 쓰는 이유는 단순히 멋 때문만은 아닌 것 같습니다.

    하루 종일 코드를 치고, 단축키를 누르고, 터미널을 오가다 보면 키보드의 반응성피로감 차이가 은근히 쌓입니다. 키압이 손에 잘 맞으면 손가락에 들어가는 힘이 줄어드는 느낌도 받을 수 있어요.

    반대로 키압이 너무 무겁거나 소리가 큰 축을 고르면 오히려 피곤할 수 있습니다. 그래서 개발자용 키보드라고 해서 특정 축 하나가 정답이라고 보긴 어렵고, 본인 작업 환경에 맞는 쪽을 찾는 게 더 현실적입니다.

    제품 유형 장점 단점
    기계식 키보드 타건감, 반응성, 스위치 선택 폭이 좋음 가격대가 높고 소음이 있을 수 있음
    멤브레인 키보드 조용하고 가격 부담이 적음 키감이 다소 밋밋하게 느껴질 수 있음
    저소음 기계식 키보드 사무실이나 밤 작업에 비교적 부담이 적음 일반 기계식 특유의 경쾌함은 줄어들 수 있음

    선택할 때 먼저 볼 부분

    기계식 키보드를 고를 때는 디자인보다 먼저 스위치 종류를 보는 게 좋습니다.

    청축은 소리가 크고 구분감이 강한 편이라 혼자 쓰는 공간에 잘 맞을 수 있습니다. 적축은 비교적 부드럽게 눌리는 느낌이라 장시간 타이핑에 무난하게 느껴질 수 있고, 갈축은 그 중간쯤으로 보는 경우가 많습니다.

    다만 같은 적축, 갈축이라고 해도 제조사와 제품 구조에 따라 느낌이 꽤 다릅니다. 보강판, 흡음재, 키캡 재질, 윤활 여부에 따라 소리와 감각이 달라져서 스펙만 보고 완전히 예상하기는 어렵습니다.

    처음부터 비싼 모델로 가기보다는, 본인이 원하는 조건을 먼저 좁혀보는 편이 좋아 보입니다.

    기준 확인할 내용 메모
    소음 집, 사무실, 카페 중 어디서 쓸지 공용 공간이면 저소음 계열이 편할 수 있음
    배열 풀배열, 텐키리스, 75%, 65% 숫자 입력이 많으면 풀배열도 고려
    연결 유선, 블루투스, 2.4GHz 여러 기기를 쓰면 무선 편의성 확인
    키압 가벼운 축, 무거운 축 손가락 피로감과 직접 연결됨
    키캡 ABS, PBT 등 오래 쓰면 촉감과 번들거림 차이가 날 수 있음

    오래 쓰는 도구로 보면 달라지는 점

    키보드는 한 번 사면 생각보다 오래 쓰는 제품입니다. 그래서 단순히 예쁜지보다 매일 쓰기 편한지가 더 중요합니다.

    개발이나 글쓰기처럼 입력량이 많은 작업을 한다면 기계식 키보드는 충분히 고려해볼 만한 선택지입니다. 다만 소음, 가격, 키압은 꼭 확인하는 게 좋습니다. 특히 사무실에서 쓸 예정이라면 타건음은 생각보다 민감한 요소가 될 수 있어요.

    처음 입문한다면 저소음 축이나 적축 계열처럼 부담이 덜한 쪽부터 경험해보는 것도 괜찮습니다. 기계식 키보드는 정답을 고르는 제품이라기보다, 자기 손에 맞는 감각을 찾아가는 취미에 가까운 느낌입니다.