개발자 관계

오픈소스와 창업

2018-10-03
개발자 관계
ko

이 글은 제가 고가용성 아키텍처 그룹 모임에서 한 강연을 정리한 것입니다. 어릴 적부터 말을 잘하지 못하는 사람이었고, 매번 공개 강연을 할 때 긴장을 느껴 자신의 생각을 완전히 표현할 수 없었습니다. 강연할 때 유창하게 말하는 사람이 부러웠습니다. 그래서 자신의 생각을 글로 정리하여 표현하기로 했습니다.

개인적으로 오픈소스 분야에서는 초보자로, 16년 초에 go-commons-pool이라는 오픈소스 프로젝트를 발표했습니다. 이것은 golang의 범용 객체 풀로, 지금까지 거의 200개의 스타를 받았습니다. 창업 분야에서도 초보자로, 15년 초에 기술 파트너로서 팀 커뮤니케이션 협업 도구를 만드는 창업을 시작했습니다. 1년 동안 개발을 하면서 제품 업무와 운영 업무를 겸했습니다. 창업과 오픈소스 두 가지의 공통점이 많다고 느껴 몇 가지 깨달음을 공유합니다. 앞서 여러 분들이 건조한 내용을 많이 이야기했고, 제 프로젝트는 기술적으로 비교적 간단해서 Tim의 조언에 따라 닭고기 수프를 좀 더 섞기로 했습니다. :)

창업이든 오픈소스든, 먼저 직면하는 첫 번째 문제는 무엇을 할 것인가입니다. 무엇을 할 것인가라는 생각은 어디서 올까요? 다음 두 가지 경로 외에는 없습니다:

  1. 관찰 주변 사람들을 관찰하고, 자신의 생활과 업무를 관찰하며, 모든 사람의 습관을 관찰하고, 어디에 개선할 곳이 있는지, 어디에 고통점이 있는지 봅니다. 예를 들어 제 pool 아이디어는 누군가 그룹에서 질문했을 때 검색해 보니 golang에 실제로 범용으로 사용하기 좋은 객체 풀이 없다는 것을 발견한 것입니다. 또 다른 예로 누군가 택시 잡기가 이렇게 어렵다는 것을 발견하고 Uber가 생겼습니다. 누군가 여러 기기에서 파일을 동기화하고 싶어서 Dropbox가 생겼습니다. 누군가 업무에서 항상 반복 작업을 하고 있다는 것을 발견하여 다양한 프레임워크가 생겼습니다.
  2. 참고 다른 선진 지역, 선진 분야를 살펴보고 참고할 만한 것이 있는지, 선진 지역이나 분야의 성과를 후진 지역이나 새로운 분야로 이식합니다. 계속 뜨거웠던 Copy To China 창업이 이런 모델로, 선진 지역의 발전 궤적을 통해 후진 지역의 미래 추세를 예측합니다. 그날 고가용성 그룹에서 indigo의 공유, 일본의 경제 사회 발전을 통해 중국의 추세를 예측하는 것도 같은 이치입니다. 제가 이 pool을 만든 것도 실제로 java 커뮤니티의 상황을 분석하고, golang이 앞으로 서버 측에서 큰 역할을 할 것이라고 생각했으며, 반드시 견고한 객체 풀이 연결 풀 등의 용도로 필요할 것이라고 생각했습니다.

무엇을 할지 생각했다면, 다음은 어떻게 할 것인가입니다. 이 단계는 창업과 오픈소스가 큰 차이가 있는 것 같지만, 두 가지의 공통점은 여전히 있습니다. 실제로 하는 핵심은 ‘일’의 리소스 투입을 평가하고 배치하는 것입니다. 리소스에는 돈과 시간이 포함됩니다. 앞서 생각한 일이 너무 크고 실제 리소스와 맞지 않으면 결과는 창업이 망하거나, 오픈소스 프로젝트는 저장소를 만들고 readme를 작성한 후 아무 일도 일어나지 않는 것일 수 있습니다. 여기서는 일의 복잡도 평가 능력과 리소스 통제 능력이 시험됩니다.

프로젝트를 만든 후에는 어떨까요? 다음 단계는 어떻게 사용자 그룹에게 알릴 것인가입니다. 즉, 지금 유행하는 말로 ‘홍보’입니다. PingCAP의 황동욱도 방금 그들의 마케팅 방식과 채널을 언급했습니다. 이 단계의 핵심은 사용자 그룹의 관심이 일반적으로 어디에 있는지, 어떻게 최소 비용으로 사용자에게 도달할 것인지 아는 것입니다. 오픈소스 프로젝트는 다양한 오픈소스 커뮤니티나 기술인 커뮤니티, 자신의 소셜 네트워크, 기술 회의 등 다양한 방식을 통해 전달될 수 있습니다.

초기 사용자 도달이 완료되고, 사용자가 프로젝트를 알게 되면, 일부 사람들은 스타를 눌렀을 수 있습니다. 이 사람들은 잠재적 사용자입니다. 또 다른 일부는 fork했을 것으로, 아마 사용하거나 2차 개발을 준비하는 것일 것입니다. 그렇다면 현재 사용자를 어떻게 유지하고 더 많은 사용자를 끌어들일 것인가? 이것이 이 단계에서 고려해야 할 것입니다. 다음을 포함하지만 이에 국한되지 않습니다:

  1. 문서를 완성하고 사용자에게 사용법을 가르칩니다. 사용자가 ‘약하다’고 싫어하지 마십시오.
  2. 사용자 피드백에 응답하고 issue를 처리합니다. 창업 제품이라면 고객 서비스 체계가 있어야 합니다.

