죽은 저장소로 가득한 폴더를 가지고 있었습니다. 그래서 공동묘지를 만들었고, 그것들을 되살릴 방법도 만들었습니다.
요약
방치된 GitHub 저장소를 시각화하고 다시 개발을 시작할 수 있도록 돕는 웹 애플리케이션 'Lazarus'를 소개합니다. 사용자의 GitHub 사용자 이름만으로 죽은 프로젝트를 분석하여 묘비 형태로 보여주고, 프로젝트 부활을 위한 단계별 계획과 AI 프롬프트를 제공합니다.
핵심 포인트
- GitHub의 미완성 프로젝트를 시각적인 '공동묘지' 형태로 렌더링
- 프로젝트 방치 원인 분석 및 요약 카드 제공
- 프로젝트 재개를 위한 맞춤형 체크리스트 및 부활 계획 생성
- GitHub Copilot 활용을 위한 전용 프롬프트 및 지침 제공
이 글은 GitHub Finish-Up-A-Thon Challenge를 위한 제출물입니다.
지금 바로 체험해 보세요 — 로그인 불필요: https://chintanonweb.github.io/lazarus/ · 코드: https://github.com/chintanonweb/lazarus
💡 쉽게 설명하자면: Lazarus는 당신이 GitHub에 방치해 둔 사이드 프로젝트(side-projects)들을 탐험하고 공유할 수 있는 작은 공동묘지로 바꿔줍니다. 그런 다음, 그중 하나를 다시 되살리기 위한 단계별 계획(그리고 바로 복사해서 사용할 수 있는 AI 프롬프트)을 제공합니다. 로그인도, 설정도 필요 없습니다. 그저 GitHub 사용자 이름만 입력하세요.
우리 모두에게는 그런 폴더가 있습니다. 좋은 아이디어들이 죽으러 가는 GitHub의 그 폴더 말이죠. todo-app-v3. the-startup. learn-rust-for-real (해설: 그들은 Rust를 배우지 못했습니다).
저에게도 그런 폴더가 있습니다. 그리고 제 폴더에서 가장 시적인 거주자는 **graveyard.js**라는 파일이었습니다. —
새벽 2시에 제가 죽은 저장소(repos)들을 목록화하기 위해 급하게 짜낸 약 40줄짜리 스크립트였죠. 그것은 RIP 문구들을 벽처럼 출력했고, 시간이 흐를수록 빛을 바랜(aged like milk) 다음과 같은 주석으로 끝을 맺었습니다.
// TODO: 묘비명? UI? 안 못생긴 것 좀? ...나중에 완성하자
저는 그것을 완성하지 못했습니다. 하지만 Finish-Up-A-Thon을 위해, 마침내 완성했습니다. 다른 모든 프로젝트를 완성하도록 도와주는 것이 유일한 임무인 바로 그 프로젝트를 말이죠.
그것의 이름은 Lazarus입니다.
내가 만든 것
Lazarus는 당신의 죽은 GitHub 저장소들을 되살려주는 로그인 불필요 웹 앱입니다. 사용자 이름을 입력하면 다음과 같은 기능을 수행합니다:
🪦 당신의 공동묘지를 발굴합니다 — 모든 저장소에 대해 방치 정도(마지막으로 만진 지 얼마나 되었는지, 얼마나 미완성 상태인지, 열려 있는 이슈(issues)가 몇 개인지)를 점수화하고, 죽은 저장소들을 차가운 달빛 아래 기울어진 각인이 새겨진 묘비로 렌더링합니다.
✍️ 묘비명을 작성합니다 — 모든 무덤에는 사망 원인(범위 확장(scope creep), 흥미 상실, "더 멋진 아이디어가 나타남", 솔직한 // TODO)과 한 줄의 시가 부여됩니다.
_"모든 것을 하려 했으나, 아무것도 하지 못했다."
📊 요약 (Wraps it up) — 다운로드하여 공유할 수 있는 '방치된 프로젝트 요약 (Abandoned Projects Wrapped)' 카드(Spotify Wrapped와 비슷하지만, 여러분의 공동묘지를 위한 것입니다)를 제공합니다: 묻혀버린 저장소(repos), 실제로 완료한 비율(%), 가장 길었던 방치 기간(cold streak), 주요 사망 원인 등을 보여줍니다.
⚡ 죽은 자를 살림 (Raises the dead) — 무덤 하나를 선택하면 Lazarus가 **부활 계획 (revival plan)**을 생성합니다: 무엇이 누락되었는지에 대한 사후 분석 (README, 테스트, CI, 라이선스), 우선순위가 지정된 체크리스트, 해당 저장소에 맞춤화된 다운로드 가능한 copilot-instructions.md, 그리고 여러분이 포기했던 바로 그 지점에서 작업을 이어갈 수 있는 **복사-붙여넣기용 GitHub Copilot 프롬프트 (prompts)**를 제공합니다.
로그인도, 백엔드도 필요 없습니다. 어떤 데이터도 브라우저를 벗어나지 않습니다.
사용 방법 (3단계)
- 사이트를 열고 아무 GitHub 사용자 이름이나 입력하세요 — 자신의 이름을 입력하거나
재기 스토리 (The Comeback Story)
여기 실제 비포(Before)와 애프터(After)가 있습니다. 그리고 네, Git 히스토리가 이를 증명합니다.
Before — 새벽 2시에 급하게 만든 graveyard.js. 파일 하나, console.log뿐이며, UI도 없고, 결코 돌아오지 않을 // TODO 주석만 남았습니다:
After — Lazarus: 영화 같은 공동묘지, 묘비명(epitaphs), 공유 가능한 Wrapped, 그리고 Copilot 기반의 부활 계획.
Before (graveyard.js) | After (Lazarus) | |
|---|---|---|
| 코드 (Code) | 약 22줄, 1개 파일 | 약 1,700줄, 24개 파일 |
| ... |
가장 어려웠던 부분은 묘비가 아니었습니다. 바로 점수 엔진 (scoring engine) 이었습니다. "이 저장소는 죽은 것 같다"라는 느낌을 정직한 데이터로 바꾸는 작업이었죠. 마지막 푸시(push) 이후 경과된 일수, 누락된 README/라이선스/토픽(topics), 방치된 오픈 이슈(open issues), 그리고 결정적인 마지막 커밋 메시지(wip, fix later, giving up for tonight) 등이 포함됩니다.
저는 이 로직을 결정론적 (deterministic) 으로 유지했습니다. 즉, 동일한 저장소는 새로고침할 때마다 무작위로 변하지 않고 항상 동일한 묘비명을 받게 됩니다. 이를 위해 독립적으로 테스트할 수 있는 작고 자기 완결적인 함수들로 로직을 작성했습니다.
또한 메타적인 작업도 수행했습니다. 저장소 자체를 완성된 상태로 만들었습니다. README, MIT 라이선스, 그리고 푸시할 때마다 자동으로 테스트를 실행하는 파이프라인(pipeline)을 구축했습니다. 사용자에게 README를 추가하라고 잔소리하는 도구 자체가 README를 갖게 된 것입니다.
GitHub Copilot 사용 경험
Copilot이 Lazarus를 작성한 것은 아닙니다. Copilot은 제가 막힌 부분(unstuck) 을 뚫어주었습니다. 버려진 프로젝트에게는 그것이 가장 중요한 핵심입니다. 세 가지 구체적인 순간은 다음과 같습니다:
1. 제 자신의 죽은 코드를 역공학 (reverse-engineered) 했습니다. 제가 가장 먼저 한 일은 Copilot Chat을 graveyard.js로 지정하고, _"여기서 내가 무엇을 만들려고 했고, 무엇이 절반만 완성된 상태인가요?"_라고 물어보는 것이었습니다. Copilot은 // TODO를 읽고 과거의 제가 포기했던 네 가지 사항을 정확하게 나열했습니다. 그것이 실제 로드맵이 되었습니다. 그리고 적절하게도, "코드를 다시 읽고 내가 어디서 멈췄는지 알려달라"는 동일한 프롬프트는 이제 Lazarus가 모든 부활을 위해 생성하는 첫 번째 프롬프트가 되었습니다. 이 기능은 그 기능을 만든 워크플로우(workflow) 그 자체입니다.
2. copilot-instructions.md를 먼저 작성했더니 품질이 급상승했습니다. 이것은 Copilot에게 프로젝트의 규칙을 알려주는 작은 파일입니다. 저는 저의 규칙들 — 두 가지 폰트, 색상 팔레트, "로직을 UI와 분리할 것" — 을 제공했습니다. 그러자 제안들이 제 아키텍처 (architecture)와 싸우는 대신 그것에 맞춰지기 시작했습니다. 그래서 저는 이 교훈을 제품에 녹여냈습니다: Lazarus는 당신이 부활시키려는 어떤 저장소(repo)에 대해서도 맞춤형 copilot-instructions.md를 생성합니다.
3. 솔직한 실패. 저는 Copilot에게 묘비명 생성기를 작성해달라고 요청했는데, Copilot은 Math.random()을 사용했습니다. 그래서 페이지를 새로고침할 때마다 모든 묘비명이 무작위로 섞였습니다. 귀엽긴 하지만 쓸모는 없었죠. 저는 다시 요구했습니다: 묘비명은 _안정적(stable)_이어야 한다고 말이죠. 우리는 각 저장소의 ID를 고정되고 반복 가능한 "무작위" 선택으로 변환하는 작은 수학적 트릭을 찾아냈습니다 (무작위처럼 보이지만 절대 변하지 않습니다). Copilot은 손이 빠르지만, 무엇이 "정확한" 것인지 결정하는 것을 대신해 줄 수는 없습니다. 제가 제약 사항을 말한 순간, Copilot은 코드와 테스트를 모두 완벽하게 해냈습니다.
결론: Copilot은 사이드 프로젝트를 죽게 만드는 바로 그 기분인 "으악, 이게 어떻게 돌아가는지도 기억 안 나"를 추진력으로 바꾸어 놓았습니다. 그래서 저는 그 기분을 버튼 하나로 출시했습니다.
🔬 내부 동작 원리 (궁금한 분들을 위해 — 그냥 플레이만 하고 싶다면 건너뛰세요)
흐름 (The flow):
사용자 이름 입력 → GitHub REST API에서 해당 사용자의 저장소(repos) 가져오기 → 각 저장소 점수 매기기 → 공동묘지(graveyard) 렌더링 → 클릭 시 해당 저장소의 상태 신호(health signals) 가져오기 → 부활 계획 수립
디자인 선택 (Design choices):
- 점수 산정 (scoring) / 비문 (epitaph) / 래핑 (wrapped) / 부활 (revival) 로직은 순수 함수 (pure functions) 입니다. 내부에서 UI나 네트워크 호출을 수행하지 않으므로 단위 테스트 (unit-test)를 수행하기가 매우 쉽습니다. 25개의 Vitest 테스트가 이를 커버합니다.
- "안정적인 랜덤 (stable random)" 비문은 저장소 ID를 시드 (seed)로 사용하여 mulberry32 의사 난수 생성기 (PRNG)에 FNV-1a 해시 (hash) 값을 입력합니다. 설계 단계부터 결정론적 (deterministic)으로 작동합니다.
- 100% 클라이언트 사이드 (client-side) 방식입니다: React + Vite + TypeScript + Tailwind + framer-motion을 사용합니다. 백엔드, 데이터베이스, API 키가 필요 없습니다. 인증되지 않은 요청은 GitHub의 공개 API를 사용하며, 선택 사항인 읽기 전용 토큰 (read-only token)을 사용하면 비공개 저장소 (private repos) 접근 및 더 높은 속도 제한 (rate limits)을 사용할 수 있습니다. 이 토큰은 브라우저를 절대 벗어나지 않습니다.
- GitHub Pages를 통해 배포되었으며, GitHub Actions가 모든 푸시 (push) 시 테스트와 빌드를 실행합니다.
당신의 GitHub에는 무엇이 썩어가고 있나요?
직접 확인해 보세요 — 사용자 이름 하나만 있으면 되며 로그인은 필요 없습니다: https://chintanonweb.github.io/lazarus/
그다음 댓글로 당신의 가장 최악인 무덤을 알려주세요. 저의 무덤은 6년 된 블로그인데, 포스트가 세 개뿐이고 지금의 제가 아닌 과거의 제가 남긴 // TODO가 하나 있습니다. 🪦
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기