클라우드 대신 집에 서버를 뒀어요 서버 구현 2편 — 만들면서 정한 것과 아직 못 정한 것

🎯 바쁘시면 이것만 읽어도 돼요

• 개인 서버를 클라우드에 안 두고 집에 남는 노트북으로 만들었어요. 월 비용보다는 어떤 일이 서버로 가야 하는지 기준을 먼저 정한 게 컸어요

• 인터넷에 포트를 하나도 안 열었어요. VPN 안에서만 붙게 해서 공유기 설정도 도메인도 필요가 없어졌어요

• 편의를 위해 켠 설정 하나가 다른 보호 장치를 끄기도 하더라고요. 계정 종류를 바꿨더니 디스크 암호화가 같이 풀렸어요

👀 이런 분들께 도움돼요

• 개인 서버나 홈랩을 만들어볼까 하는데 뭘 올리고 뭘 클라우드에 둘지 애매하신 분

• 자기 기계를 밖에서 쓰고 싶은데 공유기 포트 여는 게 꺼림칙하신 분

• 자동 백업을 걸어두고 그 안에 뭐가 들어가는지는 안 봤던 분

• AI 에이전트한테 명령 실행 권한을 준 채로 쓰고 계신 분

😮 Before: 원고가 한 기계에만 있었어요

원고를 옵시디언으로 옮기면서 문제가 생겼어요. 노트가 맥에만 있으니까 밖에서 뭐가 생각나도 열어볼 수가 없더라고요. 저는 콘텐츠 마케팅 디자이너면서 클로드랑 웹앱을 만들어 굴리는 바이브코딩 개발자고, 소설도 쓰거든요.

폰에서도 같은 원고를 보려면 동기화가 필요한데, 상용 서비스를 쓰자니 원고를 남의 서버에 올리는 게 걸렸어요.

✨ After: 집에 서버가 돌고 원고가 세 군데에 있어요

집에 남는 윈도우 노트북 한 대를 24시간 서버로 돌리고 있어요. 원고는 맥, 폰, 서버 세 군데에 동기화되고 서버에 저장될 때는 암호화돼요. 밖에서 붙을 수 있는데 인터넷에는 아무것도 안 열려 있고요.

이번 글은 만드는 방법보다 왜 그렇게 정했는지를 남겨두려고 써요. 그리고 아직 판단이 안 서는 것 몇 가지가 있어서 끝에 적어뒀어요.

🛠️ 이 서버가 하는 것 (배경 30초)

시작은 스터디장님이 공유해주신 Caddy 강의 자료였어요. 비개발자도 따라할 수 있게 만든 자료라 저도 여기서 출발했어요. 다만 그 자료는 만든 걸 인터넷에 공개하는 걸 전제로 설명하는데, 저는 저만 쓸 거라 방향이 달라졌어요.

지금 이 노트북에서 돌아가는 건 넷이에요.

1. 원고 동기화용 데이터베이스

2. 북마크 보관소

3. 메신저로 대화하는 AI 에이전트 (원래 이 기계에 살고 있었어요)

4. 위 셋을 감시하는 장치와 매일 도는 백업

🔨 과정: 만들면서 정한 것들

1️⃣ 클라우드가 아니라 집에 둔 이유는 비용이 아니었어요

처음엔 월 몇천 원짜리 클라우드를 생각했어요. 그런데 뭘 올릴지 목록을 적어보니 대부분 클라우드에 갈 필요가 없더라고요.

그래서 기준을 두 개로 정리했어요. 로그인한 브라우저가 필요한 일과 프로그램을 설치해야 하는 일만 서버로 보내기로요. 알림 보내기, 집계하기, API 호출하기 같은 건 정해진 시간에 도는 클라우드 기능으로 충분했어요. 스케줄이 있다고 서버가 필요한 게 아니더라고요.

그렇게 거르고 나니 남은 게 원고 동기화 하나였어요.

기계는 세 대를 놓고 골랐어요. 작업용 맥은 뺐어요. 제가 들고 나가면 폰 동기화가 끊기는데, 그건 어디서든 원고를 연다는 목적과 정면으로 부딪히니까요. 오래된 데스크탑도 뺐어요. 디스크가 낡았고 정전이 나면 그냥 꺼지거든요. 노트북은 배터리가 무정전 장치 노릇을 해줘서 이걸 골랐어요.

2️⃣ 포트를 하나도 안 열었어요

개인 서버 이야기에서 제일 무서운 게 인터넷에 뭔가를 여는 일이잖아요. 공유기에 구멍을 뚫고 도메인을 붙이고 방화벽을 걱정하는.

