맥 미니를 홈 서버로 사용하기

도입

블로그 시작 이래 지금까지 <맥 미니로 홈 서버를 만들어보았습니다>가 조회수 1위를 차지하고 있다. 다만 그 글은 맥 미니를 홈서버 구축을 시도하면서 내 감상을 늘어놓을 뿐이었기 때문에, 제대로 다시 정리할 필요가 있을 것 같다.

나는 맥 미니의 적은 소모 전력, 작은 물리적 크기, 조용한 팬 소리를 이유로 맥 미니를 홈 서버로 채택했다. 이전에는 라즈베리 파이나 OpenWRT를 플래시한 공유기를 홈 서버로 운용했는데, 이것의 연장선상에서 더 높은 성능을 꾀했다고 생각할 수 있을 것이다.

24시간 동작하는 서버 환경이 사실 모든 시스템에 적대적인 환경인 것은 사실이나, 맥 시스템은 특히나 서버로 운용하기에는 상당히 우려스러운 부분이 많다. 맥 미니도 결코 저렴하지는 않기 때문에 홈 서버로 채택하기 전에 고려해야할 점이 있다.

커널에서 fsync(2) 시스템 콜은 디스크 동기화 동작에서 거짓말을 하도록 구현되어있다. #1 #2 속도를 위해 안정성을 포기하여서, 운이 좋지 않다면 정전 상항에서 데이터를 잃을 수 있다. 다른 OS에서는 보지 못한 놀라운 방법의 구현이다.

널리 퍼진 의견들을 살펴보면 애플 실리콘 칩의 높은 전성비가 높은 성능으로 동치되는 경향도 있는데, 이 역시 다시 생각해보아야 한다. 애플 실리콘 칩 성능의 핵심은 맥 시스템에서 주로 이루어지는 작업들을 하드웨어 가속기로 처리하면서 성능 향상을 도모하는 것이지, 칩 자체의 순수 성능이 다른 데스크톱 프로세서에 비해 월등한 것이 아니다.

맥 OS 자체가 애플의 필요에 맞게 굉장히 커스텀되어서, 이렇게 언급한 것들 외에도 다른 운영체제에서 기대할만한 동작이 맥에서는 다르게 동작할 가능성이 높다. 특히 맥 미니를 홈 서버로 운용할 사람들은 소위 일반 사용자는 아닐 것이기 때문에 문제 상황을 더욱 많이 경험한다.

Starting net.minecraft.server.Main
[19:04:01] [ServerMain/WARN]: Failed to get system info for Microarchitecture
java.lang.NullPointerException: Cannot invoke "String.toUpperCase()" because "this.cpuVendor" is null

이는 비단 애플만의 문제는 아니다. <맥 미니로 홈 서버를 만들어보았습니다>에서 언급했던 문제 중에는 소프트웨어 측의 잘못으로부터 비롯된 것도 있었다. 친구들과 함께 플레이할 목적으로 마인크래프트 포켓몬 모드 서버를 맥 미니 위에서 운영하려고 시도한 적이 있었다. 하지만 당시의 포켓몬 모드는 이전 버전의 oshi에 의존하고 있었다. 이전 버전의 oshi는 실리콘 칩의 CPU 벤더와 아키텍처 정보를 제대로 읽어들이지 못했고, 서버는 제대로 동작하지 않았다.

나는 이러한 불편과 문제 상황을 모두 감수하기로 마음먹고 맥 미니를 홈 서버로 운용했다. M 칩이 보급되면서 높아진 맥 점유율로 대부분의 문제는 해결되었을 것으로 생각한다. 그럼에도 다양한 문제가 잠재되어있으므로 홈 서버를 위해서 맥 미니를 새로 구입하겠다면, 홈 서버의 목적, 주로 운용할 소프트웨어, 자신이 감내 가능한 문제 상황이 얼마나 되는지 충분히 고민해보아야 한다.

운용

맥 미니는 주로 홈 서버 VPN의 호스트, 파일 서버, 배포 서버, 배치 작업 처리를 수행했다. VPN 호스트와 배포 서버는 분리하고 싶었는데, 아직까지는 비용을 부담할 준비가 되지 않았다.

홈 서버 VPN의 호스트로 운용

