OK 괜찮아, 동네 개발자형

오픈 소스에 대한 오해와 진실은 다음과 같습니다:

1. 오해: 오픈 소스 소프트웨어는 무료로만 이용할 수 있다. 진실: 오픈 소스 소프트웨어는 주로 무료로 이용할 수 있지만, 이는 "무료"라는 개념을 가진 것은 아닙니다. 오픈 소스 소프트웨어의 라이선스는 대부분 자유롭고 수정 가능하며 재배포 가능한 조건을 가지고 있지만, 상업적 이용이나 수정한 버전의 판매에 대해서는 추가 요구사항이 있을 수 있습니다.
2. 오해: 오픈 소스 소프트웨어는 품질이 낮다. 진실: 오픈 소스 소프트웨어는 수많은 개발자 및 사용자의 협력과 검토를 거쳐 개발되기 때문에 품질이 매우 높을 수 있습니다. 많은 오픈 소스 프로젝트는 전 세계적으로 대규모로 개발되고 유지보수되며, 많은 사용자가 버그를 찾아내고 수정하거나 보안 취약점을 보완합니다. 오픈 소스 소프트웨어는 공동체의 지원과 풍부한 테스트를 통해 안정성과 신뢰성을 확보할 수 있습니다.
3. 오해: 오픈 소스 소프트웨어는 보안에 취약하다. 진실: 오픈 소스 소프트웨어는 일반적으로 많은 개발자와 보안 전문가들에 의해 검토되기 때문에 보안 취약점이 빠르게 발견되고 수정될 수 있습니다. 또한, 오픈 소스 소프트웨어는 투명성을 가지고 있어 누구나 코드를 검토하고 보완할 수 있으므로, 악의적인 코드나 보안 취약점이 숨겨진 경우가 적습니다. 그러나, 오픈 소스 소프트웨어 역시 보안 취약점이 있을 수 있으며, 이를 해결하기 위해서는 업데이트와 보안 패치를 지속적으로 적용해야 합니다.
4. 오해: 오픈 소스 소프트웨어는 개발자에게 이익이 없다. 진실: 오픈 소스 소프트웨어를 개발하는 개발자들은 자신의 기술력을 향상시키고 다른 사람과의 협력을 통해 더 좋은 소프트웨어를 만들기 위해 기여합니다. 또한, 오픈 소스 소프트웨어는 개발자에게 다양한 경제적 이익을 제공할 수 있습니다. 예를 들어, 개발자는 오픈 소스 소프트웨어에 기여하여 자신의 프로젝트에 대한 노출을 얻을 수 있고, 상업적인 지원, 컨설팅, 서비스 제공 등의 비즈니스 모델을 구축할 수 있습니다.
5. 오해: 오픈 소스 소프트웨어는 모든 종류의 소프트웨어에 적합하다. 진실: 오픈 소스 소프트웨어는 모든 종류의 소프트웨어에 적합하지는 않을 수 있습니다. 일부 상용 소프트웨어는 공개되지 않은 알고리즘, 특정 기능, 또는 소유권 보호 등의 이유로 오픈 소스로 제공되지 않을 수 있습니다. 또한, 기업이 자체적으로 개발한 소프트웨어의 경우에는 오픈 소스로 공개하지 않을 수 있습니다.

이러한 오해와 진실을 고려하여, 오픈 소스 소프트웨어는 현대 소프트웨어 개발과 사용에 있어서 중요한 역할을 수행하고 있으며, 다양한 장단점을 가지고 있습니다.

느낌 아시는 분들은 아시겠지만, 위에는 ai.com 이 답변한 것입니다. 오픈 소스에 대한 생각을 AI가 잘 정리해 놓아서 저도 놀랐습니다.

그리고, 오픈 소스에 참여하는 방법은 어렵지 않습니다.

자기가 짠 코드를 무.조.건. 오픈하라는 것은 아닙니다. 개인적인 의견은 `오픈 소스 프로젝트`에 참여를 권장합니다. 좋은 오픈 소스를 사용하고 피드백하는 것은 매우 도움이 되기 때문입니다.

