홈랩 투어 (2025)

장기적으로 비용을 낮추기 위한 온프레미스 전환을 실행한 다음 15개월이 지났습니다. 처음에는 월 별로 나가는 AWS 비용을 제거하면 비용이 장기적으로 줄어들 거라고 생각했습니다. 당시 개인 파일 관리 시스템으로 퍼포스를 사용하기 시작하면서 스토리지 사용량이 증가하는 상태를 AWS에서 감당할 수 없었기 때문에 어쨌든 모든 환경을 온프레미스로 가지고 오면 월 별로 꽤 큰 비용이 나가는 상황은 멈출 수 있을 거라고 예상했습니다. 처음에는 오래된 맥미니 기본 사양을 구해 AWS에서 돌아가던 모든 서비스를 온프레미스 환경으로 가져왔고 AWS에서 서버 로컬에 온갖 서비스를 동시에 설치했다가 환경 설정이 서로 충돌해 상당히 골치 아프던 상황을 근본적으로 회피하기 위해 이전에 한 번도 사용해본 적 없었던 도커를 사용하기 시작했습니다. 이 온프레미스 환경은 매월 지출하던 AWS 비용을 없애 주었지만 1년 넘게 지난 지금에 와서 생각해보면 전체 비용 감소 효과는 아직까지 미비한 수준입니다. 가장 큰 이유는 스토리지를 구입하고 또 이들의 백업을 유지하기 위해 하드웨어 구매 비용을 지출했기 때문입니다. 대용량 스토리지 하드웨어는 상당히 비쌌고 아직까지는 지금까지 AWS에 그냥 스토리지 사용요금을 납부했을 때 비용 소모가 더 적은 상황입니다. 하지만 이대로 시간이 조금 더 지나면 온프레미스로 옮겨 오며 비용을 줄이는 시점에 도달하긴 할 겁니다.

한편 이 온프레미스 환경에서 제가 필요로 하는 여러 서비스를 구동하기 위해 참고할 다른 사람들의 환경을 살펴보니 이렇게 집에서 기계에 여러 소프트웨어를 구동하는 환경을 ‘홈랩’이라고 부른다는 것을 알게 되었습니다. 어떤 사람들은 미니랙에 그럴듯한 네트워크 환경과 별도의 스토리지 서버, 애플리케이션 서버를 갖춰 놓기도 하는 것 같습니다. 그에 비하면 저는 그저 서버 하드웨어로 사용하는 맥미니 하나와 썬더볼트 인터페이스로 연결된 스토리지 장비가 전부이기는 하지만 나름 홈랩이라고 부를 수는 있지 않을까 싶은 생각이 들었습니다. 그래서 오늘은 지난 약 15개월에 걸쳐 운영해 온 홈랩 환경과 홈랩을 통해 구동하는 소프트웨어를 소개하겠습니다.

먼저 홈랩의 핵심 하드웨어는 맥미니 M4 모델입니다. 처음 시작할 때는 맥미니 M1으로 시작했는데 구동하는 서비스가 늘어남에 따라 메모리 8기가로는 버틸 수 없는 상태에 금세 도달했습니다. 맥미니는 메모리를 따로 업그레이드 할 수 없기 때문에 고민하던 찰나 새 맥미니가 나왔고 메모리를 64기가까지 올릴 수 있었습니다. 게다가 이전보다 훨씬 크기가 작아져 이전에도 충분했지만 24시간 구동 시키기에 훨씬 더 좋아 보였습니다. 그래서 현재 홈랩 핵심 하드웨어는 맥미니 M4가 되었습니다. 64기가나 되는 나름 커다란 메모리는 사실 평소에는 큰 쓸모가 없어 보이지만 로컬에서 작은 LLM을 구동할 때 사용 경험을 부드럽게 만들어 줍니다. 요즘 나오는 웬만한 오픈소스 서비스들은 LLM을 연동해 태그를 자동으로 붙이거나 내용을 요약하는 수준의 기능을 거의 기본적으로 포함하고 있습니다. 이 때마다 외부 서비스를 이용하기에는 아직 그런 수준의 속도와 정밀함을 요구하는 것 같지는 않아 로컬에서 도는 LLM을 사용해 조금 느린 속도와 조금 부족한 정확성을 감수하고 있습니다. 맥미니 M4 모델은 현재 제가 사용하는 모든 서비스를 구동하는데 아무런 부족함이 없고 앞으로 LLM의 하드웨어 요구 수준이 낮아지는 추세에 따라 상당히 장기간 운용할 수 있지 않을까 예상하고 있습니다.

