jasu's blog

스티븐 스필버그 감독은 영화 <뮌헨>을 발표한 후 알고 지내던 유태인 친구를 여러 명 잃었다고 고백했다. 영화 속에서 주인공은 이스라엘 정보기관 모사드의 도움을 받아 폭탄 제조, 문서 위조, 사건 뒤처리 등의 다양한 재주를 가진 6명의 요원으로 팀을 구성한 다음, 1972년 뮌헨 올림픽 선수촌에서 테러를 일으킨 검은 9월단의 배후 요원들을 한 명씩 살해한다.

하지만 시간이 흐르면서 주인공을 비롯한 요원들은 국가를 위한 복수와 비인도적인 살인 행위 사이에서 갈등을 겪게 되고 스스로의 생명마저 위협받자 깊은 회의에 빠져들게 된다. 스필버그 감독은 인간적인‘갈등’과‘회의’를 그렸을 뿐인데 열혈 유태인들은 그것조차 용납하기 어려웠던 모양이다.

아무튼 영화 속의 주인공은 복수의 대상 11명이 은거하고 있는 장소와 그밖에 필요한 정보를 얻기 위해서 일종의‘정보 브로커’와 거래를 한다. 그에게 거액의 돈을 주고 살해할 대상이 숨어 있는 장소에 대한 정보를 얻는 것이다. 재미있는 점은 주인공의 복수가 진행되는 동안 다른 나라의 정보조직에서도 똑같은 정보 브로커에게 접근해서 주인공과 동료들의 신원을 파악하려고 한다는 점이다. 이름도 없고, 얼굴도 없어서 어느 누구에게도 존재가 드러나지 않아야 하는 정보조직 세계의 요원들이 이렇게 ‘정보 브로커’라는 존재를 통해서 오히려 하나의 지점에서 만나는 현상이 벌어진다.


상황중심이란 개념 이해하기    

이렇게 다양한 독립적인 개체들이 자신의 목적을 위해서 공통적으로 통과할 수밖에 없는 지점, 혹은 수행할 수밖에 없는 행동을 상황중심 프로그래밍(Aspect Oriented Programming)에서는 접점(join point)라고 부른다.‘ 상황중심’이란 요즘 프로그래밍 세계에서 주목을 받고 있는 ‘Aspect Oriented’라는 표현을 나름대로 우리말로 옮겨본 것이다.‘ Aspect Oriented’라는 말이 국내에서는‘관점 지향’이라는 말로 표현되기도 하는데, 이것은 그 동안 ‘Object Oriented’를‘객체 지향’이라고 불러온 관성의 영향인 것으로 생각된다.

사실‘관점 지향’이라는 말은 의미가 분명하지 않을 뿐만 아니라 겉으로 드러나는 의미조차 정확하다고 보기 어렵다. ‘관점’을‘지향’한다니? 프로그래밍을 수행하는 사람이 자기 관점을 분명히 세우고 그것을 목표로 전진하라는 말인가?‘ 관점 지향’이라는 말이 국내 프로그래머 사이에서 일정한 합의를 이루고 있는 표현이라면 어쩔 수 없지만, 최소한 이 글에서는‘Aspect Object’를‘상황중심’으로 표현하고자 한다. 이렇게 해야 새로운 방법론이 전하고자 하는 의미가 분명하게 드러나기 때문이다.

상황중심 프로그래밍은 말 그대로 현재의 소프트웨어 코드가 처해 있는 특정한‘상황’에 초점을 맞추는 프로그래밍을 의미한다. 폭발적으로 늘어나는 수요를 감당하지 못해 심각한 위기를 맞이했던 소프트웨어 개발시장은‘모듈(module)’과‘객체(object)’라는 혁명적인 개념을 발견하면서 위기를 극복했다. 방대한 분량의 소프트웨어 코드를 모듈과 객체라는 작고 독립적인 부분으로 분리할 수 있었기 때문에 프로그래머들은 점점 더 복잡한 업무를 수행하는 코드를 만들어 낼 수 있었던 것이다. 하지만 독립적인 모듈과 객체의 수마저 기하급수적인 규모로 증가하면서 예전과는 전혀 다른 문제가 대두되었다.

