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

Posted in  | Tags , , ,  | 16 comments | 1 trackback

내가 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은 어디에 유용할까?

관련글: Re: 내가 XML을 싫어하는 이유, JSON vs XML

Posted in  | Tags , , ,  | 6 comments | no trackbacks

대안언어축제 2006 후기

Posted by 大山 Mon, 04 Sep 2006 22:49:00 GMT

주말에 대안언어축제에 다녀왔다. 대안언어축제를 어떻게 설명해야 할까. 기본적으로는 각종 비주류 언어에 익숙한 사람들이 튜토리얼 발표 세션을 진행하고, 이들 언어에 관심을 가진 사람들이 참석하는 컨퍼런스라고 할 수 있을 것 같다. 이번에 다뤄진 언어는 루비, Haskell, Mathematica, Lisp, Smalltalk, Objective-C, J, 자바, Io, OCaml, Curl, Lua 등. 200여명의 사람들이 모여 2박3일간의 합숙 형태로 진행되었고, 정규 세션 외에도 BOF(끼리끼리 모임), 언어교환 등의 활동이 활발하게 이루어진 행사였다.

나는 Wookay님의 루비 튜토리얼, 승범님의 Squeak 세션에 참석하고, 레일스 세션을 진행하게 되었다. Squeak은 매번 설치만 해 놓고 더 나아가질 못했었는데 승범님의 튜토리얼 덕분에 드디어 한발짝 들여놓게 된듯. Squeak은 딱 꼬집어 설명하기 어려운 부분이 있지만, Smalltalk로 모든 것을 제어할 수 있는 GUI 운영체제라 할 수 있을까? 예를 들면, 그림판에서 그림을 하나 만들어 객체로 변환하고 거기에 코드를 추가해서 화면에서 움직이게 할 수 있다. 무언가 끌리는 분은 Alan Kay의 Etech 2003 기조연설인 Daddy, Are We There Yet?을 참고할 것.

첫날 밤에는 재명님으로부터 Haskell을 배웠는데, C 만큼이나 아름다운 언어라는 생각. Haskell은 진정한 함수형 프로그래밍이란 무엇인가를 명확하게 보여주는 언어였다. Lisp이나 수학을 좋아하는 생각하는 사람이라면 꼭 Haskell을 익혀보라고 권하고 싶다.

둘째날에는 deepblue님, 철호님과 루비, 프로그래밍, 웹 등에 관한 여러 생각을 나눌 수 있어서 좋았고, Wookay님과의 맥북 네트워킹 실험(?)도 기억에 남는다. 루비도 맥도 저변이 점차 확대되고 있는 것을 느낄 수 있었다. 루비 전문 개발 회사를 차리신 분도 만나 뵈었고, 내년 행사에는 꼭 맥북을 들고 오겠다는 포부(?)를 밝혀주신 분도 계셨다.

셋째날에는 브라이언님과 Lisp에 관한 많은 이야기를 나눌 수 있었는데, 특히 Common Lisp 표준의 성과와 문제점 등 막연하게 짐작만 하고 있던 내용에 대해 구체적인 설명을 들을 수 있어서 좋았다.

돌아오는 버스에서는 혜식님과 이야기를 나누면서 왔는데, 유니코드의 한글 호환 자모의 존재 이유와 다국어 도메인 이슈에 관한 정확한 기술적 설명을 들을 수 있었다. 오래된 기억을 더듬어 어찌어찌 한 것이라고 밖에 표현하지 못하던 나와는 대조적으로 모든 용어를 정확히 기억하고 구사하시는 것이 인상적이었다. 개인적으로 오랬동안 궁금해하던 이슈를 명쾌히 설명해 주셔서 무척 감사!

솔직히 국내에 대안언어축제와 같은 컨퍼런스가 있다는 것에 조금 놀랐고, 개인적으로도 많은 의미가 있었던 행사였다. 배운 것도 많았지만, 많은 분들을 만날 수 있어서 특히 좋았다. 창준님을 비롯하여 이처럼 뜻깊은 행사를 기획하고 준비하신 모든 분들께 감사의 말씀을 전하고 싶다. 국내에 참석할만한 프로그래밍 컨퍼런스가 없다고 아쉬워한 분이 있다면, 대안언어축제를 꼭 권하고 싶다.

Posted in  | Tags ,  | 13 comments | no trackbacks

자바 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을 기다리는 그대 지금 루비로 오라. ;)

Posted in  | Tags , , , ,  | 22 comments | 2 trackbacks

