# 내 홈랩 AI 개발 플랫폼 > Clean Markdown view of GeekNews topic #30523. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30523](https://news.hada.io/topic?id=30523) - GeekNews Markdown: [https://news.hada.io/topic/30523.md](https://news.hada.io/topic/30523.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-06-16T09:56:23+09:00 - Updated: 2026-06-16T09:56:23+09:00 - Original source: [rsgm.dev](https://rsgm.dev/post/ai-dev-platform/) - Points: 8 - Comments: 1 ## Topic Body - 홈랩 서비스 관리를 위해 **OpenCode Web UI**에 Git 접근을 붙이고, AI 변경은 PR 검토 뒤 GitOps가 배포하는 흐름으로 구성함 - 약 12개의 **docker compose** 스택을 Arcane으로 옮겨 GitOps로 관리하며, AI 도구를 서비스 유지보수에 활용함 - 컨테이너 업데이트 때 릴리스 노트 확인, 브레이킹 체인지 점검, 수동 확인에 몇 시간이 걸렸지만, 이제 릴리스 노트 요약을 몇 분 안에 읽어 버전 업그레이드가 쉬워지고 안전해짐 - OpenCode는 서버로 실행되며 터미널, 파일 브라우저, Git diff, **git worktree**를 제공하고, 여러 기기에서 지속 코딩 세션을 동기화함 - AI는 실제 서비스에 직접 접근하지 못하고 Git 브랜치만 푸시할 수 있어, **검토되지 않은 코드**가 배포되지 않는 구조가 됨 --- ### 홈랩 관리 흐름 - OpenCode Web UI에 Git 접근을 부여해 홈랩 관리를 쉽게 만들었고, OpenCode가 Git에 변경을 푸시하면 사람이 PR을 승인한 뒤 GitOps가 변경을 배포함 - OpenCode는 서버로 실행되며, **지속 코딩 세션**이 여러 기기에서 동기화됨 - 관리 중인 서비스는 약 12개의 docker compose 스택이며, 최근 Arcane으로 옮겨 GitOps로 관리하고 배포함 - AI 도구 활용의 첫 사용 사례는 **컨테이너 업데이트**였음 - 이전에는 각 서비스의 릴리스 노트를 찾고, 브레이킹 체인지를 확인하고, 업데이트를 실행하고, 각 서비스 문제를 수동으로 확인해야 했음 - 이 과정에는 몇 시간이 걸렸지만, 이제 릴리스 노트 요약을 몇 분 안에 읽어 버전 업그레이드가 쉬워지고 안전해짐 - 대부분의 컨테이너에 healthcheck를 추가하는 데 AI를 사용해 문제를 더 빨리 발견할 수 있게 됨 ### OpenCode - Claude Code를 주로 사용했지만, AI 제공업체들이 토큰 제한으로 고객 가치를 줄이고 있어 다른 선택지를 살펴보게 됨 - 원하는 도구는 특정 벤더에 종속되지 않고 주요 플러그인이 지원하는 코딩 환경이었음 - 여러 코딩 환경을 시도한 뒤 [OpenCode](https://opencode.ai/)를 선택했으며, 시도한 선택지 중 가장 마음에 든 도구였음 - OpenCode에 [내장 웹서버와 웹 UI](https://opencode.ai/docs/web/)가 있다는 점이 홈랩 AI 개발 플랫폼 구상의 계기가 됨 ### AI 개발 플랫폼 - Truenas 호스트에 기본 개발 도구가 있는 간단한 VM을 만들고, OpenCode 웹서버를 **systemd unit**으로 추가함 - 이 환경은 내장 터미널, 파일 브라우저, Git diff, git worktree 지원을 제공해 여러 코딩 세션을 동시에 관리할 수 있음 - OpenCode의 모바일 웹 UI는 질문·답변 팝업이 매우 좋았음 - Git 서버에는 OpenCode 전용 사용자와 전용 SSH 키를 부여함 - OpenCode는 프로젝트를 클론하고 브랜치를 푸시할 수 있음 - 배포 브랜치에는 직접 푸시할 수 없음 - 워크플로는 AI를 **PR 검토 뒤**에 두며, OpenCode가 변경을 작성하고 사람이 PR에서 직접 병합함 - 이 구조는 검토되지 않은 코드가 배포되는 일을 막음 - VM은 인터넷과 Git 서버에는 접근할 수 있지만, 실제 서비스에는 접근할 수 없음 - 영향 범위가 작기 때문에 빌드 도구나 테스트 의존성을 설치해야 할 때 OpenCode에 VM root 권한을 부여해도 괜찮다고 판단함 - 이 구조는 사전 설치된 도구, 접근 가드레일, 감사 로그가 있는 개발자용 임시 컨테이너 형태의 프로덕션 개발자 플랫폼으로 확장될 수 있음 - 현재 구성은 필요한 기능을 제공하면서도 구성 요소가 너무 많지 않음 ### Workflow - 기본 작업 흐름은 OpenCode에서 기능 또는 개선을 계획하는 단계로 시작함 - 계획에는 명세, 구현 계획, 자체 리뷰가 들어감 - 가능한 경우 변경을 테스트하거나 검증함 - 마음에 들지 않는 부분은 OpenCode와 반복적으로 수정함 - OpenCode가 변경을 기능 브랜치에 푸시함 - 해당 브랜치로 PR을 열고, 만족하면 PR을 병합함 - 병합 뒤에는 **GitOps**가 배포를 이어받음 - docker 서비스 변경은 Arcane이 처리함 - Home Assistant 설정 변경은 GitOps 플러그인이 처리함 - 블로그 변경은 Cloudflare Pages worker가 처리함 ### Arcane GitOps와 OpenCode 조합 - 서비스들을 Truenas에서 Arcane GitOps 프로젝트로 옮겼으며, 주된 목적은 Truenas에서 실행하던 모든 docker compose 스택을 Git 기반 저장소로 관리하는 것이었음 - OpenCode를 함께 추가하자 이 방식이 예상보다 잘 작동함 - 휴대폰에서 모든 컨테이너의 네트워킹을 업데이트할 수 있어, 퍼져 있는 구성 관리가 훨씬 쉬워짐 - 이전에는 모든 compose 스택을 훑고 네트워크 연결을 추적하는 데 몇 시간이 걸렸음 - 지금은 OpenCode에 코드베이스와 목표를 지정하고, 생성된 PR 변경을 확인한 뒤 병합할 수 있음 ### 남은 한계와 접근 제어 - 가장 큰 빈 부분은 **CI 피드백**임 - GitHub에서는 코딩 에이전트가 Actions 로그를 보고 실패한 테스트, 린터 오류, 스택 트레이스, IaC plan 변경을 진단할 수 있음 - 이 방식은 단위 테스트가 다루지 못하는 변경에도 빠른 피드백 루프를 유지하는 데 도움이 됨 - Forgejo에서는 이 흐름이 더 어려움 - Forgejo Actions는 공개 API를 통해 job 로그를 노출하지 않음 - 문서화되지 않은 API가 있지만, 그 API를 기반으로 구성하고 싶지는 않음 - 현재 설정은 AI가 변경 대상 서비스에 직접 접근하지 못한 채, 어떤 기기에서든 홈 인프라 변경을 만들 수 있게 함 - 컴퓨터에서 변경을 시작하고, 휴대폰에서 PR을 검토하고, GitOps가 배포를 처리하게 할 수 있음 ## Comments ### Comment 59721 - Author: neo - Created: 2026-06-16T09:56:25+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48542433) - 내 환경에 맞는 **AI 통합 방식**을 아직 찾는 중임. 지금은 Forgejo와 코딩 에이전트 사이에 상호작용이 없고, Forgejo Actions 러너도 실험해 봤지만 맥락 관리가 애매했음 이슈나 PR에 있는 내용은 받을 수 있지만, 여러 차례 왕복하거나 논의가 이슈에서 PR로 옮겨가면 금방 흐려짐 - 비슷한 걸 하고 있는데, 영구적인 opencode 서버 대신 **Forgejo 액션 러너** 안에서 opencode를 실행하는 워크플로를 쓰고 있음: [https://codeberg.org/dragonfyre13/forgejo-opencode]() 아직 손보는 중이지만, 요지는 Forgejo 이슈 안에서 `/oc`로 Opencode를 호출하면 검토할 PR을 만들어 돌아오게 하는 방식임 - Claude Code와 Forgejo로 비슷하게 해봤고, Docker에서 Claude를 실행하는 작은 별도 앱 형태였음: [https://github.com/smithy-ai/smithy-ai]() - 기술 업계에서는 많은 사람이 거의 같은 시기에 비슷한 걸 독립적으로 겪는데, 정작 글로 쓰거나 공유하는 사람은 적은 느낌이 들 때가 있음 나도 **비슷한 시스템**을 만들고 있어서, 글과 댓글을 보며 다들 같은 과정을 지나고 있다는 점이 즐거웠음 - 기술 업계만 그런 건 아니고 흔한 현상임. 우리가 그렇게 독창적인 건 아님 - 나도 이걸 **세 가지 방식**으로 만들어봤고, e2b.dev도 써봤는데 좋은 서비스였음 문제는 시간의 99%를 멋진 걸 해킹하는 데 쓰고, 1%만 떠드는 데 쓴다는 것임. 더 떠들어야 함 - 기술 업계 사람들이 모든 걸 공짜로 기대해서 그런 것 같음 변호사와 얘기하다가 시간이 거의 끝났는데 “질문 하나만 더” 하려 했더니, 변호사가 “30분 더 예약하고 그 얘기하자”고 했음. 공정한 방식임 - 내 **AI 랩**에 대해 글을 써야겠다는 동기를 찾고 있었는데, 이 글이 딱 필요했던 자극이었음 내 구성도 비슷한 아이디어지만 n8n/git/argo/k3s를 쓰고, 주로 Qwen이나 Gemma4가 처리할 수 있는 자동화 워크플로용임 - 이 도메인이 왜 **Quad9 리졸버**에서 차단되는지 아는 사람이 있는지 궁금함. Quad9이 도메인을 필터링해서 웹사이트를 열 수 없음 `dig @9.9.9.9 rsgm.dev NS` 결과에 `EDE: 17 (Filtered)`가 나옴 - 추측하자면 등록이 아주 새로워서일 수 있음. 등록된 지 약 8시간밖에 안 됐고, 생성 시각은 2026-06-15 14:01:25 UTC임 - 이 구성을 아직 안 쓰는 주된 이유는 두 가지임: opencode를 실행하는 VM에 프로젝트 빌드를 위해 줘야 하는 **리소스**, 그리고 더 빠른 테스트 때문임 나는 pi 코딩 에이전트를 Mac에서 바로 돌리고, redis, postgres, kratos 같은 전체 소프트웨어 묶음도 함께 실행함. 코딩 에이전트가 주 개발 장비에서 돌면 더 빨리 빌드할 수 있고, 백엔드만 다시 빌드해 재시작한 뒤 UI 클라이언트에서 변경 사항을 바로 테스트하는 식으로 더 빠르게 확인 가능함 - 나도 매우 비슷하게 하고 있음. **Proxmox LXC**에서 OpenCode를 돌리고, 그 위에 Kimaki 레이어를 추가해 Discord 통합을 붙였음 좋아하든 싫어하든 코드베이스와 채팅할 수 있고, 취향이면 음성 메시지도 가능해서 꽤 멋짐 - 훌륭함. **홈랩 AI**는 엄청 재미있어질 것 같음 지금은 Claude가 모든 장비에 걸친 내 홈랩을 관리하게 하고 있는데, 홈랩 설치와 유지보수가 “몇 년 동안 매혹되지만 완전히 제대로 동작하지는 않고 시간을 잡아먹는 함정”에서 “실제로 좋은 아이디어이고 내 역량을 확장해주는 것”으로 바뀌었음 - 최신 모델을 써도 시간을 아껴주는 작은 부분은 있지만, 대체로 미묘한 **설정 문제** 때문에 엄청난 디버깅이 생겨 전체적으로는 손해가 되는 경우가 많았음 “docker compose 파일 만들어줘”나 “NSD 설정 줘”처럼 아주 좁게 지정한 작업이면 괜찮지만, 그 경우에도 어떤 기반 기술이 필요한지와 무엇을 물어야 하는지는 이미 알고 있어야 함 - OpenCode Web UI에 Git 접근을 붙여 홈랩 관리를 쉽게 만들고, OpenCode가 Git에 푸시하면 내가 PR을 승인하고 GitOps가 변경사항을 배포한다는 구성은 꽤 좋아 보임 다만 읽기 전에, 비슷하게 하려면 **RAM과 GPU**를 마련하는 데 수천 달러가 필요한지 궁금함 - 0달러일 수도 있음. OpenCode는 그냥 **하네스**라서, 온라인에 호스팅된 아무 모델에나 연결할 수 있음 - 우리도 비슷하게 하고 있지만 에이전트가 PR도 열 수 있게 하고, ReARM 시스템으로 릴리스 메타데이터와 **에이전트 세션**을 추적함 최근에는 에이전트가 ReARM을 통해 Helm 기반 배포를 추적하는 옵션도 출시했음: [https://docs.rearmhq.com/workflows/devops.html]() - 이 부분은 언급하지 않았지만, 글을 쓰는 동안 Forgejo PR API를 호출하는 스킬을 쉽게 추가할 수 있겠다고 깨달았음 아쉽게도 GitHub처럼 Forgejo에는 CLI가 없음