장기적으로 비용을 낮추기 위한 온프레미스 전환

지난 44호 커버스토리 세 가지 신화 끝부분에 지난 5년 동안 사용해 온 AWS 라이트세일을 통해 구동하던 제 여러 가지 일을 도와주던 서버를 클라우드에서 온프레미스로 전환했다는 이야기를 했습니다. 5년 전에 라이트세일에 처음으로 서버를 만들어야겠다고 결정한 이유는 생활의 자잘한 부분을 자동화 해 주는 환경이 제 데스크탑에 있으니 데스크탑을 항상 켜 놔야 하는 제약이 있었고 시스템을 재시작 하거나 환경이 바뀔 때 영향을 받는 점이 불편했기 때문입니다. 이 즈음에는 마지막 아르바이트의 유산으로부터 편안하게 사용할 수 있던 PHP, MySQL 스택으로 제 요구사항에 잘 맞는 남이 만들어 놓은 소프트웨어를 찾을 수 없을 때 부득이하게 직접 스크립트를 만들어 돌렸는데 제 데스크탑에서 직접 이들을 구동하기 보다 비용을 조금 내고 24시간 구동되는 클라우드 상의 서버를 사용하면 좋지 않을까 하는 생각을 했습니다. 그렇게 2024년 초봄 기준 라이트세일에 월 3.5달러 짜리 가장 작은 리눅스 인스턴스를 사용하기 시작했고 시간이 지나며 월 5달러, 그리고 월 10달러 짜리 인스턴스로 확장해 현재에 이릅니다.

5년의 시간이 흐르며 이 작은 리눅스 서버는 제 생활을 기록하는 여러 부분을 담당합니다. 가령 잠 자기 시작하고 또 알람을 느끼고 잠에서 깨어나거나 또 자리에서 일어나는 습관을 기록한 다음 잠에서 깨는 습관, 폰을 집어드는 습관에서 이를 소개하기도 했는데 잠 자기 시작하거나 알람을 멈추거나 미루는 행동은 아이폰이나 애플워치에서 일어났지만 이 이벤트는 서버에서 돌아가고 있는 MySQL 데이터베이스에 기록해 줍니다. 비슷한 요령으로 아이폰을 통해 감지하는 여러 이벤트를 서버에 자동으로 기록했는데 하나하나 기록할 때는 아무런 의미가 없었지만 이들이 1년 이상 쌓이자 흥미로운 경향을 살펴볼 수 있는 데이터가 되었고 데이터베이스를 편안하게 조회하기 위해 phpmyadmin을 설치해 그냥 브라우저 상에서 데이터베이스 상의 기록을 살펴보고 궁금한 점을 쿼리로 만들어 조회하며 궁금함을 해결할 수 있게 되었습니다.

또 몇 년 전 마지막으로 사용하던 도쿠위키를 뒤로 하고 핵심 기록 수단으로 사용하기 시작한 컨플루언스 위키는 분명 훌륭했지만 그 이전에 사용하던 도쿠위키 기록을 이전할 수 없었습니다. 사실 도쿠위키 기록을 컨플루언스 위키에 어느 한 스페이스로 모두 마이그레이션 하려고 여러 가지 방법을 시도했는데 어느 것 하나 제대로 동작하지도 않았고 또 어쩌다 마이그레이션이 일부 성공하더라도 그 결과가 전혀 마음에 들지 않았습니다. 도쿠위키와 컨플루언스는 개발 철학이 완전히 달랐고 저 자신도 모르게 그런 철학에 자연스럽게 근거해 작성한 위키 문서는 양쪽 위키 사이에 자동화된 마이그레이션을 극도로 어렵게 했는데 특히 철학에 따라 달리 기록된 여러 문서 연결 방법들은 직접 마이그레이션 도구를 만들려 해도 마이그레이션 된 결과를 상상하기조차 어렵게 만들었습니다. 고민 끝에 그냥 이전에 사용하던 도쿠위키를 모두 다운로드 한 다음 윈도우 기반에서 배치파일을 실행하면 잠시 로컬에 웹서버를 만들어 위키에 접근할 수 있게 해 주는 스크립트의 도움을 받아 이전에 사용하던 위키에 정보가 필요할 때 도움을 받았지만 매번 의식적으로 위키를 실행하는 행동은 상당히 불편해 이전 위키를 조회해야 할 상황에 좀 더 소극적으로 행동하게 만들었습니다. 하지만 클라우드에 항상 켜져 있는 서버가 있으니 도쿠위키를 여기 올려 놓고 항상 동작하게 했는데 이제 위키는 그냥 아무데서나 웹 주소로 접근할 수 있게 됐고 이전 처럼 뭘 따로 실행할 필요가 없어 몇 년 동안 사용한 기록에 소극적으로 접근하지 않게 됐습니다.

