📝 한줄 요약
메인 노트북에서만 쓰던 Hermes를 어디서든 24시간 쓰기 위해 Mac mini 헤드리스 서버 구축에 도전했습니다. 1일차는 원격 접속 경로 · 전원/보안 상태 · 작업을 기록하고 추적할 환경을 만드는 데 썼습니다.
바쁘시면 이것만 읽어도 돼요:
헤드리스 서버는 평소 안 만지는 기계라, 원격 복구 경로 가 없으면 에이전트를 깔아놔도 손을 못 댑니다. 그래서 설치 순서를 뒤로 미뤘습니다.
Tailscale + SSH + 화면 공유로 관리 경로를 두 개 만들었습니다. 공유기 포트는 열지 않았습니다.
FileVault를 껐습니다. 보안상 나쁜 선택이지만 무인 복귀와 맞바꾼 결정이고, 그 이유를 기록에 남겼습니다.
launchctl은 "안 돌아감", 포트는 열려 있음 — 출력 한 줄로 판정하면 안 되는 케이스를 만났습니다.웹채팅으로 설계하다 한계를 느껴, 작업을 기록·추적할 환경으로 VSCode를 도입했습니다.
개발자가 아니라 처음부터 쉽지 않았지만, 계획을 세우고 단계별로 확인하는 환경을 만드니 하나씩 넘어갔습니다.
😫 왜 서버를 만들기로 했나
스터디 시작 전에 사전 연습으로 맥북 터미널에 Hermes를 직접 설치해봤습니다. 텔레그램까지 연동해서 운동 모임 공지를 작성해주는 간단한 스킬도 하나 만들어봤고요. 여기까지는 잘 굴러갔습니다.
문제는 맥북에서만 돌아간다는 점이었습니다. 밖에서도 계속 작업하려면, 그리고 Hermes를 24시간 어디서든 쓰려면 계속 켜져 있는 기계가 따로 있어야 했습니다. 그래서 Mac mini를 저렴하게 구해 헤드리스 서버 구축에 도전했습니다.
문제는 제가 개발자가 아니고 이런 작업이 처음이라는 것이었습니다. 초기화된 Mac mini 화면을 보고 있으니 "뭘 먼저 깔지"가 아니라 "뭘 먼저 하면 나중에 후회하는지"를 모르겠더군요. 그래서 첫 질문을 이렇게 던졌습니다.
맥미니를 24시간 헤르메스 에이전트 및 서버로 쓸려고 지금 초기 세팅중이야.
초기 설정 순서대로 뭘 해야하는지 a to z 방식 순서대로 자세하게 설명해줘.돌아온 순서가 이랬습니다.
원격 복구 → 보안 → 문서/저장소 → 컨테이너 → 에이전트 → 백업
에이전트가 뒤에서 두 번째입니다. 이 순서를 받아들이는 게 1일차의 시작이었습니다. 혼자였으면 무조건 Hermes부터 깔았을 겁니다.
🔧 작업 과정
1. 원격 접속 경로를 일부러 두 개 만들었다
Tailscale을 설치해 인증까지 마쳤습니다. 공유기 포 트포워딩 없이 밖에서 서버에 닿는 게 목적이었고, 실제 출력으로 설치·인증 성공을 확인했습니다.
그 위에 두 경로를 올렸습니다.
SSH — 평소 관리용. 서버 전용 키를 따로 만들고, 접속 별칭을 등록해 IP를 외우지 않아도 되게 했습니다.
화면 공유 — GUI 권한 팝업이 뜨거나 SSH가 죽었을 때를 위한 두 번째 문.
여기서 AI가 제동을 건 지점이 있습니다. 보통 SSH 보안 가이드는 "비밀번호 로그인은 즉시 끄세요"가 정석처럼 나옵니다. 그런데:
키 인증이 확실히 되는지, 접속이 막혔을 때 되살릴 수단이 있는지 확인하기 전에는 비밀번호 로그인을 성급히 끄지 않는다.
헤드리스 서버에서 SSH가 잠기면 직접 가서 모니터를 꽂는 것 말고 방법이 없습니다. 보안을 서두르다 자기 자신을 문 밖에 세우는 셈이죠.
이 과정에서 터미널 호환 문제로 경고 메시지가 하나 떴는데, 실패가 아니라 구버전 도구의 호환성 경고였습니다. 초보는 경고와 에러를 구분 못 해서 멀쩡한 걸 되돌리는 실수를 자주 합니다.
2. "안 돌아간다"는 출력이 사실이 아니었던 순간
화면 공유를 켜고 상태를 확인했는데 두 출력이 정반대였습니다.
launchctl print system/com.apple.screensharing에서는 state = not running인데
lsof에서는 TCP *:5900 (LISTEN)으로 보여.혼자였으면 설정을 껐다 켰다 반복했을 겁니다. 실제 답은 이랬습니다.
macOS 화면 공유는 접속 요청이 올 때 뜨는 방식으로 동작할 수 있다. 그래서 평소엔 not running으로 보이는 게 정상이고, 포트가 열려 대기 중이라는 사실이 더 강한 근거다.
AI가 정답을 알려준 게 아니라 두 출력 중 어느 쪽을 근거로 삼아야 하는지를 알려준 순간이었습니다.
3. 보안은 "켜는" 게 아니라 "고르는" 문제였다
FileVault(디스크 암호화)는 껐습니다. 보안만 보면 나쁜 선택입니다. 하지만 24시간 서버에서 정전이 나면, 암호화가 켜져 있을 때 누군가 비밀번호를 쳐줘야 디스크가 풀립니다. 무인 복귀와 디스크 암호화 중 하나를 골라야 했고, 이 기계에서는 무인 복귀를 택했습니다. 잊고 넘어간 게 아니라 기록에 남긴 결정입니다.
확인된 상태:
항목
상태
정전 후 자동 시동
켜짐
네트워크 접근 시 깨우기
켜짐
방화벽
켜짐 / 스텔스 모드 켜짐
모든 수신 차단
꺼짐 (필요한 접속은 통과)
자동 로그인
아직 안 켬
마지막 줄이 포인트입니다. 자동 로그인을 켜면 무인 복귀가 훨씬 편해지지만, 전체 구축과 재부팅 테스트가 끝나기 전에는 켜지 않기로 했습니다. 편의 기능을 먼저 켜면 문제가 생겼을 때 원인 후보가 하나 늘어납니다.
4. 웹채팅의 한계, 그리고 VSCode
여기까지 설계와 작업을 전부 웹채팅으로 했는데 한계가 왔습니다. 결정도 상태도 실행 기록도 전부 채팅창 안에만 있었습니다. 스크롤을 올려야 찾을 수 있고, 새 채팅을 열면 맥락이 끊깁니다. 처음 하는 작업이라 어제 뭘 확인했는지가 오늘 기억이 안 나는 게 제일 컸습니다.
작업을 파일로 기록하고 갱신하고 추적할 환경이 필요했습니다. Claude Desktop과 Codex 앱을 검토했고, 작업 기록을 자동으로 개발 로그로 만들어주는 write-post 스킬을 쓰려면 VSCode 환경이 낫다는 결론이 나와 VSCode까지 설치했습니다.
이때 확정한 원칙이 하나 더 있습니다. 초기 설계를 어떤 AI로 했든 그 AI에 묶일 필요는 없다. 같은 저장소와 같은 상태 문서를 읽게 하면 어떤 도구든 이어받을 수 있습니다. 반대로 문서가 없으면 채팅 하나를 잃는 순간 프로젝트가 통째로 날아갑니다.
5. 진짜 결과물은 서버가 아니라 문서였다
"a to z 순서로 알려줘"의 결과물은 명령어 모음이 아니라 13단계 Phase로 나뉜 서버 가이드북이었습니다. 각 Phase마다 설치·검증· 백업·복원·이관 절차가 들어 있고요. 목표가 "이 맥미니를 세팅한다"에서 "다음 맥으로 통째로 옮길 수 있게 한다"로 바뀐 순간이었습니다.
그리고 문서를 종류별로 쪼갰습니다.
문서
역할
BUILD_STATUS
지금 실제로 어떤 상태인지 (최신 스냅샷)
BUILD_LOG
언제 뭘 실행했고 출력이 뭐였는지 (누적 기록)
DECISIONS
왜 그렇게 정했는지 (의사결정 기록)
가이드북
처음부터 다시 할 때 따라갈 순서
DISASTER_RECOVERY
망가졌을 때 복구 절차
"지금 상태"와 "결정 이유"와 "실행 기록"을 한 파일에 섞으면, 며칠만 지나도 뭐가 사실이고 뭐가 계획인지 구분이 안 됩니다. 이걸 분리한 게 이날의 핵심 성과라고 생각합니다.
처음 하는 작업이라 막히는 지점이 계속 나왔지만, 결국 계획을 세우고 단계별로 확인하면서 넘어가는 환경을 만든 게 해결책이었습니다. 지식이 부족한 걸 의욕으로 메우는 대신, 순서와 기록으로 메운 셈입니다.
✅ 1일차 결과
항목
Before
After
Hermes 사용 환경
맥북에서만
24시간 서버로 옮길 기반 마련
원격 접속
없음 (모니터 직결)
Tailscale 기반 SSH + 화면 공유, 포트포워딩 없음
정전 대응
미설정
자동 시동·네트워크 깨우기 켜짐
작업 기록
채팅창 안에만 존재
상태·결정·실행 기록 분리 문서 + VSCode 환경
다음 맥으로 이관
처음부터 다시
13단계 가이드북으로 재구축 가능
아직 안 된 것
서버에 Hermes는 아직 설치하지 않았습니다. 설계만 확정된 상태입니다.
정전 후 자동 복귀는 검증 안 됐습니다. 설정을 켠 것과 실제 복귀를 확인한 건 다릅니다.
재부팅 후 원격 접속이 자동으로 돌아오는지도 아직 확인 전입니다.
1일차 성과는 딱 이겁니다. "원격 접속 기반 + 일부 전원·보안 검증 + 재현 가능한 설계 문서."
💬 배운 것
1. "방법" 말고 "순서"를 물어보기 "Tailscale 설치 방법"은 검색으로도 나옵니다. "이 목적이면 어떤 순서로 해야 나중에 안 엎어?"는 AI가 훨씬 잘합니다. 초보의 약점은 개별 지식이 아니라 순서입니다.
2. "완료됐어?" 대신 "무슨 근거로 완료라고 했어?" AI는 대화 흐름상 완료로 보이면 완료라고 말합니다. 근거를 물으면 "실행했다고 말함"인지 "출력으로 확인됨"인지가 갈립니다. 이 둘은 전혀 다릅니다. 작업 기록을 정리할 때 A(실제 출력으로 확인) / B(실행했다 했으나 출력 없음) / C(설계만 확정)로 등급을 매기게 했더니, 상태 문서가 "다 됐음"과 "전부 미확인" 사이를 오가는 게 멈췄습니다.
3. 출력 한 줄로 판정하지 않기 모르는 출력이 나오면 "이거 정말 실패 맞아? 다른 해석은 없어?"를 한 번 더 물어보세요.
4. 복구 수단보다 보안 잠금을 먼저 하지 않기 헤드리스 서버에서는 "보안 강화"가 곧 "내 접속 차단"이 될 수 있습니다.
🚀 다음 작업
현재 상태 캡처 — 아무것도 바꾸지 않고 지금 값만 그대로 읽어서 기록에 반영
재부팅 테스트 — 껐다 켰을 때 원격 접속이 자동으로 돌아오는지. 이게 확인돼야 "24시간 서버"라는 말을 쓸 수 있습니다
Git 연동 — 지금까지 만든 문서와 설정을 저장소로 관리
서버 최적화 — 전원·절전·네트워크 정책 정리
필요한 파일·도구 설치 — 그리고 초기 설정 완료 후 Hermes