개발 자동화의 기반을 설계하는 software-factory 스킬 사용법
機械翻訳 / Machine-translated
機械翻訳 / Machine-translated
원문: 개발 자동화의 기반을 설계하는 software-factory 스킬 사용법（cccskills）
스킬 페이지: software-factory
이 글의 결론
software-factory는 티켓에서 머지까지를 에이전트에 맡기는 구조를, 공통 용어로 설계하기 위한 스킬입니다.
설치해 두면 개발 리더나 개인 개발자가 정해진 용어와 질문을 따라 설계를 구체화할 수 있게 됩니다.
이 글에서는 통일할 수 있는 용어와 서비스 구성, 설치 방법, 의뢰문 예시, 사용 전에 알아 두어야 할 주의 사항을 순서대로 소개합니다.
software-factory를 사용하면 개발 자동화 설계를 정해진 용어와 정해진 질문으로 구체화할 수 있습니다.
여기서 말하는 "소프트웨어 팩토리"란, 티켓이나 PR, 정기 실행을 계기로 에이전트가 동작하여 머지된 코드로 완성하는 구조를 말합니다.
예를 들어 다음과 같이 요청합니다.
software-factory를 사용하여, 미분류 티켓을 분류하는 소프트웨어 팩토리를 설계해 주세요.
티켓은 GitHub Issues로 관리하고 있습니다.
에이전트는 구조의 전체 모습보다 먼저, 해결하고 싶은 문제부터 이야기를 시작합니다.
미분류 티켓처럼 흔한 과제라면, 첨부된 EXAMPLE-TASKS.md에 있는 대응하는 태스크 예시를 참조합니다.
설계는 "서비스"와 "태스크" 두 가지로 나뉩니다.
서비스 측에서는 티켓 관리나 Git 호스트 등의 슬롯마다 제품을 결정합니다.
태스크 측에서 답하는 것은 실행 조건, 사람의 확인 부분 등 5가지 질문입니다.
모든 슬롯에 제품이 채워지고, 모든 질문에 답이 나오면 설계가 완성됩니다.
대화 도중에 "잡"이나 "워크플로우"라고 말하면, 에이전트는 공식 용어인 "태스크"를 제시합니다.
그 덕분에 팀 내에서 용어가 흔들리지 않고 논의를 진행할 수 있습니다.
이 스킬의 핵심은 설계에서 사용하는 9가지 용어입니다.
에이전트는 이 용어만 사용하며, 피해야 할 표현이 나오면 바꿔 말합니다.
| 용어 | 의미 |
|---|---|
| Task（태스크） | 한 번 정의하여 여러 번 실행하는 작업의 종류. 리뷰, 조사, 구현 등 |
| Trigger（트리거） | 런을 시작하는 계기. 티켓 관리나 Git 호스트의 변경, 시각, 다른 런 |
| Run（런） | 하나의 태스크를 하나의 러너에서 실행하는 1회분 |
| Runner（러너） | 런이 동작하는 일회용 환경. 종료되면 아무것도 남지 않음 |
| Ticket tracker（티켓 관리） | 티켓을 보관하는 곳으로, 사람과 에이전트의 창구 |
| Ticket source（티켓 발생원） | 피드백 버튼, 모니터링, 에러 트래커, 수신함 등 |
| Git host（Git 호스트） | 브랜치, PR, 리뷰를 보관하는 곳 |
| Orchestrator（오케스트레이터） | 트리거를 받아 런을 실행하고, 대기 중·실행 중·완료를 기록하는 것 |
| Observability platform（가시성 플랫폼） | 런의 로그나 상태를 사람이 확인하는 곳. 없어도 됨 |
설계의 전제가 되는 사고방식도 정해져 있습니다.
하나는 런이 사람의 답변을 기다리지 않고 일단 종료된다는 것입니다.
사람이 티켓이나 PR을 변경했을 때 새로운 런이 시작됩니다.
또 하나는 러너에 이전 기억이 남지 않는다는 것입니다.
그래서 과거의 경위는 티켓 관리, Git 호스트, 오케스트레이터에만 남습니다.
트리거를 늘릴수록 자동화는 가속되지만, 제동이 없으면 품질 낮은 변경이 대량 생산됩니다.
그래서 다음 3가지 브레이크를 도입합니다.
| 브레이크 | 내용 |
|---|---|
| 자동 체크 | 타입, 린트, 테스트 등, 모든 런이 통과해야 하는 정해진 관문 |
| 자동 리뷰 | 다른 런이 차분을 선입견 없이 읽고, 규약이나 티켓과 대조함 |
| 사람의 리뷰 | 머지 전에 사람이 PR을 읽음. 발견한 문제는 자동 체크나 자동 리뷰에 반영 |
자동 트리거는 하나씩 추가하고, 처음에는 좁혀서 운영합니다.
버그 보고 10건 중 1건만 처리하거나, 정기 실행은 하루 1회로 하는 식입니다.
아울러 처음에는 모든 PR을 사람이 확인합니다.
런의 반복에도 몇 번이 지나면 사람에게 돌려보내는 상한을 설정해 둡니다.
각 서비스는 제품을 배치하는 슬롯으로 취급합니다.
하나의 제품으로 여러 슬롯을 채워도 됩니다.
스킬에 실린 구성 예시는 다음 3가지입니다.
| 서비스 | 모두 GitHub | 티켓은 Linear | 직접 만든 트래커 |
|---|---|---|---|
| 티켓 관리 | GitHub Issues | Linear | 직접 만든 앱 |
| 티켓 발생원 | 피드백 버튼 | 피드백 버튼, 모니터링 | 피드백 버튼, 모니터링 |
| Git 호스트 | GitHub | GitHub | GitHub |
| 오케스트레이터 | GitHub Actions | 직접 만든 서버와 데이터베이스 | 직접 만든 앱 |
| 러너 | Actions 러너 | Actions, E2B, Daytona, VPS | 직접 만든 앱이나 샌드박스 |
| 가시성 플랫폼 | 없음（Actions 실행 화면으로 충분） | LLM 트레이스 도구 | 직접 만든 앱 |
기본 방침은 "서비스는 사고, 태스크는 만든다"입니다.
설계의 고민은 태스크에 담고, 서비스는 범용 제품으로 해결합니다.
티켓 관리에 대해서는 기성 제품이 권장됩니다.
안정적이고, 사용자가 이미 사용법을 알고 있으며, 외부 사람도 초대하기 쉽기 때문입니다.
각 태스크에 대해 다음 5가지 질문에 답합니다.
티켓 발생원에 대해서는, 같은 티켓을 중복 등록하지 않기 위한 구조를 묻습니다.
터미널에서 다음 명령어를 실행하세요.
도중에 Claude Code나 Codex 등 설치할 대상을 선택할 수 있습니다.
npx skills add https://github.com/mattpocock/skills --skill software-factory
에이전트에 설치를 맡길 경우, 다음 문구를 그대로 보내 주세요.
次の Agent Skill をインストールしてください。
https://github.com/mattpocock/skills/tree/main/skills/in-progress/software-factory
まず SKILL.md と付属ファイルの中身を確認し、不審な処理（外部への送信、認証情報の読み取りなど）がないことを確かめてから、Claude Code なら ~/.claude/skills/software-factory/、Codex なら ~/.agents/skills/software-factory/ に配置してください。
설치 위치는 모든 프로젝트에서 사용할지 여부에 따라 선택합니다.
| 설치 대상 | 모든 프로젝트에서 사용 | 특정 프로젝트에서만 사용 |
|---|---|---|
| Claude Code | ~/.claude/skills/ | 프로젝트의 .claude/skills/ |
| Codex | ~/.agents/skills/ | 프로젝트의 .agents/skills/ |
이 스킬은 에이전트가 스스로 판단하여 로드하지 않도록 설정되어 있습니다.
사용할 때는 의뢰문에서 스킬 이름을 지정하거나, Claude Code라면 /software-factory로 호출하세요.
첫 번째는 무엇부터 자동화할지 정하지 못했을 때의 상담입니다.
software-factory를 사용하여, 리뷰 대기 중인 PR이 쌓이는 문제를 해결하는 팩토리를 설계해 주세요.
처음에는 사람의 리뷰를 남긴 채로 시작하고 싶습니다.
에이전트는 EXAMPLE-TASKS.md에서 맞는 태스크를 선택하고, 서비스 슬롯과 각 태스크의 5가지 질문을 순서대로 채워 나갑니다.
첫 번째 트리거는 하나로 좁히고, 어디서 사람이 확인하는지도 답에 포함합니다.
두 번째는 제품 선택에 대한 상담입니다.
software-factory를 사용하여, 러너에 무엇을 쓸지 결정하고 싶습니다.
GitHub Actions와 외부 샌드박스를 비교해 주세요.
에이전트는 첨부된 RUNNERS.md를 읽어 전체 그림을 파악한 후, 현재의 선택지를 다시 조사합니다.
조사 자료에서는 선택지가 종류별로 나뉘어 있고, 그 슬롯을 결정하기 위한 질문이 나열되어 있습니다.
돌아오는 것은 그 질문에 따른 비교입니다.
세 번째는 하나의 태스크를 구체화하는 의뢰입니다.
software-factory를 사용하여, PR 자동 리뷰 태스크에 대해 실행 조건, 읽고 쓰는 서비스, 다음에 실행하는 것, 사람의 확인 부분, 중복 실행 방지 방법을 정리해 주세요.
5가지 질문에 하나씩 답한 정리 내용이 돌아옵니다.
답이 나오지 않은 항목은 그대로 설계의 미결 사항으로 남습니다.
software-factory는 설계를 정리하기 위한 스킬입니다.
포함된 파일은 SKILL.md와 5개의 Markdown 자료뿐이며, 자동화를 동작시키는 스크립트는 들어 있지 않습니다.
GitHub Actions 설정이나 러너 구축은 설계가 확정된 후에 별도로 진행하게 됩니다.
첨부된 조사 자료에 있는 제품 정보는 전체 그림을 파악하기 위한 단서입니다.
SKILL.md에는 현재의 선택지는 에이전트가 직접 다시 조사하도록 적혀 있습니다.
제품의 기능이나 요금은 결정하기 전에 공식 정보로 확인하세요.
스킬은 리포지토리의 in-progress 폴더에 위치하며, 라이선스는 MIT입니다.
설치 전과 업데이트했을 때 SKILL.md와 첨부 파일의 내용을 읽어 두면 안심할 수 있습니다.
같은 mattpocock/skills 리포지토리에는 설계 전후에 사용할 수 있는 스킬도 있습니다.
code-review는 규약 준수와 사양 실현을 나누어 변경 사항을 리뷰하는 스킬입니다.
자동 리뷰 태스크를 고려할 때 참고가 됩니다.
domain-modeling은 프로젝트의 업무 용어나 개념의 경계를 정리하여 용어집에 기록하는 스킬입니다.
어떤 스킬부터 시작할지 고민될 때는 ask-matt에 상담할 수 있습니다.
ask-matt는 상황에 맞는 스킬과 순서를 안내해 줍니다.
이 스킬이 다루는 것은 설계의 용어와 사고방식이며, 구축 절차나 스크립트는 포함되어 있지 않습니다.
도움이 되는 것은 어떤 서비스를 사용하고, 어떤 태스크를 무엇을 계기로 동작시킬지 결정하는 단계까지입니다.
가능합니다.
구성 예시 중 하나가 티켓 관리를 GitHub Issues, 오케스트레이터를 GitHub Actions, 러너를 Actions 러너로 하는 형태입니다.
이 구성에서는 Actions 실행 화면으로 충분하므로 가시성 플랫폼은 두지 않습니다.
해결하고 싶은 문제를 그대로 전달해 주세요.
미분류 티켓, 자동 리뷰 대기 중인 PR, 아무도 읽지 않는 버그 보고 등이 있다면, 에이전트가 EXAMPLE-TASKS.md에서 대응하는 태스크 예시를 보여 줍니다.
자동 체크, 자동 리뷰, 사람의 리뷰 3가지 브레이크를 도입하는 것이 전제입니다.
트리거는 하나씩 좁혀서 추가하고, 모든 PR을 사람이 확인하는 것부터 시작합니다.
브레이크가 신뢰할 수 있다고 판단된 후에 조금씩 범위를 넓혀 나갑니다.
software-factory는 티켓이나 PR에서 머지까지를 에이전트에 맡기는 구조를, 공통 용어로 설계하기 위한 스킬입니다.
팀 내에서 용어가 통일되지 않은 개발 리더나, 구성을 처음부터 고민하는 개인 개발자에게 적합합니다.
처음에 정리할 것은 해결하고 싶은 문제와, 그것을 담당하는 첫 번째 태스크의 5가지 질문입니다.
거기서부터 슬롯별 제품을 결정하고, 트리거를 하나씩 늘려 나갑니다.
설치 방법과 개요는 cccskills 페이지에 정리되어 있습니다.
리포지토리는 https://github.com/mattpocock/skills/tree/main/skills/in-progress/software-factory 입니다.
이 글은 cccskills의 읽을거리 「개발 자동화의 기반을 설계하는 software-factory 스킬 사용법」의 전재입니다.
스킬의 상세 내용과 설치 방법은 cccskills의 software-factory 페이지에 있습니다.