모듈과 객체는 코드를 추상적이고 부분적인 캡슐로 분리해서 전체적인 코드에 대한 관리가 가능하도록 만들고 필요하면 재사용 할 수 있는 방법까지 제공했다. 즉 모듈과 객체는 코드의 부분을 떼어내서 추상화하는 방법을 제공한 것이다. 하지만 이러한 방법은 모듈과 객체를 가로지르며 존재하는 공통의 관심사(cross-cutting concern)를 효율적으로 추상화하는 방법은 제공하지 않았다. 공통의 관심사란 보안(security), 성능(performance), 기록(logging)과 같은 소프트웨어의 일반적인 속성에서부터 데이터 캐시(cache) 관리나 네트워크 프로토콜의 구현처럼 구체적인 기능에 이르기까지 다양하다.

이러한 공통의 관심사는 특정한 모듈이나 객체가 구현하는 기능에 국한되는 것이 아니라 소프트웨어 시스템 전체에 걸쳐 수평적으로 영향을 미친다. 잘 이해가 되지 않는 독자는 다음 예를 생각해 보면 도움이 될 것이다.


공통의 관심사    

인터넷 붐이 한창이던 90년대에 미국에서는‘수평적 시장(horizontal market)’과‘수직적 시장(vertical market)’이라는 표현이 자주 사용되었다. 수직적 시장이란 어떤 제품이 특정한 분야의 시장에 국한되는 경우를 의미한다. 예를 들어서 책, 의류, 자동차, 컴퓨터, 혹은 의료보험 시스템 등은 다른 분야와 겹치지 않는 자기 자신만의 시장을 형성한다.

이들은 모두 수직적 시장의 예이다. 하지만 웹브라우저와 같은 소프트웨어는 특정한 시장에 국한되지 않고 모든 수직적 시장들 사이에 공통적으로 존재하며 영향을 미친다. 그 자체로는 특정 품목에 대한 시장을 형성하지 않지만 여러 시장에서 동시에 존재하는‘공통의 관심사’가 되는 것이다.

영화 <뮌헨>에서 이스라엘의 모사드, 소련의 KGB, 미국의 CIA, 팔레스타인의 검은 9월단 등은 각자 겹치지 않는 고유의 영역을 구성하고 있지만, 그들이 어떤 인물의 은신처를‘검색’하기 위해서는 다양한 정보를 보유하고 있는‘정보 브로커’를 찾아가야만 했다. 각 국의 정보기관이 수직적 시장을 형성하고 있다면,‘ 정보 브로커’는 웹브라우저와 마찬가지로 수평적 시장을 형성하고 있는 셈이다. 이 경우에‘정보 브로커’는 여러 정보기관들을 가로지르며 공통적으로 존재하는‘공통의 관심사’로서의 역할을 담당한다.

오늘날의 프로그래밍 세계에서 수직적 시장을 구성하는 존재는 말할 것도 없이‘객체’들이다. 객체들은 저마다
주어진 일감을 구현하면서 일이 서로 겹치지 않도록 소프트웨어의 전체 영역을 분할한다. 이렇게 분할을 더욱 효율적으로 만들기 위해서 비슷한 일을 하는 객체를 한곳에 묶어서‘패키지(package)’라고 부르기도 한다. 지금까지 프로그래밍은 이러한 분할을 통해서 충분히 잘 이루어져 왔다.

하지만 이렇게 역할 분담을 통한 균형과 평화가 이루어진 상황에서도 여러 객체 사이에 존재하는‘공통의 관심사’는 존재하기 마련이다. 앞에서 예로 든 보안, 성능, 기록, 캐시, 프로토콜 등이 바로 그들이다. 이밖에 유닛테스트(unit test)나 테스트 자동화 등도 여기에 포함될 수 있을 것이다.