작년에 처음 n8n이라는 자동화 도구를 알게 되었는데 IFTTT나 Zapier가 조금만 본격적으로 활용해 보려고 해도 상당한 금액을 요구해 무료 범위 안에서 아주 소극적으로 사용할 수밖에 없었습니다. 특히 활성화된 자동화 갯수에 과금하는 체계는 자잘한 재미를 위한 간단한 자동화를 만들 수가 없도록 만들었는데 가령 퇴근 시간 즈음에 밖에 비가 오면 슬랙에 비 온다고 말하는 것 같은 간단한 자동화를 만들고 싶어도 이런 자동화 갯수에 과금하는 환경에서는 도통 시도할 수 없도록 만들었습니다. 실은 Zapier에 서로 다른 이메일 계정 여러 개를 만들어 각기 무료 범위인 다섯 개 까지 자동화를 만들어 관리해 자잘한 자동화를 유지할 수 있긴 했지만 그리 즐거운 경험은 아니었고 또 이런 거 하자고 매달 상당한 돈을 내는 것도 적절하지 않다는 생각을 하게 만듭니다. 그런데 n8n은 이들만큼 강력하지도 않고 또 이들만큼 광범위한 서비스를 지원하지도 않았지만 그래도 어지간히 널리 알려진 수많은 서비스를 지원했고 IFTTT처럼 아주 간단한 자동화 외에도 여러 단계로 구성된 자동화도 그럭저럭 만들 수 있어 활용 범위가 넓습니다. 특히 그동안 아주 오래 전에 배운 PHP 스크립트를 통해 보안 상 아주 위험하게 동작하던 자동화 전부를 n8n으로 옮기고 보안 상 문제가 있던 PHP 스크립트를 완전히 제거해 큰 도움을 받았습니다.

돌고 돌아 퍼포스에 소개한 대로 한동안 용도에 맞지 않는 버전 관리 도구인 깃을 어떻게든 사용해 보려고 노력하다가 깃은 제 개인적인 용도에도 잘 맞지 않는 도구라는 결론을 내리고 익숙하고 또 제 요구사항을 잘 대응할 것이 분명한 도구인 파포스로 전환합니다. 퍼포스 제작사가 주장하는 최소 사양은 램 4기가이지만 램이 2기가 뿐인 월 10달러 짜리 서버에서도 무리 없이 동작해 항상 켜져 있는 서버에 퍼포스 서버를 구동할 수도 있게 되었습니다. 다만 퍼포스 같은 버전 관리 도구들은 버전을 관리하고 파일과 파일의 히스토리를 잃어버리지 않도록 해 주지만 그 댓가로 많은 스토리지를 사용하는데 이 점 때문에 클라우드 상에 더 큰 스토리지를 사용하도록 설정할 수밖에 없었고 이는 클라우드 이용 요금을 크게 증가시킵니다. 한동안 가난뱅이의 버전관리 서버 운영에 소개한 대로 제가 잠 자기 시작하고 또 알람이 울려 자리에서 일어나는 시점의 이벤트를 받아 제가 잠 들어 있는 동안에는 버전관리에 사용하는 서버를 멈춰 요금을 내지 않도록 해봤지만 이 방법만으로는 한계가 있었습니다. 하지만 만약 이를 제 데스크탑에 직접 돌렸다면 훨씬 더 불편하고 또 훨씬 더 관리해야 할 요소가 많아 적극적으로 버전 관리 환경을 사용하는데 어려움이 있었을지도 모릅니다. 이런 여러 서비스. 마스토돈 서버, 블로그 웹사이트 등등의 상태를 모니터링하는 서비스를 구동하고 서비스 중인 블로그 웹사이트에 직접 해볼 수 없는 설정을 실험하기 위해 똑같은 소프트웨어를 설치해 놓고 똑같은 환경을 만든 다음 여러 가지 설정을 테스트 하기 위한 고스트, 2024년 초봄 현재 액티비티펍 네트워크에 성행하고 있는 스팸을 차단하는 서비스 등 필요한 여러 가지 서비스들이 돌아가고 있습니다.