hadoop (https://hadoop.apache.org) 이전에는 or*cle 세상이었는데, 오픈 소스 hadoop이 RDBMS의 전횡을 바꿀 수 있었다고 생각합니다.

M$도 스티브 발머 이후 사티아 나델라 이후에 오픈 소스로 완전히 돌아서기도 했고, 지금도 계속되고 있습니다.

물론 국가기밀이나 회사의 영업 비밀은 오픈하면 안 됩니다. 인터넷에 오픈할 게 있고, 하지 말아야 하는 것은 존재합니다.

 

오픈 소스에 관한 퀴즈 하나입니다.

오늘 발표한 자료 공개합니다.

https://bit.ly/egovcontrib

 

http://www.ibm.com/developerworks/kr/opensource/newto/index.html

첫 장부터 펼쳤습니다. 아직 섹션 하나만 읽은 상태죠. 그런데 왠걸 좋네요. ^^; 브룩스의 Mythical Man-Month 요약도 스토리 중에 잘 되어 있고, 프로그램 용어나 생리를 잘 모르는 사장님 같은 사람들에게 설명하기 쉽도록 표현된 부분도 많군요.

고전적인 자바 클래스의 테스트는 main() 메소드에 값을 찍어보는 코드를 넣어서 콘솔에서 확인합니다. 이클립스에 익숙해진 덕에 JUnit에서 System.out.println() 집어 넣는 것은 초딩같은 습관이라고 생각을 "저만"했었습니다. 하지만, 찍어본다는 것 그리고 그것을 눈으로 확인하는 것은 굉장한 심리적 안정감을 주기는 합니다. 아직 assertEquals() 는 보이지 않는 신뢰가 필요하기 때문이죠.

httpunit의 테스트코드를 보니 재밌는 부분이 있었습니다. 상당히 많은 수의 테스트케이스에 main() 메소드가 있었고, 그 메인메소드는 JUnit을 기반으로 해당 테스트코드를 수행하도록 만들어주는 것이었습니다.

suite() 메소드를 inline 리팩토링하면 junit.textui.TestRunner.run( new TestSuite( EncodingTest.class ));  를 통해서 실행을 합니다. Java Application 으로 실행한 결과는 다음과 같습니다.

물론 이 클래스는 JUnit을 통해서도 실행됩니다.

다른 사람의 코드를 읽는 것, 프로그래머 소통의 시작이 아닐까 생각해봅니다.

참고로 HttpUnitTest 클래스의 상속구조입니다. ctrl+T 로 이클립스에서 볼 수 있습니다.

 

앞서 오픈소스를 통해서 소스 저장소에 등록되는 디렉토리 구조를 살펴보았습니다. 그리고 프로젝트 소스를 일괄처리하는 build.xml 도 살짝 들여다 보았습니다. 이클립스 툴을 쓰면 다 되는 작업을 왜 Ant 빌드스크립트를 만들어야하는지 질문을 종종 들어봤습니다. 지속적인 통합 빌드 같이 주기적으로 반복되는 작업이나 단계가 복잡한 작업들은 빌드스크립트가 효과적입니다. 클릭클릭하는 일도 지겨울 때가 있거든요. 이클립스 작업의 자동화가 빌드 스크립트라고 생각하시면 될 것입니다.

지난 번 소스 가져오기(import) 이후로 소스의 빌드 경로를 잡아보려고 합니다. 로컬pc에서 컴파일되나 안되나 확인하는 것이죠. 소스가 패키지에 맞게 제자리에 있어야 할 것이고, 참조하는 jar파일의 경로도 함께 지정해줘야 합니다.

일단 이클립스 자바 프로젝트에서 소스 폴더를 추가합니다. 자바소스가 있는 폴더를 소스폴더라고 합니다. *.java 파일과 *.properties 파일들이 위치합니다. httpunit-1.7 아래 src 폴더가 바로 소스폴더입니다. 그리고 httpunit-1.7 아래 test 라는 곳도 소스 폴더로 추가합니다. src 아래 있는 클래스들을 테스트하는 테스트케이스들의 소스 폴더입니다.

자동 빌드가 일어나면서 에러가 무진장 일어납니다. jar 파일 연결이 안되서 그렇습니다.

왼쪽 패키지 익스플로러에서 프로젝트를 선택하고 Properties 창을 엽니다. 컨텍스트 메뉴에서 제일 아래 Properties 메뉴를 선택하면 됩니다. 단축키는 alt+Enter
Java Build Path 항목을 선택하고 Libraries 탭을 클릭합니다.

우측의 Add JARs... 버튼을 클릭해서 httpunit-1.7/jars 폴더의 *.jar 파일들을 선택합니다.

오호, 에러가 줄기는 했는데, 하나 남았네요. fnfe를 클릭해서 해당 소스를 열어보겠습니다. 흠, 겁을 상실했군요. 에~ 뭐 꼭 고친다는 뜻은 아닙니다. ^^;

소스를 살짝 보니 캐릭터셋 문제로 Roger Lindsj 이름 옆에 이상한 문자가 생긴 것 같네요. 그것 때문에 아랫줄 if라인이 주석 줄로 따라 올라온 듯 합니다.

if 앞에서 엔터로 줄바꿔주니 고쳐졌습니다. ^^; 잠시 우쭐~

Problems 탭에 에러는 싹 사라졌군요. Warnings는 살짝 봐주기로 하죠. ^^;

소스 폴더가 추가된 모습입니다.

작업공간은 에러 없는 코드로 관리되는 것이 개발자 심리에 좋다고 생각을 합니다. ^^;

오픈소스에 대한 얘기는 갈 수록 높아져 가고 있습니다. Freeware, Shareware 등으로 사용되는 애플리케이션과는 달리 소스까지 공개된 프로그램을 오픈소스라고 하지만, 오픈소스 제품은 공짜로서의 의미보다 기술의 공개라는 차원에서 더 가치가 있습니다.

developerWorks에 나온 "오픈 소스 입문"에 대한 글이 입문용으로 가볍게 읽을 만 합니다.


Open Source Initiative 라는 단체가 만들어지고 오픈소스에 대한 라이센스와 가이드를 제시하고 있습니다.

오픈소스 제품이 시장에서 큰 역할을 하는 것을 예를 들면 리눅스, 아파치 웹 서버 등을 예로 들 수 있습니다.

오픈소스로 제품의 수준이 상용과 비길 수 있을 때 듀얼라이센스로 판매도 됩니다. 대표적인 것이 MySQL 같은 것이 되겠죠.


오픈 소스 작업을 위한 몇 가지 도구들이 있습니다.
Source Repository : CVS, SVN 같은 소스 버전관리 저장소입니다.
Mailing LIst : 사용자와 개발자 모두 메일을 통해서 의견 교환을 하는 경우가 많습니다. 종종 게시판이나 포럼도 사용되지만 대세는 메일링 리스트입니다.
Issue Tracker : Bugzilla, Trac, JIRA 와 같이 이슈, 버그 등을 등록해서 처리과정을 확인할 수 있는 시스템입니다.
Documentation Site : 오픈소스의 특성상 상용 제품보다 많이 부족하다고 느껴지는 부분입니다. 잘 나가는 오픈소스의 경우 매뉴얼 페이지가 잘 갱신되고 관리된다고 생각됩니다.


오픈소스 프로젝트를 호스팅하는 사이트들도 많이 있습니다. http://sourceforge.net, http://code.google.com/, http://kldp.net 등을 추천합니다.

제가 오픈해 놓은 소스 프로젝트도 있습니다.
http://code.google.com/p/daysago, http://code.google.com/p/shopgallery, http://code.google.com/p/unicodereader

작은 코드 조각(snippet)이지만 시작이 너무 크면 부담되거든요. ^^

리니지로 유명한 엔씨소프트의 삼성동쪽 건물은 잘 숨어있는 듯 합니다. 두 번째 같은 장소를 가는 것이지만 오늘도 헤매었군요. 포스코 건너편 국민은행 빌딩 15층. 안 잊어먹겠습니다. ㅎㅎ

오픈마루에서 준비하는 WoC 2007 의 준비를 위한 간담회에 다녀왔습니다.

국내 오픈소스의 활성화를 위해서 작년에 이어 두번째로 준비하는 것인데, 이번에는 국내 개발자 커뮤니티의 참여를 확대한다고 해서 저도 참석할 수 있게 되었습니다.

고등학생부터 대학원생까지 참여할 수 있고, 멘토는 기업체나 커뮤니티를 대표해서 1:1로 학생의 프로젝트를 도와줄 수 있는 구조입니다.

오픈마루 권오성님의 진행으로 2시간 정도 진행이 되었고, 다양한 분야의 사람들의 오픈소스와 WoC에 대한 의견을 들을 수 있었습니다.

이후 뒷풀이에서 잠깐 얘기하다가 먼저 나왔습니다.

내년 2월까지 진행되는 것으로 기억하는데, 오픈소스를 잘 이해하는 사람들이 많아졌으면 행사의 기본적인 취지는 살리는 것이 아닌가 생각됩니다.

ps. CN님 만나뵈서 반가웠습니다. 나중에 기회되면 더 많이 얘기할 수 있기를 바랍니다. ^^