원본읽기

어떻게 해야 프로그래밍을 제대로 배울 수 있을까? 그리고 어떤 식으로 해야 프로그래밍을 제대로 가르칠 수 있을까? 프로그래밍 기술 서적이 무더기로 쏟아져 나오지만 정작 이와 같은 질문에 바른 답을 주는 책은 드물다. 무엇이 ‘제대로’인지 깨닫지 못하는 바에야 무작정 프로그래밍 기술을 집어 삼키는 것이 무슨 의미가 있을까? 이 문제를 진지하게 고민하지 않는 이에게는 세상에 둘도 없이 못써먹을 책이겠지만 그렇지 않다면―어떻게 프로그래밍을 배우고 가르쳐야 할지 그 바른 출발점을 찾지 못해 헤매는 누군가가 있다면, 『Structure and Interpretation of Computer Programs』는 유일무이한 해답이라고 할만 하다.

김재우 | kizoo@bluette.com
블루엣 인터내셔널의 기술 이사로 재직중이며 개발 환경과 온라인 교육 시스템을 결합한 소프트웨어를 설계하고 있다. 소프트웨어 공학 기술이나 관련 이론을 실천하도록 만드는 것이 개발자로서의 목표다.


지난 1985년 MIT Press에서 출판한 『Structure and Interpretation of Computer Programs』(이하 SICP)는 MIT의 기초 프로그래밍 교육 과정을 담고 있다. 이 책의 신선한 교육 철학과 완성도 높은 내용은 기존의 프로그래밍 입문 교재들과 차원을 달리했다. 그리하여 ‘강호(?)를 평정’했다고 표현해도 될 만큼 수많은 대학에서 이 과정을 채택했고, 이른바 프로그래밍 입문 교육의 표준이 됐다(한때 SICP는 세계 300여개 대학의 프로그래밍 교육 과정에 사용됐다).

SICP의 신선한 교육 철학
SICP의 무엇이 그렇게 상큼했을까? 이 책은 프로그래밍 언어의 선택부터가 남달랐다. 당시 산업에서 인기를 끌고 있는 언어나 교육용 언어로 널리 인정받았던 파스칼을 쓰지 않고 MIT에서 개발한 새로운 언어, Scheme을 실습 언어로 선택하는 과감성을 보였다. 프로그래밍 언어 Scheme은 LISP의 전통을 이어받아 설계된 언어이나 Static Scoping(미안하지만, 아직 이 용어를 쉽게 대체할 적당한 우리말을 찾지 못했다)을 채택하고, 함수 계산 결과가 함수가 될 수 있도록 기능을 확장한 면이 다르다. 그렇다면 하고 많은 언어 중에 왜 하필이면 Scheme이었을까? 그것도 처음 프로그래밍을 훈련하는 과정에서 왜 그런 파격이 필요했을까?

