2015년 5월 26일 (화) 공개SW개발자센터의 5월 월간세미나에서

"오픈소스 소프트웨어 진짜 해보니" 라는 주제로 오픈 프론티어 개발자 분들과 토론을 했습니다. 너무나 많은 이야기들이 있었지만, 아래 글은 숭실대학교 컴퓨터공학부 1학년 양희찬 학생이 자원봉사로 정리해주신 글을 약간 편집한 내용입니다.

(여러 발언이 있었지만, 제가 한 이야기에는 제 이름이 붙어있고, 개발자분들의 이야기에는 이름 없이 '-' 로 시작합니다. 제 이야기에 집중하지 않으시면 좋겠습니다.)
--
   
(이민석) 발제 : 오픈소스의 동력은 재미와 PRIDE이다. 오픈소스로 프로젝트를 운영하면 회사입장에서 다양한 요구에 효과적으로 대응할 수 있다. 문화로서 오픈소스는 기여와 공유, 다양성을 바탕으로 발전한다.

오늘 논의할 내용은 정말로 (뼈속까지) 오픈인가? 비지니스 패러다임으로 적합한가? 문화로써 인식이 되느냐? 본인에게 재미와 자부심을 주는가? 돈이 될 것 같은가? 이다.
이전에 오픈소스 개발자로 선수가 되려면 열정, 진정성은 물론, 영어, 실력, 자세, 시간 등이 필요하다고 했다. 정말 그런가?

그리고, 정부가 세금으로 도와주는 방법, 커뮤니티 외부의 사람들, 특히 사업하는 분들이 어떻게 도와줄 수 있는지에 관한 의견들도 듣고 싶다.

(이민석 주 - 이렇게 순서대로 이야기하려고 했는데 실제 토론은 여기저기 왔다갔다 하면서 이루어졌습니다. 뭐 방송도 아니고 짜고 치는 것도 아니므로, 그냥 나온 이야기들을 거의 그대로 순서대로 옮깁니다. 생뚱 맞은 발언이 있다해도, 좀 생략하고, 편집 과정에서 순서를 적극적으로 바꾸지 않았기 때문에 그렇다는 점을 이해해주시면 감사하겠습니다. 또 괄호 안의 글은, 발언의 맥락을 제가 써 넣은 것입니다.)

- (우선, 발제 내용에 대한 반론) 왜 개발자가 선수에 반열에 올라야 하는지 이유를 제시 할 필요가 있다. 왜 당연하게 선수가 되어야하는가? (꼭 그럴 필요가 없다는 취지). 영어와 같은 장벽 또한 각자의 상황에 따라서 장벽이 될 수도 그렇지 않을수도 있다. 일반화하면 안된다. 실력이 안되면 내놓을 수 조차 없는 상황에서 오픈소스가 비지니스가 안된다는 것을 이제 모두가 안다. 문화적 현상이라는 것도 말도 안된다. 오픈소스의 핵심은 지속가능한가 보상이 있느냐이다. 지속가능한 힘은 보상에서 나온다.

(이민석) 정말 오픈하고 있나? Daily snapshot 이 공개되어야 한다. 의사 결정과정도 공개되어있는가?
   
- 피드백을 받아서 최종 결정자가 결정을 하고 있다.

- 상황이 다른데 과연 모든 것을 오픈해야 하는가?

(이민석) 학생들은 여러분처럼 오픈소스 프로젝트를 진행하는 사람들을 바라보고 따라간다. 그렇기 때문에 여러분이 홍보를 잘 해주셔야 한다.

- 과거에는 오픈소스 운동과 같은 생각에서 시작했다. 회사 관점에서는 오픈소스는 비지니스 패러다임으로 바라보지만 개인은 그렇지 않다. 오픈스택과 같은 대형 프로젝트는 회사의 입김이 크게 미치고 있다. 한국에서는 보상이 없으면 오픈소스가 유지되기 힘들다.

