GitReverse 소개
코딩 에이전트로 무언가를 만들어 보려고 할 때 가장 막히는 지점은 첫 프롬프트입니다. 만들고 싶은 결과물과 비슷한 프로젝트가 GitHub에 이미 있어도, 그 저장소를 읽어서 "이걸 만들어 달라"는 한 문단으로 압축하는 일은 별개의 작업입니다. 저장소를 그대로 붙여 넣으면 컨텍스트 창(Context Window)을 낭비하고, 요약하면 무엇을 남기고 무엇을 버릴지 매번 다시 판단해야 합니다.
이번에 소개할 GitReverse는 그 판단을 대신하는 웹 도구입니다. 공개 GitHub 저장소 주소를 넣으면, 그 프로젝트를 처음부터 한 번에 만들어 달라고 요청할 때 붙여 넣었을 법한 합성된 사용자 메시지 한 개 를 돌려줍니다. 저자는 이 결과물을 Cursor, Claude Code, Codex, v0 같은 도구에 붙여 넣는 용도로 설명하고 있습니다.
GitReverse는 Next.js 16(App Router)과 React 19, TypeScript, Tailwind CSS 4로 만들어졌고 저장소가 공개되어 있습니다. 다만 저장소는 호스팅되는 서비스의 소스이기도 해서, gitreverse.com 에는 무료로 쓸 수 있는 기본 변환 외에 유료 플랜과 크레딧 구매가 함께 운영되고 있습니다. lib/billing-config.ts 를 보면 플랜이 무료와 starter, pro, unlimited로 나뉘어 있고 deep_reverse 와 manual_control 이 플랜에 따라 제한되는 기능으로 정의되어 있습니다.
GitReverse와 기존 저장소 분석 도구 비교
저장소를 입력으로 받아 무언가를 만들어 주는 도구는 이미 여러 가지가 있고, 방향이 서로 다릅니다:
| 도구 | 입력 | 출력 | 쓰이는 자리 |
|---|---|---|---|
| ReadMeReady | 저장소 코드 | README 문서 | 만든 것을 설명하기 |
| GitMCP | 저장소 | MCP 서버 | 에이전트가 저장소를 조회하기 |
| Skill Seekers | 저장소와 문서 | 에이전트 스킬 패키지 | 저장소 지식을 에이전트에 넣기 |
| GitReverse | 공개 저장소 주소 | 요청문 한 개 | 비슷한 것을 처음부터 만들기 |
앞의 세 도구는 이미 있는 저장소를 읽기 쉽게 만드는 방향으로 갑니다. GitReverse는 반대 방향이고, 저장소를 만들어 낼 요청문으로 되돌립니다. 그래서 결과물의 성격도 다릅니다. 앞의 셋은 정확할수록 좋지만, GitReverse의 결과물은 원본을 정확히 복원하는 명세가 아니라 원본과 비슷한 것을 만들게 하는 출발점입니다.
이 차이가 저자가 시스템 프롬프트에서 분량을 120~200 단어로 정해 둔 이유이기도 합니다. 명세가 목적이라면 길수록 좋겠지만, 사람이 실제로 붙여 넣는 요청문의 길이를 모사하는 것이 목적이라 짧게 유지합니다.
GitReverse는 누구에게 맞는가
참고할 저장소를 이미 찾아 두었고 그것과 비슷한 것을 코딩 에이전트로 처음부터 만들어 보려는 사용자에게 GitReverse가 잘 맞습니다. 결과물이 짧은 한 문단이라 그대로 붙여 넣어 시작할 수 있고, 마음에 들지 않으면 직접 고쳐서 쓰면 됩니다. 저장소를 통째로 읽히는 것보다 컨텍스트 창을 훨씬 덜 씁니다.
반대로 기존 저장소를 정확히 이해하거나 옮겨야 하는 작업에는 GitReverse가 맞지 않습니다. 아래에서 살펴볼 대로 모델에 넘기는 맥락이 저장소 메타데이터와 최상위 파일 목록과 README 세 조각뿐이므로, 저장소 안쪽의 구현과 설계 결정은 결과물에 반영되지 않습니다. 저자도 하위 폴더 범위를 인식하는 맥락 수집은 이후 변경으로 계획되어 있다고 적어 두었고, 지금은 /owner/repo/tree/... 형태의 주소가 들어오면 저장소 루트로 넘겨 처리합니다. 저장소를 직접 실행해 보려는 경우라면 LICENSE 파일이 없다는 점을 먼저 확인해야 합니다.
GitReverse가 모델에 넘기는 맥락
GitReverse가 한 번의 변환에서 모델에 넘기는 것과, 모드에 따라 달라지는 조각은 다음과 같습니다:
저장소 모드에서 넘어가는 것은 GitHub API로 받아온 저장소 메타데이터, 깊이 1의 최상위 파일 트리, 그리고 README 본문입니다. 저장소 트리 문자열은 lib/file-tree-formatter.ts 가 만드는데, 깊이와 경로로 걸러낸 뒤 디렉토리를 먼저 정렬해 사람이 읽는 트리 모양으로 넘깁니다. 즉 모델은 파일 이름만 보고 구현은 보지 않습니다.
이 제약을 저자는 숨기지 않고 시스템 프롬프트 안에서 그대로 지시합니다. lib/system-prompt.ts 는 "Only claim features or stacks you infer from the README and tree you received" 라고 범위를 한정하고, README가 없거나 비어 있거나 정보가 부족했다면 "say so implicitly by keeping claims vague or limited to what the metadata suggests" 라고 이어서 지시합니다. 근거 없는 기능을 채워 넣지 말라는 조항도 별도로 들어가 있습니다.
GitReverse가 요청문에 요구하는 형식
같은 시스템 프롬프트가 결과물의 형식도 촘촘히 지정합니다. 요청하는 사람이 기술에 밝지 않거나 조금만 아는 사람 이라고 화자를 지정하고, 평범한 말로 쓴 요청처럼 들려야 하며 설계 문서처럼 읽히면 안 된다고 적습니다. 그리고 무엇을 하지 말아야 하는지를 별도 절로 나열합니다:
- 프레임워크 용어와 정확한 패키지 이름, 폴더 구조를 나열하지 않기. README가 저자도 그 부분을 중요하게 여겼다고 분명히 보여 줄 때만 예외.
- 에이전트용 시스템 지시문이나 마크다운 명세, 의사 코드 블록을 쓰지 않기.
- 맥락의 근거가 없는 기능을 만들어 내지 않기.
문체까지 지정되어 있습니다. 서두 인사와 메타 발언, 군더더기를 금지하고, 줄바꿈과 여백으로 읽기 쉽게 만들라고 하며, 하이픈과 대시를 절대 쓰지 말고 짧은 문장이나 쉼표로 나누라고 지시합니다. 마지막으로 출력은 합성된 사용자 메시지 하나여야 하고 제목이나 따옴표, 앞뒤 설명을 덧붙이지 말라고 명시합니다.
모델은 하나로 고정되어 있지 않습니다. 변환 엔드포인트는 다섯 개 제공자를 지원하고, GITREVERSE_QUICK_LLM 을 지정하면 그 제공자로 고정되며 비워 두면 발견된 키를 순서대로 씁니다:
| 제공자 | API 키 환경 변수 | 기본 모델 |
|---|---|---|
| Grok (xAI) | XAI_API_KEY |
grok-3 |
| OpenRouter | OPENROUTER_API_KEY |
google/gemini-2.5-pro |
| Azure OpenAI | AZURE_OPENAI_API_KEY + AZURE_OPENAI_BASE_URL |
gpt-5.4 |
| Google AI Studio | GOOGLE_GENERATIVE_AI_API_KEY |
gemini-2.5-pro |
| ApiSmart | APISMART_API_KEY |
DEEPSEEK_V4_FLASH |
auto 모드의 우선순위는 Grok, OpenRouter, Azure, Google, ApiSmart 순입니다. 제목 생성에는 더 작은 모델을 쓰고 추론(reasoning)을 끄며, 프롬프트 캐시 임베딩과 /library 검색에는 Azure 임베딩을 먼저 사용해 기본 512차원으로 다룹니다.
GitReverse의 웹사이트 모드
GitReverse는 저장소만 다루지 않습니다. 홈페이지의 Codebase와 Website 토글이 두 경로를 가르고, 웹사이트 모드에서는 살아 있는 웹사이트에서 브랜딩 정보와 페이지 내용, 그리고 짧은 디자인 시스템 요약을 받아 같은 형식의 요청문을 만듭니다. 이쪽 시스템 프롬프트는 저장소 모드와 대부분 같지만 한 항목이 더 있습니다. 근거가 있을 때 브랜드 분위기와 색, 타이포그래피를 문장 안에 자연스럽게 녹이라는 지시이고, 반대로 원시 디자인 토큰과 색상 코드를 그대로 나열하는 것은 금지됩니다.
또한 주소를 다루는 방식에도 짧은 편의 장치가 두 개 있습니다. 하나는 GitHub 주소에서 hub 를 reverse 로 바꾸면 그대로 열린다는 것이고(github.com/owner/repo → gitreverse.com/owner/repo), 다른 하나는 웹사이트 모드용 서브도메인입니다. lib/parse-website-reverse-host.ts 는 <이름>.gitreverse.com 으로 들어온 요청을 https://<이름>.com 을 변환하라는 뜻으로 해석합니다.
GitReverse 사용법과 자체 실행
가장 짧은 사용법은 홈페이지에 저장소 주소나 owner/repo 를 넣는 것입니다. 공유할 링크가 필요하면 /owner/repo 경로를 직접 열어도 같은 변환이 실행됩니다. 제공되는 경로는 다음과 같습니다:
| 경로 | 설명 |
|---|---|
/ |
저장소와 웹사이트 변환 시작 화면 |
/library |
캐시된 변환 결과 둘러보기 (Supabase 필요) |
/history |
로그인한 사용자의 변환 기록 |
/[owner]/[repo] |
공유 가능한 변환 링크 |
/[owner]/[repo]/tree/... |
/[owner]/[repo] 로 리다이렉트 |
직접 실행해 보려면 .env.example 을 .env.local 로 복사한 뒤 위 다섯 제공자 중 최소 하나의 API 키를 넣고 개발 서버를 띄웁니다:
pnpm install
pnpm dev
브라우저에서 http://localhost:3000 을 열면 됩니다. GITHUB_TOKEN 은 선택이고 GitHub API 요청 한도를 올려 줍니다. SUPABASE_URL 과 SUPABASE_PUBLISHABLE_KEY 도 선택이며, 넣으면 변환 결과가 서버에 캐시되고 /library 페이지가 열립니다. 운영 환경에서 필수인 값은 VIEWS_IP_SALT 하나입니다. openssl rand -hex 32 로 만들어 넣지 않으면 애플리케이션이 운영 모드에서 아예 시작을 거부합니다.
GitReverse 공식 홈페이지
GitReverse 프로젝트 GitHub 저장소
더 읽어보기
-
Skill Seekers: 문서 및 GitHub 저장소 등을 Claude 및 코딩 에이전트용 스킬(Skill) 패키지로 변환하는 도구
-
[Deep Research] GitHub의 Spec Kit으로 알아보는 Spec-Driven Development(SDD)의 개념 및 활용 (feat. Vibe Coding)
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
에서 이런 글들을 계속 정리하고 있습니다. 회원 가입으로 주요 글들을 이메일
로, 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 새 글 알림을 받아보세요! 
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 