산수유나무

머니볼

kanie — Thu, 24 Nov 2011 01:00:44 +0900

이것은 자기모순에 관한 이야기다.

이 영화의 원작 <머니볼: 불공평한 게임을 이기는 기술> 은 소설이 아니다. 제목 그대로 미국 메이저리그에서 가장 저예산의 가난한 팀 중 하나인 오클랜드 애슬레틱스가 어떻게 효율적으로 경기를 꾸려나가는가에 관한 보고서에 가깝다.

그러나 주연 브래드 피트가 제작에 참여한 이 영화는, 지독하게 냉정하고 또 감상적인 남자에 관한 이야기가 되었다.

일반 관중에게는 가장 눈에 띄지 않는 존재 가운데 하나일 터인 "단장"(General Manager)이라는 직위는 어떤 선수에게 얼마의 연봉을 주고 데려올 것인지를 결정하는 역할을 맡는다. 이 영화의 소재는 야구가 아니다. 야구에서 가장 재미없지만, 그러나 가장 중요한 문제인 선수들의 연봉과, 그것을 결정하는 사람에 관한 이야기다.

메이저리그의 30개 팀 가운데 가난하기로는 두세번째를 다투는 팀인 오클랜드 애슬레틱스의 단장 빌리 빈이 팀의 가난을 해결하기 위해 가져온 도구는 너무나 당연하게도 경제학이다. 실력에 비례해서 연봉이 결정되는 야구판이지만, 기존 스카우터들은 타율이나 방어율 등 전통적인 통계수치를 가지고 선수의 가치를 판단하고 있었다. 빌리 빈은 이런 관행을 깨고, OPS라는 저평가된 수치를 바탕으로 선수를 사모으기 시작한다.

OPS는 출루율+장타율을 의미한다. 이 수치는 이론적으로 팀이 한 회에 낼 수 있는 평균 점수에 직결되어 있다. 장타율이 높은 선수는 기존에도 높은 연봉을 받고 있었으나, 출루율은 상대적으로 저평가되어 있었다. 사구나 볼넷으로 출루하는 경우도 출루율에 포함되기 때문. 그러나 출루율이 높은 선수는 야구에서 가장 귀하고 늘릴 수 없는 자원인 아웃카운트를 소모하지 않으며 득점확률을 올릴 수 있고, 또한 상대 투수의 투구수를 늘려 체력을 소모시키게 된다. 또한 볼을 골라내는 선구안이 좋은 타자들이 출루율이 좋은데, 선구안은 훈련으로 쉽게 향상시킬 수 있는 기술이 아니므로 좋은 타자의 재목을 나타내는 수치가 된다.

그러면 이 영화는 일부 야구팬들이 열광하는 야구의 통계에 관한 이야기인가? 그것도 아니다. 출루율은 그저 "경제적으로" 저평가된 수치일 뿐 만능의 수치가 아니며, 영화는 그 수치를 그다지 진지하게 다루지 않는다. 수많은 숫자가 흘러가지만 그저 맥락이 없는 무의미한 잡음일 뿐이다.

영화가 상영시간 내내 보여주는 것은 빌리 빈이 싸우고 고민하고 협상하는 장면이다. 선수들의 연봉 총합이 뉴욕 양키즈의 4분의 1에 지나지 않는 오클랜드 애슬레틱스를 상위 팀으로 올려놓기 위해 그는 차가운 냉혈한처럼 행동한다. 주어진 예산 안에서 가장 좋은 선수를 뽑으려면 팀의 기존 스타 선수는 비싼 값에 팔고 그 돈으로 저평가된 유망주들을 사들여야 한다. 팀에서 키워낸 선수들을 계속 떠나보내는 데 익숙해져야 한다는 것이다.

그는 실제 야구경기를 보지 않는다. (실존인물 빌리 빈도 경기를 관람하지 않는 걸로 유명하다고 한다) 그가 끝까지 밀어붙인 방식으로 팀이 승승장구할때 언론이 그 공을 자신이 아닌 감독에게 돌려도 개의치 않는다. 입버릇처럼 "이래서 야구를 사랑하지 않을 수 없다니까" 하고 얘기하지만, 감독과 신나게 말다툼하고 난 뒤에 나오는 대사라면 아무래도 진심은 아닌 것 같다. 야구를 좋아하기는 하는 것인가. 애초에 왜 이 게임에서 이기려고 하는 것인가.

이것은 루저에 관한 이야기다.

패배는 개인적인 것이다. 돈으로 승자가 결정되는 게임을 플레이하는 것, 그 자체가 그에게는 패배이다. 그러나 그가 게임을 바꾸기 위해 선택한 수단 또한 돈이다. 가장 적은 돈을 가장 효율적으로 써서 승리함으로서, 그는 게임 그 자체를 바꾸고자 했다.

오클랜드는 20연승이라는 대기록을 세우고 수위의 성적으로 포스트시즌에 진출한다. 1승당 가장 적은 돈을 들여 효율적으로 승리를 거두었다니, 단장으로서는 큰 성공을 거둔 것이다. 그러나 그에게 중요한것은 "마지막 경기" 뿐이다. 오클랜드는 2002년에도 5번째 경기에서 패배하여 챔피언스 리그 진출에 실패하자, 빌리 빈은 그것을 개인적인 패배로 받아들인다.

야구를 즐길 줄도 모르고, 이길 줄도 모르고, 그저 경제적으로 수행할 줄만 아는 빌리 빈은 왜 메이저리그에서 두번째 부자 구단인 보스턴 레드 삭스의 250만 달러 연봉을 수락하지 않고 오클랜드에 남았는가. 그야, 긍지를 가지고 패배하는 것만이 인생의 유일한 승리이기 때문이다. 이 세상 누구도 합목적적이고 합리적인 우주를 가질 수는 없다. 이 우주에 궁극적인 승리란 존재하지 않는다. 그렇다면 "마지막 경기"에서 패할 때 긍지를 잃지 않기 위해 발버둥치는 수밖에. 누군들 그렇지 않겠는가.

R.I.P DMR

kanie — Fri, 14 Oct 2011 09:09:58 +0900

데니스 리치 (1941-2011)

#include <stdio.h>

int main(void)
{
    printf("goodbye, world\n");
    return 0;
}

짜증...

kanie — Fri, 30 Sep 2011 13:51:07 +0900

http://infuture.kr/1033

이 글의 논지는 별 문제가 없는데... 도킨스를 비난하는 논리가 이기적 유전자 읽어보지도 않고 도킨스 비난하는 종교인들 논리랑 너무 비슷하더라.

그래서 소셜 댓글 어플 달려있는 걸로 몇마디 했더니 리플이 다 지워졌다. 블로그에 javascript로 연결시켜 주는 외부 서비스인 듯 하니 뭐 일부러 지운 건 아니고 주인장의 실수로 링크를 깨뜨린 걸 수도 있겠으나... 어느쪽이던 다시 말 꺼내기 싫어서 그만두었다.

내가 단 리플 내용은 대충 이렇다.

