# 당신의 오픈소스를 유명하게 만드는 방법

> Clean Markdown view of GeekNews topic #19789. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19789](https://news.hada.io/topic?id=19789)
- GeekNews Markdown: [https://news.hada.io/topic/19789.md](https://news.hada.io/topic/19789.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-03-17T09:07:17+09:00
- Updated: 2025-03-17T09:07:17+09:00
- Original source: [evilmartians.com](https://evilmartians.com/chronicles/how-to-make-your-open-source-popular)
- Points: 37
- Comments: 1

## Summary

오픈 소스를 통해 유명해지거나 부자가 되겠다는 생각은 잘못되었으며, 오픈 소스 활동은 이력서 보강보다는 세상을 바꾸기 위한 것이어야 합니다. 인기 있는 오픈 소스 프로젝트를 만들기 위해서는 명확한 README 작성, 사용자에게 이점을 효과적으로 전달하는 문서 작성, 반복적이고 효과적인 홍보 전략이 중요합니다. 글에서는 README 작성 방법을 자세하게 설명하며 추가로, 프로젝트가 유명해졌을 때의 문제 해결법, 부정적인 피드백에 대처하는 방법, 경쟁 프로젝트 등장 시 대처 전략도 이야기 합니다. 일단 유명해지는게 먼저겠지만요.

## Topic Body

### 오픈 소스를 유명하게 만들기 전에 알아야 할 점  
- 오픈 소스를 통해 유명해지거나 부자가 되고 싶다면 잘못된 접근임  
- 인기 있는 프로젝트를 만들기보다 블로그 작성이나 컨퍼런스 발표가 더 효과적임  
- Redux와 React Router는 인기 있는 프로젝트지만 유지 관리자는 소셜 미디어 팔로워가 많지 않음 → 프로젝트의 인기가 개인의 인기로 이어지지 않음  
  
### 오픈 소스를 이력서에 쓰기 위해 만들지 말 것  
- 오픈 소스 참여가 필수라는 인식은 거짓임  
- 유명해지기 위해 오픈 소스를 시작해도 성공 보장은 없음  
- 좋은 프로젝트라도 별이 하나뿐이라면 우울해질 수 있음  
- 채용에서 오픈 소스 활동이 도움이 될 수는 있으나, 직접 프로젝트를 만들기보다 **기존 유명 프로젝트에 기여하는 것**이 더 효과적임  
  
### 먼저 기여부터 시작하기  
- 큰 오픈 소스 프로젝트에서 **문서 수정**이나 **버그 수정**부터 시작  
- 코드 작성보다 PR 작성이 훨씬 쉬움  
- 좋은 오픈 소스를 만들기 위한 가장 좋은 이유는 **세상을 바꾸고 싶기 때문**  
  
### 오픈 소스를 통해 세상을 바꾸는 방법  
- PostCSS를 만든 이유는 CSS 도구 생태계를 다양화하고 더 쉽게 CSS 처리가 가능하게 하기 위함 → 성공적  
- 인기와 성공은 중요한 요소임  
  
### 인기 프로젝트의 비결   
> **프로젝트의 인기 = 인지도 + 프로모션 + 사용자에게 주는 이점 + 운**  
- 인기 있는 개발자가 만든 프로젝트가 더 쉽게 인기를 얻는 경향이 있음 → 부당할 수 있지만 현실임  
- 인기의 원인을 이해하고 전략적으로 접근해야 함  
  
### 사람들이 오픈 소스를 선택하는 방식  
- 사람들은 합리적으로 도구를 선택하지 않음  
- 대부분 GitHub에서 Star 개수를 보고 결정  
- 또는 컨퍼런스에서 언급된 프레임워크를 따라가는 경우가 많음  
  
### 사람들이 실제로 정보를 읽는 방식  
- 사용자는 README나 문서를 처음부터 끝까지 읽지 않음  
- 정보를 '프로그레시브 JPEG'처럼 간단히, 점진적으로 제공해야 함  
- 첫 블록에서 혜택을 명확히 설명해야 함  
  
### 인기 얻기 전략  
  
- 소셜 미디어 계정을 잘 정리해야 함  
  - 저자는 처음에 영어 소셜 계정을 만들지 않아 사람들이 저자를 찾기 어려웠음  
  - 비영어권 개발자라면 **영어 소셜 미디어 계정**을 만드는 것이 유리함  
  - 프로젝트가 언급될 때 **프로필 링크**를 제공해야 사용자 연결이 쉬워짐  
- 현실적인 마인드 설정  
  - **운이 중요하지만 전부는 아님**  
  - 저자는 **56개의 프로젝트 중 4개만 성공**  
  - 인기 프로젝트를 만들기까지 여러 번의 실패를 경험  
  - 성공한 프로젝트는 꾸준한 시도와 반복된 실패의 결과  
- 실패를 당연하게 받아들이기  
  - 인기 프로젝트는 **마라톤**처럼 오랜 시간의 노력 필요  
  - 실패는 과정의 일부 → 지속적인 개선과 반복 시도가 필요  
  - **처음부터 실패를 예상**하고 시작하되, 작업의 퀄리티는 포기하지 말아야 함  
  
---   
  
### 오픈 소스를 인기 있게 만드는 법 : README  
- README와 문서는 프로젝트의 첫인상을 결정함  
- 사용자가 README를 통해 프로젝트의 가치를 빠르게 파악해야 함  
- README는 다음과 같은 경로를 통해 사용자에게 노출될 수 있음  
   - 발표, 블로그 글, 팟캐스트 등 다양한 프로모션 경로  
   - 결국 README로 연결되기 때문에 신경 써서 작성해야 함  
- 독자는 README를 처음부터 끝까지 꼼꼼히 읽지 않음  
- 따라서 README 첫 부분에서 프로젝트의 가치를 명확히 전달해야 함  
- 첫 블록에서 사람들이 프로젝트의 이점을 빠르게 이해할 수 있어야 함  
  
> **질문: 프로젝트의 가치를 효과적으로 전달하고 있는가?**  
  
- 사람들은 여유롭게 문서를 자세히 읽지 않음  
- 따라서 핵심 정보와 이점을 명확하고 간결하게 정리해야 함  
- 문서를 잘 정리함으로써 사용자 경험을 개선하고 프로젝트의 인기를 높일 수 있음  
  
#### 1. 사용자에게 이점을 효과적으로 전달하기  
  
- 사용자에게 프로젝트의 이점을 전달하는 것은 프로모션과 직접적으로 연결됨  
- 이전에 언급한 성공 공식에서 **사용자에게 이점을 제공**하는 것이 중요한 요소임  
  
> **프로젝트의 인기 = 인지도 + 프로모션 + 사용자에게 주는 이점 + 운**  
  
- README, 문서 또는 간단한 소개글에서 사용자에게 이점을 명확하게 전달해야 함  
- 인기나 평판이 아닌 실제 가치로 주목받기 위해서는 다음과 같은 점을 고려해야 함  
  - **정보의 가독성**: 사용자가 빠르게 핵심 내용을 파악할 수 있어야 함  
  - **스캔 가능성**: 중요한 정보가 쉽게 눈에 띄도록 구성해야 함  
  - **첫인상**: 첫 몇 초 안에 프로젝트의 가치가 명확히 드러나야 함  
  
#### 2. 메시지를 빠르고 효과적으로 전달하기  
  
- README의 첫 블록에는 다음 세 가지 요소가 반드시 포함되어야 함  
  1. **명확한 설명**  
  2. **사용자에게 어떤 도움이 되는지 명확히 제시**  
  3. **다른 제품과의 차별점 명시**  
- 사용자가 문서를 읽어야 할 이유를 첫 문장에서 명확히 전달해야 함  
  - 첫 문장이 가장 중요함 → 대부분의 사용자는 첫 문장만 읽고 프로젝트의 가치 판단  
  - 따라서 첫 블록에서 프로젝트의 이점이 명확히 드러나도록 해야 함  
- README의 첫 블록 작성에 **며칠에서 일주일** 정도 투자해도 괜찮음  
- PostCSS의 첫 블록 작성에 **약 일주일**이 걸렸음  
- 첫 블록에 충분한 노력이 들어가야 프로젝트의 성공 가능성 증가  
  
#### 3. 제품을 사람들이 쉽게 이해할 수 있도록 설명하기  
  
- 프로젝트 설명은 명확하고 직관적이어야 함  
- 멋있어 보이는 표현보다 **실질적인 설명**이 더 중요함  
- ❌ **"Svelte is cybernetically enhanced web apps"**  
  - 너무 모호함 → 구체적으로 어떤 장점이 있는지 불명확함  
- ✅ **"Svelte is a web UI framework with a unique compiler which generates smaller JS fixes."**  
  - 구체적이고 명확함 → 어떤 문제를 해결하고 어떤 이점이 있는지 설명  
- 동료와 술집에서 대화한다고 생각하고 설명 작성하기  
  - "새로운 도구를 만들었다고? 뭐 하는 도구야?" → 자연스럽게 설명하기  
- 설명이 정리되면 **더 간결하게 다듬기**  
  - 설명을 작성한 후 **2~4번 더 다듬어서 짧고 명확하게** 만들기  
  
#### 4. 리스트와 볼드 텍스트로 정보를 빠르게 전달하기  
  
- 정보를 명확하게 전달하려면 **리스트와 볼드 텍스트**를 적극 활용해야 함  
- **Nano Stores의 기존 설명** (텍스트 블록 형태)  
  - Nano Stores는 다양한 프론트엔드 프레임워크에서 사용할 수 있는 상태 관리자임  
  - 크기가 작고, 의존성이 없음  
- **수정된 설명** (리스트 및 볼드 강조 사용)  
  - **Nano Stores**는 다음과 같은 특징이 있음:  
    - **작은 크기**: 286~818바이트 (minified 및 brotlied)  
    - **다양한 프레임워크 지원**: React, Vue, Svelte, Angular 등  
    - **의존성 없음**  
- # 가독성을 높이는 포인트  
  - **리스트 사용**: 정보를 구조화해 한눈에 파악 가능  
  - **볼드 텍스트 사용**: 핵심 정보를 강조해 빠르게 인지 가능  
  - **간결한 문장**: 중요한 정보만 남기고 불필요한 내용 삭제  
    - 텍스트를 줄여도 메시지가 명확하게 전달되어야 함  
  
#### 5. 코드 예제와 이미지 활용하기  
  
- 복잡한 개념은 **예제 코드**나 **이미지**를 통해 쉽게 설명할 수 있음  
   - "백 마디 말보다 한 장의 그림이 낫다"는 말처럼 시각 자료는 이해를 돕는 강력한 도구임  
  
#### 6. 실제 통계 자료 사용하기  
- **모호한 표현이나 추상적인 약속**은 신뢰를 얻기 어려움  
   - 실제 성능, 크기, 속도 등의 **구체적인 통계**를 제시해야 함  
- # 예시: Nano ID의 실제 통계 사용  
  - **크기 증명**: Nano ID는 **141바이트**로 작음 → 명확한 수치 제공  
  - **속도 증명**: Nano ID는 UUID보다 **16% 더 빠름** → 벤치마크 결과 제시  
- 효과적인 통계 자료 활용 팁  
  - **수치화된 성능 데이터 제공** → 신뢰도 강화  
  - **벤치마크 결과 명시** → 다른 제품과의 차별화 강조  
  - **API 성능이나 사용법도 실제 예제와 함께 명확히 제시**  
    - 성능, 크기, 속도 등은 구체적인 수치와 데이터로 증명  
  
#### 7. 단계별 시작 가이드 제공하기  
  
- 프로젝트의 장점이 명확히 전달되었다면, 그다음은 **구체적인 사용 방법**을 제공해야 함  
- 사용자가 README를 읽은 후 프로젝트에 흥미를 가지면, 다음 단계로 자연스럽게 이어져야 함  
- # 효과적인 시작 가이드 작성 팁  
  - **구체적인 단계별 가이드 제공**  
    - "PostCSS를 사용하세요" 같은 모호한 설명 대신 **명확하고 구체적인 단계**를 제시  
    - 각 단계에서 필요한 명령어 및 설정 방법 명시  
  - **대체 경로 제공**  
    - 사용자의 상황에 따라 다른 접근 방법을 제시  
    - 예: PostCSS가 설치되지 않은 경우의 처리 방법 추가  
  - **사용자 유형별 섹션 제공**  
    - 대규모 라이브러리와 소규모 라이브러리 사용자에게 각각 맞는 가이드를 제공  
- # 테스트 필수  
  - 직접 작성한 가이드를 따라 보며 실제로 잘 작동하는지 테스트해야 함  
    - 가능한 경우, 프로젝트에 대한 배경 지식을 잊고 **처음부터 다시 따라 하기**  
    - 문제가 발생하면 즉시 수정하고 보완  
  
---  
  
### 효과적인 오픈 소스 홍보 전략  
  
#### **1. 반복적인 홍보의 중요성**  
- 많은 사람들이 다음과 같은 실수를 함  
  1. 소셜 미디어에 한 번만 게시  
  2. 반응이 없음  
  3. 우울해짐  
  4. 프로젝트 중단  
- 한 번의 대규모 홍보는 효과적이지 않음 → **점진적이고 반복적인 홍보 필요**  
- **효과적인 반복 홍보 사이클**  
  1. 새로운 기능 릴리스, 블로그 포스트, 소셜 미디어 게시물 등 콘텐츠 생성  
  2. 사용자 피드백 받기  
  3. 피드백 기반으로 프로젝트 수정  
  4. 수정 사항에 대한 새 콘텐츠 생성 → 다시 시작  
- 초기에는 사용자 수가 적은 것이 오히려 유리함 → 스트레스 없이 수정 가능  
- 지속적인 개선과 반복적인 홍보를 통해 인지도 상승  
  
#### **2. 효과적인 소셜 미디어 홍보 전략**  
- 단순히 링크만 공유하거나 짧은 설명으로 끝내지 말 것  
- 다음 2가지를 포함할 것  
  - **코드 예제 또는 이미지** → 사람들이 쉽게 이해함  
  - **명확한 프로젝트 설명** → 새로운 사용자도 이해 가능  
- # **홍보 글 템플릿 예시**  
  - 새 기능 발표 → 명확한 설명 → 코드 예제 포함 → 소셜 미디어에 공유  
  - Reddit에서 관련 서브레딧에 게시 (각 서브레딧 규칙 확인)  
  - Hacker News에 게시 → 초기 traction 확보 가능  
  - Dev.to, Smashing Magazine, CSS-Tricks 등에 기사 작성 → 노출 확대  
  
#### **3. PR을 통한 홍보 전략**  
- 다른 프로젝트에 자신의 오픈 소스를 도입하는 PR 제출  
  - 예: PostCSS는 다른 프로젝트에 PR을 통해 홍보 성공  
  - "도움이 필요하면 제가 이 도구를 적용해 볼 수 있습니다."  
- PR이 승인되면 README에 적용 사례 명시 → 신뢰도 상승  
- 인기 있는 프로젝트에서 자신의 도구를 사용한다고 명시하면 신뢰도 강화  
  
#### **4. 반복하되 스팸은 금물**  
- 지속적인 반복 홍보 필요  
- 그러나 **스팸은 절대 금지**  
  - 동일한 메시지를 반복하지 말고 **새로운 가치** 제공  
  - 변화와 발전된 내용을 포함할 것  
- 모든 사용자가 모든 게시물을 읽는 것은 아님 → 주기적으로 다양한 형태로 반복 홍보 필요  
  
### **반복 홍보의 이유**  
- 사람들은 합리적으로 도구를 선택하지 않음  
- 반복적인 홍보를 통해 인지도를 자연스럽게 형성  
- 오랜 기간 동안 인지도를 쌓아야 성공 가능  
  
---  
  
### 보너스   
  
#### **1. 프로젝트가 유명해졌을 때의 문제 해결법**  
- 프로젝트가 인기를 얻으면 해결해야 할 **이슈**가 폭발적으로 증가할 수 있음  
- 스스로 모든 문제를 해결하려고 하면 부담이 커져 우울감과 생산성 저하로 이어질 수 있음  
- # **해결책**  
  - 모든 문제를 직접 해결하려 하지 말 것 → 사용자에게 **PR 작성**을 권장  
  - "이 문제를 해결하고 싶다면 PR을 보낼 수 있나요?"라고 요청  
  - 문제 해결에 할당된 시간(예: 하루 15분)을 설정하고 그 시간 안에서만 처리  
  - 어려운 문제는 즉시 해결하려 하지 말고 "해결 방안을 검토 중입니다"라고 응답 → 사용자는 문제를 인지하고 있다는 피드백만으로도 안심함  
  - 문서 수정도 사용자에게 맡길 수 있음 → "이 부분을 수정해줄 수 있나요?"라고 요청  
  
#### **2. 부정적인 피드백에 대처하는 방법**  
- 부정적인 피드백은 동기 저하로 이어질 수 있음  
- 프로젝트 초기에 부정적인 피드백은 의욕을 꺾을 수 있고, 인기가 많아지면 자신감을 약화시킬 수 있음  
- # **대응 전략**  
  - 감정적으로 반응하지 말 것  
  - 비판에 대해 질문 → "왜 B가 A보다 낫다고 생각하나요?"라고 물어볼 것  
  - 비판이 단순한 감정 표출인 경우가 많음 → 사용자와 대화를 시도해 신뢰 구축  
  - 비판을 통해 개선의 기회를 얻을 수 있음  
  
#### **3. 경쟁 프로젝트 등장 시 대처 전략**  
- 경쟁 프로젝트가 등장해도 걱정할 필요 없음  
- 경쟁 프로젝트가 나오면 다음과 같은 이점이 있음  
    - 프로젝트 유지 부담에서 벗어날 수 있음  
    - 경쟁을 통해 더 나은 솔루션이 나올 수 있음 → 결국 사용자에게도 이익  
- 오픈 소스의 궁극적인 목적은 세상을 바꾸는 것 → 독점이나 지배가 아님  
- 경쟁 프로젝트 등장 → 더 나은 도구 탄생 → **윈윈 상황**  
  
---  
  
### 최종 요약  
  
#### **인기 있는 오픈 소스를 만들고 가시성을 확보하는 법**  
1. 오픈 소스를 만드는 가장 좋은 이유는 유명세나 이력서 보강이 아니라 **세상을 바꾸기 위해서**임  
2. 좋은 아이디어가 인기 프로젝트가 된다는 보장은 없음  
3. 오픈 소스 프로젝트의 인기도 공식 = **인기도 + 홍보 + 사용자 혜택 + 운**  
4. 소셜 미디어 계정은 활성화하고, 검색 가능하도록 하며, 영어 등 널리 사용되는 언어로 작성해야 함  
  
#### **효과적인 문서 작성법**  
1. README와 문서는 친구에게 설명하듯 명확하고 자연스럽게 작성해야 함  
2. 강조 텍스트, 목록, 체계적인 구성으로 복잡한 정보를 점진적으로 전달  
3. 실제 벤치마크와 코드 예제 등 **구체적 증거**를 제공해야 함  
4. 가능한 경우, 초보자와 고급 사용자에 맞춘 구체적인 시작 가이드를 제공  
  
#### **홍보 전략**  
1. 한 번의 대규모 홍보보다 반복적인 홍보가 더 효과적임 → 출시 → 피드백 → 개선 → 반복  
2. 정기적으로 게시하되 스팸은 피할 것  
3. 코드 예제와 이미지를 포함한 게시물 작성  
4. 다른 프로젝트에 PR을 제출해 홍보 효과 극대화  
  
#### **프로젝트가 유명해졌을 때의 팁**  
1. 모든 문제를 스스로 해결하려 하지 말고, 사용자가 PR을 제출하도록 유도  
2. 문제 해결을 위한 일정 시간을 정해놓고 관리 (예: 하루 15분)  
3. 부정적인 피드백이 있을 경우 질문을 통해 대화 시도  
4. 경쟁 프로젝트를 두려워하지 말 것 → 경쟁이 오히려 책임에서 자유롭게 해줄 수 있음

## Comments



### Comment 36481

- Author: roxie
- Created: 2025-03-28T19:55:42+09:00
- Points: 1

조금씩 다른 내용의, 하지만 멀리서 보면 반복적인 내용의 홍보가 용인되는 장소를 찾아내는 것도 중요할 것 같습니다. 예를 들면 트위터요.