좀 더 이해를 돕기 위해서 하나의 구체적인 상황을 생각해보자. 소프트웨어의 사용자들이 항상 그렇듯이 개발자가 개발한 시스템을 이용하는 사용자 중에는 구체적인 데이터를 제시하지 않으면서 말로만“시스템이 느려 터졌다.

답답해서 못 쓰겠다.”라고 불평을 늘어놓는 사람이 있다. 소프트웨어를 제작하고 관리하는 입장에서는 이렇게 막연하게 불평만 늘어놓는 사용자처럼 속상한 존재가 없다.

구체적으로 어떤 기능을 사용할 때‘느린지’를 알아야 그가 겪고 있는 문제가 PC 하드웨어와 관련된 문제인지, 개발자가 만든 소프트웨어의 문제인지, 네트워크의 문제인지, 혹은 서버나 데이터베이스의 문제인지를 알 수 있고 그에 따른 해결책을 제시할 수 있기 때문이다(물론 사용자가 허락만 해준다면 그가 소프트웨어를 어떻게 사용하는지 직접 관찰할 수도 있을 것이다. 하지만 성격이 곱지 않은 월스트리트의 트레이더에게‘저는 소프트웨어를 제작한 사람인데요, 잠시 옆에서 PC를 사용하는 모습을 관찰해도 될 까요’라고 묻는 것은 자살 행위이다).

그렇지만 사용자가 데이터를 제공해 주지 않는다고 해서 손을 놓고 있을 수는 없으므로 우리는 필요한 데이터를 스스로 구해야 한다는 결론을 내리게 되었다. 그리하여 우리가 구현하기로 한 기능은 사용자가 소프트웨어에서 어떤 동작을 수행할 때마다 맨 처음 GUI의 이벤트 처리 메소드(event handler)에서 출발해서 서버와 데이터베이스에 이르는 과정에 존재하는 각 계층을 통과하는 데 걸린 시간을 측정한 다음 로그 파일과 같은 하나의 장소에 기록하는 것이었다.


스파이로그    

사용자가 GUI 화면에서 주식이나 채권 가격 같은 데이터를 입력하고 OK 버튼을 눌렀다고 해보자. 그러면 소프트웨어의 흐름은 GUI 계층, GUI 계층 아래에 존재하는 네트워크 계층, 실제 네트워크 전송, 서버에서 사용자의 요청을 받아들여서 적절한 컴포넌트( component)에게 전달하는 계층, 데이터베이스에 저장되어 있는 프로시저(stored procedure), 최종적인 데이터를 담고 있는 응답객체를 생성하는 계층, 응답 객체를 GUI 클라이언트에게 전송하는 계층, GUI가 서버의 응답을 받아서 처리하는 계층 등을 차례로 통과한다.

이 때 각 계층에서 소요된 시간을 측정해서 하나의 객체에 저장하는 것이다. 이렇게 처리시간이 기록된 객체는 각 계층을 통과할 때마다 다음 계층에게 전달되면서 값을 축적해 나간다. 필요한 처리 과정이 모두 끝나고 나면 이 객체에 저장된 값은 미리 지정된 포맷에 따라서 로그 파일에 기록되고 객체의 수명은 끝이 난다.

이제 사용자가 시스템의 성능에 대해서 밑도 끝도 없는 불평을 늘어놓으면 로그 파일에 저장되어 있는 데이터를 분석해서 실제로 성능에 문제가 있었는지, 만약 문제가 있었다면 어느 계층에서 문제가 있었는지를 파악할 수 있다.

이렇게 유용한 기능의 이름을‘스파이로그’라고 불러보자. 앞의 설명을 읽으면서‘흠 소프트웨어의 여러 계층을 관통하는 <공통의 관심사>를 설명하려고 애쓰고 있군’하고 생각하는 독자가 있다면 만점이다. ‘공통의 관심사(crosscutting concern)’라는 개념을 이해했다면 상황중심 프로그래밍의 98%를 거의 이해한 것과 다름이 없다.

