크리스 웨넘은 '그대가 엉터리 개발자라는 신호들(Signs that you're a bad programmer)'이라는 제목의 글에서 여섯 가지 신호를 이야기했다. 스스로 개발자인 저자 자신의 경험을 토대로 쓴 글이라는데, 내가 겪은 경험과도 정확하게 일치한다.

이러한 신호를 이야기하는 것은 우리 주변에서 누가 엉터리 개발자인지 골라내자는 것이 아니다. 오히려 좋은 프로그래머가 되기 위해서 누구나 거쳐 가는 단계라고 보는 편이 정확할 것이다. 우리는 모두 한 때는 (어쩌면 지금도) 엉터리 개발자였다.

첫 번째는 코드를 머리로 돌릴 수 있는 능력의 부재다. 엄청난 분량의 코드를 생각만으로 돌릴 수 있는 사람도 있고, 아주 짧은 코드만 돌릴 수 있는 사람도 있는데, 어쨌든 코드를 머리로 돌리는 능력은 개발자에게 기본이다. 이것은 바둑을 두는 프로기사에게 바둑판 위에 놓이지 않은 미래의 수를 읽어내는 능력이 필요한 것과 마찬가지다.

90년대에 빌 게이츠는 마이크로소프트가 수퍼스마트(Supersmart) 프로그래머만을 고용하기를 원한다고 말한 적이 있다. 그 말을 듣고 한 기자가 게이츠에게 수퍼스마트가 어떤 사람이냐고 물었다. 그러자 그는 자기가 작성한 코드의 내용을 6개월이 지난 시점에서도 컴퓨터 없이 (마치 눈앞에서 코드를 보고 있는 것처럼) 설명할 수 있는 사람이라고 대답했다.

그 정도까지는 아니더라도 회사에서 코드리뷰를 하다보면 자기가 아침에 작성한 코드의 내용을 설명하지 못하는 프로그래머가 있음을 알게 된다. 이런 개발자가 다른 사람이 작성한 코드를 읽을 수 없음은 물론이다. 이러한 능력의 부재는 어떤 면에서 노력으로 해결할 수 있는 것이 아니다. 이것은 개발자에게 필요한 최소한의 재능을 갖추지 못한 사례에 해당하므로 하루라도 빨리 다른 일을 시작하는 것이 더 나을 가능성이 높다.

두 번째는 자기가 사용하는 언어의 프로그래밍 모델을 제대로 이해하지 못하는 것이다. 이런 현상은 오랜 개발 경험을 쌓은 개발자 중에서도 어렵지 않게 발견된다. 객체지향 패러다임이 탑재된 C++가 처음 등장했을 때 많은 개발자들이 C++를 이용해서 C 코드를 작성했다. 마찬가지로 오랫동안 자바 언어를 사용해온 개발자가 객체지향 패러다임을 전혀 이해하지 못하고 있는 경우가 생각보다 많다. 함수 패러다임은 말할 필요도 없다.

오래 전에 자바 개발자를 고용하기 위한 기술인터뷰를 수행했을 때의 일이다. 내가 멀티쓰레딩과 관련한 질문을 하자 쓰레드 같은 것은 EJB 컨테이너가 알아서 관리해 주기 때문에 자기는 그런 것까지 알 필요가 없다고 대답한 사람이 있었다. 이런 사람은 이력서에 개발 경력이 5년이든 10년이든 상관이 없다. 끊임없는 학습과 자유분방한 창의력을 요구하는 프로그래밍이라는 행위를 기계적인 코딩, 단순히 반복되는 잡무, 혹은 하기 싫지만 어쩔 수 없이 하는 회사일로 대하는 사람은 앞으로 20년 동안 경험을 쌓아도 기술적으로 변화가 있을 리 없기 때문이다.

세 번째는 학습능력의 부재다. 요즘처럼 정보가 홍수처럼 쏟아져 나오는 시대에 그 모든 내용을 미리 다 알고 있는 사람이 어디에 있겠는가. 수많은 오픈소스 라이브러리, 새로운 기술, 패턴, 사례를 모두 꿰차고 있는 사람은 어디에도 없다. 많은 것을 알고 있는 것처럼 보이는 사람은 그만큼 열의를 갖고 학습을 하기 때문이다. 인터넷 검색을 하고, 코세라 강의를 듣고, 유투브 채널에 가입하고, 세미나에 참여하고, 책을 구입해서 읽으며 쉬지 않고 공부를 한다. 여기에서 중요한 것은 공부를 통해서 습득한 지식의 분량이 아니다. 중요한 것은 공부를 하는 방법, 즉 메타 지식에 해당하는 학습능력 자체다.

