Thoughts2014.04.02 16:32

오픈소스 프로젝트는 세상에 기여하는 방법일 뿐 아니라, 자기 경력을 개발하는 데도 중요한 수단이 되고 있다. 하지만 오픈소스 프로젝트는 전세계 개발자와의 협업을 전제로 하기 때문에, 몇 가지 주의할 점이 있다. 이 사항들은 전적으로 필자의 경험에 비추어 나열하는 것에 불과하며, 다른 분들은 다르게 생각할 수도 있다. 그러니 참고만 하기 바란다. 





1. 인터페이스는 주의깊게 설계하라 


주의깊게 설계하지 않은 인터페이스는 나중에 시스템 확장을 어렵게 만든다. 단순히 개선하기 어렵다는 측면의 문제점만 있는 것은 아니다. 다른 사람들이 여러분의 소스를 받아 사용하기 시작하면, 그 소스코드의 문제점과 개선 방안을 신속히 반영하기가 점차로 어려워진다. 다른 사람들이 사용하는 코드에 대한 하위 호환성을 어떻게 보장할 것이냐의 문제 때문이다. 


그러니 오픈소스 프로젝트를 섣불리 시작하는 것은 삼가는 것이 좋다. 소스 코드가 어느 정도 안정되어, 그 개선 작업이 인터페이스나 API 규격에 미칠 영향이 적다고 여겨질 때 오픈소스로 공개하는 것이 바람직하다. 


2. 기본적인 문서는 갖춘 후에 공개하라 


소스코드가 아무리 쓸만해도 기본적인 문서가 없으면 관심을 갖는 이가 적다. 사용법, 확장법, 기본적인 예제 몇 가지 정도는 반드시 포함시키는 것이 좋다. 소스코드 패키지의 일부로 튜토리얼 문서를 넣는 것도 한 방법이다. 많은 사람의 호응을 얻는 소프트웨어가 되려면 신경써야 하는 일이 많다.


3. 많은 플랫폼에 테스트한 뒤 공개하라 


리눅스 사용자만을 위한 소프트웨어라 해도, 데비안, 우분투 등등 패키지 별로 다른 의존성을 갖게 되는 경우는 흔하다. 가능한 한 의존성이 적은 소프트웨어를 만드는 것이 최선이겠지만, 그럴 수 없을 때는 개발에 의존하는 패키지들을 정확하게 식별하고, 그 의존성을 해소하는 방법을 상세히 알려주는 것이 바람직하다. 


4. 피드백을 받을 준비를 하라 


오픈소스 프로젝트가 제 궤도에 오르면 수많은 개발자들로부터의 피드백을 받게 된다. 일일이 응대하는 것이 정신적으로 피곤한 일임은 분명하지만, 그럴만한 가치가 있는 일인 것도 사실이다. 피드백을 받기 위한 수단을 생각하고 도입하라. 구글 그룹스(google groups) 등의 온라인 포럼을 활용하면 좋다. 


5. 소스 공개 플랫폼은 신중하게 고르라


많은 사람들이 GitHub를 선호하고 있지만, 소프트웨어에 따라서는 다른 플랫폼이 더 좋을 수도 있다. 아예 독자적인 플랫폼을 꾸리는 것도 방법일 것이다. 이견이 있겠지만, 필자는 GitHub를 비롯한 Git 기반 플랫폼을 선호한다. 문제가 생길 가능성이 가장 적은 플랫폼들이기 때문이다. 



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2013.11.08 11:37

페이스북이 대용량 데이터 분석 솔루션 Presto를 오픈 소스로 공개했습니다. 대용량 데이터를 많이 분석해야 하는 Facebook 특성상 이런 솔루션이 필요했을 것으로 보이는데요. (페이스북 내부적으로 300 페타바이트 이상의 데이터가 보관되어 있다고 합니다.) 2012년부터 이 솔루션을 개발하기 시작해서 드디어 오픈 소스로 공개가 가능한 시점까지 왔습니다. https://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/10151786197628920



페이스북이 공개한 Presto 아키텍처는 위 그림과 같습니다. 글라이언트는 데이터 웨어하우스(Warehouse)에 대한 SQL 질의를 통해 데이터 분석을 시도하게 되는데, SQL 질의를 받으면 파서(Parser)와 플래너(Planner), 그리고 스케줄러(Scheduler)를 통해 최선의 질의 실행 형태를 결정하고 실행하게 되는데요. 이 과정에서 데이터에 가장 가까운 노드에 질의 수행이 맡겨지게 됩니다. 그 역할은 스케줄러가 맡는데, 질의 수행이 이루어지고 있는 전반적인 상황을 감시하게 됩니다. 데이터는 저장소에서 꺼내어져 워커(Worker)에 의해 병렬 분석 되고, 최종적으로 분석 결과가 클라이언트에게 되돌려지는 형태입니다. 


Hive나 MapReduce가 중간 결과를 다시 디스크에 쓰는 반면, Presto에서 모든 프로세싱은 메모리 상에서 이루어지고, 워커 간 파이프라인도 메모리로 구현됩니다. 따라서 불필요한 I/O가 발생하지 않기 때문에 질의 수행 시간이 줄어든다고 합니다. 