- 페블을 다루고 있는데 150명 규모의 커뮤니티에 한 개인의 커밋은 먼지정도밖에 안되고 커뮤니티의 방향을 따라가는 것이 개인에게 있어서의 최선이다. 오픈소스 커뮤니티 활동을 하려면 시간이 필요하다. 우리나라에서 정말 오픈소스가 힘을 발휘하려면 생태계가 갖춰져야 한다. 페블과 같은 예를 들면 외국은 페블을 개발하면서 먹고 살고 커뮤니티 외의 사람도 기여를 하면서 다른 일을 하고 페블은 다시 커뮤니티 외부의 사람들을 파일링하면서 커뮤니티의 선순환이 돌아간다. 페블은 에뮬러이터의 소스까지 전부 오픈하는 완전한 오픈을 했고, 비지니스 패러다임이라는 이름의 진입장벽을 만든 것 같다.

- 그루터팀이 전부 미국에 가있는데 왜 그분들이 한국에 있지 않고 미국에 가야만 했느냐. 타조와 같은 서비스는 글로벌 서비스 즉 사용자가 국제적으로 있는 상황에서 사용자가 있는 미국으로 가야했다. 국내에서 NHN 등 오픈소스 프로젝트를 많이 이용하고 있는데 과연 NHN이 직접 프로젝트를 지원하는가? 그렇지 않다고 생각한다. 국내 회사들이 오픈 소스 프로젝트에 거의 기여하지는 않는다.

(이민석) 준비를 해서 짠 하고 나오는 그런 프로젝트가 아니라 정말 열려있는 프로젝트가 필요하다. 예를들어, 만약에 삼성이 타이젠을 완전히 공개한다면 참여할 것인가?

- 삼성은 개발자나 사용자를 봉으로 대우하며 프로젝트를 지속적으로 가져가지 않는다. 타이젠 같은 경우 오픈소스라고 하나 안드로이드같은 경우 안드로이드 오픈소스와 구글 안드로이드가 다른걸 모두 알고 있다.

- 구글 안드로이드 같은 경우도 다음 제품 릴리즈가 될 때까지 피드백을 거의 안 반영하며, 모든 부분이 오픈 되어 있는 것도 아니다. 타이젠 같은 경우 코드가 오픈소스로 공개가 되어 있지만 너무 빠르게 버젼업이 되고 피드백이 반영되었는지 알려주지 않는다.

- 삼성은 갤럭시의 경우 삼성 자체칩을 쓰는 것을 삼성 자체칩의 메뉴얼조차 전혀 공개하지 않는다. 하지만 퀄컴 칩셋은 적어도 개발자가 따라 갈 수 있는 정도는 공개한다.

- 많은 글로벌 프로젝트에는 이제 슬랙 등의 서비스에서 실제 코어 개발자들과 대화를 할 수 있지만, 삼성은 정말 아무것도 오픈이 되어있지 않다. 메일도 보내봤지만 답변을 받을수 없었다.

- 구글도 구글 직원의 커밋이 더 많을 정도로 외부 커뮤니티는 잘 굴러가지는 않지만 삼성은 구글보다 더 적은 자원으로 더 폐쇄적으로 운영이 되기 때문에 잘 되지 않는 것이다.

- 삼성이 오픈소스를 하지 못하는 이유는 문화나 생태계를 고려하지 않는다. 생태계에서는 미물부터 고등생물까지 (초급 개발자부터 고급 개발자까지) 모두를 고려해야 하는데 삼성은 그렇지 않다.

- 오픈소스에서 별거 아닌거라도 기여하고 따라가는 재미가 있다. 처음 시작했을때는 깃허브 문서의 오타를 수정하는거부터 시작했다. 그에 대한 피드백을 받으니 마치 자신도 생태계에 있는 느낌을 받을수 있다.

- 아주 잘나가는 프로젝트는 어느정도 수준이 있는 결과가 아니면 박대하는 분위기가 있고 중간정도의 프로젝트는 마케팅처럼 친절한 면이 있다.

- 오픈소스도 작은 것부터 서로 존중하고 배려해줘야 건강해지지 않을까

- 재미와 자부심 이외에 WTF가 추가 되어야 한다. 단순히 재미에서 출발하는것이 아니라 사회적으로 문제를 해결하는 것에서부터 시작 할 수도 있다. 제가 생각하는 오픈소스는 가치의 나눔이라고 생각한다. 자신의 지식을 나눠 또다른 지식을 생산할 수 있다. 아주 소소한 가치의 나눔도 출발점이 될 수 있다.

- 오픈소스가 자본주의가 해결하지 못한 문제를 시민에게 떠넘기는 쇼가 되고 있다. 가치의 나눔과 같은 것은 사회문제일뿐이고 오픈소스가 그저 수단일 뿐이다. 오픈소스가 일종의 영리화 사회운동이다. 일종의 시스템 오류로 인한 Exception이다.