독특한 실습 언어, Scheme
첫 번째 프로그래밍 언어의 선택은 아주 중요하고도 민감한 문제다. 처음 배우는 언어는 프로그래머에게 모국어와 같아서, 프로그래머가 생각하는 사고의 바탕이 된다(본지 다른 기사를 통해 여러 번 같은 주장을 한 적이 있다).
선택한 언어가 표현 수준이 낮아 어려운 문제를 푸는 데 많은 사전 작업을 거쳐야 한다면 학생들은 문제를 푸는 사고를 배운다기보다, 언어의 낮은 표현 수준을 문제를 표현할 수 있는 수준으로 끌어올리는 데 더 심혈을 기울여야 한다(대부분의 시스템 프로그래밍 언어가 그렇다). 물론 그 또한 프로그래밍 교육이라고 할 수야 있겠지만 프로그래밍 사고를 형성하고자 하는 교육 목표와는 거리가 멀다. 다시 말해 프로그래밍 입문 과정에서 다룰 주제는 아니다.
또한 실습 언어가 편협한 해법을 강요하면 문제를 유연하게 해결하는 사고력을 가르치기 어렵다. 나중에 완전히 다른 방식의 해법을 공부하게 되더라도 처음 익힌 사고의 편향성 때문에 새로운 방식에 적응하기 매우 힘들다(필자 자신이 그 좋은 예다. SICP를 처음 배울 때의 충격은 프로그래밍을 처음 배웠을 때에 비할 바가 아니었다).
그러므로 가능하면 아예 처음부터 복합 사고를 익히게 하는 것이 옳다. 즉, 하나의 문제 풀이에 가능한 해법을 총동원해 보고, 그 중 가장 유리한 해법 몇 개를 섞어 쓰도록 유도하는 것이 바람직하다(이른바 멀티패러다임 프로그래밍).
Scheme은 앞의 두 가지 문제를 균형 있게 해결할 수 있는 답이다. 문법이 간결하고 구문의 의미가 명확하다 보니 다른 언어에서처럼 ‘문법의 횡포’에 시달릴 요인이 없다. 즉, 언어를 익히느라 시간을 허비하지 않아도 되므로 교육의 취지에 맞게 프로그래밍을 익히는 데 더 많은 노력과 시간을 할애할 수 있다(만일 이 글이 언어 선택에 대한 확신을 심어주기에 모자라다고 생각하면, Alan J. Perlis가 쓴 SICP의 머리말과 참고자료 ?의 논문을 읽어봐 주었으면 한다).

풍부하고 정선된 예제
SICP의 두 번째 자랑거리는 주옥같은 예제에 있다. 이 책은 예제로 시작해 예제로 끝난다고 해도 과언이 아닐 정도로 풍부한 예제를 제공하는데, 그 완성도가 뛰어남은 물론이고 하나하나 확실한 교육 목표를 염두에 두고 설계되어 있다. 즉, 프로그래밍 기법이나 새로운 응용 분야를 말로 드러내어 설명한다기보다(그렇다고 아예 설명을 생략한다는 것은 아니지만), 주어진 문제의 자연스런 해결책으로 동원될 수 있게 애써 꾸며 놓았다.
이는 시중에서 흔히 볼 수 있는 프로그래밍 책들과 크게 다른 접근 방식이다. 보통 프로그래밍 패러다임이나 설계 원리를 설명하는 책들은 이해시키고자 하는 대상에 지나치게 집중한 나머지 예제 선택의 중요성을 간과한다. 고의로 간단한 예제를 사용하고 예제 자체를 이해하는 데 부담을 줄여 원리를 이해시키는 목적에 충실하자는 의도다. 그러나 이런 방식은 원리 해설에는 유리할지 몰라도 그 원리를 실제 어떻게 응용해야 좋은지, 그리고 어떤 유형의 문제에 더 적합한지를 가르쳐 주지는 못한다.
SICP의 2.4~2.5절은 SICP의 그런 장점을 보여주는 좋은 예다. 이 두 절은 복소수를 예로 들어 다형성 문제를 취급하고 있는데, 무작정 다형성을 소개하는 것이 아니라 ‘한 종류(형, type)의 데이터라도 왜 여러 개의 표현이 필요한지’를 자연스럽게―프로그램 개발 과정에서 요구 변화에 따라오는 필연적 개선 작업으로 설명한다.
복소수는 직각 좌표계에서 표현할 수 있지만 극 좌표계에서도 표현 가능하다. 그런데 이 두 표현 방식은 쓰임새에 따라 어느 한 쪽이 더 유리해질 가능성이 있다. 예를 들어, 복소수를 덧셈/뺄셈할 때는 직각 좌표로 표현하는 것이 좋고, 곱셈/나눗셈에는 극 좌표가 자연스럽다.

◆ 직각 좌표 표현으로 덧셈
c1 + c2 = 실수부(c1 + c2) + 허수부(c1 + c2)i
= (실수부(c1) + 실수부(c2)) + (허수부(c1) + 허수부(c2))i
◆ 극 좌표로 곱셈
c1.c2 = r.e^iA
where r = 크기(c1.c2) = 크기(c1).크기(c2)
A = 각(c1) + 각(c2)