사실 곰곰이 생각해 보면 다른 여느 사람들은 이런 서버의 도움 없이도 일상 생활을 잘만 영위하고 있는데 뭔가 오버스러운 행동이 아닌가 하는 생각을 여러 번 해봤습니다. 가령 어지간한 자동화는 아이폰 로컬에서 사용할 수 있는 단축어 앱 만으로도 거의 완벽하게 해낼 수 있습니다. 특히 한동안은 단축어를 만드는데 정신이 팔려 출퇴근하는 지하철 안에서 폰을 들고 그래프를 이어 붙여 원하는 대로 동작하는 단축어를 만들곤 했는데 이게 너무 재미있어 출퇴근 시간이 순식간에 지나가 버리기도 합니다. 하지만 아이폰 단축어 앱은 디버깅 환경이 아무것도 없어 로직이 조금만 길어져도 이게 제대로 동작하고 있는지 확인하기 쉽지 않았고 디버딩을 위해 로그를 남기는 로직을 추가하자 그렇잖아도 조금만 길어져도 파악하기 쉽지 않은 로직은 더더욱 길어져 로그를 보고 잘못된 곳을 찾았지만 이 부분을 단축어 그래프 상에서 찾아내기 위해 한참을 신경 써서 스크롤 해야 하기도 했습니다. 또 어지간한 이벤트를 감지하면 아이폰 로컬에 직접 기록할 수도 있었을 겁니다. 한동안 아이폰에서 단축어 앱이 감지한 이벤트를 기록하기 위해 여러 방법을 테스트 하다가 결국 오토메이션 로그는 결국 애플 노트에만 찍기로 했고 이 방법은 잘 동작했지만 기록에 기반해 통계를 내 보려고 하자 갑자기 귀찮은 텍스트 처리 문제로 바뀌었고 여러 노트에 걸친 기록을 CSV 모양으로 만드느라 데이터를 탐색하며 노는데 집중하기 어려웠습니다. 이런 문제는 서버 기반의 데이터베이스를 도입하며 완전히 해결됩니다.

또 백업을 잘 한다면 굳이 개인이 버전 관리 소프트웨어를 별도로 사용할 필요도 그리 크지 않습니다. 만약 제가 본격적으로 코드를 만드는 직업이었다면 본격적으로 버전 관리 도구를 사용해야만 했을 겁니다. 그랬다면 깃에 별다른 불만을 가지지 않았을 가능성이 높습니다. 하지만 본격적으로 코드를 만들지 않는 제가 만들어내는 파일 대부분은 바이너리 형식이었고 이 파일 뒤에 매번 _202400204나 _최종 같은 접미사를 붙이는 어려운 방식으로 파일을 관리할 만큼 제가 똑똑하지도 않았습니다. 백업을 잘 한다면 이 파일들은 시간 단위로, 혹은 날짜 단위로 백업 되어 이전 버전이 필요할 때 활용할 수 있겠지만 작업하며 이전 버전이 필요할 때는 제가 원하지 않는 일정한 시점마다 생성된 스냅샷은 별 도움이 되지 않았습니다. 가령 프리젠테이션 파일을 만들다가 어떤 큰 변경을 가하려고 하는데 이 변경 전후로 스냅샷이 있으면 좋을텐데 단순한 백업 도구는 이런 제가 원하는 시점의 스냅샷을 만들 수가 없습니다. 드랍박스나 아이클라우드 드라이브 같은 서비스를 사용하면 저장할 때마다 모든 버전을 일정 기간 동안 보존해 줬지만 마치 노션처럼 그 이전의 기록은 모두 사라집니다. 대체로 이 이전의 버전 기록을 찾을 일이 드문 것은 사실이지만 1년에 한두번, 혹은 몇 년에 한 번은 이렇게 오래된 스냅샷을 뒤져 위기를 돌파할 일이 있어 오래된 버전이 사라진다는 점이 마음에 들지 않았습니다.