점차 사용자가 많아지고, 커뮤니티가 형성되며, 자신의 브랜드가 생깁니다. 이 단계는 제가 만든 것과 같은 작은 도구로는 도달할 수 없지만, 예를 들어 PingCAP의 TiDB, 사맹군의 beego와 같은 프레임워크는 이미 자신의 커뮤니티와 브랜드를 형성했습니다.

이 과정의 핵심점을 정리하면:

  1. 아이디어가 잘 추상화되지 않았습니다. 사실 모든 도구와 제품은 일종의 추상화를 하고 있으며, 사용자 요구의 추상화입니다. 예를 들어 그 유명한 예, 사용자에게 무엇이 필요한지 물으면 사용자는 분명 더 빠른 말이라고 대답할 것이지 자동차가 아닙니다. 자동차는 사용자 이동 요구의 추상화입니다. 하지만 이런 추상화를 어떻게 할까요? 저는 세 가지 경지로 정리했습니다.
    • DRY 원칙Don’t repeat yourself, 자신을 반복하지 말라. 가장 흔하게는 코드 규칙에서 사용되며, 마음대로 복사 붙여넣기 하지 말고 일정한 추상화를 하라고 권장합니다. 하지만 실제로 모든 언어의 고급 기능, 객체 지향, 모듈화, 코드 생성 도구, 다양한 프레임워크는 모두 이 문제를 해결하고 있습니다. 즉, 많은 반복 작업을 하고 있다는 것을 발견하면 여기서 도구를 추상화할 수 있다는 것을 의미합니다.
    • 바퀴를 다시 발명하지 마라. 이 원칙은 논란이 있는 것 같지만, 저는 논란이 ‘발명’과 ‘만들기’의 차이를 이해하지 못한 것이라고 생각합니다. 바퀴를 반복해서 발명하지 마라. 하지만 당신은 새로운 바퀴를 만들거나 기존 바퀴를 개선할 수 있습니다. 이 원칙은 다른 사람이 이미 완성한 작업을 반복하지 말고, 문을 닫고 혼자 만들지 말고, 선인의 기초 위에서 개선하라는 것입니다. 항상 바퀴를 발명한 사람은 위대하고 어렵다고 생각하며, 역사적 지위는 불을 발명한 것과 비교할 수 있습니다. 바퀴가 있은 후 인류가 사용하는 도구와 동물이 사용하는 도구는 본질적인 차이가 생겼습니다.
    • 앞서 우리는 자신을 반복하지 않고, 다른 사람도 반복하지 않았습니다. 세 번째 경지는 ‘다른 사람이 당신을 반복하지 않게 하라’입니다. 당신의 도구, 프레임워크, 추상화를 공유하여 오픈소스 제품이나 SaaS 서비스로 만들어 다른 사람이 당신이 이미 완성한 작업을 반복하지 않게 합니다.
  2. 개발 속도가 느려지고, 경쟁 제품이 나타나거나, 기능이 경쟁 제품보다 약합니다.
  3. 홍보가 제대로 되지 않아 모르고, 나중에 온 사람에게 추월당했습니다.
  4. 만든 것에 실제 수요가 없습니다. 예를 들어 pool, 어떤 사람들은 go에서 channel로 시뮬레이션하면 간단해서 복잡한 pool이 필요 없다고 생각합니다. 예를 들어 많은 Copy To China 프로젝트, 중국 환경에 맞지 않는 것을 발견합니다.
  5. 오픈소스 후 유지 관리하지 않고, 열정이 사라지고, 사용자 피드백에 응답하지 않아 결국 모두 떠났습니다. 많은 좀비 오픈소스 프로젝트가 이렇습니다.

그래서 저는 창업하고 싶은 엔지니어는 먼저 오픈소스부터 시작할 수 있다고 생각합니다. 오픈소스를 창업의 일종의 연습으로 삼으십시오. 구상, 개발, 홍보의 전체 과정을 한 번 경험하면 창업 과정의 핵심점을 경험할 수 있고, 자신의 장점과 단점을 평가할 수 있습니다. 결국 자신이 엔지니어로, 개발 시간은 스스로 통제할 수 있고, 대상 사용자도 엔지니어이며, 해결해야 할 문제는 자신이 익숙한 분야이고, 전파해야 할 커뮤니티도 자신이 익숙한 커뮤니티입니다. 이런 천시지리인화의 상황에서 프로젝트를 해도 어려움을 겪는다면, 자신이 익숙하지 않은 분야, 익숙하지 않은 사용자, 익숙하지 않은 커뮤니티로 바뀌면 어려움이 얼마나 클지 상상해 보십시오.

또한 기술인 창업에 관한 한 가지 관점을 말씀드립니다. 저는 왕안석의 시 한 구절이 매우 좋다고 생각합니다. ‘춘강수난압선지(春江水暖鴨先知)’, 우리 일선에서 코드를 작성하는 엔지니어는 물에 있는 오리로, 강물 변화를 우리가 먼저 느낄 수 있습니다. 이 점에서 우위가 있습니다. 당신이 승진해서 코드를 작성하지 않고 육지로 나가면, 강물 변화를 느낄 수 없을 것입니다.

재게시 출처: 개발자 관계 »


Similar Posts

Content icon
Content