천재태지의 세상 돌려보기

seoz.egloos.com

- About Me... - Enlightenment, EFL - 타이젠 Tizen



[오픈소스] 평범한 개발자가 리눅스 커널에 참여하게된 이야기 - 행사 후기 및 의견 ├ 오픈소스 OpenSource

이직을 하고 아직 오픈소스 컨트리뷰션 정책과 관련해 컨펌을 받지 못한 상황이라 한동안 오픈소스 컨트리뷰션을 자제하고 있었다.
몸이 너무너무 근질근질하던차 오픈소스와 관련된 반가운 세미나 소식을 접했다. 바로 "평범한 개발자가 리눅스 커널에 참여하게된 이야기[1]"였다.
강남구 대치동 오토웨이타워에 있는 구글 캠퍼스 서울[2]에서 행사가 진행됐는데, 이직 후에 서울로 출퇴근을 하다보니 이런 행사에도 비교적 편히 참가할 수 있었다.

< 행사장 전경 (발표 도중) >

<행사 개요>
시간: 5월 20일 수요일 19:30 ~ 21:30
19:30 ~ 20:20: 커널 개발을 시작하게된 경험담 발표 (김기오)
20:20 ~ 21:30: 커널 메인테이너에게 질문
장소: 구글 캠퍼스 서울 대강당 https://www.campus.co/seoul/ko/events

나도 오픈소스와 관련해서 발표를 할 때 항상 이야기하는게 "이렇게 부족한 저도 했으니 여러분들은 누구나 하실 수 있습니다"인데, 이번 행사는 이와 비슷한 맥락에서 김기오[3]님이 "저는 이런 사람인데 커널에 컨트리뷰션을 했습니다. 여러분도 하실 수 있습니다."라는 이야기를 하는 자리였다. 일단 제목부터 "평범한 개발자가"라고 하지 않았는가! 그런데 이에 대해 다른 의견을 주신 분들이 계셨다. 
< 김기오님이 평범하다는 말은 사기다 - 서주영 페이스북 담벼락 >

하지만 오픈소스 컨트리뷰션은 누구나 할 수 있다는 데에는 나도 동의한다.

김기오님의 발표가 끝나고 국내에서 커널 개발자(메인테이너 혹은 메인테이너 급)로 널리 알려진 김민찬[4]님과 김남형[5]님의 패널 토론 시간도 있었다.

행사 웹사이트[1]에 올라온 행사 소개는 다음과 같다.
<행사 소개>
안녕하세요.
저는 최근 리눅스 커널관련 업무를 시작했고 작년 처음으로 리눅스 커널에 패치를 제출하기도 하면서 LSF/MM 2015라는 리눅스 커널 개발자 회의도 참석해보게되었습니다.
그 전까지는 리눅스 커널등의 오픈소스 프로젝트에 참여해보고 싶지만 어떻게 시작해야할지 몰랐었는데 주변의 도움과 행운들이 겹쳐서 이런 경험을 하게 되었습니다. 그런 경험들을 소개하면서 누구나 제대로 준비한다면 생각보다 쉽게 오픈 소스 프로젝트에 참여할 수 있다는걸 말씀드리고 싶습니다.
또 한국인 커널 메인테이너분들을 모시고 커널에 관련해서 궁금했던 것들을 질문하고 개발자로서의 조언 등을 들을 수 있는 시작도 준비했습니다. 질문을 미리 준비하시면 더 알찬 시간을 만드실 수 있습니다.
오픈 소스 개발을 하고 있거나 하고 싶으신 분은 누구나 무료로 참석하실 수 있습니다.

발표 자료 및 영상이 공개될거라 생각하지만, 참석하지 않은 분들 및 시간이 없으신 분들, 그리고 참석은 하셨지만 정리가 된 자료 및 추가 정보가 필요하신 분들 위해, 그리고 내가 다시 보기 위해 발표를 들으며 내용을 간단히 정리해봤다. 그런데 오픈소스 이야기를 듣다보니 오덕(오픈소스 덕후)의 기운이 불끈 솟아 뜬금없이 행사장에서 오픈소스 코드 리뷰도 틈틈히 하면서 정리를 했더니 정리하다 빠뜨린 부분도 있는것 같다.

하지만 오덕의 기운을 담아 내 의견도 추가를 해서 발표 자료를 정리해본다. 참고로 나는 2010년부터 Enlightenment/EFL[6]이라는 오픈소스에 활발히 참여하고 있으며 2011년부터는 커미터로 활동[7]하고 있다. 

행사 내용은 다음 순서로 간단히 정리했다.

1. 발표자
2. 커널 개발을 시작하게된 경험담 발표 (김기오)
3. 커널 메인테이너에게 질문 (김민찬, 김남형)
4. 구글 캠퍼스 서울
5. 정리


1. 발표자

메인 발표는 LG의 김기오[3]님께서 해주셨다.
운이 좋게도 행사직전에 김기오님과 식사를 같이 하면서 이야기를 나눌 기회가 있었는데, 김기오님은 LG전자에서 TV를 만들고 계시며 업무는 그래픽스 드라이버 쪽인데 리눅스 커널 컨트리뷰션은 개인적으로 한다고 하셨다. 회사에서 하는 커널 업무가 오픈소스 컨트리뷰션으로 이어지는 분들도 계시겠지만, 아마 우리나라 개발자의 대부분은 업무가 오픈소스와 직결되지 않는 이런 상황이 아닌가 생각한다.
김기오님도 빠듯한 제품 생산일정에도 시간을 내서 컨트리뷰션을 하신 것 같았다.

< 김기오 님 발표 사진 >



2. 커널 개발을 시작하게된 경험담 발표 (김기오)


간단한 소갯말이 끝나고 김기오님의 리눅스 커널 컨트리뷰션에 대한 발표가 시작됐다. 김기오님은 장황하게 말을 하는 스타일이 아니라 차분차분히 하고 싶은 말을 하는 스타일이었는데, 그러면서도 중간중간에 유머가 섞여 있어서 발표를 하시는 동안 지루하지 않았다.

< 김기오님이 커널 개발에 대한 경험담을 발표하는 장면 >

그럼 발표 내용을 요약함과 동시에 내 생각도 간추려 보겠다.