결국 개인 용도로, 그리고 코드가 아니더라도 버전 관리 소프트웨어를 사용해야 한다는 결론에 이릅니다. 그래서 아주 옛날에는 svn을 사용했는데 이는 종종 아주 오래된 리비전 파일이 깨져 있어 이전 리비전으로 돌아갈 수 없는 사고를 종종 겪었고 깃은 커다란 바이너리 파일을 똑바로 처리하지 못했습니다. 그래서 결국 퍼포스로 돌아옵니다. 드랍박스는 그냥 파일을 저장하면 백그라운드에서 파일을 서버에 보내 버전을 보관해 주지만 이번에는 저장할 때마다 모든 버전을 보관한 덕분에 원하는 이전 버전을 찾기 오히려 어려울 때가 있었습니다. 반면 퍼포스 같은 버전 관리 도구를 사용하면 제가 원하는 시점에 코멘트를 붙여 스냅샷을 생성할 수 있기 때문에 스냅샷을 제가 수동으로 통제할 수 있고 제 코멘트에 따라 이전 버전을 탐색할 수 있어 제 요구사항을 정확히 수행합니다. 앞에서 예를 든 프리젠테이션 파일을 크게 변경하려고 할 때 변경 직전 저장하며 코멘트를 붙여 표시해 놓으면 파일 뒤에 접미사를 붙이는 굉장히 어려운 방법으로 파일을 관리할 필요가 전혀 없습니다. 또한 퍼포스 서버는 제 데스크탑 기계와 격리된 데이터센터에 있어 백업 문제로부터 자유롭습니다.

n8n을 사용하는 어지간한 자동화 역시 대부분 별 필요 없을 수 있습니다. 제 여러 행동을 자동으로 기록하는 건 재미있기는 하지만 굳이 그럴 필요는 없습니다. 또 신용카드를 사용할 때마다 전송되는 SMS를 가계부 서비스에 자동 전송해 기록 되도록 하는 것도 그냥 메시지가 올 때마다 제가 직접 포워딩 해도 그리 성가시지 않다는 점을 알고 있습니다. 또 메일함에 제가 항상 처리해야 하는 메일이 도착하면 알아서 지라에 할 일을 등록하고 또 매주, 매월, 매년 그날 그날 할 일이 지라에 등록되는 것 역시 제가 가끔 달력을 보며 다음 할 일을 검토하는 행동으로 대체할 수도 있습니다. 비가 올 때 팀 슬랙에 비 온다고 알리는 일 역시 종종 창밖을 내다보고 비가 오는 것 같으면 직접 메시지를 타이핑 하는 것으로 대신할 수도 있고 블로그 글을 작성하면 달력에 등록해 이 달력에 따라 매일 트위터와 마스토돈에 글을 공유하는 것 역시 그냥 제가 매일 아침 수행해도 충분한 일들입니다. 집에서 인도어 라이딩을 시작하기 전, 후에 아이폰으로 NFC 태그를 스캔하면 지라에서 ‘운동’ 할 일이 자동으로 시작되고 종료되며 운동 내역이 기록된 스트라바 링크가 함께 기록되는 것 역시 대부분은 별 필요 없습니다. 또 매주 같은 날 재활용 쓰레기를 내 놓으며 그 옆에 있는 NFC 태그를 스캔하면 운동과 비슷하게 할 일이 시작되고 종료되며 일정 기간마다 보안 카메라에 찍힌 영상을 별도 보관하고 아침 저녁마다 식물등이 꺼지고 켜지는 동작 역시 그냥 아침에 일어나서 조작하고 또 저녁에 돌아와서 조작하면 되는 그냥 일상적인 일일 뿐입니다. 그런데… 저는 이런 일들을 직접 하고 싶지 않았고 일 자체에만 집중하고 싶었습니다. 그래서 서버가 필요합니다.

