8개월 묵혀둔 '애증의 프로젝트', GitHub Copilot 덕분에 드디어 완성했습니다!

안녕하세요, 10년 차 IT 실무자이자 기술 블로거입니다. 오늘은 제가 8개월 동안이나 방치했던 한 사이드 프로젝트, 'BugWhisperer'를 GitHub Copilot 덕분에 마침내 완성하게 된 이야기를 풀어보려고 합니다. 아마 실무에서 쌓아둔 아이디어를 코드로 옮기려다 벽에 부딪혀 프로젝트를 묵혀둔 경험, 한 번쯤은 있으실 겁니다. 이 글이 그런 분들에게 작은 동기 부여가 되길 바랍니다.

프로젝트 공개

GitHub 레포: https://github.com/SimranShaikh20/BugWhisperer 라이브 데모: https://bugwhisperer.msusimran20.workers.dev

2025년 9월, 제가 포기했던 그 프로젝트

8개월 전, 우리 개발팀은 심각한 문제에 직면했습니다. 3개의 레포지토리에 걸쳐 60개가 넘는 GitHub 이슈가 쌓여 있었지만, 뭘 먼저 고쳐야 할지 아무도 몰랐죠. 스프린트 플래닝 회의는 늘 45분간의 우선순위 논쟁으로 변질되기 일쑤였습니다. 저는 문득 이런 생각을 했습니다. '스크립트가 모든 이슈를 읽고 가장 중요한 것을 알려준다면 얼마나 좋을까?'

그래서 당장 코드를 짜기 시작했습니다. 그날의 코드는 이게 전부였습니다.

import requests
import os

# TODO: fix this later
GITHUB_TOKEN = "put_your_token_here"

def get_issues(repo):
    # this doesnt work properly
    url = f"https://api.github.com/repos/{repo}/issues"
    r = requests.get(url)
    print(r)  # just printing for now
    # TODO: parse response properly

def analyze_issue(issue):
    # wanted to use openai here but ran out of time
    pass

def main():
    repo = "facebook/react"  # hardcoded lol
    get_issues(repo)
    # analyze_issue() # commented out, broken
    print("done?")

main()

네, 이게 전부였습니다. 원본 응답 객체를 출력하는 print(r)과, 말 그대로 아무것도 하지 않는 analyze_issue 함수, 그리고 하드코딩된 레포 URL까지. 처참하기 그지없었죠.

2025년 9월 15일, 제 커밋 메시지는 다음과 같았습니다.

"initial attempt - giving up for now, too complicated" (첫 시도 - 너무 복잡해서 일단 포기)

그렇게 이 레포는 8개월 동안 아무도 건드리지 않은 채 방치되었습니다. 아마 실무에서 이런 상황을 겪어본 분이라면 당시의 제 좌절감을 충분히 이해하실 겁니다.

버려진 프로젝트의 흔적

마침내 다시 돌아온 이유

GitHub Finish-Up-A-Thon 챌린지 공고를 보자마자, 이 프로젝트가 가장 먼저 떠올랐습니다. 아이디어 자체는 항상 훌륭하다고 생각했거든요. 해결하고자 했던 문제도 실존하는 문제였고요. 단지 그때는 어려운 부분을 돌파할 적절한 도구도, 충분한 시간도 없었을 뿐이었습니다.

하지만 이번에는 달랐습니다. 제게는 GitHub Copilot이 있었거든요. 오랜만에 다시 코드를 열어봤을 때, 당시의 좌절감이 다시 밀려오는 듯했지만, 새로운 도구가 주어지자 해낼 수 있을 거라는 자신감이 생겼습니다.

완성된 'BugWhisperer'는?

이제 BugWhisperer는 AI 기반의 완벽한 GitHub 이슈 커맨드 센터로 거듭났습니다.

어떤 GitHub 레포 URL이든 붙여넣으세요 → 단 몇 초 만에 모든 오픈 이슈에 대한 AI 분류(Triage) 결과를 받아볼 수 있습니다.

지금은 다음과 같은 기능들을 제공합니다.

모든 이슈에 대한 AI 분석