이기적 유전자 제목만 대충 읽고 도킨스를 비난하는 사람이 참 많네요. 도킨스가 책 안에서도 그 후의 저서에서도 여러번 밝혔듯 이기적인 것은 유전자일 뿐 유전자의 표현형인 생물이 이기적이라는 얘기가 아닙니다.

뭐 이 부분은 다른 사람들도 리플로 많이 한 얘기고... 블로그 원문에는 이런 문단이 있다.

여기에 리처드 도킨스가 쓴 '이기적 유전자'가 출간된지 40년이 되어가는데도 여전히 과학도서 중 베스트셀러로 건재한 것을 보면 그만큼 왜곡된 다윈주의가 우리 사회에 얼마나 많이 남아있고 조직을 이끄는 경영자들을 포함한 많은 이들의 사고의 틀을 얼마나 강하게 형성하고 있는지 가늠할 수 있습니다. 도킨스가 스스로 '이기적 유전자는 사이언스 픽션으로 읽어야 한다. 상상력을 자극하기 위해 쓰였기 때문이다'라고 고백했지만, 사람들은 그 책의 내용이 사실이고 유일한 관점으로 왜곡하는 듯하여 안타깝습니다.

이 문단만 보면 도킨스의 저서가 사실이 아니고 SF라는 것을 도킨스가 자기 입으로 밝혔는데도, 많은 사람들이 아직도 사실이 아닌 주장을 신봉하는 것처럼 보인다. 그런데 블로그 글쓴이가 인용한 원문은 사실 이기적 유전자 저자 서문의 첫 줄이다. 이 내용은 다음과 같이 이어진다.

이 책은 마치 과학소설인 것처럼 읽어야 한다. 상상력을 자극하기 위해 쓰여졌기 때문이다. 그러나 이 책은 과학소설이 아니고 과학이다. 클리셰이긴 하지만 '픽션보다 기이하다'는 말은 내가 진실에 대해 가진 느낌을 정확히 표현하고 있다.

아래는 영어 원문.

This book should be read almost as though it were science fiction. It is designed to appeal to the imagination. But it is not science fiction: it is science. Cliche or not, 'stranger than fiction' expresses exactly how I feel about the truth.

뭐 오해받기 딱 좋게 글을 쓴 도킨스의 책임도 일부 없지 않다. 대중과학서 첫 줄에 이 책은 과학소설로 읽으라니... 30주년 기념판 서문에서는 <Selfish Gene>이 아니라 <Immortal Gene>이라고 지으라는 출판업계 사람의 충고를 들을걸 그랬다고 후회하는 대목도 나온다. 아무리 그래도 앞의 두 문장만 따서 인용해 놓고 책 내용이 사실이 아닌 양 하는 것은 저술가이기에 앞서 과학자인 도킨스에 대한 모독이라 하겠다.

그래서 악의적 인용이 오해를 불러일으키는 것 같습니다... 라고 했으나 말이 심하다고 하시는데... 음 정말로 말이 심한 것은 <'이기적 유전자'는 허구다> 라는 글 제목이 아닌가 싶은데. 아무튼 그 뒤는 리플이 지워져서 더이상 말을 섞지 못했다.

게으른 프로그래머를 위한 루비 튜토리얼 #5

kanie — Thu, 15 Sep 2011 19:01:38 +0900

루비 튜토리얼 4편을 쓰고 나서 3년이 지났습니다. 음음. 그간 많이 게을렀군요. 변명을 해보자면 결혼(!)이라던지 하는 여러가지 개인적 사정이 있었답니다. 기다려주신 분이 있다면 죄송합니다.

그럼 5편을 바로 시작해볼까요.

지금까지는 재미없지만 몰라서는 안될 기본적인 사항들을 다뤘습니다. 기본적인 화면출력, 자료구조, 분기문과 반복문, 클래스 같은 것을 다루었죠. 이제 조금 생소하지만 정말 재밌는 부분으로 넘어가 봅시다. 여기부턴 다른 언어에서는 만나보기 힘든 내용이니 조심조심 따라와 주세요.

오늘은 파일을 열어볼 겁니다. 파일 읽고 쓰기는 참 쉽습니다.


# 파일은 open 함수를 이용해서 열 수 있습니다.

# "test.txt" 파일을 쓰기 모드("w")로 열어봅시다.

# 주의! 윈도우에서는 "wb" 모드로 여는 것을 추천합니다.

f = open("test.txt", "w")



# open 명령으로 파일 오브젝트를 열어 f 라는 변수에 넣었습니다.

# 이제 1편에서 보았던 puts 함수를 쓸 수 있습니다.

f.puts "Matz"



# print 함수는 뒤에 newline이 붙지 않는 것 기억하시죠?

# 윈도우에서는 \n 대신 \r\n 이 newline입니다.

f.print "Steve Jobs\n"



# write 함수도 있습니다. print와 거의 같습니다.

# 마찬가지로 윈도우에서는 \n 대신 \r\n 을 써줍시다.

f.write "Bill Gates\n"



# 아무리 게을러도 다 쓴 파일은 반드시 닫아야 훌륭한 프로그래머가 됩니다.

f.close

자 이제 메모장이나 여러분이 사랑하는 어떤 텍스트 에디터로든지 파일을 열어보면 세 사람의 이름이 한줄씩 써 있을 겁니다.

이게 어디가 다른 언어에서 만나보기 힘든 내용이냐구요? 에이... 조금만 기다려 보세요.

파일을 읽기도 해봐야죠.


# 아까 그 파일을 읽기 모드 "r"로 읽습니다.

# 주의! 쓸 때와 마찬가지로 윈도우에서는 "rb" 모드로 여는 것을 추천합니다.

f = open("test.txt", "r")



# read 함수는 파일 전체를 읽어서 문자열로 저장합니다.

string = f.read



puts string



# 파일을 썼으면 닫아야죠.

f.close


Matz

Steve Jobs

Bill Gates

쉽죠? 그렇지만 파일 전체를 읽어서 메모리에 저장하는 건 큰 파일을 다뤄야 할 때는 현명하지 못한 방법이죠. 파일을 한줄한줄 읽어봅시다.


f = open("test.txt", "r")



# 2편에서 봤던 each 함수 기억하세요?

# 파일 오브젝트에는 each_line 함수가 있습니다!

# 파일을 한줄씩 읽어서 line 변수에 저장하고, line 변수를 print 함수로 출력합니다.

f.each_line { |line| print line }



f.close


Matz

Steve Jobs

Bill Gates

그럴싸하죠?

{ |line| print line } 요 부분이 오늘의 주인공, 블록(block)입니다. 블록은 인자를 받을 수 있는 임시 코드 조각으로 생각하시면 됩니다. 여기서는 |line| 이 인자가 되고 print line 이 코드 조각이 되는 것이죠.


f.each_line { |line| print line }

이 코드에서 f.each_line 함수는 파일을 한줄한줄 읽어들인 후 line 인자에 넣어 블록으로 전달합니다. 우리가 아까 쓴 파일에는 3개의 이름이 있으니, 블록은 3번 실행되겠죠.

