설정값만 믿지 않고 전원을 뽑았다: Hermes 서버 자동 복귀 검증

📝 한줄 요약

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

• 자동 시작 설정만 확인하지 않고 정상 재부팅과 실제 전원 차단을 따로 시험했습니다.

• Hermes Gateway, 원격 화면, Syncthing, 개인 네트워크, 문서 검사 상태를 먼저 기록했습니다.

• 재부팅 뒤 새 프로세스와 실제 사용자 질문으로 서비스 복귀를 확인했습니다.

• 별도 승인 후 전원을 약 5분간 분리하고 다시 연결했습니다.

• 전원 버튼이나 수동 명령 없이 Mac mini와 핵심 서비스가 스스로 돌아왔습니다.

• 서버 자동 복귀와 MacBook 클라이언트의 무한 재시도는 다른 문제라는 한계도 남겼습니다.

ALT

웹사이트 제작 과정을 보여주는 한국어 웹사이트

설정 화면이 아니라 새 부팅 시각, 새 프로세스, 실제 채널 응답으로 자동 복귀를 증명했습니다.

🎯 이런 분들께 도움돼요

• 집이나 사무실에서 무인 Mac 서버를 운영하는 분

• “재시작 시 자동 실행” 설정이 실제로 작동하는지 확인하고 싶은 분

• 정전 뒤 AI 서비스와 동기화 서비스가 스스로 복구돼야 하는 분

• 위험한 전원 시험을 승인 단계와 복구 수단으로 나누고 싶은 분

😫 문제 상황 (Before)

Hermes와 메신저 Gateway가 launchd에 등록돼 있어도 실제 정전 뒤 돌아온다는 보장은 없습니다. 운영체제 설정, 가상화 도구, 네트워크, 로그인 전 실행 여부 중 하나만 빠져도 원격 접속이 끊길 수 있습니다.

또한 화면에 이전 창이 그대로 보이거나 시작음이 들리지 않았다는 인상만으로는 재부팅 여부를 판단하기 어렵습니다. 따라서 정상 재부팅과 전원 차단을 분리하고, 부팅 시각과 프로세스 ID 같은 객관적인 증거를 남겨야 했습니다.

🛠️ 사용한 도구

프로세스 ID(PID)는 실행 중인 프로그램에 운영체제가 붙이는 번호입니다. 재부팅 뒤 번호가 바뀌면 이전 프로그램이 남은 것이 아니라 새로 실행됐음을 확인하는 데 도움이 됩니다.

🔧 작업 과정

1. 시험 전 기준 상태를 고정했다

Gateway와 화면 서비스의 프로세스, 연결 포트, Syncthing의 미동기화·오류 수, OrbStack 상태, 개인 네트워크, SSH, 화면 공유를 기록했습니다. Hermes 설정과 인증 파일의 해시, MainVault Validator 결과, 활성 도구·컨테이너 수가 변하지 않았는지도 확인했습니다.

핵심 프롬프트에는 전원 차단 전후의 증거와 승인 경계를 분명히 넣었습니다.

먼저 정상 재부팅으로 Hermes 화면, Gateway, Syncthing, 원격 접속이
자동 복귀하는지 확인한다. 부팅 시각과 새 프로세스 ID, 실제 사용자 응답을 남긴다.
물리적 전원 차단은 별도 승인 후 파일 쓰기를 멈추고 약 5분간 수행한다.
전원 재연결 뒤 버튼이나 수동 서비스 실행 없이 같은 검증을 반복한다.

2. 정상 재부팅으로 자동 시작의 기본을 확인했다

먼저 운영체제의 정상 재부팅을 수행했습니다. 재부팅 뒤 부팅 시각이 바뀌고 Gateway와 화면 서비스의 PID가 새로 만들어졌습니다. Syncthing과 원격 접속도 돌아왔습니다.

사용자는 화면 공유로 접속하고 Hermes Mini, Telegram, Discord, Slack에서 직접 질문했습니다. 네 경로 모두 응답해 “프로세스가 존재한다”와 “사용자가 실제로 쓸 수 있다”를 함께 확인했습니다.

3. 자동 시작과 자동 업데이트를 분리했다

OrbStack을 확인하는 과정에서 자동 업데이트 설치 옵션이 켜진 것을 발견했습니다. 자동 시작은 필요하지만, 검증하지 않은 업데이트까지 자동 적용할 필요는 없었습니다. 두 기능을 분리해 자동 시작은 유지하고 자동 업데이트는 껐습니다.