좋은 개발자는 낯선 기술이 등장하면 호기심을 품고 즐거운 심정이 되어 이곳저곳 건드려보지만, 엉터리 개발자는 입을 씰룩거리며 낯을 가린다. 이제 겨우 하나를 익혔더니 또 공부를 해야 하냐며 푸념을 한다. 낯선 대상을 두려워하는 것이 아니라 사실은 학습이라는 행위 자체를 두려워하는 것이다. 프로그래밍이라는 행위가 끝없는 학습으로 이루어져 있음을 이해하지 못하기 때문이다.

웨넘이 네 번째로 거론한 내용은 포인터(pointer)에 대한 이해부족인데, C나 C++를 사용하지 않으면 요즘에는 포인터를 직접 다룰 일이 없으므로 넘어가자. 웨넘의 이야기를 최근의 추세에 맞게 재구성하자면 타입시스템(type system)에 대한 이해부족이라고 이야기해도 좋을 것이다.

다섯 번째는 재귀(recursion) 알고리즘을 이해하는 능력이 없는 것이다. 이것은 맨 처음에 보았던 머리로 코드를 돌리는 능력과 밀접한 관련이 있다. 재귀를 이용해서 정수의 팩토리얼 값을 구하는 정도는 대부분의 개발자가 어렵지 않게 이해한다. 피보나치수열까지도 괜찮다. 트리구조의 노드를 순차적으로 방문하는 알고리즘도 기본적인 것까지는 무리 없이 이해한다.

하지만 하노이의 탑과 같은 알고리즘이 등장하면 숨이 막히기 시작한다. 꼬리재귀(tail recursion)가 왜 효율적인지, 일반적인 재귀 알고리즘을 어떻게 꼬리재귀 알고리즘으로 변환할 수 있는지 등을 이야기하다보면 한계를 느낀다. 이런 사람들은 개발자가 되어서 실전에 배치되어도 운영체제의 루프백(loopback) 주소라는 개념을 이해하지 못해서 애를 먹는다. 재귀라는 알고리즘의 작동방식이 머릿속에서 그려지지 않는 탓이다.

마지막은 코드에 대한 불신이다. 엉터리 개발자들은 정작 믿지 않아야 하는 코드를 신뢰하고, 믿어도 좋은 코드를 불신한다. 유닛테스트 코드를 작성하라고 시키면 실제로 검사되어야 하는 코드를 테스트하는 것이 아니라, 언어자체의 문법이나 라이브러리 코드의 API를 확인하는데 시간을 보낸다. 버그 투성이인 자신의 코드에 애착을 품고, 철저하게 검증된 라이브러리 코드를 의심한다.

전부는 아니더라도 이러한 여섯 가지 중에서 한 두 항목에서 뜨끔한 기분을 느낀 사람이 있을 것이다. 다시 한 번 말하지만 이 글의 목적은 엉터리 개발자를 추궁하자는 것이 아니다. 좋은 프로그래머가 되기 위해서 우리가 밟아온 과정, 혹은 앞으로 밟아야 하는 과정을 환기하여 다 같이 행복한 프로그래밍을 하자는 것이 목적이다. 다음에 기회가 있으면 “그대가 훌륭한 개발자라는 신호들”에 대해서도 이야기하도록 하겠다.

출처(2014/10/24 기사) : http://www.zdnet.co.kr/view/?no=20141024082051

오늘 페이스북 타임라인을 읽다보니 '리눅스 HWP 공개 라이브러리 개발' 건에 대한 라이선스 이야기를 하는 글들이 보이네요. 저도 예전에 FCKEditor를 적용한 제품때문에 LGPL의 정체가 뭔지 몰라서 어려웠던 기억이 납니다. 글타래를 읽다보니 LGPL에 대해서 애매한 이야기들이 좀 있는것 같아서 정리해봅니다. 

1. 공통적으로 지킬 것

일단 OSI(Open Source Initiative)에 등록되어 있는 오픈소스SW 라이선스는 GPL이건 LGPL 이건 상관없이 공통적으로 지켜야 하는 내용이 두가지 있습니다. 

