Synology NAS, Docker, VM, 원격접속과 홈서버를 설치 자체보다 데이터 보호, 성능병목, 보안경계와 장애복구 관점에서 다룹니다.
서브도메인을 내부 포트에 연결하는 것만으로 reverse proxy 설계가 끝나지 않는다. DNS, TLS termination, origin binding, WebSocket, access control, health check와 public/private 서비스 경계를 분리해 NAS의 ingress를 운영하는 방법을 설명한다.
Jellyfin 성능은 CPU 사양만으로 결정되지 않는다. Direct Play와 transcoding을 구분하고 media, config, cache와 transcode temporary data의 저장위치를 분리하면 NAS 부하와 백업량을 크게 줄일 수 있다. Synology에서 미디어 서버를 운영환경으로 설계하는 방법을 설명한다.
브라우저에서 VS Code를 쓰는 것보다 중요한 것은 code-server가 NAS에서 어떤 파일·Secret·Docker 권한을 갖는지다. Workspace, config, SSH/Git credential, Docker socket, reverse proxy와 backup 경계를 분리해 개발환경이 production control plane이 되는 위험을 줄이는 방법을 설명한다.
NAS에서 서비스 하나를 돌리기 위해 무조건 Windows VM을 만드는 것은 비용이 크다. Container와 VM의 격리수준, Windows 전용 프로그램, RAM·CPU·스토리지 I/O, snapshot과 장애영향을 기준으로 VMM 사용 여부를 판단하는 방법을 설명한다.
Tailscale은 NAS 관리접속을 인터넷에 직접 공개하지 않고 tailnet 안에서 연결할 수 있게 해준다. direct·relay 연결, DSM 7 outbound 제한, access control과 reverse proxy의 역할 차이를 이해해 관리용 접속과 공개서비스를 분리하는 방법을 설명한다.
Docker 운영에서 중요한 것은 컨테이너를 실행하는 법보다 컨테이너·이미지·설정·데이터의 수명을 분리하는 것이다. Synology Container Manager에서 Compose Project, bind mount, volume, secret, backup과 update 경계를 어떻게 설계해야 장애복구가 쉬워지는지 설명한다.
NAS가 느려졌다고 바로 상위 모델을 살 필요는 없다. CPU·RAM·디스크 I/O·네트워크·컨테이너·백업 복구시간을 분리해 실제 병목을 찾고, RAM·NVMe·네트워크 개선과 본체 교체 중 무엇이 필요한지 판단하는 방법을 정리했다.
NAS 초기설정의 핵심은 DSM 설치를 끝내는 것이 아니라 어떤 데이터가 어디에 있고 어떻게 복구될지를 먼저 결정하는 것이다. Storage Pool, Volume, Btrfs, Shared Folder, Snapshot, Backup과 서비스 배치까지 복구 관점에서 설계하는 순서를 설명한다.