< Why >
  • 내가 필요로해서 작업한 것이 다른 사람들에게도 필요하겠구나 생각
  • 이를 공유하는 것이 오픈소스
  • 혼자가면 빨리가지만 여럿이 가면 멀리간다 - 인도 속담
  • 코드만 공유하는게 아니라 성공/실패, 토론의 과정을 경험
  • 엄청나게 도전해야 되는 것은 아닌것 같다.
  • 저도 했으니 누구나 할 수 있다.

발표는 "왜 오픈소스 컨트리뷰션을 하기 시작했는가?"라는 이야기로 시작했다. 그 중 혼자가면 빨리 가지만 여럿이 가면 멀리간다라는 인도 속담이 머리에 남는다. 오픈소스에 딱 맞는 말인것 같다.

나 같은 경우 오픈소스를 하기 전에도 나름대로 즐겁게 개발을 많이 해봤다고 생각했지만, 오픈소스를 접하고 나서부터는 "나는 애송이였구나" 하는 생각을 할 수 밖에 없었다. 세상에는 전문가라고 불리는 사람보다 훨~씬 더 잘하는 진짜 전문가가 있고, 그들보다 또 더 잘하는 구루들이 널려있다. 그런데 각 분야의 구루들이 한데 모여있으니 그곳이 배움의 장일뿐만 아니라 내가 얼마나 한심한 존재인지 자각할 수 있는 좋은 장소가 된다. 이런 사람들이 열정적으로 커뮤니티에 참여하고 개발 방향을 토론하고 코드를 생산함으로써 장기적인 관점에서 올바른 방향으로 소프트웨어를 개발할 수 있는 환경이 조성된다.

< 오픈소스에 참여하게 된 계기 (출처: EFL 오픈소스 활용 사례 2014 [8], 서주영) >

나는 김기오님처럼 원대한 그림을 가지고 오픈소스를 시작한 것이 아니라 지극히 개인적인 이유로 시작했다. 즉, 내가 좋자고 한 것이다.
  1. 계속해서 Enlightenment/EFL 오픈소스 창시자 칼슨 하이츨러[9]에게 직접 질문을 하다보니 "메일링 리스트, IRC에 가서 질문하는게 어떻겠냐"는 답변을 받았고 (내가 귀찮았겠지...) 그 이후로 메일링 리스트, IRC를 시작했다. 그로인해 한 명에게 질문하는 것 보다 더 다양하고 빠른 답변을 들을 수 있었다. 

  2. 또한 오픈소스 버전이 올라가면서 내가 오픈소스를 수정해서 가지고 있던 코드를 다시 작성해야 하는 일이 반복됐다. 역시 칼슨 하이츨러가 "그러지 말고 그냥 네 코드를 업스트림하는 것이 어떨까? 그럼 그 고생을 안 해도 된다."라고 했다. 당시에 주변에 오픈소스 컨트리뷰션을 하는 사람이 없었고 오픈소스에 대해서도 잘 몰랐기 때문에 나는 내가 코드를 보내면 받아주는지 조차 몰랐었다.
 
이렇게 작게 시작한 오픈소스 컨트리뷰션이 시간이 지나자 결국 풍덩 빠져들고 말았다.

수년간 오픈소스에 빠져서 살다보니 오픈소스의 장단점이 눈에 보이기 시작했다. 우선 회사 입장에서, 개인 입장에서 오픈소스가 주는 잇점을 아래와 같이 요약해봤다.

< 오픈소스가 주는 장점 - 직장 (출처: EFL 오픈소스 활용 사례 2014 [8], 서주영) >

< 오픈소스가 주는 장점 - 개인 (출처: EFL 오픈소스 활용 사례 2014 [8], 서주영) >

< 우연한 기회에 LSF/MM 2015 행사 참가 >
  • The Linux Storage, Filesystem & Memory Management Summit
  • Invitation을 받으니 회사에서 보내줌
  • CMA 테스트 업무를 맡았음. 잘 안돼서 두 달동안 씨름. 이를 수정하기 위해 한번에 세 부분에 대한 패치를 보내게 됨. CMA 관련해서 LSF/MM 행사에 초대 받음. 마침 invitation이 많지 않아 참가자로 선정됨.
  • CMA 관련해서 발표하게 됨. 편하게 발표하는 자리. 토론이 이루어지는데 영어가 잘 안들려서 사람들이 하는 말이 chicken chicken chicken 이라고 들림.
  • 암몰암궁(??) 
  • 나도 할 수 있겠구나라고 생각함

김기오님은 CMA부분(뭔지는 모르겠다.)에 컨트리뷰션한 부분에 대해 인정을 받아, LSF/MM 2015 (The Linux Storage, Filesystem & Memory Management Summit)[10]에 초대를 받았다고 한다. 이렇게 기회는 뜻밖에 찾아오기도 한다. 만약 LSF/MM이라는 행사에서 발표를 한번 해보려는 목적으로 커널 컨트리뷰션에 접근했으면 꽤나 고난의 길을 걸었을 것이고 재미도 없었을 것이다.

나도 오픈소스 커미터가 되자마자 운좋게 독일에서 열리는 Cebit이라는 행사에 참석할 기회가 있었다. 거기서 다른 오픈소스 부스들 사이에 Enlightenment 커뮤니티의 부스를 차리고 홍보를 하게 된 것은 내게 좋은 경험이 되었으며 그 이후 수많은 해외 출장 기회를 얻게 되었다. 그 때  "적절한 사람에게 적절한 기회를 주는 것은 좋은 자극제가 된다."라는 것을 배웠고 그것이 리더의 자질 중 하나가 아닐까 생각했다. (정ㅅㅈ수석님 감사합니다.)

< 오픈소스 활동으로 많아진 기회 (출처: EFL 오픈소스 활용 사례 2014 [8], 서주영) >

다음은 LSF/MM 2015 행사에서 김기오님이 발표를 하시는 모습이다.

< LSF/MM 2015 행사 도중 김기오님 발표 장면 (출처: LWN [11]) >

< 영어 >
  • 영어 공부를 해야 한다.
  • Grammar in Use 강추. 2번씩 보고 동영상 강의도 꼭 보라.
  • CNN을 봐라. 미국 발음으로 또박또박 읽어주고 단어가 한정되어 있다.
  • 미드

역시 김기오님도 영어 공부에 대한 중요성을 강조하셨다.
아내분이 영어 강사여서 나름대로 노하우를 전수 받으셨다고 한다.
내 경우엔 몸으로 부딪히며 다년간의 삽질을...