가. 저작권 관련 문구 유지

- 가져다 쓰는 것은 자유롭게 하고 개발자의 정보는 삭제하지 않는 것이죠. 이것은 원 저작권자의 인격을 보호하기 위한 사항으로 마음대로 삭제하시면 안됩니다.

나. 제품명 중복 방지

- 아파치, 리눅스 같은 프로젝트명을 선택하면 안된다는 의미입니다.

두 가지 모두 무엇인가를 직접 만들어본 사람이라면 상식적인 수준에서 지켜야 하는 것이죠.

2. LGPL 라이선스를 가져다 쓰는데 소스코드를 공개해야만 하나요?

LGPL은 GPL의 조건이 너무 엄격해서 사람들이 쓰는 것을 꺼려할까봐 이를 감안해서 만든 라이선스 입니다. 따라서 GPL과는 다르게 LGPL 라이브러리에 응용프로그램을 정적 혹은 동적으로 링크시킨다고 해도 응용프로그램의 소스코드를 공개할 필요가 없습니다. LGPL 전문에 있는 ”라이브러리의 복제본을 무상이나 유상으로 배포할 경우에, 당신은 우리가 당신에게 부여한 모든 권리를 수취인에게도 그대로 부여해야 한다.“라는 내용으로 요구 조건만 준수한다면 상업적인 유상 배포도 허용하고 있습니다. 따라서 자기가 만든 소스코드의 공개없이 가격을 받는 상용제품으로 판매하셔도 됩니다.

다만, LGPL 라이브러리의 소스코드를 수정하였을 때에는 2차적 파생 저작물에 해당하므로 라이브러리의 소스코드를 제공해야 합니다.

3. LGPL을 가져와서 개발하고 GPL 라이선스로 변경해도 될까요?

대답은 변경해도 됩니다. 아래 내용을 보시면 "양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다"라고 표기되어 있습니다. 하지만 GPL 소스코드를 가져와서 임의로 LGPL로 변경하는 것은 안됩니다.

http://olis.or.kr/ossw/license/license/detail.do?lid=1005&mapcode=&currentPage=

제3조.

 당신은 양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다. 이를 가능케 하기 위해서는 본 라이선스를 언급하는 모든 사항들을 GNU 일반 공중 라이선스 버전2의 사항들로 대체시켜야 한다. (만약 GNU 일반 공중 라이선스 버전 2 이후에 신규 버전이 공표되었을 경우에는 원한다면 신규 버전을 사용할 수 있다.) 그 외에 다른 사항들은 변경할 수 없다.

복제물에 대해 이러한 수정이 이루어졌을 경우에는 라이선스를 다시 변경하는 것은 불가능하며, 따라서 해당 복제물을 기반으로 만들어진 모든 저작물과 복제물에는 GNU 일반 공중 라이선스가 적용되어야 한다.

이러한 선택 사항은 라이브러리의 코드 일부분을 라이브러리가 아닌 프로그램에 포함시키고자 할 경우에 유용하다.

하지만 LGPL을 제외한 나머지 라이선스는 원 저작자가 아닌 사람이 임의로 라이선스를 변경할 수 없습니다. LGPL은 명확하게 전문에 표기하였기 때문에 문제가 없지만 다른 오픈소스SW 라이선스는 이를 허용하지 않습니다. 

4. 더 궁금하시면

다른 오픈소스SW 라이선스에 대하여 궁금하시다면 아래의 링크를 이용하시면 됩니다.

- 공개SW 라이선스 가이드 다운로드 http://www.oss.kr/?mid=oss_license&page=3&document_srl=70139 

- 오픈소스 라이선스 해설 http://www.oss.kr/oss_license/92922

그림출처 : http://terokarvinen.com/freehelia_licenses_and_the_definition_of_free_software.html

오늘 페이스북 타임라인을 읽다보니 '리눅스 HWP 공개 라이브러리 개발' 건에 대한 라이선스 이야기를 하는 글들이 보이네요. 저도 예전에 FCKEditor를 적용한 제품때문에 LGPL의 정체가 뭔지 몰라서 어려웠던 기억이 납니다. 글타래를 읽다보니 LGPL에 대해서 애매한 이야기들이 좀 있는것 같아서 정리해봅니다. 

1. 공통적으로 지킬 것

