GitHub 이슈에 ready만 달면 PR까지: Leon van Zyl의 소프트웨어 팩토리 구성 정리 | DAKER 커뮤니티

소프트웨어 팩토리를 오늘 저장소에 연결하는 흐름을 정리한 생성 이미지

한 줄 답: Leon van Zyl 영상(2026-09-24) 기준, GitHub 이슈에 ready 라벨을 달면 Upstash Box 등 클라우드 VM의 Claude Code·Codex 워커가 작업을 받아 PR까지 올리는 소프트웨어 팩토리 하네스입니다. 자동 머지가 아니라 사람 리뷰 후 머지하는 루프이며, 박스당 약 2CPU·4GB RAM·무료 플랜 박스 한도 최대 10개 같은 숫자는 영상 설명 기준입니다.

중요한 점은 이것이 단순히 더 강한 모델을 쓰는 이야기가 아니라는 데 있습니다. 이 글에서는 영상의 핵심을 따라, 소프트웨어 팩토리가 무엇인지, 실제로 저장소에 연결할 때 무엇을 먼저 준비하면 좋은지 차례로 정리합니다.

소프트웨어 팩토리는 에이전트 자체가 아니라 운영 하네스입니다

영상에서 말하는 소프트웨어 팩토리는 Claude나 Codex 그 자체가 아닙니다. 신호를 받아 일을 배분하고, 에이전트 상태를 추적하고, 결과를 다시 이슈와 PR로 돌려주는 시스템에 가깝습니다. 신호는 GitHub 이슈일 수도 있고, Slack·Telegram 같은 메시지일 수도 있다고 설명합니다.

트리아지 단계도 두 갈래로 나뉩니다. LLM을 써서 버그·기능·문서를 분류할 수도 있고, 더 단순하게는 코드 기반 규칙으로 빈 에이전트에게 배정할 수도 있습니다. 영상의 데모는 후자에 가깝습니다. GitHub 이슈를 디스패처가 읽고, 대기 중인 워커 에이전트에게 넘기는 방식입니다.

팩토리는 코드를 직접 고치는 주체라기보다, 대기 중인 에이전트 무리를 관리하고 결과를 다시 저장소로 연결하는 시스템입니다.

참가자 입장에서 달라지는 점

평소에는 사용자가 에이전트 세션을 직접 열어 두고 지시하는 방식이 기본입니다. 하지만 팩토리 패턴에서는 이슈를 남기고 ready 라벨을 다는 것이 시작점이 됩니다. 에이전트는 Upstash Box 같은 클라우드 리눅스 VM에서 돌아가므로, 노트북을 닫아도 작업은 이어집니다.

영상에서는 박스당 대략 2CPU·4GB RAM 구성을 예로 들고, 이슈 본문에 섞일 수 있는 프롬프트 인젝션을 막기 위해 로컬 머신 비밀값에 접근하지 않는 샌드박스 실행을 강조합니다. 작업이 끝나도 에이전트가 바로 머지하지는 않습니다. PR을 올리고, 사람의 검토를 거쳐 머지하는 구조입니다.

이 구성은 자동 머지까지 밀어붙이는 dark factory가 아니라, 샌드박스 워커가 PR을 준비하고 사람은 마지막 판단을 맡는 운영 루프입니다.

영상에서 전화로 GitHub 이슈를 남긴 뒤 워커가 PR을 준비하는 장면은, 이 차이를 잘 보여 줍니다. 사용자가 계속 세션을 붙잡고 있지 않아도 흐름이 이어진다는 점이 핵심입니다.

Claude와 Codex를 라벨로 나누는 방식

데모에는 약 10개 에이전트 스웜이 등장하고, Claude Code와 Codex를 섞어 씁니다. 이슈에 에이전트 종류 라벨을 붙이면 해당 쪽으로 배정하고, 라벨이 없으면 기본 정책을 따릅니다. 영상에서는 Claude 우선, Codex 우선, 균등 분배 같은 정책을 둘 수 있다고 설명합니다.

또한 작업 성격에 따라 역할을 나누는 예도 제시합니다. 복잡한 코드는 Claude, 3D 작업은 GPT-6 Astra(Codex 쪽)처럼 강점에 맞춰 배정하고, 문서 수정처럼 단순한 작업에는 더 가벼운 모델을 쓰는 식입니다. 대회나 해커톤 저장소에서도 리뷰용 에이전트와 구현용 에이전트를 라벨로 분리해 두면 같은 이슈 보드 안에서 역할이 섞이지 않습니다.