< 영어에 대한 중요성을 전달 중이신 김기오님 >

내 경우 이전 직장인 삼성전자에서도 외국인들이 많아(미국, 독일, 프랑스, 베트남, 인도, 호주 등등) 업무에서 영어를 많이 쓰는 편이었고, 오픈소스를 하느라 계속 영어로 메일을 주고 받았었다. 지금 직장인 구글에서는 거의 90%의 메일이 영어로 씌여있고 회의도 대부분 영어로 이루어지기 때문에 정말 영어가 중요한 편이다. (그래서 좌절중...)

아무튼... 오픈소스를 하는데 있어 영어가 장벽이 되면 안된다. 그럼 정말 억울하지 않은가! 그래서 오픈소스를 하면서 동시에 영어도 공부하게 된 내 경험을 살려 작년 여름에 "OSS 개발자 포럼[12]"에서 주최한 "오픈소스 개발자 이야기[13]"라는 행사에서 "오픈소스와 영어[14]"라는 주제로 발표를 한 적이 있다. 관심있는 분은 아래 슬라이드쉐어 페이지를 참고하기 바란다.

< 오픈소스와 영어[14] 발표 자료 - 서주영 >

그리고 박민우 님이 "개발자와 영어 Why and How [15]"라는 주제로 발표를 하신 적이 있는데 영어 공부를 하는데 있어 좋은 팁이 많이 있으니 관심있는 분은 발표 자료[15]를 한번 보기 바란다.

< 통찰력> 
  • 할아버지 개발자
  • 거대 회사들의 경쟁과 협력
  • 몇년째 또 그거
  • 고령화
  • 어르신의 한마디
  • 커널 메모리 할당이 실패할 수 있는가
  • 당연한가 당연하지 않은가 정책 결정
  • 수십년 경력자의 통찰력
  • 역사를 아는 사람만의 통찰력
  • 통찰력이란
  • 표면 아래의 진실을 찾는 능력
  • 사물을 환히 꿰뚫어 보는 능력
  • 우리나라는 통찰력을 기르기 어려운 환경
  • 개발을 하면 할수록 소모되는 느낌
  • 문제를 해결할 때, 속을 들여다보고 고민하는 통찰력을 기를 수 없다.
  • 문화와 통찰력

다음으로는 통찰력에 대한 이야기를 했다. 이는 구루들의 대화를 한번 엿들어 보면 느낄 수 있는데, 그들은 한 마디를 해도 다양한 경험과 기반 지식 그리고 번뜩이는 아이디어를 바탕으로 말을 한다. 이는 문제의 표면적인 현상만 보고 해결책을 제시하는 것이 아니라 그 기저에 깔려 있는 핵심 원리를 이해한 상태에서 장기적인 관점 그리고 올바른 관점에서 문제를 해결하려고 하는데서 비롯된다. 김기오님도 이런 의미에서 통찰력에 대해서 중요하게 이야기를 하신 것 같다.

나는 이 통찰력이 결국 그 개발자의 가치와 몸값에 영향을 준다고 생각하는데, 문제가 발생했을 때 이를 근본적으로 해결하지 않고 빨리 빨리 문제 갯수를 줄이고 넘어가야 하는 문화에서는 이런 통찰력을 기르기 어렵다. (번아웃은 덤으로 찾아온다...) 오픈소스를 하다보면 나와 동갑이거나 위/아래로 몇 살 차이가 안 나는 친구들이 이런 통찰력을 가진 것을 보고 자주 좌절하곤 한다... (오픈소스의 단점)

< 시간을 앞당기는 방법 >
  • 분명히 시간은 쏟아야 된다.
  • 1만의 시간의 법칙
  • 현실적으로 1만 시간을 채우기 쉽지 않다
  • 이를 깰 수 있는 방법은 피드백을 받는 것이다.
  • 같은 분야를 고민하는 사람들에게 피드백을 받는 문화

시간에 대한건 내가 참 중요하게 생각하는 부분 중 하나다.
천재가 아닌 이상 무엇을 하든 많은 시간을 투자해야 전문가 반열에 오를 수 있다. 그것도 단지 시간만 채우는 것이 아니라 집중해서 몰입을 하는 경우에 말이다. 그런데 피드백을 받는 것이야 말로 이런 시간을 앞당기는 아주 좋은 방법이 아닌가 생각한다.

오픈소스를 하다보면 내가 작성한 아주 작은 코드, 나의 사소한 커밋 로그 등 다양한 분야에서 다양한 방식으로 피드백을 받는다. 이 이유 때문에 나는 "오픈소스를 하기 전의 나"와 "오픈소스를 시작한 후의 나"를 구분해서 이야기한다. 혼자 아무리 독방에서 코드를 많이 작성하더라도 잘못된 방법으로 코드를 작성하게 되면 독이 될 수 있다. 오픈소스에서는 나의 사소한 티, 습관까지도 전 세계의 모든 사람들에게 공개되기 때문에 더욱 코드를 조심히 작성하게 되고, 혹시나 운이 좋아 피드백을 받게 되면 이를 통해서 많이 배운다. 물론 이것 때문에 오픈소스 컨트리뷰션을 두려워하는 분들을 많이 봐왔다. 하지만 굳이 그럴 필요가 없다고 말해주고 싶다.

이런 이유로 나는 코드 리뷰를 할 때 시간을 들여서 꼼꼼히 하는 편이다. 그리고 그렇게 하는 것이 개발자들에게 도움이 된다는 것을 눈으로 확인했다. 성의있는 코드 리뷰만큼 개발자에게 도움이 되는 것도 없는 것 같다. 코드 리뷰를 통해서 잘~ 가르쳐 놓으면 나중에 내 시간을 절약할 수도 있게 되는 건 덤이다 :)

< 김기오님 발표 도중 행사장 사진 >

< 리눅스 커널 패치 보내기 >

리눅스 커널에 패치를 보내는 방법은 검색만 해봐도 수도 없이 많이 나온다. 김기오님은 김남형님의 블로그 포스팅 "[Linux] LKML에 patch 보내기 [16]"를 소개해주셨다. 나는 개인적으로 박성재님의 "리눅스에 패치 업로드하기 [17]"라는 글을 추천한다.