각 오픈 이슈는 Groq의 Llama 3.1 AI에 의해 분석되어 다음 정보를 제공합니다.

근본 원인(Root Cause) — 이 이슈의 원인이 무엇일지 추정
제안된 해결책(Suggested Fix) — 명확하고 실행 가능한 해결책을 평이한 영어로 제시
복잡도(Complexity) — 낮음(Low) / 중간(Medium) / 높음(High)
우선순위(Priority) — 낮음(Low) / 중간(Medium) / 높음(High) / 긴급(Critical)

칸반 우선순위 보드

지루한 목록 대신, 이슈들을 4개의 컬럼으로 시각화된 보드에 분류합니다.

🔴 긴급(Critical) — 즉시 해결
🟠 높음(High) — 이번 스프린트
🟡 중간(Medium) — 다음 스프린트
🟢 낮음(Low) — 백로그

AI 스프린트 플래너

클릭 한 번으로 2주간의 완벽한 스프린트 계획을 생성합니다. 예상 소요 시간, 권장 팀 규모, 주별 업무 분배까지 상세하게 제시됩니다.

마크다운으로 내보내기

전체 분석 결과를 .md 파일로 다운로드할 수 있습니다. GitHub Wiki, Notion, Linear 등 어디든 즉시 붙여넣어 활용 가능합니다.

분석 결과를 GitHub에 게시

AI 분석 결과를 GitHub 이슈에 포맷된 댓글로 바로 게시할 수 있습니다. 복사-붙여넣기나 앱을 떠날 필요 없이 간편하게 처리됩니다.

GitHub Copilot이 이 모든 것을 가능하게 한 방법

이것은 Copilot이 실제로 어떻게 저를 도왔는지에 대한 솔직한 이야기입니다. 단순히 "놀라웠어요!" 같은 모호한 표현이 아니라, 제가 막혔던 특정 순간들을 정확히 짚어보겠습니다.

순간 1: 제 망가진 코드 이해하기

오래된 main.py 파일을 VS Code에서 Copilot과 함께 열고 다음과 같이 질문했습니다.

"What is this code trying to do and what is broken?" (이 코드는 뭘 하려 했고, 뭐가 문제야?)

Copilot은 즉시 제게 알려주었습니다.

GitHub API 호출에 인증 헤더가 없음 (8개월 전에 제가 겪었던 조용한 실패의 원인)
응답이 제대로 파싱되지 않음 — print(r)은 데이터가 아닌 응답 객체 자체를 출력함
analyze_issue 함수는 완전히 비어 있음

그러고는 적절한 인증, 페이지네이션, 오류 처리까지 포함된 완벽하게 수정된 GitHub API 호출 코드를 제안해주었습니다. 제가 8개월 전에 일주일 내내 머리를 싸매도 해결 못 했던 문제를 코파일럿은 단 2분 만에 짚어주고 해결책까지 제시해 주더군요. 정말 허탈하면서도 감탄스러웠습니다.

순간 2: LLM에서 신뢰할 수 있는 JSON 얻기

가장 어려웠던 기술적 문제는 AI 모델에서 구조화된 JSON 출력을 안정적으로 얻어내는 것이었습니다. 시도할 때마다 모델은 JSON 주위에 마크다운 펜스를 추가하거나, 설명 텍스트를 덧붙이거나, 심지어는 포맷을 완전히 깨뜨리곤 했습니다.

저는 Copilot에게 이 문제를 설명했고, Copilot은 이 문제를 완벽하게 해결해 줄 시스템 프롬프트 패턴을 작성해주었습니다.

You are a senior software engineer analyzing GitHub issues.
Respond ONLY in valid JSON format.
No other text. No markdown. No explanation. Just JSON.

{
  "root_cause": "...",
  "suggested_fix": "...",
  "complexity": "Low or Medium or High",
  "priority": "Low or Medium or High or Critical"
}