이러한 스파이로그를 실제로 구현하는 방법은 어렵지 않다. 소프트웨어가 객체지향 기법에 따라서 계층별로 잘 분리되어 있다면 더욱 그러하다. 각 계층의 시작과 끝 부분에서 시간을 측정하는 데 필요한 동작을 수행하기만 하면 되기 때문이다. 하지만 그것이 가능하기 위해서는 최소한 두개의 전제 조건이 필요하다. 하나는 스파이로그를 구현하는 프로그래머가 각 계층의 입구와 출구를 정확하게 파악하고 있어야 한다는 점이고, 두 번째는 스파이로그를 구현하기 위해서는 입구와 출구에 해당하는 객체의 소스 파일이 수정되어야 한다는 점이다. 즉, 입구에 해당하는 위치에서는 앞의 계층에서 전달한 시간 측정용 객체를 받아들인 다음 들어온 시간(time stamp)을 찍고, 출구에 해당하는 위치에서는 같은 객체 위에 나가는 시간을 찍고 나서 뒤에 있는 계층에게 객체를 전달해 주는 것이다.

이런 방법은 기능적으로는 아무런 문제가 없지만 코드의 관리라는 측면에서 보면 문제가 많다. 한 가지만 예를 들자면 이런 식이다. 시스템에 A, B, C, D라는 네 개의 계층이 존재한다고 하자. 하나의 동작(operation)이 완성되려면 A, B, C, D, C, B, A라는 완성된 사이클이 그려져야하고, 스파이로그는 이러한 일곱 단계가 소비하는 시간을 각각 측정해서 기록한다.

그런데 나중에 누가 C 계층을 리팩토링해서 그것을 C1과 C2라는 두 개의 계층으로 분리했다고 가정해보자. 그리고 스파이로그의 존재를 의식하지 못한 그가 C1이 받아들인 객체를 C2에게 전달하는 것을 깜빡 잊었다고 하자. 이와 같은 본의 아닌‘실수’가 도입되는 순간 C1과 C2 사이의 고리가 끊어지면서 스파이로그의 기능은 동작을 멈출 수밖에 없다.

여러 계층이 공유하고 있는‘공통의 관심사’가 단지 한계층에서 발생한 실수 때문에 완전히 동작을 멈춘다는 것은 공정하게 들리지 않는다. 뿐만 아니라 스파이로그의 기능이 여러 소스 파일에 분산되면서 코드의 관리가 어려워진다는 단점도 존재한다. 이러한 상황은 서로 독립적으로 분할되어 있어야 하는‘객체’라는 존재를 중심으로 하는 프로그래밍 방법론으로는 명쾌하게 해결되기 어렵다.

객체는 본질적으로 다른 객체와 나란히 서 있도록 만들어진 존재이지, 다른 객체의 허리를 가로지르며 직교(orthogonal)하도록 만들어진 존재가 아니기 때문이다. 바로 이와 같이‘난처한 상황’에서 힘을 발휘하는 것이‘상황중심’의 프로그래밍이다.


제록스 팔로알토연구소에서 탄생    

상황중심 프로그래밍이라는 개념은 제록스 팔로알토 연구소에서 탄생한 것으로 알려져 있다. 현재 캐나다의 브리티시 콜롬비아 대학의 컴퓨터 사이언스 교수인 그레고르킥잘레스(Gregor Kiczales)는 팔로알토 연구소에서의 연구를 확장해서 현재 상황중심 프로그래밍 세계에서 대표적인 언어로 인정받고 있는 AspectJ를 설계했다. IBM에서도 HyperJ나 관심 변경 환경(Concern Manipulation Environment)과 같은 상황중심 프로그래밍 언어를 발표했지만, 현재 프로그래머 사이에서 널리 받아들여지고 있는 언어는 단연 AspectJ이다.