그러므로 단 한 가지 표현만 쓰게 된다면 어느 한 쪽 연산에만 유리하다. 결국 여러 연산에 고루 유리한 복소수 데이터를 만들고자 한다면 여러 표현을 하나의 그릇에 섞을 수 있어야 하며, 이를 사용하는 쪽에서는 그 속사정을 알지 못하도록 가려야 한다. 이 문제를 가장 간단하게 해결하는 방법은 내부에서는 한쪽 표현에 따라 구현하고, 다른 표현은 인터페이스로만 제공하는 것이다. 즉, 다음과 같다.

Let c = x + yi (복소수를 직각 좌표로 표현했을 경우)

실수부(c) = x
허수부(c) = y
크기(c) = sqrt( 실수부(c)^2 + 허수부(c)^2
각(c) = atan(허수부(c), 실수부(c))

이 방법은 극 좌표 표현을 직각 좌표 표현으로부터 계산해 내기 때문에 곱셈 연산을 자주 하는 경우 계산 효율이 크게 떨어진다. 본래 연산에 따라 더 적합한 표현을 선택할 수 있는 ‘표현 선택의 자유’를 제공하려는 목적을 만족시키지 못하지만 우선 사용자 인터페이스를 설계하고 돌려 보는 용도에 적합하다. 그리고 곱셈을 별로 사용하지 않는다고 확신할 수 있다면 이 기법으로도 충분하다. 일단, ‘프로그램은 돌아가고 봐야 된다’는 목표를 달성했으니, 좀더 유리한 표현 기법을 탐구하고 실험해 볼 수 있는 적당한 시간을 번 셈이다.
자, 이제 인터페이스에는 아무런 변화를 주지 않고(복소수를 사용하는 코드에는 아무런 영향을 주지 않아야 된다는 말이다), 서로 다른 연산에 유리한 서로 다른 표현을 한 바구니에 담으려면(하나의 형처럼 취급하려면) 어떤 주문을 외어야 할까? 조사 결과 사용자는 덧셈과 곱셈을 고루 사용하는 것으로 나타났고, 곱셈에 유리한 극 좌표 구현을 제공하지 않으면 계산 효율성을 개선할 수 없다.
SICP는 이런 문제의 해법으로 정책이 전혀 다른 세 가지 프로그래밍 기술인 Tagged Data, Data-Directed Programming, Message-Passing을 소개한다. 그러나 어느 것이 절대 유리하다고 편협한 판단을 강요하지 않는다. 단지, 다음과 같은 질문을 던져 학생 스스로 상황에 따라 유리한 기법을 고를 수 있는 안목을 기르라고 소리 없이 가르친다.

◆ 추가 변동 사항이 없다면 가장 효율 있는 방법은 무엇인가?
◆ 만일 직각 좌표, 극 좌표 외에도 새로운 복소수 표현을 추가할 필요가 있다면 어떤 기법이 가장 유리한가?(즉, 또 다른 표현이 필요하다고 해도 이미 만들어 놓은 코드를 전혀 손댈 필요가 없는 기법은 무엇인가?)
◆ 만일 표현의 종류에는 변화가 없으나 연산을 새로 추가해야 한다면 어떤 기법을 쓰는 것이 가장 유리한가?(즉, 복소수 연산이 더 필요할 때 나머지 코드에 전혀 손상을 가하지 않는 기법은 무엇인가?)

이 문제에 대한 해답은 독자들의 몫으로 남겨둔다.
이제 책 내용에 대한 설명은 접고 SICP의 교육 철학에 대한 얘기를 마무리 짓도록 하자.
SICP가 보기 드물게 훌륭한 예제를 풍부하게 제공한다는 점은 앞에서 이미 얘기했다. 그런데 이 책에서 좋은 예제가 차지하는 역할이 하나 더 있다. 읽기 능력 훈련이 바로 그것이다. SICP는 다른 많은 프로그래밍 연습용 서적처럼 작은 문제를 바닥부터 홀로 만들어 올라가는 방식을 취하지 않는다. 그보다는 어느 정도 규모를 갖춘 예제와 그 예제에 걸맞은 프로그램을 그 구조를 보여주고 이를 완성하거나 개선하는 방식의 문제를 제시한다.
배우는 이가 책이 제시하는 예제를 충분히 이해해 온전히 자기 것으로 소화하지 못하면 문제의 의도는 물론이고 적절한 답을 찾기 어렵다. 이는 좋은 프로그래머라면 주어진 코드를 읽고, 그 동작 방식을 제대로 그려낼 줄 알아야 한다―즉, 프로세스 시각화 능력을 갖추어야 한다―는 교육 의도를 충실히 반영하려는 노력이다.

SICP 현황과 문제점
SICP의 철학과 우수성은 앞에서 충분히(물론 완벽할 수야 없지만) 설명했다고 본다. 이제 그 문제점과 대안을 알아볼 차례가 됐다. 세상에 완벽한 해결책이란 없는 법이다. 우선 이 멋진 책(또는 과정)을 얼마나 많은 대학에서 쓰고 있는지 살펴보자.
현재 SICP를 가르치는 대학은 약 100여개 정도 된다. 나라 별로 그 수가 많은 것부터 늘어놓아 보면 단연코 미국이 가장 많다. 미국은 모두 93개 대학으로 컬럼비아, 코넬, 프린스턴, MIT(당연히) 등이 여기에 포함된다. 그리고 영국에서는 옥스포드를 포함해 총 7개 대학, 독일은 9개 정도다. 이어서 이탈리아와 덴마크가 각 2개, 네덜란드·핀란드·벨기에·스페인이 각 한 개씩인 것으로 되어 있다.
아시아권은 그 수가 적다. 여기에는 우리나라도 물론 포함되어 있다. 일단 일본은 동경대, 싱가포르는 싱가포르 국립대에서 이 과정을 채택하고 있고, 우리나라에서는 KAIST(이광근 교수), 고려대에서 채택하고 있다(그리고 등록되어 있지 않지만 창원대(이수현 교수)에서 SICP를 가르치고 있다는 사실을 들어서 알고 있다). 또한 현재는 다른 과정으로 대체됐으나 한때 부산 동아대학교에서 1995년부터 신입생 프로그래밍 강좌로 이 강좌를 개설해 한 해 5개 강좌 약 300명이 수강하기도 했다.
총 100여개에 이르는 대학이 한 대학에서 개발한 과정을 채택하고 있다고 보면 여전히 많은 축에 속하기는 하지만 예전만큼 ‘강호를 평정’하고 있다고 하기는 어렵다. 지난 10여 년간 SICP를 채택하거나 적어도 Scheme을 실습 언어로 선택하는 대학이 많이 줄어든 것이 사실이다. 이는 많은 대학에서 이 분야의 급격한 기술 변화를 무시하지 못하고 예전처럼 유행하는 프로그래밍 언어를 가르치는 방식으로 돌아섰기 때문에 생긴 결과라 하겠다. 그러나 이런 슬픈 현상을 추세 탓으로만 돌릴 수는 없는 법이다. SICP를 채택한 이후에 겪게 된 여러 가지 문제점이 그런 변절(?)의 빌미를 제공했다고도 볼 수 있기 때문이다.
SICP의 문제점은 2002년에 발표된 참고자료 ?에 비교적 잘 설명되어 있다(SICP 방식의 교육에 깊은 관심이 있는 사람이라면 그전에 참고자료 ?의 논문을 읽어 보는 것이 좋다). 이 논문에서 몇 가지 눈에 띌 만한 것을 나름대로 정리해 보면 이렇다(아마도 SICP를 약 4장 정도까지라도 따라가 본 사람은 이 논문이 주장하는 바를 공감할 수 있을 것이다).
SICP의 가장 큰 문제는 과정 자체가 너무 어렵다는 데 있다. 프로그래밍 자체가 어려운 것이야 당연한 것이지만 프로그래밍 기법을 설명하기 위해 드는 예제들이 문제다.
SICP는 컴퓨터를 전공하는 학생들만을 위한 기초 서적이 아니다. 프로그래밍이 꼭 필요한 분야라면 전공에 관계없이 채택할 수 있는 기초 기술 서적(또는 과정)이다. 특정 분야에 치우침 없이 고루 응용할 수 있는, 다양한 문제와 해법을 다루고 있기 때문에 전산 전반에 걸친 기초 기술 모두를 한 번씩은 짚고 넘어간다고 봐도 틀린 얘기가 아니다.
게다가 완성도가 높아서 분야별 사전 지식(domain knowledge)을 먼저 학습하지 않고서는 문제 자체를 이해할 수 없는 경우가 대부분이다. 균형 잡힌 지도를 받지 못한다면 초심자들은 이 책이 전문 분야 지식과 프로그래밍 기법 중 어느 쪽에 중점을 두고 있는지 알아차리지 못할 가능성이 높다.
처음 배우는 이를 더욱 당혹스럽게 만드는 점은 이 책의 ‘보물찾기’ 식 내용 구성이다. 프로그램 설계를 그 어느 서적보다 중요하게 다루지만 드러내어 떠들지 않는다. 너무 고상한 방법으로 목표를 달성하려고 하다가 선문답식 가르침이 되어버린 셈이다. 가르치고자 하는 모든 것을 예제 속에서 엮어 놓았기 때문에 배우는 사람 스스로 그 참뜻을 찾아내려 애써야 한다.
사실, 학생 대부분은 숨겨놓은 교육 의지(제대로 프로그래밍하기)를 찾아내지 못하고, 표면 지식(이를테면, 언어 그 자체나 특정 응용 분야)에 더 중점을 두기 쉽다. 만일 가르치는 사람조차 그 의도를 충분히 알아차리지 못하면 당연히 이 문제는 더 심각해진다. 내용상의 연계성을 고려하지 않고 교육 의도―‘왜 그렇게 프로그래밍하는 것이 옳은가’를 충분히 전달할 수 없다면, SICP는 주어진 예제를 단순히 풀어내려가는 평범한(그러나 아마도 아주 혹독한) 훈련으로 전락할 수 있기 때문이다(이런 문제 때문에 이 과정을 제대로 이끌어갈 수 있는 교수진을 구성하기도 어렵다).

HTDP와 Dr. Sheme
『How To Design Programs』(이하 HTDP)는 앞에서 설명한 SICP의 여러 가지 문제점, 특히 다음과 같은 문제점을 개선하는 데 중점을 두고 만들어 낸 책(또는 교육 과정)이다.

◆ 특정 분야 지식을 과하게 요구할 뿐만 아니라 그 지식을 설명하는 데 너무 많은 지면을 할애한다.
◆ 프로그램 설계를 드러내 가르치지 않으므로 학생들에게 교육 목표를 제대로 전달하는 데 어려움이 많다.

더 자세한 개발 동기 및 설계 원칙, 교수법 등에 대한 설명은 참고자료 ?에 잘 정리되어 있으므로 참고하기 바란다.
HTDP를 쓴 저자들은 모두 PLT(Programming Language Technology, http://www.plt-scheme.org/who)라는 단체의 구성원들이다. PLT는 다양한 Scheme 구현을 제공할 목적으로 만든 자원 단체로 현재 EdScheme 또 MzScheme 등을 개발해 배포하고 있다. 특히 이 그룹에서 개발한 Dr. Scheme은 재미있는 소프트웨어다. Dr. Scheme은 여러 Scheme 구현 위에 돌아가는 일종의 Scheme IDE라 할 수 있는데, 애초부터 교육 용도로 개발된 것이다. 그래서 프로그래밍 훈련의 재미와 효과를 높일 수 있는 여러 가지 기능을 갖추고 있다. SICP 같은 과정과 Dr. Scheme 같은 실습 소프트웨어는 정말 찰떡궁합이라 할 수 있다.

HTDP와 우리 프로그래밍 교육
필자는 우리나라의 많은 교육 기관이 이론 교육과 실무 기술 교육 사이의 균형점을 찾지 못하고 우왕좌왕하고 있다고 생각한다. 컴퓨터 공학(과학)과 정보 처리학은 엄연히 다른 것인데도, 하나의 과정 속에 분별없이 섞어놓고, 학생들이 어디로 가야 할지 해답의 실마리를 쥐어 주지 않는다. 취업 문제로 고민하는 학생들에게 나름대로 해결책을 제시하기 위해 실무 기술을 가르치겠다는 의지 자체는 충분히 공감하는 바다. 그러나 기존 교육 체계는 그대로 두고서 실무 기술 교육을 강화하겠다는 것(교육 내용만 살짝 바꿔치기하겠다는 것)은 헛된 바람이다.
『The Pragmatic Programmer』(참고자료 ?)의 서문에 쓰인 말대로, 개발자 능력은 기초 컴퓨팅 이론 바탕 위에 다양한 실무 프로젝트를 개발하는 경험이 쌓여서 배양된다. 설령 철저한 실무 교육을 목표로 하는 교육 기관이라 할지라도 기초 이론 교육을 무시한다면 좋은 인력을 길러낼 수 없고, 이론 교육이라고 해도 실무 기술과 연계성을 주의 깊게 고려해 가르치지 않으면 쓸모 있는 바탕 교육이라 할 수 없다.
이런 점에서 HTDP가 추구하는 프로그래밍 교육의 원칙은 주목할 만하다. 프로그래밍의 원리 교육과 실무 기술 훈련이 하나의 과정 속에 어떻게 배치되어야 하는지 한 가지 해법을 제안하고 있기 때문이다. 참고자료 ?은 HTDP가 추구하는 프로그래밍 교육 목표를 다음과 같이 기술하고 있다.

변하는 기술 환경에 빠르게 적응할 수 있고, 수십 년 동안 소프트웨어 관련 직종에서 살아남을 수 있는, 유능한 소프트웨어 개발 인력을 양성하는 것이 프로그래밍 교육의 목표다.

너무 뻔한 얘기라서 식상하기까지 하지만, 우리네 교육기관 중 저 목표를 향해 땀 흘려 달리는 곳이 과연 몇 군데나 될까? 참고자료 ?에서는 이와 같은 교육 목표를 달성하기 위해 다음과 같은 구조로 교육 과정을 구성하는 것이 바람직하다고 주장한다. 이 제안에 따라 교육 과정을 그려보면 <그림 1>이 나온다.

프로그래밍 커리큘럼은 근본 원리를 가르치는 데 중점을 두어야 한다. 그리고 첫 해 두 번째 학기와 마지막 학년에서 산업이 요구하는 기술에 적응할 수 있도록 실용 기술을 훈련한다.

이와 같은 제안이 우리네 교육 기관이 처해있는 여러 가지 문제를 정말 해결해 줄 수 있는지를 함부로 판단할 수는 없는 법이다. 그러나 SICP나 HTDP와 같은 해법이 프로그래밍 기술의 본질을 바로 알고 더 나은 프로그래밍 교육을 시도하는 가치 있는 실천임에는 의문의 여지가 없다고 믿는다.

독자에게 드리는 선물
여기까지 글을 읽어준 독자에게 몇 가지 선물을 드릴까 한다. 이 글에서 소개한 두 권의 책은 모두 웹에 전문이 올라와 있다.

◆ http://mitpress.mit.edu/sicp/
◆ http://www.htdp.org

앞에서도 말한 바 있지만 SICP를 제대로 익히려면 좋은 선생이 필요하다. 한데 다행스럽게도(그리고 매우 고맙게도) 저자(Harold Abelson) 및 다른 MIT 교수진의 SICP 강의를 동영상으로 보고 들을 수도 있다.

◆ http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/

강의도 들을 수 있고 책도 마련했으니 이제 실습용 프로그래밍 환경만 있으면 완벽하다. 이왕 책이 권하는 대로 Scheme을 써보기로 했다면, 다음 주소에서 Dr. Scheme을 내려받을 수 있다(실습 언어로 꼭 Sheme을 써야 하는 것은 아니지만, 다른 언어를 쓴다고 해도 책을 읽고 예제를 풀기 위해 Scheme 코드는 정확히 읽고 이해할 수 있어야 한다).

◆ http://www.drscheme.org

이제 이 공개된 보물지도로 보물을 찾아 나설지 말지는 온전히 독자의 몫이다.

http://blog.naver.com/javava94/120022332758

컴파일시에 -source 옵션으로 1.4버전으로 컴파일이 가능합니다....

javac -source 1.4 Test.java

http://korea.gnu.org/people/chsong/copyleft/gpl.ko.html
http://korea.gnu.org/people/chsong/copyleft/lgpl.ko.html

링크는 GPL과 LGPL의 한글 번역문입니다.

1. GPL(General Public License) 개요
- GNU의 두 가지 라이센스 중의 하나로 라이브러리, 프로그램에 모두 적용된다.
- GPL을 가진 프로그램(라이브러리 포함)을 포함해서 제작된 프로그램 역시 GPL을 준수해야 한다.
- GPL을 가진 원시 코드를 사용하는 것을 GPL에 동의한 것으로 간주한다.
- 프로그램(라이브러리 포함)의 원시 코드와 목적 코드가 같이 배포되어야 하며, 목적 코드만 배포될 경우, 원시 코드를 인터넷(FTP 포함)으로 다운로드 받을 수 있도록 조치해야 하며, 배포판에 원시 코드를 다운로드 받을 수 있는 주소를 명시해야 한다.
- GPL을 선언한 프로그램은 무료로 배포되어야 하며, 배포를 위한 비용(프로그램에 대한 비용이 아님)을 청구하는 것은 GPL에 위반되지 않는다.

2. LGPL(Lesser General Public License) 개요
- 라이브러리에만 적용되는 라이센스로 1992년 Library General Public License에서 Lesser General Public License로 명칭이 변경되었다.
- 라이브러리의 보다 범용적인 활용을 목적으로 만들어졌으며, GNU C 라이브러리도 LGPL을 따른다.
- 독점 프로그램에 사용할 수 있으며, 사용자는 라이브러리에 대한 의무만 준수하면 된다. 준수 항목은 GPL과 동일.
- 라이브러리를 개작한 저작물은 반드시 소프트웨어 라이브러리여야 하며, 저작물 역시 LGPL을 가지게 된다.
- 어떤 프로그램이 라이브러리와 함께 링크된다면, 라이브러리가 정적으로 링크되든지 공유 라이브러리로 사용되든지 간에 이 두 개의 조합은 법적으로 말할 때 결합 저작물, 즉 최초의 라이브러리로부터 파생된 2차적 저작물로 간주됩니다. GPL은 이러한 형태의 링크가 일어날 경우에 결합된 전체 저작물이 GPL을 만족할 때에 한해서만 링크를 허용합니다. 그러나 LGPL은 보다 유연한 링크 조건을 허용하고 있습니다. – ‘GNU LGPL’ 발췌 –

3. 공통 사항
- GNU 라이센스로 원시 코드 공개 및 무료 배포(인터넷을 통한 배포가 아닌 경우, 피양도자가 배포 비용 부담)를 목적으로 하고 있다.
- 배포 시 피양도자에 코드에 대한 모든 권한이 양도된다.
- 배포판에 라이센스에 대한 명시를 해야 하며, 라이센스 허가서(영문판)를 포함해야 한다.
- 라이센스를 가지고 있는 원시 코드를 사용하는 것만으로도 라이센스에 동의한 것으로 간주한다.
- 원시 코드를 개작할 때도 라이센스는 유효하며, 개작된 저작물도 동일한 라이센스를 가진다.

4. 다른점
- GPL이 모든 프로그램(라이브러리 포함)에 적용되는 데 반해, LGPL은 라이브러리에 국한된다.
- LGPL은 GPL로 변경될 수 있지만, 한번 GPL로 선언된 원시 코드는 LGPL로 변경할 수 없다.
- LGPL을 가진 라이브러리는 독점 프로그램에 사용할 수 있으며, 라이브러리를 사용했다하더라도 프로그램에는 LGPL이 적용되지 않는다. 즉, 프로그램 자체의 코드를 공개할 의무는 없음.

 2008년 6월 25일로 eclipse 3.4 버젼인 Ganymede 가 발표되었다. eclipse 는 정말 다양한 곳에서 쓰이고 있는데 생각보다 3.4 의 발표에 대한 관심이 적은 듯 하다. 아마 지금도 충분히 만족하면서 써서 그런듯 하다(?)

 정말 광범위하게 쓰이기는 하지만 아직 eclipse 는 Java 의 개발툴이라는 인식이 강한데 사실 CDT 플러그인의 덕택으로 C/C++ 에 대한 지원도  상당히 잘되는 편이다. Java 로 만들어져서 꽤 느린감도 있지만 이제 꽤 쓸만한 수준이다.

 다음 2개의 링크에서 eclipse 3.4/Ganymede 의 새로운 기능 중 쓸만한 것들을 뽑아서 번역해보았다.

 * [Eng] eclipse 3.4 의 새로운 기능
 * [Eng] CDT 5.0 의 새로운 기능
 

전체
 - Editor 탭을 마우스 가운데 버튼 클릭으로 현재 문서를 닫을 수 있음
 - 찾기/바꾸기에서 정규식을 쉽게 쓸 수 있게 되었음
 - debugging 시에 변수를 watch 창으로 Drag & Drop 가능

CDT 5.0
 - file template 기능을 통해 New Class 를 했을 때 기본 코드를 지정할 수 있음
 - include 를 할 때 Ctrl+Space(Content Assist) 를 하면 쉽게 include 파일명을 넣을 수 있음
 - for, while, if 문등의 block 도 folding 할 수 있음
 - 단축키 설정에서 Scheme 에 "Microsoft Visual Studio" 가 추가되어 쉽게 단축키 설정을 할 수 있음
 - Rename 밖에 없던 C++ Refactoring 기능에 다음과 같은 기능들이 추가되었다.
  - Getter/Setter 생성
  - 함수 숨기기(private 로 이동)
  - Implement Method(함수 선언부에서 선택시 함수 구현부 생성)
  - Extract Constant
  - Extract Function
 - Indexer 향상(여러 상황 지원, 속도 향상)
 - Ensure newline at end of file 옵션이 기본적으로 켜져 있어서, 파일의 마지막 줄에 빈 줄을 넣지 않아서 warning 이 뜨는 현상을 위해 옵션을 고치지 않아도 된다.

자바
 - 숫자를 따로 하이라이트해준다.
 - 변수를 읽기/쓰기 하는 부분을 따로 표시할 수 있게 해준다(디버깅할 때 편할듯)
 - 멀티CPU 를 통해 30% 까지 속도 향상이 있다.
 - Java String 을 StringBuffer 로 컨버트

SWT
 - 3개의 상태를 가지는 체크 버튼(on/off 외에 중간 상태가 추가)
 - 윈도우 비스타에서의 native progress bar 지원
 - 이미지와 url 에 대한 Drag & drop 지원
 - 전체 화면 지원
 - 투명도(Alpha, Transparent) 지원

기타
 - (Beta인 셈이지만)Subversion 을 위한 Provider 제공(Help -> Software Updates -> Available Software 에서 Ganymede Update Sites -> Collaboration Tools -> SVN Team Provider 에서 설치)