네트워크는 간단히 KT 가정용 인터넷과 GL-MT6000이라는 공유기를 사용합니다. 사실 서버 하드웨어에 직접 케이블을 물리면 훨씬 좋았겠지만 집이 오래 되어 집에 들어오는 회선과 공유기를 연결할 수는 있었지만 그 공유기와 나머지 모든 인터넷을 필요로 하는 기계들을 유선으로 연결할 수는 없었습니다. 현대적인 공동주택은 단자함을 통해 집 안의 여러 공간을 유선으로 연결할 수 있는 모양이지만 제가 사는 집은 그런 환경이 없어 만약 장비들을 유선으로 연결하려고 하면 거의 공사 수준의 활동이 필요한 것 같습니다. 그래서 유선은 깨끗하게 포기하고 인터넷을 필요로 하는 모든 기계를 무선 네트워크를 통해 사용하고 있습니다. 여기에는 저와 가족들의 전화부터 시작해 각자의 컴퓨터, 랩탑, 태블릿, 인터넷을 통해 제어되는 스위치, 체중계 등등 수 십 가지 장치가 있습니다. 그리고 여기에는 홈랩 서버 하드웨어도 포함됩니다. 검색해보니 거의 모든 사람들이 홈랩 서버 기계를 와이파이를 통해 인터넷에 연결하는 행동을 추천하지 않고 있었습니다만, 추천하지 않을 뿐 정확히 어떤 이유 때문에 추천하지 않는지를 설명하고 있지는 않았습니다. 만약 홈랩 서버와 공유기 사이 구간을 케이블로 연결하려면 수 미터 짜리 케이블이 필요할 뿐 아니라 케이블이 지나가는 모든 문을 닫지 못하게 될 겁니다. 왜 서버 하드웨어를 무선 네트워크를 통해 연결하면 안 되는지 모르겠기에 제가 직접 해보고 이유를 알아내기로 했습니다. 하지만 홈랩 서버 하드웨어를 와이파이 네트워크를 통해 사용하기 시작한 지 시간이 많이 지났지만 아직 까지는 그러면 안 되는 이유를 찾지는 못했습니다.

하드웨어는 이게 전부입니다. 공유기와 맥미니, 그리고 대용량 스토리지 기계 뿐입니다. 사실 오늘 홈랩 투어에서 소개할 것은 제가 24시간 돌아가는 기계로 어떤 서비스들을 돌리고 있는지 입니다. 홈랩 환경을 소개하는 글이나 영상을 찾아보면 크게 두 가지 형태로 구분할 수 있는데 하나는 하드웨어 위주로 소개하는 것입니다. 그럴싸한 미니랙과 패치패널, 저렴한 하드웨어를 사용해 물리적으로 분리된 애플리케이션 서버와 스토리지 서버를 소개하곤 합니다. 다른 하나는 서비스 위주로 소개하는 것입니다. 홈랩을 사용해 어떤 서비스를 구동하고 어떤 도움을 받고 있는지, 또 각 서비스는 인터넷에 어떻게 연결되고 또 어떤 방식으로 보안을 유지하는지 설명하곤 합니다. 오늘 이 홈랩 투어는 두 번째 사례인 서비스 위주로 설명하려고 합니다. 그래서 서버 전체에서 돌아가는 모든 서비스를 나타낸 도커 데스크탑 스크린샷으로 시작하겠습니다.

일단 모든 서비스는 도커 환경에서 돌아가고 맥OS에서 도커 데스크탑을 사용해 관리합니다. 이전 GL-MT6000 공유기 사용기에서 소개한 도커 데스크탑 스크린샷과 가장 크게 달라진 점은 이제 서비스 단위로 별도 스택을 사용하게 되었다는 점입니다. 실은 저 때만 해도 docker compose의 존재 자체를 몰랐기에 그냥 컨테이너 하나하나를 각자 띄우고 있었습니다. mysql 데이터베이스 컨테이너 하나에 데이터베이스를 요구하는 여러 서비스를 물려 사용했고 여기에 개선의 여지가 있다고 생각하지 않았습니다. 또 여러 서비스가 공용으로 사용하는 cloudflared나 tailscale 같은 서비스 역시 브릿지 네트워크 상에 그냥 띄워 두고 나머지 모든 서비스가 이들을 사용하도록 설정했습니다. 이제 와서 생각해보면 메모리가 부족한 하드웨어에서는 그리 나쁜 선택은 아니었던 것 같습니다. 하지만 서비스 별로 환경이 격리되지 않아 오래 전 AWS에서 겪던 환경 설정 상의 문제를 다시 겪을 수도 있고 또 모든 서비스가 같은 네트워크 안에 있어 보안 상 문제가 일어날 때 문제가 순식간에 커질 수 있음을 알고는 있었습니다. 황당하실 수 있지만 이때까지는 docker compose라는 것이 있는 줄 몰랐습니다. 그런데 홈랩 하드웨어를 바꿔 메모리가 크게 늘어날 즈음 이 존재를 알게 됐고 서비스마다 별도의 스택을 사용해 컨테이너를 띄우는 편이 관리에도, 또 보안 상으로도 장점이 있다는 것을 알게 된 다음에는 대부분의 서비스를 격리된 스택과 격리된 네트워크를 통해 구동하고 있습니다.