객체지향 프로그래밍에 대한 오해와 진실 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 in  | Tags ,  | 12 comments | 1 trackback

객체지향 프로그래밍에 대한 오해와 진실

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)이라는 전혀 다른 개념을 사용하고 있다.

객체지향이란 함수를 관리하는 하나의 프로그래밍 기법에 불과할 뿐이다. 매우 효과적이고 편리한 방법임에는 틀림이 없지만, 그렇게 거창하지도 또 이해하기에 복잡한 개념도 아니다.

관련글: 객체지향 프로그래밍에 대한 오해와 진실 2

Posted in  | Tags ,  | 9 comments | 1 trackback

오픈소스가 바꾸어 놓은 것

Posted by 大山 Mon, 24 Jul 2006 01:44:00 GMT

오픈소스가 가져온 변화는 물론 한두가지가 아니다. 여기서는 프로그래머 입장에서 보았을 때 오픈소스가 게임의 법칙을 어떻게 바꾸어 놓고 있는 지를 한 번 살펴보려고 한다.

오픈소스의 일차적인 효과는 무료로 수많은 프로그램을 사용할 수 있게 되었다는 점, 그리고 해당 프로그램의 소스코드를 들여다 볼 수 있게 되었다는 것이다.

물론 컴퓨터를 쓰다가 커널 패닉이 났다고 해서 리눅스 커널을 디버깅 하겠다고 덤비는 개발자는 많지 않을 것이다. 하지만 라이브러리를 사용하려다가 한글 지원이 미비한 것을 보고 유니코드 인코딩 지원을 추가 하는 정도는 어떨까? 프레임워크를 신버젼으로 업데이트 했을 때, 호환이 안되는 구버젼 라이브러리 코드를 업데이트 하는 정도라면?

실제로 해보니까 별 것 아니더라. 필요한 프로그램을 찾아 쓰고, 고쳐서 쓰고 하다 보면, 나중에는 왠만한 건 새로 만들어서도 잘 쓰게 된다. 책의 예제를 아무리 따라해 봤자 실력이 늘지는 않는다. 제대로 익히려면 역시 소스코드를 직접 들여다 봐야만 한다.

이런 관점에서 보면, 옛날에는 미국의 커다란 IT 회사의 연구소나 유명한 대학원에 들어가지 않으면 접근할 수 없던 것을 이제는 누구나 손쉽게 접할 수 있게 되었다고 하겠다. 소수의 회사와 대학이 독점하던 것들이 이제는 밖으로 풀려져 버렸다는 얘기이다.

어느 대학이나 회사도 더 이상 소프트웨어 혁신의 중심지이지는 못하다. 리눅스는 핀란드의 한 학부생에 의해 만들어지고, MySQL은 스웨덴의 작은 회사가 만들었으며, 루비는 한 일본 개발자의 취미생활에서 시작되지 않았는가? 최근에 웹 개발 커뮤니티를 뒤집어 놓고 있는 레일스 역시 덴마크 한 학부생의 아르바이트 프로젝트에서 시작되었다. 이제 소프트웨어 혁신의 중심지는 인터넷이며 방식은 오픈소스이다.

프로그래밍에 있어 게임의 법칙은 분명히 바뀌었다. 다행인 점은 더 이상 소프트웨어 산업이 어느 한 국가나 회사에 종속적이지 않게 되었다는 것이다. 우리도 뒤쳐지지는 말아야 하지 않을까?

Posted in  | Tags , , , , ,  | no comments | no trackbacks

내가 프로그래밍을 공부한 이유

Posted by 大山 Tue, 18 Jul 2006 22:57:00 GMT

대학생 때 수학 교과서를 읽다 보면 종종 짜증이 났더랬다. 이해하고 보면 별 내용도 없는데 이해하기가 무척이나 어렵게 쓰여진 경우가 많아서다. 무슨 Obfuscated Math Textbook 콘테스트도 아닌데 말이다.

근데 Barnes & Noble(미국의 교보문고)에서 프로그래밍/컴퓨터책을 종종 들여다 보면 어찌나 잘 쓰여진 책이 많던지. 개념적으로 상당히 어려운 내용도 직관적으로 잘 설명이 되어 있었다. 수학책 한권 볼 시간에 컴퓨터책은 다섯권이 읽히더라. 삶은 유한한데 짧은 시간에 많이 배우는 것도 중요하다는 생각이 들었다.