지난 수 년에 걸쳐 문제 없이 제 일상생활을 도와주던 AWS 서울 데이터센터에 있던 이 서버에 문제가 생긴 것은 최근에 깃을 포기하고 퍼포스를 본격적으로 사용하기 시작하면서 부터입니다. 깃을 사용할 때는 커다란 바이너리 파일을 올릴 시도 자체를 포기하고 있었습니다. 깃은 전 세계적으로 가장 널리 사용되는 버전 관리 도구이고 여러 장점이 있지만 바이너리 파일을 주로 다루는 입장에서는 편안한 사용 보다는 트러블슈팅에 집중하게 만들어 요구사항을 만족하지 못하고 있었습니다. 반면 퍼포스를 사용하기 시작하면서부터 그동안 버전 관리를 하고 싶었지만 하기 어려웠던 커다랗고 아주 많은 바이너리 파일도 버전 관리 대상이 되기 시작했고 그 동안은 환율이 오르더라도 월 10달러만 내면 이 모든 일을 편안하게 할 수 있었던 것에 비해 추가로 스토리지를 구입해야 했는데 이 스토리지 비용이 서버 비용을 초과하는 상황에 이릅니다. AWS에서 서버에 스토리지를 붙이면 일단 스토리지를 추가 구입해야 하고 매일 같은 시각에 서버를 백업할 때 추가된 스토리지 만큼 백업 용량이 추가되어 이 용량에도 비용을 내야 하는데 한 달 동안 이렇게 사용해 보니 이전에 비해 몇 배에 이르는 금액을 내야 합니다. 앞으로 퍼포스로 관리하는 파일 범위가 늘어난다면 이 비용은 더더욱 늘어나게 될 것이 뻔했는데 이러다가 돈 벌어 제프 베조스 좋은 일만 시키게 될 것 같다는 위기감이 들었습니다.

몇 년에 걸쳐 데이터센터에 작은 서버를 구동하면서 다른 분들이 집 안에 서버를 두는 모습을 지켜봤는데 어지간하면 그러고 싶지 않았습니다. 가장 큰 이유는 하드웨어를 직접 만지고 싶지 않아서였는데 가령 하드웨어에 문제가 생기면 직접 고장에 대응하고 또 고장 난 동안 새 하드웨어를 구입해 대응해야 했으며 재해 상황에 백업으로부터 직접 서버를 재시작해야 합니다. 라이트세일은 만약 하드웨어 장애가 생기면 그냥 이전 스냅샷으로 새 서버를 시작하면 그만이었고 스토리지 문제가 생기면 그냥 가상 서버와 분리해 다른 서버를 만들어 그쪽에 연결하면 끝이었는데 이 모든 과정은 마우스 클릭 만으로 진행할 수 있습니다. 또한 서버 기계가 집 안에 있으면 전기와 네트워크가 끊기지 않고 계속해서 유지되어야 하는데 데이터센터는 이런 환경이 기본적으로 제공되며 만약 이 환경에 문제가 생기면 제가 이 사실을 알기 전에 뉴스로 보도될 겁니다. 현대에는 집에 네트워크나 전기가 안정적으로 지공되기는 하지만 과연 1년 내내 단 한번도 네트워크와 전기가 끊기지 않고 안정적으로 제공될 거라고 보장할 수 있을까요? 전혀 그렇지 않을 겁니다. 그래서 하드웨어를 직접 다루거나 재해 대응을 직접 하거나 네트워크와 전기가 완벽하게 안정적으로 제공되지 않는 가정 환경에 서버를 두지 않아 왔습니다. 그런데 이제 한계가 온 것 같습니다.

