Syoitu의 AI 개발 공장, 채팅 요청을 디자인·구현 PR로 잇고 두 차례 승인

Qiita 사용자 Syoitu den(@Syoitu)은 11월 4일 채팅으로 받은 앱 의뢰를 디자인·구현 PR로 연결하는 AI 개발 공장 사례를 공개했습니다. AI가 요구사항을 정리하고 모크 앱을 만들며, 사람은 디자인 미리보기와 앱 공개를 두 차례 승인하는 흐름입니다. 글은 이 개인 사례를 통해 소프트웨어 공장의 구성요소와 작업 연결 방식을 설명합니다.

티켓과 실행을 연결하는 구조

Matt Pocock의 용어집은 소프트웨어 공장을 티켓, PR, 일정 등을 입력받아 원격 인프라에서 병합된 코드를 만드는 에이전트 체계로 정의합니다. 작업(task)은 구현이나 리뷰처럼 반복 수행할 일의 종류이고, 실행(run)은 그 작업을 러너에서 한 차례 수행하는 단위입니다. 실행은 사람의 응답을 기다리지 않고 끝납니다. 사람이 티켓이나 PR을 변경하거나 오케스트레이터가 후속 실행을 시작하면 새 실행이 이어집니다. 실행 사이의 상태와 맥락은 티켓 트래커, Git 호스트, 오케스트레이터에 남습니다.

용어집은 Claude Code 클라우드 세션 같은 제품을 각 작업 실행을 맡는 러너의 선택지로 둡니다. 티켓 트래커는 의뢰와 진행 상황을 주고받고, Git 호스트는 브랜치와 PR을 보관합니다. 오케스트레이터는 신호를 받아 실행을 시작하고 진행 상태를 기록합니다. 실행이 PR을 만들면 그 PR이 자동 리뷰 작업을 부를 수 있고, 리뷰에서 문제가 발견되면 수정 작업으로 이어질 수 있습니다. 오케스트레이터가 다음 실행을 직접 시작하거나 티켓·PR의 변경을 다음 실행의 신호로 삼는 두 방식이 있습니다.

용어집은 기존 서비스를 조합하고 공장마다 다른 업무를 작업으로 정의하는 설계를 제시합니다. 모든 서비스를 GitHub로 구성하는 예에서는 GitHub Issues가 티켓 트래커, Actions가 오케스트레이터와 러너 역할을 맡습니다. Actions 실행 화면에서 진행 상황도 볼 수 있습니다. Matt Pocock의 software-factory 스킬은 이 설계 용어를 정리한 사용자 호출형 안내입니다. 스킬 PR은 10월 31일 병합됐으며, 스킬은 저장소의 in-progress 폴더에 배치돼 있습니다.

채팅 요청에서 디자인·구현 PR까지

Syoitu의 사례는 포털 채팅으로 시작합니다. Bedrock의 Claude가 사용자의 불편과 원하는 앱을 묻고, 음성 입력에는 Amazon Transcribe를 씁니다. 이용자가 의뢰 내용을 확정하면 GitHub App이 foundry 라벨을 붙인 이슈를 만듭니다. 라벨이 붙은 이슈가 자동화의 입력이 되며, 이슈와 PR, 체크 결과, Actions 실행 상태는 GitHub에 저장됩니다. 포털은 별도 데이터베이스에 작업 상태를 복제하지 않고 GitHub 기록을 읽어 진행 상황을 표시합니다.

첫 실행은 agent-design 작업입니다. Claude Code가 요구사항을 사양서와 화면별 HTML로 정리해 디자인 PR을 만들고, PR에 미리보기 주소를 남깁니다. 사람이 미리보기를 확인한 뒤 진행을 승인하면 디자인 PR이 병합됩니다. 고칠 부분이 있으면 PR에 의견을 적고 같은 디자인 작업을 다시 실행합니다. 디자인 미리보기를 중간 산출물로 둔 뒤 승인을 받아 구현으로 넘어갑니다.

디자인 PR의 병합은 agent-build를 시작하는 신호입니다. 이 작업은 승인된 디자인을 바탕으로 Next.js 모크 앱을 만들고 구현 PR을 엽니다. 타입 검사와 lint, 빌드를 포함한 CI가 통과해야 공개 버튼이 활성화됩니다. 이용자가 공개를 승인하면 구현 PR을 병합하고 이슈를 닫은 뒤 앱을 배포합니다. 배포가 끝나면 미리보기와 작업 브랜치도 삭제합니다.

사람이 개입하는 지점은 디자인 미리보기 검토와 앱 공개 승인입니다. 작성자가 설명한 사람의 검토 대상은 디자인 미리보기입니다. 자동화는 작업 연결과 산출물 작성을 맡고, 디자인 진행과 앱 공개는 사람의 승인으로 결정됩니다.

실패와 반복 지적을 작업에 반영

작성자가 설명한 구성에서 포털과 앱은 S3와 CloudFront로 제공하고 포털 API는 Lambda에서 운영합니다. Actions 러너는 일회성 Ubuntu 환경에서 Claude Code를 실행하며, Bedrock의 Claude는 도쿄 리전에서 호출합니다. Actions는 장기 액세스 키 대신 GitHub OIDC로 AWS 역할을 받아 접근합니다.

작성자는 실제로 생기는 문제에 맞춰 작업을 추가하는 방식을 설명합니다. 반복되는 리뷰 지적을 줄이는 자동 리뷰 작업은 현재 사례에 들어 있지 않으며, 추가할 수 있는 작업으로 제시합니다. 실행이 실패하면 오류 로그를 이슈로 만들고 수정 PR까지 내는 Fix 작업을 붙이는 방안도 들었습니다. 공장 자체를 바꾸는 작업에는 책임자의 검토를 거치게 하는 구상입니다.

리뷰 지침을 스킬에 더하거나, PR 댓글과 수동 수정에서 반복된 개선점을 모아 스킬 변경 PR을 만드는 방법도 제안합니다. 생성된 앱은 하나의 모노레포에 모이고 공통 부품은 여러 앱이 함께 씁니다. 이 구상에서 작업 추가는 새 문제를 맡기고, 스킬 수정은 반복 지적을 지침에 반영하며, 공통 부품은 새 앱에서 활용할 수 있는 구현 범위를 넓힙니다.