이 시스템은 Java로 구현되었는데, 개발하기 쉽고, 개발자 층이 두텁고, Java로 구현된 페이스북 내부 인프라와 연동하기 쉬워서 Java가 선택되었다고 하는군요. 질의 중 일부는 JVM 코드로 동적으로 컴파일되여, JVM에서 최적화가 가능하다고 합니다. Presto를 구현하면서 메모리 할당이나 가비지 콜렉션 과정에서 생기는 문제를 피하기 위해서 신경도 많이 썼다고 하는군요. (그 과정에서 얻은 교훈은 나중에 공개할 예정이라고 합니다. 사실 이 부분이 많이 기대되네요.) 



HDFS, Hive, HBase, Scribe같은 외부 시스템과의 연동을 위해서, 확장이 용이한 구조를 만드는 데도 신경을 썼다는군요. 위 그림은 그 구조를 밝힌 그림입니다. 


어쨌든 이런 구조를 통해 Presto는 Hive/MapReduce 시스템보다 열배 나은 성능을 달성했다고 합니다. (CPU 사용 효율, 그리고 질의 수행 시간의 측면에서 말이죠.) ANSI SQL을 대부분 지원한다는 군요. (다만 JOIN 테이블의 크기 제한 등, 몇 가지 제약조건은 잇다고 합니다.) 모든 처리 결과를 다시 테이블에 기록하는 기능은 현재로선 없답니다. (클라이언트에게 그냥 스트림 형태로 제공되기만 하는 듯.)


오픈 소스는 아래에 공개되어 있다고 하네요. 


http://prestodb.io/

https://github.com/facebook/presto



저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Extremely Agile/General2013.10.07 09:11

아마 대부분의 개발자들은 둘 중 하나일 겁니다. 오픈 소스를 쓰고 있거나, 아니면 오픈 소스를 개발하고 있거나. 물론 오픈 소스를 사용하기만 하는 개발자들이 대부분이겠죠. 오픈 소스 소프트웨어 개발에 직접 관여하는 사람은 드뭅니다. 


