1. 완성되지 않았던 자작시


사람은 어둠을 낳고

어둠은 죄를 낳는다.


그 속에서

사람은 다시 어둠을 낳고

일단의 무리들은

대체로 위로만 뻗은 도시의 빌딩 숲 속으로 사라져 버렸다.




중학생 한그루는 '죄의 구조'를 이야기하고 싶었나 보다. 

완성되지 않았던 저 시를 언급하면서 시에 대한 '야부리'를 까볼까 한다.



2. 유물론자 물상선생님에게 핀잔을 받았던 시


아, 늦었다.


명절, 제사 때마다 반복되는 엄마의 피곤함이

아빠의 새벽 출장과 맞물려

나의 개근상을 날려버렸다.

엄마의 당황스러운 표정은

개근상을 날린 짜증보다는

내가 남자라는 안도감을 앞세웠다.


안도감은 이내

개근상에 흠집이 간 상, 전근상

흠집이 간 상이라도 타겠다는 초조감으로 바뀌어

나의 등교길을 재촉했다.



재촉의 끝에 도달한 학교

학교 운동장에는 개미 한마리 없었다.




중학교 3년 동안 내 담임선생님은 영어 과목 담당 선생님. 거기다가 동일 인물.

그런데 며칠 임시로 담임을 맡은 물상 선생님은 교내 백일장에 써냈던 내 시를 읽고는 이렇게 말했다.


"한그루, 너가 눈이 얼마나 좋길래 운동장에 개미가 있는지를 어떻게 알아?"



그 때 내 머리 속에는, 당시 중학생이라면 결코 떠올릴 수 없는 유물론이라는 단어를 떠올리면서, '이런, 유물론자 같으니라구'라고 생각을 했었다. 입 밖으로 내지 않은 이유는 사회선생님의 신신당부 때문이었다. (내가 왜 당시 유물론이라는 단어를 알게 되었는지는 나중에 기회가 되면 이야기를 하기로 하고... ^^)


내 개념으로는 '물상 선생님'은 유물론자였고 국사, 역사 선생님들은 '변증법론자'였으며 국어선생님은 유물론과 변증법을 구사하기 위한 언어를 가르치는 선생님. 그러니까 예수의 제자 중 예수의 옷자락을 만져보고서야 예수의 부활을 믿었던 어떤 제자처럼 물상선생님은 눈으로 인식되어야지만 표현이 가능하다고 말했으니까.



3. WTF, 왠 영시 작문반?


He says, "I write a novel"

I say, "I read a novel"


He says, "I write a poem"

I say, "I recite a poem"


Why don't I say "I read a poem"?

Because poem is something special.


And something special makes me tired specially.

Yes, it is poem.



"선생님은 학창 시절에 산수를 무척 못하셨나 봐요"

"시꺼 임마. 너가 산수를 잘하는거지"


초등학교와 중학교 때 나는 담임선생님들로부터 '걸어다니는 스프레드 시트(엑셀 프로그램을 떠올리면 된다)' 취급(?)을 당했다. 요즘이야 한 학급에 30명 남짓이고 학교에서도 컴퓨터는 일상적으로 쓰지만 IBM-PC가 먼훗날에 나올 위대한 발명품이었던 그 시절, 선생들에게 시험 후 성적표를 작성하는 것은 큰 일이었다. 더우기 학급 인원수도 60명을 넘었던 시절이니까.


담당 과목 시험지를 채점을 하고 점수를 내고 기록하는 것은 큰 문제가 아닐 것이다. 그러나 학급을 맡은 담임들은 각 과목의 점수를 과목 담당 선생에게 받은 후 그걸 옮겨 적고 평균을 내고 석차를 내야 하기 때문에 하루 이틀 야근을 해야 했다. 복잡한 산수는 아니기 때문에 하루만 꼬박 고생하면 되지만 수업을 병행하면서 해야 했기 때문이다.



그렇게 하루, 이틀 야근을 담보잡는 일을 나는 단 십분만에 해결했다. 


'주산1급, 부기 3급 타자 1급', 초등학교 때 땄던 자격증들, 특히 주산은 3급부터는 암산으로 계산하는 과목이 있었고 주산1급이었던 나에게 두자리, 또는 세자리 숫자들의 합을 내고 학생별로, 과목별로 평균을 내고 그리고 학급 전체의 평균을 내는 것은 누워서 떡먹기보다 더 쉬운 일이었다.



중학교 시절에는 내가 주산1급이라는 사실을 담임선생님이 알리가 없었는데 우연히 교무실에 갔다가 자리를 비운 담임선생님 책상 위에 있던 성적 전표를 보고 '심심해서' 산수를 했고 그 산수의 결과를 기록한 것이 계기가 되었다. 그리고 한두달 후에 나는 한학년 당 15반, 그러니까 3개학년 45학급의 성적처리 계산을 해야 했다.



