▲

작업을 공개하면 행운이 따른다

 (github.com/readme)
27P by neo 18시간전 | ★ favorite | 댓글 2개
  • 행운은 통제 불가능한 외부 요인처럼 보이지만, 작업물을 공개함으로써 좋은 기회를 만날 확률을 높일 수 있음
  • 행운의 표면적(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.
    • 호기심과 전문성을 깊이 탐구하고, 배운 것을 공개적으로 나누는 것
  • 온라인 비판은 피할 수 없지만, 비판보다 훨씬 많은 사람들이 조용히 응원하고 있음
    • 결국 그중 한 사람이 인생을 바꾸는 기회를 제공할 수 있음
▲
wedding 15시간전  [-]

주니어들에게 늘 강조하던 것 중 에 하나가
'문제 해결 한 걸 잘 정리해서 공개된 게시물로 남겨라' 였어요.

일단 정리를 하면서 일련의 과정을 다시 한번 검토하게 되니 리마인드 하기 쉽고
똑같은 문제를 겪어도 구글링 하면 내 글이 나오니 빠르게 해결 할 수 있고(과거의 나야 고마워!)
또한 누군가에게 도움이 될 수 있으니 평판도 오를 수 있다고 설명해 줬어요

답변달기
▲
GN⁺ 18시간전  [-]
Hacker News 의견들

  • 나는 오픈소스(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 인터뷰들을 들어보면, 꾸준함이 핵심임
      어떤 사람은 제품 주도 마케팅으로 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를 만들었고,
    또 Claude Code Tools라는 CLI 도구 모음도 운영 중임.
    이런 과정이 오픈소스를 학문 출판과 유사한 신뢰 축적 수단으로 만들어줌

  • (풍자) “안녕, 오픈소스 농노들이여! 우리 AI가 당신의 일자리를 대체할 수 있도록 데이터를 더 제공해줘!”

    • “바이럴 직전 99%의 오픈소스 개발자들이 포기합니다! 그러니 제발 당신의 훈련 데이터… 아니, 코드 좀 올려주세요!”
    • (글쓴이) 나는 GitHub 직원이 아님. 단지 내 개인 경험을 공유하고 싶었던 사람임
    • 아마도 비공개 저장소도 학습에 쓰이고 있을 것 같음

  • 나는 수학책을 몇 권 썼는데, 운이 조금은 늘었지만 1200시간의 노동을 최저임금으로도 보상받지 못했음

    • 그래서 그게 바로 ‘운’의 본질임. 많이 시도할수록 확률은 오르지만, 보장은 없음
    • 나도 활발한 OSS 기여자지만, 직업적 보상으로 이어지지는 않았음

  • 나도 무언가를 공개하면서 좋은 일자리를 여러 번 얻었음. 부자가 된 건 아니지만, 커리어에는 큰 도움이 되었음

    • (유머) 와, Beej의 네트워킹 가이드 다시 한 번 고마움!
    • 나도 같은 경험을 했음

  • (글쓴이) 이 글은 몇 년 전에 쓴 것인데, 다시 HN에서 보니 반가움
    당시 스레드에서도 비슷한 논의가 있었음
    많은 사람이 “기계에 먹이를 주는 글”이라고 하지만, 이 글이 내 인생을 바꿨음. 다른 사람에게도 도움이 되길 바람

    • 미안하지만, 그 글은 완전 헛소리라고 생각함. 진짜 가치 있는 건 최고 수준의 작품을 낼 때뿐임

  • 글쓴이 직함이 “Aaron Francis, Marketing Engineer”라는데, 이제 마케팅도 엔지니어링이라 부르는 건가 하는 의문이 듦

    • 사실 여러 분야에서 세일즈 엔지니어 같은 직함은 오래전부터 있었음. 기술적 조언을 해주는 역할임
    • (글쓴이) 당시 나는 마케팅 역할을 맡은 개발자였음. 질문 환영함
    • “DevRel”의 진화형으로 볼 수도 있음. 순수 엔지니어가 마케팅으로 전환할 때 정체성을 유지할 수 있는 표현이라 마음에 듦
      내 GitHub 프로필
    • “풀스택 엔지니어”처럼, 이제는 단어의 의미가 확장된 시대임
답변달기