LaunchRepo핵심 요약
- 저장소 자체부터 시작합니다. 무엇을 하는지, 왜 유용한지, 어떻게 시작하는지에 답하는 README, 라이선스, 최대 20개의 GitHub 토픽, 그리고 소셜 미리보기 이미지입니다.
- 그다음 사용자들이 이미 이야기를 나누는 곳으로 가세요. 사용하는 언어나 프레임워크의 포럼, 채팅, 서브레딧입니다. 가입 없이 실행할 수 있게 되면 Show HN에도 올리세요.
- 잘 맞는 awesome 리스트 한두 개를 골라, 각 리스트의 기여 규칙에 따라 메인테이너에게 요청합니다.
- 웹사이트나 호스팅 버전을 몇몇 디렉터리와 런칭 플랫폼에 등록하고, 꾸준히 릴리스하세요. 꾸준한 활동이 새로운 방문자를 계속 불러옵니다.
오픈소스 배포 지도
오픈소스가 발견되는 경로에는 네 개의 층이 있습니다. 각 층은 앞의 층 위에 쌓입니다. 커뮤니티 게시물은 사람들을 저장소로 보내므로, 저장소가 먼저 그들을 설득해야 합니다.
- 1 · 저장소모든 방문자가 가장 먼저 보는 것.
- README
- 라이선스
- 토픽
- 소셜 미리보기
- 릴리스
- 2 · GitHub 안에서의 발견GitHub 안에서 사람들이 여러분을 찾는 방법.
- 토픽 페이지
- GitHub 검색
- Explore
- 스타와 리스트
- 3 · 커뮤니티사용자들이 이미 이야기를 나누는 곳.
- Show HN
- 생태계 포럼과 채팅
- 서브레딧
- Q&A 답변
- 4 · 큐레이션과 등록계속해서 여러분을 소개해 주는 곳.
- awesome 리스트
- 패키지 레지스트리
- 디렉터리
- 뉴스레터
4주 플랜 만들기
8가지 질문에 답하고 토픽을 붙여 넣으세요. 빌더가 토픽을 GitHub 규칙에 맞는지 확인하고, 모든 채널을 주차별로 배치해 준비 완료인지, 먼저 고칠 점이 있는지 표시합니다. 모든 처리는 브라우저에서 이루어지며, 아무것도 전송하거나 저장하지 않습니다.
저장소를 찾기 쉽게 만들기
이 페이지의 모든 채널은 결국 여러분의 저장소 페이지로 이어집니다. README가 답해야 할 내용은 GitHub 공식 문서에 나와 있으며, 아래 표는 이를 첫 화면에 넣을 구체적인 내용으로 정리한 것입니다.
| 항목 | 방문자에게 필요한 것 | 효과적인 방법 |
|---|---|---|
| 무엇을 하는지 | 자신의 문제에 맞는지 몇 초 안에 판단 | 제목 바로 아래 한 문장으로, 사용자가 검색할 때 쓰는 말로 |
| 왜 유용한지 | 뻔한 대안 대신 이것을 고를 이유 | 구체적인 차이 하나, 또는 짧은 비교 |
| 시작하는 방법 | 몇 분 안에 얻는 첫 성공 | 설치 명령어 하나와 붙여 넣으면 그대로 실행되는 최소 예제 |
| 동작하는 모습 보여 주기 | 설치 전에 확인할 수 있는 증거 | 상단 가까이에 스크린샷, GIF, 터미널 녹화 |
| 도움받을 곳 | 혼자 남겨지지 않으리라는 신뢰 | Issues, Discussions, 채팅 링크. 무엇을 어디서 다루는지 명시 |
| 누가 관리하는지 | 살아 있는 프로젝트라는 확신 | 메인테이너, 최근 릴리스, 기여 가이드 |
토픽: GitHub 검색으로 들어오는 최대 20개의 문
- GitHub가 제안하는 네 가지 종류를 섞어 쓰세요. 목적(cli, static-site-generator), 주제(accessibility), 커뮤니티(hacktoberfest), 언어(rust)입니다.
- 사람들이 실제로 둘러보는 토픽을 쓰세요. github.com/topics/를 열어 해당 토픽에 이미 저장소가 있는지 확인합니다.
- GitHub는 공개 저장소에 토픽을 제안하기도 합니다. 맞는 것은 받아들이고 나머지는 거절하세요.
소셜 미리보기
이미지가 없으면 공유된 링크에는 저장소의 기본 정보와 아바타만 표시됩니다. 프로젝트 이름과 목적 한 줄을 담은 깔끔한 1280 × 640 이미지가 있으면 어디서 공유되든 한눈에 알아볼 수 있습니다. 업로드하기 전에 무료 이미지 크기 검사기로 크기와 형식을 확인하세요. 출시 이미지를 플랫폼별 사이즈 규격으로 확인하기 →
| 규칙 | 공식 문구 | 여러분에게 의미하는 것 |
|---|---|---|
| README | A README is often the first item a visitor will see when visiting your repository. | README를 랜딩 페이지처럼 다루세요. 첫 화면에서 사람들이 머물지가 결정됩니다. |
| README 크기 | When your README is viewed on GitHub, any content beyond 500 KiB will be truncated. | 긴 README는 잘립니다. 깊이 있는 참고 자료는 문서로 옮기고 링크하세요. |
| 토픽 종류 | Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language. | 한 단어의 변형 열 개가 아니라, 목적, 주제, 커뮤니티, 언어에 걸쳐 토픽을 고르세요. |
| 토픽 형식 | Use lowercase letters, numbers, and hyphens. Use 50 characters or less. Add no more than 20 topics. | 플랜 빌더의 검사기는 정확히 이 세 가지 규칙을 적용합니다. |
| 소셜 미리보기 | Your image should be a PNG, JPG, or GIF file under 1 MB in size. For the best quality rendering, we recommend a size of at least 640 by 320 pixels (1280 by 640 pixels for best display). | 1280 × 640 크기에 1 MB 미만인 PNG나 JPG를 준비하세요. |
| 커뮤니티 프로필 | The community profile checklist checks to see if a project includes recommended community health files, such as README, CODE_OF_CONDUCT, LICENSE, or CONTRIBUTING, in a supported location. | 저장소에서 Insights → Community Standards를 열고 빠진 항목을 추가하세요. |
awesome 리스트: 서로 다른 두 가지 경로
awesome 리스트는 GitHub에서 주제별로 하나씩 만들어지는 큐레이션 모음입니다. 30일, 리뷰 4개처럼 자주 인용되는 규칙은 특정한 한 가지 경우에만 적용됩니다. 내가 어느 경로에 있는지 알아 두세요.
경로 A: 내 프로젝트를 주제별 리스트에 올리기
라이브러리, 도구, 앱이라면 보통 이 경우입니다. 내 주제에 맞는 활발한 리스트를 한두 개 찾아 그 리스트의 기여 파일을 읽고, 그 형식에 맞춰 한 줄을 제안하세요. 리스트마다 받아들이는 기준이 다르므로 해당 리스트의 가이드가 곧 규칙입니다. 메인테이너를 설득하는 것은 여러분의 README, 라이선스, 최근 활동입니다.
경로 B: 내 큐레이션 리스트를 awesome 메타 리스트에 올리기
직접 리스트를 관리하는 경우에만 해당합니다. 이때는 메타 리스트의 엄격한 템플릿이 적용됩니다. 최소 30일 이상 지난 리스트, 다른 열린 풀 리퀘스트 4개 리뷰, awesome-lint 실행, Creative Commons 라이선스, awesome 및 awesome-list 토픽, 그리고 “Add Name of List” 형식의 제목입니다.
| 규칙 | 공식 문구 | 여러분에게 의미하는 것 |
|---|---|---|
| 리스트에 추가하기 | If you have something awesome to contribute to an awesome list, this is how you do it. | 리스트마다 자체 절차를 설명합니다. 일반적인 가이드가 아니라 해당 리스트의 기여 가이드를 읽으세요. |
| 리스트 기간 | That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent. | awesome 메타 리스트에 들어가려는 리스트에만 해당합니다. 첫 실질적인 커밋 후 30일을 기다리세요. |
| 리뷰 | Just commenting “looks good” or simply marking the pull request as approved does not count! | 메타 리스트 제출자는 다른 열린 풀 리퀘스트를 최소 4개, 실질적인 피드백과 함께 리뷰해야 합니다. |
| AI | Fully AI-generated pull requests are not accepted. | 풀 리퀘스트는 직접 작성하세요. 완전히 생성된 것은 닫힙니다. |
| 라이선스 | A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. | 리스트에는 Creative Commons 라이선스가 필요하며 CC0를 권장합니다. 코드용 라이선스는 인정되지 않습니다. |
| 품질 | Only has awesome items. Awesome lists are curations of the best, not everything. | 리스트에는 모든 것이 아니라 최고만 들어갑니다. 등재를 결정하는 것은 README와 활동입니다. |
규칙은 확인한 날짜 기준으로 인용했으며, 메인테이너가 규칙을 바꿀 수 있습니다. LaunchRepo는 여러분 대신 풀 리퀘스트를 열거나 리스트 메인테이너에게 연락하지 않습니다.
프로젝트를 환영하는 커뮤니티
여기서는 오픈소스가 유리합니다. 프로젝트가 실제 문제를 해결하고 여러분이 남아서 질문에 답한다면, 많은 개발자 커뮤니티가 실제로 동작하는 프로젝트를 반깁니다.
| 채널 | 가장 잘 맞는 것 | 첫 단계 |
|---|---|---|
| Show HN (Hacker News) | 바로 실행해 볼 수 있는 도구 | 한 번만 올리고, 스레드에 남아 모든 질문에 답하기 |
| 생태계의 포럼이나 채팅 | 특정 언어나 프레임워크용 라이브러리와 플러그인 | 소개 게시 규칙을 읽은 뒤, 슬로건이 아닌 사용 사례를 올리기 |
| 잘 맞는 서브레딧 | Reddit에 뚜렷한 독자층이 있는 프로젝트 | 먼저 각 서브레딧의 자기 홍보 규칙 확인하기 |
| Q&A 답변 | 반복해서 나오는 질문을 해결하는 프로젝트 | 질문에 충실히 답하고, 정말 도움이 될 때만 프로젝트 언급하기 |
| 생태계의 주간 뉴스레터 | 들려줄 이야기가 있는 릴리스 | 릴리스 링크를 담은 짧은 메모를 편집자에게 보내기 |
| 밋업과 컨퍼런스 발표 | 나눌 교훈이 있는 프로젝트 | 사용하는 언어의 지역 밋업부터 시작하기 |
2025년 9월부터 2026년 8월까지 코드 저장소를 링크한 Show HN 게시물 15,859개 전체를 담은 저희 공개 데이터셋에서, 게시물의 중앙값은 2점이었고 10점 이상을 받은 비율은 9.5%였습니다. 게시물 하나는 출발점일 뿐, 계획 그 자체가 아닙니다.
Show HN에 출시하는 방법 →규칙을 지키며 Reddit(레딧)에서 SaaS 홍보하기 →
| 규칙 | 공식 문구 | 여러분에게 의미하는 것 |
|---|---|---|
| 적합한 것 | Show HN is for something you've made that other people can play with. | 공지나 랜딩 페이지가 아니라, 사람들이 직접 실행해 볼 수 있는 것. |
| 내용 | The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now. | 실제로 공을 들였고 자신 있게 이야기할 수 있는 프로젝트를 올리세요. |
| 진입 장벽 | Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. | 설치 명령어 하나로 쓸 수 있는 공개 저장소는 이상적인 Show HN입니다. |
| 투표 | Please don't ask friends to upvote or comment. That's not ok on HN. | 투표 부탁 없이 링크만 공유하세요. 결과물이 스스로 말하게 하세요. |
| 타기팅 | Don’t spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project. | 프로젝트가 실제 문제를 해결하는 커뮤니티 몇 곳을 고르세요. |
| 평판 | the best way to invite people to share and contribute to your project is to share and contribute to their projects. | 먼저 다른 프로젝트를 도우세요. 사람들은 이를 알아보고 여러분의 프로젝트도 살펴봅니다. |
디렉터리와 런칭 플랫폼
웹사이트, 문서 사이트, 호스팅 버전이 있다면 몇몇 디렉터리가 방문자와 링크를 꾸준히 더해 주는 통로가 됩니다. 오픈소스에 잘 맞는 세 곳은 다음과 같습니다.
- AlternativeTo: 프로젝트가 잘 알려진 소프트웨어의 무료 대안일 때.
- SourceForge: “Create a Project” 경로를 통해 오픈소스 프로젝트를 다운로드와 함께 호스팅합니다. 비즈니스 소프트웨어 목록과는 별개입니다.
- Product Hunt: 완성도 높은 인터페이스가 있고, 런칭 당일에 직접 대응할 수 있는 프로젝트에.
플랫폼은 독자층과의 적합성으로 고르고, 각 플랫폼의 최신 규칙을 확인하세요. 등록은 문을 여는 것이지, 사용자를 보장하지 않습니다. 개발자가 실제로 찾아보는 곳에 내 개발자 도구를 등록하세요. →
하지 말아야 할 것
- 구매하거나 교환한 스타
- GitHub 정책은 순위 조작을 금지하며, 연구에 따르면 구매한 스타의 효과는 잠깐뿐입니다. 저희가 직접 측정한 결과와 함께 자세히 살펴보세요: 진짜 쓸모로 GitHub 스타를 얻는 방법 →
- 친구에게 추천 부탁하기
- Hacker News는 그런 부탁이 괜찮지 않다고 분명히 밝힙니다. 친구 무리의 투표로는 실제 관심도 알 수 없습니다.
- 모든 곳에 같은 게시물
- 하루에 여러 커뮤니티에 복사해 붙여 넣은 공지는 스팸처럼 보입니다. 몇 곳만 골라 각각에 맞게 쓰세요.
- README보다 먼저 런칭
- 관심은 오래가지 않습니다. 어떤 게시물을 올리기 전에 저장소의 첫 화면부터 다듬으세요.
LaunchRepo의 역할
LaunchRepo는 디렉터리와 런칭 플랫폼 층을 맡습니다. 여러분의 코딩 에이전트가 프로젝트 웹사이트를 대규모 디렉터리 카탈로그에 맞춰 준비하고 제출하며, 트래커가 게시된 등록과 대기 중인 등록을 구분해 보여 줍니다.
커뮤니티 게시물, awesome 리스트 요청, 대화는 여러분이 직접 합니다. 여러분 자신의 목소리로 할 때 가장 효과가 좋기 때문입니다. LaunchRepo가 양식 작성에 들 시간을 덜어 주니, 그 시간을 그곳에 쓰세요.
출처
모든 규칙은 2026년 10월 1일에 확인했으며 영어 원문 그대로 인용했습니다. 텍스트 사본은 저희 증빙 자료와 함께 보관합니다.
자주 묻는 질문
- 오픈소스 프로젝트는 어떻게 홍보하나요?
- 저장소부터 시작하세요. 무엇을 하는지, 왜 유용한지, 어떻게 시작하는지에 답하는 README, 라이선스, 토픽, 미리보기 이미지입니다. 그다음 가입 없이 써 볼 수 있게 되면 생태계 커뮤니티와 Show HN에 공유하고, 잘 맞는 awesome 리스트 한두 곳에 요청하고, 꾸준히 릴리스하세요.
- 내 프로젝트를 awesome 리스트에 올리려면 어떻게 하나요?
- 리스트를 열고 기여 파일을 읽은 뒤, 그 형식에 맞는 항목 하나를 제안하세요. 엄격한 규칙(30일, 리뷰 4개, awesome-lint)은 내 큐레이션 리스트를 awesome 메타 리스트에 제출할 때만 적용됩니다.
- GitHub 토픽은 몇 개를 추가해야 하나요?
- GitHub에서는 최대 20개까지 허용합니다. 목적, 주제, 커뮤니티, 언어를 나타내는 토픽을 소문자, 숫자, 하이픈으로, 각각 50자 이하로 쓰세요.
- Show HN은 오픈소스에 좋은 곳인가요?
- 네, 사람들이 바로 프로젝트를 실행해 볼 수 있고 여러분이 남아서 질문에 답할 수 있다면 그렇습니다. Show HN은 가입 장벽 없이 써 볼 수 있는 것을 요구하며, 친구에게 투표를 부탁하지 말라고 합니다.
- 자리 잡은 프로젝트처럼 보이려면 GitHub 스타를 사야 하나요?
- 아닙니다. GitHub 이용 정책(Acceptable Use Policies)은 자동화된 스타 누르기 같은 순위 조작을 금지하며, 대규모 연구에 따르면 구매한 스타는 잠깐만 도움이 되고 장기적으로는 해가 됩니다.
- LaunchRepo가 커뮤니티에 대신 글을 올려 주나요?
- 아닙니다. LaunchRepo는 프로젝트 웹사이트의 디렉터리 및 런칭 플랫폼 제출을 위한 플레이북을 에이전트에게 제공합니다. 커뮤니티 게시물과 awesome 리스트 요청은 여러분이 직접 하는 일입니다.
디렉터리는 에이전트에게 맡기세요
한 번 구매로, 여러분의 코딩 에이전트와 함께, 만드는 모든 제품에 쓸 수 있습니다. 여러분이 사용자와 대화하는 동안 코딩 에이전트가 LaunchRepo를 사용해 프로젝트 웹사이트를 디렉터리와 런칭 플랫폼에 제출합니다.
요금 보기