상황중심 프로그래밍에서 사용하는 개념은 크게 네 가지가 있다. 접점(pointcut), 안내(advice), 내부타입 선언(inter type declaration), 그리고 이들을 모두 묶어서 하나의 단위로 추상화하는 상황(aspect)이 그들이다. 상황중심 프로그래밍이나 이러한 개념들이 의미하는 바는 AspectJ의 홈페이지 등에서 쉽게 접할 수 있다. AspectJ에 대한 책도 이미 적지 않게 나와 있다. 여기에서 이들이 의미하는 바를 간단하게 살펴보자면 이렇다.

우선 접점(pointcut)은 공통의 관심사가 여러 개의 객체나 계층을 가로지를 때 그들과 만나게 되는 지점을 의미한다. 앞에서 살펴본 예에서는 각 계층의 입구와 출구가 접점에 해당하고, 더 앞에서 든 예에서는 모사드, CIA, KGB의 요원들이‘정보 브로커’와 만나는 상황 자체가 접점에 해당할 것이다. 접점은 상황중심 프로그래밍을 수행하는 프로그래머가 이미 존재하는 소프트웨어 시스템을 이해하고 있는 수준, 혹은 핵심을 짚어내는 안목에 따라 제대로 짚어질 수도 있고, 엉뚱한 곳이 접점으로 인식될 수도 있다. 어쨌든 프로그래머가 일단 접점을 골라냈으면 그 다음에 할 일은 그 곳에서 할 일을 정의하는 것이다.

그것이 안내(advice)이다. 상황중심 프로그래밍에서 안내는 객체지향 프로그래밍에서의 메소드에 해당한다고 생각하면 쉽다. 특정한 접점에 이르기 직전이나 혹은 직후에 어떤 일을 할 것인가를 정의하는 알고리즘이 안내의 내용을 이룬다.

내부 타입 정의(inter type declaration)는 약간 복잡하다. 이것은 자바 프로그래밍과 같은 기존의 프로그래밍 방식에 익숙한 사람들에게 개념적인 혼란을 초래하기 때문이다. 자바 언어를 예로 들자면, 어느 객체에게 새로운 인스턴스 변수(instance variable) 혹은 필드(field)를 추가하는 것은 언제나 소스 코드의 수정과 컴파일을 통해서 이루어진다.

프로그램이 실행되고 있는 도중에 새로운 필드를 내 마음대로 추가할 수는 없는 것이다. 자바 런타임(runtime) 내부에서 클래스 이름만 가지고 클래스의 인스턴스를 만들어내는 기능은 있지만 클래스에 이미 정의되어 있지 않은 필드를 더하는 기능은 없다.

그런데 상황중심 프로그램에서 사용하는‘내부 타입 정의’기능은 객체에게 새로운 필드를 동적으로 더하는 것을 가능하게 만든다. 이러한 기능이 필요한 이유는 이미 존재하는 다양한 객체와 계층을 가로지르면서 동작하는 알고 리즘을 작성하기 위해서는 주어진 객체의 정해진 틀을 뛰어넘는 능력이 필요하기 때문일 것으로 추측된다. 사실 필자 역시 상황중심 프로그래밍에 익숙하지 않기 때문에 섣불리 말하기는 어렵지만, 이러한 기능이 바람직한지에 대해서는 의문이 든다.

상황중심 프로그래밍을 구사하는 프로그래머가 어느 객체에게 내부 타입 정의 기능을 이용해서 동적으로 어떤 필드를 추가했다고 해보자. 그는 객체를 정의하고 있는 클래스에 새로운 필드를 사용하는 알고리즘을 추가할 수도 있다. ‘( 내부 타입 정의’기능을 통해서 추가한 필드가 퍼블릭으로 정의되어 있다면 기존의 자바 코드에서 접근하는 것이 가능하기 때문이다.)

이렇게 작성된 소스 코드를 나중에 읽는 다른 프로그래머는 (특히 그가 상황중심 프로그램의 존재를 인식하지 못하고 있다면) 도대체 이 코드가 사용하고 있는 필드가 어디에 정의되어 있는 것인지 알 길이 없다. 이런 식의 혼란은 미묘한 버그의 원인이 될 수 있다.

