오픈소스 프로젝트 만들어서
스타 100개 받기까지
첫 커밋부터 ★100 달성까지 — 아무도 알려주지 않은 현실과 그 과정
오픈소스를 만들게 된 계기
솔직히 처음부터 "오픈소스를 만들겠다"는 거창한 계획은 없었다. 회사 프로젝트에서 Next.js App Router를 쓰면서 반복적으로 필요한 패턴이 생겼다. 폼 상태 관리였다. React Hook Form을 쓰고 있었는데, Zod 스키마 기반으로 에러 메시지를 다국어로 처리하는 부분에서 매번 비슷한 보일러플레이트를 작성하고 있었다.
세 번째 프로젝트에서 또 같은 코드를 복사하다가 멈췄다. "이거 그냥 패키지로 만들면 어떨까?" 그 생각이 시작이었다. 나만 이런 불편함을 느끼는 게 아닐 것 같았다. npm에 올려두면 나도 편하고, 누군가에게도 도움이 될 수 있겠다 싶었다.
그렇게 주말 이틀을 써서 만든 게 첫 번째 오픈소스 라이브러리였다. 이름은 next-zod-form. README도 대충 썼고, 예제도 하나뿐이었다. GitHub에 올리고 npm publish 한 다음, 친구한테 "나 오픈소스 만들었어"라고 자랑했다. 친구 반응은 "오 대박"이었고, 그게 전부였다.
★ Stars: 1 ← 나 자신
⑂ Forks: 0
👁 Watchers: 1 ← 나 자신
📦 npm downloads (week 1): 3 ← 나, 회사 노트북, 집 노트북
─────────────────────────────────────
→ 침묵이 이어졌다. 2주 동안.
처음 두 달 — 아무 일도 일어나지 않았다
첫 달이 지났다. 스타는 1개였다. npm 주간 다운로드는 한 자릿수와 두 자릿수를 오갔다. GitHub Insights에서 traffic을 보면 방문자가 하루 1~3명이었다. 그 중 한 명은 나였다.
라이브러리 자체는 쓸 만하다고 생각했다. 나는 실제로 회사 프로젝트 두 곳에서 쓰고 있었고, 덕분에 폼 처리 코드가 확실히 줄었다. 그런데 아무도 찾아오지 않았다. 훌륭한 도서관을 지어놨는데 입구 표지판이 없는 것과 같았다.
그때 깨달은 것이 있었다. 오픈소스는 코드가 50%고, 나머지 50%는 알리는 것이다. GitHub에 레포가 존재한다고 사람들이 알아서 오는 게 아니었다. npm에 올렸다고 검색에 뜨는 게 아니었다. 내가 적극적으로 존재를 알려야 했다.
"좋은 걸 만들면 알아서 퍼진다." 이건 극히 일부의 이야기다. 대부분의 유용한 라이브러리는 세상에 알려지지 않은 채 GitHub 어딘가에 있다. 홍보는 선택이 아니라 필수다.
스타 0→10개 — README를 세 번 다시 썼다
두 달 차에 접어들면서 전략을 바꿨다. 코드를 더 짜는 게 아니라, README를 제대로 쓰기로 했다. 기존 README는 설치 방법 한 줄, 기본 예제 하나, 그게 전부였다.
잘 된 오픈소스들의 README를 20개쯤 분석했다. 공통점이 있었다. 첫 세 줄 안에 "이게 뭔지"가 명확했고, 바로 쓸 수 있는 예제가 위에 있었고, "왜 이게 필요한지"에 대한 설명이 있었다.
Next.js App Router에서 Server Action과 클라이언트 유효성 검사를 함께 쓰려면 매번 비슷한 코드가 반복됩니다. 이 패키지가 그 반복을 없애줍니다.
npm install next-zod-form zod react-hook-form
README를 다시 쓰고 나서 2주 안에 스타가 10개로 늘었다. 이전 두 달 동안 1개였던 게 2주 만에 10배가 됐다. README 하나의 차이가 이렇게 컸다.
① 첫 줄에 한 문장으로 "무엇인지" 설명 ② 설치 명령어와 기본 예제를 최상단에 ③ 기존 방법과 비교해서 "왜 쓰는지" 설명 ④ TypeScript 타입 예제 포함 ⑤ 실제 사용 사례 (데모 링크 또는 CodeSandbox)
스타 10→50개 — 커뮤니티에 직접 가져갔다
"만들어봤는데 피드백 주시면 감사하겠습니다" 톤으로 올렸다. 자랑보다는 피드백 요청. 댓글 12개, 스타 +8개. 그 날 하루에 생긴 스타가 지난 두 달 전체보다 많았다.
"Next.js Server Action에서 타입세이프 폼 만들기" 제목으로 올렸고, 패키지를 소개했다. dev.to 추천 피드에 올라가면서 스타 +14개. 글을 쓰는 것이 광고보다 효과적이었다.
모르는 사람이 타입 개선 PR을 올렸다. 그게 그렇게 기뻤다. 내 코드를 다른 사람이 보고 개선하고 싶다는 생각을 했다는 게. 스타보다 이게 더 큰 확인이었다.
검색하다가 내 라이브러리를 소개한 한국어 블로그 글을 발견했다. 내가 쓴 글이 아니었다. 스타 그래프가 그날 처음으로 급격히 올라갔다. 스타 50개를 넘어선 게 이 즈음이었다.
오픈소스를 알리는 가장 좋은 방법은 광고가 아니라 그걸 활용한 글을 쓰는 것이다. 라이브러리 홍보 글보다 그 라이브러리로 문제를 해결한 튜토리얼이 열 배는 더 효과적이다.
스타 50→100개 — 예상 못 한 경로로 왔다
50개에서 100개가 사실 제일 오래 걸릴 줄 알았다. 그런데 의외로 빨랐다. 원인은 세 가지였다.
누군가 Next.js 공식 Discord의 #help 채널에서 폼 처리 질문을 올렸고, 다른 유저가 내 패키지를 추천했다. 내가 한 게 아니었다. 그 하루에 스타가 +17개 왔다. 커뮤니티에서 자발적으로 언급되는 순간이 오면 성장 속도가 갑자기 달라진다는 걸 그때 알았다.
이 시기에 GitHub Issues에 처음으로 버그 리포트가 들어왔다. 특정 케이스에서 타입 추론이 틀어지는 문제였다. 6시간 안에 수정하고 새 버전을 릴리즈했다. 그 이슈를 리포트한 사람이 "이렇게 빠르게 반응해주는 라이브러리는 처음 봤다"는 코멘트를 남겼고, 그 스레드를 보고 스타를 누른 사람들이 있었다.
빠른 응답은 마케팅보다 강력한 신뢰 구축 수단이었다.
React Hook Form의 GitHub Discussion에서 Server Action 관련 이슈를 보고 내 패키지가 이 문제를 해결한다는 코멘트를 달았다. 몇 시간 후 Discussion 작성자가 내 패키지를 써봤다며 긍정적인 피드백을 남겼고, 그 스레드가 활성화되면서 스타가 또 늘었다.
생태계 안에서 관련 프로젝트와 연결되는 것이 단독으로 홍보하는 것보다 훨씬 효과적이었다.
기술적으로 신경 쓴 것들
스타를 모으는 것도 중요하지만, 받은 스타를 유지하려면 라이브러리 자체 품질이 기반이 돼야 한다. 초기에 제대로 잡아두지 않으면 사용자가 하나 둘 떠난다.
exports 필드 누락 (ESM/CJS 호환 문제), peerDependencies 미설정 (번들 크기 문제), keywords 비어있음 (npm 검색 누락), CHANGELOG.md 없음 (버전 변경 추적 불가). 이 네 가지는 초기에 잡아야 한다.
스타 100개가 커리어에 준 것
솔직히 스타 100개 자체보다 그 과정에서 얻은 것들이 더 컸다. 구체적으로 정리한다.
오픈소스 프로젝트 운영 경험. npm 주간 다운로드 수, GitHub 스타 수를 수치로 적을 수 있게 됐다. 면접에서 실제로 이 얘기가 나왔고, 기술력보다 "스스로 뭔가를 만들어서 배포한 경험"을 높이 사는 면접관이 있었다.
사용자 입장에서 API를 설계해야 한다는 게 뭔지 몸으로 알게 됐다. "나는 이게 편하다"가 아니라 "처음 보는 사람이 30초 안에 쓸 수 있는가"가 기준이 됐다. 회사 코드에서도 이 감각이 적용됐다.
이슈 응답, PR 리뷰, README 작성 전부 영어였다. 처음엔 구글 번역 도움을 많이 받았는데, 3개월 지나니 기술 영어로 의견을 주고받는 게 자연스러워졌다. 오픈소스가 영어 훈련장이 됐다.
모르는 사람이 코드를 고쳐줬다. 내가 미처 생각 못 한 케이스를 커버하는 PR이 들어왔다. 혼자 만들었을 때보다 더 좋은 코드가 됐다. 협업의 의미를 다른 방식으로 배웠다.
GitHub Actions로 테스트 → 빌드 → npm publish 자동화. 회사에서 DevOps 엔지니어가 해주던 것들을 직접 구성하면서 CI/CD 이해도가 완전히 달라졌다.
스타 100개는 목표였는데, 도달하고 나니 그 숫자보다 "이걸 만들고 운영한 사람"이라는 정체성이 남았다. 지금 200개를 향해 가고 있는데 예전보다 덜 긴장된다. 이미 한 번 해봤으니까.
오픈소스 처음 만드는 분들께
거창하게 시작하지 않아도 된다. 내가 반복해서 쓰는 유틸 함수 하나, 매번 똑같이 세팅하는 설정 파일 하나 — 그게 첫 번째 오픈소스가 될 수 있다. 중요한 건 "완벽하게 만들고 올린다"가 아니라 "일단 올리고 개선한다"다.
스타는 결과고, 과정은 훨씬 더 많다. 문서를 고치고, 이슈를 처리하고, 릴리즈 노트를 쓰고, 커뮤니티에 공유하는 그 모든 과정이 개발자로서의 스펙트럼을 넓혀준다. 코드만 짜는 개발자와, 코드를 만들고 배포하고 운영하고 알리는 개발자는 결이 다르다.
그리고 솔직히 말하면, 스타 100개를 받았을 때 생각보다 덤덤했다. 진짜 기뻤던 순간은 첫 외부 기여자 PR이 들어왔을 때, 누군가 모르는 커뮤니티에서 내 패키지를 추천해줬을 때, 버그 리포트를 빠르게 고쳤더니 감사하다는 코멘트가 달렸을 때였다. 숫자보다 그 순간들이 더 오래 남는다.
본인이 반복해서 쓰는 유틸 함수나 설정 파일을 하나 골라보자. GitHub에 레포를 만들고, README에 "이게 뭔지" 한 문장으로 쓰고, npm에 올리는 것까지가 첫 번째 오픈소스다. 완벽하지 않아도 된다. 버전 0.1.0이어도 된다.
134일, 102개의 스타. 숫자로는 소박하지만 그 안에 꽤 많은 게 있었다. README를 세 번 갈아엎었고, 이슈를 새벽에 처리한 날도 있었고, 아무도 안 오는 것 같아서 그만두고 싶었던 순간도 있었다. 그 과정이 지금의 나를 조금 다른 개발자로 만들었다. 다음 목표는 ★500이다. 그때 또 솔직하게 쓰겠다.
💬 오픈소스에 도전해보신 적 있으신가요?
만들어보고 싶은데 어떻게 시작해야 할지 모르겠다거나, 이미 운영 중인 프로젝트가 있다면 댓글로 공유해 주세요. 주제, 스택, 현재 스타 수 — 어떤 이야기든 환영합니다. 서로의 레포를 스타 눌러주는 것도 좋습니다 😄
'개발자 > 사이드프로젝트 창업' 카테고리의 다른 글
| 개발자가 부업으로 외주 받아본 현실 후기 (0) | 2026.07.11 |
|---|---|
| 개발자 둘이서 창업했을 때 갈라진 이유 (0) | 2026.07.04 |
| 1인 SaaS 만들어서 월 수익 낸 이야기, 퇴근 후 6개월 (1) | 2026.06.27 |
| 앱 하나 출시까지, 현실 타임라인 (0) | 2026.06.20 |
| 사이드 프로젝트 세 번 실패하고 얻은 진짜 교훈들 (0) | 2026.06.13 |
