폭스바겐 Lisp
Posted by 大山 Sat, 06 Jan 2007 06:57:00 GMT
Lisp 프로그래밍 언어의 유연함을 폭스바겐 비틀에 빗대어 표현했네요. 보시다가 내용이 잘 이해가 안되는 부분이 있으면, 댓글로 물어보셔도 좋습니다. :)
JSON vs XML
Posted by 大山 Tue, 26 Dec 2006 23:30:00 GMT
지난 9월쯤에 XML에 태클을 거는 글을 쓴적이 있었습니다. 그에 이어지는 글에서도 많은 분들이 토론에 참여해 주셔서 저도 생각의 폭을 넓히는 계기가 되었구요. (그때의 토론을 기반으로 제가 짧은 글을 마소에 기고하기도 했습니다.)
이제 미국쪽 블로고스피어에서도 비슷한 토론이 시작된 것 같습니다. 관심있으신 분들은 참고하시면 좋을 것 같습니다.
루비 vs PL/I
Posted by 大山 Fri, 17 Nov 2006 17:53:00 GMT
최근에 한 시중 은행의 전산망을 총괄하시는 부장님을 만나뵐 기회가 있었다. 일반 엔터프라이즈 환경이야 특별히 궁금할 것도 없지만, 엔터프라이즈 중에서도 가장 보수적이라는 은행의 전산망 인프라는 예전부터 궁금해했던 참이라 신나게 이것저것을 여쭤볼 수가 있었다.
여기서 질문 하나. 은행의 전산실에서 주로 쓰이는 프로그래밍 언어는 무엇일까?
자바? 땡!
C++? 땡!
정답은 PL/I과 COBOL이다.
올해 초에 한 네덜란드 PL/I 개발자와 작업을 같이 한적이 있는데, 사실 그전까지는 나도 PL/I이라는 언어가 있는지도 몰랐었다. PL/I은 1960년대 초에 COBOL과 Fortran의 역할을 하나의 언어에서 해결하기 위해 IBM에서 만든 언어로, 은행의 전산실에서 PL/I이 많이 쓰이는 것은 아마도 IBM 메인프레임이 아직도 많이 사용되기 때문인 듯.
여기서 질문 하나 더. 왜 은행에서는 아직도 유닉스 서버 대신에 메인프레임이 사용되는 것일까?
답: 유닉스 서버는 다운이 잘되서.
윈도우에 비하면 철옹성같아 보이는 유닉스도 은행의 기준에서는 다운이 잘되는 편이라니, 할말을 잃었음. 최근에는 유닉스도 충분히 안정적이라는 판단이지만, 아직은 업체들의 지원 수준이 미덥지 못하다고 한다.
이번에는 다소 쉬운 질문. 은행에서 주로 사용되는 데이터베이스 서버는?
답: 오라클이 대세. Sybase도 가끔 눈에 띄는 정도. DB2는 찾아보기도 힘들다고.
1959년에 나온 COBOL과 1964년에 나온 PL/I이 아직도 지배하는 은행의 전산실, 과연 이곳에 변화의 기미는 없을까? 그렇지만은 않다고 한다. 요새는 PL/I 인력이 전혀 양성되지 않는 이유로 신규 인력은 모두 내부적으로 교육을 하는데, 요즘의 젊은 개발자들은 PL/I을 배우길 꺼려한다고.
Web 2.0이다 Ajax다 해서 나날이 변해가는 웹 개발에 비하면, 조선시대 만큼이나 먼 옛날의 기술이 아직도 점령하고 있는 은행의 전산실이지만, 시스템 안정성을 최우선하는 그곳의 보수적인 문화에서 배울 점도 적잖이 있었다. 데스크톱 애플리케이션이 다운되듯이 전산망이 다운된다면 큰일일테니 말이다. ;)
나의 루비 이야기에 아직도 프로그래밍 언어에 그만한 발전의 여지가 남아 있었냐고 놀라워 하시던 그분도 루비의 계보가 Lisp과 Smalltalk로 이어진다는 말에는 곧 고개를 끄덕이셨다. 언어는 달라도 SQL을 사용해서 데이터베이스 프로그래밍을 하는 것은 크게 다르지 않아, 레일스의 생산성이 어떻게 가능한지를 설명하는 것도 생각보다 어렵지는 않았다.
반세기에 가까운 기술의 간극에서 이런 대화가 가능하다는 것이 기술이 얼마나 빨리 변하는지를 웅변해 주는 듯한 느낌이다. 뭐 이미 루비로 구현된 신용카드 결제 모듈도 여럿 있는데, 언젠가는 은행의 전산실에서 루비가 쓰이는 것도 아주 꿈만은 아닐지도. :)
실용적 함수형 프로그래밍 세미나 후기
Posted by 大山 Sat, 14 Oct 2006 17:49:00 GMT
오늘은 실용적 함수형 프로그래밍 세미나에 다녀 왔다. 대안언어축제 2006에서 같은 방을 사용했던 유재명님이 '다시 보는 디자인 패턴' 그리고 'Parsec 사용법 가이드'라는 주제로 발표를 하셨는데, 역시 Haskell은 매력적인 언어라는 생각이다. 대안언어축제때 재명님께 pair로 가르침을 받은 덕분에 이제 왠만한 Haskell 코드는 대강 이해가 가더라는~ :D
얼마전에 Mark Dominus가 1972년의 디자인 패턴이라는 글에서 디자인 패턴 무용론을 주장하여 한동안 영어권 웹에서 논쟁이 후끈 달아오르기도 했지만, GoF 책에 소개된 디자인 패턴 중 상당수가 자바나 C++의 언어적 제약을 극복하기 위해서 고안된 것만은 분명해 보인다. '다시 보는 디자인 패턴'은 Haskell과 같은 함수형 프로그래밍 언어에서 어떻게 많은 디자인 패턴이 패턴이라는 이름이 무색할 정도로 손쉽게 코딩될 수 있는 지를 잘 보여주는 발표였다.
두번째 발표였던 'Parsec 사용법 가이드'도 무척 흥미로웠는데, Parsec 같은 라이브러리만 있으면 왠만한 파서의 구현은 무척 간단한 작업이라는 생각이 들었다. 루비 코드 파서를 구현해보는 것도 그리 어려운 일은 아닐듯.
Haskell이 메인스트림 언어가 되지는 못할 것이라는 재명님의 언급이 있었지만, 길게 내다보는 개발자라면 함수형 프로그래밍 언어 한둘은 익혀야 한다는 생각이다. 멀리가지 않고 루비만 제대로 익히려 해도, 함수형 언어의 개념들이 필수적이다. 이론적인 것을 좋아하는 사람이라면 Haskell, 쉽게 배우고 싶다면 Lisp, 실무에 활용하고 싶다면 OCaml 등을 공부해 보는 것은 어떨까?
다른 약속이 있어서 마지막 발표인 'C++ 함수형 프로그래밍'은 참석하지 못했다. 다소 아쉽긴 했지만, 이건 다른 분들의 후기를 참고해야 할듯.
Re: 내가 XML을 싫어하는 이유
Posted by 大山 Tue, 12 Sep 2006 17:44:00 GMT
내가 XML을 싫어하는 이유에 답글을 쓰다가 너무 길어지는 것 같아 별도의 글로 엮어 봅니다.
우선 XML, Lisp 리스트, 해시 리터럴, JSON, YAML 등은 모두 트리형 데이타를 기록하기 위한 포맷입니다. 이 점에서 이들 포맷은 모두 같은 위상을 가지고 있습니다. 이들은 모두가 다 구조적이며 얼마든지 확장이 가능하지요. (XML의 차이점은 이렇게 확장된 포맷을 DTD, XML Schema, RELAX NG 등으로 엄밀하게 정의할 수 있다는 점인데, 이 때문에 validation도 가능합니다.)
XML 포맷의 가독성이 떨어지는 이유는 크게 두가지인데 첫째로는 오픈(open) 태크와 클로즈(close) 태그에서 태그 이름이 중복되어 표시되고 있고, 둘째로는 자동으로 생성된 XML 마크업 코드의 Indentation이 임의적이 경우가 많기 때문이죠. 물론 attribute 값을 표시하는 방법이 두가지인 등, 불필요하게 복잡한 요소가 있기도 하구요. 저는 XML의 가독성 문제가 기본적으로 신택스에 있다고 생각합니다.
네임스페이스가 구분되어 있다보니까, 한 파일에서 여러 XML 규격을 mix & match하는 것이 가능한데, 과연 이게 필요한 것인지 저는 다소 회의적이네요. 새로 합쳐진 통합 규격을 지원하는 애플리케이션이 아니라면, 어짜피 이런 포맷을 처리할 수는 없겠죠. 이러한 애플리케이션 군이 필요하다면 서민구님이 언급하신 것처럼 두가지 XML 규격이 합쳐진 새로운 규격을 만드는게 더 적합한 해결책이라고 생각합니다.
포맷 validation과 HTML 렌더링이 브라우저마다 달라지는 이슈는 별도의 문제인 것 같습니다. 렌더링이 달라지는 것은 브라우저마다 각 태그를 렌더링할 때 사용하는 default 값이 다르기 때문으로, validation으로 해결될 문제는 아니라는 생각입니다. validation이 체크해 주는 것은 신택스일 뿐이고, 시맨틱적인 해석에는 별 도움을 줄 수 없지요. 사실 DTD 등이 없이도 기본적인 XML 신택스는 검증할 수 있기 때문에, 실질적인 validation의 역할은 해당 파일에서 허가된 키워드만을 쓰고 있느냐를 확인하는 역할에 제한됩니다.
이원구님의 말씀처럼 XML이 복잡해진 이유는 범용적이기 때문이라고 생각합니다. 지나치게 범용적인 도구는 막상 적합한 용처가 드물 수 있지요. XML의 장점은 분명하지만, killer 애플리케이션이 그렇게 많지는 않은 것 같습니다.
공성식님께서 YAML의 장점과 단점을 잘 지적해 주셨는데, 사실 제가 하고 싶었던 이야기도 크게 다르지 않습니다. 상황에 따라 여러 적합한 포맷이 있는데 맹목적으로 XML을 고집하지는 말자는 것이죠. 설정파일에는 YAML이 편리하지만, 문서 파일에는 YAML이 적합하지 않을 수 있습니다. (depth-level 변경 정도는 텍스트 편집기에서 지원할 수 있지 않을까요?) 빌드 파일에서는 rake처럼 아예 프로그래밍 코드를 직접 사용하는게 더 편리하다는 생각이고, Ajax에서는 JSON의 사용이 더 자연스럽다고 생각합니다. 애플리케이션에서 데이타를 저장할때는 그냥(오픈 형식의?) 바이너리 파일을 사용하는 것이 어떨까요? 파일이 열리는 속도가 훨씬 빨라질텐데 말이죠.
자바 프레임워크의 설정 파일, ant의 빌드 파일, Ajax에서의 XML, 애플 Keynote의 파일 포맷, SOAP 등은 모두 XML을 잘못 활용한 예였다고 생각합니다. 반대로 RSS, DocBook 등의 경우에는 XML이 딱이라는 생각이 들더군요. 다른 분들의 생각은 어떠신지요? :)
관련글: JSON vs XML
내가 XML을 싫어하는 이유
Posted by 大山 Sat, 09 Sep 2006 13:45:00 GMT
내 생각에 XML이 가져온 효과는 단 한가지이다. 바로 오픈 포맷의 확산에 기여했다는 것. 그런데 그렇게 확산된 오픈 포맷이 하필 XML이라는 것은 다행중 불행인 것 같다.
우선 XML 마크업은 가독성이 매우 낮다. XML의 주요 설계 목적 중 하나가 사람 눈에 읽힐 수 있어야 한다는 것이었는데, 말 그대로 읽히기만 한다. 차라리 Lisp 코드의 가독성이 더 나을듯.
XML을 둘러싼 hype이 워낙에 거셌다 보니까, ant처럼 빌드 파일 포맷에 XML이 사용되기도 하고, 각종 설정 파일에도 XML이 단골이다. 개중에는 SOAP처럼 원격 프로시져 호출에 XML을 사용한 경우도 있다. 그런데 사실 따지고 보면, XML 포맷이란 트리 구조의 데이타를 단순히 텍스트 형태로 나타낸 것에 불과하다. 트리 구조를 표현하기에 적합한 텍스트 포맷은 XML 말고도 여럿 있다. 위에서 살짝 언급한 Lisp의 리스트도 좋은 예이고, 해시 리터럴(literal), YAML, JSON 등도 있다. 이들은 가독성도 뛰어나고, 파싱도 쉽고, 처리속도도 빠르고, 저장 공간도 더 적게 차지한다.
물론 XML에는 네임스페이스나 문서 검증 기능도 있지만, 자바에서 네임스페이스 충돌을 원천적으로 막겠다고 네임스페이스 이름에 도메인 주소를 집어넣는 만행을 저지른걸 떠올려 보면, XML의 네임스페이스도 다소 오버한 느낌이다. 지난 10여년간 HTML이 발전해온 과정을 보면 문서 검증 기능도 그다지 중요한 것 같지는 않고.
결과적으로 XML은 가독성도 나쁘고, 핸드 코딩도 힘들고, 파싱도 복잡하고, 처리속도도 느리다. 과연 XML은 어디에 유용할까?
자바 7은 클로저를 지원할 듯
Posted by 大山 Sun, 20 Aug 2006 06:14:00 GMT
자바 7에서는 드디어 클로저를 지원하려나 보다. 지금이 자바 5이니, 자바 7이 언제 나오게 될지는 모를 일이지만.
모르는 분들을 위해 살짝 귀뜸하면, 클로저(Closure)는 코드 중에 함수를 직접 정의해서 객체로 변환시킨 걸 이르는 용어이다. 우리말로 하면, 익명 함수 정도가 될까? 흥미로운 건 이걸 다른 메소드에 인자로 넘길 수 있다는 거다. 예를 들면, 다음과 같은 식이다.
>> [1, 2, 3, 4, 5].map(&lambda {|i| i * 3})
=> [3, 6, 9, 12, 15]
위에서 lambda { ... } 부분이 클로저인데, 이는 i에 해당하는 수를 넘겨주면 그의 3배수를 리턴하는 익명 함수 객체이다. 위의 코드에서는 이 클로저를 배열의 map 메소드에 인자로 넘겨주고 있다. map 메소드는 배열의 각 원소에 넘겨받은 클로져를 적용해서, 새로운 배열을 만들어 리턴해준다. 이를 보다 루비스럽게 작성하면 다음처럼 되겠다.
>> [1, 2, 3, 4, 5].map {|i| i * 3}
=> [3, 6, 9, 12, 15]
루비에서는 클로저란 어려운 이름 대신, 이를 블록이라고 부른다. 다른 예를 하나 들어보자.
>> ["banana", "kiwi", "apple", "water melon"].sort
=> ["apple", "banana", "kiwi", "water melon"]
위의 코드에서 sort 메소드는 배열의 원소를 알파벳 순서로 정렬해준다. 그런데 sort에 블록을 붙여주면 정렬 법칙을 바꿀 수 있다. 다음 코드를 한번 보자.
>> ["banana", "kiwi", "water melon", "apple"].sort {|i, j| i.length <=> j.length}
=> ["kiwi", "apple", "banana", "water melon"]
위에서는 문자열의 길이를 비교하는 블록을 sort 메소드에 넘기고 있다. 결과적으로 리턴되는 배열도 문자열의 길이대로 정렬되어진다.
자바 5에서는 generic이 추가되더니 7에서는 클로져를 지원하는 등 자바도 갈수록 루비스러워지는 듯. 자바 7을 기다리는 그대 지금 루비로 오라. ;)
객체지향 프로그래밍에 대한 오해와 진실 2
Posted by 大山 Thu, 17 Aug 2006 07:56:00 GMT
[참고: 이 글은 객체지향 프로그래밍에 대한 오해와 진실에 이어지는 시리즈임.]
객체지향 언어에 대한 입문서를 보면, 상속, 캡슐화, 다형성 외에도 빠지지 않고 등장하는 설명이 하나 있다. 바로 객체는 실제 세상(Real World)의 물체를 모델링한다는 것이다. 물론 이 내용을 다루는 챕터는 모든 객체가 실제 세상의 물체와 대응될 필요는 없다며 어물쩍 마무리를 하기 마련이지만 말이다.
실제 세상에 대한 모델링이란 주장은 얼핏 객체의 필요성에 대한 그럴듯한 설명인 것 처럼 보이지만, GUI 프로그래밍이나 시뮬레이션 설계를 하는게 아니라면 전혀 맞아들어가지 않는 설명이다. 오히려 이 때문에 일부 뛰어난 해커들마저 OOP를 오해하는 경향이 있기 때문에 여기서 짚고 넘어가려고 한다.
객체지향 프로그래밍에 대한 또 한가지 오해는 상속이 코드 재사용의 핵심이라는 말이다. 이는 다분히 과장된 주장이라고 보여진다.
마지막으로 모든 객체지향 언어에 해당되는 것은 아니지만, 많은 개발자에게 '객체지향 언어 == C++ 또는 자바'로 받아들여지므로 이 내용을 같이 다루어도 좋을 성 싶다. 바로 스태틱 타이핑(Static Typing)이 버그를 줄여준다는 오해이다.
하나씩 짚어보자. 어쩌다가 객체지향 언어는 실제 세상의 물체를 모델링한다는 설명이 생기게 되었을까? 바로 최초의 객체지향 언어였던 Simula가 시뮬레이션 용으로 만들어진 언어였기 때문이다. 하지만 여기서 주의할 점은 Simula는 1960년대에 나온 프로그래밍 언어였다는 점이다. 실제로 1971년에 나온 Smalltalk-71은 Simula에서 객체에 대한 메세지 보내기 개념(즉 데이타와 함수를 묶어두는 방식)만 따와서 구현된 것으로 알려져 있다.
시뮬레이션 또는 GUI 프로그래밍에서는 객체지향 프로그래밍이 무척이나 자연스럽게 느껴지는 것이 사실이다. 하지만 프로그래밍의 범주는 이보다 훨씬 더 넓고, 객체지향(데이타에 함수 묶어두기) 프로그래밍은 꽤나 보편적으로 유용하다.
두번째로 상속과 코드 재사용성 부분인데, 상속을 통해서 코드 재사용을 추구하는 것은 프레임워크에서 제공하는 템플릿 클래스를 사용하는 등의 상당히 제한된 경우에만 적합한 것 같다. 이 때문에 Objective-C를 사용하는 Cocoa 같은 프레임워크에서는 조합(Composition)과 위임(Delegation)의 사용을 훨씬 더 강조하고 있다.
그런데 왜 상속을 통한 코드 재사용이 그토록 강조되는 것일까? 아마도 마케팅의 영향이 아닌가 싶다. C++와 자바는 모두 업계 주도적으로 확산된 언어이다. 마케터들은 실제로 중요한 것 보다는 사람들의 머리속에 각인될만한 내용으로 마케팅을 전개하기 마련이다. 이 마케팅이 너무 성공적이어서 수많은 개발자들을 헤매이게 만들기는 했지만 말이다.
마지막으로 스태틱 타이핑 부분인데, 스태틱 타이핑이 컴파일 최적화에 도움을 주기 때문에 프로그램의 성능을 높여주는 것은 사실이다. 무어의 법칙때문에 나날이 덜 중요해지는 요소이기는 하지만 말이다. 하지만 스태틱 타이핑이 개발자의 실수를 방지해서 버그를 줄여준다는 말은 낭설에 가까운 것 같다.
스태틱 타이핑의 옹호자들에게 물어보라. 당신들은 스태틱 타이핑이 자신들의 실수를 줄여준다고 생각하느냐고. 그들은 이렇게 말한다. 자신들은 그런 초보적인 실수를 안하지만, '평균'적인 개발자에게는 그런 안전장치가 필요할 것이라고. 사용자들이 멍청할 것이라고 가정하는건 개발자들이 범하는 가장 흔한 실수 중의 하나이다. 일부 프로그래밍 언어의 설계자들 역시 비슷한 오류에 빠졌던 것은 아닌가 싶다.
객체지향 프로그래밍에 대한 오해와 진실
Posted by 大山 Wed, 16 Aug 2006 08:14:00 GMT
많은 개발자들이 OOP(객체지향 프로그래밍, Object Oriented Programming)를 처음 접하는 것은 아마도 C++나 자바를 통해서일 것이다. 보통 C++/자바 입문서는 OOP란 무엇인가를 설명하는 챕터로 시작되기 마련인데, 하나같이 객체지향 프로그래밍의 핵심을 상속(Inheritance), 캡슐화(Encapsulation), 다형성(Polymorphism)이라고 설명하고 있다.
나중에 Objective-C, Smalltalk, 자바스크립트 등을 접하면서 이같은 설명이 얼마나 엉터리인지 깨닫게 되었다. 이 글에서는 내가 지난 수년간 객체지향 프로그래밍에 관해서 이해하게 된 것을 한 번 정리해 보려고 한다.
조금 규모가 있는 프로그램을 작성하다 보면, 가장 골치아픈 이슈 중의 하나가 소스코드의 복잡성을 관리하는 문제이다. 변수와 함수의 이름을 일관적으로 정리하고 전체 소스코드에 체계적인 구조를 잡아두지 않으면, 자신이 직접 작성한 코드를 들여다 보는 것 조차 막막해지기 십상이다.
프로그래밍 언어는 이러한 소스코드의 복잡성을 보다 체계적으로 관리할 수 있는 방향으로 발전해 왔다. 초기의 프로그래밍 언어에는 함수 개념 조차도 빠져 있었다. 함수는 프로그램을 유닛 단위로 나누어서 관리하기 위해 만들어진 가장 기초적인 개념이다. 루프, 조건문, 케이스문 등 역시 프로그램을 보다 체계적으로 작성하기 위해 생겨났는데 과거에는 이들 대신에 GoTo문이 사용되곤 했었다.
그런데 점차 프로그램에서 사용되는 함수의 수가 늘어나자, 함수의 이름과 그 소스코드를 관리하는 일이 커다란 문제가 되어버렸다. C나 PHP로 개발을 해 본 사람은 잘 알겠지만, mysql_field_name(), mssql_field_name() 식으로 함수 이름 마다 접두사(Prefix)가 필요한 데다가, mb_strlen(), ob_get_length(), mysql_fetch_lengths() 처럼 함수 이름을 명명하는 방식은 개발자마다 제각각이게 마련이다. mailparse_determine_best_xfer_encoding() 처럼 함수 이름이 한도없이 길어지는 문제는 두말할 필요도 없겠다.
객체지향 프로그래밍은 바로 이러한 문제에 대한 해결책을 제시했다. 함수를 아예 데이타에 묶어서 관리하면 그 이름이 짧아지게 될 뿐더러, 함수의 소스코드 또한 데이타 구조의 정리체계에 따라 관리가 가능하다는 것이 바로 객체지향 프로그래밍의 핵심이다. 객체지향 프로그래밍에서는 이렇게 데이타에 묶여진 함수를 메소드(method)라고 부른다.
물론 데이타에 묶어서 관리하는 것이 자연스럽지 못한 함수도 적지 않은게 사실이다. OOP 언어에서는 데이타(객체)에 묶어두기에 적합하지 않은 함수를 클래스나 모듈에 묶어 관리하는 방식으로 이 문제를 비켜가고 있다. 클래스는 함수 이름 관리를 위한 적절한 네임스페이스를 제공해 주기도 하기 때문에, 객체에 묶이지 않은 함수의 경우에도 함수 이름과 그 코드의 관리가 한결 수월하게 되었다.
이 글의 시작에서 언급했던 내용을 다시 한 번 살펴보도록 하자. OOP를 설명하는 일반적인 방법은 상속, 캡슐화, 다형성 등의 개념을 통해서이다. 그런데 캡슐화란 프로그래밍에서는 너무도 보편적인 개념인 추상화(Abstraction)의 또다른 표현일 뿐이고, 다형성은 함수 이름에서 접두사(Prefix)가 빠진다는 것을 어려운 용어로 표현한 것에 불과하다. 상속 조차도 객체지향 시스템을 설계하는 하나의 방식에 불과해서, 자바스크립트 같은 언어에서는 상속 대신 프로토타입(Prototype)이라는 전혀 다른 개념을 사용하고 있다.
객체지향이란 함수를 관리하는 하나의 프로그래밍 기법에 불과할 뿐이다. 매우 효과적이고 편리한 방법임에는 틀림이 없지만, 그렇게 거창하지도 또 이해하기에 복잡한 개념도 아니다.
오픈소스가 바꾸어 놓은 것
Posted by 大山 Mon, 24 Jul 2006 01:44:00 GMT
오픈소스가 가져온 변화는 물론 한두가지가 아니다. 여기서는 프로그래머 입장에서 보았을 때 오픈소스가 게임의 법칙을 어떻게 바꾸어 놓고 있는 지를 한 번 살펴보려고 한다.
오픈소스의 일차적인 효과는 무료로 수많은 프로그램을 사용할 수 있게 되었다는 점, 그리고 해당 프로그램의 소스코드를 들여다 볼 수 있게 되었다는 것이다.
물론 컴퓨터를 쓰다가 커널 패닉이 났다고 해서 리눅스 커널을 디버깅 하겠다고 덤비는 개발자는 많지 않을 것이다. 하지만 라이브러리를 사용하려다가 한글 지원이 미비한 것을 보고 유니코드 인코딩 지원을 추가 하는 정도는 어떨까? 프레임워크를 신버젼으로 업데이트 했을 때, 호환이 안되는 구버젼 라이브러리 코드를 업데이트 하는 정도라면?
실제로 해보니까 별 것 아니더라. 필요한 프로그램을 찾아 쓰고, 고쳐서 쓰고 하다 보면, 나중에는 왠만한 건 새로 만들어서도 잘 쓰게 된다. 책의 예제를 아무리 따라해 봤자 실력이 늘지는 않는다. 제대로 익히려면 역시 소스코드를 직접 들여다 봐야만 한다.
이런 관점에서 보면, 옛날에는 미국의 커다란 IT 회사의 연구소나 유명한 대학원에 들어가지 않으면 접근할 수 없던 것을 이제는 누구나 손쉽게 접할 수 있게 되었다고 하겠다. 소수의 회사와 대학이 독점하던 것들이 이제는 밖으로 풀려져 버렸다는 얘기이다.
어느 대학이나 회사도 더 이상 소프트웨어 혁신의 중심지이지는 못하다. 리눅스는 핀란드의 한 학부생에 의해 만들어지고, MySQL은 스웨덴의 작은 회사가 만들었으며, 루비는 한 일본 개발자의 취미생활에서 시작되지 않았는가? 최근에 웹 개발 커뮤니티를 뒤집어 놓고 있는 레일스 역시 덴마크 한 학부생의 아르바이트 프로젝트에서 시작되었다. 이제 소프트웨어 혁신의 중심지는 인터넷이며 방식은 오픈소스이다.
프로그래밍에 있어 게임의 법칙은 분명히 바뀌었다. 다행인 점은 더 이상 소프트웨어 산업이 어느 한 국가나 회사에 종속적이지 않게 되었다는 것이다. 우리도 뒤쳐지지는 말아야 하지 않을까?
Older posts: 1 2