지난달 AWS에서 날아온 청구서를 물끄러미 바라보며 백수 주제에 이 비용을 매달 낼 수는 없다는 생각이 들었고 이제 라이트세일에 저렴한 서버만으로는 제 요구사항을 감당할 수 없는 시점이 왔으며 라이트세일에 환경을 유지하며 비싼 월 이용요금을 내거나 여러 달에 걸친 비용을 한번에 지출해 월 비용을 없애는 것 중 어느 하나를 선택해야만 하는 상황을 맞이합니다. 지난달에 청구된 금액은 50달러 쯤 됐는데 서버 비용 10달러를 제외한 나머지 비용은 스토리지 비용이었습니다. 그렇다면 월 약 6만 6천원을 낸다 치면 대략 12개월에서 18개월 치 비용을 한번에 지출하는 선에서 클라우드 환경을 온프레미스 환경으로 바꿀 수 있고 같은 장비를 60개월 이상 사용할 수 있다면 전체적으로 볼 때 월 비용을 이전과 비슷한 수준으로 유지할 수 있겠다 싶었습니다. 여기에 네트워크 요금은 어차피 집에 가정용 인터넷이 항상 들어와 있으니 무시하고 전기요금 역시 무시했는데 이건 전력을 적게 사용하는 장치를 사용하면 역시 계산에서 무시할 수 있는 수준일 거라고 예상합니다. 이런 생각으로 쿠팡에서 크게 할인하던 오래된 맥미니를 지난달 AWS로부터 청구된 금액의 15개월 치에 해당하는 비용으로 구입해 라이트세일에서 구동되던 서비스 거의 전부를 맥미니로 옮겨 옵니다. ‘거의’인 이유는 이전에 너무 오래된 지식으로 만든 PHP 스크립트 전부를 n8n으로 대체했지만 아직 PHP 환경이 남아 있었는데 온프레미스로 옮겨 오면서 PHP는 완전히 없애 버렸기 때문입니다.

이번에 라이트세일에서 구동하던 여러 서비스들을 맥미니로 옮겨 오면서 처음으로 도커를 사용해봤습니다. 사실 도커는 말만 들었고 이게 정확히 무슨 소프트웨어인지 정확히 파악하고 있지도 않은 상태였습니다. 다만 이전부터 여러 소프트웨어가 도커 기반으로 배포되고 있음은 알고 있었고 어느 순간부터는 직접 설치하는 버전보다 도커 버전이 더 강조되어 배포되는 것들도 많다는 점 역시 알고 있었습니다. 그래서 램 2기가 짜리 라이트세일 서버에서 도커를 돌려보려고 했었는데 서비스 하나를 올리자 램이 부족해 죽는 모습을 보고 바로 포기합니다. 거대한 스왑을 설정해 시도해 보기도 했지만 트러블슈팅 하다가 서비스를 못 쓸 수준이어서 이내 포기했습니다. 서버에 여러 서비스들을 직접 설치하는 건 그리 나쁘지 않았지만 몇몇 소프트웨어들이 같은 스택의 서로 다른 버전을 요구하면서 종종 골때리는 문제를 겪곤 했습니다. 가령 앞에서 소개한 고스트, n8n, uptime-kuma는 모두 npm이라는 스택을 요구했는데 이들 각각은 의도적으로 그런 것은 아닐 것 같지만 종종 서로 요구하는 npm 버전이 달랐습니다. 그래서 어느 한 쪽을 업데이트 하면서 별 생각 없이 npm 버전이 바뀌면 나머지 서비스가 구동되지 않아 상당히 골치아팠습니다. 그래서 이번에야말로 도커가 이런 문제를 없애 줄 거라고 기대하고 서버 환경을 모두 도커로 바꾸기로 결정합니다.