그걸 통째로 안 하기로 했어요. VPN을 깔아서 제 기기끼리만 서로 보이게 하고, 서버에는 그 안에서만 접근해요. 공인 아이피로 열린 포트가 하나도 없어요.

이렇게 하니까 자체 호스팅을 말할 때 따라붙는 걱정 대부분이 해당 사항이 없어졌어요. 대신 VPN 계정이 단일 실패 지점이 됐어요. 거기가 뚫리면 제 기기 전부가 한 번에 노출돼요. 위험이 사라진 게 아니라 한 곳으로 옮겨간 거죠.

3️⃣ 백업을 열어봤더니 열쇠 꾸러미였어요

AI 에이전트의 기억이랑 설정을 매일 압축해서 다른 기계로 보내고 있어요. 처음엔 이걸 클라우드에도 올리려고 했어요. 받는 기계가 고장 날 수도 있으니까요.

그러다 압축 파일 안을 열어봤어요. 메신저 봇 토큰, 외부 서비스 인증 파일, 데이터베이스 관리자 비밀번호가 평문으로 들어 있더라고요. 백업이라기보다 열쇠 꾸러미에 가까웠어요.

그래서 안 올리기로 했어요. 올려야 할 일이 생기면 그 파일들만 빼고 따로 만들기로 하고요. 복원할 때 인증을 한 번 더 하면 되는 일이라 잃는 게 크지 않다고 봤어요.

비슷한 판단을 한 번 더 했어요. 원고 백업은 클라우드에 올리고 있는데, 동기화 도구가 접속 정보랑 암호화 열쇠를 원고 폴더 안에 평문으로 저장하더라고요. 그대로 두면 암호화를 켠 의미가 반감돼요. 열쇠가 같이 클라우드에 올라가니까요. 그 폴더만 백업에서 빼는 걸로 막았어요.

4️⃣ 😲 하이라이트: 계정 종류를 바꿨더니 디스크 암호화가 같이 풀렸어요

무인 재부팅을 견디게 만들려고 자동 로그인을 켰어요. 새벽에 윈도우 업데이트로 재시작되면 로그인 화면에서 멈춰 있고, 그러면 서버가 아침까지 아무것도 안 하니까요.

그런데 안 됐어요. 재부팅해봐도 계속 로그인 화면에서 멈춰 있었어요.

제 예상은 설정을 잘못 건드렸겠거니였어요. 그런데 화면에 뜬 문구가 힌트였어요. 네트워크에 연결할 수 없다는 메시지였거든요. 로그인하는데 왜 네트워크가 필요한가 싶었죠.

마이크로소프트 계정이 로그인할 때 온라인 검증을 시도하기 때문이었어요. 그런데 부팅 직후에는 무선 연결이 아직 안 붙어 있어요. 실제로 재보니 부팅하고 무선이 붙는 데 1분 40초쯤 걸리더라고요. 자동 로그인은 그걸 안 기다리고요.

유선으로 바꿔도 부팅 시점에 인터넷이 있어야 로그인된다는 조건은 남아요. 정전 복구처럼 공유기가 늦게 뜨는 상황이면 또 같은 일이 벌어지고요. 24시간 서버에 인터넷이 있어야 켜지는 조건이 붙어 있는 게 그 자체로 이상하다고 느꼈어요.

그래서 로컬 계정으로 바꿨어요. 온라인 검증이 없어지니 재부팅해도 알아서 올라와요.

여기서 예상 못 한 게 나왔어요. 전환하고 나니 디스크 암호화가 풀려 있었어요. 그게 마이크로소프트 계정에 묶여 있는 기능이었거든요. 자동 로그인이라는 편의를 얻으려고 계정을 바꿨는데, 전혀 다른 보호 장치가 조용히 꺼진 거예요.

집에 두는 기계라 물리적 접근 위협은 낮다고 판단했어요. 그래도 자동 로그인만 켜두면 누구든 열고 부팅하면 제 세션이라, 로그온하고 30초 뒤에 화면이 잠기게 걸어뒀어요. 세션은 살아 있어서 서버는 계속 돌고 화면만 잠기는 방식이에요.

📊 결과

정한 것마다 얻은 게 있고 대신 생긴 게 있어요. 그걸 같이 적어두는 게 나중에 도움이 되더라고요.

💡 효과적이었던 것

올릴 것 목록부터 적어본 게 컸어요. 서버가 필요한 일과 아닌 일을 두 기준으로 갈랐더니 다섯 개쯤 될 줄 알았던 목록이 하나로 줄었어요. 그러고 나니 클라우드를 빌릴 이유가 없어졌고요.