beszel은 간단한 모니터링 서비스입니다. 처음에는 모니터링조차 없이 서비스를 시작했는데 현재 하드웨어나 네트워크가 얼마나 사용되고 있는지 알 필요가 있었습니다. 또 어떤 서비스가 더 많은 자원을 사용하거나 그렇지 않은지 알아야 할 일이 일어나곤 했습니다. 도커 환경에서 가장 널리 사용되는 모니터링 스택은 프로메테우스와 그라파나를 사용하는 것이었는데 제 기술 수준에서 이들은 필요 이상으로 복잡하고 설정을 유지하기도 어려워 보였습니다. 특히 몇몇 모니터링 컨테이너는 스토리지 모니터링을 위해 루트 볼륨을 마운트 할 것을 요구했는데 왜 그러는지 이해할 수 있고 또 이 애플리케이션이 꽤 신뢰할 수 있다는 것도 납득할 수 있었지만 보안 상 전혀 안전하지 않은 설정이라고 생각했습니다. 그래서 가장 널리 사용되는 것처럼 보이는 도커 모니터링 스택 대신 아예 다른 애플리케이션을 사용하기로 했고 그게 ‘beszel’입니다. beszel의 가장 큰 장점은 설정이 단순하고 의존성이 없다는 점입니다. 간단한 그래프를 그리기 위해 그라파나를 요구하지도 않고 하드웨어 정보를 가져오기 위해 별도의 컨테이너를 요구하지도 않습니다. 그냥 beszel 서버 컨테이너와 클라이언트 컨테이너만 있으면 됩니다. 클라이언트는 컨테이너 환경에서 구동할 수도 있고 직접 설치할 수도 있는데 직접 설치하면 시스템 수준에서 제공하는 온도 센서나 풍향 센서로부터 정보를 받아 표시합니다. 클라이언트를 컨테이너 환경에서 구동하면 도커 엔진이 제공하는 정보만 보여주는데 제 입장에서는 이 정도면 충분하다고 생각해 클라이언트를 컨테이너 환경에서 구동합니다.

ByteStash는 주로 단순한 코드 블록을 기록해 두는 도구입니다. 도커 환경에서 서비스를 처음 구축할 때 docker run 커맨드를 적어 두는데 사용했습니다. 처음에는 개인 위키에 기록했는데 간단한 명령어를 빨리 찾고 싶을 상황에 썩 어울리지 않는다는 생각이 들었습니다. 다른 좋은 서비스들도 있긴 하지만 코드에는 종종 인증 키가 포함되어 있어 원격 환경에 저장했다가 리파지토리 설정을 잘못 해 공개로 전환된다든지 하는 사고가 일어날 수 있을 것 같아 아예 로컬에서 돌아가는 서비스를 선택했습니다. 이후 도커 컴포즈 기반으로 전환할 때도 설정 파일을 보관하는데 한동안 사용했습니다. 그런데 시간이 지나며 도커 명령어 조각들을 기록하는 용도에는 이 서비스보다 차라리 퍼포스를 통해 버전 관리를 하는 편이 더 나을 것 같다는 쪽으로 생각이 바뀌었습니다. 디지털 - 휴먼 API (2024)에서 이미 온갖 이상한 용도에 퍼포스를 사용하고 있다고 소개했는데 도커 컴포즈 파일을 기록하는 용도에 퍼포스를 사용하고 이 서비스는 곧 사용하지 않을 작정입니다.

docklogkeeper는 도커 컨테이너들이 뿜어내는 로그를 기록하는 서비스입니다. 도커 컨테이너들은 실행 중 온갖 로그를 뿜어내지만 컨테이너를 재시작 할 때마다 이전에 뿜어냈던 로그가 모두 사라지고 처음부터 다시 시작합니다. 그런데 오래된 로그를 찾아볼 일이 어쩌다 일어났습니다. 서버에서 무슨 일이 일어났는지 알아보기 위해서는 며칠, 혹은 몇 주 전 로그가 필요했고 처음 몇 번은 로그가 아예 남아있지 않다는 사실이 굉장히 당혹스러웠습니다. 이 서비스는 간단히 도커 컨테이너 각각이 뿜어내는 로그를 sqlite에 기록하고 보여주고 또 검색해줍니다. 다른 기능은 아무 것도 없습니다. 심지어 더 이상 사용하지 않거나 이름이 바뀐 컨테이너 항목을 삭제하는 기능도 없는데 예상하기에 언젠가 추가되지 않을까 싶습니다. 그 정도로 단순합니다. 현재 실행 중인 컨테이너의 로그를 예쁜 모양으로 모여주는 서비스들이 여럿 있지만 이 서비스처럼 단순한 모양으로 그 목적에 정확히 일치하는 모양으로 동작하는 서비스는 드물어 보입니다. 그래서 몇몇 기능이나 생김새에 불만이 있지만 이 서비스를 계속해서 사용하고 있습니다.

ghost는 블로그 서비스에 사용하는 도구입니다. 지난 고스트 블로그를 온프레미스 환경으로 이전에서 매니지드 서비스를 사용하던 것을 온프레미스 환경으로 옮겨 온 과정을 소개했습니다. 실은 이전에도 고스트를 로컬에 설치해 놓고 있었는데 주로 n8n을 통한 연동을 확인하는 테스트 환경이었습니다. 또 고스트는 이 글을 타이핑 하고 있는 2025년 늦봄 현재에도 테마 프리뷰 기능이 없습니다. 테마 제작자가 만든 샘플 웹사이트를 볼 수 있기는 하지만 샘플 사이트 전부가 영어권 사이트여서 한국어가 가득한 사이트에 어울릴지 그렇지 않을지 예측하기 어려웠습니다. 그렇다고 서비스 환경에서 테마를 적용해 프리뷰 하는 것은 목적을 만족하기는 하지만 별로 좋은 생각은 아니다 싶었습니다. 그래서 로컬에 테스트용 고스트 환경을 만들어 놓고 여기에 테마를 적용해 프리뷰 하는 용도로 사용하곤 했습니다. 그러다가 본격적으로 매니지드 환경에서 온프레미스 환경으로 고스트를 통째로 옮겨 왔고 지금까지는 그럭저럭 잘 동작하는 것 같습니다. 매니지드 환경에서는 뉴스레터 발송 기능이 포함되어 있어 별도로 메일건을 구매하지 않아도 되었습니다만, 이제 뉴스레터를 보내려면 별도로 메일건을 구입해야만 합니다. 등록과 로그인 같은 최소한의 기능이 필요로 하는 메일은 외부 메일 서버를 사용할 수 있지만 대량 발송은 메일건만 지원합니다. 이제 뉴스레터를 보내지 않기로 했기 때문에 고스트 매니지드에서 제공하는 메일 기능이 필요 없어져 온프레미스에서 블로그를 구동하는데 아무 문제가 없어졌습니다. 뉴스레터 기능을 사용하지 않기로 결정하는 순간 오래 전 워드프레스 대신 고스트를 선택한 이유가 사라져 버리기는 하지만 지금 당장 딱히 도구를 바꿀 이유는 없는 것 같습니다.

