sata_sil + Seagate SATA HD problem

꽤 오래 전에 했던 삽질인데, 앞으로의 미디어 정리 프로젝트 진행을 위해, 정리해 둠.

Problem

현재 www.lastmind.net이 동작하고 있는 machine인 athlon64 machine에 SATA HDD를 꽂고, 데이터를 복사하기 시작하니까 kernel이 hang 되기 시작했다.

문제 재발생/확인은 여러가지 loop 테스트 (CPU/memory/disk)로 했고, /var/log/messages에서 disk I/O 오류를 확인하고, linux kernel의 sysrq debugging을 켜서 disk I/O 관련 루틴에서 hang 되는 것을 확인하였다.

더불어 검색을 통해, 다음과 같은 호환성 문제를 확인하였다.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0404.3/1364.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0406.3/0666.html

즉, 내 nForce2 보드에 들어있는 Silicon Image SATA controller와 sata_sil driver, Seagate 160GB SATA Hard Disk 사이의 문제…

Solution?

kernel 버전을 2.6.8-rc1까지 올려보았으나, 해결되지 않았다. 현재는 Hard Disk를 떼서 Windows machine에 물려놓고, samba로 연결해서 사용중이다. 앞으로 athlon64 machine에 Hard Disk를 추가할 때는 Seagate SATA를 선택하지 않는 것이 간단한 해결책이겠지만, 그래도 Seagate가 성능/소음 면에서 가장 만족스럽기 때문에, 가능하다면 Seagate를 고르고 싶다. (현재 stable이 2.6.9이니 테스트해볼까… 하지만, ChangeLog에 sata_sil 관련 fix는 보이지 않는다.)

사실 전에도 linux와 하드웨어 간의 호환성을 고려하지 않고 하드웨어를 선택해서 곤욕을 치른 적이 있었는데, 비슷한 것을 이번에도 또 반복했다. (요즘에 워낙 지원이 잘 되다보니 … 고려하지 않은 면도 있다.) SATA controller들은 비교적 최근에 추가된 하드웨어이다보니 리눅스에서 잘 지원되지 않거나 문제가 발생하는 경우가 많으니, 리눅스 machine을 고려중이라면, SATA 쪽은 재고해보거나, 호환성 문제를 잘 확인하고 선택하는 것이 바람직하리라고 본다.

다음은 문제 해결(?)에 많은 도움이 되었던 tj형과의 대화 발췌.

tj. doom III this summer, prep for upgrades 님의 말:
우선 콘솔 모드로 부팅해보고
tj. doom III this summer, prep for upgrades 님의 말:
커널 뷜드할 때 debug에 가면 sysrq어쩌고 있거든
tj. doom III this summer, prep for upgrades 님의 말:
그거 켜고 멈췄을 때 ctrl-alt-break-? 치면 도움말 나오고 어디서 멈춰있는 지 알 수 있거든
[세라비/회사] WTL on sf.net! 님의 말:

tj. doom III this summer, prep for upgrades 님의 말:
NMI watchdog도 켜고
[세라비/회사] WTL on sf.net! 님의 말:

tj. doom III this summer, prep for upgrades 님의 말:
커널 문제면 보통 그런걸로 찾을 수 있고 아니면 뭔가 하드웨어상의 문제일 듯..
[세라비/회사] WTL on sf.net! 님의 말:
넹 T_T
[세라비/회사] WTL on sf.net! 님의 말:
SATA 달았는데 그것때문인가 ㅎ
tj. doom III this summer, prep for upgrades 님의 말:
우선은 빌드할 때 안 쓰는 옵션은 다 끄고 빌드해
tj. doom III this summer, prep for upgrades 님의 말:
드라이버들
tj. doom III this summer, prep for upgrades 님의 말:
별로 상관은 없겠지만 하여간 커널 버그면 저런걸로 대충 나와
tj. doom III this summer, prep for upgrades 님의 말:
시퓨 온도도 측정해보고 무한 룹 돌리는 거 한참 해보고 그러다보면 알겠지 뭐
[세라비/회사] WTL on sf.net! 님의 말:
아 안그래도 무한룹 해보는 중
[세라비/회사] WTL on sf.net! 님의 말:
음 INT32_MAX에 도달하는데도 꽤 걸리네요 한 1-2초?
tj. doom III this summer, prep for upgrades 님의 말:
아 INT32_MAX면 2G인걸 -_-;
[세라비/회사] WTL on sf.net! 님의 말:
아 10초 정도군
tj. doom III this summer, prep for upgrades 님의 말:
그리고 룹안에 뭔가 좀 길게 넣어놔
tj. doom III this summer, prep for upgrades 님의 말:
그냥 계속 점프만 하는 건
[세라비/회사] WTL on sf.net! 님의 말:

