안녕하세요, 23기 "24시간 AI 서버 스터디" 스터디장 온어닷입니다. =)
지난주 1주차에 여러분은 바이브코딩으로 첫 API 서버를 만들었고, 오늘 2주차에는 그걸 Docker에 올립니다.
그 전에, OT 때 잠깐 예고드렸던 것 하나를 실행에 옮긴 이야기를 들려드리려 합니다.
기억하실지 모르겠습니다 —
지난주 OT에서 "지금 데스크탑에서 돌고 있는 이 봇들, 조만간 미니PC 홈서버로 이사시킬 예정"이라고 간략히 말씀드렸었죠.
그 이사를 바로 어제 마쳤습니다.
24시간 돌던 텔레그램 봇 11개 + 지식관리 DB + 에이전트 허브를,
Claude Code와 함께 일주일 준비해서 45분 만에 통째로 옮겼습니다.
이 글은 그 전말입니다
— 그 작은 서버가 계속 자라면 어디까지 가는지, 스터디장이 직접 겪은 실전 사례.
참고로 저는 코드를 못 쓰는 비개발자입니다.
여러분이 이번 4주간 만들 것이 이 시스템의 출발점이고,
이 글은 그 출발점을 1년쯤 굴리면 도달하는 풀 버전의 모습입니다.
오늘 저녁 Docker를 만나기 전 워밍업으로 읽어주세요.
(스터디 참가자가 아닌 분께는 "이 스터디 끝까지 가면 뭐가 되는데?"에 대한 답이 될 것 같습니다.)
---
1. 배경 — "PC를 못 끄는 삶"은 오늘 밤부터 시작될 수 있습니다
저는 개발자가 아닙니다.
그런데 바이브코딩으로 이것저것 만들다 보니 어느새 이렇게 되어 있었습니다.
- 텔레그램 봇 11개 (뉴스 요약봇, 지식수집봇, 할일봇, 업무비서봇...)
- 지식관리 DB (문서 19,139건, 검색용 벡터 32,900개)
- 에이전트 허브 (봇들을 관리하는 API·대시보드·RAG 답변기)
시작은 여러분의 지난주 1주차와 똑같았습니다.
Claude Code에게 말로 시켜서 작은 서버 하나를 만든 것.
그게 봇이 되고, 봇이 늘고, 도커 컨테이너에 올라가고(바로 오늘 2주차에 하는 그것입니다), 그러다 보니 어느 날 깨달았습니다 — "어? 나 이제 컴퓨터 못 끄네?"
봇이 24시간 살아있으려면 뭔가는 24시간 켜져 있어야 하니까요.
그 "뭔가"가 작업용 데스크탑(Windows의 WSL2)이었던 게 문제였습니다:
- 데스크탑을 24시간 켜둬야 함 (전기, 소음, 발열)
- Windows가 업데이트로 재부팅하면 봇 전체가 흔들림
- 작업 PC와 서버가 한 몸이라, 뭘 실험하다 잘못되면 봇도 같이 죽음
그래서 몇 주에 걸쳐 Claude와 선택지를 비교했습니다.
맥미니 vs 미니PC, 미니PC vs 클라우드(제 세션 기록을 통째로 읽혀서 워크로드 분석을 시켰습니다). OT 시연 때 보여드린 "미니PC vs 클라우드" 비교가 바로 이 검토의 결과물입니다.
결론은 미니PC + 우분투 서버.
제 봇들은 연산이 무거운 게 아니라 API 호출 위주라 클라우드 월 비용보다 미니PC 한 번 사는 게 쌌고, 데이터를 집에 두고 싶었습니다. — 이 "서버 전용 장비 분리"가 스터디에서 지향하는 종착지이기도 합니다.
(스터디는 미니PC 없이 지금 쓰는 PC로 시작합니다. 저도 1년을 데스크탑으로 버텼고요.)
2. 준비 — "45분 컷오버"는 일주일이 만들었다
이번 이관에서 가장 크게 배운 것: 실행이 아니라 준비가 전부였습니다. Claude Code에게 그냥 "서버 옮겨줘"라고 한 게 아니라, 일주일에 걸쳐 단계를 밟았습니다.
│날짜│ 한 일 │ 스터디 연결 │
│D-7│미니PC에 우분투 설치, Tailscale(가상 사설망)로 기존 기기들과 연결│다음 주(3주차)│
│D-5│ 노트북에서 미니PC 원격 제어 확인 │다음 주(3주차) │
│D-3 |현재 인프라 전체(도커·네트워크)를 그림으로 시각화 "옮길 게 뭔지"부터 파악|오늘(2주차)│
│ D-2 │ 이관 계획서 작성 → 다른 AI(codex)에게 교차검토 → 블로커 5건 발견·수정│지난주(1주차) 습관 │
│ D-2 │ 소스 동결: 코드 저장소 6곳의 버전, 볼륨 목록, 결정사항을 문서로 못박음 │
│ D-1 │ 리허설: 실전과 똑같은 절차를 밤에 한 번 완주 → PASS │
│ D-day │ 체크리스트 런북 따라 실행 │
포인트 세 가지:
① AI 교차검토 — Claude가 쓴 계획서를 codex에게 검토시켰더니 블로커 5건 + 보완 6건이 나왔습니다. Claude는 지적사항을 그대로 수용하지 않고 하나하나 실측으로 재검증한 뒤 반영했습니다. 스터디에서도 강조해야겠다 싶었는데, AI의 산출물은 다른 AI로 검증시키면 확실히 단단해집니다.
② 소스 동결 문서 — 이관 직전에 "무엇이 정본인지"를 항상 기록했습니다. 덕분에 당일 "어? 이 파일 최신 맞아?" 같은 혼란이 없었습니다.
③ 리허설 — 전날 밤 전체 절차를 한 번 미리 완주했습니다. 그래서 당일은 "처음 하는 일"이 아니라 "어제 한 일의 반복"이 됐습니다.
3. D-day — 45분의 기록
당일 오후, Claude Code에게 런북을 열게 하고 사전 점검부터 시작했습니다. 원래 밤 9시~12시로 잡았는데 사전 점검이 전부 통과되자 Claude가 "지금 시작할까요?"라고 물었고, 승인하고 바로 진행했습니다. 14:52 시작 → 15:37 종료. 45분.
1. 기준선 확인 — 옮기기 전 DB의 실제 데이터 건수를 파일로 저장 (나중에 대조용)
2. 정지 → 백업 → 전송 → 복원 — 기존 서비스를 멈추고, DB를 덤프해서(243MB), 체크섬으로 무결성 확인 후 미니PC로 전송·복원
3. 검증 1층: 개수 — 옮긴 DB 31개 테이블의 건수가 원본과 완전 일치하는지 대조
4. 검증 2층: 내용 — 도커 볼륨 11종을 전송한 뒤, 의심 구간은 파일 내용의 해시(지문)까지 대조
5. 검증 3층: 실동 작 — 미니PC에서 컨테이너 13개 기동 → 대시보드 접속, RAG에 실제 질문(제 지식 DB를 인용해 답하는지), 그리고 마지막으로 제 폰에서 봇에게 진짜 메시지를 보내 답이 오는지
6. 자동화 이양 — 백업·감시 스케줄 11종을 미니PC로 옮기고, 기존 데스크탑은 "콜드 스탠바이"(비상시 되돌릴 수 있는 상태)로 전환
7. 백업의 백업 — 옮긴 직후 풀 백업을 만들고, 그 백업에서 실제로 복원이 되는지까지 테스트 (파일 1,619개 = 1,619개 확인)
여기서 배운 것: 검증은 3중으로. "개수 일치 → 내용 지문 일치 → 실제 동작"은 각각 다른 종류의 누락을 잡습니다. 개수만 맞으면 안심되지만, 내용이 깨졌거나 인증이 죽었으면 봇은 안 돌아갑니다.
참고로 이 45분 동안 저는 미니PC를 만진 적이 없습니다. 전부 Tailscale 경유 원격으로 진행됐고, 심지어 이날 저녁의 후속 작업 일부는 폰의 tmux에서 했습니다. "어디서든 닿는" — 다음 주 3주차에 하는 그것입니다.
4. 사고 — 죽였던 서버가 살아 돌아왔다
순조롭던 중 사건이 하나 터졌습니다. 이관한 봇 하나가 미니PC에서 계속 죽는 겁니다. 에러는 텔레그램의 "409 Conflict" — 번역하면 "이 봇, 다른 데서 누가 이미 돌리고 있는데?"
Claude가 추적을 시작했습니다.
토큰이 겹쳤나? → 아님.
프로세스가 중복인가? → 아님.
그러다 기존 데스크탑의 컨테이너 목록을 보고 발견했습니다.
아까 분명히 정지시킨 데스크탑 봇들이 저절로 부활해 있었습니다.
범인은 한 달 전에 제가(정확히는 Claude가) 설치해둔 자가복구 타이머였습니다.
"컨테이너가 죽으면 5분 안에 자동으로 되살리는" 안전장치인데, 이 장치 입장에선 컷오버로 정지시킨 것과 장애로 죽은 것을 구분할 수 없으니, 성실하게 되살린 거죠.
약 11분간 구서버와 신서버가 같은 봇을 동시에 돌리고 있었습니다.
해결: 다시 정지시키고, 복구 스크립트를 실행 불가 상태로 만들어 무해화한 뒤, 다음 5분 타이머가 실제로 실패하는 것까지 확인했습니다.
이날의 교훈이자, 이 글에서 하나만 가져가신다면 이것입니다:
▎ "서버를 죽지 않게 만드는 장치"는 서버를 옮기는 날에는 최대의 적이 된다.
▎ 워치독, 자동 재시작, 자가복구 타이머 — 뭐든 만들어뒀다면, 이관 체크리스트 맨 위에 "그것들 먼저 끄기"를 적어두세요.
재미있는 건, 이 장치도 과거의 제가 Claude와 함께 만든 것이라는 점입니다.
과거의 자동화가 미래의 자동화와 싸운 셈인데, 이걸 진단하고 해결한 것도 Claude였습니다.
서버를 오래 굴리면 이런 "내가 만든 것들끼리 싸우는" 순간이 옵니다 — 스터디에서 자동화를 하나 만들 때마다 목록으로 기록해두는 습관을 같이 잡으려는 이유입니다.
5. 지금 상태, 그리고 다음 이야기
- 3스택 전부 미니PC에서 가동 중, 텔레그램 실메시지 왕복 확인 완료 → 공식 완료
- 완료 직후 72시간은 관찰 기간: 이상이 보여도 고치지 않고 진단만 기록 (수정하면 "뭐가 문제였는지" 기준선이 오염되므로)
- 데스크탑은 이제 꺼도 됩니다. 드디어.
같은 날 저녁, 내친김에 다음 단계 계획까지 세웠습니다.
미니PC에 Cloudflare Tunnel + Caddy를 얹어 제 도메인으로 서비스를 공개하는 것 — 서비스명.내도메인.com 식으로 주소를 부여하는 구상입니다.
포트포워딩 없이(집 IP 노출 없이) 되는 구조인데, 다음 주 3주차의 Tailscale이 "나만 접속"이라면 이건 "세상에 공개"로 한 단계 더 나간 버전입니다.
관찰 기간이 끝나고 진행할 예정이라, 잘 되면 스터디 기간 안에 다음 글로 이어가겠습니다.
6. 배운 점 요약 — 재사용 가능한 체크리스트
1. 소스 동결 문서 — 이관 전 "무엇이 정본인지"를 못박으면 당일 혼란이 사라진다
2. 리허설 1회 = 당일 45분 — 전날 전 절차를 완주하면 D-day는 확인 작업이 된다
3. 검증은 3층 — 개수 → 내용 지문(해시) → 실동작. 각 층이 다른 누락을 잡는다
4. 자가복구 장치 먼저 끄기 — 이중 가동 사고의 1순위 원인
5. 복원 테스트까지가 백업 — "백업 성공" 로그가 아니라, 실제로 복원해봐야 백업이다
6. 관찰 기간 정해놓기 — 이관 직후 72시간은 수정 금지, 진단만
7. 만료되지 않는 인증 선택 — 무인 자동화의 인증은 만료 없는 방식으로 (만료형 토큰은 1년 뒤 "조용한 실패" 예약)
8. AI 교차검토 — 한 AI의 계획을 다른 AI로 검토시키되, 지적을 그대로 받지 말고 실측 재검증 후 수용
7. 스터디장으로서 한마디 — "명령어는 한 줄도 안 쳤습니다"
이번 작업에서 제가 직접 한 일은 이렇습니다:
선택지에서 고르기(이관 범위, 인증 방식...), 폰으로 봇에게 메시지 보내서 답 오는지 확인하기, 그리고 "진행해줘"라고 말하기.
명령어는 한 줄도 안 쳤습니다.
대신 제가 반드시 해야 했던 일도 분명히 있었습니다.
갈림길마다 결정을 내리는 것, 그리 고 AI가 세운 계획의 전제("리허설 통과했나?", "백업 확인했나?")를 따라가며 승인하는 것.
AI가 일을 하고, 나는 일이 제대로 되고 있는지 확인하는 구조 — 이게 되니까 서버 지식이 없어도 서버 운영이 됩니다.
우리 스터디는 정확히 이 구조를 4주로 압축한 빌드이고, 지금 딱 절반 지점에 서 있습니다:
- 1주차 (완료) — 바이브코딩으로 API 서버 직접 만들기 → 지난주에 여러분이 만든 그 서버가 제 봇 11마리의 출발점과 같은 것입니다
- 2주차 (오늘) — Docker 배포 + Agent SDK로 에이전트 구축 → 오늘 밤이 지나면 여러분의 서버도 "이사 갈 수 있는 짐"이 됩니다. 이번에 제가 이사시킨 컨테이너 13개가 전부 이 형태입니다
- 3주차 (다음 주) — 로컬 LLM 백엔드 + Tailscale → 제가 폰에서 서버를 만진 바로 그 통로
- 4주차 — 데모데이 + 회고
데모데이 때 여러분의 결과물은 봇 11마리가 아니라 1마리일 겁니다. 하지만 구조는 같습니다 — 그리고 제 경험상, 1마리에서 11마리까지는 생각보다 금방입니다.
스터디 소개(4주 빌드 청사진·도구 스택·준비물): https://homelab-ai-agent-study.vercel.app/
궁금한 점은 오늘 세션에서 직접, 또는 댓글로 물어봐주세요.
