# 작업을 공개하면 행운이 따른다 > Clean Markdown view of GeekNews topic #25406. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25406](https://news.hada.io/topic?id=25406) - GeekNews Markdown: [https://news.hada.io/topic/25406.md](https://news.hada.io/topic/25406.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-29T10:16:02+09:00 - Updated: 2025-12-29T10:16:02+09:00 - Original source: [github.com/readme](https://github.com/readme/guides/publishing-your-work) - Points: 45 - Comments: 3 ## Summary > Do the work. Tell people. ⇨ Luck = [Doing Things] × [Telling People] 더 **많은 일**을 하고 더 **많은 사람에게 알릴**수록 **행운의 표면적**이 커집니다. 개발자에게 **작업의 공개**는 자랑이 아니라 **학습의 확산**이라는 것을 기억하세요. ## Topic Body - **행운은 통제 불가능한 외부 요인**처럼 보이지만, **작업물을 공개**함으로써 좋은 기회를 만날 확률을 높일 수 있음 - **행운의 표면적(Luck Surface Area)** 은 “무언가를 하고(Doing Things)”와 “사람들에게 알리는(Telling People)” 정도의 곱으로 정의됨 - **작업 수행과 공개**는 개발자·디자이너 등 창작자에게 필수적인 과정이며, 개인의 **호기심과 전문성**을 드러내는 수단임 - 완벽한 결과물을 기다리기보다 **과정과 배움, 시행착오를 함께 공유**하는 것이 중요하며, 이는 다른 사람에게 영감을 주는 행위로 작용함 - 공개된 작업은 **새로운 일자리, 협업, 강연, 커뮤니티 연결** 등 예기치 못한 기회를 만들어내며, 이는 단순한 운이 아니라 **공유 행위가 만든 확률적 결과**임 --- ### 행운의 표면적 개념 - 행운은 “예상치 못한 좋은 일이 일어나는 것”으로 정의됨 - 예: **OSS 라이브러리의 성공**, **컨퍼런스 초청**, **새로운 일자리 제안**, **클라이언트 확보**, **팟캐스트 출연**, **커뮤니티 내 인맥 형성** 등 - Jason Roberts의 정의에 따르면, **행운의 표면적(Luck Surface Area)** 은 “열정을 가지고 무언가를 하는 정도”와 “그것을 효과적으로 전달하는 사람 수”의 곱에 비례함 - 수식으로 표현하면 **Luck = [Doing Things] × [Telling People]** - 더 많은 일을 하고 더 많은 사람에게 알릴수록 행운의 표면적이 커짐 ### 작업 수행 (Doing the work) - 공개하기 전에 먼저 **실질적인 작업 수행**이 필요함 - 개발자, 디자이너, 창작자 등은 본질적으로 무언가를 만드는 사람이며, 이는 행운의 기반이 됨 - 두 가지 유형의 사람이 있음 1\. 이미 많은 일을 하고 있지만 **자신의 작업이 공유할 가치가 없다고 생각하는 사람** 2\. **무언가를 시작하고 싶지만 실행하지 못하는 사람** - 첫 번째 그룹은 자신이 가진 지식의 가치를 과소평가하는 경향이 있으며, 커뮤니티에서 공유되는 사례를 관찰해보면 자신이 이미 할 수 있는 일들이 많음을 깨달을 수 있음 - 두 번째 그룹에게는 “**작은 것부터 시작하는 것**”이 필요 - 완벽한 아이디어를 기다리지 말고, **작은 프로젝트나 실험**으로 시작해야 함 - **“움직임이 움직임을 낳는다”** ### 호기심과 전문성의 발휘 - **개인 프로젝트**는 호기심을 탐구하기 좋은 공간임 - 예: GitHub 이슈를 출력하는 영수증 프린터 제작, 조립식 창고를 사무실로 개조, SVG 드로잉 도구 개발, 금융 인프라에 대한 장문 뉴스레터 작성 등 - **업무 프로젝트**는 전문성을 발휘하기 좋은 영역임 - 직장에서 해결한 문제나 배운 점을 **블로그, 발표, 오픈소스 프로젝트**로 전환 가능 - 세부 내용이 비공개여도 **개념·교훈·패턴**은 공유할 수 있음 - 한 달간 업무 중 흥미로운 문제나 패턴을 기록하면 공유할 아이디어가 풍부해짐 ### 공개하기 (Hitting the publish button) - 많은 사람이 **공유 단계에서 두려움**을 느낌 - 이유로는 비판에 대한 두려움, 완벽주의, 마케팅에 대한 거부감 등이 있음 - 그러나 **공유는 자만이 아니라 배움의 확산 행위**로, 다른 사람에게 영감을 주고 학습을 돕는 과정임 - 공개 플랫폼은 **Twitter, GitHub, 블로그, 뉴스레터, YouTube 등** 어디든 가능하며, “하드드라이브가 아닌 곳”이면 됨 - **공유는 배워야 하는 기술**이며, 완성된 결과물만이 아니라 **진행 과정, 실패, 사고 과정**을 함께 나누는 것이 중요함 - 처음에는 어색하지만 지속하면 자연스러워짐 ### 행운 포착 (Capturing the luck) - 작업을 공개하면 **예상치 못한 긍정적 결과**가 발생할 가능성이 커짐 - 예: 특정 주제 전문가로 인식, 독자 피드백, 구직 제안, 클라이언트 문의, 강연 초청, 커뮤니티 내 인맥 형성, OSS 프로젝트 인지도 상승 등 - 이러한 사례들은 실제로 저자가 경험한 일들로, **공유를 통해 행운의 표면적이 확장된 결과**임 - 핵심 공식은 단순함 - **Do the work. Tell people.** - 호기심과 전문성을 깊이 탐구하고, 배운 것을 공개적으로 나누는 것 - 온라인 비판은 피할 수 없지만, **비판보다 훨씬 많은 사람들이 조용히 응원하고 있음** - 결국 그중 한 사람이 인생을 바꾸는 기회를 제공할 수 있음 ## Comments ### Comment 48395 - Author: wedding - Created: 2025-12-29T13:49:49+09:00 - Points: 3 주니어들에게 늘 강조하던 것 중 에 하나가 '문제 해결 한 걸 잘 정리해서 공개된 게시물로 남겨라' 였어요. 일단 정리를 하면서 일련의 과정을 다시 한번 검토하게 되니 리마인드 하기 쉽고 똑같은 문제를 겪어도 구글링 하면 내 글이 나오니 빠르게 해결 할 수 있고(과거의 나야 고마워!) 또한 누군가에게 도움이 될 수 있으니 평판도 오를 수 있다고 설명해 줬어요 ### Comment 48376 - Author: neo - Created: 2025-12-29T10:17:01+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46397991) - 나는 오픈소스(OSS) 업계에서 일해온 사람으로서, 내 **GitHub 프로젝트가 유명해지지 않기를 진심으로 바람** 50개 이상 스타를 받은 실험적 프로젝트들이 있지만, 그것들이 ‘진짜’ OSS로 발전하지 않아 다행이었음 오래된 프로젝트의 버그 수정 요청이나 관심 없는 PR 리뷰 때문에 주말을 잃은 적도 있음 OSS 유지보수는 **보상 없는 파트타임 직업**에 가까움. 명성도 제한적이고, 뛰어난 OSS 개발자조차 업계에서 적절한 일자리를 찾기 어려워함 OSS 유지보수자는 세상의 소프트웨어를 떠받치는 **성인(聖人)** 같은 존재라고 생각함 - 나도 OSS에서 오래 일했는데, “유지보수 안 함”과 “아이 생일도 포기하고 PR 리뷰함” 사이의 **중간 단계**가 더 널리 받아들여졌으면 함 GitHub README에 “PR 환영”, “보안·치명적 버그만 수정”, “새 유지보수자 구함” 같은 **상태 배지**를 추가하면 좋겠음 - 오픈소스 문화가 지난 수십 년간 크게 변했음. 지금은 사용자 수가 기여자보다 훨씬 많고, 유지보수자가 **상업 제품 엔지니어처럼 지원 역할**을 하게 됨 그래서 요즘은 “왜 굳이 이런 사회적 계약을 맺어야 하나?”라는 의문이 생김 대안으로는 **자체 호스팅 Git 커뮤니티**를 통한 자율적 프로젝트 운영이 있음. 이런 방식은 유지보수자의 노력을 상품화하지 않고, 오픈소스를 다시 즐겁게 만들 수 있음 - GitHub가 OSS 유지보수자의 삶을 개선할 수 있는 위치에 있음에도, **문제 해결에 더 적극적이지 않은 점이 아쉬움** 예를 들어, 5년간 손대지 않은 저장소에 PR이 오면 자동으로 코드 리뷰 요약을 제공하거나, 무례한 코멘트를 필터링하는 기능을 도입할 수도 있음 - 나도 최근 몇 개의 라이브러리를 **유지보수 피로감** 때문에 비공개로 전환했음. “매니저를 불러달라”는 식의 **권리의식 강한 사용자들**이 경험을 망쳤음 - 새 OSS 프로젝트를 시작했는데, 기본은 오픈소스로 두고 **엔터프라이즈 옵션**을 추가할 예정임 코드를 공개하지 않으면 커뮤니티의 **신뢰 형성**이 어렵고, “이메일을 남기면 백서 PDF를 드립니다” 같은 접근은 2025년에는 통하지 않음 0달러의 100%는 여전히 0이지만, **거대한 시장의 0.001%** 도 꽤 큰 기회임 - 이 글의 핵심을 보면, 결국 **누군가 다른 사람(보통은 기업)** 이 오픈소스 공개로 가장 큰 이익을 얻는 구조임 GitHub(=Microsoft)가 “무료 노동 추출기”로 비칠 수밖에 없는 이유도 여기에 있음 균형 잡힌 글이라면 이런 **이해 상충**을 경고했어야 함 - 나도 같은 생각임. 투자자들이 “완벽하지 않아도 빨리 출시하라”고 조언하는 것도 비슷한 **위험한 조언**처럼 들림. 그들은 자원이 많아, 필요하면 그냥 복제할 수 있음 - (글쓴이) 내가 그 글을 썼음. 내 OSS 프로젝트가 성공하면서 **인생이 바뀌었음**, 물론 사람마다 다를 수 있음 - 젊은 세대가 왜 우리가 **GPL을 만들었는지** 다시 깨달았으면 함 기업들은 우리의 무료 노동을 좋아하지만, 고용은 하지 않음. “덕분에 잘 썼어요, 하지만 채용은 안 합니다” 식임 이제는 우리의 코드가 **LLM 학습 데이터로 흡수**되어 이름조차 남지 않음 - 나는 바다에 글을 던지고 아무 반응도 듣지 못하는 기분임 플랫폼은 “한 번만 더 올리면 성공할 거야”라고 속삭이지만, 그게 정말일까 하는 회의가 듦 - [Startups for the Rest of Us](https://www.startupsfortherestofus.com/) 인터뷰들을 들어보면, **꾸준함이 핵심**임 어떤 사람은 제품 주도 마케팅으로 3년 만에 성공했고, 또 다른 사람은 5년간 블로그로 청중을 쌓은 뒤 OSS로 수익화했음 결국 “운을 늘린다”는 말은 **동기부여용 슬로건**에 가깝지만, 실제로는 최소 5~6년의 꾸준한 노력이 필요함 - 이제 우리는 **LLM의 유령 콘텐츠 생산자**가 되어가고 있음 우리의 글은 기업의 학습 데이터로 흡수되고, 독자는 그 기업에 돈을 내며, 우리는 **감사 인사조차 듣지 못함** 인간 간의 직접 교류가 가능한 **폐쇄형 커뮤니티**만이 예외임 - 가끔 아무 기대 없이 쓴 글이 **뜻밖에 폭발적 반응**을 얻고, 정작 공들인 글은 묻히는 게 가장 아이러니함 - (농담) 혹시 그 글에 **틱톡 댄스 영상**도 같이 올렸는지? - 안녕, **동료 인간**이여 - 나도 이 글에 깊이 공감함 OSS 덕분에 **이력서나 코딩 테스트 없이** 여러 회사에서 제안을 받았음 GitHub 고객지원에서 버그를 함께 디버깅하다가 Microsoft MD에게 추천받은 적도 있고, Cloudflare에서도 비슷한 일이 있었음 결국 OSS는 **신뢰 기반의 네트워크**를 만들어주는 도구임 - 맞음, 결국 **네트워크 효과** 이야기임. 나도 25년 동안 정식 지원서를 낸 적이 거의 없음 책을 쓰고, 컨퍼런스에서 사인회를 하면서 자연스럽게 기회가 생겼음 - 내가 생각하는 오픈소스의 단계는 이러함 1\. 내 업무에서 느낀 **고통 지점**을 찾음 2\. 그 문제를 해결하는 도구를 만듦 3\. Reddit, HN, Bluesky 등에서 자연스럽게 공유함 오픈소스는 **신호 발신 수단**임. 잘 되면 명함이 되고, 컨설팅이나 채용 기회로 이어짐 예시로, 2023년 4월 LangChain을 보고 [Langroid LLM agent framework](https://github.com/langroid/langroid)를 만들었고, 또 [Claude Code Tools](https://github.com/pchalasani/claude-code-tools)라는 CLI 도구 모음도 운영 중임. 이런 과정이 오픈소스를 **학문 출판과 유사한 신뢰 축적 수단**으로 만들어줌 - (풍자) “안녕, 오픈소스 농노들이여! 우리 AI가 당신의 일자리를 대체할 수 있도록 **데이터를 더 제공**해줘!” - “바이럴 직전 99%의 오픈소스 개발자들이 포기합니다! 그러니 제발 당신의 **훈련 데이터**… 아니, 코드 좀 올려주세요!” - (글쓴이) 나는 GitHub 직원이 아님. 단지 내 **개인 경험을 공유**하고 싶었던 사람임 - 아마도 **비공개 저장소**도 학습에 쓰이고 있을 것 같음 - 나는 수학책을 몇 권 썼는데, **운이 조금은 늘었지만** 1200시간의 노동을 최저임금으로도 보상받지 못했음 - 그래서 그게 바로 **‘운’의 본질**임. 많이 시도할수록 확률은 오르지만, 보장은 없음 - 나도 활발한 OSS 기여자지만, **직업적 보상**으로 이어지지는 않았음 - 나도 무언가를 공개하면서 **좋은 일자리**를 여러 번 얻었음. 부자가 된 건 아니지만, 커리어에는 큰 도움이 되었음 - (유머) 와, **Beej의 네트워킹 가이드** 다시 한 번 고마움! - 나도 같은 경험을 했음 - (글쓴이) 이 글은 몇 년 전에 쓴 것인데, 다시 HN에서 보니 반가움 [당시 스레드](https://news.ycombinator.com/item?id=32071137)에서도 비슷한 논의가 있었음 많은 사람이 “기계에 먹이를 주는 글”이라고 하지만, **이 글이 내 인생을 바꿨음**. 다른 사람에게도 도움이 되길 바람 - 미안하지만, 그 글은 **완전 헛소리**라고 생각함. 진짜 가치 있는 건 **최고 수준의 작품**을 낼 때뿐임 - 글쓴이 직함이 “Aaron Francis, Marketing Engineer”라는데, 이제 **마케팅도 엔지니어링**이라 부르는 건가 하는 의문이 듦 - 사실 여러 분야에서 **세일즈 엔지니어** 같은 직함은 오래전부터 있었음. 기술적 조언을 해주는 역할임 - (글쓴이) 당시 나는 **마케팅 역할을 맡은 개발자**였음. 질문 환영함 - “DevRel”의 진화형으로 볼 수도 있음. 순수 엔지니어가 마케팅으로 전환할 때 **정체성을 유지**할 수 있는 표현이라 마음에 듦 [내 GitHub 프로필](https://github.com/aarondfrancis) - “풀스택 엔지니어”처럼, 이제는 **단어의 의미가 확장된 시대**임 ### Comment 48525 - Author: roxie - Created: 2026-01-01T00:18:03+09:00 - Points: 1 > Luck = [Doing Things] × [Telling People] 몇 년 전에도 이 공식을 본 것 같은데 잘 실천을 못했네요 그동안은