unit-testing

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처럼 개발 생산성을 높여주는 도구들에 대해서도 정기적인 후원과 관심을 기울이는 것이 생태계 전체의 건강함을 유지하는 길입니다.

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가 가장 잘할 수 있는 '로직 구현'에 집중할 수 있도록 개발자가 정확한 맥락과 구조를 먼저 설계해 주는 도구를 구축하는 것이 권장됩니다.