보통 홈 네트워크 외부에서 홈 서버로 접근하기 위해 포트포워딩을 사용하는 경우가 많다. 하지만 필요에 따라 외부 네트워크에 개방해야 하는 포트가 계속 변화해야하고, 개인 목적으로 사용하려는 것인데도 일반에 공개하게 되어 해킹 공격의 우려가 있다.

이 외에도 여러가지 이유로 홈 서버 전용 사설망(VPN)을 구축해 사용하는데, VPN이 포트포워딩을 대체한다는 것은 아니다. 둘은 엄연히 다른 분야의 기능, 기술이고, 상보적으로 사용한다.

VPN 구축에는 와이어가드를 사용했다. 와이어가드는 네트워크 진입점으로 사용할 호스트가 필요한데, 맥 미니가 이 역할을 맡았다. ShapeLayer/dotfiles/wireguard

맥에서 와이어가드 데몬은 자동 실행되지 않아, 직접 plist를 작성해 맥의 init 데몬인 launchd에 등록해야 한다. com.wireguard.wg[n].plist를 참고하여 등록한다. 이 plist는 /opt/homebrew/bin/wg-quick 명령을 실행하는 것이 골자이다.

파일 서버, 배포 서버로 운용

파일 서버라고 하더라도 이미 홈 네트워크에 NAS 장비를 더해 운용하고 있으므로, 맥에서의 파일 서버는 배포 서버의 일환으로 운용하였다. 주로 친구들과 마인크래프트 모드 서버를 플레이할 때, 임시로 모드 적용 프로그램이 패치 파일을 다운로드할 수 있도록 파일을 배포하는 데 사용했다.

그 외에는 주로 백엔드나 정적 페이지로 빌드할 수 없는 웹 페이지를 운용하는데 사용했다. 지금 운용하고 있는 대부분의 웹 페이지는 정적으로 빌드해 배포할 수 있다. 그래서 보통은 pages.dev와 gh pages를 사용하고, 프로젝트 데모, 동아리 모집 폼 등 서버 기능이 필요한 프로젝트에 짧은 기간 동안에만 배포하는 방식으로 사용했다.

호스트해야하는 프로젝트의 환경이 꽤 다양하고, 프로젝트 배포는 일시적이어서 컨테이너화를 하지 않으면 시스템에서 대기하는 런타임이 지나치게 많아지거나, 의존성이 잘못 잡혀 오히려 소요가 커지는 경우가 많았다.

아마 개인적인 문제일 것으로 생각하는데, 홈 서버 운용 초기에는 도커 데스크톱 클라이언트의 응답이 지연되거나 제대로 동작하지 않는 문제가 있었다. 이어서는 대부분을 podman으로 전환하고, 아직 도커를 사용할 소요가 없어 문제가 해결되었는지는 파악하지 않았다.

배치 작업 처리

배치 작업은 특히 인공지능 학습에 유용하게 사용할 수 있었다. 다만 맥 미니가 인공지능 처리에 강점이 있다는 뜻은 아니다. 일반적으로 기계학습에 사용하는 그래픽카드의 성능이나, 코랩 구독으로 사용할 수 있는 가속기에 비해서는 다소 아쉬운 수준이다.

하지만 칩에는 NPU가 통합된데다 최근에는 인공지능 라이브러리의 메탈 플러그인, MPS 백본 지원으로 상황이 나아졌으므로 개인 용도로는 충분하다. 최소한 학부 과정의 인공지능 관계 과목에 맥 미니를 활용했을 때는 큰 불편함이나 아쉬움이 없었다.

인공지능 학습 외에는 크롤링이나 영상 렌더링 등에 사용했던 것 같다.

목적외 사용: VNC 환경

맥 미니로 홈 서버 운용이 어느정도 익숙해지면, 엄격하게 홈 서버를 운용하는것이 아니라 점차 필요에 따라 무언가 예외가 생기기 시작한다. 특히 맥 OS는 서버용 OS라기보다는 일반 사용자용 데스크톱 시스템이기 때문에, 데스크톱 환경을 점차 활용하게 되었다.

내 경우에는 구체적으로 온라인 녹화 강의나, 줌 웨비나 등에서 유용했다.

지난 두 학기 동안에는 캡스톤디자인 프로젝트로, 출석 기간 안에 녹화 강의를 수료할 여유가 없게 되는 상황이 꽤 있었다. 이 때 출석을 위해 녹화 강의를 재생시켜 결석되지 않도록 사용했다. 혹은 줌으로 세미나나 강연이 열리는데 일정이 맞지 않아 듣지 못하게 될 때, 회의실에 참여해서 녹화시키는 용도로 사용했다.

