2008년 10월 1일

크로포드, "창발에 대한 부정적인 생각"

GPG 보내기 인쇄하기 / PDF로 저장하기 인쇄하기 / PDF로 저장하기인쇄하기 / PDF로 저장하기

크리스 크로포드 | 2000년대 초 | 원문보기[영어]

 

아마 독립적인 사고가 존재하지 않는다는 가장 강력한 증거는 지적 유행에 대한 민감함일 것이다. 그런 유행은 거의 팝 음악이 스타일을 바꾸는 것처럼 빨리 왔다 가버린다. 대부분 그 바탕에 깔린 개념이 옳긴 하지만, 너무 폭넓게 적용되어 과분한 신뢰를 받는다. 1950년대에는 정보 이론이 유행했었다. 클로드 섀넌의 뛰어난 연구에 바탕을 둔 정보 이론은 다양한 영역에 새로운 영감을 불어넣어주었다. 공교롭게도, 많은 사람들이 세계 전체를 하나의 거대한 정보 이론으로 변환하려고 했었다. 또 다른 표본으로는 카오스 이론이 있다. 카오스 이론의 바탕이 되는 수학적 논리는 견고하고 이론은 수학자들에게 새로운 세계를 열어주었다. 하지만 모두가 카오스 이론의 성공에 뛰어들었고, 곧 “쥬라기 공원”이라는 논문이 등장해 공룡은 사육할 수 없음을 증명했다.

최근의 유행 중 하나가 '창발'이다. 그 가장 엄격하고 학문적인 형태에서는 가치 있는 관념이지만, 대중적 인식에는 근본적인 잘못이 있다. 그 대중적 인식이란 다음과 같이 요약될 것이다.

“창발은 복잡계의 특성으로 시스템의 설계자가 예기치 못했던 작용의 출현을 가능케 한다.”

이 개념에 대한 내 이의는 “예기치 못한다”는 말에 있다. 시스템이 디자이너가 예기치 못한 작용을 보인다면, 나는 그걸 버그라고 한다. 창발이 아니다. 내 차가 운전 중에 우측으로 핸들을 돌렸는데 좌측으로 가는 창발을 보인다면 수리점에 몰고 가야 할 것이다.

자, 그럼 대중적 정의를 수정해보자.

“창발은 복잡계의 특성으로 시스템의 설계자가 예기치 못했던 바람직한 작용의 출현을 가능케 한다.”

더 낫다. 하지만 여전히 문제가 있다. 설계자가 처음에 예기하지 못 한 것이라면, 바람직한 것과 바람직하지 않은 것의 차이를 어떻게 알 수 있는가? 만약 이 훌륭한 새로운 작용이 설계자가 전혀 예상하지 못 한 것이라면, 그게 훌륭한 건지 재앙인지 알 도리가 있는가? 마이크로소프트 윈도가 여러 번 다운되었다. 그 중 몇 번이 고장이고, 몇 번이 당신의 박사 논문이라도 대신 써주는 훌륭한 결과를 내는가? 뭔가 잘못되는 길은 무지막지하게 많다. 제대로 되는 길은 정말로 적다. 어쩌다 윈도가 당신을 위해 박사논문을 써줬다는 소식을 들으면 빌 게이츠가 아주 기뻐할 것이다. 하지만 그 전에 수 백시간의 작업을 날려먹은 무수한 고장에 대해 책임을 져야 한다.

여기에 나의 정의가 있다.

“창발은 복잡계의 특성으로 시스템의 설계자가 설계자 자신의 이해력보다 높은 추상도에서 실행하는 코드를 쓰는 것이다.”

인정하자. 이것이 더 지적으로 정직한 창발의 정의 같지 않은가? 그 핵심은 추상화의 관념이다. 단일 표본에서 벗어나 추상화에 기반해 규칙을 다루는 순간부터 우리는 일을 그르칠 위험을 안게 된다. 왜냐면 우리가 만든 규칙이 전혀 예기치 못한 상황에 적용되기 때문이다.

여기 예가 있다. 1990년대에 레이스트랙 옆에 맥주 광고판을 넣은 아케이드 레이싱 게임이 있었다. 그 디자이너는 그저 게임의 몰입도를 높이고자 했던 것이지만, 다른 사람들은 맥주 회사가 청소년들에게 자기네 제품을 광고하려고 게임 제작사에게 돈을 주었다고 생각했다. 그래서 어느 진지한 정치인은 캘리포니아 주 입법부에 미성년에 팔리는 게임에 알코올 음료를 묘사할 수 없는 법안을 제출했다. 나는 그것 때문에 위원회 앞에서 증언을 해야 했다. 나는 그들에게 환경 문제에 대한 멋진 교육용 시뮬레이션인 “밸런스 오브 플래닛”을 보여주었다. 그리고 그 화면 가운데, 쓰레기 더미 속에 버려진 보드카 병 그림이 있었다. 내 멋진 교육용 시뮬레이션은 이 법으로 퇴출당했다! 이럴 수가! 위원회에서 나는 죽었다.

그것이 바로 추상화의 문제이다. 너무 많은 경우의 수를 다룬다. 그 모두를 예측하기란 어렵다. 그 중 어떤 경우는 항상 버그의 근원이 된다. “그런 상황이 일어날 거라고는 생각하지 못 했다”는 것은 손을 버그로 물들인 많은 프로그래머들이 하는 변명이다.

들어보라. 이건 중요하다. 추상을 정복하는 것은 좋은 소프트웨어 디자인의 심장이자 영혼이다. 정상에 있는 디자이너들은 개개의 경우가 아니라 추상의 조건에서 생각한다. 그들은 평범한 사람들이 보지 못 하는 것들을 예측할 수 있다. 그것이 그들을 위대한 디자이너로 만들어 주는 것이다.

추상적으로 생각하는 것은 종종 수학적이고 통계적인 조건으로 생각한다는 것을 의미한다. 예를 들어, 나는 ‘에라스매트론’1의 ‘스토리월드’를 단순히 직접 플레이해봐서 테스트하지 않는다. 그런 방법으론 턱없이 부족하다. 대신, 나는 ‘리허설’이라 부르는 루틴을 실행해 스토리월드를 조금씩 다른 조건에서 수백 번 실행하고 그 결과로 통계 그림을 만든다. 그 통계 그림을 조사해서 스토리월드를 평가한다. 숫자가 적힌 표에서 추상적인 수준의 드라마를 본다. 액터들이 얼마나 자주 폭력에 의존하는가, 대립과 권태의 전반적인 양은 어떤가, 서로 다른 액터의 구성에서 얼마나 많은 상호작용이 일어나는가. 이 숫자들은 전반적인 스토리월드의 모습을 분명하게 보여준다. 단순히 플레이해보는 것보다 낫다. 보통의 스토리텔링의 관점에서 생각하는 사람이라면 완전히 이상하다고 볼 수도 있겠다. 하지만 이것이 진짜 소프트웨어 디자인의 실체다.

그러니까, 추상화하자. 당신의 소프트웨어에서 아무 것도 창발하지 않을 것이다.

주석

1. 애라스매트론(Erasmatron)은 크리스 크로포드가 개발중인 인터랙티브 스토리텔링 저작 소프트웨어 ‘스토리트론’(Storytron)의 예전 이름이다. 스토리월드란 스토리트론을 통해 만들어진 인터랙티브 스토리텔링 작품으로, 이 글에서 크로포드는 그것의 테스트 방법을 예로 들어 설명하고 있다.

댓글 없음:

댓글 쓰기