한 학급은 60명 한 학급의 한 과목의 평균을 내는데 걸리는 암산시간은 그냥 쯕 읽어 내리면 되니까 3초 정도? 적는 시간까지 고려한다면 넉넉 잡아 5초. 과목은 국산사자음미체실 등 10개 정도. 그러니까 한 학급의 과목당 평균을 내는데 15초. 그리고 학생별로 평균을 내야하는데 1초 정도? 계산 시간보다 평균 내고 적고 다음 학생으로 이동하는 시간이 더 걸리니까... 이 것도 3초 정도? 그러니까 한 학급의 학생당 평균을 내는데는 3초 x 60명 = 180초 = 3분



한 학급의 과목당 평균 내는 시간 15초, 학생당 평균을 내는 시간은 3분. 합해서 3분 15초. 그걸 45학급을 해야 하니까 두어시간 남짓? 실제로는 두시간 정도 걸렸었다.



ㅠ.ㅠ;;; 그리고 나중에는 학급별, 학년별 평균점수별 소팅 작업까지 해야 했다.



나의 주산1급으로 인한 산수 실력은 학교 선생님들에게는 '구세주' 역할을 했지만 성적 산출을 끝내 '구세주'가 된 나는 '구세주'를 찾아야 했다. 왜냐하면, 성적을 낸 후에는 자기 점수가 궁금한 급우는 물론 선배들까지 질문의 쓰나미를 이뤘기 때문이다.




내가 중학교 2학년 때 특활시간에 영시 작문반에 갔던 이유이다. 중학교 2학년 때 담임선생님은 1학년 때 담임선생님과 같은 선생님이었고 성적 산출이 계기가 되어 담임선생님의 시다바리(?) 역할까지 겸해야 했던 내가 담임선생님 심부름 차 교무실에 갔었는데 그 교무실에 간 동안 특별활동 반배정을 했었고 그리고 내가 교실로 돌아왔었을 때 남은 유일한 반은 영시 작문반이었다.



"뭐냐..... 이게.... 왠 영시 작문반?"



뭐, 당시 영어 실력이야 영어과목 담당이었던 담임선생님에게 인정받을 정도였지만 영시는 내게 정말 생경한 세계였고 그리고.... 1년 동안 나는 일주일에 한번씩 아스트랄한 정신 세계를 체험해야 했다. 그리고 위에 적은 시는 그 때 썼던 영시들 중 그나마 기억에 남는 영시이다.



3. 객체지향 프로그램


디지탈은 0과 1의 조합이다. 영화에서 SOS라는 무전을 치는 이유는 SOS가 'Save of ship' "Save of Sea' 등의 의미가 아니다. 이렇게 해석되고 알려진 것은 문학적으로 이야기하자면 일종의 의도의 오류(Intentional Fallacy)이다. SOS는 디지탈 최상의 조합이다. 무선의 신호는 무선을 타전하는 스위치를 길게 누르거나 짧게 누르는 것의 조합인데 길게 누르면 0, 짧게 누르면 0이다.


그리고 SOS는 '짧게, 짧게, 짧게(0,0,0=S)', '길게, 길게, 길게'(1,1,1=O), '짧게, 짧게, 짧게(0,0,0=S)'의 조합이다. 그러니까 위기 상황에서 실수를 하지 않고 가장 정확하고 명료하게 보낼 수 있는 디지탈 신호가 바로 SOS라는 것이다.



우리가 이야기하는 CPU는 0과 1의 조합을 가장 창조적으로 쓴 결과이다. 최근에 화제가 되었던 알파고도 결국은 0과 1의 구조로 되어 있다. 그리고 이런 CPU의 핵심은 microcode라는 부분이 담당한다. SOS가 0과 1의 조합이듯, microcode는 0과 1의 조합을 해독하여 일을 한다. 예를 들어, microcode가 읽은 조합이 0100이라면 jump, 0101이라는 call(함수 호출), 0100이라면 두 수의 덧셈 등등....


예전에 FPGA(디지털 로직을 설계하여 동작시키게 하는 반도체 부품)를 이용하여 8비트 CPU를 만들어본 적이 있다. CPU를 하드웨어로 구성하는 것은 크게 어려운 일은 아니다. 물론, 예를 들어 펜티윰 CPU의 특장 중 하나인 명령을 읽어드리는 방법인 pipe line 구조나 메모리 관리 기법 중 하나인 cache tag와 같은 구조를 설계하는 것은 나의 엔지니어링 능력을 초과하는 것이지만, 그 CPU 내부에서 명령을 해독하는 microcode는 기본적으로는 같다. 결국, 0과 1의 조합을 해독하여 일을 수행하는 구조라는 것이다.