이 조정은 사소해 보여도 중요합니다. 서버가 잘 돌아오는지 시험하는 동안 프로그램 버전까지 바뀌면 장애 원인을 구분하기 어려워집니다.

4. 별도 승인 뒤 실제 전원 차단을 시험했다

정상 재부팅이 통과한 뒤에만 물리적 전원 차단 승인을 받았습니다. 새 백업·동기화·컨테이너 작업이 0인지 확인하고 파일 시스템 쓰기를 마친 뒤 AC 전원을 약 5분간 분리했습니다. 화면 공유가 끊길 때를 대비한 현장 복구 방법도 준비했습니다.

전원을 다시 연결한 뒤 전원 버튼을 누르거나 서비스를 수동 실행하지 않았습니다. 새 부팅 시각, 재부팅 기록, 새 PID가 실제 냉간 부팅을 증명했습니다. 이전 창이 보였고 시작음이 없었지만 객관적인 기록은 새로운 부팅과 서비스 재실행을 보여줬습니다.

마지막으로 Hermes Mini와 세 메신저, 화면 공유, Syncthing, 문서 검사 결과를 다시 확인했습니다. 모두 사용 가능한 상태로 돌아왔습니다.

✅ 결과 (After)

Before vs After

결과물

• 정상 재부팅과 물리적 전원 차단의 분리 시험 기록

• Hermes 화면·Gateway·Syncthing·원격 접속 자동 복귀 확인

• 부팅 시각과 프로세스 ID 기반의 재실행 증거

• 전원 시험 전 쓰기 작업 0과 현장 복구 수단 확인 절차

• 자동 시작과 자동 업데이트를 분리한 운영 기준

Mac mini 서버가 자동으로 돌아오는 것과 MacBook 앱이 오랜 장애 동안 계속 재시도하는 것은 별개입니다. 현재 클라이언트는 약 5분의 장애 동안 정해진 재시도 횟수를 소진할 수 있으며, 그때는 사용자가 앱을 다시 열어야 합니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

• AI에게 “설정을 확인해줘”가 아니라 재부팅 전후에 달라져야 할 증거를 정의하게 했습니다.

• 위험이 낮은 정상 재부팅을 먼저 수행해 기본 문제를 찾은 뒤 전원 차단으로 넘어갔습니다.

• 사람의 체감과 시스템 기록이 다를 때 부팅 시각·PID·실제 응답을 우선했습니다.

이렇게 하면 안 돼요

• 백업이나 동기화가 진행 중일 때 전원을 분리하면 데이터 손상 위험이 있습니다.

• 원격 복구 경로 없이 무인 서버의 전원 시험을 하면 현장 접근이 필요할 수 있습니다.

• 서버 복귀와 클라이언트 자동 재연결을 하나의 성공 항목으로 합치면 남은 한계를 놓칩니다.

🌍 다른 업무에 적용한다면?

매장 단말, 홈 자동화 서버, 사내 대시보드처럼 사람이 항상 곁에 없는 장비에도 같은 방식이 필요합니다. 설정값, 정상 재부팅, 실제 전원 복구, 사용자 기능 확인을 단계적으로 나누면 위험을 줄이면서 신뢰도를 높일 수 있습니다.

🚀 앞으로의 계획

• MacBook 클라이언트의 장기 장애 재시도 전략 개선

• 정기 점검에서 부팅 시각·서비스 실행 횟수·채널 응답을 함께 기록

• 배터리 백업 전원이나 정전 알림이 필요한지 운영 데이터를 보고 판단

📋 재사용 가능한 프롬프트

프롬프트 1: 무인 서버 자동 복귀 시험

[서버]의 자동 복귀를 설정값이 아니라 실제 시험으로 검증해줘. 먼저 서비스·동기화·네트워크·설정 해시의 기준 상태를 기록하고 정상 재부팅을 수행해줘. 새 부팅 시각, 새 프로세스 ID, 실제 사용자 기능을 확인한 뒤에만 별도 승인으로 물리적 전원 차단을 진행해줘. 전원 차단 전 쓰기 작업이 0인지와 현장 복구 수단을 확인하고, 서버 복귀와 클라이언트 재연결 결과를 분리해 보고해줘.