이런 측면에서 보자면 내부 타입 정의를 이용하는 것은 멀쩡한 객체에게 뼈를 깎고 살을 붙이는 성형수술을 시도하는 것, 혹은 객체의 유전자를 조작해서 없던 장기를 만들어 내는 것에 비유할 만하다. 수술이나 유전자 조작이 필요한 결과를 낳는다면 다행이지만, 잘못된 결과를 낳거나 그것이 남용된다면 차라리 하지 않느니만 못한 일이 될 것이다.

마지막으로, 객체지향 프로그래밍에서 클래스가 변수와 메소드를 한 곳에 묶어서 하나의 객체로 추상화하듯, 상황중심 프로그래밍에서 사용되는 접점, 안내, 내부 타입 정의를 한 곳에 묶어서 추상화하는 것은‘상황(aspect)’이다. 따라서 상황은 객체지향 프로그래밍에서 객체가 중심에 서있듯이 상황중심 프로그래밍에서 가장 중심에 서있는 개념이 된다(이것은 프로그래머들이 혐오하는‘중복’된 표현처럼 들린다. 하지만 달리 표현할 방법이 없다. 상황중심 프로그래밍에서 중심은 상황이기 때문이다).


출처 : 임백준(월스트리트 금융전문가) & 소프트웨어 산책외 다수 저자

 지금의 고등학교에서는 문과와 이과를 구분하여 수업을 듣고 있는지 모르겠으나 나의 고등학교 시절에는 문과와 이과를 나누어 ‘가벼운 수학’과 ‘깊이 있는 수학’으로 구분하여 수업을 들었던 기억이다. 수학이 싫다는 단순한 생각에서 이과가 아닌 문과를 지망하게 되었지만 수학은 여전히 나의 기대에 부합하지 않고 문과에서 날 괴롭혔다.
 
 그러했던 나의 선택에 그나마 스스로에게 최선을 다 하겠다며 수학 시간에 학내 도서관에서 빌린 소설책을 선생님 몰래 보면서 스스로를 위한 하곤 했다…^^; 지금은 직장생활로 인해서 전문서적을 보는 것으로 책 읽기를 대신하고 있으니 평소에 소설을 책 한 권 접하기가 쉬운 일이 아니다.
 
 그래서 얼마동안 이 두 가지 토끼(전문 서적 & 에세이 & 소설)을 잡을 욕심으로 가벼운 프로그래밍 관련 서적을 구입하여 읽었다. 읽다 보니 임백준이라는 저자의 책들을 읽게 되었는데 그 중 4권을 소개해 볼까 한다.
 
 먼저 저자 임백준은 삼성 SDS와 미국 루슨트 테크놀로지에서 소프트웨어 엔지니어로 근무했으며 월간 마이크로소프트웨어에 컴퓨터 칼럼을 연재했고 인터넷 신문 “프레시안”에 시사 칼럼을 쓰고 있는 저자다.
 책은 초판발행일자 기준으로 정리 하였다.

1. 행복한 프로그래밍 – 컴퓨터 프로그래밍 미학 오디세이

: 책 제목에 ‘프로그래밍’이라는 말이 들어가면 사람들은 대개 기술적이거나 전문적인 내용을 다루는 책을 떠올리기 마련이다. 하지만 ‘행복한 프로그래밍’이라는 제목에서 필자가 중점을 둔 부분은 “프로그래밍”이라는 명사가 아니라 “행복한”이라는 형용사다. 다시 말해서 이 책은 특정한 기술이나 전공 지식을 담은 책이 아니라 컴퓨터 프로그래밍 속에 들어 있는 미학을 전달하려는 소프트한 얘기를 담고 있는 책이다. –서문중에서
해바라기 씨앗의 배열을 닮은 피보나치 수열은 매우 아름답지만, 그것을 컴퓨터 프로그램으로 옮기는 것이 별로 어려운 일이 아니라는 사실은 나중에야 알게 됐다. 그 때에는 화면에 나타나는 숫자들을 바라보는 것만으로도 황홀감을 느낄 지경이었다 – “영혼을 녹여서 만드는 아름다운 공식” 중에서…