tj. doom III this summer, prep for upgrades 님의 말:
시퓨가 별로 하는 일이 없어서 열이 많이 안날거야
tj. doom III this summer, prep for upgrades 님의 말:
int/float이런거 섞어서 길게.. 서로 디펜던시 없게 가득 차서 돌게

sata_sil + Seagate SATA HD problem 더 읽기"

Indigo: The Five Minute Challenge

Don Box의 Indigo가 무엇인지/왜 Indigo를 만들었는지에 대해 ‘5분 안에 설명하기’. 영문를 읽기 싫어하는 사람들을 위해 대충 번역을 해주겠다.

The Five Minute Challenge

Indigo는 structureal contracts (schemas) 또는 behavioral contracts (message exchange pattern) 를 사용하여 software를 연결한다.

CLR과 COM을 연동하고, local type을 data contracts나 service contracts로 추출해준다. Indigo의 특히 멋진 기능은 sender와 receiver가 같은 CLR type을 공유할 필요가 없다는 것이다. (Indigo와 CLR 혹은 COM 사이에서도..)

Indigo에서 사용하는 message는 SOAP processing/data model이 기반하고 있지만, 필요하지 않다면, angle bracket을 사용하지 않을 수 있다.

여러 message transport를 지원하고 transport-level/SOAP-level 모두에서 보안과 신뢰성(reliability)을 지원한다.

System.Transactions와 queueing system과도 tight하게 연동한다.

Indigo가 local type에 독립적으로 동작한다는 점은 매우 마음에 든다. 왜냐하면, Indigo와 같은 integration solution에서 가장 큰 문제 중 하나가, platform (예를 들면, programming language) 별로 local type을 어떤 common type으로 static하게 binding 해야한다는 점이 solution을 매우 구리게 만드는 점 중의 하나였기 때문이다. php와 C++ 간의 data mapping을 예로 들면, php 상의 array는 (요즘 대부분의 dynamic language에서 그런 것처럼) 실제로 hash이다. 하지만, C++의 array는 hash가 아닐 뿐더러, size 정보조차 없다. 물론 standard library (container)를 사용할 수 있다. 하지만, std::vector를 선택할 것인가? 아니면 hash container를 추가할 것인가? 논의가 이렇게 되면 C++ 개발자는 raw array를 돌려달라고 외친다. Microsoft의 경우 local type의 문제는 CLR에서 어느 정도 해결했겠지만, non-CLR platform에서는 다시 이 문제가 불거지게 마련이므로, Indigo에서 이러한 점을 해결(?)한 것은 매우 훌륭하다고 생각한다. 아마도 구현상으로는 XML messaging이 이러한 점을 해결해주는 것이 아닐까 하는데, contract 상에 정의된 데이터 모델과 local type 사이의 변환이 매우 자유로운 스타일 정도가 아닐까 생각된다. 자세한 것은 좀 더 살펴봐야할 듯 하다.

Message 자체와 Message Transport의 분리, 그리고 거기에 Aspect의 형태로 여러가지 서비스(Transaction, Security, …)를 붙일 수 있는 점은 매우 훌륭한 architecture인 것 같다. 물론 CORBA도 이러한 architecture이고, EIP 같은 책에서도 이러한 architecture를 언급하고 있으므로 절대 처음은 아니다.

SOAP/XML은 Service간의 integration을 위한 Web Services에서는 표준 프로토콜이 되었지만, 하나의 Service 내에서의 component/module 간의 integration에 과연 XML을 사용하는 것이 맞는 solution일까 하는 의문이 든다. 성능 때문에 XMLRPC도 버리는 마당에 말이다. (이것이 미신은 아니라고 생각한다.) angle bracket 없이 SOAP data를 전송한다는 것도 흥미로운 점인데, 일종의 binary protocol인지 아니면 단순히 약간의 성능을 위한 tweak인지가 궁금하다.

