cloudflare·2026년 8월 4일·4분 읽기큐레이션 요약

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은 다른 팀으로도 확산되고 있다. 실용적으로는 처음부터 모든 개발 과정을 자동화하기보다, 재현·진단·검증처럼 절차가 명확한 좁은 영역부터 시작하는 것이 적절하다. 또한 에이전트의 실패를 숨기기보다 테스트, 문서, 추상화 경계를 개선하는 신호로 활용해야 자동화 품질과 사람 개발자의 생산성을 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)

unit-testingAI 에이전트오픈 소스GitHub Actions+4

spotify·2026년 2월 19일원문

2025년 Spotify FOSS (새 탭에서 열림)

스포티파이는 자사 기술 스택의 근간이 되는 오픈소스 생태계를 지원하기 위해 2025년 '스포티파이 FOSS Fund' 수혜 프로젝트로 FFmpeg, MSW(Mock Service Worker), Xiph.Org 재단을 선정했습니다. 이번 펀딩은 대규모 멀티미디어 인프라부터 개인 개발자가 주도하는 테스팅 도구까지 다양한 규모의 프로젝트에 실질적인 금전적 지원을 제공함으로써 오픈소스의 지속 가능성을 확보하는 데 목적이 있습니다. 스포티파이는 이를 통해 자사가 의존하는 핵심 기술에 보답하고, 자원봉사자 중심으로 운영되는 오픈소스 환경의 안정적인 성장을 돕고자 합니다. ### 멀티미디어 인프라의 핵심, FFmpeg (3만 유로 지원) * **프로젝트 위상:** FFmpeg은 지난 25년간 멀티미디어 인코딩, 디코딩, 트랜스코딩, 스트리밍 분야에서 중추적인 역할을 해온 핵심 인프라입니다. 유튜브, 넷플릭스, 스포티파이 등 세계적인 서비스들이 이 기술에 의존하고 있습니다. * **비전과 목표:** "현존하는 모든 멀티미디어 파일을 재생하는 것"을 목표로 하며, 취미로 영상을 편집하는 개인부터 거대 기업까지 누구나 사용할 수 있는 범용성을 지향합니다. * **자금 활용 계획:** 지원금은 개발용 하드웨어 구매, 컨퍼런스 참가 비용, 그리고 새로운 개발 프로젝트를 추진하는 데 투입될 예정입니다. * **지속 가능성에 대한 제언:** 메인테이너 Kieran은 오픈소스의 장기적인 유지를 위해 기업들이 정규직 개발자를 고용해 프로젝트에 투입하거나, 일회성이 아닌 반복적인 펀딩 구조를 마련해야 한다고 강조했습니다. ### API 모킹의 표준, MSW (1.5만 유로 지원) * **프로젝트 역할:** Mock Service Worker(MSW)는 JavaScript/TypeScript 생태계에서 API 모킹을 가능하게 하여 유닛 테스트를 쉽고 유용하게 만들어주는 도구입니다. 현재 Artem Zakharchenko가 1인 풀타임 메인테이너로 운영하고 있습니다. * **최근 기술적 성과:** 2025년에는 네트워크 레이어(node:net)에서 동작하는 새로운 'Interceptors' 아키텍처를 도입하고, 사용자 요청이 많았던 서버-전송 이벤트(SSE) 지원 기능을 추가했습니다. * **미래 로드맵:** 2026년에는 기술적 난제가 많았던 '원격 요청 가로채기(Remote request interception)' 기능을 완성하고, 요청 가로채기 방식을 완전히 새롭게 정의하는 내부 아키텍처 개편을 단행할 계획입니다. * **개발자 지원:** 지원금은 메인테이너의 생계 유지뿐만 아니라, 외부 기여자들이 지속적으로 프로젝트에 참여할 수 있도록 재정적으로 보상하는 방안을 마련하는 데 사용됩니다. ### 오픈소스 생태계 지원의 다양성 * **조직 규모의 차이:** FFmpeg과 Xiph.Org는 다수의 메인테이너가 참여하는 대규모 프로젝트인 반면, MSW는 개인 개발자가 주도하는 프로젝트입니다. 스포티파이는 규모와 상관없이 생태계에 끼치는 영향력을 기준으로 지원 대상을 선정했습니다. * **기업의 역할 확대:** 프로젝트 관계자들은 기업들이 'Open Source Pledge'와 같은 이니셔티브에 참여하여 오픈소스 소프트웨어를 단순 소비하는 주체에서 지원하는 주체로 변화해야 한다고 입을 모았습니다. 기업이 오픈소스를 활용해 비즈니스를 운영한다면, 해당 프로젝트의 지속 가능성을 위해 실질적인 자금을 투입하는 것은 선택이 아닌 필수적인 투자입니다. FFmpeg과 같은 기반 기술뿐만 아니라 MSW처럼 개발 생산성을 높여주는 도구들에 대해서도 정기적인 후원과 관심을 기울이는 것이 생태계 전체의 건강함을 유지하는 길입니다.