맥미니는 램이 8기가여서 맥OS GUI를 다 띄우고 도커 데스크탑을 띄우고 여기에 백업 소프트웨어와 컨테이너 여러 개를 띄워도 아무 문제 없이 동작했습니다. 도커에 대해서 대강 살펴보며 이건 대강 좀 가벼운 VM 비슷한 거라고 인식했는데 다들 VM과는 다르다는 점을 강조하고 있었습니다. 하지만 제 입장에서는 이미지 기반으로 동작하는 VM 비슷한 거고 컨테이너는 휘발성이어서 서버를 계속해서 유지하려면 상태 유지에 필요한 부분을 볼륨이나 파일 모양으로 마운트 해서 별개로 유지해야 한다는 정도로 인식했고 이 인식은 여전히 VM과 별로 다르지 않은 것 같습니다. 아무래도 아마존 데이터센터에 있는 것에 비해 제가 보안을 잘 유지할 수 있을 것 같지 않아 외부에 아무 포트도 열지 않고 모든 서비스가 클라우드플레어 네트워크의 리버스 프록시를 사용해 인터넷과 통신하게 했는데 도커 환경을 처음 사용해 봐서 이들을 서로 같은 가상 네트워크 안에 둬야만 통신할 수 있다는 점을 잘 몰라 트러블슈팅 하는데 시간이 조금 필요했습니다. 일단 리버스 프록시를 통해 컨테이너 각각이 인터넷과 통신할 수 있게 되자 각각의 서비스는 이전 라이트세일 서버와 달리 서로 환경이 격리되어 서로 뭘 하든지 영향을 주지 않게 됩니다. 이전에 npm을 사용하는 서비스 중 하나를 업데이트 하려면 시작하기 전에 스냅샷을 떠 나머지 서비스가 고장날 때 바로 돌아올 수 있게 한 다음 시작하곤 했는데 이제는 그럴 필요가 전혀 없어졌습니다.

이제 기계가 집 안에 있기 때문에 백업을 제가 직접 처리해야 합니다. 처음에는 그냥 타임머신을 사용하면 될 거라고 예상했습니다. 타임머신은 강력하고 단순하고 OS 수준에서 지원해 OS를 시작할 수 없는 상태에서도 접근해 복원할 수 있습니다. 하지만 설정할 수 있는 것이 거의 없어 하다못해 외장 드라이브를 함께 백업하도록 설정할 수도 없었습니다. 그래서 고민 끝에 이전에 여러 이유로 사용을 그만 둔 적이 있는 Arq를 다시 도입해 타임머신과 똑같은 정책으로 1시간마다 한 번 백업하게 하고 이번에는 맥 내장 스토리지와 외장 스토리지 전체를 백업하도록 설정합니다. 이전 시대에 윈도우에서는 거의 사용이 불가능하던 것과 달리 맥에서 Arq는 잘 동작했고 타임머신만큼 단순하고 유려하지는 않고 또 OS를 시작 조차 할 수 없는 상황에 대응할 수도 없기는 하지만 낮은 비용으로 백업을 유지할 수 있어 이 정도로 만족하기로 했습니다.

이렇게 해서 지난 5년 동안 제 생활의 여러 부분을 보조 하던 클라우드 서버는 완전히 온프레미스 환경으로 옮겨 왔습니다. 이 과정에서 지난 달에 가장 많이 청구된 요금을 기준으로 15개월치 요금을 한 번에 지출했습니다. 반면 성능은 램 기준으로 4배, 스토리지 기준으로도 4배 증가했으며 CPU는 몇 배 증가했는지 모르겠지만 적어도 라이트세일 서버 기준의 CPU 성능에 비해 4년 전에 출시된 M1 프로세서가 좀 더 낫지 않을까 싶습니다. 또 라이트세일에서는 CPU 성능을 최대 20% 까지만 사용할 수 있지만 이번에는 100%까지 사용할 수 있습니다. 전기요금을 고려하지 않을 때 월 지출 비용은 0이 됐고 이 환경을 60개월 이상 추가 비용 없이 유지한다면 한번에 15개월 어치 비용을 지출하면서도 60개월에 걸쳐 이전에 월 10달러 수준으로 사용하던 모든 서비스를 똑같이 사용할 수 있게 됩니다. 대신 아직까지는 아마존 서울 데이터센터에 서버가 있을 때처럼 아무데서나 편리하게 모니터링하고 또 제어하기는 좀 어렵게 됐고 또 하드웨어를 제가 직접 관리해야 하며 만약 고장이 발생하면 마우스 클릭 몇 번으로 하드웨어를 교체하는 대신 직접 맥을 들고 애플스토어에 가거나 연결된 하드디스크를 별도로 주문하는 등의 대응을 해야 하며 이것이 온프레미스 환경의 댓가입니다.

