15년 동안 꺼놓지 않은 집구석 컴퓨터가 가져다준 것들

나는 15년 동안 집에서 컴퓨터를 꺼본 적이 없다. 작고 어두운 케이스 안에서 돌아가는 팬 소리와 전면 패널의 LED가 밤마다 작게 깜빡일 때면, 그 소음이 나에게는 이상하게도 일종의 안정을 주었다. 처음에는 남몰래 미디어를 모으고, 여러 기기에서 보는 용도로 썼다. 토렌트 클라이언트가 돌아가고, 거실 TV와 노트북에서 서버의 영상을 스트리밍 해서 보던 시절이 있었다.

그런데 넷플릭스 같은 서비스가 자리 잡고 사회생활을 시작한 뒤로는 용도가 바뀌었다. 파일을 보관하고 동기화하는 ownCloud와 WebDAV가 실사용이 되었고, 지금은 개발과 실험을 위해 계속 켜두는 ‘홈랩’이 되었다. 내가 홈랩 이야기를 꺼내는건, 홈랩을 구축하고 돌려보는 경험이 주는 가치와 성장에 대해 이야기를 풀어보고 싶어서이다.

집에 있는 컴퓨터가 주는 체감

집에서 24시간 돌아가는 컴퓨터는 비용을 몸으로 느끼게 해주는 도구가 되었다. 한 번은 저렴한 하스웰 셀러론 기반 중고 장비에 약 30만 원을 썼고, 이 장비를 1년 내내 집에서 운영하는 데 들어가는 전기와 유지 비용을 계산해보았다. 같은 기간 동안 매달 약 2~3만 원씩 나가는 EC2 인스턴스를 계속 켜두는 것보다 훨씬 저렴했다. 전기세가 생각만큼 폭증하지도 않았다.

여기서 흔히 나오는 질문이 있다. “Vercel이나 Netlify는 무료 티어도 있고, 깃 푸시만 하면 알아서 배포되는데, 굳이 집에서 서버를 돌릴 이유가 있을까?” 처음에는 나도 비슷하게 생각했다. 실제로 사이드 프로젝트를 처음 올릴 때는 Vercel의 배포 경험이 마치 마법처럼 느껴졌고, 얼마간은 그 편리함에 푹 빠져 살았다. 다만 무료 티어가 영원히 무료는 아니라는 것, 그리고 일정 수준을 넘기면 세부 항목마다 가격표가 따라붙는다는 사실을, 비용이 한 번에 확 튀어 오른 다음에서야 뒤늦게 체감했다.

손쉬움이 가려버리는 것들

클라우드의 편의성은 분명 매력적이다. 콘솔에 들어가 클릭 몇 번이면 배포가 끝나고, 자동으로 붙는 CDN과 SSL, 롤백 버튼 하나로 되돌릴 수 있는 배포 이력은, 익숙해질수록 이것 말고 다른 선택지를 굳이 찾을 필요가 있을까 하는 생각마저 들게 만든다. Vercel이나 Netlify처럼 깃 푸시만 해도 알아서 빌드와 배포가 이뤄지는 환경은, 처음 사이드 프로젝트를 올려볼 때 정말 마법처럼 느껴진다.

특히 Vercel이나 Netlify처럼 마법처럼 쉬운 배포 경험은 초반에는 생산성을 크게 올려주지만, 프로바이더가 제공하는 추상화 레이어를 벗어나는 순간 갑자기 할 수 있는 일이 확 줄어든다. 특정 프레임워크와 빌드 방식에 최적화되어 있기 때문에, 조금만 다른 아키텍처를 시도해보면 “이건 지원하지 않는다”는 공식 문서의 각주와 마주치게 된다.

반대로 집에서 돌리는 홈랩에서는, 배포도 결국 내가 직접 다뤄야 하는 하나의 작업이 된다. 단일 서버에서 도커 컴포즈 파일로 서비스를 올려볼 수도 있고, GitHub Actions나 Jenkins 같은 CI 도구를 연결해 단계별로 빌드와 테스트, 배포를 나눌 수도 있다. 프로바이더에 종속되지 않고 내가 이해하는 범위 안에서 배포 전략을 설계해볼 수 있다는 점이 조금 번거로운 만큼 더 많이 배운다는 느낌을 줬다.

엔지니어로서 아키텍처를 이해하고 싶은 마음이 있다면, 최소한 한 번쯤은 이 번거로움을 겪어보는 편이 좋겠다는 생각을 하게 됐다. 코딩의 입문 단계에서는 Vercel이나 Netlify와 같은 클라우드 프로바이더가 제공하는 빠른 배포 경험은 분명 의미가 있지만, 그 이후에는 자신만의 환경을 직접 운영해보는 쪽이 장기적으로 얻을 수 있는 경험이 더 많다고 느껴진다.

아키텍처를 현실에서 검증한다는 것

짧게 켜두는 개발 서버와 24시간 돌아가는 서비스는 전혀 다른 질문을 던져준다. 홈랩을 운영하면서 가장 빨리 발견한 건 메모리 누수 같은 ‘시간 축’의 문제였다. 며칠, 몇 주 단위로 서서히 쌓였다가 어느 순간 응답이 느려지고 프로세스가 죽어버리는 증상은, 로컬에서 잠깐 테스트할 때는 좀처럼 드러나지 않는다. 계속 켜둔 상태에서만 보이는 버그들이라는 걸 몸으로 느끼게 된다.

