🖥️

AI 에이전트 작업 환경과 시스템 구성

Tags
AI
AgenticAI
Projects
CI/CD
Description
두 대의 맥북, 윈도우 머신, 맥미니, 시놀로지 NAS에 개발과 연산, 미디어 생성, 서비스 운영, 데이터 보관을 나누어 맡긴 작업 환경을 정리합니다.
Published
2026년 9월 15일 발행
On this page
AI 에이전트들과 게임을 만들다 보니 코드 작성 외에도 할 일이 많아졌습니다. 이미지를 생성하고, 브라우저에서 결과를 검증하고, 오래 걸리는 연산을 돌리고, 만든 서비스가 계속 동작하도록 관리해야 했습니다. 에이전트에게 일을 맡겨도 그 작업을 실행할 컴퓨터는 필요했습니다.
지금은 개인 프로젝트용 MacBook(지니), 업무용 MacBook(아리), 연산·미디어 생성용 Windows 머신(노바), 상시 운영용 Mac mini 서버(루나), 웹서비스·데이터 보관용 Synology NAS(메이)에 역할을 나누어 두고 있습니다.
에이전트와 머신에 같은 이름을 쓰는 경우가 있어서 처음 보면 헷갈릴 수 있습니다. 이 글에서는 이름을 머신의 구분으로 사용합니다. 에이전트들의 소개는 👥함께 일하는 AI 에이전트 스쿼드에 따로 정리했습니다.

전체 구성

맥북 두 대에서는 에이전트와 직접 작업하고, 노바에서는 연산과 생성 작업을, 루나에서는 상시 워크플로우와 러너를 운영합니다. 메이는 Docker 기반 웹서비스를 운영하면서 코퍼스와 미디어 파이프라인 데이터를 보관합니다. 아래 그림은 각 머신에 맡긴 역할을 묶은 구성도입니다.
flowchart TB subgraph DEV["로컬 에이전트 실행"] direction LR subgraph JINNI["개인 프로젝트용 MacBook(지니)"] J1["Claude Code · Codex · Antigravity"] J2["Claude 메모리 동기화"] end subgraph ARI["업무용 MacBook(아리)"] A1["업무용 로컬 에이전트"] A2["Claude 메모리 동기화"] end end subgraph NOVA["Windows 연산·생성 머신(노바)"] N1["nova-run · WSL 검증·테스트·빌드·벤치마크"] N2["헤드리스 브라우저 검증"] N3["ComfyUI · 이미지·비디오·오디오 생성"] N4["RTX 4070 Ti + RTX 5070 Ti · GPU별 ComfyUI 워커"] N6["공유 디스패처 · 필요한 모델·노드에 맞춰 배정"] N5["WoL · 전원 종료 시 원격 기동"] end subgraph LUNA["Mac mini 서버(루나)"] L1["n8n · 상시 워크플로우"] L2["웹서버 운영"] L3["프로젝트별 GitHub Actions 러너 병렬 운영"] end subgraph MAY["Synology NAS(메이)"] M1["Docker 웹서비스 · firejune.io 포함"] M2["코퍼스 · 스크래치 데이터 보관"] M3["이미지·영상 파이프라인 데이터 보관"] end

두 MacBook의 로컬 작업 환경

맥북은 에이전트를 실행하고 작업을 이어 가는 자리입니다. 개인 프로젝트와 회사 업무에 쓰는 머신을 구분하고, 각 환경에서 필요한 도구를 실행합니다.

개인 프로젝트용 MacBook

지니 맥북에서는 Claude Code, Codex, Antigravity를 함께 사용합니다. 에이전트 이름과 실행 머신이 일대일로 대응하는 구성은 아닙니다. 개인 프로젝트용 맥북에서는 Claude Code와 Codex 에이전트의 작업도 진행합니다.
여러 도구를 사용하다 보면 코드만 옮긴다고 작업이 그대로 이어지지는 않습니다. 앞서 어떤 결정을 했는지, 어떤 방식으로 작업하고 있었는지도 다음 환경에서 참고할 수 있어야 합니다. 이를 위해 Claude의 메모리를 동기화하는 도구를 별도로 두었습니다.

업무용 MacBook

아리는 업무용 맥북입니다. 개인 프로젝트용 머신과 구분해 로컬 에이전트를 실행하며, 이곳에서도 Claude 메모리 동기화를 사용합니다.
📝
덧붙임: Antigravity 메모리 동기화는 7월에 중단했습니다. 이후 작업 환경을 원격으로 이어 쓰게 되면서 Claude 메모리 동기화도 중단했고, 업무용 머신에서 개인 프로젝트를 이어 작업하는 방식은 더 이상 사용하지 않습니다. 구체적인 과정은 머신 간 에이전트 메모리 동기화에 정리했습니다.

Windows 머신의 연산과 미디어 생성