이 외에도 처음으로 도커 환경을 사용해 보며 과연 이게 맞나 싶은 찜찜한 구석도 있습니다. 가령 지금은 컨테이너를 띄우고 이들을 살펴보는데 도커 데스크탑이라는 프로그램을 사용하고 있습니다. 실행 중인 컨테이너들을 살펴보고 각각의 로컬에 접속해 살펴보거나 할 수 있지만 실제 서비스를 구동하는 환경에서 이렇게 해도 되는지 잘 모르겠습니다. 이전에 라이트세일 서버는 GUI 환경이 없었기 때문에 갑자기 GUI 환경이 있으니 이게 개발환경에서 사용하라고 만든 소프트웨어인지 아니면 실제 서비스 환경에서도 사용해도 괜찮은 것인지 자신이 없는 상태입니다. 또 도커 이미지들을 살펴보니 상당수는 리눅스 이미지 위에 서비스만 얹어 그냥 root 권한으로 서비스가 동작하고 있었습니다. 이들 중 소수만이 서비스 구동을 위한 별도 사용자를 생성하고 있었는데 물론 컨테이너 각각을 살펴보는 입장에서 편리하기는 하지만 만약 컨테이너 중 하나 이상에 보안 사고가 일어난다면 같은 네트워크에 묶인 모든 서비스가 노출될 수 있겠다 싶습니다. 또 지금은 모든 서비스를 같은 네트워크에 넣고 클라우드플레어 네트워크를 통하게 하고 있는데 보안 수준을 조금 더 높이려면 각 서비스가 서로 격리된 네트워크에 있고 각 네트워크마다 별도로 클라우드플레어 커넥터 컨테이너가 동작하도록 하는 편이 나을 것 같습니다. 하지만 이건 너무나 귀찮을 것 같아 현재 상태가 별로 안전하지 않은 것은 알지만 그냥 두고 있습니다.

몇 년 만에 집 안에 서버 하드웨어를 뒀고 이전과 달리 호화로운 사양에 GUI까지 갖추고 있어 어리둥절하기는 하지만 간만에 도커라는 새로운 환경을 직접 사용해볼 수 있어 즐거웠고 또 제 생활의 자잘한 부분을 보조하는 모든 환경이 똑같이 동작하는 점은 만족스럽습니다. 이제 문제는 앞으로 적어도 60개월 동안 현재 상태를 유지해야만 이전과 같이 월 10달러 수준의 지출과 비슷한 수준을 유지할 수 있으며 그보다 더 오래 사용해야 이익이라는 점인데 애플 하드웨어는 제조사인 애플이 직접 하드웨어와 소프트웨어의 수명을 통제한다는 점이 위험 요소일 수 있습니다. 이미 4년 전에 출시된 하드웨어를 앞으로 5년 더 지원 받으며 사용할 수 있을지는 의심스럽습니다. 반면 아슬아슬하게 제가 직접 조립한 하드웨어에 비해 맥미니는 견고하게 잘 만들어진 것 같고 제 사용 용도 상으로는 그리 험하게 하드웨어를 굴릴 것 같지도 않아 한 60개월 정도는 안정적으로 돌아가지 않을까 하고 희망적으로 생각하기로 했습니다.