네트워크 쪽도 비슷했다. 도메인을 직접 구매해서 DNS를 붙이고, 내부 네트워크를 어떻게 나눌지 고민하면서 포트 포워딩과 방화벽 룰을 손으로 일일이 적어넣는 경험은, 예전에 책으로만 읽어봤던 개념을 다시 몸으로 이해하게 해줬다. 그리고 이런 실험을 하다 보면 자연스럽게 외부에서 스캔이나 공격 시도가 들어오는데, 그때마다 보안 정책과 운영 절차를 하나씩 만들어가야 했다. 로그를 뒤져 IP를 차단하기도 하고, 평소에 열어둔 포트와 서비스 목록을 재점검하기도 했다. 공격은 언제나 불편하지만, 동시에 운영 역량을 키우는 강제 훈련장 같은 면이 있었다.

이런 과정을 거치다 보면, 내가 머릿속에서 그려놓은 아키텍처가 문서나 다이어그램 상에서만 작동하는 것이 아니라, 현실의 트래픽과 실패 상황 속에서 어떤 식으로 반응하는지를 조금씩 더 분명하게 볼 수 있게 된다. 이건 클라우드에서도 물론 할 수 있는 일이지만, 모든 선택의 결과가 곧바로 자신의 전기세와 장비 상태로 돌아오는 환경에서는 훨씬 더 또렷하게 체감된다.

URL 하나가 만들어주는 현실감

홈랩의 가장 큰 장점 중 하나는 언제든지 외부에 보여줄 수 있는 ‘살아 있는 URL’을 갖고 있다는 점이다. 사이드 프로젝트를 빠르게 올려놓고, 개발 모임이나 친구들에게 링크를 건네주면, “이 부분이 헷갈린다”, “여기서 멈춘다” 같은 반응이 바로 돌아온다. 배포를 위해 별도의 환경을 준비하거나 요금제를 고민할 필요가 없으니, 작은 실험을 훨씬 가볍게 시작할 수 있다.

출처: Unsplash

이 과정은 비용과도 연결된다. 클라우드에서 유료 플랜을 계속 올려가며 실험하는 것보다, 이미 구축된 홈랩 위에서 하드웨어가 허용하는 한도 내에서 여러 인스턴스를 띄워보는 편이 심리적 부담이 확실히 적었다. 새 프로젝트를 하나 더 올리는 선택이 “월 얼마가 더 나간다”가 아니라 “디스크를 조금 더 써본다” 정도의 고민으로 줄어드는 셈이다. 덕분에 실험 주기는 자연스럽게 짧아지고, 실패를 빨리 반복하면서 배우는 속도도 함께 빨라졌다.

돌이켜보면 중요한 건 개발 자체라기보다, 짧은 주기로 사용자 반응을 확인하고 그것을 바탕으로 목표를 조정하는 능력에 가까웠다. 홈랩은 그 과정을 부담 없이 반복해볼 수 있는 실험실 같은 역할을 해줬다.

작은 실험실을 넓혀가는 중

최근에는 작은 사무실을 마련하면서 전기세 부담에서 조금 자유로워졌고, 덕분에 노드를 늘려 Proxmox로 여러 대를 묶어 관리하는 쪽으로 확장하고 있다. 일종의 프라이빗 클라우드를 손으로 만들어가는 셈인데, 클러스터를 구성하고 마이그레이션을 시험해보는 과정에서 그동안 문서로만 보던 개념들이 조금 더 입체적으로 다가온다. 그 위에 GPU를 추가해 가벼운 AI 모델을 돌려보는 실험도 시작했다. 최근 AI 관련 통계를 보면, 대규모 모델뿐 아니라 소규모 도메인 특화 모델을 자체 인프라에서 돌려보는 시도가 점점 늘어나고 있다고 하는데, 그런 흐름을 아주 작은 규모로나마 따라가 보는 느낌이다. 이 블로그도 결국은 그 홈랩 위에서 돌아가고 있다.

여기까지 오면서 느낀 건, 홈랩은 단순한 비용 절감 도구가 아니라 학습과 실험, 그리고 피드백을 묶어주는 플랫폼에 가깝다는 점이다. 직접 배포하고, 깨지고, 고치고, 또 배포하는 과정에서 얻는 경험은 문서와 강의만으로는 잘 쌓이지 않는 종류의 자산처럼 느껴진다.

당신이 지금 가장 크게 느끼는 제약은 비용일까, 학습의 밀도일까, 아니면 빠른 사용자 검증일까. 어떤 것이 더 중요한지에 따라 선택은 조금씩 달라질 것이다. 다만 작은 서버 한 대로 시작해서 필요한 만큼만 천천히 확장해보는 접근이 생각보다 많은 것을 보여줄 수 있다는 점은 경험으로 알게 됐다.

구체적인 구성과 설정 이야기는 곧 따로 정리해보려고 한다. 그 사이에 당신도 집 어딘가에서 조용히 돌아가는 한 대의 컴퓨터를 떠올려볼 수 있으면 좋겠다. 그게 어떤 질문을 던지게 할지, 나도 조금 궁금하다.