hoarder는 인터넷 상에 있는 뭐든 스크랩 하는 앱입니다. 이전에 같은 용도로 인스타페이퍼나 포켓 앱을 사용했는데 무료 버전으로 사용하기에 대체로 무리 없었지만 웹사이트가 사라질 경우를 대비한 보관 기능은 유료 버전에서만 사용할 수 있었습니다. 이 서비스들로부터 큰 도움을 받은 것은 사실이지만 과연 이 서비스에 비용을 지출하는 것이 올바른지는 좀 생각해볼 문제라고 생각했습니다. 분명 잘 이용하고 있기는 한데 그들이 제공하는 ‘만약을 대비한’ 기능에 돈을 지불하는 것이 적절한가 한참을 고민하다가 그냥 무료 기능에 머무르기로 결정했었습니다. 그런데 이 앱은 로컬에서 웹사이트를 통째로 저장했다가 나중에 다시 꺼내 볼 수 있습니다. ‘호더’라는 이름이 무척 마음에 들었지만 저작권 문제로 ‘karakeep’이라는 이름으로 리브랜딩 했습니다. 새로 바뀐 이름이 나쁘지는 않지만 이전 이름이 훨씬 직관적이고 재미있어 좀 아쉽습니다. 이 앱을 사용하기 시작하면서부터 브라우저로 열 수 있는 모든 것을 간단히 로컬에 저장할 수 있게 됐습니다. 외부 LLM을 연동하면 내용 요약과 자동 태깅을 제공하는데 여기에 로컬에 설치한 LLM을 사용합니다. 내용 요약과 태깅을 요청하면 딜레이가 좀 있기는 하지만 이 정도면 개인이 사용하기에는 나쁘지 않습니다. 또 유튜브 주소를 스크랩 하면 영상을 다운로드 해 줍니다. 유튜브가 사라지지 않는 한 별 필요 없는 기능이라고 생각할 수 있지만 종종 저작권 문제로 채널이나 영상이 사라지는 일을 겪고 보니 나중에 참고할 가능성이 있는 유튜브 주소는 꼬박꼬박 스크랩 해 영상을 보관해 놓게 되었습니다. 로컬에서 이 모든 작업을 할 수 있게 된 것은 큰 장점입니다만, 그 댓가로 큰 스토리지를 필요로 하게 되었습니다.

hollo는 페디버스에 계정을 만들고 글을 쓰고 페디버스에 있는 다른 사람들과 이야기할 수 있게 해 주는 액티비티펍 프로토콜 호환 소프트웨어입니다. 이전에 사용하던 마스토돈을 로컬에서 돌릴 생각을 잠깐 했었지만 제가 감당하기에는 꽤 복잡한 설정과 스택을 요구해서 직접 페디버스 연동 서비스를 구동하지는 않고 있었습니다. 그런데 hollo는 설정과 스택이 단순해 쉽게 접근할 수 있습니다. hollo 본체, 데이터베이스만 있으면 구동 시킬 수 있고 필요에 따라 오브젝트 스토리지 컨테이너를 추가할 수도 있습니다만, 저 혼자 사용하기에 오브젝트 스토리지가 필요하지는 않다고 생각해 데이터베이스만 사용하고 있습니다. 여기에 인터넷에 연결하기 위한 cloudflared를 추가해 총 세 개의 컨테이너만으로 돌아갑니다. 이 소프트웨어의 핵심은 클라이언트를 제공하지 않는 이른바 ‘헤드리스’ 모양으로 동작한다는 점입니다. 그래서 별도 클라이언트를 사용해야 합니다. 제 경우에는 이전에 마스토돈을 사용할 때는 Ivory라는 앱을 사용했는데 hollo를 사용한 다음부터는 Phanpy라는 웹 기반 클라이언트를 사용하고 있습니다. 가끔은 Ivory의 정돈된 사용 경험이 아쉬울 때도 있지만 hollo와 Phanpy의 조합도 나쁘지 않습니다.