그런 이유로 컴퓨터 책을 읽기 시작한지가 6년이 조금 넘었다. 읽고 나서 소장 가치가 있는 책이 아니면 정기적으로 정리하는데도 지금 내 책장엔 컴퓨터책이 서른권 정도 꽂혀있다. 컴퓨터에는 한계효용체감의 법칙이 적용되지 않는 것인지.

잘 쓰여진 컴퓨터책이 왜 많을까를 언제나 궁금해 했는데 블로깅을 시작해 보니 대강 이유를 알 것 같다. 글을 쓰는 일과 코드를 작성하는 일은 별반 다르지 않더라. 그래서 SICP서문에는 이런 글귀가 적혀져 있었나 보다.

컴퓨터 프로그램은 언제나 사람에게 읽히기 위해 쓰여져야 합니다. 프로그램이 컴퓨터에서 실행된다는 것은 부차적인 일일 뿐입니다.

프로그래밍을 익히고 나니 이제는 무엇을 개발할 것인지가 고민이다. 프로그래밍은 결국 누군가를 위한 도구를 만드는 일이고 사람들이 필요로하는 것을 이해하려면 사람을 이해해야만 한다. 인문학을 공부할 차례일까?

Posted in  | Tags , ,  | 3 comments | no trackbacks

손톱깎기의 지겨움

Posted by 大山 Tue, 18 Jul 2006 00:16:00 GMT

나는 손톱깎는 것을 싫어한다.
불가피해서 한다.
안깎는 게 신성하다.
손톱깍기엔 손톱을 파괴하는 요소가 있다.

그러나 손톱이 짧아야만 키보드를 칠 수 있다.
나도 평생 키보드를 쳤다.

손톱을 깎으면 손톱이 깨진다는 거 안깎고 내버려 두어보면 안다.
나는 손톱을 매일 깎을 때도 있었고 몇주째 내버려도 보았지만
내버려 둘때 손톱이 온전해지고 길어지는 걸 느꼈다.

손톱을 보면 개발자 손톱 같고
손톱을 보면 디자이너 손톱 같고
손톱을 보면 기획자 손톱 같아 보이는 손톱은 손톱깎기 때문에 망가진 거다.
누구의 손톱인지 감이 안 와야 그 손톱이 온전한 손톱이다.

그런데 손톱 안깎는거, 그게 말이 쉽지 해보면 어렵다.
적당히만 기르는 거는 내버려 두는게 아니라 손톱깎기의 연장이다.
가끔이라도 깎지 않으면 못 참는 거는 손톱깎기에 중독되어 있는 거지 내버려 두는 게 아니다.
내버려 두는 거는 그냥 자라는 손톱을 바라만 보는 거다.

- 손톱깎기의 지겨움 中 [1]

개발자에게 게으른 것은 덕목이라고 한다. 가능한한 많은 것을 자동화해서 생산성을 높여야하기 때문이다. 그래서 경험이 쌓일수록 스크립트를 많이 짜게 된다. 루틴이 되어 버린 작업을 자동화 시킬 수 있으니까.

오늘도 손톱이 키보드에 미끄러지기 시작해서 손톱깎기를 집어들었다. 루틴도 이만한 루틴이 없는데 손톱깎기 스크립트는 짤 수가 없다.

  1. 이 글은 김훈 작가의 밥벌이의 지겨움에 나오는 글귀를 패러디한 것입니다.

Posted in  | Tags ,  | no comments | no trackbacks

프로그래밍의 본질

Posted by 大山 Mon, 17 Jul 2006 06:59:00 GMT

중학교 3학년때 쯤이었나, 통일장 이론을 완성하면 삶에 대한 모든 깨달음을 얻게될 거라고 굳게 믿었던 시절이 있었다. 뭐 대학생 때도 크게 다르진 않았던 것 같다. 인간이 자유의지가 있는지 없는지를 계산 가능성 문제로 이해한답시고 자바로 튜링머신을 구현해 놓고 한참을 끙끙댔었으니. (로저 펜로즈황제의 새마음 참고)

근데 학부때 교수랑 프로젝트를 잠깐 해보니까 대학원에 가도 내가 하고싶은 연구를 맘대로 할 수 있는게 아닌 것 같더라. 아카데미아에 대한 환상을 깨고 돈부터 벌기로 했다. 빨리 돈벌고 은퇴해서 통일장 이론 연구해야지, 뭐 지금도 계획은 그렇다.

