자체 호스팅과 기술 독립: 직접 만드는 기쁨
(ssp.sh)- 기술 독립과 자체 호스팅의 즐거움에 대한 경험과 중요성 강조
- 도메인 소유와 블로그 자립 운영이 장기적으로 커리어와 자기 성장에 큰 이점임을 설명함
- 개방형 오픈소스 생태계에서 자신의 지식과 코드를 공유하며 얻는 커뮤니티와 학습의 소중함 언급
- Homelab 구축과 다양한 자체 호스팅 오픈소스 도구를 소개하며, 구독 기반 서비스의 한계에서 벗어나 실제로 써볼 때 느끼는 자유를 강조함
- Markdown 기반의 콘텐츠 공유와 오픈소스 정신이 소프트웨어 생태계 및 개인 역량 강화에 미치는 긍정적 영향 강조
들어가며: 기술 독립과 직접 구축의 가치
- PewDiePie가 Arch Linux 설치와 오픈소스 기반 제품을 직접 만드는 영상을 보고, 저자는 자신만의 것을 만드는 자체 호스팅 및 기술 독립의 중요성을 되새기게 되었음
- 스스로 쌓은 도메인과 블로그, 직접 관리하는 서비스들이 장기적으로 누적되는 자산이 되며, 이는 단순한 플랫폼 이동보다 큰 의미를 가짐
도메인 소유와 블로그 자체 운영의 힘
- 새로운 글쓰기를 시작하거나 구직을 고민 중인 이들에게 먼저 자신만의 도메인 구매와 블로그 운영을 추천함
- 플랫폼을 옮길 때마다 소중한 컨텐츠와 도메인을 잃는 일이 반복되므로, 직접 도메인을 소유하며 지속해서 같은 주소에서 콘텐츠를 쌓는 것이 중요함
- 시간이 지남에 따라 쌓인 백링크와 오래된 게시글, 투자 내역이 장기적 신뢰성으로 연결됨
저자의 자체 호스팅 경험과 학습
- 저자는 블로그, 두 번째 두뇌, 책, 구독 리스트 등 다양한 서비스들을 직접 호스팅하며, GoHugo, Listmonk, Memberstack 등을 활용함
- Homelab 환경 구축, SSH, 백업, 사진 관리, Gitea, 프록시/SSL 인증서 자동화 등으로 점진적으로 기술 역량을 쌓아감
- 처음엔 어렵게 느껴져도 과정에서 배움과 성취감이 가장 큰 보상임
오픈소스와 커뮤니티의 가치
- 오픈소스 소프트웨어 활용 및 기여가 기술 독립을 가능하게 하며, 본인의 지식과 도구들도 GitHub에 공개함
- 오픈소스의 경우 다양한 라이선스를 통해 모두가 자유롭게 사용할 수 있으며, 커뮤니티 피드백과 협업의 기회가 늘어남
- 저자는 오픈소스 BI 도구 사용 경험을 통해 오픈소스 생태계에 매력을 느끼기 시작했고, 현재 대부분의 온라인 활동과 데이터 엔지니어링 글도 이에 기반함
리눅스와 Linus Torvalds
- Linux는 전 세계 디지털 기기의 핵심이며, Linus Torvalds가 이를 상업화하지 않은 덕분에 세계적으로 널리 퍼질 수 있었음
- Torvalds는 git도 개발했으며, 이는 전 세계 모든 소프트웨어 개발자의 필수 도구가 되었음
- 오픈소스에 자신의 작업을 공개하면, 타인의 학습과 피드백, 기여, 연결 경험이 얻게 되어 개인의 성장뿐 아니라 커뮤니티 발전에도 이바지함
감사와 오픈소스 도구들
- 저자가 자주 활용하며 감사하게 생각하는 몇몇 오픈소스 도구들이 있음
- Quartz: 오픈소스 Obsidian Publish 대체제
- GoatCounter: 익명화된 사이트 트래픽 분석 도구
- Listmonk: 오픈소스 뉴스레터 리스트 시스템
- listmonk-rss: 블로그 작성 시 자동 이메일 발송
- Homelab에서 권장하는 오픈소스 소프트웨어 예시:
- Paperless: 문서 디지털화 및 관리
- PhotoPrism: AI 기반 자체 호스팅 사진 관리
- Pi-hole: 네트워크 전체 광고 차단
- Nginx Proxy Manager: 도메인 라우팅 및 SSL 자동화
- Audiobookshelf: 오디오북/팟캐스트 서버
- Calibre: 전자책 관리
- Syncthing: 분산 파일 동기화
- Gitea: 경량형 자체 Git 서비스
저렴한 장비로도 충분한 실험
- 값비싼 최신 서버가 아니더라도, 중고 클라이언트 서버와 좋은 운영체제만으로 충분히 Homelab 구성을 할 수 있음
- 직접 구축과 운영 과정에서 배우는 즐거움과 독립성을 중시함
기술 독립성과 플랫폼 리스크
- 스스로 구축과 호스팅을 통해 Google, Apple 등 대형 서비스의 기능 변경, 서비스 종료 등의 리스크에서 자유로워짐
- 자신만의 환경과 특징을 직접 설계, 수정할 수 있는 자유를 얻는 것이 Tech Independence의 진정한 이점임
마무리 및 Markdown의 중요성
-
오픈소스 및 자체 제작, 경험 공유의 기쁨을 강조하며, 모든 솔루션과 콘텐츠 생산 기반이 Markdown으로 통일되어 있다는 점도 부각함
-
Markdown은 다양한 플랫폼 간 호환성을 보장하고, 오픈소스/지식 공유 문화의 표준 도구가 됨
-
더 많은 데이터 엔지니어링 블로그, 두 번째 두뇌 노트, 공개 집필 중인 책 등은 모두 ssp.sh 및 GitHub에서 확인 가능함
-
독자와의 경험 공유 및 토론을 언제나 환영함
Hacker News 의견
-
자기 홍보여서 좀 미안하지만, 셀프 호스팅할 때 꼭 직접 하드웨어를 새로 살 필요 없는 현실임을 이야기하고 싶음. 몇 년 지나면 Windows에서 느려서 못 쓰던 구형 노트북도 Linux 서버로는 충분히 쓸 만한 성능 제공. 집이나 주변 친구들 중에 굴러다니는 오래된 노트북 발견할 확률이 높고, 나도 2011년산 i3 노트북으로 두 명이서 잘 사용 중이며 2025년이 되는 지금까지도 업그레이드 필요 없어 보임. 노트북은 대기 상태에서 전원 효율도 좋아서 장기적으로 보면 데스크톱보다 더욱 합리적 선택. 셀프 호스팅 초보에게 노트북이 훌륭한 첫 서버 후보라는 생각. (참고로 노트북엔 UPS가 내장되어 있지 않으니, 24시간 꽂아놓고 쓸 거면 반드시 배터리를 분리 추천)
오래된 하드웨어 재활용 관련 글-
지금 이 글도 13년 된 Acer 노트북에서 Linux Mint XFCE로 작성 중임을 고백. 오래된 기기 버리기가 항상 아까워서 새 노트북 산 후에도 거실 TV에 HDMI로 연결하고 $25짜리 Logitech K400+ 무선 키보드/트랙패드로 세팅해둔 상태. 웹 서핑, YouTube, Netflix 모두 무리 없이 사용 가능하고, 가끔 작업할 때 VS Code나 Thunderbird 열고 사용, 심지어 Steam에서 인디 게임도 게임패드로 무리 없이 구동 가능. Framework 노트북이 우리나라에도 들어오면 이런 재활용 환경이 한층 더 늘어날 듯 아쉽게도 내 나라는 아직 배송 안 됨
-
우리 동네(스웨덴의 250세대 아파트 단지)에서는 사람들이 전자 쓰레기장에 구형 컴퓨터를 버리는 일이 일상. 마치 Mad Max 영화의 캐릭터처럼 개 산책 나갈 때마다 매일 여러 번 스카우트함. 여러 대로부터 부품 조합해서 debian 깔고 docker 컨테이너 돌려 갖가지 용도로 사용. 이렇게 만든 Frankenstein 서버를 부모님, 사촌, 친구들에게도 선물한 적 있음. 사람들이 얼마나 쓸 만한 기기를 버리는지 놀라울 정도. 비밀번호 없는 노트북도 심심찮게 보이는데, 윈도우 로그인하면 온갖 가족 사진 가득함. 가끔 잠금 해제된 5년 전 쯤 모델 아이폰도 발견. 참 묘한 세상이라 생각할 수밖에 없음
-
집에 Mac-Mini 2012년식 모델도 한 대 있음. 선물로 받은 거라 Mac으로 갈아탈 생각은 없었고 강력하진 않지만 성능은 준수함. 작년 크리스마스에 부팅했는데, 기본 OS로도 너무 느렸고 macOS 업데이트하니 사용 자체가 불가능해짐. YouTube 따라 SSD로 바꾸고 Debian 설치, CasaOS(웹 기반 홈서버 OS/UI) 올린 뒤로는 Wireguard로 외부에서 접속해 Navidrome으로 음악 스트리밍 쓰는 환경 구축. Docker 개념은 아직 잘 모르겠지만 PATH 매핑 등 다양한 걸 배우는 중
-
중고 시장에서 쇼핑하는 게 꺼려지지 않는다면, 나는 요즘 Threadripper 3세대 32코어/64스레드, 256GB ram, 2x10G, 2x2.5G, 전용 IPMI 관리 1G 인터페이스, 64 PCIe gen 4 lane 갖춘 Proxmox 노드를 2,000유로 미만에 구축 중
-
RAID6/RAIDZ2 미만의 셋업에서는 꽤 큰 데이터 손실 위험 존재. 대부분의 노트북은 SATA/M.2 포트 부족으로 페리티 구성 자체가 안 되니까, RAID 수준의 내결함성 원하면 결국 새 하드웨어 필요. 백업은 최소 2개의 물리적 위치로 분산해야 한다는 원칙을 지킨다면 이중으로 갖추는 게 가장 이상적
-
-
셀프 호스팅하고 싶은 이유도 이해하지만, 하기 싫은 마음도 충분히 이해함. 셀프호스팅은 번거로운 일로, docker 업데이트도 해줘야 하고, 뭔가 고장나면 나만 해결해야 하며, 설령 잘 되어도 매끄럽다기보단 살짝 어설픈 느낌 받는 경우가 많음. 지금은 잘 동작해 내 시간을 아껴주는 self hosted 툴 리스트가 아주 적은데(첫 번째는 firefly), 셋업하다가 깨지고 결국 포기한 경우가 많았음. 요즘은 프라이버시 존중하고 가격도 괜찮은 회사 제품은 그냥 돈 내고 씀
-
Docker가 문제의 원인이라 생각. Docker는 스토리지, 네트워킹 등에 불필요한 간접 계층을 추가하고, 보안 등 업데이트하려면 컨테이너 재빌드가 필요하거나 남이 해주길 바라야 하니 힘듦. 가능하다면 업스트림 OS 패키지나 단일 바이너리(go 기반 프로젝트에서 종종 보임) 형태로 배포 가능한 서비스를 고수하면 장기적으로 더 쉽게 운용 가능
-
Docker를 왜 꼭 업데이트해야 하는지 의문. 내 경우 1년 넘게 Docker는 업데이트 없이 운용 중. 도커 이미지 업그레이드는 한 달에 15분 남짓 투자하고 끝. 그리고 프라이버시 존중하는 기업은 극히 드물고, 해를 거듭해 독자적 정책을 고수하리라는 신뢰는 어렵다는 점이 실상
-
프라이버시 존중하고 가격 좋은 회사를 찾기조차 극히 어려운 상황
-
어떤 프로젝트에서 문제를 겪었는지 궁금. Docker Compose까지 제공하는 수준에 오르면 거의 대부분 문제없이 동작하는 경험했음. 그리고 거의 모든 회사가 언젠가는 신뢰를 배반한다 생각. 그래서 굳이 그럴 기회조차 주지 말자는 것. 나는 Home Assistant를 셀프호스팅 중인데, 이 회사는 유저에게 불리하게 운영되지 않게 법적으로 장치까지 마련했다는 점이 독특함
-
-
필요한 것 대부분을 셀프호스팅하지만, 최근에 진짜 위기가 찾아온 경험은 인터넷이 간헐적으로 끊겼을 때임. 스스로 이런 질문을 하게 됨
- 인터넷 없이 얼마나 생산성 유지 가능한가
- 무엇을 놓치게 되었는가
결론적으로 더 많은 문서 아카이빙이 필요하다는 사실과, NixOS는 캐시 서버를 직접 두지 않으면 오프라인에서 활용이 거의 불가 - 그 점은 매우 불편함. 결과적으로 인터넷 없이도 내가 필요한 것의 대부분을 셀프호스팅하고, 그 환경에서 오히려 생산성이 매우 상승했다는 도전 결과 발견
-
"devdocs"를 직접 호스팅하고 리눅스용 zeal(오프라인 문서 뷰어) 써보니 오프라인 문서 문제 상당 부분 해결.
devdocs github
zealdocs 공식페이지 -
다운타임이 있을 때마다 내 시스템 약점을 새로운 기회로 삼음. 어쩔 수 없이 upstream의 문제로 이런 상황을 못 피하면 어쩔 수 없지만, 대응책이 있는 상황에는 코스트-확률 균형 맞추는 시나리오 세우고 그 작업 자체가 재밌게 느껴지는 성향
-
나는 이 오프라인 추구를 최대치로 밀어붙여 본 경험자. 인터넷 완전 단절 시기가 내 작업 생산성 최고치를 기록하는 순간이었음. 전체 웹사이트 wget으로 재귀적 저장하는 bash alias 가지고 있고, yt-dlp로 원하는 동영상 저장, Kiwix로 위키피디아 전체 오프라인 사본 보유, 이메일도 로컬 저장에 오프라인 작성 메일 큐잉 지원, SingleFile 확장으로 개별 페이지 저장도 효율적, Zeal은 오픈 소스 문서 브라우저로 추천할만한 툴
-
"NixOS는 자체 캐시를 안 두면 오프라인에서 쓸 수 없다" 문제에 공감. 패키지 매니저 쓰는 소프트웨어라면 캐시나 저장소 백업이 꼭 필요. 의존성 트리 끝단의 모든 개인들이 제 역할을 계속 해줘야 시스템이 온전히 작동한다는 점, 이게 요즘 소프트웨어 개발 방식에서 가장 불안한 지점. 최종 사용자 소프트웨어 쓸 땐 모든 의존성 포함된 개별 패키지가 훨씬 낫다는 입장. 어차피 실제 하드에 저장되는 건 그런 형태
-
Kiwix(위키피디아 오프라인 솔루션)과 다양한 jellyfin 셋업은 강력한 오프라인 리소스. 그런데 NixOS, Gentoo 등의 배포판은 지속적으로 인터넷 연결을 요구하는 경향. 전체 패키지 미러링은 현실적으로 거의 불가능
-
"먼저 도메인을 사라"는 조언에 대해, 사실 도메인이라는 건 빌리는 것이지 진짜로 살 수 있는 게 아님. 결제 한 번 빠지면 바로 내쫓기는 구조라 무섭기까지 함. 이런 온라인 정체성의 덧없음이 슬플 정도
-
"도메인은 빌리는 것뿐이다"라는 부분, ICANN이 승인하는 루트존/레지스트리만 쓴다면 그렇지만, 나는 실험적으로 나만의 레지스트리를 만들어 타인과 공유하지 않는 커스텀 루트존을 수년간 직접 운영. 커스텀 TLD는 도메인 이름에 전 세계 모든 제품/서비스 분류 체계를 담는 역할도 실험했고, ICANN TLD의 모호함과 부적절함을 직접 체감
-
이건 일종의 기술적 한계. 내 모든 기기(즉, 도메인명 소비자)들이 특정 공개키로 서명된 걸 “XorNot.com”으로 인정하라고 세팅하면 시스템 대체도 가능. 기술적으로 더 많은 지원만 받으면 “신뢰할만한 키-이름 목록”으로 지금 구조 전체를 교체해버릴 수도 있다고 봄
-
-
셀프호스팅용 툴 생태계 큰 발전 느끼는 시대. 처음엔 호스팅된 컴포넌트로 시작해 각 요소를 하나씩 셀프호스트로 교체 가능. 내 블로그도 집 서버에 셀프호스팅.
앞단엔 Cloudflare Tunnel 쓰지만 전엔 nginx+letsencrypt+public_ip도 해봤고, 데이터 저장소도 Cloudflare R2, S3, 또는 로컬 NAS로 다양하게 교체 가능(FUSE 거치면 접근 방식도 동일).
반면에 반드시 빌려야 하는 자원은 도메인(구매처럼 보여도 임대에 불과), 인터넷 연결 정도뿐이고, 나머지 요소는 대부분 선택적으로 쓸 수 있는 시대. 물론 서비스 끄면 불편해지지만 기본 동작은 유지.
예전에 비해 정말 엄청 쉬워진 시대. 90년대~2000년대 초반엔 상상도 못할 도구 환경.
단, 이메일 스팸 방지 조건만 아주 까다로워진 게 단점. 8년 전까지 내 메일도 직접 운영했지만, 지금은 G Suite 사용 중 -
나는 “셀프호스트 할 것인가”가 아니라 “셀프호스트 할 수 있는 능력” 자체가 요점이라고 생각. 기술이 부족하거나 비용을 지불하고 싶을 때 남에게 맡길 수도 있다는 관점이 포용적. “돈 내면 되지” 하는 사람들이 장기적으로 실제로 가장 큰 리스크를 맞이함. 요즘 비즈니스는 장기적인 기술 의존도를 인질 삼아 기획적으로 고객을 포획함. FOSS에 관심 없어도, 벤더 이전 가능성은 정말 중요한 문제라는 인식. 락인 되면 언제라도 불합리한 이용 당할 수 있다는 부분 강조. 이런 구조로만 사고하는 회사도 많음
- Bluesky에서 말하는 “credible exit(믿을만한 퇴출 경로)”가 이와 약간 비슷한 개념 언급.
Zulip을 오픈소스, 자가 호스팅, 클라우드 서비스, 상호 이전 모두 지원하는 서비스로 높이 평가
- Bluesky에서 말하는 “credible exit(믿을만한 퇴출 경로)”가 이와 약간 비슷한 개념 언급.
-
개발자가 넘쳐나고, AI로 집에서 생성 가능한 코드 품질이 천차만별로 늘어나는 시대라면, 셀프호스팅도 확실히 트렌드가 될 수 있음
-
리눅스 기초만 배우면 굳이 필요한 게 아니어도, “내 서비스를 직접 돌린다”는 쾌감과 성취가 있어서 셀프호스팅의 매력 느끼는 사람 많음.
더 큰 효과는, 완전히 의존 중인 플랫폼에서 내가 이유 없이 쫓겨날 수 있는, 현실적인 리스크 제거 효과. Gmail 계정까지 날리면 “일반인”들은 계정 속 온라인 신상, 패스워드 리셋, 심지어 앱 로그인까지 다 막혀서 곤란에 빠질 수 있음. Hacker News에도 Gmail 계정 날리면 인생 곤란할 사람 분명 존재할 것. 그러니 최소한 이메일 아이덴티티는 내 소유여야 한다는 입장. 이 원칙을 웹호스팅, AWS, Spotify, Netflix 등 모든 온라인 서비스에 반복 적용해야 하고, “새 클라우드 호스트로 대체” 정도로는 문제 해결 안 됨.-
이메일 서버 설치는 정보도 많고 쉽지만, 직접 운영하는 과정(특히 호환성 문제나 장애 대응 등)에 관한 자료가 잘 없음이 개인적 아쉬움. 예를 들어, 구글이 내 서버를 블랙리스트에 올리면 누구에게 연락해야 하는지, 에러 메시지에 대처 절차가 있는지 등 실전에서는 도움 받을 곳 부족. 글로벌 IP 블록 등 외부의 불합리한 요소에 제대로 대응하는 방법 설명서가 필요. DKIM, DNS 같은 프로토콜 문제가 아니라, 실제 서비스 운영에서 부딪히는 타 사업자 대응책 가이드라인이 필요
-
도메인은 직접 소유해서 원하는 이메일 제공업체에 붙인 뒤, 문제가 생겨도 바로 다른 곳으로 옮기면 됨. 도메인 자체는 저렴하고, 이메일 제공사 자체의 고유 이메일은 절대 쓰지 않는 게 정답.
그리고 이 원칙은 직접 이메일 서버를 운영하든, 상용 서비스를 이용하든 마찬가지. 둘은 별개 문제 -
리스크가 실제로 크고, 위험은 명확하지만 정말 다수에게 발생하는 리스크인지는 의문. 초기 Gmail 이용자 대다수가 채택한 이유는 기존 대안들의 품질 저하가 컸기 때문. ISP 메일, 대학/직장용 메일 등은 필요하면 언제든 계정 없어지는 구조였음. self-hosting이 문제를 “부분적으로” 해결할 수 있지만, 보안 유지 능력이 없다면, 자기가 직접 관리하는 메일서버라도 완전한 통제권 못 가짐. 도메인 갱신 등 신경쓸게 많고, 결국 신경 안 쓰면 여기서도 계정 날아감. 나는 Gmail 등 소수의 대형 사업자가 왜 이렇게 인기 있는지 이해하는 편. 대부분의 사람에겐 단기적으로나 중기적으로나 여전히 이 선택이 낫다는 현실
-
집에서 self-hosting할 때, HDD가 고장날 확률과 Gmail 계정을 잃을 확률 중 어느 게 더 큰 위험인지 자문. 직접 호스팅 시작하면 장비 공간, 백업 기획, 업데이트 관리까지 신경 쓸 게 급격히 늘어나고, 업데이트/백업 진행 중 정전까지 고려하면 결국 UPS도 도입해야 함. 그런데 내 경우 UPS가 불량이어서 NAS 하드 드라이브까지 망가져버린 경험. 결국 할 일이 너무 많아져서 일상에 집중할 시간 줄어듦
-
self-hosting은 오히려 중요한 리스크를 초래할 수 있다는 입장. 로컬 private key나 메인 이메일 도메인 잃으면 복구 불가. 2FA와 계정 복구는 외부 제공 서비스가 훨씬 편리. self-hosting 자체를 반대하는 건 아니지만, 대부분 사람에게는 계정 복구 가능성을 확보하는 쪽이 훨씬 안전한 길이라는 의견
-
-
Arch 리눅스 공식 설치 프로그램 등장 이후로, 더 이상 어렵다고 말하기엔 무리가 있다고 생각. 여전히 커맨드라인으로 진입하지만, 예전처럼 복잡한 파티션 블록 계산에 머리 싸매야 했던 시절에 비하면 훨씬 쉬워진 현실
-
집에서 Kubernetes 4노드 pi 클러스터와 Intel N150 미니 PC를 Portainer로 함께 관리 중.
오픈소스 운영 도구 중 아래 툴들 덕분에 작업 생산성에 큰 변화 체감(전부 컨테이너 환경에서 동작)- kubetail: 클러스터 전체 K8S 로그 뷰어. Helm chart로 설치. 매우 강력 추천
- Dozzle: N150 미니PC(여기에선 Kubernetes 대신 Docker만 사용) 도커 로그 뷰어. Portainer로 수동 설치
- UptimeKuma: 서버, http/https 엔드포인트, PostgreSQL 등 모니터/알람 전용. Portainer로 수동 설치
- Beszel: 서버 cpu, 메모리, 디스크, 네트워크 및 도커 컨테이너 모니터링. Helm chart/K8S 또는 Portainer로 수동 설치
- Semaphore UI: ansible 플레이북의 일정 실행 및 UI 지원. Portainer로 수동 설치