- 우리가 정보를 접하고 지식을 얻는거는 누군가의 오픈에서 오는 것이다. 나의 정보와 지식을 나눔에 있어서 주저함이 생기는데 자본주의에서 내꺼 라는 생각에 빠져 있기때문이다. 그런 자본주의적 생각에서 우리가 벗어나야 한다. 지식도 고인물이 썩듯이 지식도 흘러가야 한다.

- 정부가 지적재산권의 보장을 제대로 해주지 않기 때문에 개발자가 보상을 얻기 힘들다. 우리가 필요한것은 이름뿐인데도 정부가 지재권의 보호를 개인에게 떠넘기면 안되고 정부가 해결해야 한다.

- 대부분의 개발자들이 소프트웨어 개발 기술로 기업에서 일하는데 실질적으로 오픈소스를 사용하는것은 개발자의 몫이다. 개발자들이 제이쿼리 같은 오픈소스를 가져다가 쓰면서 재단에 기여를 하자는 개발자는 별로 없다. 개발자도 반성이 필요하다.

(이민석) 가져다가 쓴 오픈소스에 수정하거나 개선한 내용을 다시 기여를 하는 것은 경영 관점에서는 이후에 자신들의 방향과 다르게 수정되었 때 추가로 들어가는 비용을 사전에 방지하기 위함인데 우리나라는 아직 그런 관점이 부족하다. 이것은 GPL 스타일 라이선스가 아닌 라이선스들을 많은 오픈소스 소프트웨어가 선택하는 이유이다.
 
- 오픈소스 프로젝트중에 정말 제대로 돌아가는 프로젝트는 거의 없다 대부분은 어도비의 에디터같은 예와 같이 제대로 굴러가지 않는다. 현재는 저비용으로 하이퀄리티의 프로그램을 만드는 원동력은 오픈소스인데 지금의 시스템은 그 오픈소스가 개인의 희생에 의해서 돌아가고 있다.

- 오픈소스가 굉장히 많은 기여를 함에도 불구하고 오픈소스의 개발자에 대한 충분한 보상이 이뤄지지 않고 있다. 도네이션을 받아서 오픈소스를 운영하겠다는 야심찬 계획들을 세웠지만 생활비도 제대로 대기가 힘들었다. 결국 구글에 들어가기는 했다. 구글등에 들어가는 사람들은 정말로 뛰어난 몇몇이고 그렇지 않은 사람이 훨씬 많다. 오픈소스 필드에서는 양극화가 심하다.

- 오픈소스 프로젝트에 참여함으로써 자신의 역량을 키우는 것이 나중에 자신의 가치를 높이는데 도움이 된다. 역량을 키우는 것은 오픈소스 커뮤니티의 직접적인 보상이 아닌 간접적인 보상이다. 역량을 키워서 취업을 하는것은 극소수이다 오히려 오픈소스에 참여한 이력이 문제가 되는 경우가 있다. SI 기업같은 곳에서는 오히려 꺼린다.

- 그것은 오픈소스를 하는 사람들의 성향 문제이다. 우리나라의 시장이 왜곡되어 있기 때문에 힘들다
   
(이민석)  해외에서도 오픈소스 개발자를 스카우트 하는 경우에도 결국 회사에서 원하는 그 사람의 능력을 다른 프로젝트에 투입하는 경우가 많다. 큰 프로젝트의 리더 그룹을 데려와 회사의 홍보에 쓰는 경우가 많다.

- 오픈소스 프로젝트가 몇몇 기여자의 이직에 의해서 버려진다면 그것은 문제가 있다. 어떤 소프트웨어에 기여를 할 때 유명하지 않은 프로젝트는 외부에서 기여와 실력을 보기 힘들다. 그렇지 않는다면 대형 프로젝트에 참여해야하는데 몇만 라인의 프로젝트같은 것들은 기여가 힘들다.

- 우리나라에서는 작은 기여라도 띄워줘야하는데 그런 것이 별로 없어서 문제이다.

- 구조적으로 창의적으로 할 시간이 없게 만든다. 개발자가 자부심을 가질 수 있는 정책이라도 해줘야 한다.