루비에는 배열에서 사용한 each 함수나 파일에서 사용한 each_line 함수처럼 코드 블록을 인자처럼 사용할 수 있는 여러가지 함수들이 있습니다. 재미있는 것만 몇가지 살펴볼까요?


# 모든 정수에는 times 함수가 존재합니다.

# 블록을 해당 숫자만큼 반복 실행하는 함수입니다.

3.times { puts "knock" }


knock

knock

knock


# There is more than one way to do it! 기억하시나요?

# { ... } 블록 대신 do ... end 로 감싸서 사용할 수도 있습니다.

# 의미는 완전히 동일합니다.

3.times do

    puts "knock"

end


knock

knock

knock


# 문자열을 한글자씩 잘라주는 each_char 함수도 유용합니다.

"ABC".each_char do |c|

    puts c

end


A

B

C


# 1편에서 봤던 자료구조 Hash 기억하시죠?

h = {"one" => 1, "two" => 2, "three" => 3}



# Hash에도 each 함수가 있습니다.

# Hash의 each 함수는 key와 value를 쌍으로 블록에 넘깁니다.

h.each do |key, value|

    puts key

    puts value

end


one

1

two

2

three

3


# map 함수는 배열의 모든 값에 블록 내용을 실행한 새로운 배열을 리턴합니다.

# 배열의 값에 2를 곱해 볼까요?

[1, 2, 3, 4].map {|x| x * 2}

# => [2, 4, 6, 8]



# 특정 조건을 만족하는 값을 찾는 것도 select 함수로 간단히 해결됩니다.

# 1, 2, 3, 4 가운데 짝수만을 리턴하게 해봅시다.

[1, 2, 3, 4].select { |x| x % 2 == 0 }

# => [2, 4]



# 정수 오브젝트에 포함된 even? 함수를 이용하면 더욱 간단합니다.

# 함수 뒤의 물음표도 함수 이름에 포함되므로 붙여써야 하는 점에 주의하세요.

[1, 2, 3, 4].select { |x| x.even? }

# => [2, 4]

재미있죠? 블록을 받아 동작하는 다양한 함수들이 있기 때문에 루비 코드는 간결하고 아름다워집니다. 서로 비슷한 일을 하지만 아주 조금씩 다른 동작 때문에 비슷비슷한 루프를 만들어야 했던 어떤 언어들과 비교하면 참으로 상쾌하죠.

블록을 받는 함수는 우리도 만들 수 있습니다. 조금 전까지 열었다 닫았다 했던 그 파일 기억하시죠? 파일을 열고 닫는 코드를 반복해서 썼었죠. 솔직히 그런 반복은 지겹습니다. 우리는 게으르잖아요. 파일을 필요할 때 열고 할일이 끝나면 알아서 닫게 하고 싶으면 어떻게 하면 될까요?


def test_open

    # 파일 열고 닫기가 지겨워서 함수에 담아보려고 합니다.

    myfile = open("test.txt", "r")



    # 이 한줄이 마술의 핵심입니다.

    yield myfile



    # 파일을 닫습니다.

    # 이미 닫힌 파일을 두번 닫으면 에러가 일어나므로

    # 닫혀 있는지 먼저 체크해야 합니다.

    if not myfile.closed?

        myfile.close

    end

end



test_open do |f|

    f.each_line do |line|

        print line

    end

end


Matz

Steve Jobs

Bill Gates

대체 무슨 일이 일어난 건가요?

이 코드는 한줄한줄 따라가면서 설명해 보겠습니다.

먼저 test_open 함수를 정의했죠. 함수 안에는 처음보는 키워드 yield가 포함되어 있군요. 안에 yield 문이 들어있는 함수는 "아 이 함수는 블록을 붙여서 사용하는 함수구나" 하고 생각하시면 됩니다.


test_open do |f|

    ...

end

test_open 함수를 블록과 함께 호출하면 일단 블록은 무시하고 먼저 함수가 실행됩니다. 함수의 첫번째 줄로 가봅시다.


    myfile = open("test.txt", "r")

파일을 열어서 myfile 변수에 담았죠


    yield myfile

yield는 함수에 주어진 블록을 실행하는 부분입니다. yield 뒤에 인자를 주면 해당 인자가 블록에 전달되지요. 우리도 블록으로 따라가 볼까요.


test_open do |f|

    ...

end

해당 블록은 do ... end 부분이고 |f| 를 인자로 받는 것을 알 수 있죠. 아까 yield myfile로 이 블록을 호출했으니 인자 f 에는 아까 저장된 myfile의 값이 저장됩니다.


    f.each_line do |line|

        print line

    end

이곳에서 f의 내용이 한줄씩 화면에 출력되고 블록은 종료됩니다.

블록의 내용이 종료되면 context는 다시 원래 함수의 원래 위치로 돌아가서 실행을 계속합니다. yield의 다음줄은 파일 닫는 구문이었죠. 논리 부정 연산자 not 도 봐둡시다.


    if not myfile.closed?

        myfile.close

    end

파일을 안전하게 닫고 함수는 정상적으로 종료됩니다.

어떻습니까? 파일 닫기를 내가 굳이 부르지 않아도 마지막에 자동으로 호출해주는 안전한 함수가 쉽게 완성되었죠. 이 함수는 사실 루비가 기본으로 제공하는 함수를 직접 손으로 구현해본 것입니다. open 함수는 블록과 함께 부르면 정확히 우리의 test_open 함수처럼 동작합니다. 정말 그런지 확인해볼까요?


# nil 은 빈 값을 의미합니다. Java의 null이나 C/C++ 의 NULL 에 해당합니다.

# 여기서는 비어있는 변수 myfile을 만들어 봅시다.

myfile = nil



open("test.txt", "r") do |f|

    # 블록 인자는 블록 바깥에서 접근할 수가 없습니다.

    # 여기선 나중에 열어보기 위해 외부 변수인 myfile에 담아봅시다.

    myfile = f



    # 파일 내용을 출력한 후 닫습니다.

    puts f.read

end



# 블록과 함께 호출했기 때문에, open 함수의 실행이 끝나면 파일은 이미 닫혀 있습니다.

# myfile.read는 파일이 이미 닫혀 있다는 내용의 에러를 일으킵니다.

myfile.read


Matz

Steve Jobs

Bill Gates

tutorial5-3.rb:16:in `read': closed stream (IOError)

    from tutorial5-3.rb:16:in `<main>'

재미있으셨나요? 머리가 아프신가요? 아직 이정도에 좌절하시면 안됩니다. 오늘 내용을 정리할 겸, 제가 다음 튜토리얼을 쓸 때까지 시간벌기를 할 겸 (...), 연습문제를 하나 드리죠. 1편부터 5편까지의 내용을 이용해서 my_times 함수를 구현해 보세요. my_times 함수는 다음과 같이 동작해야 합니다.


my_times(3) do

    puts "knock"

end


knock

knock

knock

어떻게 하면 블록을 원하는 숫자만큼 실행하게 할 수 있을까요?

힌트 : yield 키워드는 다른 루비 함수처럼 인자 없이도 사용할 수 있습니다.

