왜 셀프 호스팅을 해야 하는가?

 (romanzipp.com)
17P by GN⁺ | ★ favorite | 댓글 1개
  • 개인 서비스의 셀프 호스팅을 통해 빅테크와 정부의 감시로부터 벗어나 프라이버시와 데이터 주권을 확보할 수 있음
  • 캘린더, 연락처, 위치 정보 등 민감한 개인 데이터는 생각보다 많은 정보를 노출하며, Google이나 Apple 같은 기업에 의존하지 않고 직접 관리할 필요가 있음
  • 기술 기업들이 이유 없이 계정을 잠그거나 프로토콜 대신 독점 API를 강요하는 상황에서, 표준 프로토콜 기반의 자체 서버 운영은 디지털 주권을 보장함
  • CalDAV/CardDAV 서버, 메일 서버, Home Assistant, RSS 리더, 위치 추적기 등 실용적인 셀프 호스팅 서비스와 구체적인 소프트웨어 옵션을 소개함
  • 초기 설정의 복잡함에도 불구하고, 장기적 관점에서 데이터 통제권과 서비스 안정성을 확보하는 것이 개인정보 보호와 기술적 자립에 중요함

왜 셀프호스팅을 선택해야 하는가

  • 최근 나의 Homelab 환경을 동료에게 공유하면서 “도대체 왜 직접 서버를 설치하고 컨테이너를 구성하며, 하드웨어에 많은 돈을 들여가며 번거롭게 운영하는가?”라는 질문을 받음
  • 이 질문을 계기로 셀프호스팅의 주요 동기들과 실제로 어떤 서비스를 셀프호스팅할 수 있는지 구체적으로 설명함

프라이버시

  • 프라이버시는 자동으로 주어지는 권리가 아니며, 싸워서 얻어야 하는 권리
  • 빅테크 기업들과 일부 정부(예: EU의 chat control)가 개인 생활 전반을 들여다보려는 시도 지속
  • 직접 서비스를 호스팅하면 감시 위험을 줄이거나 없앨 수 있지만, 이를 위해서는 기술적 지식이 필요함
  • 가족이나 지인에게 서비스 제공을 통해 그들도 데이터 독립성을 가질 수 있도록 도움 줄 수 있음

  • 캘린더 & 연락처

    • 캘린더는 생각보다 많은 정보를 노출함
      • 신원 정보 외에도 정기적인 만남, 가족, 동료, 기밀 비즈니스 미팅 정보
      • 의료 예약을 통한 건강 정보, 수면 및 운동 루틴
      • 법적 의무, 대출 일정이나 구독 같은 금융 정보
      • 시위 참석 일정을 통한 정치적 신념
      • 언제 연락 가능한지 파악해 신원 도용에 활용 가능
    • 연락처 데이터도 마찬가지로 민감함
      • 소셜 그래프와 메타데이터(검색 이력, 생성 날짜)를 통해 개인 정보 유추 가능
      • 예: 같은 성별, 이름만 있는 연락처가 갑자기 늘면 데이트 중이라고 추정, 치료사 연락처 생성은 정신과 방문을 의미
    • 대부분의 사람들은 소셜 그래프 데이터가 어디에 저장되는지 인식하지 못하며, 실제로는 Google, Apple, Samsung 등이 처리함
    • Apple의 Advanced Data Protection조차 캘린더와 연락처는 엔드투엔드 암호화되지 않음

  • 위치 정보

    • 수년 전 Android와 Google Maps 사용 시, Google 계정에서 수년간의 상세한 위치 기록을 발견함
      • 직접 활성화한 적 없는 기능이 자동으로 모든 이동과 방문을 지오코디네이트로 기록
    • 매력적이지만 두려운 경험이었으며, 데이터를 직접 통제하고 본인만 접근할 수 있기를 원함

  • 그 외

    • 데이터가 추적되는 모든 방법과 그에 대한 경각심을 가져야 하는 이유를 나열하는 것은 이 글의 범위를 넘어섬
    • 새로운 여정을 시작하도록 동기 부여하는 것이 목적

