노트북을 닫아도 에이전트가 이슈를 처리합니다 — Leon van Zyl 소프트웨어 팩토리를 오늘 내 저장소에 연결합니다 | DAKER 커뮤니티
코딩 에이전트를 한 창에서만 지켜보면, 노트북을 닫는 순간 작업도 멈춥니다. Leon van Zyl의 유튜브 영상 「I Built the Simplest Software Factory (You Can Copy It)」(2026-09-24)는 그 한계를 우회하는 구성을 보여 줍니다. GitHub 이슈에 ready 라벨만 달면, 클라우드 박스 위의 Claude Code·Codex 에이전트가 작업을 받아 풀 리퀘스트까지 올립니다. 오늘은 이 흐름을 영상 기준으로 정리하고, 내 저장소에 연결할 때 바로 할 일을 적어 둡니다.
소프트웨어 팩토리는 코딩 에이전트가 아닙니다
영상에서 말하는 소프트웨어 팩토리는 Claude나 Codex 자체가 아닙니다. 신호(시그널)를 받아 일을 배분하고, 에이전트 상태를 추적하고, 결과를 이슈·PR로 되돌리는 하네스(시스템)입니다. 신호는 GitHub 이슈뿐 아니라 Slack·Telegram 같은 메시지도 될 수 있다고 설명합니다. 트리아지(분류·배정) 단계에서는 LLM으로 버그·기능·문서를 나눌 수도 있고, LLM 없이 단순 코드로 빈 에이전트에 배정할 수도 있습니다. 영상 데모는 후자, 즉 GitHub 이슈 디스패처 방식입니다. 팩토리는 “대기 중인 에이전트 무리”를 관리하는 쪽에 가깝고, 실제 코드 수정은 워커 에이전트가 담당합니다.
참가자에게 바뀌는 점
평소에는 “에이전트 세션을 내가 열어 두고 지시한다”가 기본입니다. 팩토리 패턴에서는 “이슈를 남기고 ready를 단다”가 시작점이 됩니다. 에이전트는 Upstash Box 같은 클라우드 리눅스 VM에서 돌아가므로, 노트북을 닫아도 작업이 이어집니다. 영상에서는 박스당 대략 2CPU·4GB RAM 예를 들고, 이슈 본문에 섞일 수 있는 프롬프트 인젝션을 막기 위해 로컬 머신 비밀값에 접근하지 않는 샌드박스 실행을 강조합니다. 완성 후에는 에이전트가 바로 머지하지 않고 PR을 올려 사람이 검토합니다. 어두운 공장(dark factory)처럼 자동 머지하는 구성이 아니라고 분명히 말합니다. 전화로 GitHub에 이슈만 남겨도 워커가 PR을 준비해 둘 수 있다는 장면이 이 차이를 잘 보여 줍니다.
Claude와 Codex를 라벨로 나눕니다
데모에는 약 10개 에이전트 스웜이 나오고, Claude Code와 Codex를 섞어 씁니다. 이슈에 에이전트 종류 라벨을 붙이면 그쪽으로 배정하고, 라벨이 없으면 기본 정책(Claude 우선·Codex 우선·균등)을 따릅니다. 영상은 복잡한 코드는 Claude, 3D 작업은 GPT-6 Astra(Codex 쪽)처럼 강점에 맞춰 나누라고 제안합니다. 문서만 고치는 단순 작업에는 더 가벼운 모델을 쓸 수도 있다고 합니다. 대회·해커톤 저장소에서도 “리뷰용 에이전트”와 “구현용 에이전트”를 라벨로 갈라 두면, 같은 이슈 보드에서 역할이 섞이지 않습니다. 라벨이 바뀌는 과정도 운영에 도움이 됩니다. ready → factory running → factory review처럼 상태가 이슈에 그대로 보이므로, 채팅을 뒤지지 않아도 진행을 확인할 수 있습니다.
영상 속 구축 순서
- 관리할 GitHub 저장소를 하나 이상 준비합니다. 공개 저장소면 다른 사람이 이슈를 열어 팩토리를 자극할 수 있으니, 시작은 비공개·또는 본인 이슈만 처리하도록 트리아지를 제한하는 편이 안전합니다. 영상에서는 RTS 데모와 to-do 앱 두 저장소를 연결하는 예를 씁니다.
- Upstash Box에서 에이전트가 돌 클라우드 VM을 씁니다. 영상은 무료 플랜으로도 따라 할 수 있다고 안내하며, 무료 플랜 박스 한도는 최대 10개라고 말합니다. 데모에서는 4개(Claude 2·Codex 2)로 시작했습니다.
- 팩토리 자체 코드는 GitHub Actions 쪽에서 돌아가도록 구성합니다. Leon은 직접 코딩하지 않고, 공개 스킬 저장소의 「create Upstash software factory」 스킬을 에이전트에 설치한 뒤 슬래시 명령으로 생성하게 합니다. 스킬에는 박스 생성·에이전트 설치·이슈 루프·GitHub Actions 연결에 필요한 참고가 들어 있습니다.
- 스킬 인터뷰에서 연결할 저장소, Claude 구독/API·Codex 사용 여부, 팩토리 저장소 이름(비공개 권장), 박스 수, 기본 에이전트, 브라우저 앱이면 agent-browser 포함 여부를 고릅니다. Context7로 최신 문서를 읽게 할지는 선택이며, 거절해도 웹 검색으로 진행된다고 합니다.
- 비밀값은 .env에 세 가지를 둡니다. Upstash Box API 키, GitHub fine-grained PAT(Contents·Issues·Pull requests 읽기/쓰기, 가능하면 선택 저장소만), Claude Code OAuth 토큰(구독으로 돌릴 때). 영상에서는 채팅에 붙여 넣기보다 .env 파일 직접 수정을 권합니다. PAT 만료를 짧게 두는 장면도 나옵니다.
- 스모크 테스트용 박스를 만들었다가 지운 뒤, 관리 대상 저장소에 팩토리가 연 연결용 PR을 머지합니다. 이 PR이 “ready 이슈 → 팩토리” 신호를 보냅니다. dry-run으로 연결만 확인한 다음, dry-run을 끄고 실제 수정을 돌립니다.
- 시험 이슈를 만들고 ready 라벨을 달면, 이슈 라벨이 factory running → factory review로 바뀌고, 댓글에 워커 이름(예: Claude02)과 PR 링크가 달립니다. 사람이 PR을 머지합니다. 권한 때문에 명령이 막히면 Claude Code에서 해당 명령을 허용해 주면 된다고 안내합니다.
스냅샷으로 스킬을 미리 싣습니다
박스마다 스킬·MCP·AGENTS.md를 반복 설치하지 않으려면 Upstash 스냅샷을 씁니다. Claude용·Codex용 스냅샷을 만들어 두고, 새 박스는 그 이미지에서 띄웁니다. frontend-design 스킬이나 agent-browser처럼 공통으로 쓸 도구를 스냅샷에 넣으면, 이후 생성되는 워커가 같은 환경을 물려받습니다. 영상에서 중요한 제약도 나옵니다. 에이전트는 박스·스냅샷을 삭제하지 못하므로, 옛 이미지는 사람이 지운 뒤 새 스냅샷으로 박스를 다시 만들어야 합니다. 박스를 늘리는 스케일도 “10개로 늘려 달라”는 한 문장으로 요청하는 장면을 보여 줍니다.
저장소를 추가할 때
새 프로젝트 저장소를 붙일 때도 순서는 같습니다. GitHub fine-grained 토큰의 선택 저장소 목록에 새 저장소를 추가하고, 팩토리 에이전트에게 해당 저장소를 팩토리에 넣어 달라고 요청합니다. 연결용 PR이 열리면 머지한 뒤, ready 이슈로 한 번 더 시험합니다. 3D 비중이 큰 앱이면 Codex 라벨을 같이 달아 배정하는 예가 영상에 나옵니다. 토큰에 저장소가 빠져 있으면 에이전트가 접근 실패를 보고하므로, PAT 범위부터 다시 확인하면 됩니다.
오늘 바로 할 일
새 도구를 전부 깔기 전에, 아래 네 가지만 먼저 확인하면 됩니다.
- 팩토리로 맡길 GitHub 저장소 하나를 고릅니다. 가능하면 비공개이거나, 이슈 작성자를 본인으로 제한할 계획을 적습니다.
- Leon의 스킬 저장소(https://github.com/leonvanzyl/skills)에서 create Upstash software factory 스킬 경로를 열어, 에이전트에 설치할 URL을 복사합니다.
- Upstash Box 콘솔(https://console.upstash.com/box)에서 계정·API 키 발급 화면까지 들어가 둡니다. 무료 한도(영상 기준 박스 최대 10)를 확인합니다.
- GitHub fine-grained PAT 초안을 만듭니다. Contents·Issues·Pull requests 권한, 대상 저장소만 선택. 만료일을 짧게 두는 편이 안전합니다. 토큰 문자열은 이 글에 붙이지 말고 .env에만 넣습니다.
이 네 가지가 준비되면, 로컬 코딩 에이전트에게 스킬 설치 → 팩토리 생성 → 연결 PR 머지 → ready 이슈 한 건 시험 순서로 진행하면 됩니다. 첫 시험은 “라이트·다크 모드 추가”처럼 범위가 작은 이슈가 영상과 잘 맞습니다. 이슈 설명에 재현 절차와 기대 결과를 짧게 쓰면, 워커가 PR 본문을 채우기 쉽습니다.
대회·해커톤에 옮길 때
DAKER·DACON 대회 저장소에 바로 붙이기보다, 먼저 개인 포크나 팀 전용 비공개 저장소에서 팩토리 루프를 검증하는 편이 안전합니다. 제출 마감·리더보드 제출 횟수는 사람이 관리해야 하고, 에이전트 PR은 코드 리뷰 게이트 뒤에 두는 것이 영상과도 일치합니다. 이슈 템플릿에 “재현 절차·기대 결과·금지 명령”을 적어 두면, 샌드박스 안에서도 작업 범위가 덜 흔들립니다. 팀원에게는 ready 라벨 의미와 factory review에서 사람이 볼 체크리스트(테스트 통과, 비밀값 미포함, 제출 스크립트 미변경)를 공유해 두면 운영이 단순해집니다.
정리
이 영상은 “더 센 모델”이 아니라 “이슈 → 배정 → 샌드박스 에이전트 → 사람 머지”라는 운영 루프를 복제 가능한 스킬로 보여 줍니다. 노트북을 닫아도 일이 이어지게 하려면, 오늘 저장소 하나·스킬 URL·Upstash 키·짧은 수명 PAT 네 가지만 먼저 고정하면 됩니다. 그다음 ready 이슈 한 건으로 루프가 한 바퀴 도는지 확인하면, 이후 박스 수와 스냅샷은 필요에 따라 천천히 늘리면 됩니다.
영상이 말하는 루프를 한 줄로
신호(이슈) → 디스패처 배정 → 샌드박스 워커(Claude 또는 Codex) → 검증·PR → 사람 머지 → 다음 신호 대기. 이 다섯 단계를 로컬 세션이 아니라 GitHub·Upstash·Actions에 걸쳐 두었기 때문에, 자리를 비워도 워커가 이슈를 처리할 수 있습니다. 오늘 연결의 목표는 이 루프가 내 저장소에서 한 바퀴 도는지 확인하는 것입니다. 한 바퀴가 확인되면 박스와 스냅샷을 늘려도 늦지 않습니다.
출처
Leon van Zyl, 「I Built the Simplest Software Factory (You Can Copy It)」, YouTube, 2026-09-24.
https://www.youtube.com/watch?v=AsvzMlLyQ38
스킬 저장소: https://github.com/leonvanzyl/skills
Upstash Box: https://console.upstash.com/box