2. 누워서 읽는 알고리즘 – 생각하는 방법을 알려주는 알고리즘 이야기
: 이 책은 어렵고 복잡한 알고리즘을 ‘쉽게 풀어서’ 설명한 책이 아니다. 오히려 맛있는 읽을거리를 만들기 위해서 알고리즘과 같은 기술적인 내용을 ‘동원한’ 책이다. 나는 새로운 알고리즘 이론을 소개하는 것도, 독자들에게 알고리즘을 ‘강의’ 하는 것도 아니다. 즉 ‘공부’와는 아무런 상관이 없다. 나는 실전 프로그래밍을 업으로 삼고 있는 사람들과 함께 가볍게 ‘수다’를 떨면서 우리가 매일 수행하는 ‘일’이 얼마나 재미있는지, 얼마나 아름다운지 그리고 얼마나 창조적인지 확인하고 싶었다 – 서문 중에서
짧은 시간이 흐르고, 화면에 나타나는 결과를 보았을 때 필자의 가슴은 그만 철렁 내려앉고 말았다. 화면에 나타난 것은 정상적인 페이지가 아니라 페이지 수가 이미 최대 값에 도달했으므로 더 이상의 페이지를 열 수 없다는 오류 메시지였다. 모든 경우에 대해서 완벽하게 동작하는 것처럼 보였던 알고리즘안에 조용히 숨어 있던 버그가 드디어 모습을 들어낸 순간이었다 – ‘재즈로 여는 아침의 향기’ 중에서



3. 나는 프로그래머다 – 무결점에 도전하는 아름다운 사람들의 이야기
: 인생에 있어서 도전이란 결코 입맛에 딱 맞는 방식으로 찾아오지 않는다. 그것은 언제나 두 발을 전부 땅에서 떼서 허공에 몸을 완전히 맡겨야 하는, 따라서 상당한 불편함과 두려움을 수반하는 방식으로 찾아온다. 어렵지만 마음에 쏙 드는 일자리를 만났을 때, 어렵지만 풀어 보고 싶은 문제를 만났을 때, 어렵지만 한 번 걸어 보고 싶은 길을 만났을 때, 어렵지만 한 번쯤 말을 꼭 걸어 보고 싶은 이성을 만났을 때, 필요한 것은 앞뒤를 재고 따지는 ‘계산’이 아니라 최선을 다해서 허공에 몸을 맡기는 ‘용기’다. – 서문 중에서
이 책은 IT 각 분야에서 종사하는 7분이 모여서 만든 책이다. 김용준, 김종호, 원은희, 유영창, 이춘식, 임백준, 허광남, 임백준을 제외한 분들은 책을 많이 써보지 않은 분들이라 그런지 문장이나 형식이 자연스럽지 못하다는 느낌이 많이 들었던 것 같다. 임백준의 글이 가장 읽기 편했다. (길들여 진 것일까..;;)