주권

  • 디지털 주권은 데이터를 통제하고, 데이터로 무엇을 할지 선택하며, 누구와 공유할지 제어하는 것을 의미

  • 계정 잠금 문제

    • 기술 기업들이 명백한 이유 없이 계정을 잠그는 사례가 계속 보고되며, 과거 Google에서 직접 경험함
    • 연락조차 불가능하거나 AI 챗봇에게 시달리는 거대 기술 기업의 자비에 의존하고 싶지 않음
    • 규제 당국이 기술 기업에게 실제 사람과 연락할 방법을 제공하도록 요구하지 않는 이유가 의문

  • 프로토콜과 표준

    • 프로토콜과 파일 표준을 선호함
      • "Gmail" API가 아닌 SMTP와 IMAP 사용 (오래되었지만 현재 최선이며, 새로운 JMAP 이니셔티브는 환영)
    • Microsoft 같은 빅테크는 AI-Copilot 통합 Office 365 소프트웨어 사용을 강요하며, 최근 Office 365 계정의 SMTP 접근을 비활성화함

무엇을 셀프 호스팅할 것인가

  • 하드웨어

    • enum.co라는 회사에서 근무하며, 디지털 주권을 중시하는 환경
    • 3대의 미니 서버로 구성된 고가용성 Kubernetes 클러스터 운영 중 (상사의 도움으로 설정)

  • 캘린더 & 연락처

    • 민감한 데이터이므로 자체 CalDAV/CardDAV 서버 호스팅 중
    • 서버 옵션:
      • Radicale: Python 기반, 기본 웹 UI, 단일 사용자만 지원, Apple 기기와 호환 안 됨
      • ⭐ 추천 Baïkal: PHP 기반, 활발한 개발, 고급 웹 UI, 다중 사용자 지원
      • DAViCal: PHP 기반, 시도하지 않음
      • Xandikos: Python 기반, 내장 인증 없음, 웹 UI 없음
      • Nextcloud: PHP 기반, 이미 사용 중이라면 괜찮지만 너무 무거움
    • 캘린더와 연락처 데이터를 의식한다는 것은 어떤 앱이 접근 권한을 가지고 있는지 검토하는 것도 포함

  • 메일

    • 자체 호스팅 메일 서버는 금기시되어 왔지만, 실제로는 그렇게 어렵지 않음
    • Stalwart나 Mailcow 같은 최근 솔루션이 개인 메일함 호스팅을 쉽게 만들어줌 (마케팅 메일이 아닌)
    • 집에서 호스팅하는 것은 권장하지 않음 (고정 IP 필요, 전체 인터넷에서 접근 가능해야 함)
    • 설정 단계:
      • 신뢰할 수 있는 호스팅 제공자 선택
      • 깨끗한 IP 주소 확보 (메일 블랙리스트 확인 후 반복)
      • 서버 설정 후 수신 가능 여부와 모든 프로토콜이 올바르게 구성되었는지 확인
      • internet.nl 온라인 테스트 도구로 검증
      • Google, Microsoft, Yahoo 주소로 메일 전송해 스팸 처리 여부 확인
      • DNS, DMARC, SPF, TLS 등 반복적으로 점검
    • 향후 상세한 블로그 포스트 작성 예정

  • 스마트 홈

    • 수년 전 Home Assistant 인스턴스를 호스팅하기 시작했으며, 당시에는 Apple Homekit으로 충분했지만 실험적으로 시작
    • 이후 많은 스마트 홈 회사들이 파산하거나, 클라우드 서비스를 종료하거나, 가격을 인상하거나, 무료 서비스를 유료화함
    • 몇 주 전 Philips Hue가 사용자에게 계정 생성을 강제한다는 소식을 듣고 Home Assistant가 빛을 발함
      • 이미 돈을 지불한 조명의 모든 기능을 사용하려면 계정이 필요
      • 스마트 홈 기기의 외부 네트워크 트래픽을 차단하는 방화벽 규칙을 항상 설정해왔음
      • 로컬 네트워크에서도 Philips Hue 앱 전용 기능(촛불 모방 애니메이션 등)을 사용할 수 없는 것으로 보임
      • 이 기능을 에뮬레이션하는 커뮤니티 플러그인이 있기를 바람
    • 로컬에서만 사용하는 기기를 위해 온라인 계정을 절대 생성하지 않을 것
    • 현재 에너지 사용량 추적에 빠져 있으며, 머신 비전을 통해 가스 미터의 에너지 사용량을 추적하는 Raspberry Pi + 카메라 장치를 개발할 계획

  • RSS 애그리게이터

    • RSS를 통해 많은 뉴스 사이트와 블로그를 구독 중이며, RSS 자체가 이미 탈중앙화되고 주권적임
    • 따라서 RSS 애그리게이터 셀프 호스팅은 선택 사항이며 마지막 단계
    • iPhone과 Mac에서 NetNewsWire 사용 중
      • 최고의 RSS 리더이며, 오픈 소스이고 훌륭한 사람들이 지원
      • FreshRSS와 네이티브 통합 제공
    • FreshRSS는 피드 애그리게이터로 필터링 등 더 많은 기능 제공
      • RSS 피드를 기본 제공하지 않는 소스도 구독 가능

  • 위치 추적기

    • dawarich 인스턴스 배포 (독일어로 "내가 거기 있었다"는 의미)
      • 지리적 위치 데이터를 수집하고 보는 서버
      • 현재 위치를 서버로 전송할 수 있는 다양한 모바일 앱 선택 가능
    • 사용 가능한 앱:
      • 공식 dawarich 앱: iOS 노치에 항상 내비게이션 아이콘 표시
      • Overland: 배터리 소모가 심함
      • ⭐ Owntracks: iOS에서 가장 잘 작동하지만 앱 설정이 매우 혼란스러움
      • PhoneTrack

