소개
첫날에는 서버 구축 순서와 상태·결정·실행 기록을 나누는 문서 체계를 만들었습니다. 하지만 문서가 있다는 것과 다른 AI·다른 Mac에서도 같은 작업을 이어갈 수 있다는 것은 달랐습니다. 채팅에서 만든 설계 자료는 서로 충돌했고, 실제 서버 상태는 아직 확인하지 않았으며, 저장소를 잘못 다루면 비밀정보나 쓰기 권한까지 서버로 복제할 수 있었습니다.
그래서 네 개의 설계 자료를 하나의 도구 중립 운영 저장소로 조립하고, MacBook에서 작성한 변경만 private Git 저장소를 거쳐 Mac mini의 읽기 전용 실행 사본으로 전달하는 흐름을 만들었습니다. 마지막에는 최소 도구 목록을 Brewfile로 선언하고 새 checkout에서도 규칙과 스크립트가 통과하는지 확인했습니다. 이 글은 문서 초안이 실제로 재현 가능한 운영 기반이 되기까지를 다룹니다. 애플리케이션과 백업 서비스 실행은 아직 포함하지 않습니다.
제품 제작 과정을 보여주는 한국 웹사이트
설계 자료를 단일 운영 원본으로 정리하고, 검토된 변경만 서버로 전달하는 구조입니다.
한눈에 보는 흐름: 설계 자료 → 단일 운영 원본 → Private Git → Pull-only 서버
진행 방법
Codex는 서로 다른 AI가 만든 설계 자료를 비교하고, 충돌·미확인 상태·비밀정보 경계를 먼저 분리했습니다. 저는 계정 용도와 권한, staging·commit·push처럼 외부 상태가 바뀌는 단계마다 대상을 확인하고 승인했습니다.
실제로 사용한 대표 prompt는 다음과 같습니다.
현재 열린 폴더는 [프로젝트명 제거] 서버 프로젝트의 신규 로컬 저장소다.
새로운 구조를 처음부터 임의로 창작하지 말고,
네 입력을 비교하여 중립적이고 재현 가능한 저장소로 조립해야 한다.
완성된 청사진보다 바뀌어도 무너지지 않는 구조를 만들었다
처음 받은 자료에는 역할이 겹치거나 미래 결정을 이미 확정한 것처럼 적힌 부분이 있었습니다. PKM을 읽기 전용으로 고정한 설계는 Hermes가 Markdown을 생성해야 한다는 요구와 충돌했고, 아직 고르지 않은 automation·지식관리 구조도 구체적으로 정해져 있었습니다. 반대로 전원 복구, 원격 접속, private Git, container, backup·restore처럼 서버라면 반드시 검증해야 할 항목은 유지해야 했습니다.
그래서 저장소를 고정 청사진이 아니라 Phase마다 실제 상태를 확인하고 갱신하는 living operations repository로 바꿨습니다. 미래의 폴더 구조와 workflow는 미결정 항목으로 분리하고, 필수 결과와 검증 gate만 baseline으로 남겼습니다. 조사 전의 host·service·backup 상태는 과거 채팅의 표현을 복사하지 않고 미확인으로 기록했습니다.
AI별 규칙 파일에도 모든 내용을 복제하지 않았습니다. 상세 규칙은 한 파일만 원본으로 삼고, 자동으로 읽히는 adapter에는 파괴적 작업을 멈추게 하는 동일한 최소 안전 코어만 넣었 습니다. validator는 두 안전 코어가 byte 단위로 같은지, 필수 중단 항목과 문서 구조가 남아 있는지 확인하도록 했습니다. 덕분에 Claude와 Codex 중 무엇을 쓰더라도 같은 저장소 상태와 안전 경계에서 이어갈 수 있었습니다.
작성하는 Mac과 실행하는 Mac의 권한을 나눴다
다음 문제는 저장소를 어디서 어떻게 바꿀지였습니다. MacBook은 문서와 설정을 작성·검토하는 곳으로, Mac mini는 승인된 결과를 가져와 실행하는 곳으로 역할을 나눴습니다. 개인 서버 저장소에는 개인 Git 계정과 provider의 비공개 email 방식을 사용하되, 사업·고객·조직 자산에는 자동으로 재사용하지 않는 계정 분류 규칙도 만들었습니다.
MacBook에는 개인 계정용 SSH 경로를, Mac mini에는 이 private 저장소 하나만 읽을 수 있는 별도 deploy key를 구성했습니다. 쓰기 권한은 끄고 private key와 recovery code는 채팅·문서·Git에 남기지 않았습니다. staging, commit, push도 한 번에 묶지 않고 각각 diff와 비밀정보 pattern을 확인한 뒤 승인했습니다.
push 뒤에는 별도 clean checkout에서 같은 commit과 validator 통과를 확인했습니다. Mac mini에는 author 정보와 push URL이 없는 pull-only checkout을 만들고, MacBook·remote·Mac mini의 commit이 같은지도 대조했습니다. 저장소 이름의 대소문자까지 canonical 형태로 맞춰 다음 이관에서 서로 다른 경로로 인식될 가능성을 줄였습니다.
설치 목록도 기억이 아니라 선언으로 남겼다
운영 저장소가 준비된 뒤 Mac mini의 architecture, 개발 도구, Homebrew, shell, locale, PATH와 기존 service를 먼저 조사했습니다. 그 결과 JSON·YAML 처리, 검색, shell 검증, terminal session, 상태 확인, 파일 동기화와 backup에 필요한 최소 CLI를 골라 Brewfile에 선언했습니다.
설치 후에는 패키지가 보인다는 것만 확인하지 않았습니다. Brewfile 충족 여부, 버전과 실제 경로, repository validator, Bash syntax와 ShellCheck를 Mac mini의 runtime checkout에서 다시 실행했습니다. interactive SSH에서는 보이던 명령이 non-interactive SSH나 launchd에서 PATH 차이로 사라질 수 있다는 점도 확인해, 자동화에서는 명시적인 PATH나 absolute path를 사용하도록 기록했습니다.
Syncthing과 restic도 설치 목록에는 들어갔지만 service는 시작하지 않았습니다. 도구가 설치된 것과 데이터 흐름을 승인한 것은 다른 상태이기 때문입니다.
결과와 배운 점
완료된 결과는 다음과 같습니다.
충돌하던 설계 자료를 하나의 Phase 중심 운영 저장소로 조립했습니다.
상세 규칙의 단일 원본, AI adapter의 최소 안전 코어와 자동 검증을 만들었습니다.
MacBook authoring → private remote → Mac mini pull-only 흐름을 실제 동일 commit으로 확인했습니다.
계정·email 용도, 최소 권한, 비밀정보 제외와 Git 변경 승인 경계를 정했습니다.
최소 CLI를 Brewfile로 선언하고 clean runtime checkout에서 다시 검증했습니다.
설치한 동기화·backup 도구는 아직 service로 시작하지 않았습니다.
이 저장소는 서버 전체의 backup이 아닙니다. 승인된 문서·설정·스크립트를 다시 가져오는 경로일 뿐, runtime 데이터와 token, session, 실제 복원 검증은 별도의 backup 과정이 필요합니다. 애플리케이션도 아직 설치하지 않았습니다.
이번 경험에서 얻은 재사용 가능한 교훈은 세 가지입니다.
여러 AI를 이어 쓰게 만 드는 핵심은 대화 기록이 아니라 같은 상태 원장과 검증 가능한 규칙입니다.
서버가 Git 저장소를 읽을 수 있다는 이유로 쓰기 권한까지 줄 필요는 없습니다.
재현 가능성은 패키지 목록만으로 생기지 않습니다. clean checkout, 환경별 PATH와 동일 commit까지 확인해야 실제 이관 경로가 됩니다.
다음 단계에서는 이 기반 위에서 원격 복구가 정상 재부팅과 외부망에서도 실제로 작동하는지 확인하고, 그다음 container runtime과 Hermes를 올립니다.