Copilot이 알려준 핵심은 "No other text. No markdown. No explanation." 이라는 지시가 단순히 "respond in JSON format."이라고 말하는 것보다 훨씬 더 안정적이라는 것이었습니다. 제가 실무에서 LLM을 활용한 프로젝트를 진행하면서 가장 많이 씨름했던 부분이 바로 이 '안정적인 JSON 파싱'이었습니다. 이 한 가지 통찰 덕분에 저는 아마 3시간 정도의 프롬프트 디버깅 시간을 절약할 수 있었습니다. 그야말로 황금률이었죠.

순간 3: 칸반 보드 컴포넌트

저는 칸반 보드를 한 번도 만들어본 적이 없었습니다. Copilot에게 이렇게 물었습니다.

"Write a React component that takes an array of issues each with a priority field and displays them in 4 columns: Critical, High, Medium, Low" (우선순위 필드를 가진 이슈 배열을 받아서 Critical, High, Medium, Low 네 가지 컬럼으로 표시하는 React 컴포넌트를 작성해줘)

Copilot은 한 번의 응답으로 완전히 작동하는 컴포넌트 전체를 작성해주었습니다. 저는 그저 제 데이터를 연결하기만 하면 되었습니다.

순간 4: 스프린트 플래너 프롬프트

분석된 모든 이슈를 바탕으로 2주간의 스프린트 계획을 생성하고 싶다고 설명했습니다. Copilot은 완전한 AI 프롬프트, API 호출, JSON 파싱 코드를 작성해 주었고, 심지어 제가 생각지도 못했던 team_size_recommended 필드를 추가할 것을 제안했습니다. 이 하나의 제안이 기능을 훨씬 더 유용하게 만들어주었습니다.

기술 아키텍처

사용자 입력 (GitHub URL)
        ↓
Cloudflare Worker
        ↓
GitHub REST API → 오픈 이슈 가져오기 (인증됨)
        ↓
Groq API (Llama 3.1 8b instant) → 각 이슈 분석
        ↓
반환: root_cause, suggested_fix, complexity, priority
        ↓
React 프론트엔드 → 칸반 보드
        ↓
선택 사항: 스프린트 플래너 (두 번째 Groq 호출)
선택 사항: 마크다운 보고서 내보내기
선택 사항: GitHub에 댓글로 게시

기술 스택

레이어	기술 스택
프론트엔드	React + TanStack + Tailwind CSS
백엔드	Cloudflare Workers (서버리스)
AI	Groq API — llama-3.1-8b-instant
GitHub	GitHub REST API v3
호스팅	Cloudflare Workers (무료 티어)

왜 Groq를 사용하고 OpenAI를 사용하지 않았을까요?

속도와 비용 때문입니다. Groq의 추론 속도는 정말 놀랍도록 빠릅니다. 이슈 10개를 분석하는 데 총 8초 정도밖에 걸리지 않죠. 무료 티어는 하루 14,400회 요청을 제공하는데, 이는 충분하고도 남는 양입니다. OpenAI는 비용이 발생하지만, Groq는 무료입니다. 모든 개발자가 접근할 수 있는 개발자 도구라면, 무료가 최고죠!

왜 Cloudflare Workers를 사용했을까요?

Lovable은 Cloudflare Workers에 맞게 구성된 TanStack 프로젝트를 기본으로 생성합니다. 전 세계적인 엣지 배포 덕분에 앱이 어디서든 빠르게 로드됩니다. 게다가 무료 티어로 하루 100,000회 요청을 처리할 수 있으니, 이 역시 충분했습니다.

전과 후 요약

구분	2025년 9월	2026년 6월
코드	47줄의 망가진 Python	완벽한 React + Cloudflare 앱
UI	터미널 전용	아름다운 다크 웹 인터페이스
AI	`pass` — 말 그대로 비어있음	Groq Llama 3.1 분석
GitHub	하드코딩된 `facebook/react`	모든 공개 레포 URL
분석	없음	근본 원인, 해결책, 복잡도, 우선순위
계획	없음	AI 2주 스프린트 플래너
내보내기	없음	원클릭 마크다운 보고서
배포	한 번도 성공적으로 실행된 적 없음	workers.dev에서 라이브 운영 중
비용	0달러 (아무것도 안 함)	0달러 (모든 API 무료)

제가 배운 것들

