“어떤 개발자가 되고 싶으세요?”

SW개발자 중에선 오픈소스란 정신을 동경하고, 그를 실천하려는 사람들도 적지 않다. 그리고 자신의 SW를 오픈소스로 공개하고, 해당 SW의 오픈소스 개발을 주도적으로 이끌어가는 사람. 그들은 ‘커미터’라 불린다.

커미터는 아파치, 리눅스 같은 유명 오픈소스 재단의 각 프로젝트를 이끄는 오픈소스 SW개발의 정점에 선 존재다. 기본적인 SW 개발능력은 물론이고, 프로젝트 발전을 원활히 이끌어가는 리더십과 깊이있으면서 포괄적인 전문지식을 갖춰야 한다. 여기에 더해 오픈소스SW에 대한 애착과 열정도 가져야 한다.

최근 국내 유명 오픈소스SW 커미터들이 한자리에 모이는 자리가 마련됐다. 지난달 29일 서울 상암동 누리꿈스퀘어에서 열린 ‘제3회 대한민국커뮤니티데이’ 중이다. 행사중 ‘오픈소스 커미터, 과연 개발자의 미래인가’란 주제로 열린 토론회 성격의 자리였다.

이 자리엔 트위터 소속 개발자로서 네티(Netty)를 개발하고, 아파치 미나 프로젝트 설립자인 이희승씨, 리눅스 시스템 프로파일링도구인 퍼프(perf) 커미터인 LG전자의 김남형씨, 오픈소스 올챙이 개발자인 조현종씨, 스마트스터디를 창업한 박현우씨, KTH에서 ‘서비스로서의 백엔드(BaaS)’를 개발하고 유저그리드 컨트리뷰터인 진성주씨가 참석했다.

토론회는 패널들이 자신의 경험을 공유하고, 오픈소스SW 커미터에 대한 나름의 의견을 밝히는 자리로 진행됐다. 결론부터 말하자면, 커미터들은 모두 공통된 메시지를 던진다. ‘두려워말고 용기를 갖고 도전하라’는 거다. 이들은 개발자로서 느끼는 성취감, 사회적인 기여 등에서 오픈소스SW 커미터의 매력을 강조했다. ■커미터가 되는 길

일단 커미터는 어떻게 될 수 있을까. 개인적으로 오픈소스SW 프로젝트를 만들어낼 수도 있고, 아파치나 리눅스 같은 기존 재단의 프로젝트에 참여해 커미터 지위를 얻을 수도 있다.

이희승씨는 “커미터가 된다는 건 더 많은 책임과 권한을 갖게 된다는 의미가 있다”라며 “적극적인 리뷰와 피드백이 가능한지, 더 많은 시간을 그 프로젝트에 할애할 수 있는지. 그런 것에 대한 동의가 있을 때 커미터가 된다”라고 밝혔다 그는 “커미터가 된다는 건 해당 프로젝트에 대한 기술적 이해 더하기, 그 프로젝트에 집중하고자 하는 마음, 이 두가지가 합쳐져 되는 거라 본다”라고 강조했다.

조현종씨는 “올챙이 같은 경우 커미터가 되고 싶다고 하면, 우리 멤버들과 친해지면 된다고 답한다”라며 “이는 쉬우면서도 어려운 얘기인데, 커뮤니티 멤버와 친하게 지내면서 버그 패치에 기여하고 실력을 보여주면서 신뢰를 쌓는 과정을 성실히 거치면 커미터가 될 수 있다”라고 말했다.

진성주씨는 “내 경우 기업에서 투자한 프로젝트 참여자로서 엄밀히 정의하면 커미터는 아니다”라며 “기업에서 진행하는 프로젝트는 기여는 할 수 있어도 커미터가 되기 힘든 구조이지만, 코드패치나 로드맵에 대한 의견 제시를 꾸준히 하면서 커미터에 준하는 권한을 갖게 되는 것도 중요할 것이라 생각한다”라고 밝혔다.

박현우씨는 “과거엔 의사소통수단이 이메일 같은 거에 한정돼 오픈소스 개발에 쉽게 접근하기 힘들었지만, 이제 기트허브(Github)를 통해 모든 커뮤니케이션이 이뤄지므로 커미터가 아니라도 참여할 방법이 얼마든지 있다”라며 “협업도구를 통해 다양한 참여를 시도해보라”고 조언했다.

김남형씨는 “리눅스 커널은 이제 특정 개발자가 커미터 권한을 갖고 중앙에 집중시키는 게 아니라. 메인테이너란 직위가 존재한다”라며 “메인테이너는 자신이 맡은 서브시스템에 대해 최종적인 승인을 하는 리뷰 권한을 보유한다”라고 말했다.

그는 이어 “메인테이너가 된다는 건 한 분야에 대해 깊이 이해하고 있다는 것으로, 자신의 이해도를 증명해야 될 수 있다”라며 “새로운 프레임워크서 새 메인테이너를 정하게 되는데, 해당분야서 자주 활동하고, 의미있는 의견을 많이 제시하고, 리뷰를 잘 해주는 사람이 후보자가 된다”라고 덧붙였다.

■왜 오픈소스를 생각하게 되는가

이날 참석한 개발자 상당수가 자신의 개발품을 오픈소스로 공개한 경험을 갖고 있었다. 그들은 왜 오픈소스를 택하게 됐을까 궁금해진다. 제품을 상용화해서 거액을 벌지도 모르는 일인데 말이다.