- 배우려는 학생들이 바라보는 오픈소스 프로젝트는 유명한 대형 프로젝트인데 소형 프로젝트는 지원도 제대로 안되고 있기 때문에 오픈소스의 현재 인식이 하나의 징검다리로 여겨지고 있다.

- 스펙으로써 소프트웨어를 접근하는 것은 긍정적인 면이 없지는 않겠지만 열정과 진정성이 결여되어 있으면 끝까지 가지 못하는 경우가 많다. 스펙이라는 관점에서 접근하면 아무런 효과가 없다. 학생들이 처음에 진입하는 의욕이 꺽이는 경우가 많다.

- 쉽게 접근하는 방법은 오픈소스를 오래 쓰다가 자연스레 버그등이 보이고 작은 기여부터 시작한다. 대단한 일이 아니라 하고 싶은대로 가볍게 시작하는게 좋다.

- 대부분은 공짜인 오픈소스를 가져다가 사용하는 이점때문에 사용하다가 자신의 필요에 의해 기여가 시작된다. 자신이 오랫동안 쓸 프로젝트같은 경우 변경등이 일어날 때마다 merge하는 귀찮음등을 해결해준다.

(이민석) 어떻게 하면 큰 프로젝트에 참여할 수 있는가?

- 프로젝트 자체에 대한 사람들의 평가에 별개로 포트폴리오 관리라는 측면에서 오픈소스가 좋기때문에 프로젝트의 사이즈는 별 문제가 되지 않는다. 큰 프로젝트는 당연히 할 일이 없다. 작은 프로젝트라도 하다보면 충분히 된다. 어떤걸 했냐가 아니라 했던 경험을 중요하게 여겨야 한다.

- 하고 싶어서 하는게 가장 좋다. 자신의 열정이 가장 오래 간다. 컨트리뷰트보다 먼저 남의껄 베끼는거부터 시작한다.

- 아주 조그만 것이라도 이름만 올라가도 뿌듯함을 느낄 것이다. 작은 리워드라도 자신의 일에 대한 보상이 필요하다. 국가 기관등등에서 그런 사이트라도 만들면 좋겠다.
 
- 기여한 내용이 평소에 보상이 오는게 아니라 취업등을 할때 자신의 능력을 보여줄 수 있는 창구가 되어 보상이 된다.

(이민석) 잘 돌아가는 오픈소스 프로젝트중에는 트위터등을 이용하여 기여자들을 자주 노출 시켜주는 등의 보상을 하고 있다.

(이민석) 우리나라에서 시작한 올챙이나 타조 등의 프로젝트, 또는 여러분이 하는 프로젝트가 사업적으로 돈이 되기 위해서 어떤 것을 해야하는 것에 대한 고민은 정부가 해야할 일은 아닌 듯하다. 만간에서 할 수 있는 것이 있다면 어떤 도움이 필요하겠는가?

- 회사들 위주로 널리 쓰이는 프로젝트들에 대한 공적 펀딩 재단이 필요하다. 가까운 일본만 해도 OSS재단에 의해 많은 지원이 이뤄지고 있다. 루비등도 그런 지원에서 탄생했다. 개발자로써 뭔가 열의가 보인다면 작은 조건만 만족해도 결과를 떠나 지원이 이뤄졌으면 좋겠다.

- 소프트웨어 뿐만이 아니라 사회적 가치를 창출해내는 조직을 지원해주는 정부조직이 필요하다. 소프트웨어는 거대 포탈에서 움직이는게 가장 필요하다. 수많은 조그마한 기업에서 일하는 개발자들이 자신의 시간을 쪼개서 기여하면 큰회사에서 데리고 가는 반면 중소기업은 손해를 보게되는 것이다.

- 개발자 집단과 비지니스 집단의 협의 과정에서 큰 관점의 차이가 있다. (사람이 하는 일이므로 사람에 대한 관점이 필요한데, 비지니스 집단들은 그렇지가 않은 것 같다)

- 작은 오픈소스 개발자들을 위하여 소스포지와 같은 이용자들이 가져다가 쓸 수 있는 브릿지가 필요하다. 또 개발자들이 자신의 영역을 넓히기 위해서 영어를 쓰는것은 보편적이지만 사용자들에게는 언어의 장벽을 없애줘야 한다. 그것을 브릿지에서 영어를 한국어로 번역하는 언어장벽을 없애는 것은 물론 반대로 한국어 프로젝트를 영어로 바꿀수 있는 것이 필요하다.