노바는 윈도우 시스템입니다. 이미지와 영상을 생성하는 일뿐 아니라, 맥에서 진행하기 부담스러운 전체 검증과 연산도 이곳에 맡깁니다. 맥에서 여러 전체 검증이 겹쳐 메모리가 고갈된 경험이 있었고, 무거운 검증 작업을 노바로 옮기게 됐습니다.

무거운 검증을 맡기는 공용 팜

맥에서는 소스를 다루고 작업을 조율하며, 노바의 WSL 기반 공용 팜에는 nova-run으로 전체 검증·테스트·빌드·벤치마크를 제출합니다. 작업 에이전트는 자신이 변경한 경로를 테스트하고, 지휘 세션은 전체 검증을 조율하는 방식으로 역할을 나누고 있습니다.
실제로 노바에 맡기는 검증에는 다음과 같은 것들이 있습니다.
  • rig-c 코어의 전체 self-test
  • Chromium에서 한글·영문 레이아웃과 클릭 도달성을 확인하는 브라우저 검증. 의도적으로 결함을 넣은 대조 사례도 함께 확인합니다.
  • 깨끗한 환경에서 패키지를 설치하고 플레이어가 기본적으로 동작하는지 확인하는 스모크 테스트

GPU별 워커와 공유 디스패처

미디어 생성에는 ComfyUI를 사용합니다. RTX 4070 Ti와 RTX 5070 Ti에 각각 ComfyUI 인스턴스와 워커를 두고, 공유 디스패처가 작업에 필요한 모델과 노드가 있는 GPU에 배정합니다. 두 GPU의 메모리를 한 작업에 합치는 방식은 아니며, GPU별 워커를 풀로 운영하는 구성입니다.
이미지뿐 아니라 비디오와 오디오 생성 작업도 맡깁니다. 게임을 만들면서 필요한 코드와 리소스를 함께 다루다 보니 노바가 처리하는 작업도 자연스럽게 넓어졌습니다.

상시 운영과 원격 기동

노바에는 Wake-on-LAN(WoL)을 활성화해 두었습니다. 처음에는 유휴 시간의 전력을 줄이고, 제가 집에 있든 회사에 있든 필요할 때 원격으로 켜서 생성 작업을 하려는 목적이었습니다. 현재는 계속 켜 두고 사용하며, WoL은 시스템이 꺼졌을 때 원격으로 다시 켜는 수단으로 남겨 두었습니다.

Mac mini 서버의 상시 운영과 병렬 러너

루나는 계속 켜 두는 맥미니입니다. n8n 워크플로우와 웹서버를 운영하고, GitHub Actions의 실행 머신으로도 사용합니다.

n8n과 웹서버

정해진 흐름에 따라 반복해서 실행할 작업은 n8n에 맡깁니다. n8n도 AI와 함께 운영하기 편하도록 커스터마이즈해서 사용하고 있습니다. 어떤 부분을 바꾸었고 에이전트가 어떻게 활용하는지는 별도의 글로 정리할 만한 주제입니다.
루나를 구입할 때는 OpenClaw 운영도 목적 중 하나였습니다. 지금은 OpenClaw를 내려 두었지만, 머신은 워크플로우와 서버를 운영하는 역할로 계속 사용하고 있습니다. 처음 생각했던 용도와 지금의 쓰임이 완전히 같지는 않습니다.

GitHub Actions 러너

루나에서는 프로젝트별 GitHub Actions 러너를 병렬로 운영합니다. 현재는 블로샤퍼에 세 개, 구운몽과 포트폴리오에 각각 한 개의 러너를 두고 있습니다.
에이전트가 만든 코드를 확인하는 과정에도 실제 실행 환경이 필요합니다. 루나는 서비스를 계속 운영하는 동시에, 여러 프로젝트에서 올라오는 작업을 실행하는 자리이기도 합니다.

Synology NAS의 웹서비스와 데이터 보관

메이는 시놀로지 NAS입니다. Docker 기반 웹서비스를 몇 개 운영하고 있으며, 지금 이 글을 읽고 있는 🔥firejune.io 도 그중 하나입니다.
각종 코퍼스와 스크래치 데이터도 메이에 보관합니다. 이미지와 영상 파이프라인을 돌리다 보면 데이터가 계속 쌓이기 때문에, 이를 보관하는 자리도 작업 환경에 포함되어 있습니다.
메이라는 이름의 에이전트는 직접 소통할 일이 적어 운영을 중단했지만, NAS는 지금도 사용하고 있습니다. 에이전트를 내려 두었다고 머신의 역할까지 없어진 것은 아닙니다.

작업 지시와 결과 회수

개인 프로젝트의 HQ와 작업 세션은 맥에서 실행합니다. 작업 지시의 정본은 저장소 이슈에 두고, AgentBridge로 작업을 시작시키거나 질의와 완료 보고를 주고받습니다. 아래에서는 맥의 작업 세션과 노바 사이, 그리고 GitHub를 거쳐 루나의 실행 결과를 확인하는 흐름을 나누었습니다.

