내 홈랩 AI 개발 플랫폼

 (rsgm.dev)
11P by GN⁺ | ★ favorite | 댓글 1개
  • 홈랩 서비스 관리를 위해 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를 선택했으며, 시도한 선택지 중 가장 마음에 든 도구였음
  • OpenCode에 내장 웹서버와 웹 UI가 있다는 점이 홈랩 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가 배포를 처리하게 할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 내 환경에 맞는 AI 통합 방식을 아직 찾는 중임. 지금은 Forgejo와 코딩 에이전트 사이에 상호작용이 없고, Forgejo Actions 러너도 실험해 봤지만 맥락 관리가 애매했음
    이슈나 PR에 있는 내용은 받을 수 있지만, 여러 차례 왕복하거나 논의가 이슈에서 PR로 옮겨가면 금방 흐려짐

  • 비슷한 걸 하고 있는데, 영구적인 opencode 서버 대신 Forgejo 액션 러너 안에서 opencode를 실행하는 워크플로를 쓰고 있음: https://codeberg.org/dragonfyre13/forgejo-opencode
    아직 손보는 중이지만, 요지는 Forgejo 이슈 안에서 /oc로 Opencode를 호출하면 검토할 PR을 만들어 돌아오게 하는 방식임

  • 기술 업계에서는 많은 사람이 거의 같은 시기에 비슷한 걸 독립적으로 겪는데, 정작 글로 쓰거나 공유하는 사람은 적은 느낌이 들 때가 있음
    나도 비슷한 시스템을 만들고 있어서, 글과 댓글을 보며 다들 같은 과정을 지나고 있다는 점이 즐거웠음

    • 기술 업계만 그런 건 아니고 흔한 현상임. 우리가 그렇게 독창적인 건 아님
    • 나도 이걸 세 가지 방식으로 만들어봤고, 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가 없음
답변달기