4. 임백준의 소프트웨어 산책 – 소프트웨어에 대한 새로운 시선 그리고 통찰력
: 이 책은 공부를 목적으로 하는 책이 아니다. 프로그래밍과 조금이라도 관련이 있는 사람이라면 이 책을 한 손에 들고 다른 한 속으로는 새우깡이라도 먹으면서 마치 소설책처럼 읽을 수 있기를 바라면서 글을 썼기 때문이다. 사실 이 책은 소설을 담고 있다는 점에서 실제로 ‘소설책’이기도 하다. 깊이와 짜임새를 향한 결심은 지켜내지 못했지만 독자들이 이 책을 재미있게 읽을 수 있기를 바라는 마음에서 아예 소설을 한 편 쓰기도 했다. 말하자면 프로그래머가 프로그래머를 위해서 프로그래밍을 주제로 쓴 소설인데, 책의 뒤에 실려 있다 – 서문중에서
“어려운 문제를 드디어 풀어냈다는 성급한 기대가 K씨의 심장을 빠르게 뛰게 만들었다. 사실 프로그래머가 이와 같은 ‘유레카’의 순간에 느끼는 순백의 열정은 사랑에 빠진 청춘의 감격과 별로 다를 것이 없다. 적어도 그 순간만큼은 세상의 모든 사물이 그 자리에서 동작을 멈추고 시간이 정지한다. – 프로그래머 K씨의 하루 중에서




 이렇게 4권의 책을 읽게 되었다. 임백준은 프로그래밍에 숨어 있는 미학을 발견하고 프로그래밍을 통해서 세상을 이해하려는 노력을 하고 있다. 현재는 뉴욕 월스트리트에서 금융 소프트웨어를 개발하고 있다고 한다. 책의 서문이나 내용을 보면 알 수 있겠으나 대부분의 책들은 프로그래밍이나 컴퓨터 언어에 대한 해박한 지식을 요구하거나 강요하지 않는다. 그렇다고 프로그래밍과 전혀 관련이 없는 사람들이 읽기에는 공감이 가는 성격의 글이 아니기에 권하고 싶은 마음은 없다.
 
 작년 Macromedia conference MAX 2005 KOREA에서 스피커로 나왔던 Jared Tarbell은  “프로그래밍은 시와 같다”, “프로그래밍은 아트다” 와 같은 이야기를 한 적이 있다. 임백준이 프로그래밍에서 발견한 미학이라는 것이 이런 의미에서의 아름다움이 아닐까 하는 생각이 든다. 나 자신도 구조적으로 잘 짜여진 짧지만 많은 의미를 담고, 아름다울 만큼 창의적인 결과를 표현하는 프로그램을 보면 ‘아름답다’라는 표현이 가장 적절하다는 생각이 든다.
 
 얼마 전에 모 출판사에서 나에게 책을 쓸 것을 권한 적이 있다. 판매금액의 10%를 받는 조건으로 책을 쓰면 어떻겠냐는 이야기였다. 금전적인 문제를 떠나 내가 쓴 책이 일반 서점에서 독자들에게 판매될 수 있다는 것을 생각하니 결정도 내리지 않은 시점인데도 흥분되는 일이 아닐 수 없었다.
 
 며칠 동안 고민하다가 일단 샘플을 하나 만들고 간단한 구조로 내용을 담아 보았다. 그런데 가만히 내가 만든 소스와 내가 쓴 글을 보고 있으니 책으로 세상에 내놓기에는 쓰레기 같아 보였다. 소스는 순전히 개인적인 습관과 입증되지 않은 구조와 알고리즘으로 낙서를 해놓은 것 같은 느낌이 들었다.
 
 임백준의 책 속에 이런 내용이 있다. “자신이 만든 프로그램으로 만든 전투기를 직접 자신이 조정할 수 있는 용기가 있는가” 결코 쉬운 일이 아닌 듯 싶다. 더군다나 인터넷이 아닌 인쇄물로 한번 세상에 내놓으면 수정할 수도, 업데이트 할 수도 없는 책을 출간한다면 잘못된 정보를 통해 위와 같은 질문에 ‘예’라고 대답한 사람들의 사고들을 내가 어찌 감당할 수 있겠는가 싶었다. 그래서 다음날 출판사 담당자에게 기회가 되면 다음에 쓰겠다고 정중히 거절을 했던 일이 있었다. 지금도 나는 그때의 결정을 잘 했다고 생각한다.
 
 프로그래밍이 아름다음을 갖으려면 그것을 만드는 사람의 흥미와 재미, 열정과 인내가 필요한 작업이 아닐까 싶다. 혹시나 나는 인내가 어려워 가벼운 흥미와 재미를 쫓고 그것을 열정이라 자찬하고 있는 것은 아닐런지...;