연습문제 답은 밑에 접어두겠습니다.

답 확인해보기

def my_times(n)

    for i in 1..n

        yield

    end

end

이상과 현실

kanie — Wed, 20 Jul 2011 16:04:54 +0900

언젠가 결혼한다면, 혹시 자식도 낳는다면 두가지 타입으로 분류하고 대응하겠다. 이 친구가 현실주의자라면 현실이 어떤 곳인지 똑똑히 보여줄 것이다. 이 폭압적인 세상에서 살아남는 법을 알려주고, 이렇게 말하겠다. '니 능력껏 살아라. 너의 능력으로 현실을 극복하고, 거기서 삶의 의미를 찾아라. 그리고 이상주의자를 도와라.' 한편 이 친구가 이상주의자라면 현실이 털끝도 건드리지 못하도록 하겠다. 순수함을 잃지 않는한 모든 것을 스폰싱해줄 것이다. 그리고 이렇게 말 할 것이다. '시궁창 같은 현실은 내가 살고 있는 곳이다. 너는 그 꿈을 계속 꾸면 되는거다. 그게 니가 살아가는 의미다. 그걸 놓는 순간 너는 아무것도 아닌 게 된다.' 물론 이 글은 있지도 않은 자식에게 하는 말이 아니다.

http://egoing.net/1581

"리처드 스톨만은 이상주의자다. 그리고 리누스 토발즈는 현실주의자다."

내가 이렇게 말한다면 이것은 리처드 스톨만이나 리누스 토발즈에 대해 많은 것을 알려주는가? 아니다. 오픈 소스 소프트웨어의 이상과 현실에 대해 내가 어떻게 생각하는지를 훨씬 많이 알려준다. (내가 정말로 이렇게 생각한다는 것은 아니다. 나는 이상과 현실이라는 이분법에 큰 관심이 없다.)

마찬가지로, 내 자식이 현실주의자인지 이상주의자인지 판단하는 것은 내 자식에게 달려 있지 않다. 내가 이상과 현실에 대해 어떻게 생각하는지에 훨씬 크게 달려 있다. 30년, 혹은 그 이상의 미래를 살아갈 내 자식의 이상과 현실에 대해 판단하는 것이 리누스 토발즈가 어떤 사람인지 판단하는 것보다 과연 생산적인 일일까?

이상주의자인지 현실주의자인지 따위의 시시한 판단은 아니더라도, 나도 언젠가는 내 자식에 대해 판단을 해야 할 것이다. 그러나 어떤 판단을 내리더라도 "그걸 놓는 순간 너는 아무것도 아닌 게 된다." 따위의 협박을 하지는 않을 것이다. 내 경험상, 자신을 구성하는 것 중에 무엇이 중요하고 무엇이 중요하지 않은지를 부모가 결정해준 사람은, 성인이 되고 나서의 인생이 상당히 피곤하다.

소스코드

kanie — Mon, 16 May 2011 17:49:58 +0900

오랜만의 영화 리뷰입니다. 요즘은 예전처럼 영화를 많이 안보는데 그 책임은 거의 전적으로 동네 영화관에 있습니다. CGV의 상영작 선택은 항상 별로라고 생각했는데 동네 CGV 상영관은 그 중에서도 좀더 재미없는 영화를 틀어주는데 주력하고 있습니다. 상영관은 8개나 되는데 말이죠.

소스코드는 여러가지 장르가 혼합된 영화입니다. 한가지 장르에만 충실한 영화는 의외로 많지 않겠지만서도 이 영화는 기존 장르물의 여러가지 소재를 이어붙여서 만든 것 같은 인상을 줍니다. 반복되는 시간을 소재로 한 서스펜스물, 주로 두 남녀의 대화로 구성된 로맨틱 코미디, 매트릭스를 생각나게 하는 가상현실 SF, 그리고 시간여행과 평행우주론 SF에서 흔히 보이는 아이디어도 몇가지 가져옵니다.

미국 육군의 헬리콥터 조종사 콜터 스티븐스 대위는 아무런 사전정보 없이 통근열차 안에서 깨어납니다. 앞자리에는 처음 보는 아름다운 여자가 앉아 있는데 이 여자는 주인공에게 아는척을 해요. 그런데 이 여자는 주인공을 콜터가 아니고 "션"이라는 이름으로 부릅니다. 주인공은 여기가 어딘지, 자신이 누구인지 알 수 없는 혼란스러운 상황에 처해 있는데, 아무런 사전정보가 없는 관객들 역시 혼란스럽긴 마찬가지죠. 정신이 나간채로 열차 안을 이리저리 방황하던 중, "뻥"! 폭탄이 터지고 스티븐스 대위는 사망합니다. 끝.

...이 아니고 다시 깨어난 주인공은 이번에는 알 수 없는 어두운 방 안에서 깨어납니다. 자신은 방 안에 단단히 묶여 있고 외부와 소통할 수 있는 수단은 오로지 모니터 너머에 앉아 있는 콜린 굿윈이라는 공군 장교 뿐입니다. 여기서 주인공의 상황이 좀더 자세히 밝혀지죠. 주인공 콜터 스티븐스에게는 어떤 컴퓨터 프로그램 속에 들어가 폭탄테러범의 정체를 알아내야 하는 임무가 주어져 있죠. 프로그램 안에서 그는 폭탄테러의 사망자인 션 펜트리스의 기억을 대신 체험하게 되며, 프로그램 안에는 여러번 다시 들어가볼 수 있지만, 주어진 시간은 폭발로 사망하기 직전의 8분 뿐입니다. 8분 안에서 약간씩 달라지는 사건들을 겪으며 주어진 시간을 계속 다시 체험하게 되는 것이죠.

이야기는 3개의 공간 안에서 전개됩니다. 하나는 콜터 스티븐스가 폭탄테러범을 찾아내고 연애도 하며 덤으로 사람들도 구해냈으면 하다가 죽어버리는 시카고 통근열차 안, 하나는 굿윈 대위와 대화하는 방 안, 그리고 마지막으로 굿윈 대위와 "소스코드"라는 시스템을 발명한 러트리지 박사가 있는 연구실입니다. 2011년과 큰 기술적 차이가 없어 보이는 배경에서 (스마트폰마저 좀 옛날 모델인 것 같아요) 이런 충격적인 기술적 성취가 어떻게 가능했는지에 대한 설명은 거의 없습니다. 그냥 양자역학이 어쩌구저쩌구 하는데 뭐 자세한 설명이 꼭 필요한건 아니긴 하죠.

이 아래부터는 스포일러가 있습니다. 중간쯤에 밝혀지는 정보지만 그래도 혹시나 해서 가려둡니다.

스포일러 보기