이렇게 사용하면 주로 원격지에서 데스크톱 환경에 접근해야 할 일이 잦다. 이 때 주로 홈 VPN이 연결된 기기에서 VNC 클라이언트로 접근했다. (맥OS에는 공유 설정의 “화면 공유” 항목이 VNC에 해당한다.) 만약 상황이 마땅찮으면 크롬 원격 데스크톱으로 접근하기도 했다.

크롬 원격 데스크톱을 사용하려면 시스템이 부팅되면서 자동으로 로그인하도록 설정해야 한다. 그래서 개인적으로는 VNC를 통해서만 접근하려고 했지만, 사실 현실이 녹록치 않아 어느 순간부터 크롬 원격 데스크톱을 함께 사용하고 있었다.

자동 로그인 설정을 사용하려면 FileVault 디스크 암호화를 비활성화해야한다. 사실 윈도우에서도 비트로커를 사용하는 일이 드물어서 끄고 사용해도 된다고 생각하지만, 기본값을 변경한다는 것이 꽤 기분을 찜찜하게 한다.

목적 외 사용: 간이 VPC 운용

애플 기기 대상으로 애플리케이션을 빌드하는데 있어, 일반적인 방법으로는 맥 os가 꼭 필요하다. 특히 게임 개발 동아리에서 모바일 게임을 개발하면서 맥 os의 수요가 있었다. 아이폰 게임 빌드 용도로 콘텐츠진흥원에서 맥북을 대여해 사용할 수 있긴 하지만, 대여 기간이 짧아서 디버깅을 하거나 대여한 맥북으로 개발을 이어나가는 것은 어려운 모양이었다.

그래서 게임 개발 동아리의 회장을 맡으면서 맥 미니에 VM을 호스팅하기도 했다. 사실 테스트 빌드를 기기에 설치하려면 맥과 기기를 물리적으로 연결해야해서 수요가 크지 않을것으로 생각했다.

실제로는 몇명이 호스트를 받아서 사용했는데, 대강 맥을 한 번도 안써봐서 신기해서 호스트받았다는 회원도 있었고, 빌드하면서 컴파일 오류를 찾아내는데 사용하는 회원도 있었다.

마무리

도입할 때 언급했듯, 맥 미니는 탑 티어 전성비의 칩, 물리적으로 굉장히 작은 크기, 매우 조용한 팬 소음으로 홈 서버에 있어 매우 매력적인 선택지이긴 하다. 특히 눈에 띄는 크기 축소로 주목을 받았던 24년형 맥 미니의 출시 이후에, 이전에 작성했던 맥 미니로 홈 서버 만들기 글의 조회수가 급상승한 것을 고려하면 더욱 그렇다.

하지만 사용 패턴에 따라서는 장점을 상쇄할 단점이 있다. 맥은 POSIX를 따르지만 리눅스의 POSIX와는 차이가 있어, 리눅스와 동일한 방법으로 사용할 수 없다. 가격도 애플 제품 사이에서는 저렴한 편이라고는 하나, 여전히 부담되는 가격이다. (perillamint님이 [KO] RE: 개발자를 꿈꾸는 분들에게 <장비 지원> 부분에서 조금 더 자세히 적어두셨다.)

혹시 홈 서버를 구축하는 데 맥 미니를 새로 구매하려고 한다면, 맥 미니를 구매해서 사용해보고 싶은 것에 가까운지 다시 한 번 따져볼 필요가 있다. 최근에는 맥 미니만큼의 성능은 아니더라도 훨씬 저렴한 x86 아키텍처 미니 PC가 정말 많다. 특히나 N100 시스템이 시장에 굉장히 많이 풀려서 정말 매력적인 선택지가 많이 등장했다.

TL;DR

정리해서, 맥 미니로 홈 서버 운용은 무리 없이 충분히 가능하고 꽤 유용하다. 하지만 다른 시스템보다 문제 상황에 휘말릴 가능성이 높고 피곤한 작업이 될 것이다. 단점과 문제는 대부분 감수 가능한 선에 있지만, 이를 감수하지 않아도 되는 선택지도 많이 있다.