unit-testingTypeScriptJavaScriptstreaming+4

woowahan·2025년 12월 4일원문

AI와 함께하는 테스트 자동화: 플러그인 개발기 | 우아한형제들 기술블로그 (새 탭에서 열림)

낮은 테스트 커버리지 문제를 해결하기 위해 AI를 활용한 테스트 자동화 도구를 개발하고 적용한 과정을 담고 있습니다. 처음에는 AI에게 모든 것을 맡기는 완전 자동화를 시도했으나 높은 컴파일 오류율로 인해 실패했고, 대신 플러그인이 구조적 템플릿을 생성하고 AI가 로직을 채우는 협업 모델을 통해 30분 만에 100개의 테스트 코드를 성공적으로 생성했습니다. 결과적으로 AI의 할루시네이션(환각) 문제를 개발 도구의 맥락 파악 능력으로 보완하여 운영 안정성을 확보할 수 있었습니다. **AI 에이전트 도입과 초기 한계** * 팀의 생산성을 위해 IntelliJ와 통합이 원활하고 프로젝트 전체 컨텍스트 이해도가 높은 Amazon Q를 도입했습니다. * 단순 AI 사용 시 매번 팀 컨벤션을 설명해야 하는 번거로움과 클래스당 약 10분의 소요 시간, 그리고 15% 정도의 빌드 오류가 발생하는 한계가 있었습니다. * 반복적인 프롬프트 작성과 의존성 수집 작업을 자동화하기 위해 IntelliJ 플러그인 개발을 결정했습니다. **플러그인 첫 버전의 실패와 문제 패턴** * 플러그인이 클래스 코드를 수집해 AI API로 직접 전체 테스트 코드를 생성하는 방식을 시도했으나, 컴파일 성공률이 10%에 불과했습니다. * 주요 실패 원인은 존재하지 않는 클래스를 참조하는 할루시네이션, Import 오류, 기존 테스트 코드를 덮어씌워 삭제하는 문제 등이었습니다. * 특히 실제 운영 환경의 멀티모듈 구조에서는 동일한 이름의 클래스가 여러 패키지에 존재하여 AI가 정확한 의존성을 판단하지 못하는 복잡성이 장애물이 되었습니다. **'컴파일 보장 템플릿'을 통한 해결** * AI에게 모든 생성을 맡기는 대신, 플러그인이 PSI(Program Structure Interface) 분석을 통해 정확한 의존성과 메서드 구조가 포함된 템플릿을 먼저 생성하도록 전략을 수정했습니다. * 플러그인은 팀의 테스트 컨벤션(Kotest, MockK 등)을 반영한 골격과 정확한 Import 문을 작성하여 컴파일 오류 가능성을 원천 차단합니다. * 이렇게 생성된 안전한 기반 위에서 Amazon Q가 구체적인 테스트 로직만 채워 넣게 함으로써 생성 정확도를 획기적으로 높였습니다. AI는 복잡한 프로젝트의 구조와 의존성을 파악하는 데 한계가 있으므로, 이를 플러그인과 같은 도구로 보완하는 '하이브리드 접근법'이 실질적인 생산성 향상의 핵심입니다. 단순히 AI에게 모든 것을 요청하기보다, AI가 가장 잘할 수 있는 '로직 구현'에 집중할 수 있도록 개발자가 정확한 맥락과 구조를 먼저 설계해 주는 도구를 구축하는 것이 권장됩니다.

unit-testingAIAI 에이전트Kotlin+5