일단 OSI(Open Source Initiative)에 등록되어 있는 오픈소스SW 라이선스는 GPL이건 LGPL 이건 상관없이 공통적으로 지켜야 하는 내용이 두가지 있습니다. 

가. 저작권 관련 문구 유지

- 가져다 쓰는 것은 자유롭게 하고 개발자의 정보는 삭제하지 않는 것이죠. 이것은 원 저작권자의 인격을 보호하기 위한 사항으로 마음대로 삭제하시면 안됩니다.

나. 제품명 중복 방지

- 아파치, 리눅스 같은 프로젝트명을 선택하면 안된다는 의미입니다.

두 가지 모두 무엇인가를 직접 만들어본 사람이라면 상식적인 수준에서 지켜야 하는 것이죠.

2. LGPL 라이선스를 가져다 쓰는데 소스코드를 공개해야만 하나요?

LGPL은 GPL의 조건이 너무 엄격해서 사람들이 쓰는 것을 꺼려할까봐 이를 감안해서 만든 라이선스 입니다. 따라서 GPL과는 다르게 LGPL 라이브러리에 응용프로그램을 정적 혹은 동적으로 링크시킨다고 해도 응용프로그램의 소스코드를 공개할 필요가 없습니다. LGPL 전문에 있는 ”라이브러리의 복제본을 무상이나 유상으로 배포할 경우에, 당신은 우리가 당신에게 부여한 모든 권리를 수취인에게도 그대로 부여해야 한다.“라는 내용으로 요구 조건만 준수한다면 상업적인 유상 배포도 허용하고 있습니다. 따라서 자기가 만든 소스코드의 공개없이 가격을 받는 상용제품으로 판매하셔도 됩니다.

다만, LGPL 라이브러리의 소스코드를 수정하였을 때에는 2차적 파생 저작물에 해당하므로 라이브러리의 소스코드를 제공해야 합니다.

3. LGPL을 가져와서 개발하고 GPL 라이선스로 변경해도 될까요?

대답은 변경해도 됩니다. 아래 내용을 보시면 "양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다"라고 표기되어 있습니다. 하지만 GPL 소스코드를 가져와서 임의로 LGPL로 변경하는 것은 안됩니다.

http://olis.or.kr/ossw/license/license/detail.do?lid=1005&mapcode=&currentPage=

제3조.

 당신은 양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다. 이를 가능케 하기 위해서는 본 라이선스를 언급하는 모든 사항들을 GNU 일반 공중 라이선스 버전2의 사항들로 대체시켜야 한다. (만약 GNU 일반 공중 라이선스 버전 2 이후에 신규 버전이 공표되었을 경우에는 원한다면 신규 버전을 사용할 수 있다.) 그 외에 다른 사항들은 변경할 수 없다.

복제물에 대해 이러한 수정이 이루어졌을 경우에는 라이선스를 다시 변경하는 것은 불가능하며, 따라서 해당 복제물을 기반으로 만들어진 모든 저작물과 복제물에는 GNU 일반 공중 라이선스가 적용되어야 한다.

이러한 선택 사항은 라이브러리의 코드 일부분을 라이브러리가 아닌 프로그램에 포함시키고자 할 경우에 유용하다.

하지만 LGPL을 제외한 나머지 라이선스는 원 저작자가 아닌 사람이 임의로 라이선스를 변경할 수 없습니다. LGPL은 명확하게 전문에 표기하였기 때문에 문제가 없지만 다른 오픈소스SW 라이선스는 이를 허용하지 않습니다. 

4. 더 궁금하시면

다른 오픈소스SW 라이선스에 대하여 궁금하시다면 아래의 링크를 이용하시면 됩니다.

- 공개SW 라이선스 가이드 다운로드 http://www.oss.kr/?mid=oss_license&page=3&document_srl=70139 

- 오픈소스 라이선스 해설 http://www.oss.kr/oss_license/92922

그림출처 : http://terokarvinen.com/freehelia_licenses_and_the_definition_of_free_software.html

오늘 페이스북 타임라인을 읽다보니 '리눅스 HWP 공개 라이브러리 개발' 건에 대한 라이선스 이야기를 하는 글들이 보이네요. 저도 예전에 FCKEditor를 적용한 제품때문에 LGPL의 정체가 뭔지 몰라서 어려웠던 기억이 납니다. 글타래를 읽다보니 LGPL에 대해서 애매한 이야기들이 좀 있는것 같아서 정리해봅니다. 

