Astro의 GitHub 이슈를 0개로 만들기 위해 소프트웨어 팩토리를 구축한 방법 (새 탭에서 열림)
AI 에이전트를 소프트웨어 생산 파이프라인처럼 조합하면 오픈소스 이슈 triage를 상당 부분 자동화할 수 있다는 글이다. Astro는 GitHub Actions 안에서 격리된 에이전트들이 이슈 재현·원인 분석·수정·검증을 수행하도록 구성해 열린 이슈를 200개 이상에서 약 30개까지 줄였다. 이 경험은 특정 플랫폼에 종속되지 않는 에이전트 워크플로 프레임워크인 Flue와 재사용 가능한 GitHub Action으로 발전했다. ## 오픈소스 유지보수와 이슈 폭증 - AI 때문에 이슈, pull request, 보안 보고서를 생성하는 비용은 크게 낮아졌다. - 반면 유지보수자가 각 보고서를 읽고 재현하고 검토하는 비용은 증가했다. - 기존의 수동 triage 방식만으로는 늘어나는 입력량을 감당하기 어려워졌다. - Astro 팀은 이슈를 자동으로 닫거나 “issue bankruptcy”를 선언하지 않고, 실제 문제를 해결하는 방향을 택했다. ## 에이전트 스킬로 시작한 자동화 - 첫 자동화 대상은 개발 과정 중 시간이 많이 들고 보상이 적은 이슈 triage였다. - 유지보수자는 로컬 코딩 하네스에서 에이전트 스킬을 개발·테스트한 뒤, 동일한 워크플로를 GitHub Actions에서 실행했다. - 수동 이슈 처리 절차를 다음 단계로 분리했다. - **재현:** 제보자가 제공한 재현용 저장소를 복제하고 문제 발생 여부 확인 - **진단:** 코드에 로깅과 계측을 추가해 근본 원인 파악 - **검증:** 테스트, 주석, 문서를 검토해 실제 버그인지 의도된 동작인지 판단 - **수정:** 재현 사례를 실패하는 단위 테스트로 변환하고 적절한 수정안을 구현 - 각 단계는 서로 격리된 서브에이전트가 담당한다. - 에이전트 간 정보는 `report.md`에 기록해 순차적으로 전달한다. - 단계별 격리는 LLM이 실제 버그가 아닌데도 해결책을 억지로 만들려는 편향을 줄인다. ## GitHub 이슈 라벨 기반 상태 머신 - 자동화 파이프라인은 사실상 이슈 라벨로 구동되는 상태 머신이다. - 새 이슈에는 `triage needed` 라벨이 붙고, 사용자가 수정 사항을 확인하면 `fix verified`로 이동한다. - 별도의 복잡한 내부 상태 저장소 없이, 이슈의 라벨과 기존 댓글을 읽어 현재 상태와 다음 작업을 판단한다. - 수정이 완료되면 다음 작업을 자동 수행한다. - `pkg.pr.new`를 이용해 프리뷰 릴리스 생성 - 분석 결과와 전체 로그를 이슈에 게시 - 제보자가 자신의 프로젝트에서 프리뷰 패치를 설치하도록 안내 - 제보자가 수정 사항을 확인하면 관련 pull request 생성 ## Flue로의 일반화 - 초기에는 GitHub 이슈에 맞춘 시스템처럼 보였지만, 핵심 구조는 플랫폼과 무관한 워크플로였다. - 이벤트를 받고, 격리된 서브에이전트를 순차 실행하며, 추론과 실제 실행 권한을 분리하는 방식은 Slack, cron, webhook 등에도 적용할 수 있다. - 이 구조를 특정 플랫폼이나 모델에 종속되지 않는 런타임으로 확장한 결과가 오픈 프레임워크 **Flue**다. - Flue는 지속적으로 실행 가능한 에이전트와 워크플로를 구축하기 위한 프레임워크를 지향한다. ## 자동화가 커뮤니티에 미친 영향 - 팀은 자동화된 봇 응답이 유지보수자와 사용자 사이를 더 멀어지게 만들 수 있다고 우려했다. - 실제로는 반복적인 이슈 처리에 쓰는 시간이 줄면서 더 가치 있는 커뮤니티 활동에 참여할 수 있었다. - Discord에서 사용자와 직접 소통 - RFC 논의와 신규 기능 요청 검토 - 기여자와 협업해 아이디어를 프레임워크에 통합 - 자동화가 사람과의 소통을 없앤 것이 아니라, 소통의 초점을 더 유용한 논의로 옮겼다는 설명이다. ## 에이전트 실패를 코드베이스 개선 신호로 활용 - 에이전트가 문제를 해결하지 못하면 단순히 모델의 실패로 보지 않고 코드베이스의 결함을 점검한다. - 주요 원인은 다음 세 가지다. - **불투명한 추상화:** 컴포넌트 간 경계가 불명확함 - **부족한 문서화:** 구현 이유와 핵심 로직을 설명하는 주석이 없음 - **불충분한 테스트:** 특히 특정 조건과 회귀 사례를 검증하는 단위 테스트 부족 - HMR 버그 사례에서 에이전트는 특정 `if` 조건을 반복 수정했지만, 다른 곳에 회귀를 일으켰다. - 해당 조건의 의미를 설명하는 주석과 테스트를 추가하자 에이전트는 올바른 설계 의도를 이해하고 잘못된 수정을 반복하지 않게 됐다. - 따라서 에이전트 자동화는 코드 구조, 문서, 테스트 품질을 개선하는 피드백 루프로도 작동한다. ## 독립적인 GitHub Action으로 분리 - 초기 triage 로직은 Astro 모노레포 내부에 직접 들어 있어 변경과 Flue 업그레이드가 어려웠다. - 팀은 이를 `triagebot-action`이라는 독립 저장소로 분리했다. - 분리 후 다음이 가능해졌다. - 자동화 로직의 독립적인 테스트 - 기존 코드베이스에 영향을 주지 않는 안정성 검증 - 여러 프로젝트에서 재사용 - 다른 팀이 그대로 사용하거나 포크해 자체 자동화 공장을 구축 - Astro에서 시작한 이 Action은 다른 팀으로도 확산되고 있다. 실용적으로는 처음부터 모든 개발 과정을 자동화하기보다, 재현·진단·검증처럼 절차가 명확한 좁은 영역부터 시작하는 것이 적절하다. 또한 에이전트의 실패를 숨기기보다 테스트, 문서, 추상화 경계를 개선하는 신호로 활용해야 자동화 품질과 사람 개발자의 생산성을 함께 높일 수 있다.