(이민석) 정부에서 리포지토리 같은 것은 만드는 것은 실패할 가능성이 높다.

(이민석) 결국은 오픈소스 프로젝트를 정부가 평가를 해서 투자하는 필여하다는 것인데 정부는 그 평가를 잘 할 수 있는 조직이 아니다. 그래서 프로젝트를 지원하는 민간 조직이 필요하다. 소프트웨어에서 개발자 개인의 다양성이 중요하다는 것을 정부는 알고 있지만 관료주의적 체계가 문제가 되고 있다. 정부는 스탠다드를 유지하는 역할만 해야한다.

- GS인증등을 받으면 조달청에서 구매가 가능한것처럼 검증된 오픈소스 마켓을 정부가 운영해서 관공서등에서 구매할 수 있게 해야한다. 국산 소프트웨어를 거래 할 수 있는 마켓을 만들고 있다.

- 정부의 지원을 몇몇 큰 그릇이 아닌 수많은 작은 그릇에 나눠줘야한다.

- 나이가 들었다고 취업하지 못하는 종류의 사람들을 모아서 기초생활수급자처럼 값싸게라도 고용해줘서 생계유지에 도움을 줘야한다.

- 우리나라에는 훌륭한 개발자들은 많지만 훌륭한 소프트웨어 경영자가 없다.

- 개발자의 정체성을 지키면서 개발 할 수 있게 해줘야 한다.

- 개발자를 보호할 장치가 필요하다. copyright를 지켜줘야 한다.

- 펀딩을 받을 수 있는 환경이 있는가부터 고민해봐야 한다.

- 네티가 성공적인 프로젝트임에도 개발자 자신의 급여 정도밖에 얻지못하고 있다.

(이민석) 많은 개발자들이 분명히 사업적인 가치가 있음에도 불구하고 사업적으로 다가가면 두려움을 느끼고 있다. 왜 인가?

- 성공의 확률과 자신이 받고 있는 급여를 저울질하기 때문이다.

- 같이 사업을 하자하는 컨택이 자주 온다. 개발자들이 월급을 가져갈수 있을정도로 토대가 마련이 되어있기에 불구하고 비지니스로 가는 순간 처음에 가졌던 오픈소스 철학이 흔들릴 수 있을 가능성 때문에 두려워한다. 경영자들이 돈을 벌기 위해서 사업을 하는 순간 오픈소스가 아닌 한 회사의 기술처럼 적용이 될 수 있다는 두려움으로 인해 사업을 하는데 주저하게 된다.

- 돈을 들고 온 투자자들이나 경영자들은 오픈소스 프로젝트의 긴 시야를 기다리지를 못한다. 경영자들은 단기평가자이기 때문에 흔들린다면 문제가 된다. 결과에 대한 조급함

- 어느 회사의 오픈소스등은 그 오픈소스에 기여하는것이 그 회사의 수익창출에 영향을 미친다고 생각하면 사람들은 참가를 하지 않는다.

- 오픈소스 개발자들이 원하는 것은 놀이인데 어떤 물건을 파는 노동으로써의 개발로 바뀌면서 동기를 잃어버린다.

- 경영자들의 욕심이 너무 크다.

- 레드햇의 컨트리뷰트를 하려고 해도 컨트리뷰터들을 보면 전부 레드햇 사람들이다. 그런것을 보면 진짜 오픈소스 프로젝트가 아니다. 회사가 개입되는 순간 오픈소스 프로젝트로써 유지되기 힘들다.

- 우리나라도 헤드헌터나 미술품 트레이더들이 많이 생기듯이 코드에 대한 큐레이션을 전담해주는 큐레이터가 필요하다.

--------

전부 다는 아니지만 여기까지가 2시간 토론이고.. 이후에 저녁 식사를 하면서 3시간 반 정도 (작은 그룹들로 나뉘어) 이야기를 더 했습니다.

실질적으로 오픈소스 개발자들이 사업적으로 가진 기대와 우려는 위 토론에 나온 내용들과 일맥 상통하고 있고, 사업가(소프트웨어를 팔아줄 분들 - 가능하면 개발자들의 꿈과 재미를 지켜주면서)들과 개발자들이 편견을 버리고, 더 많은 대화를 하면 좋겠다는 생각을 했습니다.

 *


반응형
Posted by hl1itj
,