< 어느 부분을 볼 것인가 >
  • 뭐부터 시작할까?
  • 리눅스 커널은 엄청 다양한 부분으로 이루어져 있다.
  • 시작점은 다트를 던져서 찍어도 된다.
  • 요즘 인기 좋은 것은 스토리지/파일시스템

이 부분에서 재미있는 점은, "시작점은 다트를 던져서 찍어도 된다"이다. 지금 유행인 분야를 지금부터 파서 메인테이너가 되겠다고 달려들어봤자, 그 때는 다른 분야가 유행이 될거라는 말이다. 이 부분에 동의하는 편이다 ^^ 인기 좋은 분야를 따라다니면서 컨트리뷰션을 한다는 것은 결국 그 사람이 "오픈소스 컨트리뷰션 자체가 목적이 되는 상황"에 놓여 있는게 아닌가 생각한다. 즉, 컨트리뷰션을 위한 컨트리뷰션이 된다. 남들에게 어필하기엔 좋겠지만 오픈소스 커뮤니티에서 오래 활동을 하다보면 그런 패치를 보내는 사람들이 눈에 보인다. 패치는 받아 주겠지만 당연히 좋은 인상으로 남을리 없다.

만약 자신의 전문 분야가 있으면 관련 오픈소스 혹은 해당 분야를 사용하는 다른 오픈소스를 찾아보는 것도 추천한다. 특정 부분에 대해서 패치를 계속 보내는데 커뮤니티에 해당 분야 전문가가 없어서 코드 리뷰가 의미가 없어져 그 컨트리뷰터가 쉽게 커미터가 된 경우도 몇 번 봤다. 혹시 Enlightenment/EFL 프로젝트에 컨트리뷰션을 하고 싶은 분이라면 내가 작년(2014년) 4월에 발표했던 "실전! Enlightenment 오픈소스 컨트리뷰션 [30]"에 어느 부분의 패치를 보낼것인지에 대한 팁을 몇 가지 언급했으니 참고 바란다.
  - p92. 버그리포팅 시스템 활용
  - p99. 때론 특정 분야에 집중해서 컨트리뷰션, 자신만의 전문 분야를 만들자.
  - p118. 빌드 워닝 수정은 다른 사람이 흘려놓은 콩고물
  - p123. Coverity 같은 정적 분석 툴의 결과를 주목하자

그리고 웹킷(WebKit) 리뷰어이자 블링크(Blink) 커미터이신 김규영[31]님의 발표 자료 "컨트리뷰션 꺼리를 찾는 방법[32]"도 참고하면 도움이 될 것이다.

내 경우에는 다른 사람의 패치를 리뷰하다보면 그 패치와 직/간접적으로 내가 컨트리뷰션할 꺼리가 보인다. 패치 리뷰를 한번할 때 내가 다른 커밋 2~3개를 하는 경우가 종종 생겼다. 물론 남의 패치를 뺏으면 안되기 때문에 그 패치와 관련된 내용은 건드리지 않는다. 대신 패치를 보낸 사람이 잘 수정할 수 있도록 리뷰를 꼼꼼히 해준다.

< 결론 >
  • 전공을 만들자
  • 전공과 커널의 접점을 찾자
  • 작은 문제도 근본적인 접근
  • 근본 원리 분석
  • 커널만 하는 사람은 많지 않다.
  • 꼭 커널일 필요도 없다.
  • webkit, emacs, docker, wayland, android
  • 내가 쓰는 공개 프로젝트가 뭔가
  • 커널만 하고 싶을 때
  • lkml.org 리뷰
  • 키워드, 사람 이름 등으로 필터링
  • cma, ion, kdbus

위 결론과 함께 김기오님의 발표는 막을 내렸다.
결론에 언급된 항목들은 한번씩 곱씹어서 읽어보도록 하자.


3. 커널 메인테이너에게 질문 (김민찬, 김남형)

다음은 "커널 메인테이너에게 질문"이라는 세션으로 김민찬님과 김남형님이 패널로 등장하셨다. 사전에 온라인으로 질문을 취합 받아서 이를 하나씩 답변하는 형식이었는데, 사전 질문도 많았고 현장 질문도 많아 참석자들의 뜨거운 관심을 확인할 수 있었다.

< 패널로 나오신 김남형님(좌)과 김민찬님(우) >

질문: 우리나라 리눅스 커널 메인테이너는 몇 명?
(민찬) 많다. 30명?

실제로 국내 커뮤니티에서는 잘 활동하지 않지만 우리나라에 리눅스 커널 메인테이너가 많은 것으로 알고 있다. 전에 다니던 삼성전자에서도 많은 분들을 계셨다. 이 분들은 패치를 보내기만 하는 컨트리뷰터가 아니라 리뷰도 하시고 서브시스템을 관리하시는 메인테이너 분들이다.

질문: 왜 우리는 리눅스 커널을 공부 해야 하는가
(남형) 본인이 즐거워서 해야 함

질문: 리눅스 커널 소스에서 어느 부분이 가장 흥미로웠는가?
(민찬) Memory management 분야 코드가 복잡해서 즐거웠다. 나중엔 세부 코드를 보는 것 보다 큰 흐름이나 정책을 정하는 것이 더 재미있다.
(남형) Kprobes.

누가 시켜서 하든, 이력에 도움이 되어서 하든, 오픈소스 컨트리뷰션 활동은 즐거움이 없으면 꾸준히 하기 어렵다고 생각한다. 생각만큼 바로 티가 안난다. 시간을 가지고 자신의 아이덴티디를 만들어 가야 한다.
그리고 흥미로운 분야를 찾아다니는 것도 좋긴한데, 자기에게 흥미로워야지, 다른 사람에게 흥미로운건 별로 중요하지 않다고 생각한다.

질문: 오픈소스 활동이 업무와 관련이 있는지
(민찬) 처음엔 회사에 기여를 하는 것과 상관없이 원하는 부분을 컨트리뷰션할 수 있었다. 이런 활동이 쌓이다 보니 회사에 기여를 하게 되었다. 시작은 그렇지 않았는데 이제는 회사 업무와 관련이 없다고 할 수 없다. 결혼하기 전에 바짝했다. 결혼 후 퍼포먼스가 20% 하락, 첫째 아이 태어났을 때 50%하락, 지금은 회사에서 밖에 할 수 없는 상황.
(남형) 결혼은 했고 아이가 둘이 있었는데 오픈소스가 하고 싶었다. 회사를 관두고 시작했다. 초반에는 진입 장벽을 넘기 위해 시간을 투자해야 한다.