it-tools는 종종 사용할 일이 있는 온갖 자잘한 도구를 모아 놓은 웹사이트입니다. 사실 굳이 이런 서비스를 직접 구동하지 않아도 구글에 1초만 투자해 검색하면 똑같은 역할을 하는 사이트를 얼마든지 발견할 수 있습니다. 다만 그런 서비스를 사용하기에 마음이 불편할 때가 있습니다. 가령 텍스트를 암호화하거나 복호화 할 때, 비밀키와 공개키 조합을 만들 때, 텍스트를 간단히 Base64로 인코딩하거나 디코딩 할 때 서비스가 이 텍스트들을 기록하지 않을지 걱정됩니다. 특히 비밀키, 공개키 조합을 만들고 싶을 때 분명 이를 수행하는 훨씬 안전한 도구들이 로컬에 있지만 이들을 사용하는 것 보다 그냥 웹사이트에서 버튼을 눌러 텍스트를 얻는 쪽이 제 입장에서는 훨씬 편리합니다. 하지만 구글 검색 상위에 노출되는 이런 역할을 하는 서비스들이 과연 무엇을 위해 이런 편리한 서비스를 제공하고 있는지 의심스러울 때가 있습니다. 이들이 사용자에게 알리지 않고 조용히 온갖 텍스트를 수집했다가 이를 활용해 인터넷에 돌아다니는 암호화된 텍스트를 복호화 하는 시도에 사용될 수 있지 않을까 생각해봤습니다. 너무 멀리 갔나 싶다가도 이 시나리오는 너무 단순하고 실행하기 쉽기 때문에 누구라도 할 것 같습니다. 이런 무서운 세계에서 제가 직접 구동할 수 있는 비슷한 역할을 하는 서비스가 있다면 문제는 훨씬 단순해집니다. 이 서비스가 아무것도 기록하지 않고 또 인터넷을 통해 아무것도 발신하지 않는다는 사실을 알고 있고 또 그러지 못하도록 설정해 놓은 덕분에 이 소프트웨어가 제공하는 온갖 변환 기능을 찜찜함 없이 편안하게 사용할 수 있습니다.

kono는 지난번에 마스토돈을 온프레미스 환경으로 이전해 온 것입니다. 위에서 hollo를 사용하기 시작한 이유 중 하나로 마스토돈을 온프레미스 환경에서 직접 구동하기가 좀 까다로워 보인다는 것인데 결국 시간이 지나고 보니 마스토돈을 온프레미스 환경에서 구동하게 됐습니다. 이전까지는 고스트처럼 마스토돈 역시 온프레미스 환경에 적은 비용을 지불하고 있었습니다. 제가 서버 환경에 아무 것도 신경 쓸 필요가 없었고 또 최신 버전으로 업데이트가 칼 같이 제공되었습니다. 또 최신 버전에 생긴 문제를 관리자가 빠르게 수정하기도 하고 또 알려진 보안 문제에 마스토돈 개발자들보다도 더 빨리 임시 대응했다가 마스토돈 새 버전이 나오면 다시 이를 적용하기도 했습니다. 이전까지 사용해 오던 매니지드 서비스에 불만이 전혀 없었지만 고스트를 온프레미스 환경으로 옮겨 오면서 이제 돈을 내고 있는 매니지드 서비스는 컨플루언스 클라우드와 마스토돈 뿐이라는 사실을 깨달았습니다. 컨플루언스는 거의 제 두뇌를 대신하는 역할을 하고 있어 이 서비스의 구독을 중단하는 일은 아마도 일어나지 않을 겁니다. 하지만 마스토돈은 비용을 줄일 수 있을 것 같았습니다. 특히 이 마스토돈 서버는 소수의 릴레이에만 연결되어 있고 또 여느 마스토돈 서버들이 그러는 것처럼 운영자가 캐릭터성을 가지고 행동하고 있지도 않기 때문에 사용자가 많지 않습니다. 마스토돈을 사용하기 시작한다면 마스토돈 공식 서버를 선택하면 되기 때문에 굳이 다른 서버를 사용할 이유도 별로 없습니다. 하지만 일단 서비스를 시작했고 사용자가 있는 이상 이를 중단하는 것은 예의가 아니라고 생각했습니다. 그래서 제 나름대로는 꽤 고생한 끝에 마스토돈을 온프레미스 환경으로 옮겨 왔습니다. 매니지드 서비스에서는 상위 요금제로 올려야 사용할 수 있었던 더 큰 미디어 스토리지, 데이터베이스 스토리지, 스트리밍 스레드를 이제 마음껏 크게 설정할 수 있게 되었습니다만, 다른 여느 컨테이너들처럼 유지보수 부담을 안게 되었습니다.

librespeed는 클라이언트와 서버 사이에 네트워크 속도를 측정합니다. 마치 fast.com 같은 역할을 하는데 이걸 클라이언트와 홈랩 사이에 적용한다고 보면 됩니다. 다른 기능 없이 그냥 속도를 측정해 주고 이를 sqlite 파일에 기록합니다만, 아직까지는 기록을 볼 방법을 제공하지도 않습니다. 별도로 sqlite 파일을 읽을 수 있는 소프트웨어를 사용해야만 합니다. 처음에는 외부에서 서버까지 속도를 측정할 용도가 있을 거라고 생각했습니다. 하지만 모니터링 소프트웨어가 있는 이상 굳이 별도로 속도를 측정할 필요가 별로 없다는 사실을 깨달았습니다. 특별히 제거할 필요가 없어 그냥 놔 두고 있습니다만, 조만간 메인터넌스 때 제거하지 않을까 싶습니다.