영화가 집중하고 있는 공간은 시카고 통근열차 안이예요. 8분이라는 시간은 감독이 의도적으로 선택한 숫자인 것 같습니다. 제가 지금까지 본 영화나 드라마 가운데 반복되는 시간을 소재로 다룬 작품들은 보통 하루를 단위로 반복되었기 때문에 중간중간 많이 뛰어넘어야 했지만, 소스코드의 8분은 미드 <24>나 영화 <메멘토>처럼 실시간으로 진행됩니다. 죽기 직전의 8분동안 연애도 하고 세계도 구하고 자신이 어쩌다 이런 처지가 된 건지도 알아내야 해야 하다보니 주인공의 모든 행동은 전략적인 선택이 되어야 하고, 자연히 서스펜스가 생겨나죠. 시간을 뛰어넘을 필요가 없어집니다.

기차 안에서 발생하는 서스펜스의 성격은 약간 독특합니다. 주인공은 첫번째 8분이 지난 후에는 자신이 반복되는 시간을 경험하고 있다는 것을 분명히 알게 되지만, 마치 그 사실을 일부러 모른 체 하는 것처럼 행동합니다. 폭탄테러범 수색에 집중하고는 있지만 그 이유가 군인으로서의 임무수행이 아니라, 눈앞에 있는 아름다운 여성 크리스티나를 비롯한 열차의 승객들을 구하고 자신도 살아남는 것이 목적인 것처럼 보여요.

그 이유는 아무래도 주인공이 죽었기 때문인 것 같습니다. 정확히 말하면 콜터 스티븐스 대위는 뇌의 일부만 살아서 프로그램을 통해 외부와 소통하고 있죠. 굿윈과 대화를 나누는 좁은 방은 현실의 공간도 아니고, 누군가가 만든 프로그램도 아니며 심리적이고 상징적인 공간이라는 힌트가 상당히 초반부터 주어지죠. 그 방은 그를 단단하게 가두고 있는 것처럼 보이지만, 자신이 죽었다는 사실을 아는 순간 일그러지며 확장됩니다. 마치 현실과 자신의 거리감을 나타내는 것처럼요. 주인공은 자신이 처한 상황을 정확히 알게 되자 더욱 현실과의 괴리를 느끼고 가상현실 속의 세계에 집착하게 됩니다.

저는 단테의 연옥에 해당하는 이 중간지대의 묘사가 좋았습니다. 그러고보면 <매트릭스> 시리즈에서도 저를 매혹시킨 것은 가상세계나 현실세계보다는 주인공들이 Loading Room이라고 부르는 중간지대였죠. 주인공에게 호감을 갖고 인간 대 인간으로 대하면서도 차분하게 그의 임무를 환기시키는 굿윈과의 대화도 좋았구요. 이런 부분은 굿윈 역의 배우 베라 파미가의 힘이라고 봐야겠죠.

하지만 이 중간지대의 묘사가 열어놓은 SF적 가능성에 비하면 시카고 통근열차 안에서 전개되는 이야기의 결말은 상당히 시시합니다. 주인공은 열차 안에서 필요한 거의 모든 것을 알아낼 수 있는 유리한 입장에 있기 때문에, 용의주도한 척 하는 테러리스트는 의외로 쉽게 잡힙니다. 주인공에게 호의적인 굿윈의 도움으로 승객들의 목숨도 간단히 구할 수 있게 됩니다.

평행우주론의 아이디어를 갖다붙인 마지막은 특히 별로였어요. 주인공은 션 펜트리스의 인생을 살아가는데 불만이 없는 것인가! 불쌍한 션 펜트리스 선생님은 어디로 간 것인가! 영화가 열어놓고 있는 시시한 SF적 세계에 비하면 남녀 주인공이 키스하면서 시간이 멈추는 그 장면에서 영화가 끝났다면 오히려 결연한 아름다움을 지닌 결말이 되었을걸요. 게다가 소스코드라는 비인간적이지만 훌륭한 시스템은 영원히 제대로 활용되지 못한 채 예산만 잡아먹다가 퇴출되는 평행우주가 적어도 하나는 존재할 겁니다. 모든 테러가 미수로만 끝나게 될테니까요. 엔딩을 선택하는데 좀더 용감했으면 좋은 영화로 남을 뻔 했습니다.

ps. 다른 사람의 몸을 빌려 과거를 체험하는 아이디어는 <퀀텀 리프>라는 작품에서 따왔다고 하네요. 저는 못 본 작품이라 모르겠지만, 이 작품의 패러디가 몇가지 등장한다고 합니다.

나의 언어 편력기

kanie — Thu, 05 Aug 2010 13:44:04 +0900

http://langdev.net/post/141 이곳을 보고 여러가지가 생각나서 적어본다.

* 1993 : GW-BASIC

국민학교 다닐 때의 일이라, 학교에서 운영하던 방과후 컴퓨터 교실에서 배운 것이 먼저였는지 우리집에 컴퓨터를 구입하고 설치하는 것을 도와준 외삼촌이 알려주었는지 기억이 확실치 않다. 컴퓨터가 단순히 게임하고 타자쳐서 글쓰는 기계가 아니고 내가 시킨 일을 수행하기도 한다는 것을 가르쳐 준 언어.

루비 튜토리얼에서도 한번 언급한 적 있지만, 함수도 없고, 사용자 정의 데이터타입도 없고, 변수 스코프도 없는, 구조적 측면에서는 정말 초보적인 언어다. 그러나 복잡한 개념을 가르칠 필요 없이 바로 눈에 보이는 결과가 나온다는 점에서 교육용 언어라는 애초의 목적에는 충실한 언어였다.

95년 무렵부터 엄마를 졸라 사설 컴퓨터 학원에 다녔는데, 이곳에서 QuickBASIC을 구할 수 있었다. QuickBASIC은 GW-BASIC의 상당히 업그레이드된 버전이었다. 함수와 C 스타일의 typedef를 제공했고, 인터프리터 환경에서 개발한 후 EXE 파일로 컴파일할 수도 있었다. 무엇보다 간단한 에디터와 디버거를 통해 IDE와 유사한 환경을 제공했다. 예제 코드도 상당히 많이 들어 있었기 때문에, 프로그래밍의 기본을 QuickBASIC으로부터 다 배웠다 해도 과언이 아니다.

* 1996 : C

위에 언급한 사설 컴퓨터 학원에서 turbo C 컴파일러를 통해 C를 배우게 되었는데, 대단한 언어라고 들었던 C가 어렵기만 하고 별로 재밌지 않아서 실망했던 기억이 있다. 명령어만 입력하면 삑삑 소리도 나고 원하는 위치에 글자도 뿌릴 수 있었던 GW-BASIC과 달리 C는 그 자체로 할 수 있는 일이 별로 없었다. 결국 QuickBASIC에 더 많은 시간을 투자했던 것으로 기억한다.

애초에 시스템 프로그래밍 언어를 지향했던 C로서는 나의 악평(?)이 억울했겠지만, 당시 좀더 강력한 라이브러리를 자랑하던 borland나 watcom의 컴파일러는 나로서는 쉽게 구할 방법이 없었다. (turbo C 역시 borland사의 제품인 걸로 알고 있는데 어떻게 구했는지는 기억이 나지 않는다. 아마 불법복제였던 듯 싶다.)