이희승씨는 “당시엔 깊은 생각은 없었던 것 같다”라면서도 “내가 했다는 걸 보여주고 싶어서 그러기도 했고, 오픈소스로 하게 되면서 느끼는 건 과연 나 혼자 수정하고 개발해서 상용화를 하든 비공개소스 라이브러리만 공개했든 지금만큼의 퀄리티가 나왔을까하는 점이다”라고 말했다.

그는 “오픈소스는 개발 프로세스 통해 끊임없이 피드백을 얻고, 점진적으로 개선돼 나가는 과정을 걷는다”라며 “그 과정 자체를 공개하지 않고 그 과정을 밟는다는 건 불가능하다. 공개를 제대로 하지 않았더라면 망하지 않았을까 생각한다”라고 덧붙였다.

조현종씨는 “처음 올챙이를 혼자 만들어서 갖고 있다가 회사를 관두면서 공개했다”라며 “ 이클립스를 사용하면서 빚진 마음도 있었고, 내가 만든 걸 다른 사람이 재밌게 썼으면 하는 마음도 있었다”라고 밝혔다.

그는 “IDE는 일반인 말고 개발자 쓰는 소프트웨어라, 내가 사용자 의도에 맞게 개발하고 있는지, 어떻게 고쳐야 할지 알고 싶었다”라며 “나혼자 감당하기엔 무거워 결국 오픈할 수밖에 없었다”라고 설명했다.

박현우씨는 “오픈소스하는 개발자는 좋아서 하는 사람들이다”라며 “개발을 좋아하는 개발자가 자신의 것 알리면서 사용하는 사람이 늘고, 유명해지는 게, 통장에 돈 꽂히는 것보다 더 큰 의미를 갖게 된다고 생각한다”라고 말했다. 그는 “이전에 이희승씨가 ‘나눴더니 더 큰게 돌아오더라’고 말한 적이 있는데. 그점에 더 큰 가치가 있다고 본다”라며 “돈벌겠다는 생각과 오픈소스는 맞지 않다”라고 덧붙였다.

■오픈소스도 경쟁, 규모의 경제를 얻는 방법

전세계적으로 오픈소스 프로젝트의 수는 셀 수 없을 정도로 많다. 개발자가 필요하다고 여기는 수요 판단은 유사할 수 있기 때문에 비슷한 콘셉트를 갖고 동시에 진행되는 프로젝트도 허다하다. 당연히 프로젝트 사이에 경쟁이 생긴다. 어떻게 경쟁을 뚫고 우뚝 설 수 있을까.

이희승씨는 “오픈소스 프로젝트에도 규모의 경제가 적용된다”라며 “커뮤니티가 더 큰 쪽이 양질의 기여자를 얻을 확률이 높다”라며 “초창기일수록 누군가 왔을 때 그를 잠재적인 일원으로 보고, 잘 활동할 수 있도록 신경을 많이 써주는 게 중요했다”라고 밝혔다.

그는 “참여자에게 만족을 준 다음 추천사도 받았다”라며 “내 프로젝트가 덜 유명하더라도 추천사를 모아나가다 보면, 처음 써보는 사람이 평가를 할 때 기왕이면 사이트가 이쁘고 문서화 잘 됐고, 활성화 외에 추천사 많은 것 쓰려 한다”라고 설명했다.

박현우씨는 “오픈소스에선 내가 만들려고 하는 것의 대부분이 이미 다 만들어져 있다”라며 “없는 건 필요하지 않기 때문에 없는 것이고, 세상을 깜짝 놀라게 해준다는 건 어려운 것 같다”라고 말했다.

그는 이어 “구글은 오픈소스 기트허브 코드 검색도 된다. 내가 만든 것과 남이 만든 것 찾아보면서 비교하면서. 요구사항 일치를 확인하는게 필요하다”라며 “만들고 싶은 게 있다면, 찾아보고, 있으면 참여하고. 없으면 시작하되 내가 필요한 걸 만들어 쓰는 게 오픈소스 개발의 옳은 방향이다. 열정의 지속 가능성을 담보하기 때문이다”라고 강조했다.

조현종씨는 “SNS로 알리고, 유튜브에 데모영상도 올리고, 크고 작은 공개발표 자리에도 나가려고 노력했다”라며 “소스까보기 같은 행사를 만들어 다른 사람의 참여 유도했고, 관련 프로젝트와 관련된 회사와 친밀하게 지내려 했다”라고 경험을 소개했다.

정부의 오픈소스 지원방안에 대한 의견도 나왔다.

박현우씨는 “오픈소스에 국가가 의미있는지 모르겠다”라며 “오픈소스는 그 기능과 어떤 커뮤니티의 활성화 정도, 그리고 내용만으로 평가받는 것이지 국가 주도나, 국가서 지원해주는 걸로 이뤄지는 게 아니다”라며 비판했다.

진성주씨는 “국가가 오픈소스냐 상용제품이냐 무얼 쓴다고 할 때 두가지 측면을 다 봐야 한다”라며 “무조건 오픈소스 밀어줘서 오픈소스만 쓰느냐도 아닌 것이 국가는 국민 이익을 보호해야 할 의무가 있다. 질 좋은 소프트웨어를 사용한다는 관점에서 오픈소스가 더 좋다면 그걸 택하고, 상용제품이 더 좋다면, 특정기업에만 쏠리게 않게 조율만 잘하면 써도 나쁘지 않다”라고 말했다.

■구성원간 갈등을 해결하는 방법

커미터는 여러 개발자들의 의견을 조율하는 역할도 해야 한다. 참여자들 사이에 벌어지는 논쟁을 관리하면서, 원활한 개발을 유도하는 정치력도 요구된다.