연산·생성 작업과 검토 순환

CPU 작업은 nova-run이 SSH 위의 rsync로 독립된 작업 스냅샷을 전송하고, SSH를 통해 WSL 풀의 슬롯에서 실행합니다. 출력은 스트리밍으로 확인하며 결과 JSON과 로그를 맥으로 회수합니다.
GPU 작업은 nova-comfy가 ComfyUI HTTP API로 작업 그래프와 입력을 올립니다. 워커에 필요한 모델과 노드가 있는지 확인해 배정하고, HTTP 폴링으로 진행 상태를 확인한 뒤 history와 output을 통해 결과를 내려받습니다.
flowchart TB HQ["Mac · 프로젝트 HQ"] WORK["Mac · 작업 세션"] CPU["WSL CPU 팜(Windows)"] GPU["ComfyUI GPU 워커(Windows)"] REVIEW["증거 검토 · 필요한 재측정·리뷰·시각 판정"] HQ -->|"AgentBridge · 작업 지시"| WORK WORK -->|"nova-run · rsync/SSH 전송·실행"| CPU CPU -->|"SSH 출력 · JSON·로그 회수"| WORK WORK -->|"nova-comfy · HTTP 제출·폴링 요청"| GPU GPU -->|"폴링 응답 · 결과 다운로드"| WORK WORK -->|"AgentBridge · 결과 보고"| HQ HQ --> REVIEW REVIEW -->|"수정 필요 · 재지시"| HQ
검토에는 HQ의 증거 확인과 재측정, 다른 모델의 코드 리뷰, 필요한 경우 사람의 시각적 판단이 들어갑니다. 수정이 필요하면 다시 지시합니다. 작업 자체를 자동 재시도하거나 결과를 보고 자동으로 재작업하는 구조는 아닙니다. 최종 반영 기준은 저장소별로 다릅니다.

CI와 배포 순환

루나의 GitHub Actions 러너는 GitHub에 바깥 방향으로 연결해 long polling으로 작업을 가져옵니다. GitHub가 외부에서 루나에 접속해 명령을 넣는 방식은 아닙니다. 실행 상태는 러너가 GitHub에 보내고, 맥의 HQ는 GitHub API를 폴링해 결과를 읽습니다. 검토 후 수정할 것이 있으면 다시 push하면서 다음 실행으로 이어집니다.
flowchart TB MAC["Mac · HQ와 작업 세션"] GH["GitHub · 저장소와 Actions"] RUNNER["Actions 러너(Mac mini)"] REVIEW["결과 검토"] MAY["Docker 웹서비스(Synology NAS)"] MAC -->|"SSH/HTTPS · push·PR"| GH RUNNER -->|"외부 방향 long polling · 작업 요청"| GH GH -->|"poll 응답 · 실행할 작업"| RUNNER RUNNER -->|"실행 상태 전송"| GH MAC -->|"GitHub API · 결과 조회 요청"| GH GH -->|"API 응답 · 실행 결과"| MAC MAC --> REVIEW REVIEW -->|"수정 필요 · 재작업 후 push"| MAC RUNNER -->|"포트폴리오 빌드 결과 배포"| MAY
포트폴리오 러너의 빌드 결과는 메이의 Docker 서비스로 배포합니다. 스토어의 최종 공개와 필요한 최종 시각 판정은 사람이 담당합니다.
결과 회수에는 맥에서 SSH로 루나의 로그를 가져오는 경로도 사용합니다. 루나의 n8n에서 노바의 ComfyUI에 이미지 생성을 맡기는 워크플로우도 운영하고 있습니다.

작업 방식과 함께 바뀌는 구성

이 구성은 rig-c 개발을 시작하던 9월 초에 자리를 잡았습니다. 이후에도 사용하는 도구와 각 머신에 맡기는 일은 계속 바뀌고 있습니다. OpenClaw를 위해 준비했던 머신이 다른 서비스를 운영하고, 이미지 생성 머신에서 브라우저 검증까지 돌리게 된 것처럼 필요에 따라 역할을 조정합니다.
에이전트를 여러 개 실행하는 것에서 시작했지만, 실제로 일을 이어 가려면 연산을 맡길 곳, 검증할 곳, 계속 켜 둘 곳과 데이터를 보관할 곳도 함께 정해야 했습니다. 집과 사무실 사이에서 작업 맥락을 이어 가는 일도 그중 하나였습니다.
에이전트들이 일을 나누고 결과를 검토하는 방식은 이후 🤝AgentBridge 기반 멀티 에이전트 오케스트레이션로 발전했습니다. 이 글의 구성은 그 작업들이 실제로 실행되는 환경에 해당합니다.
처음부터 제가 혼자 그려 놓은 구성도는 아닙니다. 에이전트 식구들과 필요할 때마다 문제를 하나씩 해결하다 보니 지금의 모습이 되었습니다.