1999년 무렵에 gcc를 도스용으로 포팅한 djgpp 컴파일러를 통해 다시 C를 만나게 되었을 때 드디어 C의 매력에 빠지게 되었다. djgpp는 일단 공짜로 쉽게 구할 수 있었고(!) gnu 진영의 다양한 라이브러리를 쉽게 설치할 수 있었다. 이전까지는 게임 불법 다운로드(...)에나 사용하던 PC 통신에서 프로그래밍 관련 정보를 얻을 수 있다는 걸 알게 된 것도 이 무렵이었는데, 여기서 유전 알고리즘에 대한 간략한 소개를 보고 직접 prisoner's dilemma 문제를 코딩해 보기도 했는데 결과는 중구난방이었다. 지금 생각해보면 CPU가 구린 것을 나름 보완한다고 진화압력과 돌연변이 확률을 너무 크게 잡았기 때문이 아니었나 싶다.

* 2000 : C++

djgpp는 C 컴파일러이기도 했지만 C++ 컴파일러이기도 했기 때문에 자연스럽게 C++를 접할 수 있었다. C++는 참 이름을 잘 지은 것이, 사실 C와 큰 관련이 없는 언어지만 이름 때문에 C의 후계자가 C++라고 아주 당연하다는 듯이 생각하고 있었던 것 같다.

C++는 수많은 키워드와 에러나기 쉬운 메모리 관리 시스템 때문에 참 어려웠는데, 나는 "진짜" 프로그래밍 언어는 어려운 것이 당연하지 하면서 열심히 배웠다. 지금은 단순히 C++의 문법이 지저분한 것 뿐이라고 생각한다. 게다가 당시에는 C++ == MFC 인 것마냥 대부분의 책이 MFC만을 다뤘기 때문에, C++의 진짜 힘인 template의 존재를 알지 못했다. MFC나 좀 건드려 보다가 말았던 걸로 기억한다. 매크로로 떡칠된 MFC의 라이브러리 디자인은 지금도 좋아하지 않는다.

나중에 대학교에 들어와서 C++를 다시 돌아보게 되는 데는 Effective C++와 더 나중에 만난 Modern C++ design 의 도움이 컸다. 특히 Modern C++ design은 C++의 강력함과 한계를 동시에 알게 해 주는 책이다. 적극 추천하는 바이다.

* 2003 : java

대학교에 들어와서 전공이 정해진 후 프로그래밍의 기초 시간에 Java를 처음 배웠던 것 같다. C++과 열심히 씨름했던 덕분에 Java는 참 쉽게 배울 수 있었다. template을 제외하면 C++의 핵심적인 기능은 대부분 Java에도 있었고, 덤으로 좀더 단순한 문법과 풍부한 기본 라이브러리를 자랑한다. (Java에도 훗날 template이 추가되었다.)

그러나 개인적으로는 java가 차지하고 있는 위치가 애매하달까... CPU 성능을 극단적으로 요구하는 프로젝트는 C가 더 나은 경우가 많고, 병렬 프로그래밍은 haskell이 훨씬 쉽고, 보다 generic한 프로그래밍에는 상황에 따라 파이썬이나 루비를 사용하기 때문에 요즘은 java는 그다지 좋아하지 않는다.

특히 자바 커뮤니티는 다른 언어로 된 라이브러리 갖다 쓰는 것을 굉장히 싫어하고 모든 것을 자바 언어 내에서 해결하고 싶어하는 특징이 있는데, 나에게는 별로 맞지 않는 것 같다.

* 2004 : nML

이 언어는 모르는 사람들이 많을 텐데, 서울대학교 이광근 교수님이 Standard ML과 OCaml의 디자인을 합쳐 만든 ML의 방언이다. 프로그래밍 언어 시간에 nML을 처음 만났을 때의 충격을 아직도 잊을 수 없다. 아마 함수형 언어를 배운 사람들은 대부분 함수형 언어와 처음 만나는 순간을 충격적으로 기억하고 있을 게다.

함수형 언어의 심플한 아름다움은 아마 접해본 사람은 다들 알고 있을 것이고 접해보지 않은 사람에게는 말로 전달해줄 능력이 없다. 두려워하지 말고 만나보라고 할 수밖에. 프로그래밍을 바라보는 눈이 바뀔 것이다.

하지만 지금은 nML을 쓰지 않는다. 함수형 언어를 쓰고 싶은 프로젝트를 만나면 그냥 Haskell을 쓴다...

* 2004 : PHP

웹 프로젝트에 잠시 사용해 봤다. 끝... 이 아니고...

네트워크 프로그래밍 시간에 처음 써봤고, 이후에도 웹 개발할 일이 있을 때 한두번 더 써보기도 했지만, 지금은 웹 개발은 전부 루비로 하고 있다.

* 2005 : python

파이썬의 강력함은 이전부터 익히 들어 왔지만, 실제로 다뤄본 것은 4학년때 잠깐, 그리고 대학원에 들어가고 나서의 일이었다. 대학원에서는 주로 numpy와 scipy를 통해 수치해석을 많이 했고, 요즘 들어서는 twisted로 네트워크를 많이 다루고 있다.

워낙 대세가 되어 개발자라면 써보지 않은 사람이 없을 것이다. 나 역시 혼자 작업할 때는 루비를 선호하지만 국내 개발자 가운데서도 루비 쓰는 사람은 별로 없어도 파이썬 안써본 사람은 거의 없기 때문에 누군가와 함께 작업할 때는 대부분 파이썬을 쓰게 된다.

* 2006 : matlab

대학원에서 처음 접하게 된 언어. 수치해석과 그래프 그리기의 최강자. 그러나 과제 때 몇번 써보고 이후에 비슷한 과제가 있을 때는 그냥 numpy로 대체해 버렸다.

* 2007 : ruby

실용적인 프로그래밍의 진정한 의미를 가르쳐준 언어이자, 프로그래밍 언어의 문법이 심플하지 않아도 아름다울 수 있다는 것을 가르쳐준 언어. 루비의 특징은 이 블로그에서 몇번 소개하였으므로 루비 태그를 참조하시면 되겠다.

루비는 언어 자체도 독특하지만 커뮤니티 역시 참 독특하다.

* 테스트 주도 개발을 거의 맹신이라고 할만큼 철저히 지킨다. 테스트 주도 개발은 java 진영에서 먼저 보편화되었지만, 요즘은 루비의 훌륭한 테스트 도구들이 java/python 진영으로 역수출되는 추세다.

* Mac 사용자의 비중이 다른 커뮤니티에 비해 높다. 사용자 친화를 중시하는 애플 진영의 특성과 프로그래머 친화를 중시하는 루비의 특성이 잘 맞기 때문인 것 같다. 덕분에 루비의 Mac OS 지원도 상당히 훌륭하다.

* 웹 개발자가 많다. 이것은 물론 Ruby on Rails 라는 걸출한 프레임워크 덕분인데, 이 때문에 다른 분야 라이브러리들의 발전은 느린 편이다. 루비 커뮤니티에서 가장 아쉬운 점이다.

* 2008 : haskell