상태 라벨도 운영에 도움이 됩니다. ready에서 시작해 factory running, factory review로 바뀌는 흐름이 이슈에 그대로 남기 때문에, 채팅 로그를 뒤지지 않아도 진행 상황을 확인할 수 있습니다.

라벨은 단순한 분류표가 아니라, 어떤 에이전트가 어떤 상태로 일하고 있는지 드러내는 운영 인터페이스가 됩니다.

영상 속 구축 순서

  1. 관리할 GitHub 저장소를 하나 이상 준비합니다. 공개 저장소라면 다른 사람이 이슈를 열어 팩토리를 자극할 수 있으므로, 시작은 비공개 저장소이거나 본인 이슈만 처리하도록 트리아지를 제한하는 편이 안전합니다. 영상에서는 RTS 데모와 to-do 앱 두 저장소를 연결합니다.
  2. Upstash Box에서 에이전트가 돌 클라우드 VM을 준비합니다. 영상은 무료 플랜으로도 따라 할 수 있다고 안내하며, 무료 플랜 박스 한도는 최대 10개라고 말합니다. 데모에서는 4개(Claude 2·Codex 2)로 시작했습니다.
  3. 팩토리 자체 코드는 GitHub Actions 쪽에서 돌아가도록 구성합니다. Leon은 직접 코딩하지 않고, 공개 스킬 저장소의 create Upstash software factory 스킬을 에이전트에 설치한 뒤 슬래시 명령으로 생성하게 합니다.
  4. 스킬 인터뷰에서 연결할 저장소, Claude 구독/API·Codex 사용 여부, 팩토리 저장소 이름, 박스 수, 기본 에이전트, 브라우저 앱이면 agent-browser 포함 여부를 고릅니다. Context7로 최신 문서를 읽게 할지는 선택 사항이며, 거절해도 웹 검색으로 진행된다고 합니다.
  5. 비밀값은 .env에 세 가지를 둡니다. Upstash Box API 키, GitHub fine-grained PAT, Claude Code OAuth 토큰입니다. 영상에서는 채팅에 붙여 넣기보다 .env 파일을 직접 수정하는 방식을 권합니다. PAT는 Contents·Issues·Pull requests 읽기/쓰기 권한을 주고, 가능하면 선택 저장소만 대상으로 두며, 만료도 짧게 잡는 장면이 나옵니다.
  6. 스모크 테스트용 박스를 만들었다가 지운 뒤, 관리 대상 저장소에 팩토리 연결용 PR을 머지합니다. 이 PR이 ready 이슈에서 팩토리로 신호를 보내는 연결점이 됩니다. 먼저 dry-run으로 연결만 확인하고, 이후 dry-run을 끄고 실제 수정을 돌립니다.
  7. 시험 이슈를 만들고 ready 라벨을 달면, 이슈 라벨이 factory running에서 factory review로 바뀌고, 댓글에 워커 이름과 PR 링크가 달립니다. 최종 머지는 사람이 맡습니다. 권한 때문에 명령이 막히면 Claude Code에서 해당 명령을 허용해 주면 된다고 안내합니다.

스냅샷으로 반복 설치를 줄이는 방법

박스마다 스킬·MCP·AGENTS.md를 반복 설치하지 않으려면 Upstash 스냅샷을 쓰면 됩니다. Claude용과 Codex용 스냅샷을 만들어 두고, 새 박스는 그 이미지에서 띄우는 방식입니다. frontend-design 스킬이나 agent-browser처럼 공통 도구를 스냅샷에 넣어 두면 이후 생성되는 워커가 같은 환경을 물려받습니다.

영상에서는 제약도 함께 짚습니다. 에이전트는 박스와 스냅샷을 삭제하지 못하므로, 오래된 이미지는 사람이 지운 뒤 새 스냅샷으로 박스를 다시 만들어야 합니다. 박스 수를 늘리는 장면도 나오는데, 10개로 늘려 달라는 한 문장 요청으로 스케일을 조정하는 흐름을 보여 줍니다.