수학, 물리 빼놓으면 할 줄 아는게 컴퓨터밖에 없으니 돈 벌려면 이걸로 뭔가 해야겠는데, 수학하던 버릇이 어디 가려나. 처음에는 알고리즘에만 관심이 있었다. 그냥 단순한 계산 알고리즘 말고 뭔가 심오한 깨달음을 줄 수 있는 그런 알고리즘을 찾아 헤맸다. 사실 재귀함수나 메타프로그래밍은 그런 느낌을 일부 주기도 했다. 이들의 피드백 루프는 인간이 스스로의 존재를 깨닫는 자아 인지 과정과 뭔가 유사한 면이 있기도 하니까.

근데 거기쯤에서 끝이더라. 프로그래밍에 그보다 더 심오한 것은 없었다. 실무에서는 퀵소트 보다 더 복잡한 알고리듬을 구현할 일도 없다. 몇달 전에는 루비 BBCode 파서 라이브러리를 구현하다 참고하려고 PunBB의 파서 코드를 들여다보다 깜짝 놀랐다. 재귀함수를 써서 트리 파싱을 하는게 아니라, 여는 태그와 닫는 태그 갯수를 세어서 숫자가 일치하나 안하나만 확인하더라. HTML로 변환하는 것도 정규식을 써서 앞태그 따로 뒷태그 따로 대치하는 식이었다. (솔직히 알고리듬 자체는 꽤나 촘촘하게 구현되어 있었다. 에러나는 예외 케이스 생각해 내려고 5분 정도 고민하다가 그만둬 버렸으니까.)

지난 30년간 Lisp으로 인공지능을 구현한다던 MIT의 천재들도 결국은 실패했다. (실패가 아니라고 이뤄낸 것도 많다고 우기는 사람도 있는데 실패라는 관점이 우세하다. AI의 그랜드 플랜은 인간 지능의 재현이었지 지식 구조의 설계가 아니었다.)

요지는 이거다. 프로그래밍은 공학이 아니고 과학은 더더욱 아니다. 해커와 화가에서 말하듯 프로그래밍은 공학보다는 미술에 가깝다. 작업 내용만 놓고 보면 건축에 더 가깝지만, 전 과정을 거의 혼자서 작업한다는 측면에서는 미술에 더 가깝다. 하지만 단순히 감상하기 위해서 만드는게 아니라 도구로써 사용하기 위해 만드는 것이니 공예에 가장 가깝다고 할 것이다.

물론 보통의 공예 작품을 만드는 것보다는 수학적, 공학적 지식이 엄청나게 많이 요구된다. 하지만 대부분의 프로그래머들이 이공계 출신이니 이것이 큰 문제는 아니다. 오히려 대부분의 개발자에게는 예술적 균형감각이 부족하다는게 문제이다.

더 이상 개발자의 경쟁력은 알고리즘 구현이나 복잡한 코드를 해독하는데 있지 않다. 해독하기 힘든 코드를 작성하는 개발자는 어디서도 환영받지 못할 테니까 말이다. 나는 앞으로 개발자의 경쟁력이 다음 세가지에 있다고 생각한다.

  • 기술적으로 옳바르게 설계하는 능력
  • 몇만 줄의 코드로 작성된 프로젝트도 쉽게 이해할 수 있게 직관적으로 설계하는 능력
  • 사용성이 뛰어난 소프트웨어를 설계하는 능력

프로그래밍 언어가 발전할수록 개발에 요구되는 기술적 전문성은 급격히 줄어든다. 더 이상은 포인터를 이해하지 못해도 개발에 지장이 없다. 메모리 관리도 직접 할 필요가 없다. 기술적 전문성이 중요하지 않다는 이야기가 아니다. 기술적 전문성은 기본이되 그것만으로는 충분하지 않다는 얘기이다.

요즘 프로그래밍에서 눈에 띄는 추세 중의 하나는 아마추어의 부상이다. Linux는 학부생이 만들어 냈다. 루비는 일본의 한 아마추어가 취미 삼아 만든 프로그래밍 언어이다. 레일스의 개발자는 PHP로 아르바이트를 하던 학부생이었다. 엘리트 개발자들은 무엇을 하고 있었을까? 윈도우 NT, 자바, 그리고 스트럿츠를 만들어내고 있었다.

오늘날 개발자의 최대 경쟁력은 균형감각이다. 어셈블리어를 이해하는 능력이 경쟁력이던 시대는 이미 지나갔다. 정신을 바짝 차리고 미술 감각도 익히고 마케팅도 공부해야 한다. 안그러면 아마추어에게 밀릴지도 모를 일이다.

Posted in  | Tags  | 5 comments | no trackbacks

Older posts: 1 2