Why Indigo? : The Five Minute Challenge

대부분의 소프트웨어 개발은 이미 만들어진 코드와 이미 저장된 정보를 서로 붙이는 (gluing together) 것이다. 순수하게 처음부터 개발을 시작하는 (pure green fields development) 사치를 가진 사람은 거의 없다.

Microsoft나 업계 전체의 현상태는 integration (CORBA, DCOM, EDI)와 access (JNDI, JDBC, JMX)를 위한 여러 solution들을 만들어내고, 개발자들이 알아서 해결하는 것이다. Indigo에서는 XML messaging을 사용하여 interact하는 service에 기반한 새로운 범용 platform을 만들 수 있다.

중심 metaphor로 messaging을 선택한 것은, pipe의 end(역주: messaging을 주고 받는 peer/endpoint)에 사용되는 기술이 아닌, 교환되는 데이터의 통합(integration)에 집중을 하게 해준다. 이것은 great discipline으로 증명되었고, Indigo의 시작으로부터 수백명의 사람을 가진 팀(역주: Indigo 팀)이 집중을 할 수(초점을 가질 수) 있게 해주었다.

XML을 선택한 것은 진입점(bar of entry)을 가능한 한 낮게 해주었다. 돌아보면, XML stack은 상당히 복잡해졌고, (XSD, XML DSIG, XML Encryption, XQuery) 나는 XML 대신 Lisp S-Expressions에 기반한 architecture를 원했었다. 하지만 우리는 XML을 선택했다.

“service”란 용어를 선택한 것은 사실 어느 정도 임의적이다. 업계는 XML message를 사용하는 code에 대해 용어를 필요로 했고, “service”는 그 첫번째 용어였다. “SOA”의 인기(glow)가 사그라들기 시작하면, 우린 다른 이름을 사용하게 되리라고 확신한다. (예를 들면, “business agents”?)

재미있는 의문은 도대체 왜 Microsoft가 이것을 하느냐이다. 그것은 쉽다. 우리는 새로운 platform을 만들기 위한 local execution의 토대를 필요로 했고, CLR을 만들었다. CLR-based platform은 distributed/heterogeneous integration/access를 위한 토대를 필요로 하고 있고, 따라서 Indigo를 만들고 있는 것이다.

“Message”라는 metaphor를 왜 썼느냐보다, ‘metaphor’를 적극적으로 활용하고 있는 것이 인상적이었다. 우리 회사의 경우, 개개의 ‘requirement’가 개발의 주축을 이루기 때문에, 결과물인 product는 공유된 ‘metaphor’를 가지지 못하는 문제가 있는 것 같다. 진짜 문제는 ‘metaphor’가 없는 것이 아니라, 이로 인해, 해당 product의 정체를 아무도 모른다는 것이고, 또한 앞으로 어떤 방향으로 나가야할 지를 모른다는 것이다.

Indigo가 완성되면, CLR과 함께 엄청난 시너지를 발생시킬 것 같다. 어떻게 보면 ‘reinventing wheel’처럼 보이지만, ‘wheel’은 승합 마차에 쓰이느냐, 전차에 쓰이느냐에 따라 새로 발명할 필요도 있는 것이다.

Indigo: The Five Minute Challenge 더 읽기"

Dave's True Story – I'll Never Read Trollope Again

Dave’s True Story는 guitarist이자 songwriter인 Dave Cantor가 waitress이자 singer인 Kelly Flint를 만나서 자신의 노래를 가르쳐주면서 만들어진 밴드라고 합니다. Davit Cantor의 곡과 가사도 좋지만, 무엇보다 매력적인 것은 Kelly Flint의 목소리 같습니다.

약간 우울하군요. 저녁을 안먹어서 그런지, Kelly Flint의 목소리 때문인지… 그나마 약간은 즐거운 곡을 선곡합니다.