새 저장소를 추가할 때 확인할 점

새 프로젝트 저장소를 붙일 때도 순서는 같습니다. GitHub fine-grained 토큰의 선택 저장소 목록에 새 저장소를 추가하고, 팩토리 에이전트에게 해당 저장소를 팩토리에 넣어 달라고 요청합니다. 연결용 PR이 열리면 머지한 뒤, ready 이슈로 다시 시험합니다.

영상에서는 3D 비중이 큰 앱에 Codex 라벨을 함께 달아 배정하는 예도 나옵니다. 반대로 토큰에 저장소가 빠져 있으면 에이전트가 접근 실패를 보고하므로, 이 경우에는 PAT 범위를 먼저 확인하는 것이 좋습니다.

오늘 바로 준비해 둘 네 가지

새 도구를 한꺼번에 모두 설치하기 전에, 아래 네 가지만 먼저 확인해 두면 흐름을 잡기 쉽습니다.

  1. 팩토리로 맡길 GitHub 저장소 하나를 고릅니다. 가능하면 비공개 저장소이거나, 이슈 작성자를 본인으로 제한할 계획을 세워 두는 편이 안전합니다.
  2. Leon의 스킬 저장소 https://github.com/leonvanzyl/skills 에서 create Upstash software factory 스킬 경로를 열어, 에이전트에 설치할 URL을 복사합니다.
  3. Upstash Box 콘솔 https://console.upstash.com/box 에서 계정과 API 키 발급 화면까지 들어가 둡니다. 무료 한도는 영상 기준 박스 최대 10개입니다.
  4. GitHub fine-grained PAT 초안을 만듭니다. Contents·Issues·Pull requests 권한을 주고, 대상 저장소만 선택하며, 만료일은 짧게 두는 편이 안전합니다. 토큰 문자열은 글이나 채팅이 아니라 .env에만 넣는 것이 좋습니다.

이 네 가지가 준비되면, 로컬 코딩 에이전트에게 스킬 설치, 팩토리 생성, 연결 PR 머지, ready 이슈 한 건 시험 순서로 진행하면 됩니다. 첫 시험은 라이트·다크 모드 추가처럼 범위가 작은 이슈가 영상의 흐름과 잘 맞습니다. 이슈 설명에 재현 절차와 기대 결과를 짧게 적어 두면 워커가 PR 본문을 채우기 쉬워집니다.

대회·해커톤 저장소에 옮길 때

DAKER·DACON 대회 저장소에 바로 붙이기보다, 먼저 개인 포크나 팀 전용 비공개 저장소에서 팩토리 루프를 검증하는 편이 안전합니다. 제출 마감과 리더보드 제출 횟수는 사람이 관리해야 하고, 에이전트 PR은 코드 리뷰 게이트 뒤에 두는 편이 영상의 방향과도 맞습니다.

이슈 템플릿에 재현 절차, 기대 결과, 금지 명령을 적어 두면 샌드박스 안에서도 작업 범위가 덜 흔들립니다. 팀원에게는 ready 라벨의 의미와 factory review 단계에서 사람이 확인할 체크리스트를 공유해 두면 운영이 단순해집니다. 예를 들면 테스트 통과, 비밀값 미포함, 제출 스크립트 미변경 같은 기준입니다.

정리

이 영상이 보여 주는 핵심은 더 강한 모델 경쟁이 아니라, 이슈에서 시작해 배정되고, 샌드박스 에이전트가 작업하고, 사람이 머지하는 운영 루프를 복제 가능한 형태로 만든 점입니다.

신호(이슈) → 디스패처 배정 → 샌드박스 워커(Claude 또는 Codex) → 검증·PR → 사람 머지 → 다음 신호 대기라는 루프를 로컬 세션이 아니라 GitHub·Upstash·Actions 위에 올려 둔 것이 이 구성의 본질입니다.

노트북을 닫아도 일이 이어지게 하려면, 우선 저장소 하나, 스킬 URL, Upstash 키, 짧은 수명 PAT 네 가지부터 준비하면 됩니다. 그다음 ready 이슈 한 건으로 루프가 실제로 한 바퀴 도는지 확인해 보면 됩니다. 박스 수를 늘리거나 스냅샷을 다듬는 일은 그 이후여도 늦지 않습니다.

출처