맥미니를 홈서버·셀프호스팅 장비로 운영하는 데 필요한 셋업, 전력·발열, 소프트웨어 팁을 모읍니다.
Tududi 1.2.0은 직접 서버에 설치해 쓰는 할 일, 프로젝트, 메모, 영역 관리 도구다. 기본 설정은 단일 컨테이너와 SQLite라서 복잡한 데이터베이스를 따로 준비하지 않아도 시작할 수 있다. 계정 가입이 필요 없고, 사용 기록을 외부로 보내는 원격 측정도 없다. GitHub에서는 별 3천 개와 포크 213개를 기록했다. 이번 버전에는 프로젝트별로 켜고 끌 수 있는 칸반 보드, 목표 중심으로 일을 묶는 목표 기능, 오늘 화면의 인공지능 보조 기능, 긴급도와 중요도로 일을 나누는 아이젠하워 매트릭스, 연락처를 관리하는 사람 관리 기능이 추가됐다. 인공지능 보조 기능은 일일 요약, 할 일 분석, 프로젝트 분석을 보여주며 OpenAI API 키가 필요하지만 설정에서 끌 수 있다.
fin은 Jellyfin이나 Subsonic 계열 미디어 서버를 터미널에서 조작하는 도구다. Rust로 만들어졌고, 계속 켜 두고 쓰는 텍스트 화면 방식과 한 번 명령을 실행하는 방식 둘 다 지원한다. 로그인할 때 Navidrome, Airsonic, Gonic, Astiga 같은 서버 종류를 자동으로 알아낸다. 음악과 영상 보관함을 검색하고, 재생목록을 관리하며, 로컬 컴퓨터, 같은 네트워크의 Chromecast, Sonos·Kodi·Roon 연결 장치, 삼성·LG TV 같은 UPnP MediaRenderer로 재생을 보낼 수 있다. 로컬 음악 재생은 이제 mpv를 거치지 않고 fin 안에서 바로 처리된다. 원격 재생은 대기열을 만들 수 있고, 한 항목이 끝나면 클라이언트 쪽에서 다음 항목으로 자동 재생된다.
현재 구성은 HP EliteDesk 800 G5 Mini에 Proxmox를 올리고, 그 위에서 Home Assistant OS, AdGuard, 마인크래프트 서버, Docker LXC, Portainer, Twingate를 돌리는 형태다. 저장 장치는 TerraMaster F4-425 Plus NAS이며, 지금은 기본 운영체제인 TOS를 쓰고 있다. 새로 추가하려는 것은 Jellyfin 미디어 서버와 Radarr, Sonarr, Prowlarr, qBittorrent 같은 자동화 도구 묶음이다. 선택지는 두 가지다. 첫째, 남는 8기가바이트 메모리 2개를 써서 Proxmox 서버를 16기가바이트로 올리고, 미디어 관련 프로그램을 전부 그 서버에서 실행한다. 이 경우 NAS는 파일 보관만 맡는다. 둘째, NAS에 별도 SSD를 사서 TrueNAS Scale을 설치하고, 미디어 서버와 자동화 도구를 NAS에서 직접 실행한다. 핵심 걱정은 Proxmox 서버의 16기가바이트 메모리가 기존 서비스와 미디어 묶음을 함께 버틸 수 있는지, 그리고 NAS가 두 사람이 동시에 다른 영상을 볼 때 트랜스코딩을 감당할 수 있는지다.
File Orbit은 여러 대의 개인 서버나 저장장치가 서로 파일을 맞춰 볼 수 있게 하려는 파일 탐색기 프로젝트다. 이번 알파 단계에서 두 대의 컴퓨터에서 돌아가는 파일 탐색기 앱이 서로 동기화되는 데 성공했다. 구조는 AT Protocol 기반 파일 시스템과 IPFS를 함께 쓰는 P2P 방식이다. 목표는 Nextcloud 같은 개인 클라우드를 직접 운영하다가 홈 서버가 망가졌을 때 생기는 불편을 줄이고, 여러 NAS가 서로 연결되며 하나의 로그인으로 쓰이게 하는 것이다. 로그인과 데이터 소유권은 Personal Data Server 쪽에 두려는 방향이라, File Orbit 쪽 서버를 쓰기 싫은 사람은 BlueSky나 자신이 운영하는 Personal Data Server를 이용할 수 있다. 현재 설치 프로그램은 macOS와 Windows용이 있고, Linux 지원은 다음 순서다. 예전 이름은 substratum.cloud였지만 서비스형 사업 모델과 이름 문제를 피하려고 File Orbit으로 바꿨고, 기반 프로토콜 이름은 그대로 남겨 다른 사람이 채택하거나 갈라 만들어 직접 호스팅할 수 있게 하려는 뜻이 있다.
Authelia로 여러 사이트 로그인을 보호하고 있으며, 패스키와 TOTP를 설정해 사이트에는 2단계 인증을 요구하고 있다. 문제는 Authelia의 설정 화면이 아이디와 비밀번호만으로도 열리는 점이다. 설정에서는 `/settings` 경로에 `two_factor` 정책을 걸고, 높은 권한 세션에도 두 번째 인증을 요구하도록 해 두었지만 기대처럼 막히지 않는다. 새 사용자는 수동으로 추가할 계획이다. TOTP나 패스키를 새로 등록할 때도 기존 패스키나 TOTP 대신 이메일 일회용 비밀번호를 요구하는 점을 바꾸고 싶어 한다. 메모리가 제한된 환경이라 Authelia를 골랐고, Traefik을 리버스 프록시로 쓰며, CrowdSec으로 Authelia에 대한 무차별 대입 공격을 차단하고 있다.
Reticle은 집이나 사무실에서 운영하는 서버 구성을 그림으로 그리고, 그 그림 위에서 바로 상태를 확인하게 해주는 도구다. 개인 클라우드를 직접 운영하면 서버 구조도, 감시 화면, 명령어 창을 따로 오가게 되는데, Reticle은 이 문제를 줄이려 한다. 실제 서버, 서비스, 연결 관계를 넓은 캔버스에 배치하고, 각 항목은 SSH나 kubectl로 상태 확인을 실행한다. 문제가 생기면 해당 항목이 지도에서 빨간색으로 바뀐다. 전체 지도는 하나의 YAML 파일로 저장되어 변경 내용을 비교하기 쉽고, vim 같은 편집기에서 고치면 화면도 바로 갱신된다. 개인용 데스크톱 앱은 무료이며 MIT 라이선스로 공개되어 있고, Rust/Tauri로 만들어졌다. 유료 기능은 팀용 단일 실행 파일 형태로, 같은 화면을 내부 네트워크의 브라우저에서 열고 상태 확인을 24시간 실행하게 해준다.
가정용 프린터에 전용 이메일 주소를 만들면 가족이 휴대폰에서 파일을 더 쉽게 출력할 수 있다. 기존에는 내부 웹주소에 접속해 파일을 올리는 방식이었지만, 가족들이 그 주소를 저장하고 브라우저에서 파일을 고르는 일을 거의 하지 않았다. 새 방식은 개인 도메인의 print 주소로 온 메일을 Cloudflare Email Routing으로 우편함에 넣고, 필터가 전용 폴더로 옮기는 구조다. 집 안 서버의 작은 컨테이너가 IMAP으로 그 폴더를 확인한 뒤, 첨부된 피디에프나 이미지를 바로 출력한다. 워드 문서는 LibreOffice를 화면 없이 실행해 먼저 피디에프로 바꾼 다음 출력한다. 첨부파일이 없으면 이메일 본문 자체를 피디에프로 만들어 출력하므로 학교 안내문 같은 전달 메일도 처리된다. 출력은 CUPS를 통해 HP 레이저 프린터로 보내고, 처리된 메일은 Printed 폴더로 옮겨 재시작 뒤에도 같은 문서가 다시 출력되지 않게 하며, 보낸 사람에게 출력 완료 답장을 보낸다. 가장 중요한 안전장치는 보낸 사람 허용 목록이며, 허용되지 않은 주소는 기본적으로 거부해야 스팸이 종이로 출력되는 일을 막을 수 있다.
장애 알림이 울리면 사람이 로그, 최근 배포 내역, 대시보드, 서비스 상태를 하나씩 확인하느라 실제 원인 파악 전에 많은 시간을 쓴다. 기존 인공지능 사고 분석 도구들은 대부분 클라우드형 서비스라서 로그와 서버 정보를 외부 업체로 보내야 한다. 이 방식은 보안이나 회사 정책 때문에 받아들이기 어려운 곳이 많다. 제안된 방향은 오픈소스로 공개되는 자체 호스팅 도구다. 알림이 오면 자동 조사 프로그램이 로그를 모으고, 최근 배포를 확인하고, 컨테이너 상태를 보고, 여러 서비스의 증상을 연결해 대시보드에 진단을 올린다. 데이터는 자체 서버 안에 남고, 밖으로 나가는 것은 LLM API 호출뿐이다. 도구는 읽기 전용으로만 동작해 직접 고치지 않으며, 모든 진단 문장은 실제로 수집한 근거를 가리켜야 한다. 근거가 없는 내용은 추측으로 표시되고, 알림 출처 같은 연결부는 플러그인으로 붙일 수 있게 하려는 방향이다.
서버를 브라우저에서 관리하는 도구로 Guacamole, Termix, Nexterm을 써본 경험이 비교됐다. Guacamole은 설치와 유지 관리가 번거로웠다. Termix는 매우 유용했지만, 화면 구성이 크게 나빠져 계속 쓰기 힘들다는 평가를 받았다. Nexterm은 보기에는 좋지만, 이유 없이 서버 연결이 자주 끊겨 신뢰하기 어렵다는 문제가 있었다. 현재 필요한 기능은 SSH 접속뿐이며, Windows 원격 접속에 쓰는 RDP는 더 이상 필요하지 않다. 핵심 요구는 보기 편하고, 관리 부담이 작고, 서버 연결이 안정적인 SSH 중심 대안이다.
Papra 26.6.0은 개인이 직접 운영할 수 있는 문서 보관 서비스에 자동 태그 기능을 추가했다. Papra는 Paperless-ngx와 비슷한 오픈소스 문서 보관 도구이며, 더 현대적인 사용성과 쉬운 조작을 목표로 한다. 새 버전은 문서에서 내용을 뽑아낸 뒤 AI가 기존 태그 이름과 설명을 보고 알맞은 태그를 붙일 수 있다. 설정에 따라 필요한 새 태그를 자동으로 만들 수도 있다. 자동 태그에는 여러 LLM 제공자를 연결할 수 있어, 앞으로 다른 AI 기능에도 같은 구조를 쓸 수 있다. 문서 내용 추출과 OCR도 더 유연해져서, 문서 종류에 따라 Mistral OCR, Azure DI, Docling 같은 외부 엔진을 나눠 쓰거나 실패할 때 다른 엔진으로 넘길 수 있다.
중국에 머무는 동안 집에 있는 개인 컴퓨터나 서버를 VPN처럼 써서 휴대폰 인터넷 요청을 집으로 보낸 뒤, 집 인터넷을 통해 인스타그램 같은 서비스에 접속하려는 구상이다. 목적은 48시간 이동 중 가족과 연락하고 사진을 보내는 것이며, 라틴아메리카에서는 WhatsApp 같은 Meta 서비스 의존도가 높다는 점이 배경이다. 후보로 Tailscale, RustDesk, AnyDesk 같은 원격 접속 도구가 떠올랐지만, 정리된 답변에서는 Shadowsocks가 가장 나은 선택으로 보인다. VLESS/V2Ray도 대안으로 언급됐고, Tailscale은 작동할 수는 있지만 안정적이지 않다는 평가가 붙었다. 현지 법을 어기지 말라는 주의도 함께 강조됐다.
여러 자체 호스팅 노트 앱을 몇 주 동안 직접 써 본 결과, 설치 난이도보다 매일 쓰는 편집과 모바일 경험이 더 큰 문제로 드러났다. Obsidian은 VPS에서 돌리기 번거롭고, 로컬에서 Syncthing으로 맞춰 써도 편집 중 줄 선택이 어긋나거나 편집 화면과 미리보기 화면을 오가는 흐름이 불편했다. Anytype은 사용 방식은 익힐 수 있었지만, 데스크톱과 모바일 앱의 기능 차이가 컸고, 모바일에서 쿼리가 보이지 않거나 문단 들여쓰기 같은 기본 편집이 제대로 되지 않았다. Joplin은 Markdown 기반 편집과 웹뷰 방식이 맞지 않았고, 동기화도 즉시 되지 않아 5분마다 자동으로 맞추거나 직접 버튼을 눌러야 했다. SiYuan은 편집감이 가장 좋았지만, 모바일에서 브라우저로만 접근해야 해서 바로가기를 누를 때마다 새 탭이 열리는 문제가 있었다. Notesnook은 SiYuan만큼 편집 경험이 좋았지만, 8개가 넘는 컨테이너를 띄우고 여러 포트와 서브도메인을 설정해야 해서 부담이 컸다.
맥미니는 작은 로컬 인공지능 음성 생성 장비로 꽤 실용적으로 쓸 수 있다. 로컬 음성 모델에서는 중앙처리장치 성능보다 메모리와 모델 크기가 더 자주 한계가 된다. 기본형에 가까운 Apple Silicon 맥미니도 작은 모델은 돌릴 수 있지만, 기다리는 시간을 줄이고 선택지를 넓히려면 통합 메모리가 많은 구성이 유리하다. 이 용도는 짧은 한 줄을 즉시 뽑아내는 방식보다, 대본을 넣고 한 번에 초안을 만든 뒤 들으면서 어색한 부분만 고쳐 다시 생성하는 일괄 처리 흐름에 더 잘 맞는다. 로컬 음성 생성은 최종 홍보 영상처럼 아주 매끈한 결과를 만들 때는 클라우드 도구보다 부족할 수 있다. 대신 유튜브 초안, 강의 내레이션, 오디오북식 검토, 개인 문서, 임시 대사처럼 여러 번 고쳐 보는 작업에서는 사용량 요금이나 크레딧을 신경 쓰지 않아도 되는 점이 장점이다. 앱 자체는 작아도 모델 파일 때문에 저장 공간을 생각보다 많이 쓸 수 있다.
Portabase가 이제 도커 볼륨 백업과 복원을 지원한다. Portabase는 직접 서버를 운영하는 사람이 자신의 환경에 설치해 쓰는 오픈소스 백업·복원 도구이며, PostgreSQL, MariaDB, MongoDB, Redis 등 9개 데이터베이스를 이미 지원한다. 이번 확장은 직접 운영하는 앱의 중요한 데이터가 데이터베이스에만 있지 않기 때문에 추가됐다. 워드프레스 업로드 파일, Nextcloud 사용자 파일, 미디어 보관함, 앱 설정 파일처럼 도커 볼륨 안에 남는 데이터도 백업 대상이 된다. 구조는 중앙 서버가 전체를 관리하고, 가벼운 에이전트가 실제 서비스 가까이에서 작업하는 방식이다. Portabase는 백업과 복원을 더 단순하고 안정적으로 운영하는 것을 목표로 한다. 현재는 도커 볼륨 백업이 실제 문제를 해결하는지, 어떤 복원 흐름이 필요한지, 어떤 도커 연동이 유용한지, 초기에 처리해야 할 예외 상황이 무엇인지 피드백을 받고 있다.
사무실에 남아 있는 맥북 에어 M2 4대, 각 16기가바이트 메모리를 묶어 대형 언어 모델 추론에 쓰려는 구성이다. 목표는 썬더볼트 4 연결을 고리처럼 이어 여러 대를 하나의 분산 노드처럼 쓰는 것이다. 이미 exo-explore/exo로 시험했지만, Qwen 2.5/3.5 9B 4비트 모델에서 생성 속도가 초당 6~8토큰보다 낮아 실사용에는 느렸다. 다음 구상은 vllm-metal에서 입력을 미리 처리하는 노드와 답변 생성을 맡는 노드를 나누고, LMCache를 함께 써서 여러 M2 기기가 KV 캐시 저장소 역할을 하게 하는 방식이다. 핵심 쟁점은 vllm-metal이 애플 실리콘 여러 대에서 텐서 병렬 처리나 파이프라인 병렬 처리를 실제로 안정적으로 지원하는지다. 현재 문서상으로는 mx.distributed를 통한 맥 간 집합 통신이 아직 실험적이거나 개발 중인 상태로 보인다. 또 LMCache가 vllm-metal과 자연스럽게 붙어 분산 KV 캐시 계층을 만들고 속도를 끌어올릴 수 있는지도 불확실하다.
대출 중개 사업을 운영하는 창업자는 Notion 컨설턴트 여러 명에게 비용을 쓰고, 맥미니를 사고, n8n과 AI 에이전트로 업무 자동화를 준비했다. 사업은 한 달에 약 30건의 거래를 처리했고, 그중 8~10건에 자금을 연결했으며, 수익은 약 2만5천 달러 수준이었다. 문제는 모든 거래가 여전히 창업자 본인을 거쳐야 했다는 점이다. intake, 즉 처음 들어오는 신청과 문의를 자동화하려 했지만, 업무 흐름이 먼저 정리되지 않으면 자동화는 문제를 없애지 않고 더 빠르게 반복한다. 정돈된 절차는 자동화했을 때 돈과 시간을 아껴 주지만, 엉킨 절차는 하루에 수백 번씩 같은 혼란을 만들어 낸다. 먼저 사람이 처음부터 끝까지 따라 할 수 있는 하나의 깨끗한 절차를 만들고, 그 다음에 자동화해야 한다는 결론이다.
개인용 메시 네트워크를 다루는 4부작 중 두 번째 주제는 실제 인터넷 환경에서 원격 접속이 왜 자주 막히는가이다. 집 밖에서 내 서버나 셀프호스팅 서비스를 열려고 하면 방화벽이 연결을 막고, 공유기가 기기를 밖에서 바로 보이지 않게 만들 수 있다. 통신사가 쓰는 Carrier-Grade NAT는 여러 사용자가 같은 공인 주소를 나눠 쓰게 해, 바깥에서 집 안 기기로 들어오는 연결을 더 어렵게 만든다. 이런 제한이 있어도 오버레이 네트워크는 상황에 맞춰 다른 길을 찾으며 연결을 유지하려고 한다. 핵심은 이론상 깔끔한 네트워크 구조가 현실의 복잡한 인터넷 조건에서 어떻게 버티는지를 이해하는 것이다.
Plotix는 서버나 기기에서 숫자 데이터를 보내면 웹 화면에서 그래프로 보여주는 직접 운영형 도구다. 예를 들어 `curl` 명령으로 중앙처리장치 60, 그래픽처리장치 45 같은 값을 `localhost:8080/computer-temps` 주소로 보내면, Plotix가 그 값을 그래프로 만든다. 사용자는 그래프 화면을 여러 방식으로 꾸밀 수 있다. GitHub 저장소에는 설명서와 Docker Compose 실행 예시가 제공된다. 처음에는 후원자 수 같은 개인 지표를 보기 위해 만든 도구였고, 최근 이틀 동안 다시 디자인해 공개용으로 되살렸다. 수요가 적으면 프로젝트가 중단될 수도 있다.
2018년형 Mac mini를 리눅스 서버로 쓰려는 경우, t2linux가 꼭 필요한지는 쓰는 기능에 따라 달라진다. 최신 리눅스 배포판은 T2 칩이 들어간 Mac을 어느 정도 지원하지만, 키보드, 블루투스, 와이파이 같은 장치를 제대로 쓰려면 커널 패치가 필요할 수 있다. 서버 용도라면 이런 장치를 거의 쓰지 않을 수 있다. 핵심으로 필요한 기능이 Thunderbolt와 Ethernet이라면, 별도 t2linux 커널 없이 일반 업스트림 커널만으로 충분할 가능성이 있다. t2linux 지원 목록에서도 많은 기능이 이미 업스트림에 들어간 것으로 보인다.
Tome은 KOReader 사용자를 위한 자가 호스팅 전자책 도서관 서버다. BookLore 개발이 멈춘 뒤, 깔끔한 화면, 쉬운 책 정보 관리, 자세한 독서 기록을 함께 제공하려고 만들어졌다. 설정 화면에서 서버 주소와 API 키가 들어간 KOReader 플러그인을 내려받아 넣고 다시 시작하면 바로 연결된다. 기존 KOSync처럼 파일 해시로 책을 맞추지 않고 안정적인 고유 아이디를 써서, 책을 다시 내려받거나 책 정보를 고쳐도 독서 기록이 끊기지 않는다. 독서 시간, 읽은 쪽수, 사용한 기기, 연속 독서일, 히트맵, 읽는 속도, 책별 집중도, 완독 예상치를 기록하며 기존 KOReader 기록도 가져올 수 있다. 읽던 위치와 하이라이트를 양방향으로 동기화하고, EPUB와 CBZ를 읽는 웹 리더도 포함한다. Hardcover로 평점과 진행률을 한쪽 방향으로 보낼 수 있고, 만화와 라이트노벨용 시리즈 관리, OPDS, 책 정보 가져오기, 권한 역할, 대량 파일 가져오기용 받은 편지함도 제공한다. Python/FastAPI와 React로 만들었고 SQLite를 쓰며, 외부 서비스 없이 하나의 Docker 이미지로 실행된다.
초보자가 집이나 작은 사무실에서 직접 서버를 운영할 때 필요한 기본 도구를 다루는 무료 유튜브 강의 묶음이다. 각 강의는 따로 볼 수 있게 나뉘어 있어 필요한 주제만 골라 볼 수 있다. 네트워크 쪽은 pfSense 방화벽 설치, WAN/LAN 설정, 방화벽 규칙, DNS 설정을 다룬다. 직접 가진 장비에 VPN 서버를 세우는 방법도 포함되며, WireGuard와 OpenVPN을 이용해 외부 업체 없이 접속 통로를 만드는 흐름이다. 관리형 스위치에서 VLAN을 써서 사물인터넷 기기를 별도 네트워크로 분리하는 방법도 있다. 서비스 운영 쪽은 Docker의 컨테이너, Compose, 볼륨, 네트워크 기본기를 설명하고, Zabbix로 집 안 네트워크 장비를 감시하며 알림과 대시보드를 만드는 내용을 담는다. 윈도우 서버를 함께 쓰는 환경을 위한 SSH 설정, 그리고 홈랩이나 작은 사업장에 맞춘 3-2-1 백업 규칙과 실제 도구 선택도 포함된다. 모든 자료는 유튜브에서 무료로 볼 수 있고 유료 장벽은 없다.
클라우드에 의존하던 음성 비서를 없애고 Raspberry Pi 5 기반의 열린 하드웨어 단말인 Hoorii Stage를 OpenClaw로 돌리는 로컬 음성 환경이다. 음성 데이터는 외부 서버로 나가지 않고 집 안 네트워크 안에 머문다. 이 단말은 사람이 말한 명령을 의미 단위로 바꿔 Home Assistant에 바로 넘긴다. 열린 하드웨어라서 개인이 만든 자동화 스크립트와 템플릿 스위치에도 비교적 쉽게 연결됐다. Raspberry Pi 5 성능도 데스크톱 음성 단말로 쓰기에 빠르게 느껴진다. 남은 핵심 문제는 차고 문이나 스마트 도어록처럼 위험도가 높은 장치를 서버 쪽에서 어떻게 보호할지다. 검토 중인 한 방법은 Home Assistant에서 오래 쓰는 낮은 권한의 토큰을 만들고, 이 음성 단말이 민감한 장치에 직접 접근하지 못하게 막는 구조다.
Arr 스택과 Jellyfish 등을 설치하는 일은 비교적 쉬웠지만, 책과 만화를 자동으로 찾고 정리하는 구성은 만족스럽지 않았다. 이미 Usenet 제공업체와 인덱서를 갖춘 상태에서 Readarr를 써 봤고, 책 정보 출처를 api.bookinfo.pro로 바꿔 보기도 했다. 그래도 일부 책이 저자와 제대로 연결되지 않는 문제가 남았다. LazyLibrarian도 시험했지만, 책을 지운 뒤 같은 책을 다시 검색할 수 없는 문제가 있었다. 책과 만화 자동화를 안정적으로 운영하려면 어떤 도구와 안내서를 써야 하는지가 핵심 고민이다.
초보자가 셀프 호스팅을 시작할 때 쓸 만한 쉬운 관리 도구를 찾고 있다. 원하는 도구는 Runtipi나 Dokploy처럼 앱을 빠르게 올려 보고 관리할 수 있는 형태다. 목적은 모든 앱을 처음부터 오래 설정하는 것이 아니라, 흥미로운 저장소를 발견했을 때 몇 분 안에 실행해 보고 계속 쓸지 판단하는 것이다. 장비로는 Beelink SER8을 홈랩으로 쓸 계획이지만, 질문의 핵심은 특정 장비보다 초보자에게 편한 셀프 호스팅 관리자 선택이다.
홈 서버 구축은 장비를 먼저 늘리기보다, 왜 그렇게 구성했는지 적어 두는 일에서 시작할 수 있다. 서버 명령어는 나중에 다시 찾아 따라 할 수 있지만, 선택의 이유와 시행착오는 기록하지 않으면 금방 사라진다. 구성 예시는 작은 노드 3대로 Kubernetes 클러스터 하나를 만들고, 모든 노드에 Talos Linux를 설치하는 방식이다. Talos Linux는 SSH나 일반 셸 접속을 쓰지 않고, 설정 파일을 통해서만 관리한다. 역할은 제어 노드 1대와 작업 노드 2대로 나뉜다. 핵심은 노드를 다시 설치하는 방법보다, 그 구성을 선택한 이유를 남기는 것이다.
목표는 온라인 음악과 집에 저장한 음악을 한 화면에서 다루는 것이다. 재생 목록이 여러 앱에 흩어지지 않고, 집 안 여러 방의 스피커도 같은 화면에서 고르고 음량을 조절하려는 구성이다. 집 자동화 알림이 오면 음악을 잠시 끊을 수 있어야 한다. 차처럼 다른 기기에 연결된 스피커로도 같은 방식으로 음악을 보내고 싶어 한다. 현재는 한 장치에서 Home Assistant를 감독자 설치 방식으로 돌리고, 그 안에서 맞춤 Music Assistant 설치와 맞춤 plugin을 함께 쓰고 있다. 온라인 음악에서 노래를 요청하면 이 plugin이 Lidar와 통신한다. 전체 목표는 분명하지만, 구성 요소가 많아져서 튼튼하고 매끄럽게 동작하지 않는 상태다.
InkDrop은 직접 운영하는 만화·코믹스 서버에서 빠진 작품을 찾고 내려받기 흐름을 관리하는 자체 호스팅 도구다. 이름은 상용 메모 앱 Inkdrop과 관계가 없으며, 공개 전에 바뀔 수 있다. Kavita가 보관함과 읽기 앱 역할을 잘하지만, InkDrop은 그 앞단에서 필요한 작품 목록, 대기열, 내려받기, 가져오기, 실패 기록을 관리한다. 시리즈, 권, 필요한 항목, 대기 상태, 검색 시도, 내려받기, 가져오기, 제공처 상태, 기록, 사람이 직접 확인해야 하는 예외를 따로 추적한다. 화면 구성은 단순 스크립트 묶음보다 Sonarr, Radarr, Prowlarr 같은 자동화 앱에 가깝게 만들고 있다. 작품과 권 정보를 맞추는 데 ComicVine 자료를 쓰고, Kavita에 이미 있는 파일은 빠진 항목으로 보지 않는다. 검색은 미리 설정한 여러 출처를 순서대로 확인하는 방식이며, SLSKD 연동이 유용하게 쓰이고 있다. 내려받기는 상황에 따라 qBittorrent나 SABnzbd로 넘긴다.
MacBook M1 Max에 CalDigit TS5 Plus 도크를 오래 연결해 두면 SD 카드와 미니 SD 카드 슬롯이 멈추는 문제가 나타난다. 도크를 뺐다가 다시 연결하면 슬롯이 다시 작동하지만, 시간이 조금 지나면 같은 문제가 반복된다. 그래서 카드 작업은 도크 대신 맥에 있는 카드 리더기를 직접 쓰는 우회 방법을 쓰게 된다. 비슷한 인식 문제는 외장 드라이브에서도 생긴다. 전면 USB 포트에 한 드라이브를 꽂았다가 곧 다른 드라이브로 바꾸면 새 장치를 알아보지 못한다. 소프트웨어를 계속 최신 상태로 유지해도 문제가 해결되지 않았다.
Mac Mini M2 Pro를 가족용 저장 공간의 중심으로 쓰려는 상황이다. 가족 안에는 오래된 iMac도 있고, 앞으로 2~4년 안에 컴퓨터를 바꿀 가능성도 있다. 사진, 영상, 파일이 많아 큰 저장 공간이 필요하며, 과거에 메모리 카드 용량 문제를 겪은 경험 때문에 외장 하드도 비슷한 제한이 있는지 걱정하고 있다. 현재는 한 개짜리 하드디스크도 최대 40테라바이트 제품이 있고, 앞으로 Toshiba가 150테라바이트급 제품을 낼 가능성도 언급된다. 핵심 질문은 맥에서 외장 하드 한 개의 최대 용량을 따로 신경 써야 하는지, 아니면 연결 단자의 하위 호환성만 보면 되는지다.
AudioMuse-AI는 음악 파일을 직접 분석해 자동 재생목록을 만들어 주는 무료 오픈소스 프로그램이다. Jellyfin, Navidrome, Emby, Lyrion, Open Subsonic API를 지원하는 음악 서버와 함께 쓸 수 있다. Jellyfin 플러그인과 Navidrome 플러그인이 이미 제공되며, 앞으로 음성 명령을 위한 Music Assistant 제공자 플러그인도 계획되어 있다. Raspberry Pi 5 8GB와 빠른 저장장치 확장 보드를 붙인 환경에서 v2.4.0을 실행했을 때, 가장 부담이 큰 음악 분석 중에도 평균적으로 CPU와 메모리의 절반 정도를 사용했다. 순간 사용량이 올라가도 자원이 꽉 차지는 않아, 아주 무거운 서버가 아니어도 돌릴 수 있다는 점을 보여준다. 분석과 데이터는 자기 컴퓨터 안에서 처리되므로, 외부 서비스의 유료화나 접근 차단에 덜 묶인다.