이건 내가 질문했던건데, 원래도 주로 새벽 시간을 이용해서 오픈소스 컨트리뷰션을 했지만 최근 둘째가 태어나면서 더욱 시간이 모자라진 관계로 다른 분들은 어떻게 컨트리뷰션을 하는지 궁금했다. 김민찬님과 김남형님은 정말 운이 좋은 경우로 회사(LG전자)에서 오픈소스에 전념할 수 있게 해주는 부서에 계신다. 우리나라에 이런곳이 또 있을까...

김민찬님의 코멘트가 재미있었다. "결혼하기 전에 바짝했다" 그런데 내 경우 결혼하기 얼마 전에 커미터가 됐고 커미터가 되고나서 더 일이 많아지고 바빠졌기 때문에 오픈소스 컨트리뷰션에 어려움이 많았다. 그 당시에 내린 결론은 잠을 줄이는 거였는데, 나이가 들다보니 이제는 몸이 안따라준다. 이제 새벽엔 둘째 아이 기저귀 갈아줘야 한다...

그리고 내 경우에 휴대폰으로 메일링 리스트나 IRC를 수시로 확인하는 습관이 있어서 새벽 시간 외에도 출퇴근할 때, 신호 대기 중에, 화장실에서 등등 시도때도 없이 오픈소스에 빠져있는 편이다. 요새는 이직 및 둘째 아이 출산으로 더더욱 시간이 모자라긴 하다. 참고로 아래는 나의 오픈소스 기반 생활 패턴을 나타내는 그림이다.


하지만, 결혼 후에도 또는 아이를 가진 후에도 오픈소스에 컨트리뷰션을 하고 커미터가 되는 분들을 주변에서 여러분 봐왔기 때문에, 의지가 있으면 못할건 아니라고 본다. 커미터/메인테이너들도 다 사람이다.

질문: 커널 공부 팁?
(민찬) 영어 공부에 왕도가 없는 것과 같다. 시간을 들이고 반복적으로 봐야 한다. 다양한 각도로 보고 그림도 그려보는 등. 리뷰에 참여하기. 질문하기.
(남형) 전혀 모르는 상황에서 소스를 볼 때, 그림을 그려보고 글로 써본다.

빙고! 내가 늘 하는 말과 같다.
"오픈소스를 어떻게 하면 잘해요? 개발을 어떻게 하면 잘해요? 어떻게 전문가가 될 수 있어요?" 등의 질문을 종종 받는데, 이건 영어 공부에 왕도가 없는것과 똑같다. 단, 요즘은 이런 행사를 포함해서 온라인에 오픈소스와 관련된 문서가 많아서 어느 정도 팁을 들을 수 있을것이다.

질문: 어떻게 시작하고 어느 정도 수준 학습이 되어야 하나?
(남형) 보면 볼수록 모르는게 많다. C 언어 정도를 하고 커널 컴파일할 수 있을 정도면 시작할 수 있다. 메일링 리스트에서 참고할 것.
(기오) 영어로 메일 쓰는 법 검색
(민찬) 우리나라 영어 교육은 오픈소스에 최적화 되어 있다. 말하기, 듣기가 아니라 읽기, 쓰기 능력 위주로 공부한다.

우리나라 영어 교육이 오픈소스에 최적화되어 있다는 멘트가 정말 재미있었다. 그리고 사실이다...
나도 외국인이 저 앞에 있는데 일부러 IRC로 질문을 하는 경우가 많이 있다. 이유는 많지만 가장 중요한 이유는, 대화 내용을 빠뜨리지 않고 여러번 곱씹어서 읽어볼 수 있다는 장점 때문이다.

질문: 메인테이너가 되고나서 얼마나 많은 시간을 투자하고 있는가
(민찬) 시간을 많이 투자하기 보다는 다른 시각으로 패치를 본다. 초기에는 더 많은 패치를 보내는데 집중한 반면 나중엔 안정성이나 유지보수 관점에서 보수적으로 패치를 만들게 된다.
(남형) 초기에는 패치를 보내고 리뷰를 받는데 시간 투자, 나중엔 커뮤니티에 기여를 하기 위해 다른 사람의 패치를 리뷰하기 시작

나 역시 같은 경험을 했는데, 오픈소스 컨트리뷰션 초기에는 하나라도 더 패치를 보내려고 시간을 투자한 반면에 시간이 지나면서 부터는 다른 사람이 내 코드를 보고 학습을 할 수 있다는 생각에 패치 하나를 만들어도 많은 생각을 하게 된다. 그리고 이제는 내가 직접 코드를 작성하는 시간이나 양 보다는 다른 사람들의 코드를 리뷰하는데 더 많은 시간을 투자하고 있다.

그리고 오픈소스 커미터가 "되는 것만" 생각하고 컨트리뷰션을 하시는 분이 종종 계신데, 나는 "커미터가 되고 나서가 시작"이라고 말하고 싶다. 내 경우 커미터가 되고나서 일도 꽤 많아졌고, 책임감도 생기게 됐다. 오픈소스 메인테이너/커미터로 활동하시는 다른 분들도 분명히 이와 같은 상황에 처해 있을 것 같다.

(2013년 가을로 기억하는데) 운이 좋게도 리눅스 커널 안정버전을 관리하는 그렉 크로아 하트만(Greg Kroah-Hartman [19])과 같은 테이블에서 식사를 할 기회가 있었다. (사랑해요 삼성전자 오픈소스그룹!) 그 분은 틈나는대로 휴대폰으로 메일을 확인하고 있었는데, 하루에도 수백개의 패치를 리뷰한다고 한다. 이런 분들이 패치 리뷰에 많은 시간을 쏟는 것은 어찌보면 당연해 보인다. 그런데 재미있는 것은 그렉씨는 거의 대부분의 패치를 반려(reject) 한다는 것이다. "내겐 너무 까칠한 당신" 처럼 보이겠지만 이렇게 해서 패치를 보낸 사람도 공부를 하게 되고 커뮤니티의 코드 품질도 높아지는 것이다. 사실 나도 패치를 리뷰할 때 승인(accept)하는 패치보다 반려하는 패치 수가 월등히 많은 것 같다. (미안하지만...)