이런 구조는 디지탈 시대의 위대한 창조물인 알파고에서도 같다.(라고 판단된다) 문제는 CPU를 동작케 하는 프로그램을 어떻게작성하느냐이다. 예를 하나 들어보자.


1) C = A + B

2) int A;
int B;


sum()
{ int C;
C = A+B;
}


3) 
mov reg1, mem1
mov reg2, mem2
add reg1, reg2
mov mem3, reg1

4)
01000000 10000010
01000001 10000001
10000001
11000000 10000011


위의 네가지는 수학적 연산의 결과는 모두 같다. 차이점은 1)은 산수, 2)는 C언어, 3)은 mnemonic 그리고 4)는 기계어

CPU의 microcode는 4)의 형식으로 되어 있는 명령을 읽고 해독하여 일을 수행한다. 그리고 4) --> 3) --> 2)는 1)이라는 인간 사회에서 약속된 것을 CPU라는 것에 일을 시키기 위한 프로그래밍을 작성하는 프로그래머들이 좀더 편리하게 일을 할 수 있게 고안된 역사이다.

최초에는 4)의 방법으로 CPU가 일을 하는 프로그램을 작성했다. 내 선배들은 3)의 방법을 이용하여 프로그램을 작성했다. 내 세대는 3)과 2)의 방법을 병행하면서 프로그램을 작성했다. 내 후배들은 주로 2)의 방법으로 프로그램을 작성한다.


이 CPU에 일을 하는 역사의 발전은 산업계의 역사와 등치된다. 바로 'hardware oriented'에서 'software oriented'로의 전이...라는 표현이 그렇다. 그런데 이 과정들의 이면에서는 message 전달 방법에의 고려가 주포인트이다.


4)의 방법은 기계와 직접 대화하는 것이지만 CPU는 '0'과 '1'을  hardware적으로 전기적 신호의 높낮이로 구별한다. 그런 hardware적인 신호의 높낮이를 0과 1로 바꾸어 '기계어로 프로그램을 해서' CPU에게 일을 시키는 것이다.


즉, 4)의 방법 역시 가장 기계에 가까운 표현이지만 궁극적으로는 프로그래머가 CPU에게 일을 시키는 '메세지 전달 방법의 고려'의 산물이라는 것이다. 그렇게 4) --> 3) --> 2)의 순서대로 프로그래머가 CPU에게 일을 시키는 '메세지 전달 방법'을 편리하게 만들어져 왔다.


그런데 전자산업이 고도화되고 더 많은 일을 수행할 필요가 있으면서 이제는 프로그래머와 CPU의 메세지 전달 방법이 아닌 프로그래머들끼리의 메세지 전달 방법이 고려되어야 했다. 윈도즈의 멀티태스킹이 그렇고 한 프로그램을 여러 명의 프로그래머가 공동 제작을 할 때가 그렇다.


프로그래머들이 한 프로그램을 나누어 작성할 때는 서로 다른 프로그래머가 작성한 프로그램이 수행한 결과를 참조할 필요가 있다. 때로는 다른 프로그래머가 수행한 결과값을 조작해야할 필요가 있다. 그런데 그 다른 프로그래머가 수행한 결과갑들 중에는 내가 필요하고 조작해야할 결과값과 절대 건들어서는 안되는 과정 또는 결과값들이 있다. 이 것을 어떻게 구분해야 할까?


구분하는 방법이 있기는 하다. 서로 규칙을 정하면 된다. 그러나 그런 규칙을 정하는 것은 아마도 프로그램을 작성하는 시간보다 더 많은 시간을 소요할 것이고 빈번히 그 규칙은 위배되고 결과물인 프로그램은 엉망이 될 것이다.


이런 문제점을 해결하기 위해 프로그래머들의 '메세지 전달 방법'에 주목한 것이 바로 객체지향 프로그램(Object oriented Programming)이고 흔히 C++로 표현되는 언어툴이다.


4. 객체지향적 논쟁


객체지향 프로그램은 인문학적으로도 중요한 메세지를 던진다. 메세지 전달 방법에 주목한다는 것은 그 메세지의 결과만 취급한다는 것이지 그 메세지를 만들어낸 방법은 관심 밖이라는 이야기다. 메세지를 만들어낸 방법에 주목한다는 것은 우리가 흔히 이야기하는 것인 '메세지를 까지 않고 메신저를 깐다'는 것과 같고 다른 말로 표현한다면 '사상 검증'과 같다는 것이다.



예를 들어, 내가 비행소년님과 '한국 경제에 대하여 논쟁을 한다'고 가정해보자.