1. GitHub Copilot은 지식 격차를 메우는 데 최고입니다.

저는 칸반 보드를 만드는 방법을 몰랐습니다. LLM에서 구조화된 JSON을 강제하기 위한 최적의 프롬프트 패턴도 몰랐죠. Cloudflare Workers가 Node.js와 다르게 환경 변수를 읽는 방식도 몰랐습니다. Copilot은 제가 막혔던 이 모든 지식 격차를 즉시 메워주었습니다. 앱 전체를 대신 작성해준 것이 아니라, 제가 막다른 길에 부딪혔을 때, 마치 경험 많은 시니어 개발자가 옆에서 힌트를 주는 것처럼 정확한 방향을 제시해 주었죠.

2. 오래된 아이디어는 종종 좋은 아이디어입니다.

2025년 9월에 제가 작성했던 스크립트는 올바른 아이디어를 담고 있었습니다. 문제는 실존했고, 해결책의 방향도 맞았습니다. 단지 시간, 더 나은 도구, 그리고 어려운 부분을 밀어붙일 동기가 필요했을 뿐입니다. 여러분의 오래된 프로젝트들을 지우지 마세요. 종종 그 문제에 가장 가까이 있었던 시기의 최고의 생각이 담겨 있을 수 있습니다.

3. 제약은 더 나은 설계를 강요합니다.

오직 무료 API만 사용하겠다는 제약은 저에게 효율성을 강요했습니다. 분석당 300토큰으로 제한하고 가장 빠른 모델을 사용함으로써 앱은 즉각적인 반응 속도를 보여줄 수 있었죠. 만약 예산이 무제한이었다면, 아마 더 느리고 더 비싼 것을 만들었을지도 모릅니다.

4. 계획보다 완성이 중요합니다.

BugWhisperer v2는 2025년 9월에 제가 Python 스크립트를 작성했을 때 상상했던 것과는 전혀 다릅니다. CLI 스크립트가 아니라 웹 앱이 되었고, OpenAI가 아닌 Groq를 사용하며, 제 노트북이 아닌 Cloudflare에서 실행됩니다. 모든 구현 세부 사항이 바뀌었지만, 핵심 아이디어 — 개발자들이 GitHub 이슈를 더 빠르게 이해하도록 돕는 것 — 는 정확히 그대로 유지되었습니다. 계획이 아니라 아이디어를 완성하는 데 집중해야 합니다.

지금 바로 경험해보세요!

👉 라이브 데모: https://bugwhisperer.msusimran20.workers.dev

아래 레포지토리 중 아무거나 테스트해보세요.

https://github.com/fastapi/fastapi
https://github.com/requests/requests
https://github.com/psf/black
또는 여러분이 작업 중인 어떤 공개 GitHub 레포지토리라도 좋습니다!

GitHub 레포: https://github.com/SimranShaikh20/BugWhisperer

다음 계획

프라이빗 레포 지원 (사용자가 직접 토큰 제공)
GitHub Actions 연동 — 새 이슈 생성 시 자동 분석
'긴급' 우선순위 이슈에 대한 Slack 알림
VS Code 확장 프로그램
다중 레포 비교 기능

이 프로젝트 이야기가 여러분의 묵혀둔 사이드 프로젝트에 대한 생각을 바꾸는 데 도움이 되었다면, 반응을 남겨주세요. 여러분의 반응은 이 글과 제게 큰 동기 부여가 됩니다.

그리고 어딘가에 미완성 프로젝트가 있다면, 이 챌린지가 바로 그것을 드디어 완성할 때라는 신호입니다. 여러분이 포기했던 그 아이디어는 아마 여러분이 기억하는 것보다 훨씬 더 좋을 겁니다. 🚀

GitHub Finish-Up-A-Thon Challenge를 위해 개발되었습니다.
Groq AI + GitHub Copilot + Cloudflare Workers 기반.

원문: https://dev.to/simranshaikh20_50/bugwhisperer-how-i-finally-finished-my-abandoned-github-issue-analyzer-8-months-later-with-4ll8 수집일: 2026-05-30 01:51:58