< 그렉 크로아 하트만 - 2014 코리아 리눅스 포럼 >

질문: 리눅스 커널 같은 큰 오픈소스의 경우 개인적으로 꾸준하게 컨트리뷰션할 수 없는 것으로 알고 있다.
(민찬) 동의하지 않음. 대부분 개인 컨트리뷰션. 흥미를 느낀다면 꾸준하게 할 수 있을듯.
(남형) 할 수 있을 것 같다.

이 부분은 나도 들은게 있어서 이야기를 하자면,
사실 상당수의 사람들이 특정 회사 소속이 아니라 취미 생활로 돈을 받지 않고 리눅스 커널에 패치를 보내고 있다. 오차를 감안하더라도 이 숫자는 주목할만하다. 올해(2015년) 2월에 발행된 "Linux Kernel Development -  
How Fast is it Going, Who is Doing It, What Are They Doing and Who is Sponsoring the Work [20]" 보고서를 보면, 컨트리뷰션을 통해 급여를 받지 않는 자원봉사자들이 보낸 리눅스 커널 패치가 12.4%에 달하고 있으며, 이는 다른 회사 각각의 패치수보다 많다. 자세한 내용은 아래 그림을 참고하자.

< 누가 리눅스 커널에 패치를 보내는가? > 

한가지 주목할만한 점은 이렇게 돈을 받지 않고 리눅스 커널에 패치를 보내는 사람의 비중이 계속 줄어들고 있다는 점이다. 2012년에는 14.6%, 2013년에는 13.6% 였으며 최근엔 11.8%로 떨어졌다. 이 부분에 대해서 리눅스의 창시자인 리누스 토발즈(Linus Torvalds)[21]"회사에서 리눅스 커널 컨트리뷰터들을 바로바로 채용해가고 있기 때문"이라고 분석[22]했다. 이런 이유로 많은 사람들이 돈을 받지 않고서도 리눅스 커널에 패치를 보낸다.

질문: 커널에서 가장 핫한 부분은?
(민찬) 서버에서는 가상화 기술의 근간. 임베디드에서는 메모리 관리.

질문: 오픈소스에 기여하게 된 계기
(민찬) 오픈소스 커뮤니티도 커뮤니티다. 사람과 사람과의 관계. 커뮤니케이션 스킬이 중요. 토론을 하다보면 있는 문제를 해결하려는 것이 아니라 코드를 억지로 밀어넣고 싶어하는 의도가 보인다. 자세, 커뮤니케이션 능력, 스킬이 중요하다. 앞부분(부팅 프로시저)에 너무 많은 것을 쏟아부어서 정작 해야 할 것은 못한다.

질문: 커널을 한국어로?
(민찬) 운영체제?
(남형) 커널은 이해하기 어렵습니다.

질문: 리눅스 커널이 다른 개발붙야보다 재미있는 점?
(민찬) 소프트웨어로 할 수 있는 부분의 가장 밑단.

질문: 유닉스 버전 6로 공부를 하고 있는데 도움이 되나요?
(민찬) 저도 그 책 보고 있다.
(남형) 운영체제 기본 원리를 공부하는데 도움이 될 것. 큰 그림 보는데 도움이 될 것. 세부적인 사항은 많이 바뀌었을 것.
(기오) 어떻게 굴러가는지 원리 등을 중점적으로 보면 좋을 것.

이 부분에서는 김민찬님이 "사람들이 너무 앞부분에 기를 쏟아서 결국 해야할 것을 못하고 있다"라고 안타까움을 드러내셨다. 나 같아도 부팅 프로시저에 가장 먼저 관심이 가긴 할텐데, 어쨌든, 나는 석사 때 리눅스 커널 TCP/IP 스택을 분석하고 발표한 적은 있다. (응?) 생각해보니 윈도 디바이스 드라이버도 공부하고 강의한 적이 있긴하다. (지금은... 먼산...)

질문: 오픈소스 커뮤니티 온/오프라인 모임
iamroot.org
(민찬) 올해에 리눅스 커널 서밋이 열린다. 코리아 리눅스 포럼과 같이 열린다.

작년 코리아 리눅스 포럼에서 그렉 크로아 하트만[19]이 이야기했던 것으로 기억하는데, 올해 10월에 리눅스 커널 서밋 2015 행사[23]코리아 리눅스 포럼 2015[24]와 함께 서울에서 열린다고 한다. 한국 개발자들의 리눅스 기여도가 높아지고 있고, 한국 기업의 지원이 많아져서 생긴 멋진 현상이 아닌가 생각한다. 아마 많은 분들이 노력을 했을거다. 관심있는 분들은 참석을 하면 좋겠다. (초대권을 부탁합니다... 굽신굽신...)

운이 좋게도 코리아 리눅스 포럼 1회(2012년) 부터 작년까지 모두 참석했는데, 후기는 2012년 행사 만 두 개 올렸다. (쓰다만 후기만 몇 개인지... 게을러서 원 ㅡㅜ) 혹시 관심있는 분들은 아래 글을 참고하기 바란다.


질문: 버전 업그레이드와 함께 주도적인 혁신의 방향성은 누가 결정하는가? 리더십 포지션에 있는 한국인들?
(민찬) 개인 역량이다. 허태준님 정도가 리더십 포지션에 있다.
(남형) 다른 사람과 비교를 하면 항상 비참해진다. 커널 개발을 시작하게 된 계기가 허태준님의 경험담 강의.

당연한 말이지만 주도적인 혁신의 방향성은 주로 커뮤니티를 리딩하는 사람들이 한다. 이런 리더가 되는 것이 중요하다. 그리고 이런 리더를 많이 보유할수록 회사에 도움이 된다. 그래서 오픈소스 리더를 영입/양성하는 회사가 늘고 있다.

여기에 언급된 허태준님은 참 대단한 분이다. 리눅스 커널 패치 숫자 면에서도 상위권에 랭크되어 있다. 그리고 최근 화두가 되고 있는 리눅스 커널 cgroup의 메인테이너 이시기도 하다. 미국에 거주하고 계시며 행사가 있으면 종종 한국에 오신다. 참고로 작년 코리아 리눅스 포럼에서도 cgroup에 대해서 발표를 하셨고 작년 삼성오픈소스컨퍼런스(OSCON)에서도 키노트를 하셨다.