논쟁에 있어서 나나 비행소년님은 각각 상대방의 최종학력이 어떻게 되는지, 출신지는 어디인지, 사는 곳은 어디인지 그리고 연봉은 어떻게 되는지는 '한국 경제를 논하는데 전혀 관련이 없다'. 단지, 서로의 발언이 이론적으로 타당한 것인지, 그리고 그 이론이 현실에 맞게 적용이 되는지, 그리고 그 적용의 결과가 어떻게 되었는지 또는 될 것인지만을 따지는 것이다.



그러나 우리는 흔히, '학출 출신 주제에' 또는 '그 쪽 지방 출신이기 때문에' 등등 논쟁에 전혀 관계없는 소위 인신공격을 하는 것들을 너무 많이 보고 또한 스스로도 드물지 않게 범한다. 



그리고 특히, 한국에서 논쟁의 무의미성은 그 논자들의 무식과 진영논리에서도 기인하지만 이런 객체지향적 사고 방식이 부족하기 때문이다. 지금은 혐오동물로 전락한 진중권의 '척보면 압니다'라는 말이 유효한 이유이다. 논쟁의 첫마디에서 그의 속성이 드러난다는 것이다. 그리고 그런 속성이 논쟁과 관련이 없는 것을 드러내는 것이라면 무시해주는 것이 맞다.



인문학적 관점에서 본 객체지향 프로그램을 한마디로 이야기하자면 '객체지향은 민주주의의 핵심 중 하나'라는 것이다.




5. 시는 객체지향 프로그램이다.


객체지향 프로그램의 특징인 '메세지 전달 방식'을 가장 잘 활용한 것이 시라는 문학 쟝르이다. 객체지향에서 메세지는 속성과 전달의 두가지로 구성이 되어 있고 다른 프로그래머 또는 자신의 다른 프로그램 부분에서 그 메세지의 허용 범위를 논한 것이 encapsulation(캡슐화)이다.


소설은 모든 메세지의 속성과 전달 방법을 독자에게 공개한다. 그리고 그 방법의 섬세함이 소설의 완성도를 높인다. 그러나 시는 메세지의 속성은 작가가 숨겨놓고 전달방법만 공개하여 독자들에게 퀴즈를 내는 형식의 쟝르이다. 프로그램에서 encapsulation을 얼마나 잘했는지가 프로그램의 완성도를 판별하는 것 중 하나인 것처럼 퀴즈의 난이도가 시의 완성도를 판단하는 기준이 현대시다...라고 나는 이해하고 있다.



내가 최근에 시를 읽지 않았던 이유는 바로 이 퀴즈의 난이도가 너무 높기 때문이다. 그리고 '술래가 되고 싶은 생각은 추호도 없다'는 성격과 궁금증이 생기면 반드시 해답을 찾아야 하는 괴팍한(?) 성격이 맞물린 결과이기도 하다.



물론, 보다 근본적인 이유가 있다. 나는 프로그래머로서 프로그램을 작성할 때 Assemble와 C/C++ 언어 둘 중 하나를 선택하라면 Assembler를 선택한다. 보다 직관적이기 때문이다. 32비트 이상 프로세서들로 프로그램을 할 때 library를 사용할 필요가 없는 경우에는 나는 assembler로 프로그램을 작성한다. 물론, 개발기간으로만 따지면 C/C++ 로 프로그램을 작성하는 것이 훨씬 효율적이다. 나 역시 그렇다. 그럼에도 assembler를 선택하는 이유는 나의 완고함에 기인한다.



그리고 무엇보다도 text 세대인 내가 video 세대에 적응한 부작용의 결과이다. 시인분들에게 정말 죄송한 표현이지만 나는 시를 읽고 퀴즈를 푸는 것보다 웹툰을 보는게 더 낫다. 속물적이다라고 비난하면 감수하겠다. 그러나 그건 내 탓은 아니다. 생존경쟁에서 이겨야 한다는 의식의 결과이다.




아래 로자한나님께서 나를 호출하셨는데 당황스러움과 죄송함 때문에 몇 자 적었다.


내가 시에 대하여 로자한나님께 인상적인 멘트를 했었나 보다. 그런데 그건, '소가 뒷걸음질 치다가 쥐를 잡은 격'이다. 뭐, 소통의 즐거움을 생각한다면 '뒷걸음 치다가 쥐만 잡는다'면 허탕을 수백번 하더라도 뒤걸음 칠 용의가 있다. 그런데 소가 뒷걸음 치는 곳에는 쥐만 있는게 아니다. 웅덩이도 있고 심지어는 절벽도 있다. 뒷걸음 치다가 허탕치는 것이야 얼마든지 그럴 수 있겠지만 웅덩이에 빠지는 꼴을 연출한다면? 으~ 생각만 해도 얼굴이 화끈거린다.

이 게시물을...

백이숙제는 "以暴易暴"를 남겼고 한그루는 "以寂易騷"를 남기고 간다.