아이디어 & 전망

  • 최근 홈랩을 재구성해 단일 대형 서버에서 3노드 Kubernetes 클러스터로 전환
    • 호스팅할 수 있는 애플리케이션 종류에서 훨씬 더 많은 유연성 확보
  • 살펴보고 싶은 앱과 도구 목록:
    • EteSync: 엔드투엔드 암호화된 CalDAV & CardDAV
    • AnyType: 자체 AnyType 서버 인스턴스 호스팅
    • Immich 또는 ente: iCloud 사진에서 셀프 호스팅으로 이동
    • Passbolt: 비밀번호 관리자 (Bitwarden은 선호하지 않음)
    • BirdNET: 마이크로 외부 조류 종 모니터링
    • penpot: Figma와 유사하지만 무료 & 오픈 소스
    • Habitica: 습관 관리자
    • vert: 파일 변환기
    • InvoiceShelf: 인보이스 관리자
  • selfh.st는 셀프 호스팅 가능한 애플리케이션을 찾을 수 있는 훌륭한 리소스
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 개인용 서비스를 직접 셀프 호스팅하는 것뿐만 아니라, 소프트웨어나 SaaS 소기업들도 더 직접적으로 호스팅하는 방식을 고민해볼 만하다고 말하고 싶음
    클라우드 벤더들이 복잡성과 스케일 때문에 본인들이 꼭 필요하다고 이야기하지만, 실제론 대부분의 소프트웨어 프로젝트나 사업에 그만한 필요가 없음
    예를 들어, NextJS 배포를 위해 굳이 Vercel이나 Netlify에 의존할 필요 없으며 Ubuntu가 깔린 VPS에 Nginx나 Caddy(내가 좋아함)를 띄우면 됨
    거의 90% 이상의 프로젝트는 다음과 같은 방법으로 직접 호스팅이 충분함

    • 보안이 잘된 VPS와 필수 보안 제어 적용(루트 로그인 비활성화, SSH키 기반 로그인 등)

    • Caddy/Nginx 같은 리버스 프록시 세팅으로 정적 파일 혹은 웹사이트 서빙 가능, 하루에 수백만 요청이 아니라면 CDN도 안 써도 됨

    • Supervisor나 systemd로 백엔드/API 구동

    • 같은 리버스 프록시가 백엔드·다른 서비스들에도 프록싱 가능

    • 직접 mysql/postgres 데이터베이스를 돌리고 보안 세팅 적용

    • 백업 스크립트/크론으로 모든 백업이 가능하며, 정기적으로 테스트 필요

    • DOS/DDOS 방지하려면 Cloudflare 레이어 추가 가능
      최종적으로는 Cloudflare/DNS→Reverse Proxy(Caddy/Nginx)→앱으로 구성됨
      배포는 git pull로도 대부분 충분하고, 필요하면 추가 빌드도 가능
      도커나 컨테이너도 필수는 아님, 소규모~중규모 프로젝트면 없어도 무방
      어렵다고 생각할 수 있지만 실제로는 생각만큼 어렵지 않음, 대부분의 프로젝트는 대규모 웹스케일 필요 없음

    • 내게 가장 불안한 점은 전체 OS(커널, 유저랜드 포함)를 관리할 때 생기는 보안 위험임
      파이어월을 제대로 설정했는지, 최신 CVE에 신속하게 대응하는지 등이 걱정임
      그래서 오히려 GitHub Actions로 워크플로우 구축→컨테이너 이미지 빌드해 프라이빗 레지스트리로 푸시→k8s 설정으로 해당 이미지를 서비스에 배포하는 편이 안정적이라고 느껴짐
      직접 VM에 올리는 것만큼이나 간단하며, 이렇게 하면 내 앱과 인터페이스만 책임지면 됨

    • 내가 canine.sh를 만든 이유가 바로 위에 언급된 모든 세팅 과정을 원클릭으로 만들고 싶었기 때문임
      예전에 작은 SaaS를 공동창업했을 때, 우리 클라우드 이용료가 연간 50만 달러가 넘었음
      실서비스 운영에서 sentry가 필수라는 걸 곧 깨달았고, 에러 확인을 서버로그에서 일일이 찾기보다는 클라우드 sentry로 대략 월 40달러
      데이터 모니터링 위해 datadog도 필요해 월 300달러
      고객 프리젠테이션용 대시보드를 위해 Looker/Tableau/Omni 같은 BI툴은 연 2만 달러
      데이터 웨어하우스 및 복제는 연 15만 달러
      이런 외부 서비스 비용이 계속 쌓이고, 궁극적으로 외부 서비스 전부를 내 인프라에서 유지·운영하는 게 가장 좋다는 결론에 다다름
      예시로 Cloud Sentry→Self Hosted Sentry, Datadog→Prometheus/Grafana, Looker→Metabase, Snowflake→Clickhouse, ETL→Airbyte 등
      대부분의 회사가 결국 쿠버네티스를 선택하게 되는 이유임
      인디해커들이 왜 쿠버네티스의 복잡성이 필요한지 잘 이해하지 못할 수 있지만, 모든 걸 단일 VPS에 올릴 수 없는 이유가 여기에 있음

    • "대부분의 프로젝트는 웹스케일까지 필요 없다"는 말에 공감함
      요즘 주요 클라우드 플랫폼의 마케팅은 사실상 YAGNI(You Ain't Gonna Need It)이 인프라 쪽에서도 실현되는 느낌임
      2000년대 초반부터 시스템관리자로 일해오며, 다들 자기 서비스를 직접 호스팅하는 흐름이 마치 무슨 혁신처럼 떠오르는 걸 보면 재밌음
      예전에는 Docker가 나오기 전부터 이미 LXC, BSD Jails 등으로 코드 격리해서 돌렸고, 또다른 DevOps 전의 오랜 전통임
      요즘 개발자들이 이런 걸 새로 발견하는 걸 구경하는 것도 흥미로움
      마지막으로, 그레이비어드(고참) 시스템 관리자들과 협업하거나 커피 한잔 하면서 도움받으면 좋겠음
      예전 방식으로 직접 인프라 관리하는 걸 기꺼워하는 사람이 많으며, 실질적인 노하우도 많이 있음

    • 셀프 호스팅의 또 다른 장점은 클라우드 서비스와 달리, 시스템 기술과 지식이 이식성이 높다는 점임
      systemd, ufw, ssh 동작법을 익혀두면 다른 시스템에도 곧장 적용 가능함
      오히려 Docker 및 컨테이너 레이어별 빌드, 각종 트릭들을 익히는 데 드는 시간·비용이 일반적인 Debian 웹서버 관리보다 더 많다고 생각함

    • 전반적으로 동의하며, 의견 공유해줘서 고마움
      한 가지 다르게 생각하는 것은 "CDN은 규모가 커야만 필요하다"는 부분임
      CDN은 단순히 오리진 요청을 분산시키는 용도가 아니라, 사용자 경험의 지연을 낮추는 목적이 크다고 생각함
      체감 속도는 사실 가장 중요한 기능이라고 할 수 있고, 미리 최적화하는 건 주의해야겠지만, 최소한 정적 자산을 사용자 근처 엣지에서 서빙하는 게 이미 10년 전부터 기본 스펙 수준임

  • 훌륭한 주제임, 내 경험을 바탕으로 관점을 나눌 수 있음
    홈랩을 직접 운영하면서 가장 큰 이점은 비용절감이나 데이터 프라이버시 자체가 아니라, 실제 깊이 있는 실무적 지식을 얻게 되는 것임
    Docker, 네트워킹, 리눅스 관리에 대해 글로 배우는 것과, 실제 가족이 사용하는 서비스를 스스로 운영하다가 DNS가 멈추거나 도커 컨테이너가 재부팅 실패해 직접 해결해야 할 때에서 얻는 배움은 완전히 차원이 다름
    하지만 여기엔 또 다른 현실이 있음
    처음에는 재미있는 프로젝트였지만, 패스워드 매니저나 파일 동기화 같은 중요한 서비스까지 직접 호스팅하기 시작하면 24/7 온콜 책임자가 된다는 점임
    백업, 보안패치, 가동시간 모두 내가 책임져야 하고, 그때부터는 단순한 취미를 넘어 '직업'이 됨
    결국 셀프호스팅은 데이터 통제권을 갖고 큰 성취도 얻을 수 있지만, SaaS의 비용 대신 내 시간·정신적 부담을 IT 담당자 역할로 치환하는 트레이드오프임
    하지만 HN 사용자라면 충분히 해볼 만한 가치가 있다고 생각함

  • 회사(enum.co)에서 디지털 소버린(주권)을 중시하며 일할 수 있어서 행운이라고 적었지만, 실제로 info.addr.tools로 메일서버를 조회해보니 MX가 smtp.google.com, TXT레코드에도 구글 속성이 많았음
    이건 단순한 "구호"가 아니라 DNS 상의 현실임
    디지털 주권을 중시하면서도 구글 메일서비스에 의존하는 건 모순임
    https://info.addr.tools/enum.co

    • enum을 변호하자면, 그들이 제공하는 서비스는 k8, S3 호환 스토리지, DevOps 쪽임
      만약 셀프호스팅/이메일 주권을 판다고 해놓고 gmail을 썼으면 완전히 다르겠지만
      완전히 100% 독립은 아니고, 실제로 OP도 "셀프호스팅 메일서버가 큰 금기어처럼 여겨지지만, 생각만큼 두려울 필요는 없다"고 언급함
      모두가 이 문제를 인식하고 있고, 개선점도 남아있음

    • 안녕하세요, enum 창업자임
      그 지적은 타당하고 좋은 포인트임
      솔직히, 우리 내사용 이메일에 Google Workspace를 쓴 건 초기에 코어제품 개발에 집중하고자 한 실용적 선택이었음
      스타트업에서 아주 흔한 선택이고, 앞으로 몇 주 내에 전환 예정임
      단, 우리 고객 대상 플랫폼과 모든 데이터는 언제나 100% 주권을 지키고 있음
      인프라는 완전히 빅테크와 독립적임
      문제를 지적해줘서 고마움

    • 이메일만큼은 셀프호스팅 예외로 생각함
      나는 모든 서비스 셀프호스팅을 하지만, 이메일은 3rd party에 맡김

    • DNS에 구글 관련 레코드가 있다는 점을 강하게 지적한 것에 감탄함
      대단하다고 생각함

    • TXT "google-site-verification=..." 부분은 굳이 "악한" 게 아니라, 구글이 메일 발송시 스팸 취급하지 않게 처리하려는 절충임

  • 이메일을 셀프호스팅하는 경우, 디지털 주권이 프라이버시보다 더 중요하다면
    나는 gmail에 커스텀 도메인을 쓰고, 직접 이메일 서버를 셀프호스팅해서 mbsync로 gmail에서 메일을 계속 다운로드함
    저장 및 열람은 내 서버에서 하지만, 발송은 그대로 gmail 이용
    구글이 내 계정 접근 차단해도 이메일은 직접 갖고 있으며, 공급자를 바꿀 땐 DNS만 변경하면 됨
    보낸 메일의 도달 문제도 없음

    • SPF, DMARC 등 DNS 설정으로 6년 전 메일 셀프호스팅을 시작했음
      문제는 한두 번밖에 없었고, 대부분 서비스나 무작위 장애, IP 변화, 백업 자동화 등 메일 서버보다 딴 게 더 골치 아팠음
      오히려 메일 서버는 그냥 알아서 잘 동작함

    • 왜 메일 전송까지도 셀프호스팅하지 않는지 묻는다면
      아마도 메일 발송 도달성(Deliverability) 이슈 때문임?

    • 이메일의 완전한 주권은 커스텀 도메인에 달려 있음
      이걸 안전하게 가져가면, 언제든 여러 공급자 중 선택 가능하고 업무이동이 자유로움

  • 셀프호스팅 정말 멋짐
    1년 전 소프트웨어 엔지니어에서 SaaS 창업을 시작하면서부터 Coolify와 Hetzner 20달러 서버로 Postgres, 구버전 Minio, Nuxt, NextJs, Umami analytics, Open WebUI, 정적 사이트 등을 직접 호스팅함
    처음엔 배우는 과정이 필요했지만, 세팅 끝나고 나서는 새로운 서비스 띄우는 게 플러그 앤 플레이처럼 쉬워짐
    서버 리소스도 1/4도 안 쓰고 있음(이용자 적어서 ㅋㅋ)
    https://coolify.io/docs/

  • IT 전문가로 일하지만, 집에서 셀프호스팅이나 NAS 구축만큼은 계속 미루다 결국 Ugreen NAS 4베이 모델을 사서 바로 TrueNAS CE 설치함
    ChatGPT에 나만의 docker-compose 파일 등 컨텍스트까지 줘가며 세팅을 진행함
    도커, 네트워킹 등에 과거 학생때 조금 경험한 것 외에는 거의 지식 없던 상태였지만
    현재는

    • 여러 Dockerized 앱 운영
    • 각 앱스택 별 독립 네트워크
    • Traefik+Docker labels로 웹 UI 노출 관리
    • Traefik 443포트만 외부로 공개, 필요시만 포트포워딩
    • 선택적 Cloudflare 터널
    • 도메인에 대한 자동 Traefik TLS 종료(LAN/WAN 모두)
    • LAN/WAN을 위한 Split-DNS
    • 노출된 모든 컨테이너에 CrowdSec 적용
    • Cloudflare로 노출서비스에 MFA 적용
    • Technitium으로 로컬 DHCP/DNS
    • 자동 ZFS 스냅샷/원격백업
    • DB, 로그 등 휘발성 데이터는 SSD, 대용량 파일은 HDD로 분리
      로 운영 중임

  • 셀프호스팅 좋지만, 문제는 백업과 업그레이드임
    다양한 리소스를 직접 호스팅하지만, 중요 데이터나 타인이 의존해야 하는 건 직접 호스팅하지 않음
    앱 복구나 업그레이드가 쉽지 않으면 의존하지 않는 주의임
    실제 셀프호스팅 앱 중 백업/복구가 한두 줄로 되는 곳은 별로 없음
    참고로, Tailscale과 Pangolin은 집에서 안전하게 셀프호스팅할 때 신의 선물과 같음

    • 기대하는 백업 솔루션이 뭔지 궁금함
      모든 셀프호스팅 앱은 도커로 돌리니, 컨테이너 볼륨 폴더와 docker-compose.yml만 백업하면 됨
      복원은 폴더 넣고 docker compose up 하면 끝
      앱마다 별도 백업 구현 필요 없다 생각함, 그건 개발자 시간 낭비임

    • Tailscale 대신 netbird 셀프호스팅을 강추함
      아주 활발하게 개발 중이고, UI도 훌륭함
      https://github.com/netbirdio/netbird

    • Pangolin이 뭔지 궁금함
      검색해보니 동물만 나옴

  • 내 셀프호스팅 스택

    1. immich
    2. jellyfin
    3. ghost
    4. wallabag
    5. freshrss
    6. vaultwarden
    7. nextcloud
    8. overleaf/sharelatex
    9. matrix 서버
    10. atproto용 pds
    • 어떻게 업그레이드하는지, 보안 패치는 어떻게 적용하는지, 백업은 어떻게 하고 실제로 정기적으로 테스트하는지 궁금함
      최신 버전업이나 보안 패치 안내가 부실하거나, 모든 버전을 차례로 거치지 않으면 안 되는 경우도 있음

  • "셀프호스팅"을 너무 집안 서버에만 한정하면 늘 비주류로 남을 수밖에 없음
    오픈소스 비구독형 앱, 옛날식 윈도우 PC 애플리케이션, 쉽게 옮길 수 있는 클라우드앱 등 SaaS가 아닌 모든 방식을 장려해야 함
    어떤 방식이든 락인을 피하고, 사용자가 통제권을 얻는 것이 진짜 셀프호스팅 목표라고 생각함

    • 그럼에도, 단어의 의미가 흐려지면 안 됨
      스탠다드 프로토콜로 옮길 수 있는 클라우드앱이라도, 결국 내 소유/제어서버가 아니면 운영자 맘대로 데이터정책·수집방침이 바뀔 수 있음
      예기치 못하게 데이터가 수집되거나, 서비스 종료 전에 데이터 이전이 가능할지 확신할 수 없음

    • 윈도우 설치형 소프트웨어도 셀프호스팅 범주에 포함될 수 있음
      실제로 처음엔 윈도우 실행파일이나 도커로부터 시작해서 점점 더 발전하는 방식도 있음

    • 최소한, 본인이 루트 권한 있는 채로 타인 데이터센터(코로케이션 등)에서 서버를 돌리는 것도 셀프호스팅에 포함된다고 생각함

  • 20년 전만 해도 할아버지들도 limewire.com에서 setup.exe다운하고 next->next->next만 누르면 완벽한 파일서버와 클라이언트를 설치할 수 있었음
    2007년에는 세계 컴퓨터 1/3이 limewire를 썼음
    근데 요즘은 아주 기본적인 셀프호스팅 소프트웨어조차 사실상 프로급 엔지니어만 설치 가능함
    SSH, Docker 사용, Tailscale, TLS 인증서 등 복잡한 관리를 해야 하고, 백업과 수많은 기타 자동화까지…
    왜 apt-get install하고 끝나는 '셀프호스팅' 소프트웨어가 드물까 싶음
    그래서 아무도 직접 호스팅 안 하는 것임
    https://en.wikipedia.org/wiki/LimeWire

    • 일부 소프트웨어는 apt-get install로 설치가 끝나기도 하지만, 인터넷에 서비스 노출하려면 도메인 네임과 HTTPS 설정부터 해야 함
      Limewire나 BitTorrent 같은 클라이언트는 센트럴 서버(트래커 등) 덕분에 도메인 없고도 쓸 수 있었던 것임

    • 많은 사람들이 limewire 같은 설치 프로그램을 셀프호스팅이라고 생각하지는 않을 것임
      그냥 로컬 프로그램 설치임

    • Ubuntu에서 snap으로 서버 사이드 앱을 쉽게 설치 가능하게 하려 했는데, 커뮤니티가 강하게 반발해서 실패함
      snap에도 단점 있지만, 서버앱 배포를 쉽게 하려고 만든 포맷임
      예시로 지금도 nextcloud를 snap으로 설치 가능함
      완벽하지 않다는 이유로 현실적인 '좋음'까지도 배척한 셈임

    • Limewire는 클라이언트일 뿐 서버가 아님
      제대로 업로드하게 하려면 방화벽/포트포워딩해야 하고, UPnP 허용(추천 안 함)도 필요
      셀프호스팅 서버는 완전히 다른 영역임
      초보자도 자동으로 할 수 있었을 세상에서, 악성 해커 때문에 세팅·운영의 난이도가 높아졌음
      전문가조차도 프로 침투테스터나 국가급 해커에게는 무방비임

    • 요즘 소프트웨어 개발 자체가 너무 복잡해졌다고 생각함
      점점 쓸데없는 문제를 일부러 만들어 직업을 유지하는 관료주의와 비슷함
      대다수는 셀프호스팅까지 필요 없고, 그냥 컴퓨터에서 돌리고 때때로 로컬 네트워크에서 접근만 가능해도 충분함
      그런데 수익모델이 부재하고, 개발자들은 특수한 레이어, 불필요하게 복잡한 아키텍처에 집착함
      결과적으로는 서버 소프트웨어, 웹뷰 기반, 데이터와 로컬 환경의 괴리, 관리할 장비만 늘어남
      대다수 컴퓨터는 놀고 있는데 관리자용 계층만 쌓여감
      노트북 흐름도 이런 혼란의 일부라고 생각함
      좋은 Mac용 로컬 앱도 사라지고, 클라우드 구독 기반만 넘쳐남
      오픈소스도 결국 Docker 이미지, 복잡한 설정, 온갖 gotcha가 산더미임
      만약 단순 설치·관리가 가능했다면 유료로도 쓸 만하지만
      지금은 시간만 얼마나 들어가는지 알 수 없어 다들 그냥 빅테크에 맡기고 마는 것임
      웹 기술이 인터랙티브 문서에 좋긴 해도, 이 용도 외에는 여전히 사용성에 큰 어려움이 있음

답변달기