< 허태준님 cgroup 발표 장면 - 코리아 리눅스 포럼 2014 >

한국 리눅스의 메카인 KLDP[25]에 가면 한국 오픈소스 커미터 목록 [26] 위키 페이지가 있다. 누가 내 이름을 추가해줬는지는 모르겠지만(또다른 나의 자아가? -_-a) 내 이름도 있다. (고마우신 분이다.) 물론 누락된 분들도 있는것 같긴 한데, 이렇게 위키 페이지에 정리가 될정도로 한국인 오픈소스 커미터의 수가 많지 않다.
 
< 패널 질문/답변 모습 >

질문: 커뮤니티의 방향과 회사의 방향이 다른 경우?
(민찬) 제품에 들어가는 코드의 경우는 어쩔수 없이 임시적으로 코드를 넣어야 하는 경우가 생긴다. 오픈소스에는 올바로 수정을 해서 넣는다.

이 질문에 대해서는 참 할 말이 많긴하다. 고해성사를 하는 기분이다.

삼성전자에 다닐 때는 오픈소스를 이용해 제품도 만들고 플랫폼도 만들고 동시에 오픈소스에 컨트리뷰션도 했다. 회사의 방향이 오픈소스 커뮤니티의 방향과 일치한 횟수보다 일치하지 않은 횟수가 더 많았다.
대부분의 경우에 오픈소스의 방향성이 옳바르기 때문에,
  첫째도 회사 사람들을 설득
  둘째도 회사 사람들을 설득
  셋째도 회사 사람들을 설득
해야 하지만, 제품의 경우 출시일이 정해져 있고 뭐든 빨리 해야 하기 때문에 그게 쉽지 않다.

이 경우 흔히 빠지기 쉬운 유혹이 바로 "제품에는 일단 넣고 오픈소스에 컨트리뷰션하지 않는 것"이다. 이 유혹에 빠지는 수많은 분들을 봐왔지만, 시간이 조금만 지나도 이 실수가 부메랑이 되어 돌아온다. 나도 이 유혹에 빠져봤으니 경험을 공유하자면...

  - 조금만 지나도 관리할 수 없는 코드가 됨
  - 논리적인 오류를 포함할 가능성이 많음
  - 3rd 파티에 API를 공지했는데, 알고보니 말도 안 되는 API 였음
  - 오픈소스 업데이트를 따라가려면 코드 차이 때문에 다리가 찢어짐 
  - "이거 누가 짠 코드야?"라는 욕을 먹게 됨
  - 기타 등등

그래서 나는 수많은 욕을 먹으면서도 올바른 방향으로 코드를 넣어야 한다고 고집을 부렸다. (이 때 욕을 많이 먹어서 난 수명 연장의 꿈을 이뤘다.) 이 과정에서 갈등이 생기기도 하고 때로는 감정 싸움으로 번지기도 하기 때문에 소통을 잘 해야 한다. (실패를 많이 해본 1인) 결국 밤을 새서라도 올바른 코드를 만들고 이를 가능한 일반화해서 회사의 방향을 수용하려고 노력했다. 때로는 오픈소스 진영을 설득해야 하는 일도 발생한다. 그렇기 때문에 회사에서는 영향력이 있는 오픈소스 리더가 더더욱 필요하다.

물론 제품 출시 직전에는 어쩔수 없이 오픈소스의 방향과 다른 코드가 들어갈 수 밖에 없었는데 ("이건 꼼수 코드이고 나중에 지워야 한다"와 같은 고해성사를 담은 주석과 함께), 이 경우엔 외부 개발자나 제 3자에게 영향을 주지 않고 추후에 올바르게 변경이 가능하도록 내부적으로만 작업을 하도록 노력했다.

질문: 커널 개발할 때 어떻게 테스트를 하고 검증을 하는지?
(남형) 많은 경우 테스트 케이스를 통해서 검증.
(기오) LTP라는 프로젝트 참고할 것.

이번 발표에서 처음 들은건데 Linux Test Project (LTP) [27]라는게 있다. 리눅스 커널을 개발하는 분들은 짚고 넘어가야 할 프로젝트로 보인다.

질문: 준수해야 하는 코딩 스타일. 이것 만큼은 알아야 하는 코딩 스타일.
(남형) 문서화되어 있다. 스크립트가 있다. (scripts/checkpatch.pl)
(민찬) 코드가 하는 일을 주석으로 달지 말고 왜 그 코드가 필요한지를 주석으로 달 것. 패치를 보낼 때 코딩보다 설명이 더 중요하다.
(기오) 이유를 기술하는 것이 어렵다.

리눅스 커널의 경우 코딩 스타일을 검사해주는 checkpatch.pl [28]이라는 공식 펄 스크립트가 있다. 이 스크립트를 이용해서 코딩 스타일만 고치는 패치를 보내는 분도 있다고 들었는데, 어느 정도는 괜찮지만 그런식으로 패치 갯수를 늘리는건 결국 본인에게 도움이 안된다.

내가 활동하는 Enlightenment 커뮤니티에서는 더이상 코딩 스타일만 교정하는 패치를 받지 않는다. 가능하면 처음부터 코딩 스타일을 지켜서 패치를 보내고, 만약 기존 코드를 수정해야 하는데 코딩 스타일이 잘못되어 있다면 이 경우 코딩 스타일을 수정하는 별도 커밋을 허락한다. 기존 코드의 코딩 스타일을 바꾸는데 방어적인 이유는 이런 커밋이 커밋 로그를 어지럽히기 때문이다. 논리적으로는 변경된 내용이 없는데 커밋 로그에는 최신 변경사항으로 남기 때문에 로그를 추적할 때 방해물이 되기 십상이다.

그리고 공동 개발을 할 때는 코딩 스타일을 지키는 것이 필수이기 때문에, 내가 코드 리뷰를 할 때는 코딩 스타일이 틀린 패치는 내용도 안보고 무조건 반려처리한다.

질문: 문서 번역을 하고 있다.
(민찬) 저도 문서 번역이 첫번째 패치였다. 제가 문서 메인테이너도 하고 있으니 저에게 패치를 보내달라.

김민찬님이 문서 메인테이너도 하고 있다고 하시니 혹시 문서 번역에 관심있으신 분은 김민찬님에게 패치를 보내면 되겠다.


4. 구글 캠퍼스 서울

