오픈소스에 한걸음 더: 2018 오픈소스 개발자 이야기를 다녀와서
한국 마이크로소프트
지난 6월 30일 토요일, OSS 개발자 포럼의 주최로 '2018 오픈소스 개발자 이야기'라는 주제의 세미나가 한국 마이크로소프트에서 열려 참석했다. 인프라 엔지니어로 일하던 시절, 개발자로 일하기를 열망하며 퇴근후 틈틈이 웹을 공부하고 '구글은 SKY를 모른다', '오픈소스 소프트웨어 아키텍쳐'와 같은 책을 읽었었다. 그때만 해도 오픈소스에 대해 어렴풋이 알고있었는데 이런 책들을 통해, 그리고 뭔지 모르면서도 GitHub Explore를 기웃거렸던 경험을 통해 오픈소스에 대한 이해를 키워갔다. 그러면서 참 설레었다. 나도 언젠가 누군가에게 도움이 될 수 있는 소프트웨어를 만들고 싶다는 생각을 했다.
몇년이 지나 나는 지금 Frontend Engineer로 재미있게 일하고 있고, 오픈소스를 더 많이 사용하고, 더 많이 듣고 접하고 있다. 그럼에도 여전히 내가 어떻게 오픈소스에 기여할 수 있고, 오픈소스 소프트웨어를 만든다는 것은 어떤 의미이고, 이것으로 어떤 영향을 미칠 수 있는지 등 오픈소스를 아우르는 전반적인 것에 대해서는 이해가 많이 부족하다. 딱 이럴때 2018 오픈소스 개발자 이야기라는 매력적인 주제의 세미나가 Facebook을 훑던 중 눈에 들어와 바로 결제했다. 오후 1시부터 5시간이 넘는 시간동안 보고 느낀 것이 많았는데 이것에 대해서 정리해보고자 한다. 시작하기 전에, 정말.. 안타깝게도 세미나 당일 이천에서 11시에 출발해서 올라왔는데 교통이 너무 혼잡해 종민님의 발표부터 듣게되어 여기부터 후기를 작성하고자 한다.
김종민님의 'Elastic에서 Remote로 일하기'
Elastic에 대해서는 ElasticSearch를 여기저기서 많이 듣고 관련 오프라인 강의 세션도 몇번 들으면서 조금 알고있던 차였다. 종민님이 쓰신 ElasticSearch 책도 갖고있어서 종민님에 대해서도 조금 알고있었다. 제목에서 알 수 있듯이 종민님의 발표는 Elastic에서 원격으로 일하는 것의 다양한 면을 담고있었다. 언젠가 원격근무를 하고싶은 나에게 유익하고 재밌었던 시간이었다.
Elastic은 ElasticSearch이었던 사명에서 Search를 빼 현재의 이름이 되었다고 한다. 그래서 종민님의 말씀대로 구글에서 Elastic을 검색해보면 진성(?) 'Elastic' 말고도 고무줄 같은 것이 잔뜩 나온다..(피식했다) 발표를 들으며 깨달았던 것, 재밌었던 포인트들이 몇가지 있는데 이를 위주로 이야기 해야겠다.
Elastic이 돈을 버는 방법
오픈소스로 일군 회사는 대체 어떻게 수익을 내는지 궁금했었다. 소프트웨어를 파는 것은 아닐텐데 그럼 컨설팅이나 교육으로 버는 건가? 그러기엔 조금 적지 않을까? 라고 자문했었다. 알고보니 반은 맞고 반은 틀렸었다. 교육과 컨설팅이 있는 것은 맞지만 이외에도 기술지원과 유료 사용자 기능이 있었다. 기술지원은 지원하는 범위와 지원 시간에 따라서 가격이 책정되는듯 하다. Elastic에서 정기적으로 메일이 오는데 여태 자세히는 읽어보지 않았었다. 돌이켜보니 Subscription에 대한 내용과 기술지원에 대한 내용이 많았던 것 같다. 유료 사용자 기능은 뭔지 잘 모르겠지만 최근 ELK 이외에 Beats와 X-Pack 같은 전에 보지 못했던 제품군들이 눈에 띄었는데 당연히 유료 사용자라면 이런 추가적인 강력한 기능들이 제공되지 않을까 추측해보았다.
Elastic은 현재 약 800명의 직원이 있는데 Elastic의 제품을 사용하는 기업의 수에 비해 조금 적은 것은 아닌가하는 생각이 들었다. 기업의 종류와 국가도 매우 다양할텐데 직원이 그에 맞게 적절히 포진해 있는 것도 상당히 어려운 일이라고 느꼈다. 오픈소스 회사를 세워 수익을 어떻게 내는지 궁금했는데 조금 더 구체적으로 알 수 있었다.
원격으로 근무한다는 것
원격으로 근무하는 것이 어떤 것인지에 대해서 그간 여러 글들이나 세미나, Automattic에서 근무하시는 태곤님의 이야기를 통해 들었었는데 종합적인 장단점은 이런 것 같다.
우선 고정적으로 이동하는 시간이 사라지므로 시간적으로 더 여유가 있다. 이런 시간을 연단위로 계산하면 꽤 나올 것이다. 나의 경우, 하루 평균 출퇴근을 1시간으로 잡고 워킹데이를 200일로 잡으면 벌써 200시간이 나온다. 200시간이면 아주 많은 시간이다. 1시간이 넘는 경우가 대다수일 것이라 생각하면 정말 큰 장점으로 다가오지 않을까싶다. 다음으로, 개인이 가장 집중도가 높은 시간에 자율적으로 일할 수 있다. 낮이든 밤이든 본인이 가장 편한 시간에 일할 수 있다. 그리고 당연히 편하게 있을 수 있다.
그렇지만 이에 못지 않은 단점들도 존재하는데, 대표적으로 회의가 있다. 크고 작은 회의들을 Skype나 Zoom같은 툴을 이용해 진행할텐데 이게 생각보다 불편한 점들이 있다. 누군가 말을 하고 있으면 순간 interrupt 하기도 어렵고 순간순간 즉흥적으로 말하기도 어렵다. 화질 및 음질이 좋지 않을 수도 있어서 집중이 조금 어려울 수 있다. 그리고 아무래도 원격으로 근무하면 혼자 일하는 경우가 대부분이어서 회사 동료들과의 물리적이고 인간적인 소통이 결여된다. 얼굴을 보고 웃으며 이야기하기도 어렵고, 같이 식사나 맥주 한잔 하는 것도 없다.
종민님이 말하셨던 장단점도 이것과 크게 다르지 않았던 것 같다. 다만 단점에서 한가지 새로 배운 사실이 있는데, 동료들과 물리적으로 함께 일한다면 캐주얼한 대화를 가끔 하게 되는데 의외로 그것에서 배우는 점이 많다는 점이다. 생각해보니 정말 그런 경우가 많았던 것 같다. 요새 이런 이슈가 있었는데~, 이런 공부하고 있는데 이런 모임이 있더라~ 부터 시작해서 기술적인 이야기도 많이 나눴던 기억이 있다. 그러니 원격으로 일한다면 이런 부분을 놓치게 되는 셈이니 이것도 단점으로 작용하게 되는 것이다.
그리고 원격으로 일을 한다는 것은 필히 나에 대한 이해가 수반되어야 한다는 것을 느꼈다. 원격으로 일하고자 한다면 이렇게 일하는 것의 장점은 최대한 살리고 단점은 최대한 보완해야 할 것이다. 먼저 내가 혼자 대화없이 오랫동안 일을 할 수 있는지부터 알아야할 것이고, 없어진 이동시간을 어떻게 활용할 것인지, 나는 어느 시간대에 일하면 가장 능률이 좋은지, 일을 밀도있게 집중해서 단번에 끝내는 것 혹은 여유있게 천천히 하는 것 중 어떤 것이 내게 편한지 등 나 스스로에 대해 이해해야 하는 것이 많다. 그리고 동료들과의 인간적인 소통도 어떻게 보완할 것인지도 생각해봐야 한다. 참 '원격으로 근무한다는 것'이라는 짧은 한 문장에 많은 내용이 함축되어 있는 것 같다.
전에는 몰랐던 다양한 Software Engineer 직군들
Software Engineer 안에서도 다양한 직군들이 있는 것을 보고 놀랐다. Solution Architect, Developer, Infra Engineer는 알고 있었는데 Community Engineer, Support Engineer, Education Engineer라는 직군은 처음 알았다. 이름을 보고 어떤 일을 하는지 감이 오기는 했는데 그걸 알고나니까 일을 더 다양하게 할 수 있다는 것을 깨달았다. 내가 어떤 일을 잘 하고 좋아하는지 이해하고 있다면 그것에 맞춰서 이런 직군들을 선택해볼 수 있겠다는 생각을 했다. 가령, 전에는 단순히 Software Engineer라면 항상 기술을 다루고 만드는 일에만 관련이 있을 거라고 생각했는데 이제보니 나는 기술 자체를 만들고 활용하는 것보다는 이 기술을 다른 엔지니어들에게 잘 전달하고 이것으로 무얼 할 수 있는지 설명하기를 더 잘 하고 좋아한다면 Community Engineer나 Support Engineer를 하는 것이 좋을 수도 있을 것이다. 물론 아직 정확히 이 직군들이 어떻게 다른지는 잘 모른다. 전에는 단순히 알고있던 것을 이번 기회를 통해 좀더 자세히 알게되었고 나도 지금은 만들고 활용하는 것만 해왔는데 내가 잘 할 수 있는 것이 무엇인지 다시 한번 생각해봐야겠다.
변정훈님의 '오픈소스 생태계 일원으로서의 개발자'
개발자가 아니었을때 혼자 공부하면서 모르는 것을 찾아보면 변정훈님의 블로그가 매번 나와서 많이 참고하고 댓글도 달았었는데 눈앞에서 직접 뵙고나니 감회가 무척 새로웠다. 아웃사이더님이라니!
아직도 기억나는 것이, 당시에 git stash와 remote branch를 찾아보고 있었는데 사진처럼 동일한 블로그가 계속 나와 git 관련 글들은 정훈님의 블로그를 많이 참고했다.
정훈님은 오픈소스 생태계를 어떻게 바라보고 기여하는지에 대해 이야기 해주셨다. 근데 GitHub 티셔츠를 정말 좋아하시는 것 같다.
우리는 이미 오픈소스 생태계 안에서 살고있다
나는 지금껏 어떻게 하면 오픈소스 생태계에 입문할 수 있을까, 아직 부족한 게 너무 많은데 어떻게 기여할 수 있을까라고 생각해왔었다. 그런데 정훈님이 이미 우리는 모두 오픈소스 생태계 안에서 살고있다고 하는 것이 아닌가. 놀랐다. 그간 나는 오픈소스와는 관계가 아직은 먼 사람이고 어떻게 하면 발을 담을 수 있을까라고 단순하게만 생각하면서 계속 오픈소스에 관심을 두는 것을 망설였던 것 같다. 허나 이미 안에 들어와있고 이 생태계를 활용하면서 살고있다는 것을 깨닫게 되니 마음이 한결 가벼워졌다. 너무 딱딱하게 생각해왔었는데 이번을 계기로 내가 자주 사용하는 라이브러리들부터 되돌아보고 싶다는 생각을 했다. 가령, 내가 가장 많이 사용하는 API에 대한 Docs는 어떠한지, 설명이 추가되면 좋지는 않을지, 현재의 모습은 어떤 과정을 거쳐 이루게 된 것인지, 현재 가장 이슈가 많은 부분이 어느 것인지 등에 대해 먼저 살펴보면 재미있을 것 같다는 생각을 했다.
어떤 프로젝트를 하나 선택해서 시작한다기 보다는 조금씩 천천히 빠지게 되는 것
이 문장도 위 단락과 깊이 연결되어 있는 것 같다. 정훈님의 발표를 듣고 위에서와 같이 생각을 다시 해보게 되었는데 아래와 같은 흐름으로 생각이 바뀌게 되었다.
- 내가 어떻게 오픈소스에 기여할 수 있을까? 잘 모르겠다. 아직은 아닌것 같은데..
- 나중에 하게된다면 어떤 프로젝트를 선택해서 기여하면 좋을까? 잘 모르겠다.
- 그런데 이미 내가 이 생태계 안에서 살고있다고? 아 내가 이미 도움을 크게 받고 있구나. 그렇다면 내가 지금 자주 쓰고있는 것들에 무엇이 있었지?
- 아 내가 A라는 라이브러리의 B라는 API를 자주 쓰는구나. 이게 어떻게 동작하는지 한번 살펴보면 어떨까? Docs를 이렇게 보충하면 어떨까?...
전에는 무얼 하나 선택해서 시작해야 한다는 생각이 강해서 그런지 그것에서 오는 왠지 모를 압박감이 있어서 선뜻 선택하지 못했고 그래서 Docs나 코드 한번 살펴보지 않았었다. 그런데 이렇게 생각이 바뀌게 되니 정훈님의 말씀처럼 내 주위를 먼저 둘러보고 그것에 자연스럽게 관심을 갖게되어 천천히 기여하는 흐름이 훨씬 자연스럽다는 생각을 했다.
그리고 기여는 꼭 코드만으로 하는 것은 아니라는 말이 기억에 남았다. 이렇게 자연스럽게 관심을 갖고, 오탈자가 있으면 고쳐주고, 불필요한 개행이나 문법 오류가 있으면 고쳐주는 등의 문서화 그리고 이슈 리포팅 등의 다양한 활동이 모두 이 오픈소스를 더 낫게 만드는데 도움이 된다는 것을 깨달았다.
이력서를 받다보면 GitHub 활동을 꾸준히 하는 사람이 드물어서 아쉽다
위와 같은 말씀도 하셨는데 생각보다 활동하는 사람의 비중이 적어서 놀랐다. 그래도 지원하는 사람 중 절반은 되지 않을까 생각했었는데 꾸준히 활동하는 것이 중요하다는 것을 다시 한번 느꼈다. 대단한 것을 만드는 게 아니더라도 GitHub에 꾸준히 무언가를 올리며 활동을 한다는 것은 적어도 내가 무엇에 관심이 있는지, 어떤 언어 및 기술을 사용하는지, 얼마나 꾸준히 하고있는지 등에 대해 나타내는 것이니 안한다고 해를 입진 않겠지만 다른 개발자들과 교류하고 구직할 때에도 도움이 되지 않을까? Interviewer의 입장에서도 문장 뿐인 이력서만 보는 것보다는 GitHub 활동과 코드를 직접 볼 수 있다면 Interviewee에게 있어서는 더 잘 어필할 수 있는 좋은 도구가 되지 않을까한다.
송태웅님의 '해외 오픈소스 컨퍼런스 발표와 참여'
태웅님은 Linux Foundation - OSSEU17에 스피커로 참여하신 경험에 대해 이야기 해주셨는데 비록 같은 분야가 아니라서 구체적인 것은 잘 모르지만 그럼에도 느낀 것이 많았다.
꼭 Professional level이어야만 하는 것은 아니다
아직 국내 컨퍼런스에서 발표할 생각도 해보지 못했던 나로서는 해외 컨퍼런스에서 발표한다는 것은 대단하고 멀게만 느껴졌다. 태웅님의 발표에서 기억나는 것 중 하나는 이런 해외 오픈소스 서밋 및 컨퍼런스에서 스피커로 참여하는 것이 꼭 전문가 수준이어야만 하는 것은 아니라는 점이다. 여전히 스피커로 나서는 것 자체가 도전적인 과제이지만 어떤 프로젝트를 진행하면서 겪었던 문제, 이슈, 해결 및 대처 방법 등에 대한 경험 그리고 그 과정에서 느끼고 배운 것을 공유하는 자리가 될 수도 있다는 점을 알게되었다. 여기까지 생각이 미치니 틈틈이 생각하고 기록하는 습관이 중요하다는 생각이 들었다. 만약 올해 말 혹은 내년 초에 있을 서밋에 스피커로 참여하고자 한다면 무슨 프로젝트를 진행했는지, 어떤 문제점들이 있었는지, 그것을 어떻게 받아들이고 해결했는지, 무엇을 배우고 깨달았는지, 비하인드 스토리는 없었는지 등을 적어도 기억을 하고 어떤 주제로 이야기를 풀어나갈지 정리할 수 있어야하기 때문이다.
영어는 여전히 중요하다
후배들에게 영어를 매일같이 하라고 말하고 다닐만큼 직업의 종류에 상관없이 영어가 얼마나 중요한지 잘 이해하고 있었는데 태웅님처럼 해외 서밋에 스피커로 나가 영어로 자신의 경험을 전달하고 질문을 주고받으며 다른 개발자들과 잘 이야기하기 위해선 영어를 잘 해야한다는 생각을 색다른 느낌으로 다시 하게 되었다. 구글 검색에서 찾을 수 있는 좋은 글과 문서들이 대부분 영어로 되어있기 때문에 영어를 잘 하면 좋다는 말은 이제는 흔하지만 만약 내가 당장 다음달에 유럽에서 영어로 발표를 해야한다면 느낌이 어떨까? 질문도 오고 중간에 쉬면서 다른 사람들과 이야기도 해야할텐데 상상하는 것만으로도 벌써 떨린다. 물론 이것이 꼭 영어 때문이라기 보다는 발표를 한다는 점에서 떨리는 것도 있을 것이다. 이런 색다른 관점에서 생각해보니 영어는 정말.. 여전히 중요하다.
김영근님의 '파이썬, 파이콘, 파이썬소프트웨어재단'
영근님은 파이썬 커뮤니티가 파이콘 등을 통해서 교류하고 성장하는 과정에 대해서 이야기 해주셨는데 중간중간 너무 웃겨서 몇번을 웃었는지 모르겠다. 문장의 호흡이 짧은데 툭툭 개그를 치시는게 정말 웃겼다. 그러면서 표정은 또 진지하심.
건강한 커뮤니티
발표의 많은 내용이 파이썬 커뮤니티가 어떻게 사람을 대하고 그것을 통해 어떻게 성장해왔는지에 대해 다루었다. 무엇보다 감명 깊었던 것은 파이썬 커뮤니티의 정신이었다. 어떻게 사람을 대하고, newcomers를 어떻게 반기는지, 또 그들이 커뮤니티에 안착할 수 있도록 다양한 방법으로 돕고, 어떠한 차별없이 다양성을 존중하고 장려하는 문화가 정말 너무 좋았다. 이런 문화가 있는 커뮤니티라면 꼭 파이썬이 아니어도 그냥 들어가서 눌러앉고 싶은 생각이 절로 든다. 그래서 영근님의 발표를 들으며 파이썬이 갑자기 더 좋아졌다. 차별없고 다양성이 존중받는 그 어느 곳이든 모두 아름답다.
코드만이 오픈소스에 기여하는 방법은 아니다
변정훈님의 말씀과 닮은 점이 있었던 문장이다. 이미 파이썬을 사용하고 있는 것 자체가 파이썬과 파이썬 커뮤니티에 기여하고 있다는 점은 다시 한번 놀랍다. 누군가 만약 파이썬을 활발히 사용하고 있다면 다른 누군가가 모르는 것이 있을때 알려줄 수도 있고 파이썬이 보다 나은 언어가 될 수 있도록 개선안을 제시할 수도 있을 것 같다. 이외에도 커뮤니티를 알리고, 문서를 번역하고, 이슈를 리포팅하고, 문서화를 돕는 것 모두 오픈소스에 기여하는 일이라는 점이 기억에 남는다. 점점 나도 기여해보고 싶다는 생각이 강해지는 것 같다.
이문수님의 '아파치 제플린, 프로젝트 시작부터 아파치 탑레벨 프로젝트가 되기까지'
문수님은 어떻게 아파치 제플린 프로젝트를 시작했는지, 그 과정에서 어떤 일이 있었고, 어떻게 아파치 탑레벨 프로젝트가 되었는지에 대해 이야기 해주셨다. 발표 내용도 재밌었지만 말하시는 내내 웃는 인상이셔서 나도 모르게 계속 웃고 있었던 발표였다.
작게 시작하는 것
크게 성장한 많은 프로젝트들의 공통적인 특성인 것 같다. 그리고 유니콘 스타트업들의 시작에서도 비슷한 면이 있는 것 같다. 모두들 작게 시작했다는 점이다. 아래와 같은 흐름인 것 같다.
처음 어떤 자그마한 문제나 의문점에서 프로젝트를 작고 빠르게 만든다. 그리고 바로 공개한다. 운이 좋으면 크고 작은 피드백들이 오기 시작한다. 만든이는 이런 피드백을 보고 신나서 기능을 추가하고 없애고 수정하면서 더 개선된 형태로 프로젝트를 발전시킨다. 다시 피드백이 온다... 이하 사이클 반복
발표를 들어보니 아파치 제플린도 비슷했다. 하둡과 관련된 생태계에서 비어있는 부분을 발견하고 그 부분을 채우면 어떨까하는 생각에 프로젝트가 시작된다. 얼마간 놔뒀다가 다음 해에 다시 빠르게 만들고 공개한다. 얼마후 반응이 오기 시작한다. 신난다. 개선한다... 반복
신기하다. 거창하게 시작하는 것보다 작게 시작하면서 사람들에게 정말 필요했던 것을 만들고 그것이 좋은 반응을 얻으면 그때부터 성장의 길이 열리는 것 같다. 뭔가 Lean 개발 방법론과 궤를 같이 하는 것 같은 생각이 들었다.
완벽한 코드 보다는 돌아가는 코드
발표를 잘 이해하지 못한 것일 수도 있는데 아파치 제플린 프로젝트가 커져가면서 더 많은 가치를 빠르게 전달하기 위해 완벽한 코드 보다는 돌아가는 코드에 집중했다는 기억이 있다. 문수님도 이를 두고 좋지 않은 코드가 당시에 많았었다고 회상하시던 기억도 난다. 물론 그 정도가 얼마만큼을 의미하는 것인지는 알 수 없지만 적어도 완벽한 설계를 바탕으로한 코드에 집착하는 것 보다는 돌아가는 코드를 빠르게 만듦으로써 프로젝트의 성장을 우선시한다는 뉘앙스로 다가왔다. 코드의 가독성 개선이나 최적화 등의 리팩토링은 프로젝트가 어느정도 궤도에 오른 뒤 밟아나가도 된다고 받아들이면 되는 것일까? 아마 그렇지 않을까싶다. 물론 처음부터 좋은 설계 위에 좋은 코드를 쌓으면 더할나위 없이 좋겠지만 꼭 좋은 프로젝트/서비스가 항상 좋은 코드로만 시작하고, 그런 코드로만 구성되어 있지는 않으니까 말이다.
소감
이렇게 후기를 마쳤다. 이야기만 들었을 뿐인데 오픈소스에 한걸음 더 다가간 것 같다. 내가 살고 있는 세상이 생각보다 훨씬 더 오픈소스에 영향을 받고있음을 느꼈다. 이제 개발자로 일한지 14개월이 되었는데 지금은 부족하지만 연차가 늘어갈 수록 더 실력을 쌓으면서도 코드 뿐만이 아닌 여러 방면으로 오픈소스에 기여해야겠다는 다짐을 해본다. 좋은 배움과 좋은 계기가 남는 알찬 세미나였다. 이런 세미나를 기획하고 준비한 OSS 개발자 포럼과 황금같은 주말 시간을 내어 발표해주신 모든 발표자분들께 감사한 마음이 든다. 나는 오늘도 도움을 받는다. 나도 조금씩, 더욱 도움이 되는 사람이 되기를.
참고하면 좋은 링크