프로그래밍 언어의 진화의 한 정점에 서 있는 언어. 세상에서 가장 정교한 프로그래밍 언어를 꼽으라면 나는 주저없이 haskell을 꼽을 것이다.

side-effect를 허용하지 않는 순수 함수형 언어로, side-effect 없이 I/O를 구현하기 위해 monad라는 독특한 개념을 이용한다. 순수 함수형 언어라는 점을 제외하면 nML과 유사한 문법을 갖고 있어서 쉽게 입문할 수 있었는데, 배우면 배울수록 새로운 개념이 끊임없이 등장하는, 굉장히 깊은 언어이다. 게다가 학자들이 좋아하는 (...) 언어다 보니 새로운 프로그래밍 패러다임의 주된 실험장이기도 하다.

실용적인 측면에서 haskell의 가장 큰 특징은 persistent data일 것이다. nML이나 LISP 등 대부분의 값 중심 (함수형 언어의 다른 별명) 언어들의 특징이기도 한데, 한번 계산된 값은 절대 변경되지 않는다는 것이다. 예를 들어 list에 새로운 값을 추가하거나, hashmap에 새로운 key/value를 추가해도 원래 값은 변하지 않고 그로부터 계산된 새로운 값이 반환된다. 또한 같은 함수에 같은 값을 넣으면 항상 같은 동작을 한다는 것이 100% 보장되기 때문에 일단 컴파일된 코드는 높은 확률로 의도대로 동작한다는 것을 보장하는 훌륭한 특성을 갖고 있다.

다만 함수형 언어의 생소함 외에도 monad라는 수학적인 개념을 광범위하게 다루고 있기 때문에 배우기 어려운 언어인 것은 사실이다. haskell을 공부하고 싶은 사람에게는 공식 홈페이지 www.haskell.org 와, haskell의 실용적인 측면을 많이 다루고 있는 Real World Haskell을 추천한다.

* 2010 : actionscript

flash 개발을 위한 언어. javascript 방언이다. 회사에서 쓸 데가 있어 배우긴 했는데 언어적으로 참 지저분하다 -_- flash까지 덩달아 싫어지게 만드는 마술같은 언어.

* 2010 : lua

와우 애드온 고칠때 조금 끄적여본 수준. 재미있어 보이긴 하는데 많이 들여다보지는 않았음.

이렇게 써놓고 보니 대학교에 입학한 이후로는 나도 모르는 사이에 매년 새 언어 배우기 원칙을 실행하고 있었다... 2009년에는 딱히 새 언어를 배우지 않았다는 것이 갑자기 아쉬워진다.

* 그 외에 요즘 기대하고 있는 언어들

clojure : 요즘 루비 커뮤니티에서 주목받고 있는 LISP 방언이다. LISP가 등장한지 50년이 넘었지만 여전히 코드를 그 자체로 데이터로 다루는 LISP만의 특징은 다른 언어들은 흉내만 낼 뿐 완전히 구현하지 못하고 있다. clojure는 현대 언어들의 기능 (dynamic inheritance, hashmap, STM 등등) 으로 재무장한 LISP라고 할 수 있는데, 자바 가상 머신 위에서 동작하기 때문에 자바의 수많은 라이브러리를 바로 갖다 쓸 수 있다는 장점이 있다. 다만 등장한지 얼마 되지 않아서 API가 확립되지 않은 것이 단점이라 하겠다.

go : 작년에 구글에서 공개한 언어. 디자이너 가운데 무려 켄 톰슨^[각주:1]과 롭 파이크^[각주:2]가 포함되어 있다. 역시 구글이랄까 I/O 함수와 강력한 병렬처리에 집중하는 점이 돋보인다. 이번 프로젝트 끝나면 회사에서 한번 스터디해볼 계획이다.

B 언어(C 언어의 전신), Unix, UTF-8을 개발한 업계의 전설 [본문으로]
역시 Unix의 개발자. 또하나의 전설 [본문으로]

구들장(온돌)의 역사

kanie — Mon, 12 Jul 2010 14:39:09 +0900

온돌은 한국에서 발명되어 세계적으로 사용되는 몇 안되는 기술 가운데 하나다. 전문 건축용어로는 복사난방이라고 한다. 바닥을 따뜻하게 데워서 방안 전체의 공기를 데우는 이 기술은, 개념적으로 그렇게 어렵지 않음에도 불구하고, 서양에는 비교적 현대에 와서야 도입되었다. 한국에서는 고구려 때 발명된 것으로 추정되며, 2천여년 간 "구들"이라는 이름으로 불리다가 19세기부터 "온돌"이라는 이름으로 불리게 되었다고 한다. 만주를 비롯한 중국 북부 지역에도 이와 비슷한 난방장치인 "캉"이라는 것이 있는데, 이곳 사람들은 방 전체를 데우는 것이 아니라 침대만을 데우는 장치를 더 좋아했다고 한다.

난로로 데워진 방과 아파트나 주택에 설치된 온돌방을 비교해보면 온돌방의 위력을 금방 알 수 있다. 얼굴만, 혹은 등만 뜨겁고 나머지는 차가워지는 난로방과 달리 온돌방은 바닥으로부터 시작하여 방안 전체 공기가 훈훈해지므로 몹시 편안하다. 온돌방이 더 우수하다는 것은 의학적으로도 근거가 있는데, 머리는 차고 팔다리는 따뜻한 것이 가장 이상적인 체온 분포이기 때문이다.

서양에서는 건축문화가 발달했던 로마 시대에 온돌과 유사한 형태의 바닥 난방 시스템이 발명되어 목욕탕을 비롯한 공공장소^[각주:1]에 건축되었으나, 중세 시대에 로마의 공공 건축 문화가 교회와 수도원을 제외하고는 거의 완전히 사라지면서 함께 사라졌다고 한다. ^[각주:2] 로마 시민들은 목욕탕의 따뜻한 바닥에 발을 데지 않기 위해서 샌들을 신고 목욕탕에 들어갔다고 한다.

전통적인 온돌 난방과 현대의 온돌 난방은 조금 형태가 다른데, 가장 큰 차이는 전통적인 온돌은 부엌의 아궁이불로 데워진 공기가 안방 바닥에 깔린 돌들을 데워 그것으로 바닥을 데우는 방식인 반면에, 현대의 온돌 난방은 최근 아파트들에서 볼 수 있는 것처럼 바닥에 파이프를 깔고 파이프로 따뜻한 물을 흘려 그것으로 바닥을 데우는 것이다. 공기 대신 물을 사용하는 데는 두 가지 큰 장점이 있는데, 하나는 물이 비열이 높아 온기를 저장하기에 훨씬 효율적인 수단이라는 것이고, 또 하나는 연료를 태우면서 나오는 연기나 유독가스에 중독될 염려가 없다는 것이다. 전기장판처럼 온수파이프 대신 전기를 통해 바닥을 데우는 방식도 있는데, 물을 직접 데우는 방식에 비해 열->전기->열로 변환하는 과정은 상대적으로 열효율이 낮아 많이 쓰지 않는다.

