GitHub in DevOps Meetup 2019
GitHub과 기업내 오픈소스 문화
사실 현시점에서 나는 개발을 하지 않기 때문에 깃헙은 개인 포트폴리오나 홈페이지 정도로 사용하고 있어서 기능 전체를 파워풀하게 쓰고있진 않다. 헌데 깃헙이란 회사 자체에 관심이 있고, 개발자들이 오픈소스에 기여하는 '문화'가 생기고 정착하는 그 과정 자체에 관심이 많이 있어서 이번 밋업에도 참석하게 됐다.
오전 오후에 제조 산업분야, 게임/닷컴 분야 두 세션으로 진행됐다.
난 오전에 진행한 제조산업분야 세션에 참석-
1) Innersource journey for the Open Source Enterprise / Christian Lewis
* GitHub Action - 11/12-13 github universe에서 신기능으로 release 예정
* Deploy, 한 yml에서 여러개(aws, azure,google cloud 등) 셋업해둘 수 있음.
* 릴리스 노트, 코멘트, 변경이력, 컴플렉스 리퀘스트 등 작성
2) 오른손으로 바꾸는 협력 개발 문화 / 손건 이사
* 한국은 개인적인 지식 생산 비율이 더 높음, 헌데 해외에서는 오픈 소스에 기여하는 비율 높음
* 이너소스의 골 : 재사용, 협업, 커뮤니티
* 오픈소스는 "이런 걸 만들어야 해요 -> 예전에 해봤는데 잘 안됐어요 -> 아 네..."와 같은 상황을 "이런 걸 만들어야 해요 -> 예전에 https://github.com/***** 해봤어요, 잘 안되긴 했지만. -> 읽고 그 다음 코멘트를 준다" 요렇게 협업 문화를 바꾼다.
* 월마트 사례) 고객이 온라인 장바구니에 넣었다면 직원 단말기에 그 물건들을 찾기 위한 최적 루트를 제공하는 AI 로직 개발 등 소프트웨어적으로 이너소스 문화를 끌어올리는 중. 다른팀에서 Order랑, Billing 시스템을 개발하고 통합하는 경우 팀 간 디펜던시가 있다면 다른팀 개발자가 PR올리고 저지하는 등, 협업하는 개발문화가 활발히 일어나고 있음
* Eli Lilly 사례) 보안 관련된 것들이 모듈 별로 따로 이루어지고 있었는데, 중앙에서 한 번에 보안업데이트가 일어나면서 효율 측면에서 좋아졌음.
- 이걸 주도했던 윗사람은 디지털 트랜스포메이션 관점에서 만족스럽다고 느꼈는데, 실무의 개발자 측면에서는 오픈소스를 찾고 어떻게 써야하는지 모르는 상황이 벌어져서 원래대로 돌아가더라고. 그래서 직원들은 기존 방식과 바뀐 방식을 혼재하여 사용하는 더 혼란스러워진 상황에서 어떻게 하면 좋을까 고민함
--> 이너소스 정착을 위한 7가지 factor가 있더라고 발표했음.
- 중앙에 협업플랫폼이 꾸려지고 협업이 이루어져야 하고, 그 안에서 개발자들이 손쉽게 필요한지를 찾을 수 있어야 하고, 플랫폼의 repository 안에서 누구를 컨택해야하는지, 어떻게 활용할 수 있는지 등이 투명해져야 구성원들이 손쉽게 접근할 수 있어야 이너소스 문화가 정착되더라는.
* IBM 사례) 코드 리스트가 없어야 하고, 그걸로 평가하지 않기, 투명한 문서화(README.md, who is owner)로 진입 장벽 낮추기, 글로벌 커뮤니티와의 교류, 단시간에 이루어질 수 없다!
* 추가 코멘트 : 한국에는 외주 개발 문화가 있다. 월마트에서 작년에 발표할 때 그랬는데, 개발자가 내부에 있어야 이너소스 문화가 더 발전할 수 있지 않을까 싶다고.
3) 왜 오픈소스 문화에 관심을 가져야 하는가?
* 오픈소스가 더 좋은 소프트웨어가 되길 바라며 기여하고...
* The cathedral and the Bazaar : 성당과 시장, 지금 오픈소스는 시장 모델. 더 많은 사람이 모여 기여할 수 있게 하는 데 초점이 맞춰져 있음.
- 보는 눈이 많으면 찾지 못할 버그는 없다, 리누스 토발즈 -> 오픈소스 핵심 모델 중 하나
- 오픈소스는 문서가 친절함. (문서가 잘 되어있지 않으면 시간 들여서 보지도 않음)
— README.md : 설치작업을, 사용방법은, 개발할거야 구성, 기여하는 방법, 이슈를 보고하는 형식(이슈를 올리고 PR 올리는 형식 등). 이걸 보면서 내 코드를 여기에 올릴지 다른데 올릴지 생각해본다. -> 더 많은 사람들이 참여할 수 있게 하는 것. 어제 쓸지 몰라 그냥 닫아버리는, 이탈을 방지하기 위함.
— 회사에서도 문서 작성함. 회사의 문서는 금방 노후함. 새로운 회사에 가면 문서를 잘 믿지 않음, 그런 전제를 깔고 문서를 보거나 문서 말고 코드를 보고 문서를 찾는 경우가 더 많음.
— 이유는 보는 눈이 적어서. VS 오픈소스는 문서를 쓰는 사람보다 보는 사람 수가 훨씬 많기 때문에 문서가 항상 최신. 아래 두 상황 중에는 2번이 훨씬 최신일 것. 즉, 오픈소스는 이런 흐름을 자연스럽게 만들어 내는 것.
(1) 1년 간 팀 멤버가 달라질지 않은 팀의 개발환경 구성 문서
(2) 3개월마다 새로운 팀원이 들어온 팀의 개발환경 구성 문서
- 다양한 사람이 다양한 환경에서 시도해보고 그 결과가 문서에 반영된다. 문서를 작성하는 건 시간과 노력이 많이 들지만, 녹슬지 않고 돌아가게 하는 것이 중요하니까 그 문서가 계속 읽혀지게 만드는 것이 오픈소스에 중요하니까.
— 계속 사람을 뽑을 수 없으니 각 조직 간 경계없이 최대한 참여할 수 있게 하기.
* 투명한 의사결정
- 비동기 커뮤니케이션을 하니 ‘자연스레’ 기록이 남고, 이는 누구나 볼 수 있는 히스토리가 됨. 동기 커뮤니케이션(전화)는 기록과 히스토리가 남지 않음.
- 채팅의 대화, 위키, 이슈, Pull Request, Commit message (커뮤니티는 슬랙을 많이 쓰지만 오픈소스는 슬랙은 잘 안씀. 초대 기반이니까)
- CI : 코드 컨벤션 검사, 유닛 테스트, 커버리지 측정(좋은 테스트인가 하는것과는 다름), 라이센스 검사 -> 좋은 테스트를 만드는지는 사람이 직접 봐야하는 부분이라 자동화가 어려움. 헌데 커버리지가 내려가게 만드는 PR은 받지 않는 경향이 있음.
- 코드리뷰 : 누군가 리뷰를 해주지 않은 코드를 반영하지 않음. Pre-commit 훅으로 코드를 올리기 전에 미리 검사하기도 함. PR을 올리고 CR이 나오기 전에 그냥 가면, 메인터너들이 나서야하니까 그 전에 검사하는 방법. 감정소모를 줄일 수 잇음.
- 배포 자동화 : 회사에서는 라이브러리나 도구같은 것이 많음. 회사에서도 역시 자동화는 중요하지만 잘 안되는 경향이 있음.
-개발-배포까지 전부 자동화해야 한다는 생각을 갖고 있음. 휴가갔을 때 누구나 핫픽스 할 수 있게 하려고. 서로 간 실수를 방지하기 위해서 링트를 하고..
- 코드리뷰는 코드 검사가 아님. 코드의 당위성에 대해 설득하는 과정. 헌데 회사에서는 먹이사슬이 있어서 의미없는 코드리뷰가 이루어지는 경향이 있음 (시니어니까 그냥 커밋하거나, 주니어는 그냥 시니어 코드에 어프로벌 눌러주기만 하는 일들이 빈번하니까) 코드리뷰는 개인이 아니라 참여자 모두가 함께 작성한 코드가 되게하여 이 코드가 왜 필요한지 서로 이해하며 소유권을 서로 나눠갖는 과정. 그 과정에서 지식이 전파되고 코드에 대한 이해도가 균등해지는 것.
- Bus factor : 팀원 중 일부가 버스에 치였을 때 프로젝트에 영향을 줄 수 있는 수. 1이면 가장 안좋은 것. 그 소스코드에 대한 주인이 1명이엇던 것. 내가 없어지고 다른 사람이 와도 잘 돌아갈 수 잇도록 버스 팩터가 높아지게 하는 과정. 다른 사람도 쉽게 참여하고 코드에 기여할 수 있어야 하고, 코드에 대한 지식 기술을 팀 내에 전파해야 하는것.
- 사내 소스도 재사용 가능함.
* 자발적인 참여로 더 적극적으로 기여하고 더 많이 배운다.
- 열정페이 형태지만, 그냥 재밌어서.
- 만드는 과정이? 결과물이? 그게 뭐든, 집에가서 무언가 즐거움을 주는 행위를 하는 시간이 누군가에겐 오픈소스에 기여하는 일인 것일 뿐. 재밌는 일도 회사일로 하면 재미없어지는 경우가 많지만 누군가는 타 프로젝트, 타 팀의 일에 관심이 있을테니 그걸 더 적극적으로 권장하면 지식도, 참여도도 올라갈 거라 생각함
—> 그렇다고 타 팀에 일주일에 1번씩 기여하세요 이러면 망함ㅋㅋㅋ 회사내 조직내 합의와 문화를 만들고자 하는 노력이 필요함. 이런 경험의 결과가 오픈소스에 많이 녹아들어있기 때문에 회사에 도입할 수 있는 요소들은 도입하려고 노력하면 좋을 것.
*질문*
1) 국내 대기업에서 이너소스를 도입해서 성공한 사례
- 가장 큰 대기업에서 깃헙 엔터프라이즈를 사용하고 있음 내부에서 모든 문서 작업, 이슈 발행 등을 굉장히 잘 쓰고 있다고.
- 문서/문서화 - 법률쪽에서도 적극 사용 중
2) 이너소스 문화에 깃헙 엔터프라이즈를 써야하는 이유?
- 다른 플랫폼에 비해 더 많은 41만 컨트리뷰터가 있다. 그들과 연결된다는 건 중요함. (-> 컨트리뷰팅 문화라는 것도 궁금함. 이건 어케 끌어올리는건가)
3) 깃헙에서 디펜던시 분석을 지원해 그래프로 보여주고, 시큐리티 결과도 보여주는게 놀라웠음. 조만간 라이센스 분석도 자동으로 하는걸 기대해도 되나?
- 그렇다, 기대해도 좋다
4) 깃헙 코리아 조직 규모는?
- 전세계에 1055명인데, 70%가 재택/원격근무함. 이 말은 한국에 있는 직원만 코리아에 서비스하는게 아니라는 뜻임. 한국을 담당하는 직원은 6명, 기술지원 조직/IT Infra로 딱 나눠져있지 않고 회사 문화도 소셜코딩임.
5) 회사에서도 리드미를 만들어도 혼자만 업뎃한다. 일이라는 업무로써의 문서화와 오픈소스의 컨트리뷰션과의 차이점일까?
- 2018년 기준으로 작성된 보고서를 보면 같은 내용의 전제가 있다. 소셜 코딩에 참여하면 왜 나대냐, 시간이 많냐 같이생각할까 하는. 처음에는 비슷한 과정을 겪는 것 같다. 헌데 지금은 붐이 일어났기 때문에 어떻게 쓰는지와 시기의 문제인 듯 하다.
6) README.md가 아무리 잘돼있어도 사내에 어떤 소스코드가 있는지 홍보/검색은 어려운 것 같다. 이에 대한 솔루션이나 사례가 있나?
- 깃헙은 서치 자체가 잘되어 있음. 깃헙 엔터프라이즈 온프라임 쓰면 키워드나 필터링 기능을 활용하면 좋겠다. 닷컴에 있는 것도 함께 찾는 기능도 있음. 사내의 온프라임 인스턴스를 상단에 띄우는 기능 활용 요.
7) 오픈소스를 만들려고 하는데 라이센스를 어케 해야할지 막막하다.
- 깃헙 가보면 Code of Conduct 에 정리 잘돼있음.
8) 10명 이내 스타텁 조직에 엔터프라이즈가 유용할까요?
- 아뇨, 프로나 팀 라이센스를 쓰세요.
9) 비개발자(디자이나 기획자 사장님)와 협업한 사례나 방법이 있나요?
- 세일즈도 Pull Request를 하고있음. 문서 버저닝도 깃헙쓰고. 이메일 alias 쓰던걸 현재는 PR을 씀.
10) 깃헙의 star의 의미는 뭘까? 최근 모 대기업 사례..
- 스타는 페이스북의 like 아님. 그 사건 때 스타를 0으로 만들어달라는 요청이 있었는데, 스타를 누른 사람에게 소유권이 있고 깃헙에게 있지 않다. 철저히 오픈소스 생태계임. 따라서 어뷰징이란 표현은 좀 세다.
11) 오픈소스 생태계에서 코드의 ‘verifying’은 어떤 아웃컴이 있나? C레벨은 보안 취약성에 대해 민감하다.
사실 과거에 LG전자에서 webOS를 처음 오픈소스로 공개한다고 했을 때 이런 생각을 했었던걸 적어둔게 있어서 여기 기록해둠.
--
오픈소스가 플랫폼이 되는 과정
새로운 기술 -> 개발자들 사이에 확산 -> 시간이 지나면서 일반인들 관심도 높아짐
* 새로운 기술이 나오면 최초 시점에는 일반인의 관심 없음. 일반인이 수용할 수 있는 범위에 그 기술이 필요치 않으니까.
* 그런데 기업에서는 새로운 기술을 넣은 제품을 팔고싶어 함. "세계 최초!" 이렇게.
* 허나 신기술 개발-사용자가 받아들임 사이에는 시간이 필요함. 그 사이 시간이 개발자들에 의해 규모가 커져 확산되는 것이라고 볼 수 있음 => 플랫폼
* 즉, 이런 시나리오로 가려면 개발자들이 모여들 수 있는 신기술이어야 하고, 그게 모여 궁극적으로 서비스/컨텐츠 플랫폼으로 연결되어야 함.
질문)
1. 그렇다면 webOS는 외부 개발자들이 달려들만큼 흥미로운 기술인가?
=> 현 시점에서는 아님. 미국에서도 webOS 개발자 안뽑을 정도로 webOS와 그 기술에 관심 없음. 외부 개발자들이 당연히 모여들 것이라는 전제를 넣으려면 그들이 모일만한 이유가 필요함.
2. webOS의 비즈니스 모델이 무엇인가? => LG에서 4-5년 양산하면서 쌓인 기술은 영상, 이미지 등 큰 디스플레이에 특화된 기술. 그럼 타겟 제품은 TV인가? 안드로이드는 애초에 폰에서 시작.
3. 만약 디스플레이 특화 제품에 대해 오픈소스라고 하면, 다시 질문 1로 넘어감. webOS가 개발자들이 흥미를 가질만한 OS인가?
4. 그렇다면 webOS에서 개발자들의 흥미를 유발 시킬 요인은 뭐가 있을까? (chip dependency 떨어지고, 유연성 큰 것은 B2B에 좋은 이유로 보임)
--