일찍 퇴근해서 저녁 내내 음악만 들어버렸습니다. 그러고보니 생각이 났는데, 여러분들은 저에게 제가 시간을 사용하는 방법에 대해서 이러쿵 저러쿵 가치판단을 강요할 권리가 전혀 없습니다. 기껏해야 충고 정도지요. 충고라고 하더라도 그 선의는 고맙게 받겠지만, 충고는 마음속으로만 하시기를 바랍니다. 제가 항상 말하듯이, “제 인생에 너무 많은 간섭은 말아줘요”.

http://www.davestruestory.com/

Dave's True Story – I'll Never Read Trollope Again 더 읽기"

한국 문화의 집

점심식사를 하고 날씨가 좋아서, 자판기 커피 놀이를 하러 회사 건물(COEX 아셈타워) 밖으로 나갔다가, 국악 공연을 하는 것을 발견하고 구경하게 되었다. 해금, 대금/소금, 태평소/피리(아마도?)와 키보드의 연주였다. 가을 날씨에 야외 공연만한 즐거움은 흔치 않을 것 같다. 귀에 익숙한 곡들을 적당히 양악과 조합한 연주를 들으면서, 곡이 끝날 때마다 인사에 박수로 다함께 화답하며 즐길 수 있었다.

끝날 때 즈음, 안내지를 나누어주었는데, 삼성역 근처에 있는 ‘한국 문화의 집’이란 곳이었다. 무료 공연도 많이 하고 있는 것 같으니, 언제 짬을 내어 부담없이 방문해봐도 괜찮을 것 같다.

‘한국 문화의 집’ 홈페이지: http://www.kous.or.kr/

한국 문화의 집 더 읽기"

OOPSLA '2004

OOPSLA는 10월 24일부터 시작하는 Object technology에 관한 ACM conference이다. 본인도 참석하려 하였으나, 제출한 paper가 accept되지 않는 바람에, 기분이 나빠서 안가기로 했다..는 것은 농담. 아직도 병역의 의무를 다하지 못한 본인은, keyword라도 살펴볼 생각에, 프로그램이나 살펴보기로 하였다.

개인적으로 눈에 띄는 topic을 다룬 것들을 몇몇 뽑아보았다. Google에서 찾을 수 있는 것들은 link도 걸어놓았으니, 참고.

Tutorials

  • Model-Driven Software Development: Introduction & Best Practices
    Markus Voelter, Indepdendent Consultant
    Jorn Bettin, SoftMetaWare
  • Scrum and Agile Project Management
    Angelika Langer, Independant Trainer/Mentor/Consultant
  • Generative Software Development http://www.swen.uwaterloo.ca/~kczarnec/gsdoverview.pdf
    Krzysztof Czarnecki, University of Waterloo
    Jack Greenfield, Microsoft Corporation
  • Feature Oriented Programming and Product-Lines http://portal.acm.org/citation.cfm?id=776935 (ACM Portal로의 link이니 필요한 사람은 개인적으로 contact 바람.)
    Don Batory, University of Texas at Austin
  • Testing Component-Based Software
    John McGregor, Clemson University

Practitioner Reports

  • Synchronization-Free Concurrency: Comparing the RTSJ to C++
    Daniel Dvorak & William Reinholtz, Jet Propulsion Laboratory, California Institute of Technology

Technical Papers

Workshops

  • Patterns for Retrospectives http://www.cs.unca.edu/~manns/retropatterns.html
    Linda Rising, Independent Consultant
    Mary Lynn Manns, University of North Carolina at Asheville
  • Early Aspects 2004: Aspect-Oriented Requirements Engineering and Architecture Design http://www.early-aspects.net/events/oopsla04ws
    Ana Moreira, Universidade Nova de Lisboa
    Awais Rashid, University of Lancaster
    Elisa Baniassad, Trinity College
    Bedir Tekinerdogan, University of Twente
    Paul Clements, Carnegie Mellon University
    Joao Araujo, Universidade Nova de Lisboa
  • Component And Middleware Performance http://nenya.ms.mff.cuni.cz/projects/corba/oopsla-workshop
    Petr Tuma, Charles University, Czech Republic
    Paul Brebner, University College London, United Kingdom
    Emmanuel Cecchet, INRIA Rhone-Alpes, France
  • Objects in Large Distributed Applications III (OLDA-III) http://www.dcs.gla.ac.uk/~pd/OLDA3/
    Peter Dickman, University of Glasgow
    Karen Renaud, University of Glasgow
    Huw Evans, Kelvin Institute

