Codex에게 부탁하다: 홈 서버를 고치고 영화를 보고 싶다
요약
사용자가 홈 서버의 스토리지 풀링(mergerfs) 문제 해결을 위해 Codex를 활용한 경험담입니다. 단순히 용량 부족 문제를 넘어, 파일 배치 정책 수정과 기존 파일 재분배라는 복잡한 데이터 재균형화 과정을 성공적으로 수행했습니다. 이 과정에서 체크섬 검증 및 네트워크 스토리지를 통한 안정적인 파일 읽기까지 확인하며 시스템 관리의 어려움을 보여줍니다.
핵심 포인트
- Codex를 활용하여 스토리지 풀링 환경의 복잡한 데이터 불일치 원인을 진단하고 해결할 수 있었다.
- 파일 배치 변경과 기존 파일 재분배는 별개의 작업이며, 시스템적인 접근이 필요하다.
- 데이터 무결성 확보를 위해 체크섬 검사 및 제어된 복구 과정이 필수적이다.
- 홈 서버 관리 시 발생하는 스토리지 리밸런싱 문제는 전문적인 진단 도구가 유용하다.
내 홈 서버는 약 24TB의 여유 공간이 있었지만, 다운로드 파일을 가져올 수 없었다. 전체 스토리지 풀의 용량은 안심할 만한 수치였다. 하지만 실제로 가져오기(import)에 사용될 수 있는 브랜치는 100GiB 예약 용량을 밑도는 약 99GiB만 남아 있었다.
Codex는 불일치(mismatch) 원인을 진단해 주었다. 내가 직접 파헤칠 수도 있었지만, 나는 영화를 보고 싶었기 때문이다. 그저 이 기능을 사용하기 위해 스토리지 설정을 만지고 싶지 않았다.
배치 변경은 기존 파일을 이동시키지 않는다
내 드라이브들은 mergerfs로 풀링(pooling)되어 있다. 새로운 파일 배치를 위한 정책(policy for placing new files)은 이미 관련 디렉토리를 포함하고 있는 브랜치만 고려하고 있었다. 여유 드라이브 두 개는 해당 트리가 없었기 때문에, 그들의 여유 공간이 가져오기에 목적지를 제공하지 못했다.
새로 파일 배치 변경과 기존 파일 이동은 별개의 작업이었다. 다른 정책을 선택하는 것만으로는 데이터를 자체적으로 재균형화(rebalance)할 수 없었다.
이 복구 작업에는 두 가지 부분이 필요했다. Codex가 새로운 파일 배치를 수정했고, 그 후 별도로 기존 파일을 재분배했다. 이 재균형화 과정에서 24개의 오래된 영화들이 이동했다. 각 목적지는 원본이 제거되기 전에 체크섬(checksum) 검사를 통과했으며, 재배치된 파일들은 이후 일반 네트워크 스토리지 경로를 통해 읽혔다.
'복사 시작됨(copy started)'이나 눈에 띄게 많은 여유 공간 자체가 완료 결과는 아니었다. 완료 기록은 완료된 이동 및 읽기 작업을 포함했다.
중간에 중단된 적도 있었다. 연결이 끊긴 스토리지 마운트(storage mount)는 제어된 복구(controlled recovery)가 필요했고, 그 정확한 원인은 밝혀지지 않았다. 나중에 VM의 제어 에이전트(control agent)가 재시작되면서 리밸런싱(rebalance) 작업이 일시 중지되었다. Codex는 작업을 재개하기 전에 상태를 확인했다. 이러한 세부 사항들은 최종적인 복구만큼이나 계정 기록에 포함되어야 했다.
요청했던 에디션을 유지하며
더 최근의 요청은 물리적 서버에 연결된 USB SSD로 시작되었다. 나는 그 스타워즈(Star Wars) 에디션들을 사용 가능한 자막과 함께 내 4K Radarr/Plex 라이브러리로 복사하고 싶었다.
에디션들은 4K77, 4K80, 그리고 4K83이었다. Codex는 체크섬(checksums)으로 복사본을 검증하고 사용 가능한 영어 자막 트랙을 선택했다. 나는 Radarr가 그 에디션들을 자신이 더 높게 순위 매긴 버전으로 교체하는 것에 대해 물었고, 자동 업그레이드가 해당 에디션을 대체하는 것을 막기 위해 세 가지 모두 모니터링되지 않도록 남겨두었다. 작업이 끝났을 때 소스 SSD는 변경되지 않은 채 마운트 해제된 상태였다.
2026년 10월 6일에 촬영된 동일한 현재 Plex 항목의 세 가지 스크랩. 에디션 라벨과 영어 자막 필드는 캡처 시점의 결과 라이브러리 항목을 보여준다.
나는 옆에 앉아 남자친구와 함께 작업이 진행되는 것을 지켜보았다. 우리는 기다렸고, 영화들이 로드되었으며, 우리는 영화를 볼 수 있었다.
명령어는 여전히 실제 서버에 도달해야 한다
Codex는 내 MacBook에서 실행된다. 이는 LAN을 통해 SSH 및 API를 거쳐 개인 서버에 접근하거나 Tailscale을 이용한다. 로컬 home-infra 저장소는 인벤토리, 운영 규칙(operating rules), 런북(runbooks), 그리고 비공개 정의를 제공한다. 스택 작업은 Komodo와 Compose를 사용하며; Proxmox 및 호스트 운영은 자체 SSH/API 경로를 사용한다.
문서화된 제어 경로는 LAN 또는 Tailscale을 통해 내 MacBook에서 실행된다. 로컬 저장소는 인벤토리, 운영 규칙 및 비(非)비밀 정의를 제공한다.
이러한 구성은 작은 유지보수 요청도 처리한다. Usenet 제공업체의 도메인이 변경되었다는 이메일을 받았을 때, 나는 Wispr Flow를 사용하여 요청 내용을 구술하고: 변경 사항을 찾고 서버를 업데이트했다.
Codex가 공지사항을 확인하고 Prowlarr의 엔드포인트를 변경했으며, 기존 키로 테스트하여 네 개의 Sonarr/Radarr 인스턴스 모두에 동기화됨을 확인했다. 재시작할 필요는 없었다.
MacBook과 AI 데스크톱 앱은 현재 나의 작업 방식에 적합하다. 나는 서버 작업을 Codex에게 맡기고, 무슨 일이 일어났는지 확인한 후 다음 작업으로 넘어갈 수 있다. 그 엔드포인트 변경의 경우, 다음 작업으로 넘어가는 것이 내가 원했던 바로 그것이었다.
내가 작성하거나 구축한 것에 대해 이야기하고 싶다면? 연락하기.
이 글은 billiem.uk의 원래 기사를 AI 도움을 받아 각색한 것입니다. 원본 기사는 출판 전에 검토되었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기

