Intro
“Heroes must see to their own fame. No one else will.” —Gore Vidal, Jullian
자기 자신을 상대보다 낮춰서 상대가 알아주길 바라는 시대는 끝났다. 허세에서 비롯되는 자의식 과잉을 추구하라는 것은 아니다. 단지 15년 기준 SW 종사자가 25만 명을 바라보는 시점에, 셀프 마케팅과 셀프 프로모션은 때려야 땔 수 없는 생존 수단이 되어버린 것이다. 오픈소스는 이러한 소프트웨어 개발자에게 자신을 알릴 수 있는 통로로, 더 나아가 다양한 개발자들과 공유, 피드백, 수정하며 더 나은 제품을 만들어가는 삶의 방식이 되었다.
기업의 제품 또한 오픈소스의 매우 밀집한 관계가 있다. 네트워크 통신, 데이터베이스, 테스팅, 이미지 처리, 디버그… 대부분의 핵심 모듈에서 이미 오픈소스 라이브러리를 응용하고 있을 것이다. 개발자들은 제품 개발을 위해 오픈소스의 프로젝트를 사용할 때는 큰 걱정 없이 사용한다. 단지 막상 업무시간에 오픈소스 프로젝트를 만들어서 많은 개발자들에게 공유하려고 하지는 않는다.
“업무 시간에 오픈소스 프로젝트를 하면 스스로 눈치가 보이는 것 같아요. 개인 프로젝트인지 회사 업무인지 경계가 모호해서…”
회사 업무와 오픈소스 병행하기
회사 업무와 개인 프로젝트의 경계를 확실히 하기 위해선, 확고한 주관과 규칙이 필요하다. 아래의 몇 가지 항목들은 개인적으로 사용하는 철칙들이다.
1. 존재하는 솔루션에 시간 낭비 하지 않기
회사 제품의 기능을 구현할 때 좋은 솔루션이 이미 존재한다면, 굳이 지식을 뽐내기 위해서 시간 낭비를 하지 말라. 어차피 만들어도 개발자들이 굳이 사용하지 않을 것이다. 존재하는 솔루션을 찾기 위해서 수많은 검색과 웹 브라우징을 마쳐도 여전히 못 찾겠다면 다음 단계로 넘어갈 때이다.
구상한 방법을 하나의 모듈화된 솔루션으로 추상화시킬 수 있겠고, 유지보수, 사용성 면에서 더 뛰어나다면 그때 프로젝트를 공개해서 사람들의 의견을 수집해라.
실하게 시간 낭비하기
2. 회사에서 사용하는 오픈소스 프로젝트의 Issue 티켓들을 모두 확인하라
계속 유지되고 있는 건강한 오픈소스 프로젝트일 경우, 티켓들만 확인하더라도 일정을 파악할 수 있다. 버그 수정이나 기능의 배포 예정일이 언제인지, 누가 진행하고 있는지를 파악해서 큰 그림을 파악해야 한다. 죽은 프로젝트일 경우 과거 Maintainer에게 연락을 해서 프로젝트의 권한을 넘겨받고 싶다고 연락도 해보아라. 물론 Fork를 떠서 PR부터 넣는 것부터 시작해야 할 것이다. 티켓들을 모두 확인하고 나면, 더 나은 솔루션을 만드는 것과 기존의 것을 고쳐서 사용하는 것의 장단점들이 파악될 것이다.
3. 이해관계의 조율에 신경을 써라
모든 업무에는 마감일이 있고, 다양한 이해관계들이 엮여있다. 오픈소스를 하기 위해 다른 일정을 연장한다던가, 개인의 욕구를 먼저 충족시키기 위해서 다른 요소들을 무시하는 건 지양해야 한다. 사내에서 오픈소스를 하는 것은 최우선으로 회사의 제품을 발전시키기 위함인 것을 잊으면 안 된다. 그걸 원치 않으면 오픈소스는 개인 시간에만 하고 회사를 그만두는 것이 양측에 도움이 될 것이다.
4. 솔루션을 만들었다면, 알려라!
제품을 만들고 홍보를 하지 않으면 많은 잠재적 사용자들을 놓치는 셈이다. 오픈소스 프로젝트 또한 마찬가지이다. 다양한 사용자들이 써야 피드백도 받고, 더 좋은 API도 개발하고, 제품이 성장해나가는 것이다. 공개 깃에 올려두기만 하고 아무도 쓰질 않는다면, 복붙 코드와 다를 바가 없다.
겸손의 시대는 가라: 셀프 마케팅 시대
1. README, CONTRIBUTING, LICENSE 작성
귀찮더라도 README, CONTRIBUTING, LICENSE, 등. 마크다운 파일들을 꼭 작성해두자. 요즘은 깃허브에서 쉽게 클릭 몇 번으로 작성을 가능하게 해줘서 훨씬 편한 편이다. 특히 README 의 경우 사용자가 가장 최초에 접근하는 페이지라서, 첫인상이 시각적으로 보기 편하면 사용 수가 확연하게 차이가 난다. 또한, 마크다운으로 작성해놓을 시 다양한 사이트에서 크롤링해서 가져가기 때문에 더 다양한 유입 채널이 생기는 것이다. 프로젝트들에 라이선스가 명시되지 않아서 사용을 못 하는 경우가 많이 존재한다, 라이선스는 꼭 명시하자!
2. gh-pages 이용한 페이지 개설
Gh-pages 브랜치를 만들어서 html 페이지를 추가한 뒤 푸쉬 하게 되면
ButterKnife의 랜딩 페이지
3. 블로그 이용
개발 블로그가 있다면, 새로운 솔루션을 왜 만들게 되었고, 어떤 문제를 해결하였고, 예제 코드와 사용법 등을 설명하는 글을 쓰자. 검색에 노출되는 것은 물론이고, 사용자가 개발자의 공감대를 형성하는 과정이므로, 미래의 컨트리뷰터를 만나게 되는 몇 안 되는 수단일 수도 있다. 주의해야 할 점은, 유지 보수 시 관리 포인트가 증가하는 점이다. 깃과 블로그에서 설명하는 API가 다를 경우 많은 혼란을 줄 수 있으니 꼭 유의 해야 한다. 개인적으로 떠오르는 나쁜 예로는 SugarORM 프로젝트에서 버젼 관리와 문서 노후화이다.
너 덕에 고생 좀 했다…
4. 다양한 개발 채널 이용
개발 채널은 너무 많아서 정리하기가 힘들지만 크게 개인적으로 사용하는 것들은 아래와 같다:
a) GDGkr 채널, Facebook 생활 코딩, Twitter
휘발성이 좀 강하긴 하지만, 사용자 접근이 쉬운 채널들이다. 개인정보와 함께 노출되어서 좋아하지는 않지만, 국내에서 영향력은 확실히 있는 편.
b) Androiddev Subreddit, MaterialUp – UpLabs
Reddit 의 androidDev subreddit 은 다양한 분야의 정보 공유 채널로 이용되는데, 안드로이드의 경우 다양한 셀프 프로모션 글들이 올라온다. 건설적 피드백도 많이 주는 편이라서 애용하는 편이다. MaterialUp – UpLabs 의 경우 특성상 디자이너들이 많이 보게 되며, 클라이언트 라이브러리 위주로 많이 올라온다. 시각적으로 매력적인 샘플 앱을 작성하고 README.MD 파일에 추가 해두면, 관리자가 자체적으로 긁어간다.
c) Github issue 댓글, Android Arsenal
Android Arsenal 의 경우 안드로이드 라이브러리의 집합소 같은 곳인데, 이미지 규격, 글 길이, 등 구체적인 제한 사항들이 있어서 업로드 전에 잘 확인 해야 한다. 업로드가 끝나고, 관리자의 검수가 끝나야 페이지에서 노출이 된다.
깃허브 댓글은 해당 문제가 있는 라이브러리의 이슈 티켓에 다는 것이 좋다. 프로젝트가 더는 관리되지 않거나, 어떤 사유로 포함이 안 되었을 경우, 별도로 포팅 시켜서 공유하면 필요한 사람들이 사용하게 되는 것이다.
d) RSS 피드와 뉴스레터
본인의 블로그 RSS 피드를 활성화해놓을시, 스크랩하는 사용자들도 있기 때문에 같은 맥락에서 블로그 운영을 주기적으로 하는 것을 추천한다. 또한, 국내 개발자 블로그 및 RSS 피드를 정리하는 오픈 리포같은곳에 추가가 되어있다면, 더 많은 사용자에게 노출된다.
안드로이드의 경우 뉴스레터가 크게 두 가지가 있는데, Android Dev Digest 와 Android Weekly 이다. 두 곳 모두 투고 형식으로 글이 올라가는데, 최종 검수자가 일주일 치 투고된 글들과 라이브러리들을 종합해서 매주 발행하는 방식이다. 경쟁이 좀 있는 편이라, 안 뽑히는 경우가 많으며, 뉴스레터 특성상 트랜드가 지났을 경우에는 선정 안 되는 경우가 발생하니, 지속해서 지켜봐야 한다.
오픈소스를 하면 생기는 장점들
오픈소스 프로젝트에 참여하게 되면 개발자로서 많은 경험을 할 수 있게 된다. 수많은 회사를 거쳐서 쌓을 수 있는 축적된 노하우들을 오픈소스 프로젝트를 진행함으로써 간접적으로 체험할 수 있다.
코드 리뷰
다양한 개발자들에게서 코드 리뷰를 받을 수 있게 되며, 수많은 사고방식과 디자인 패턴 등에 노출되면서 자연스레 코드를 비판적으로 보는 실력이 는다. 다양한 언어로 자기 생각을 풀어내는 경험은 아무 회사에서 쉽게 경험하지 못하며, 다양한 실력 군의 사람들과 의사소통 하는 경험은 어느 다국적 대기업에서 경험하는 것 그 이상이다. 또한, 공개된 장소에 코드를 공유하는 만큼 더 신중하고 깊게 코드를 작성하고 공유하게 되는 습관이 생기며, 이것은 더 성숙한 개발자가 되는 과정에 필수 요소라고 생각한다.
프로젝트의 성장 과정 경험
한 회사에서 장기간 근속을 하는 경우, 기발하던 코드 뭉치들이 레거시코드가 되는 과정을 지켜보는 경험을 할 수 있겠지만, 상대적으로 경험이 부족한 개발자들은 이러한 일을 쉽게 경험하지 못한다. 오픈소스는 이러한 기술 부채가 생기는 과정, 레거시 코드가 생기는 과정 등을 보며, 어떤 방향으로 프로젝트가 변화하는지 이해할 수 있다.
오픈소.. 읍읍!
바람직한 API 설계 습관
API 의 백포팅, 함수 매개변수 설정, 상황에 적합한 패턴 판단하기, Fast Failing API, 등. 사용자 (개발자) 입장에서 설계하는 습관을 들이게 된다. 다른 개발자들이 빌드를 깨트리는 것을 방지하기 위해서 Testable 코드를 작성하는 것이 우선시 되게 된다. 결과 우선주의가 통용되는 기업 문화에서는 경험하기 힘든 것들을 자유로운 오픈소스에서는 당연시하게 되는 것이다.
결론
빠르게 변화하는 개발의 세계인만큼 오픈소스가 선택이 아닌 필수가 되는 시대가 올 것이라고 조심스레 상상해본다. 깨어있는 시간의 반을 회사에서 보내는 개발자로서, 넓은 세상의 좋은 코드들을 개인 시간에만 만져 볼 수 있다면, 얼마나 슬플까. 세상은 넓고, 좋은 프로젝트는 많다!
Contributor Covenant: 컨트리뷰터/기여자들의 행동 강령 ...
