내 홈랩 AI 개발 플랫폼 — OpenCode와 GitOps로 안전하게 자동화하기

내 홈랩 AI 개발 플랫폼 — OpenCode와 GitOps로 안전하게 자동화하기

2026년 6월 현재, 홈랩 운영자 사이에서 AI 개발 도구를 직접 서비스에 붙이지 않고도 GitOps 흐름 안에서만 쓰는 패턴이 빠르게 자리 잡고 있다. AI가 실제 서비스 대신 Git 브랜치만 만질 수 있고, 사람이 PR을 검토한 뒤 GitOps가 배포를 이어받는 구조다. 긱뉴스에 올라온 rsgm.dev 사례는 Truenas 위 12개 docker compose 스택을 Arcane GitOps로 옮기고, OpenCode 웹 UI에 Git 접근 권한만 부여해 변경을 PR로 받아 처리하는 흐름을 보여준다.

홈랩 관리 흐름 — 왜 AI를 직접 서비스에 붙이면 안 되는가

이 사례의 출발점은 단순하다. 약 12개의 docker compose 스택을 Arcane으로 옮겨 GitOps로 관리하면서, AI 도구는 컨테이너 업데이트와 healthcheck 추가 같은 유지보수에 쓰기 시작했다. 이전에는 각 서비스의 릴리스 노트를 찾고, 브레이킹 체인지를 확인하고, 업데이트를 실행한 뒤 수동으로 이상 여부를 점검해야 했다. 이 작업에 몇 시간이 걸렸지만, 이제는 릱리스 노트 요약을 몇 분 안에 읽고 버전 업그레이드를 진행한다. 대부분의 컨테이너에 healthcheck를 추가하는 데에도 AI를 활용해 문제 발견이 빨라졌다. AI가 서비스에 직접 접근하지 못하는 구조라, 검토되지 않은 코드는 배포되지 않는다.

OpenCode — 서버로 실행되는 지속 코딩 세션

OpenCode는 서버로 실행되며, 내장 터미널, 파일 브라우저, Git diff, git worktree를 제공한다. 여러 기기에서 동일한 코딩 세션이 동기화되기 때문에 컴퓨터에서 시작해 휴대폰에서 이어받는 작업이 자연스럽다. 작성자는 Claude Code를 주로 사용했지만, AI 제공사들이 토큰 제한을 강화하면서 특정 벤더에 종속되지 않는 코딩 환경을 원하게 됐다. 여러 코딩 환경을 시도한 뒤 OpenCode를 선택한 이유는 서버 실행과 모바일 웹 UI가 홈랩 AI 개발 플랫폼 구상의 출발점이 되었기 때문이다. OpenCode의 모바일 웹 UI는 질문·답변 팝업이 매우 좋다는 점도 채택 이유였다.

AI 개발 플랫폼 — VM 위 가드레일 구조

Truenas 호스트 위에 기본 개발 도구가 설치된 간단한 VM을 만들고, OpenCode 웹서버를 systemd unit으로 추가했다. 이 환경은 내장 터미널과 Git diff, git worktree 지원을 제공해 여러 코딩 세션을 동시에 관리한다. Git 서버에는 OpenCode 전용 사용자와 전용 SSH 키를 부여했고, OpenCode는 프로젝트를 클론하고 브랜치를 푸시할 수 있지만 배포 브랜치에는 직접 푸시할 수 없다. VM은 인터넷과 Git 서버에는 접근 가능하지만 실제 서비스에는 접근할 수 없다. 영향 범위를 좁게 유지했기 때문에 빌드 도구나 테스트 의존성을 설치해야 할 때 VM root 권한을 부여해도 안전하다. 사전 설치된 도구, 접근 가드레일, 감사 로그가 결합된 형태는 개발자용 임시 컨테이너 플랫폼으로 확장 가능한 출발점이 된다.

Workflow — 계획에서 병합까지 다섯 단계

기본 작업 흐름은 OpenCode에서 기능이나 개선을 계획하는 단계로 시작한다. 계획에는 명세, 구현 계획, 자체 리뷰가 들어가고, 가능한 경우 변경을 테스트하거나 검증한다. 마음에 들지 않는 부분은 OpenCode와 반복적으로 수정한 뒤, OpenCode가 변경을 기능 브랜치에 푸시한다. 그 브랜치로 PR을 열고 만족하면 PR을 병합한다. 병합 뒤에는 GitOps가 배포를 이어받는다. docker 서비스 변경은 Arcane이 처리하고, Home Assistant 설정 변경은 GitOps 플러그인이, 블로그 변경은 Cloudflare Pages worker가 처리한다. 이 단계들은 OpenCode가 푸시 → 사람이 PR 병합 → GitOps가 배포로 이어지는 일관된 흐름이다.

Arcane GitOps와 OpenCode 조합

Truenas에서 실행하던 모든 docker compose 스택을 Git 기반 저장소로 옮긴 뒤 OpenCode를 함께 추가하자, 이 방식이 예상보다 잘 작동했다. 휴대폰에서 모든 컨테이너의 네트워킹을 업데이트할 수 있어, 여러 시스템에 흩어져 있던 구성 관리가 훨씬 쉬워졌다. 이전에는 모든 compose 스택을 훑고 네트워크 연결을 추적하는 데 몇 시간이 걸렸지만, 지금은 OpenCode에 코드베이스와 목표를 지정하고 생성된 PR 변경을 확인한 뒤 병합만 하면 된다. 이 조합은 컨테이너 운영과 코드 변경을 한 흐름으로 묶어 홈랩 관리 비용을 크게 낮춘다.

남은 한계와 접근 제어 — CI 피드백의 빈 자리

가장 큰 빈 부분은 CI 피드백이다. GitHub에서는 코딩 에이전트가 Actions 로그를 본다. 실패한 테스트와 린터 오류를 본다. 스택 트레이스와 IaC plan 변경도 함께 본다. 이 네 가지 신호로 단위 테스트가 다루지 못하는 변경까지 빠르게 진단할 수 있다. Forgejo에서는 이 흐름이 더 어렵다. Forgejo Actions는 공개 API로 job 로그를 노출하지 않는다. 문서화되지 않은 API는 쓰고 싶지 않다. 현재 설정은 AI가 변경 대상 서비스에 직접 접근하지 못한다. 대신 어떤 기기에서든 홈 인프라 변경을 만들 수 있다. 2026년 6월 기준으로, GitOps와 PR 검토 사이에 CI 피드백을 끼워 넣는 것이 이 패턴의 다음 숙제다.