matomo는 구글 애널리틱스를 대신할 목적으로 사용하는 웹 통계 소프트웨어입니다. 이미 구글 애널리틱스를 사용하고 있고 개인적인 사용 수준으로는 유료 요금제가 필요하지도 않았습니다. 다만 구글 애널리틱스에서 제가 필요로 하는 뷰를 만들기 위해서는 상당히 귀찮은 과정을 거쳐야 했습니다. 그래서 장기적으로 구글 애널리틱스를 대체할 목적으로 웹 통계 소프트웨어를 직접 구동하기로 마음먹었습니다. 같은 역할을 하는 여러 소프트웨어가 있었는데 제가 주로 보고 싶은 정보는 방문자 수 같은 정보보다는 유입 경로, 유입된 페이지, 사이트 내부에서 이동 같은 것들이었습니다. 웹사이트 규모가 작으니 통계에 가까운 정보 보다는 사용자들의 구체적인 행동으로부터 배울 점이 더 많았습니다. 가령 유입 검색어와 유입 페이지를 보면 검색엔진이 검색어에 따른 올바른 정보를 제공하고 있는지 여부를 짐작할 수 있습니다. 이 정보로 제가 할 수 있는 일은 검색어를 보고 사용자의 의도를 예상한 다음 검색엔진이 보여준 페이지가 그 의도를 만족하는지 살펴보고 만약 의도를 만족하지 못했을 것으로 판단하면 의도를 만족할 만한 정보를 포함한 페이지를 만듭니다. 이런다고 제가 어떤 이익을 얻지는 않지만 온라인 상에 텍스트 모양으로 어떤 정보를 제공하고 있는 이상 기왕이면 검색엔진이 중간에서 제 역할을 하지 못하더라도 웹사이트 수준에서 사용자들의 검색 목적을 추측해 여기에 정확히 답하는 페이지를 만들어 미래의 사용자들에게 도움을 줄 수는 있을 겁니다. 다만 처음에는 어느 정도 서비스가 안정되면 구글 애널리틱스를 제거할 작정이었습니다만, 아직도 두 서비스를 함께 사용하고 있습니다.

n8n은 IFTTT나 Zapier 같은 자동화를 대신해 줍니다. 이들만큼 미려한 인터페이스나 이들만큼 훌륭한 연동 수준을 제공하지는 못하는 것 같지만 직접 호스팅 할 수 있는 비슷한 도구 중 가장 나아 보입니다. n8n을 사용하기 전까지는 아이폰에서 ‘단축어’를 적극적으로 사용했습니다. 이 도구가 강력하다는 점에는 이견의 여지가 없습니다만, 로직이 조금만 길어져도 코드 내비게이션 자체에 문제가 생길 뿐 아니라 아이폰, 맥OS 사이에 의존성에 따른 호환성 문제가 생기기도 하고 또 디버그, 버전관리 환경을 아무 것도 제공하지 않아 로직을 만들고 유지하기 상당히 고통스러웠습니다. 반면 n8n은 노드를 연결해 가며 로직을 구성할 수 있고 이를 큰 모니터로 볼 수 있을 뿐 아니라 로직이 서버에서 돌아가기 때문에 근본적으로 아이폰과 맥OS 사이를 오가며 겪던 호환성 문제를 겪지 않을 수 있습니다. n8n을 사용해 신용카드 사용 내역을 후잉 가계부로 전송하고 메일을 확인해 지라에 할 일이 등록되도록 합니다. 아이폰 단축어 앱을 사용할 때는 아이폰으로부터 다양한 트리거를 설정할 수 있었습니다. 가령 지오펜스 이벤트, 날씨 이벤트, 앱의 특정 상태 이벤트 등을 받을 수 있었는데 서버에서 구동되는 n8n으로는 그렇게 할 수 없었습니다. 하지만 아이폰에서 아벤트가 일어나면 n8n을 호출하도록 해 단축어는 그저 아이폰에서 이벤트를 감지하고 이를 n8n에 넘겨주는데까지만 작성하고 나머지는 n8n에서 처리하도록 해 작성하기 어려운 긴 단축어를 만들지 않게 됐습니다. IFTTT나 Zapier는 몇 개 안 되는 자동화를 사용하려고 해도 적지 않은 돈을 지불해야 하지만 n8n을 직접 호스팅하면 이 제한으로부터 완전히 자유로워져 다양한 시도를 해볼 수 있습니다. n8n 역시 유료 버전이 있지만 직접 호스팅 하는 환경에서 비용 걱정 없이 여러 가지 시도를 해볼 수 있어 큰 도움을 받고 있습니다.