온돌이라는 난방기술이 서양에 다시 소개된 것은 20세기 초라고 한다. 미국의 전설적인 건축가 프랭크 로이드 라이트가 동경 제국 호텔의 설계를 의뢰받아 일본에 오게 되었는데, 여기서 머물렀던 일본인의 집에 조선식 온돌방이 설치되어 있었다고 한다.^[각주:3] 그는 "바닥으로부터 따뜻해지는 설명할 수 없는 편안함"을 경험하고 후에 그의 건물에 적용하게 된다. 여기서 기존의 온돌 방식 대신 바닥에 온수를 흘리는 방식을 발명했다는 점이 그의 천재성을 드러내는 부분이라고 생각한다.^[각주:4] 이 기술은 1970년대 무렵부터 다시 한국의 아파트에 수입되어 큰 인기를 끌었다.

바닥 난방 기술은 세계적으로 많이 보급되어 있지만, 온돌방을 주택에 설치하는 것은 주로 아시아 국가들이고, 서양 사람들은 여전히 벽난로를 선호해서 그런지 주택에는 그다지 설치하지 않는다고 한다. 다만 난방 효율이 좋아서 공공건축물이나 상업용 건물에는 종종 설치한다고 하는데, 현대적인 공공건물에는 주로 직접 따뜻한 공기를 주입하는 난방을 많이 하는 한국인들로서는 약간 상상하기 어려운 일이다.

반대로 여름에는 바닥 대신 천장을 차갑게 하는 천장 냉방 기술도 존재한다. 공기를 직접 뜨겁게 하는 벽난로 대신 바닥을 따뜻하게 데우는 온돌처럼, 공기를 차게 식히는 에어콘 대신 천장을 차갑게 식혀서 시원해진 공기를 바닥으로 가라앉히는 방법이라고 생각하면 된다. 다만 이 방법은 천장이 너무 차가워지면 천장에 이슬이 맺히는 단점이 있어서 많이 사용되지 않는데, 최근에는 천장의 이슬을 제거하는 기술이 발명돼서 유럽에서 일부 사용하고 있다고 한다. 에어콘 바람을 직접 맞으면 금방 몸이 아파지는 나같은 사람에게는 실로 반가운 소식이다. 어서 한국 건축에도 도입되었으면 하는 바이다

로마에서는 목욕탕이 남자들끼리의 공적인 사교의 무대였으므로 공공장소로 취급되었다. [본문으로]
로마의 바닥 난방 기술은 이슬람을 통해 살아남아 15세기까지 이슬람 점령지역이었던 스페인에 일부 남아있다. [본문으로]
일본인들은 온돌방이라는 것이 있다는 걸 알고는 있었지만 그다지 좋아하지는 않았기 때문에, 라이트가 일본에서 온돌방을 만나게 된 것은 순전한 우연이다. [본문으로]
온수를 흘려 난방하는 기구인 "라디에이터"는 이보다 조금 일찍 19세기 말에 발명되었지만, 이것을 바닥 밑에 설치해서 방 전체를 데운 것은 라이트가 처음이다. [본문으로]

카테고리 이론 동영상 강좌

kanie — Wed, 09 Jun 2010 10:59:39 +0900

http://www.youtube.com/user/TheCatsters

평균 5분~10분 사이 동영상이 77개니까 약 9시간, 대학 강의로 치면 반개 학기 분량의 강의다. 관심이 있긴 하지만 이거 끝까지 들을 수 있나 ㄷㄷㄷ

Orson Scott Card - Speaker for the Dead 중에서

kanie — Mon, 07 Jun 2010 11:15:01 +0900

위대한 랍비가 시장에 나와 가르침을 펴고 있다. 그때 한 무리의 군중이 어떤 부인이 남편을 두고 부정을 저질렀다는 증거를 찾아, 그녀를 돌로 쳐죽이기 위해 시장으로 끌고 나온다. (이 이야기는 이미 유명하지만, 사자의 대변인^[각주:1]인 나의 친구가 같은 상황에 처한 다른 두 명의 랍비에 대해 들려 주었다. 여기서는 다른 두 버전을 이야기할 것이다.)

랍비는 앞으로 걸어나와 여인 옆에 섰다. 사람들은 랍비를 존경했으므로 손에 돌을 든 채로 삼가며 기다렸다. 랍비가 군중에게 말했다. "이 가운데서 다른 남자의 부인이나 다른 여자의 남편을 탐낸 적이 없는 사람이 있소?"

그들은 어물거리며 말한다. "랍비님, 우리도 탐욕에 대해 모르는 바 아니지만, 실제로 행한 적은 없습니다."

그러자 랍비가 말한다. "그렇다면 무릎을 꿇고 신께서 그대를 강하게 창조했음을 감사하시오." 그는 여인의 손을 끌고 시장 밖으로 나온다. 그는 여인을 보내기 전에 그녀에게 속삭인다. "시장님에게 가서 내가 그의 연인을 구했다고 말해주시오. 그분이 나의 충성을 알아주실 것이오."

그리하여, 무질서로부터 스스로를 보호하지 않는 타락한 공동체 덕분에 여인은 목숨을 구했다.

다른 도시의 다른 랍비는 다른 이야기에서 그랬던 것처럼 그녀에게 다가가 군중을 멈춰세웠다. 그리고 말했다. "그대들 중에 죄 없는 자가 누구요? 그 사람이 먼저 돌로 치시오."

그들은 부끄러움을 느끼고, 각자의 죄에 대해 기억해내어 그들 자신의 원래 목적을 잊게 되었다. 그들은 생각했다. 어느날 내가 이 여자처럼 될지도 모르지. 그때 누군가 용서해주고 한번 더 기회를 주면 좋겠다. 내가 받고 싶은 만큼 그녀에게도 주어야지.

그들이 손에 든 돌을 땅에 떨어뜨렸을 때, 랍비가 땅에 떨어진 돌을 주워 여인의 머리 위로 높이 쳐들고, 온힘을 다해 내리쳤다. 그녀의 두개골이 부서지고 뇌가 포석에 흩어졌다.

"나 역시 죄가 없지 않지만, 오직 완벽한 사람만 법을 집행할 수 있게 허락한다면, 우리의 법은 죽을 것이고 우리의 도시 또한 죽을 것이오."

그리하여, 여인의 일탈을 용서할 수 없는 경직된 공동체 때문에 그녀는 목숨을 잃었다.

이 이야기의 유명한 버전은 우리의 경험상 놀라울 정도로 희귀한 사례이기 때문에 주목할만 하다. 대부분의 공동체는 부패와 사후강직 사이를 요동치다가, 너무 크게 탈선하게 되면 죽음을 맞는다. 오직 한명의 랍비만이 법을 지키면서 동시에 일탈을 용서할 수 있는 완벽한 균형을 우리에게 기대하였다. 그리하여, 당연하게도, 우리는 그를 죽였다.

Orson Scott Card - Speaker for the Dead 중에서

(역주) 사자의 대변인: 오슨 스콧 카드의 소설 제목이자, 주인공 엔더 위긴의 직업이기도 하다 [본문으로]