그런데 최근 개발자들 사이에서는, 오픈 소스 프로젝트에 참여하는 것이 능력치를 올리는 좋은 방법일 뿐 아니라, 좋은 직장을 구하는 방법이 될 수 있다는 것에 공감대가 형성되고 있습니다. Netty 프로젝트를 진행한 이희승씨의 사례는 귀감이 되고 있죠. (관련기사 참조: http://article.joins.com/news/article/article.asp?total_id=9364915&cloc=olink|article|default


최근, 인사이트(www.insightbook.co.kr)에서 대한민국 오픈소스 개발자들과의 인터뷰를 모은 책을 내려고 준비하고 있다고 합니다. (http://www.insightbook.co.kr/post/6600 참조) 잘 엮여지면 오픈소스 개발자를 꿈꾸는 많은 사람들에게 좋은 참고서가 될 법 한데요. 책으로 묶이기 전에 현재 책 내용의 일부, 그러니까 대담 가운데 일부가 온라인으로 공개되고 있습니다. http://osdi.insightbook.co.kr/ 로 들어가 보시면 내용을 확인하실 수 있습니다. 


최근 저도 오픈 소스 프로젝트를 진행하고 GItHub를 통해 공개하는 작업을 하고 있어서, 관심있게 지켜보고 있습니다. 오픈소스 개발을 꿈꾸는 다른 분들께서도, 진행 상황을 지켜보시면 좋을 것 같아요. 


제가 진행하고 있는 오픈 소스 프로젝트는 SDN (Software Defined Networking) 컨트롤러에 관한 것으로, 현재 http://openiris.etri.re.kr 에 공개되어 있습니다. Openflow를 사용한 네트워크 제어 기술에 대해서 관심 있는 분들께서는 둘러보시면 좋을 것 같네요. 






저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 오픈IRIS

    질문드려요 IRIS를 해보려고 하는데 튜토리얼봐도 잘 모르겠어요 알려주실수있나요?
    설치까지는 했는데.. 그다음부터는 잘 안되네요

    2014.08.26 15:57 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2011.11.07 10:35
IETF (Internet Engineering Task Force)는 인터넷과 관련된 표준화를 담당하는 표준화 기구입니다. ITU-T에 계시는 분들은 IETF에서 제정된 RFC가 진정한 의미에서의 표준은 아니라고 낮추어 보기도 합니다만, 제 소건으로는 ITU-T와 IETF는 표준화 하는 영역에 조금 차이가 있을 뿐, 결국 거기서 거기입니다. 하다 보면 결국 두 기구가 특정한 기술을 표준화 하는 데 있어서 협력을 하기도 하고요.

그런데 오늘 하려고 하는 이야기는 사실 그건 아닙니다. 오늘 하려고 하는 이야기는 Open Source의 개발 모델과 IETF의 표준화 모델 사이의 유사성입니다.

IETF

IETF는 표면적으로는 열려 있는 표준화 기구이고 아무나 참석하여 표준화에 기여할 수 있도록 되어 있습니다만, 좀 더 깊이 들어가보면 사실 꼭 그렇지는 않습니다. Cisco, Juniper, Huawei 등 네트워크 분야의 주도권을 쥐고자 하는 많은 업체들이 싸우는 전쟁터이기도 합니다. 각 업체 입장에서 보면, 표준이 제정될 때 어떻게든 자사 기술이 표준으로 채택되도록 만들 필요가 있습니다.

보통 표준화가 진행되기 전에 각 업체는 자사 기술에 대한 많은 특허를 내놓습니다. 그러나 자사 기술이 공통 표준에 많이 반영되면 될수록 표준 = 자사 기술의 등식이 성립하게 되고, 이렇게 되면 유리합니다. 자사 특허를 침해하지 않고 표준안 대로 기술을 구현할 수 있는 가능성이 적어지게 되니까요.



그렇게 되면 궁극적으로는 자사의 기술을 택한 장비가 시장에 퍼지게 되던지, 아니면 특허에 대한 기술료라도 받아 챙길수 있는 구조가 됩니다. 간단히 말하자면 그렇습니다. 이것이 IETF를 통한 표준화에 네트워크 장비 생산업체들이 그렇게 열심인 이유입니다.

Open Source

오픈소스 또한 모든 개발자에게 열려 있는 구조입니다. 아무나 참여해서 필요한 기능을 추가하고, 확장해 나갈 수가 있습니다. 그런데 최근의 오픈소스 개발 모델을 보면, 어느 정도는 IETF와 비슷해지고 있습니다.

페이스북이 Message 시스템을 새롭게 개편할 때 (https://www.facebook.com/note.php?note_id=454991608919) 페이스북은 Cassandra, MySQL, HBase 등의 시스템을 놓고 저울질을 했습니다. Cassandra와 MySQL은 이미 페이스북에서 널리 사용되고 있는 기술이었습니다. 

결국 Message 시스템의 구현에 필요한 Consistency 측면과, 다량 메시지에 대한 Indexing 요구사항을 처리할 수 있는 데이터베이스 기술로 최종 채택된 것은 HBase 였습니다. [각주:1] 그리고 HBase를 페이스북의 Message 데이터베이스로 이용하기 위해, HBase에 페이스북은 꽤 많은 기여를 했습니다. 그 덕에, 전 세계의 좀 더 많은 개발자들은 좀 더 향상된 기능의 HBase를 사용할 수 있게 되었죠. (여전히 HBase는 오픈소스입니다) 



그렇다면, 오픈소스 세계에서 최종적으로 살아남게 되는 기술은 어떤 기술일까요? 최종적으로는, 페이스북과 같은 대형 업체에서 사용되는 오픈소스가 살아남을 가능성이 높습니다. 개발자들은 본능적으로 그런 기술에 이끌리게 되어 있죠. 

결국, 페이스북이나 구글과 같은 대형 업체들이 잠식하고 있는 것은 플랫폼 시장 만은 아닌 셈입니다. 이미 그런 대형 IT 업체들은 Open Source 프로젝트 또한 좌지우지 할 정도의 영향력을 행사하게 되었고, 그 과정을 통해서 성장한 Open Source 기술들은 대형 플랫폼 업체들이 자사 기술의 영향력을 확대시키는 수단으로서도 기능하게 되었습니다.

오픈 소스 시스템을 상업적으로 이용하려면 우리는 그에 대한 대가를 지불해야 합니다. 오픈 소스는 오픈되어 있기는 하지만, 공짜는 아니기 때문이죠. 오픈 소스 시스템을 확장했다면 (확장을 어떻게 했느냐에 따라서는) 확장하는 데 사용된 소스를 공개해야 합니다. MySQL처럼 '상업적으로 사용하려면 돈을 내라'고 하는 곳도 있습니다. 거기다 오픈 소스 구현에 사용된 기술 중 상당수는 이미 특허가 제출된 것들입니다.

'공개'의 함정

그러니 우리는 뭔가가 '공개'되었다고 하면 거기에 대해서 다시 한 번 생각해 봐야 해요. 오픈소스 프로젝트가 처음 태동되었을 때만 해도 '공개'의 의도는 순수했습니다. 그런데 지금도 정말 그럴까요? 누가, 무엇을, 왜 공개했는지 좀 더 심도있게 고민해야 할 시점이 된 것 같네요.

 
  1. MySQL은 RDBMS라서 데이터가 많아지면 인덱싱하는 데 드는 시간이 성능 요구사항을 만족할 수 없을 정도로 커졌고, Cassandra의 Eventual-consistency 모델은 '결국에는 consistency가 맞는다'는 낙관적인 형태의 모델이어서, 언제나 consistency가 보장되어야 하는 messaging 시스템 구현에는 쓰이기 곤란했습니다. HBase는 간단한 형태의 consistency 모델을 제공하고 있었고, 성능도 괜찮았습니다. [본문으로]
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 오픈소스의 함정
    최근들어 와닿는 이야기입니다''
    순수 오픈을위한 경우가 얼마나될까요

    2011.11.08 00:31 신고 [ ADDR : EDIT/ DEL : REPLY ]