구글러이면서도 개인 사정상 처음으로 구글 캠퍼스 서울 [2]에 가봤다. 요즘 다양한 행사가 이 곳에서 열리는 모양인데, 관심있는 분들의 많은 참여를 바란다.
그런데 이번 행사에서만 그랬는지 모르겠지만, 의자를 옮기는 것, 참가자 접수하는 것 부터 해서 AtoZ 모두 행사를 진행하는 사람이 처리를 해야 한다. 말그대로 "장소만 제공"해주는 것 같았다. 혹시 이 곳에서 행사를 계획하고 있는 분이라면 참고 하기 바란다.

< 구글 캠퍼스 서울 입구 >


< 명찰도 참가자가 스스로 작성했다 >


5. 정리

"리눅스 커널"과 "오픈소스"라는 두 단어가 시너지를 내 정말 많은 분들이 참석했다. 내가 행사 진행자는 아니지만 이런 행사를 통해서 많은 분들이 오픈소스에 관심도 가지고 리눅스 커널을 비롯한 오픈소스에 컨트리뷰션을 했으면 하는 바람이다.

오픈소스 컨트리뷰션은 우리나라 개발자 실력이라면 누구나 할 수 있다. 단, 영어는 조금 더 신경쓰자. 작년에 내가 참 좋아하는 친구 세드릭 바일[29]과 식사를 같이할 기회가 있었는데 그 때 세드릭 바일이 이런 이야기를 했다.

"한국 개발자 실력은 세계에 내놓아도 평균 이상인데 영어 때문에 수줍음이 많아 실력을 충분히 드러내지 못한다."

세드릭은 한국에서 몇 년간 살면서 일을 해봤기 때문에 한국 개발자를 바로 옆에서 지켜본 경험이 있다. 그의 생각으로는 한국 개발자의 실력이 결코 낮지 않다는 것이다. 결국 기승전영어가 됐지만 아무튼 동감하는 말이다. 내 경우엔 어디 내놓기 부끄러울 정도의 어줍짢은 영어 실력으로도 자신감 하나 만으로 동료들보다 많은 기회를 얻을 수 있었다. 결코 부끄러워하지 말자!

< 세드릭 바일과 샌프란시스코에서 식사 중에 나눈 이야기 >

행사가 끝나고 패널 김민찬님과 사진을 찍었다. 그리고 여러 분들이 내게 다가와 인사를 해주셨다. 내가 항상 하는 말이 있는데, "컨퍼런스에서 얻을 수 있는 가장 큰 소득은 발표자와 안면을 트는 것"이다. 안면을 트라는게 그냥 사진 한 장 찍고 마는 것이 아니라 나중에 기회가 있을 때 질문을 해보기도 하고 어떻게 사는지 소식도 전하는 소통의 창을 열어놓으라는 뜻이다. 그래도 한번 얼굴본 사람에게 더 친절하지 않겠는가. 김민찬님과는 꼭 리눅스 커널 뿐만 아니라 오픈소스와 관련해서도 이야기를 나눌 기회가 생길것 같다.

< 패널 김민찬[4]님과 함께 >

그리고 행사가 끝난 뒤 마지막까지 남은 몇몇 분들에게 기념품으로 블록 달력을 선물해줬다. (진솔아 대신 받아줘서 고맙다 ㅎ) 기구한 블록의 운명... 지금은 첫째 아이 장난감으로 사용되는 중이다. 아무튼 사랑해요 구글!

앞으로도 이런 행사가 많았으면 하는 바람이고, 행사가 있으면 잊지 말고 나도 초대해줬으면 좋겠다 ^^
마지막으로 이 글이 읽으신 분들에게 조금이나마 도움이 되었기를 바란다.

[1] 행사 웹사이트 http://onoffmix.com/event/45512
[2] 구글 캠퍼스 서울 https://www.campus.co/seoul/ko/events
[6] Enlightenment/EFL https://www.enlightenment.org/
[7] Enlightenment/EFL 커미터가 됨 http://seoz.egloos.com/3581937
[8] EFL 오픈소스 활용 사례 2014 http://www.slideshare.net/seojuyung/efl-2014
[10] LSF/MM 2015 (The Linux Storage, Filesystem & Memory Management Summit) http://events.linuxfoundation.org/events/linux-storage-filesystem-and-mm-summit/program/about
[11] LSF/MM 2015 행사에서 김기오님이 발표를 하시는 모습 https://lwn.net/Articles/636259/
[13] 오픈소스 개발자 이야기 http://onoffmix.com/event/28835
[14] 오픈소스와 영어 - 서주영 http://www.slideshare.net/seojuyung/opensource-english
[15] 개발자와 영어 Why and How - 박민우 http://www.slideshare.net/tebica/developer-english-why-and-how
[16] [Linux] LKML에 patch 보내기 http://studyfoss.egloos.com/5392934
[18] 오픈소스, 빡! 끝! - 제7회 삼성소프트웨어멤버십 기술전 - 서주영 http://www.slideshare.net/seojuyung/7-40148436
[19] 그렉 크로아 하트만 (Greg Kroah-Hartman) http://en.wikipedia.org/wiki/Greg_Kroah-Hartman
[20] Linux Kernel Development - How Fast is it Going, Who is Doing It, What Are They Doing and Who is Sponsoring the Work http://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2015
[21] 리누스 토발즈 (Linus Torvalds) http://en.wikipedia.org/wiki/Linus_Torvalds
[22] Torvalds: "People Who Start Writing Kernel Code Get Hired Really Quickly" http://linux.slashdot.org/story/15/02/18/1745246/torvalds-people-who-start-writing-kernel-code-get-hired-really-quickly
[25] KLDP http://kldp.org
[26] KLDP 한국 오픈소스 커미터 목록 https://wiki.kldp.org/wiki.php/KoreanOpenSourceCommitter
[27] Linux Test Project (LTP) https://linux-test-project.github.io/
[29] 세드릭 바일 Cedric Bail https://www.linkedin.com/pub/cedric-bail/1/73a/989
[30] 실전! Enlightenment 오픈소스 컨트리뷰션 - 서주영 http://www.slideshare.net/seojuyung/efl-contribution
[32] 컨트리뷰션 꺼리를 찾는 방법 http://www.slideshare.net/gyuyoung/how-to-discover-contribution-item


1 2 3 4 5 6 7 8 9 10 다음