open-webui는 여러 곳에서 돌아가는 AI들과 연결해 같은 인터페이스를 사용하도록 해 주는 소프트웨어입니다. 처음 로컬에서 LLM을 구동할 생각으로 맥미니에 64기가 램을 붙였는데 n8n을 사용해 이들과 연결하는 환경을 만들 수 있기는 했지만 생각만큼 유용한 뭔가를 만들기는 쉽지 않았습니다. 특히 MCP가 등장하기 전에는 n8n으로 아슬아슬하게 기워 프로토타입에 가까운 간신히 동작하는 뭔가를 만들 수는 있었지만 실 사용에는 문제가 많았고 금세 이런 시도에 시들해졌습니다. open-webui는 n8n으로 꽤 피곤하게 만들던 웹 기반 프롬프트 인터페이스를 그 뒤에 있는 로컬, 리모트 AI와 검색 서비스 등을 간단한 설정으로 묶어 사용할 수 있게 해 줍니다. 그저 원격에서 웹 기반으로 텍스트를 주고 받는 단순한 프롬프트를 만들려 해도 이전에는 n8n으로 웹 주소를 만들고 프롬프트를 받아 AI에 전달하고 다시 받아 표시하도록 직접 만들어야 했지만 이제 이 정도는 그냥 마우스로 설정 몇 가지만 하면 간단히 동작합니다. 하지만 처음 생각했던 것과는 달리 상용 AI 서비스들이 아주 빠르게 발전하고 개선되면서 로컬에서 구동하는 작은 AI 모델이 충분히 효율적이지 않은 상태가 되어 요즘은 별로 사용하지 않게 되었습니다.

p4d는 개인 파일 관리에 사용하는 퍼포스 서버입니다. 제가 일하는 업계에서는 리파지토리에 대용량 바이너리 파일이 많아 git을 사용하는데 상당한 부담이 있습니다. git은 작은 텍스트 파일과 아주 크지 않은 리파지토리를 잘 운용하는 것 같지만 리파지토리의 최신 버전이 수 백 기가에 달하는 상황이 되면 근본적으로 DVCS 환경을 유지할 수 없게 됩니다. 퍼포스는 거대한 바이너리 파일이 난무해 거대한 리파지토리가 만들어져도 이를 멀쩡하게 처리해 주는 몇 안되는 CVCS 환경을 제공합니다. 개인적인 거의 모든 기록을 컨플루언스 위키에 기록함에 따라 파일 모양의 기록이 크게 줄어든 것은 사실이지만 여전히 작업 결과로 파일을 만들 일이 아예 없어지지는 않았습니다. 가령 마이크로소프트 오피스 도구를 사용해 작업하면 작업 결과는 파일 모양으로 남습니다. 원드라이브에 저장해 자동 버전 관리와 안전한 백업을 받을 수도 있지만 이 과정이 제가 원하지 않는 시점에 자동으로 처리되는 동작이 마음에 들지 않았습니다. 저는 프로그래머가 아니어서 제 작업 결과는 주로 바이너리 모양으로 만들어지기 때문에 이들을 제 입맛에 맞게 버전 관리하고 또 백업하는데 퍼포스가 어울린다고 판단했습니다. 퍼포스는 계정 다섯 개 까지 무료로 사용할 수 있어 개인적인 수준에서 사용하기에 충분합니다. 또 일할 때 사용하는 것과 같은 도구를 사용하기 때문에 도구에 더 익숙해질 수 있다는 장점도 있습니다. 버전 관리 뿐 아니라 퍼포스 서버를 안전하게 백업하고 있으면 클라이언트 각각을 백업하는데 집중하지 않아도 됩니다. 중요한 모든 파일은 퍼포스 서버에 있어 퍼포스 서버만 백업하면 나머지 기계를 백업할 이유는 기계를 교체할 때 빠른 복원 뿐입니다. 퍼포스는 지난 수 십 년에 걸쳐 대규모 리파지토리를 안정적으로 운용해 왔고 아마 앞으로도 그럴 겁니다. 개인 수준에서 바이너리 파일이 많이 나타나고 이들을 버전 관리 하고 싶다면 퍼포스를 추천합니다.

portainer는 도커 환경을 웹을 통해 제어할 수 있게 해 줍니다. 컨테이너 각각이나 스택을 실행하고 정지할 수 있고 이들의 현재 상태를 볼 수도 있으며 컨테이너 각각에 터미널을 통해 접근할 수도 있고 이들의 실시간 로그를 살펴볼 수도 있습니다. 처음 홈랩 환경을 구축한 다음 가장 자주 들락달락 하던 서비스였습니다. 하지만 최근에는 portainer 대신 터미널 환경에서 동작하는 lazydocker를 더 즐겨 사용하고 있어 이 서비스는 터미널에 접근할 수 없는 비상 상황에 대응할 용도로만 남겨 두고 있습니다.