1. 공통적으로 지킬 것

일단 OSI(Open Source Initiative)에 등록되어 있는 오픈소스SW 라이선스는 GPL이건 LGPL 이건 상관없이 공통적으로 지켜야 하는 내용이 두가지 있습니다. 

가. 저작권 관련 문구 유지

- 가져다 쓰는 것은 자유롭게 하고 개발자의 정보는 삭제하지 않는 것이죠. 이것은 원 저작권자의 인격을 보호하기 위한 사항으로 마음대로 삭제하시면 안됩니다.

나. 제품명 중복 방지

- 아파치, 리눅스 같은 프로젝트명을 선택하면 안된다는 의미입니다.

두 가지 모두 무엇인가를 직접 만들어본 사람이라면 상식적인 수준에서 지켜야 하는 것이죠.

2. LGPL 라이선스를 가져다 쓰는데 소스코드를 공개해야만 하나요?

LGPL은 GPL의 조건이 너무 엄격해서 사람들이 쓰는 것을 꺼려할까봐 이를 감안해서 만든 라이선스 입니다. 따라서 GPL과는 다르게 LGPL 라이브러리에 응용프로그램을 정적 혹은 동적으로 링크시킨다고 해도 응용프로그램의 소스코드를 공개할 필요가 없습니다. LGPL 전문에 있는 ”라이브러리의 복제본을 무상이나 유상으로 배포할 경우에, 당신은 우리가 당신에게 부여한 모든 권리를 수취인에게도 그대로 부여해야 한다.“라는 내용으로 요구 조건만 준수한다면 상업적인 유상 배포도 허용하고 있습니다. 따라서 자기가 만든 소스코드의 공개없이 가격을 받는 상용제품으로 판매하셔도 됩니다.

다만, LGPL 라이브러리의 소스코드를 수정하였을 때에는 2차적 파생 저작물에 해당하므로 라이브러리의 소스코드를 제공해야 합니다.

3. LGPL을 가져와서 개발하고 GPL 라이선스로 변경해도 될까요?

대답은 변경해도 됩니다. 아래 내용을 보시면 "양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다"라고 표기되어 있습니다. 하지만 GPL 소스코드를 가져와서 임의로 LGPL로 변경하는 것은 안됩니다.

http://olis.or.kr/ossw/license/license/detail.do?lid=1005&mapcode=&currentPage=

제3조.

 당신은 양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다. 이를 가능케 하기 위해서는 본 라이선스를 언급하는 모든 사항들을 GNU 일반 공중 라이선스 버전2의 사항들로 대체시켜야 한다. (만약 GNU 일반 공중 라이선스 버전 2 이후에 신규 버전이 공표되었을 경우에는 원한다면 신규 버전을 사용할 수 있다.) 그 외에 다른 사항들은 변경할 수 없다.

복제물에 대해 이러한 수정이 이루어졌을 경우에는 라이선스를 다시 변경하는 것은 불가능하며, 따라서 해당 복제물을 기반으로 만들어진 모든 저작물과 복제물에는 GNU 일반 공중 라이선스가 적용되어야 한다.

이러한 선택 사항은 라이브러리의 코드 일부분을 라이브러리가 아닌 프로그램에 포함시키고자 할 경우에 유용하다.

하지만 LGPL을 제외한 나머지 라이선스는 원 저작자가 아닌 사람이 임의로 라이선스를 변경할 수 없습니다. LGPL은 명확하게 전문에 표기하였기 때문에 문제가 없지만 다른 오픈소스SW 라이선스는 이를 허용하지 않습니다. 

4. 더 궁금하시면

다른 오픈소스SW 라이선스에 대하여 궁금하시다면 아래의 링크를 이용하시면 됩니다.

- 공개SW 라이선스 가이드 다운로드 http://www.oss.kr/?mid=oss_license&page=3&document_srl=70139 

- 오픈소스 라이선스 해설 http://www.oss.kr/oss_license/92922

그림출처 : http://terokarvinen.com/freehelia_licenses_and_the_definition_of_free_software.html

- 한국저작권위원회 라이선스 설명 : http://olis.or.kr/ossw/license/license/list.do  

- 공개SW역량플라자 라이선스 설명 : http://www.oss.kr/45607

http://panocafe.tistory.com/

http://www.kimsq.co.kr/note/wildnote