OOPSLA '2004 더 읽기"

Double-Checked Locking

Double-Checked Locking은 C++/Java 세계에서는 Singleton 또는 Lazy Initialization을 구현하는데에 잘 알려진 idiom이다. DCL은 Singleton object를 생성하는 부분에 필요한 synchronization cost를 절약하기 위한 방법이다. (자세한 내용은 다음 paper를 참고. “Double-Checked Locking” http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf)

하지만, DCL은 compiler optimization 문제와 Multiprocessor에서의 cache coherence 문제 때문에 portable하게(Memory barrier를 사용하지 않고) 동작하는 것이 불가능한 것이라고 한다. (자세한 내용은 Scott Meyer가 정리한 다음 note를 참고. “Double-Checked Locking, Threads, Compiler Optimizations, and More” http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf)

이러한 문제는 C++이 memory model(e.g. memory read/write ordering)을 명시하기 않기 때문이라고 볼 수도 있고, Java에서는 Memory Model의 개선을 통해 이 문제를 해결하려는 것 같다. (http://www.cs.umd.edu/~pugh/java/memoryModel/)

관련 링크들

Double-Checked Locking 더 읽기"

rpm vs dpkg

흔히 rpm이 dpkg에 비해 나쁘다는 얘기가 있다. 자주 들리는 얘기임에도 불구하고, 확실한 근거가 따라다니지 않으며, rpm과 dpkg를 동시에 ‘잘’ 써본 사람이 드물다는 점 때문에, ‘미신’이 아닌가하는 의심이 크게 들었다.

일단 나의 경험을 얘기해보자면, 학교 다니던 시절에만 redhat을 쓰고 이후에는 FreeBSD, 지금 회사에선 debian을 쓰고 있기 때문에, 동시에 사용하면서 비교해본 적은 없다고 할 수 있을 것 같다. 개인적으로 rpm을 사용할 때 가장 불편했던 점은 dependency에 해당하는 package들을 모두 따로 www.redhat.com이나 www.rpmfind.net에서 받아서 써야한다는 것, 그리고 cyclic dependency가 있으면 update하기가 불편해지는 점 (내가 기억하고 쓰는 rpm command line option은 ‘rpm -qa’와 ‘rpm -Uvh’ 밖에 없기 때문일지도) 이었다. 하지만, 데비안에서도 이러한 문제를 pakaging system인 dpkg가 해결하는 것이 아니라, apt가 해결하는 것이란 것은 rpm와 dpkg의 비교에서 항상 사람들이 혼동하는 사실중의 하나다. redhat에서 제공하는 상용 패키지 관리툴인 up2date가 apt에 equivalent한 product라고 볼 수 있는데, RHN에 등록해야하고 또 무료로는 불편한 점(업데이트 주기에 제한)이 있어서 사용을 그만두었었다. 하지만, 현재는 “ Yes, but it no longer uses the Red Hat Network (RHN). (It still downloads from the Red Hat servers, you just can’t use the features of the Red Hat Network.”라고 한다. (from http://www.fedorafaq.org/#up2date)

이러한 package management tool에는 up2date, yum, apt가 있다. apt야 debian에서는 검증된 시스템이지만 rpm 쪽에서는 porting 중이고 아직 신뢰할 만한 수준은 아닌 것 같다. (?) up2date는 위에서 말한대로 RHN에 관련된 문제없이 사용가능하다. 결국, rpm에서도 package management tool로서 3가지의 option이 존재한다는 것인데, 한번 써봐야할 것 같다.

결국, 내가 직접 경험한 차이도 rpm과 dpkg 자체와는 관련없는 외적인(package management) 문제라는 것인데, 주변 사람의 얘기를 들어보아도 거의 비슷한 의견을 들려주었다.

다음은 googling을 통해 얻은 rpm과 dpkg의 비교에 관한 page들인데,

사실, 단순한 package의 사용자 측면에서는 느끼기 힘든 차이들(pros and cons)인 것 같다.

다음은 RPM의 문제를 지적하고 해결책을 제시하는 article인데, 역시 마찬가지.

결론은 사용자 (특히, 나)의 입장에서 rpm과 dpkg는 별로 차이가 없으며, rpm과 함께 사용할 수 있는 package management tool(up2date w/o RHN, yum, apt)을 한번 사용해보자는 것.

rpm vs dpkg 더 읽기"

나쁜 교육

영화를 보기도 전에 OST를 사게 했던, ‘그녀에게’의 감독인 페드로 알모도바르의 영화, 나쁜 교육을 보았다. 이른바 ‘공부’ 모드로 들어갔기 때문 영화보기에 소홀했던 터라, (최근에 딱히 볼 영화가 없었기도 하지만) 딱맞춰 재상영하는 ‘나쁜 교육’은 내겐 고마운 이벤트였다.

좋은 영화는 오프닝 씬만 봐도 알 수 있다. 오프닝 씬에서 나오는 음악만으로도 가슴이 떨려오는 건 왜일까. 어른이 된 이나시오와 엔리케의 재회를 시작으로, 이나시오가 영화 감독인 엔리케에게 배역을 부탁하며, 선물로 준 시나리오의 내용이, 신학교 시절의 이나시오와 엔리케, 마놀로 신부, 그리고 제4의 인물의 이야기가 진실과 허구가 뒤섞여 펼쳐진다. 이 매력적인 스토리텔링은 엔리케가 앙겔의 정체를 알아내고, 마놀로 신부가 찾아와 진실을 밝히면서 절정으로 치닫는다. 더구나 매력적인 씬과 매력적인 배우와 매력적인 음악과 완벽한 호흡을 이루면서.

욕망을 제대로 표현한 영화는 항상 욕망과 절제, 열정과 고통을 대비시킨다. 신부복을 입은 마놀로 신부와 나이가 들어 애까지 생긴 마놀로, “Moon River”를 부르는 소년 시절의 이나시오와 마약에 찌들어 죽어가는 이나시오, 엔리케와 이나시오의 다정한 모습과 더이상 노래를 부르지 않는 배역 문제 때문에 다투는 엔리케(앙겔)와 이나시오. 그 유사성으로 인해 자연스럽게 이나시오의 시나리오와 현실은 비교되고, 그 괴리는 더욱 가혹하다.

네 사람의 사랑과 복수, 파멸의 스토리 속에는 철저하게 순수한 인간의 욕망이 존재하고 있다. 신부복을 입은 마놀로 신부의 눈빛에서, 엔리케의 나체에서, 이나시오의 얼굴에 두근거리는 내 가슴에서 그것을 느낄 수 있었다. 감히 ‘사랑’이라는 단어-가치를 거기에 가져다 별명으로 준다면.. 난 너무 나쁠까?

unpop님의 블로그여름님이 단 comment에 의하면, 국내 배급사인 씨네휴의 공식 홈페이지에서 OST 예약 주문을 받고 있다고 한다. 둘러봐도 OST 구하기가 힘든 것 같아, 급한 김에 당.연.히. 주문을 해버렸다. 공식 홈페이지도 한번 둘러보길.. 음원을 퍼온 페이지들도…1, 2..

Jardinero torna a surriento

Moon river

나쁜 교육 더 읽기"

A와 B 이야기

간단한 이야기로 내가 사회를 바라보는 관점을 설명해보자. 이 글을 읽은 사람이라면, “A와 B 이야기”는 나와 대화할 때 항상 쓰이는 일종의 메타포가 되어, 대화와 이해에 들이는 시간과 노력을 절약할 수 있을 것이라고 본다. (몇몇은 이미 이 메타포를 나와의 대화중에 들었으리라고 본다.)

합리적인 구성원들로 이루어진, 규칙을 가진 사회 U를 가정해보자. 이 사회는 두 부류의 사람들로 이루어져있는데,  A는 규칙을 잘 지키는 사람, B는 규칙을 잘 안지키는 사람이라고 해보자.  이 때, B는 규칙을 안 지킴으로써 자신의 이익을 얻을 기회가 많다고 가정하자. (일반적인 모든 규칙이 아니라, 이러한 조건을 만족하는 규칙 a에 대해서 생각해보라.) 이러한 규칙이 존재하는 이유는 A로 이루어진 사회의 이익이, A와 B가 섞여있거나, B로만 이루어진 사회의 이익보다 크기 때문이다. (그렇지 않다면 이 규칙은 존재할 이유가 없다.)

사회가 A와 B를 구분할 방법이 없는 경우, 당연히 B는 항상 규칙을 어김으로써 항상 이익을 얻을 수 있다. 이 때, 이러한 방법을 발견해내지 못하는 사회는 다른 사회와의 경쟁에서 도태될 수 밖에 없다. 사회는 항상 A와 B를 구분해내고, 합당한 정도의 처벌을 B에게 가해야한다. 이 처벌의 정도는 항상 B가 규칙을 어김으로써 얻는 (확률)이익의 크기보다 커야할 것이다.

하지만, 개체의 입장에서는 상황에 따라 A와 B 사이에서 왔다갔다 하는 것이 가장 유리하다. 사회 U의 합리적인 구성원들은 항상 자신의 이익이 가장 크게 하려고 노력하기 때문이다.

개체 이익의 최대화는 진화론에서 빌려온 “개체가 추구하는” 가치(진화론이 추구하는 가치가 아니다)이다. 이러한 이야기로부터 추론할 수 있는 사실 중의 하나는 사회는 A와 B에 어떤 가치를 부여하려고 노력하지만, 개체의 입장에서는 ‘이익’만이 중요할 뿐, 규칙을 지키느냐 안지키느냐의 가치는 전혀 무의미하다는 것이다.

‘규칙’이라는 사회의 가치는 사회가 부여하는 모든 가치로 대체해도 그대로 ‘A와 B의 이야기’에 적용될 수 있다. 법률, 도덕, 관습은 ‘규칙’의 형태를 띄고 있지만, 종교나 과학 같은 것은 규칙으로 해석하기에 직관적이지 않지만, 역시 사회가 부여하는 가치의 일종이다.

이러한 사상은 전근대를 벗어나면서 계몽주의자들이 열심히 제창했던 얘기와 다를 바가 거의 (몇몇 사변적 장치만 제외하고는) 없다.  몇세기가 지났지만, 여전히 사람들은 이 단순한 ‘A와 B의 이야기’를 자신의 주변이야기로 생각하지 못한다. 이른바 포스트모더니즘의 시대에 전근대적 사람들이 득실대는 것이다.

<인간의 굴레에서 Of Human Bondage>의 주인공인 필립은 이러한 생각을 자신의 ‘행동원칙’으로 삼는다. 이는 인간 본성에서 비롯된 당연한 것이지 신기해하거나 의아해할 일이 아니다. 인류가 인간의 본성에서 벗어나기 시작한 것은 얼마되지 않았기 때문에 인간의 본성에 벗어나는 어떤 것을 강제하는 것은 매우 어렵다. 이러한 것을 이해하지 못하면서, 자신의 이익뿐만 아니라 자신의 가족, 팀, 회사의 이익을 취하기는 힘들 것이다. 합리적인 행동에 대해 “저 사람 왜 저래? 미친 거 아냐?” 같은 반응을 보면 짜증스럽다.

“당신에게 제일 중요한 가치는 무엇입니까?”라고 한다면, 나는 없다고 대답할 것이다. 인류는 어떤 가치도 발견하지 못했다. 이런 상황에서 과학적 방법론을 취한다면, 가치는 존재하지 않는 것이란 결론이 내려진다. 나의 가치관은 ‘가치’는 없다는 것이다. 즉, 모든 것에는 가치가 없다. 내가 살아있는 것은 ‘사실’일 뿐이지 목적을 가진 것이 아니다. 걸어다니는 기계일 뿐이기 때문에, ‘이익’을 취하는 기본 동작 방식-본능에 충실하려고 노력한다. 이를 위해서  ‘가상적’인 가치를 세워놓는 것은 매우 편리하다. 예를 들어, “부자가 되기” 라든가, “세계 평화에 기여” 같은 것 말이다. 실제로 내가 어떤 ‘가상적인’ 가치/목표를 세워놓았는지는 다음에 써보도록 하겠다.

당신의 가치는 무엇인가? 라는 질문에 한번씩 대답해보길 바란다. (난 포스트모던시대의 계몽주의자인가? ;) 그리고, 기회가 된다면 Edward O. Wilson의 <인간 본성에 대하여 On Human Nature>를 한번 읽어보기 바란다.

 

A와 B 이야기 더 읽기"