uptime-kuma는 웹 기반의 서비스 모니터링 도구입니다. 위에서 ‘beszel’이라는 모니터링 도구를 소개했는데 이것과 다른 점은 ‘beszel’이 주로 프로세서, 메모리, 스토리지, 네트워크 사용에 초점을 맞추고 있다면 ‘uptime-kuma’는 서비스 단위의 현재 상태, 응답 속도를 모니터링하는데 초점을 맞추고 있다는 점입니다. 또 모니터링 결과를 스테이터스 페이지로 만들 수도 있습니다. 만약 모니터링 기능만 필요했다면 Uptime Robot에 무료 기능으로도 충분했겠지만 스테이터스 페이지를 만들기 위해서는 비용을 지불해야만 합니다. 그래서 ‘uptime-kuma’를 사용하기 시작했습니다. 지금까지 소개한 여러 서비스들이 정상 동작하고 있는지, 응답 속도는 어느 정도인지를 모니터링 해 기록해 주고 또 서비스가 중단되면 틀레그램 메신저로 메시지를 보내도록 설정하고 있습니다. 처음 기대한 것은 서비스 별로 상태를 모니터링하고 스테이터스 페이지를 운영하는 것이었습니다만, 서비스 별 상태 모니터링은 그리 유용하지 않았습니다. 도커 환경에서 동작하는 컨테이너들은 도커 엔진이 크래시되어 모든 서비스가 한 번에 중단되거나 가정용 인터넷에 장애가 생겨 접근 불가능해지지 않는 이상 서비스 단위로 모니터링 할 필요가 거의 없었습니다. 도커 환경에서 모든 서비스는 모두 정상이거나 모두 비정상인 경우가 거의 대부분이었습니다. 그래서 어떤 서비스 상태가 정상이 아니라면 모니터링 서비스가 동시에 비정상일 때가 대부분이어서 그리 유용하지 않았고 이런 모니터링 서비스는 독립된 별도의 장비를 사용해야 한다는 교훈을 얻었습니다. 하지만 여전히 스테이터스 페이지는 유용하기에 사용하고 있고 또 외부로부터 모니터링은 ‘Uptime Robot’의 무료 범위에 의존하고 있습니다.

webtop은 도커 환경에서 구동되는 원격 리눅스 머신입니다. 업무용 장비에서 개인 컨플루언스 위키에 접근하거나 사용이 금지된 메신저를 사용하고 싶을 때 VPN을 통해 웹브라우저에서 접근할 수 있는 리눅스 GUI 환경이 있으면 굉장히 편합니다. 로컬 서버로부터 격리되어 있지만 인터넷을 사용할 수 있고 또 어지간한 리눅스 기반 소프트웨어를 사용할 수 있습니다. 아마도 로컬 환경에서 접근하면 훨씬 높은 프레임 레이트로 빠르게 동작하는 것 같지만 클라우드플레어 터널을 통해 서비스 하고 있기 때문에 로컬 데스크탑 환경에 비해서는 아무래도 굼뜨게 움직이는 것이 사실입니다. 하지만 업무 환경에 아무것도 설치하지 않고 사용할 수 있어 유용합니다. 이 환경을 갖춰 놓은 다음에는 제가 통제하는 안전한 환경에서도 종종 습관적으로 원격 리눅스 환경을 사용할 때도 있는데 이쯤 되면 ‘이게 뭐 하는 짓인가’ 싶은 생각이 들기도 합니다. 살펴보니 리눅스 뿐 아니라 도커 기반으로 윈도우를 돌릴 수도 있는 모양인데 리눅스와는 비교할 수 없을 정도로 높은 사양을 요구했고 또 제가 사용하는 소프트웨어가 모두 리눅스 환경에서도 제공되어 윈도우를 시도하지는 않았습니다.

웹 기반 서비스는 모두 클라우드플레어 터널을 사용해 서비스하고 있습니다. 다른 사람들의 홈랩을 살펴보니 traefik을 사용해 리버스 프록시를 로컬에 구동하는 경우가 많았는데 제 관점에서 리버스 프록시는 근본적으로 내 서버 앞단에서 동작해야 의미가 있다고 생각했습니다. 그래서 리버스 프록시는 완전히 클라우드플레어에 의존하기로 했습니다. 특히 클라우드플레어 터널을 사용하면 캐시 설정을 조정해 블로그나 마스토돈 서버로부터 더 적은 미디어 파일만 발신되도록 할 수 있고 홈랩 서버와 클라우드플레어 사이의 연결에 아무 포트도 노출하지 않아도 되기 때문에 초보자가 최소한의 보안 수준을 달성하는데 도움을 줍니다. 여기에 몇몇 서비스는 테일스케일을 통해 로컬 네트워크처럼 접근할 수 있어 퍼블릭 인터넷에 아예 노출되지 않도록 만들 수도 있어 클라우드플레어 터널과 테일스케일을 적극적으로 활용하고 있습니다.

이제 남은 일은 도커 컨테이너 기반으로 서비스를 운영하며 컨테이너 각각을 유지보수 하는 일, 이 환경 전체를 안전하게 백업하는 전략, 더 많은 스토리지가 필요해짐에 따라 지금 수준의 단순한 하드웨어를 유지하는 선에서 스토리지 규모를 확장할 방법을 찾아내기 같은 것들입니다. 앞서 잠깐 소개한 것처럼 AWS와 여러 매니지드 서비스를 사용하던 것을 모두 온프레미스 환경으로 옮겨 왔지만 아직까지는 AWS에 이 모든 인프라 비용을 지불하는 것 보다 더 많은 비용을 지출한 상태입니다. 앞으로 몇 개월이 더 지나야 그 시점까지의 AWS 비용과 제가 하드웨어 구입에 사용한 비용이 거의 같아지게 됩니다. 그 다음부터는 비용을 절약할 수 있게 되는데 그 때가 되면 비용을 얼마나 절약할 수 있게 되었는지 살펴보는 것도 재미있을 것 같습니다. 1년 이상 홈랩을 운영해보니 굳이 기술에 대해 많은 지식이 없어도 필요로 하는 서비스를 도커 기반으로 운용하기 굉장히 편하다는 사실을 알게 되었습니다. 만약 24시간 돌려도 괜찮은 컴퓨터가 있다면 충분히 시도해볼 만 하다고 생각합니다.