Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 01. 22:47

AI 에이전트만 사용하여 죽은 오픈 소스 프로젝트를 부활시키다 — 주말 만에 0개 별점에서 500회 이상의 다운로드까지 (GitHub

요약

방치된 오픈 소스 프로젝트인 devtoolbox를 AI 에이전트만을 활용해 72시간 만에 부활시킨 실험적 사례를 다룹니다. 코드 분석, 버그 수정, 문서 생성 및 CI 복구를 자동화하여 프로젝트를 다시 활성화하는 과정을 상세히 설명합니다.

핵심 포인트

  • AI 에이전트를 활용한 자동화된 코드베이스 분석 및 버그 수정
  • 방치된 프로젝트의 이슈 해결 및 문서화 프로세스 자동화
  • GitHub Actions 및 의존성 문제를 해결하는 에이전트 워크플로우
  • AI 에이전트 기반의 오픈 소스 유지보수 가능성 증명

AI 에이전트만 사용하여 죽은 오픈 소스 프로젝트를 부활시키다 — 주말 만에 0개 별점에서 500회 이상의 다운로드까지

요약 (TL;DR): 14개월 동안 손길이 닿지 않았고, 23개의 열린 이슈(open issues), 문서 없음, 고장 난 CI, 그리고 커뮤니티가 전무했던 오픈 소스 개발자 툴킷을 가져왔습니다. 코드 분석, 버그 수정, 문서 생성 및 릴리스 자동화를 위해 AI 에이전트(AI agents)를 사용하여 72시간 만에 프로젝트에 생기를 불어넣었습니다. 추한 부분까지 포함한 전체 이야기를 소개합니다.

무덤 문제 (The Graveyard Problem)

모든 개발자에게는 그런 프로젝트가 하나씩 있습니다. 정말 열광했던 사이드 프로젝트 말이죠. 영리한 아키텍처(architecture), 멋진 이름, 그리고 3시간 동안 공들여 작성한 README를 가진 프로젝트입니다. 그러다... 현실의 삶이 시작됩니다. 새로운 직장, 이사, 번아웃(burnout), 또는 오픈 소스 유지보수는 단거리 경주가 아니라 마라톤이라는 사실을 깨닫게 되는 순간 말입니다.

저 또한 그런 경험이 있었습니다. 하지만 GitHub Finish-Up-A-Thon을 위해, 저는 제가 버린 저장소(repos)보다 더 큰 도전을 하기로 했습니다. 잠재력은 충분하지만 방치되어 썩어가고 있는 다른 누군가의 버려진 프로젝트를 찾아, 오직 AI 에이전트(AI agents)만을 사용하여 죽음에서 되살려낼 것입니다.

규칙은 간단했습니다:

  1. 실제 가치가 있지만 방치된 상태인 프로젝트를 찾을 것
  2. 남아있는 이슈(issues)를 해결할 것
  3. 릴리스(release)를 배포할 것
  4. 모든 것을 문서화할 것

진행 과정은 다음과 같았습니다.

1단계: 무덤 사냥 (0~6시간 차)

적절한 시체 찾기

모든 버려진 프로젝트가 부활할 가치가 있는 것은 아닙니다. 저는 다음과 같은 조건을 갖춘 프로젝트가 필요했습니다:

  • 유용성 (Useful) — 개발자들이 겪는 실제 문제를 해결할 것
  • 견고한 아키텍처 (Architecturally sound) — 뼈대는 좋으나 단지 방치된 상태일 것
  • 수정 가능성 (Fixable) — AI 에이전트가 현실적으로 다룰 수 있는 이슈일 것
  • 영향력 (Impactful) — 의미가 있을 만큼 충분한 잠재적 사용자가 있을 것

저는 GitHub API를 스캔하여 방치된 저장소(repos)를 찾는 Python 스크립트를 작성했습니다:

import requests
import datetime

...

200개 이상의 후보를 분석한 끝에, 완벽한 타겟을 발견했습니다: devtoolbox — 개발자를 위한 Python CLI 툴킷으로, 234개의 별(stars), 23개의 열린 이슈(open issues), 6개의 열린 PR(pull requests)이 있었으며 2025년 3월 이후로 손길이 닿지 않았습니다. 이 프로젝트는 다음과 같은 상태였습니다:

  • 탄탄한 Click 기반의 CLI 아키텍처 (CLI architecture)
  • 유용한 기능들 (프로젝트 스캐폴딩 (project scaffolding), 의존성 분석 (dependency analysis), 코드 메트릭 (code metrics))
  • 명확한 README는 있으나 그 외의 문서는 전무함
  • 고장 난 GitHub Actions (Python 3.8 — EOL (지원 종료))
  • "Windows에서 import 실패"부터 "JSON 출력 지원 추가"까지 아우르는 23개의 이슈 (issues)

이것이 바로 바로 그 대상이었습니다.

2단계: 부검(Autopsy) — 무엇이 죽었는지 이해하기 (6~18시간 차)

무엇인가를 수정하기 전에, 코드베이스 (codebase)를 깊이 있게 이해해야 했습니다. 바로 이 지점에서 AI 에이전트 (AI agents)가 빛을 발합니다. 이들은 단 몇 분 만에 전체 코드베이스를 읽고 이해할 수 있습니다.

아키텍처 스캔 (The Architecture Scan)

저는 프로젝트의 전체 구조를 매핑하기 위해 첫 번째 에이전트를 배치했습니다:

# 에이전트 작업: 코드베이스 아키텍처 매핑
hermes agent --task "Analyze the devtoolbox codebase. Map every module, 
its dependencies, public APIs, and identify architectural patterns. 
...

에이전트는 45분 만에 포괄적인 지도를 생성했습니다:

devtoolbox/
├── src/
│   ├── cli/           # Click 기반 CLI 엔트리 포인트 (entry points)
...

이슈 분류 (The Issue Triage)

다음으로, 에이전트에게 23개의 모든 열린 이슈 (open issues)를 분류하도록 시켰습니다:

issue_categories = {
    "bugs": [12, 15, 18, 21, 23, 25, 27],        # 버그 7개
    "features": [8, 11, 14, 19, 22, 24, 26, 28],  # 기능 요청 8개
...

근본 원인 분석 (The Root Cause Analysis)

에이전트는 프로젝트를 죽게 만든 세 가지 치명적인 문제를 발견했습니다:

  1. Python 3.8 의존성 — CI (지속적 통합)가 Python 3.8 (2024년 10월 EOL)로 고정되어 있었습니다. 여러 기능이 match/case 문 (Python 3.10 이상)을 사용하고 있었지만, CI 자체가 고장 나 있었기 때문에 이를 잡아내지 못했습니다.

  2. core/analyzers 내의 순환 참조 (Circular import) — complexity.py가 metrics.py를 임포트(import)하고, metrics.py가 다시 complexity.py를 임포트하고 있었습니다. 이로 인해 새로 설치할 때마다 충돌이 발생했습니다.

  3. templates/ 내 __init__.py 누락 — Python이 템플릿 파일을 패키지 (package)로 찾을 수 없었기 때문에 스캐폴드 (scaffold) 명령이 소리 없이 실패했습니다.

# 모든 것을 망가뜨린 순환 참조
# src/core/analyzers/complexity.py
from ..metrics import calculate_complexity  # ← 이것이 metrics.py를 트리거함
...

3단계: 수술 — AI 에이전트를 이용한 수정 (18~48시간 차)

이 단계에서 본격적인 작업이 이루어졌습니다. 저는 각각 특정한 임무를 가진 여러 에이전트를 병렬로 배치했습니다.

에이전트 1: 버그 헌터 (The Bug Hunter)

임무: 7개의 버그 이슈를 모두 해결할 것.

에이전트는 체계적으로 작업을 수행했습니다:

# Fix #12: 순환 참조 (Circular import) 해결
# 수정 전 (오류 발생):
# src/core/analyzers/complexity.py
...

# Fix #15: Windows 경로 처리
# 수정 전 (오류 발생):
template_dir = Path(__file__).parent / "templates"
...

에이전트는 8개월 동안 방치되어 있던 까다로운 Windows 경로 문제를 포함하여, 6시간 만에 7개의 버그를 모두 해결했습니다.

에이전트 2: 인프라 엔지니어 (The Infrastructure Engineer)

임무: CI/CD를 수정하고 프로젝트를 현대화할 것.

# 수정 전: .github/workflows/test.yml (오류 발생)
name: Tests
on: [push]
...

또한 에이전트는 다음 작업들을 수행했습니다:

  • setup.py를 pyproject.toml로 업데이트 (패키징 현대화)
  • 린팅(Linting) 및 포매팅(Formatting)을 위한 pre-commit 훅(hooks) 추가
  • 개발 환경 설정 안내가 포함된 CONTRIBUTING.md 생성
  • 자동 의존성 업데이트를 위한 dependabot.yml 설정

에이전트 3: 기능 빌더 (The Feature Builder)

임무: 요청된 8개의 기능을 구현할 것.

가장 요청이 많았던 기능(#22, 추천 47개)은 JSON 출력 지원이었습니다. 에이전트는 이를 깔끔하게 구현했습니다:

# src/cli/utils.py — 출력 포매팅 추가
import json
from typing import Any, Optional
...

구현된 기타 기능들:

  • 의존성 취약점 스캐닝 (Dependency vulnerability scanning) (#8) — pip-audit와 통합
  • 프로젝트 템플릿 커스터마이징 (Project template customization) (#11) — 스캐폴드(Scaffold) 내 Jinja2 변수 사용
  • 코드 중복 탐지 (Code duplication detection) (#14) — jscpd 통합 사용
  • Git 히스토리 분석 (Git history analysis) (#19) — 커밋 빈도, 기여자 통계
  • 다국어 지원 (Multi-language support) (#22) — Go, Rust, Java를 위한 파서(Parser) 확장
  • 플러그인 시스템 (Plugin system) (#24) — entry_points 기반의 플러그인 아키텍처
  • 워치 모드 (Watch mode) (#26) — 자동 재빌드를 위한 watchdog 통합

에이전트 4: 문서 작성가 (The Documentation Writer)

임무: 포괄적인 문서를 작성할 것.

에이전트가 생성한 결과물:

  • API 레퍼런스 (API Reference) (docstrings에서 자동 생성됨)
  • 사용자 가이드 (User Guide) (예시를 포함한 12페이지 분량)
  • 변경 이력 (Changelog) (git 히스토리 및 이슈 해결 내역 기반)
  • 마이그레이션 가이드 (Migration Guide) (v0.x에서 v1.0으로의 전환)
## Quick Start

### Installation
...

bash
pip install devtoolbox


### 프로젝트 의존성 분석하기 (Analyze Your Project Dependencies)

bash

텍스트 출력 (기본값)

devtoolbox deps analyze

스크립트용 JSON 출력

devtoolbox deps analyze --format json

파일로 저장

devtoolbox deps analyze --format json --output report.json


### 새 프로젝트 생성하기 (Generate a New Project)

bash

대화형 모드 (Interactive mode)

devtoolbox scaffold new my-project

템플릿 사용

devtoolbox scaffold new my-project --template fastapi

사용자 정의 변수 사용

devtoolbox scaffold new my-project --template fastapi \
--var author="Your Name" \
--var license=MIT

console

4단계: 테스트 및 검증 (48~60시간 차)

모든 수정 사항과 기능이 적용되었으므로, 이제 아무것도 고장 나지 않았는지 확인할 차례였습니다.

테스트 스위트 (The Test Suite)

수정 전 상태: 테스트 통과율 67% (51개 테스트 중 34개 통과)

모든 수정 후 상태: 테스트 통과율 100% (51개 테스트 전체 통과 + 23개의 신규 테스트 추가)

$ pytest --cov=src --cov-report=term-missing
========================= test session starts ==========================
platform linux -- Python 3.12.1, pytest-8.3.4, pluggy-1.5.0
...

크로스 플랫폼 검증 (The Cross-Platform Validation)

# Ubuntu (CI)
✅ All tests passed
✅ Installation successful
...

5단계: 출시 및 배포 (60~72시간 차)

출시 (The Release)

변경 이력(changelog)을 포함한 정식 릴리스를 생성했습니다:

# 출시 브랜치 생성
git checkout -b release/v1.0.0

...

공지 (The Announcement)

포괄적인 출시 공지문을 작성하여 다음 채널들에 게시했습니다:

  • GitHub Discussions (해당 리포지토리 내)
  • Dev.to (이 글!)
  • Reddit r/Python 및 r/opensource
  • Hacker News (Show HN)

결과: 전 vs 후

정량적 지표 (Quantitative Metrics)

지표 (Metric)이전 (2025년 3월)이후 (2026년 6월)변화량
오픈 이슈 (Open Issues)230-100%
...

정성적 성과 (Qualitative Wins)

  1. 커뮤니티 부활 (Community Revival) — 릴리스 후 48시간 이내에 3명의 새로운 기여자(Contributor)가 PR(Pull Request)을 제출함
  2. 이슈 해결 (Issue Resolution) — 23개의 모든 이슈가 해결되었으며, 그중 일부는 14개월 동안 열려 있던 것들이었음
  3. 현대적 스택 (Modern Stack) — 중단된 Python 3.8에서 현대적인 3.10+ 버전으로 업데이트됨
  4. 실질적인 문서화 (Real Documentation) — 이제 사용자들이 실제로 도구를 _사용_할 수 있음
  5. 자동화된 유지보수 (Automated Maintenance) — Dependabot과 pre-commit을 통해 향후 코드 노후화를 방지함

배운 점: AI 지원 부활에 대한 냉혹한 진실

훌륭하게 작동했던 부분

1. 병렬 에이전트 배포 (Parallel Agent Deployment)

4개의 에이전트(버그, 인프라, 기능, 문서)를 동시에 실행한 것은 게임 체인저(Game-changer)였습니다. 각 에이전트는 격리된 컨텍스트(Context)와 명확한 경계를 가졌습니다. 병합 충돌(Merge conflict)도 없었고, 서로의 영역을 침범하는 일도 없었습니다.

2. 코드베이스 이해 (Codebase Comprehension)

아키텍처 매핑(Architecture mapping) 에이전트는 45분 만에 전체 코드베이스를 이해했습니다. 인간 개발자라면 동일한 수준의 이해에 도달하기 위해 2~3일이 걸렸을 것입니다.

3. 체계적인 이슈 분류 (Systematic Issue Triage)

에이전트는 23개의 이슈를 완벽하게 분류하고 우선순위를 정했습니다. 에이전트는 여러 보고된 버그의 근본 원인이 순환 참조 임포트(Circular import)임을 식별해냈는데, 이는 인간 보고자들이 놓쳤던 부분이었습니다.

예상보다 어려웠던 부분

1. 엣지 케이스 테스트 (Testing Edge Cases)

AI 에이전트는 해피 패스(Happy path) 테스트를 작성하는 데는 뛰어나지만, 엣지 케이스(Edge cases)에는 어려움을 겪습니다. 저는 다음과 같은 항목에 대해 수동으로 테스트를 추가해야 했습니다:

  • 파일 경로 내 유니코드 (Windows)
  • 심볼릭 링크(Symlink) 처리 (macOS)
  • 워치 모드(Watch mode)에서의 레이스 컨디션(Race conditions)

2. 원래의 비전 보존 (Preserving the Original Vision)

원래 작성자는 특정 설계 철학(최소한의 의존성

예시 1: 플러그인 시스템 (The Plugin System)

가장 복잡한 기능 추가 사항 — Python의 entry_points를 사용하는 플러그인 시스템:

# src/core/plugins.py — 플러그인 검색 및 로딩
import importlib.metadata
from typing import Dict, Type, List
...

예시 2: 의존성 취약점 스캐너 (The Dependency Vulnerability Scanner)

# src/core/analyzers/vulnerabilities.py
import subprocess
import json
from typing import List, Dict, Optional
from dataclasses import dataclass

@dataclass
class Vulnerability:
    name: str
    version: str
    vuln_id: str
    description: str
    severity: str
    fixed_version: Optional[str]

class VulnerabilityScanner:
    """pip-audit를 사용하여 알려진 취약점에 대해 의존성을 스캔합니다."""

    def scan(self, requirements_file: str = "requirements.txt") -> List[Vulnerability]:
        """requirements 파일을 스캔하여 취약점을 찾습니다."""
        try:
            result = subprocess.run(
                ["pip-audit", "-r", requirements_file, "--format", "json", "--desc"],
                capture_output=True,
                text=True,
                check=True
            )
            return self._parse_results(json.loads(result.stdout))
        except subprocess.CalledProcessError as e:
            if e.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0