백업 안을 한 번 열어본 것도요. 안 열어봤으면 열쇠 꾸러미를 클라우드에 올릴 뻔했어요. 백업은 만들고 나면 잘 안 열어보게 되는데, 그 안에 뭐가 들어가는지는 한 번은 봐야 하더라고요.

안 만들기로 한 결정을 기록해둔 것도 좋았어요. 처음 계획에는 리버스 프록시가 들어 있었는데 올릴 게 하나뿐이라 미뤘거든요. 라우팅은 갈림길이 있어야 필요한 건데 갈림길이 없었으니까요. 이유를 안 적어두면 나중에 왜 안 했는지 잊고 또 검토하게 돼요.

⚠️ 이런 건 아쉬웠어요

디스크 암호화가 풀린 걸 한참 뒤에 알았어요. 계정을 바꾸면서 뭐가 같이 꺼지는지 미리 안 찾아본 제 탓이에요. 편의를 위해 설정 하나를 켤 때 그게 다른 보호 장치를 건드리는지 확인하는 습관이 없었어요.

서버로 쓰는 노트북의 저장장치가 고장 판정을 받은 것도 늦게 알았어요. 원고를 올리기 직전에 발견해서 다행이었는데, 기계를 고르는 단계에서 디스크 상태를 안 본 게 실수였어요. 오래된 데스크탑은 디스크가 낡았다고 뺐으면서 정작 고른 기계는 안 봤거든요.

컨테이너 데이터를 어디에 둘지도 잘못 잡았어요. 백업하기 편하라고 윈도우 폴더에 뒀는데 데이터베이스가 거기서 제대로 못 돌아요. 다시 해야 해요.

📋 따라하려면

1. 올릴 것 목록부터 적으세요. 로그인한 브라우저가 필요한 일, 프로그램을 설치해야 하는 일. 이 둘에 안 걸리면 서버가 없어도 될 수 있어요

2. 포트를 열기 전에 VPN을 먼저 보세요. 기기끼리만 연결하면 공유기 설정도 도메인도 필요가 없어요

3. 기계를 고를 때 디스크 상태를 확인하세요. 사양보다 이게 먼저예요

4. 백업을 만들었으면 압축 파일을 한 번 열어보세요. 안에 뭐가 들어가는지 보고 클라우드에 올릴지 정하세요

5. 편의를 위해 설정을 켤 때 그게 뭘 같이 끄는지 찾아보세요. 계정 종류를 바꾸는 것처럼 커 보이지 않는 변경도 다른 걸 건드려요

🙏 아직 못 정한 것

여기부터는 제가 판단이 안 서는 것들이에요. 혹시 이런 걸 겪어보신 분 계시면 의견 주시면 정말 좋겠어요.

하나. 인증 토큰이 든 백업을 평문으로 두 기계에 두고 있어요. 암호화를 붙이는 게 맞을까요, 아니면 그 열쇠를 또 어디 보관하느냐는 문제가 새로 생겨서 오히려 손해일까요. 자동으로 도는 백업이라 사람이 매번 암호를 넣을 수는 없는 구조예요. 저장장치가 고장 판정을 받은 상태라 백업을 자주 뜨고 있고, 그만큼 그 파일들이 여기저기 쌓이고 있어서 좀 급해요.

둘. 자동 로그인을 켜고 바로 잠그는 조합이 적정한지 모르겠어요. 집에 두는 개인 기기라는 전제에서요. 디스크 암호화를 다시 켜야 하는 수준일까요, 아니면 물리 접근 위협이 낮은 상황에서는 과한 대비일까요.

셋. 이게 제일 궁금해요. AI 에이전트가 명령 실행 권한을 가진 채로 메신저에서 지시를 받아요. 그래서 알림 채널은 에이전트가 읽는 채널과 분리해뒀어요. 복구됐다는 알림을 자기 지시로 읽는 걸 막으려고요. 그런데 그게 충분한지는 모르겠어요. 이 구조에서 프롬프트 인젝션 관점으로 더 봐야 할 게 있을까요.

내 다음 목표

컨테이너 데이터 위치부터 고쳐야 해요. 그리고 하나씩 올려서 재부팅까지 견디는지 확인하는 절차를 건너뛰었는데, 그것도 다시 밟을 거예요.

폰 동기화는 아직 안 붙였어요. 그거까지 되면 처음에 원했던 어디서든 원고 열기가 완성돼요.

그리고 이 서버를 만들면서 자동화가 조용히 실패하는 걸 몇 번 겪었는데, 그건 지난 글에 따로 정리해뒀어요.