이번 학기 <인류 문명과 건설>이라는 과목을 듣고 있습니다. 교수님은 건축가 김진애씨. 저는 이분이 첫 수업 시간에 화이트보드에 기다란 시간의 수평선을 그리실 때부터 홀딱 빠져서는 열심히 수업을 경청하고 있지요 히히. 이 과목 숙제로 제출한 에세이를 또 슬쩍 올려봅니다.
사족 1) 서론과 예의상 대칭을 이뤄줘야 할 결론의 분량이 빈약한 것은 배고픈데 식당 문 닫을 시간이 다 되어가서 얼른 마무리를 하고 밥을 먹으러 가야 했기 때문입니당. ^^;;
사족 2) 아래 글을 보시다 보면 입실론 같은 것을 기묘하게 부르고 있는 걸 발견하실텐데 그건 나름대로 비전산인(?) 독자를 향한 배려라고나...
사족 3) 에세이에선 이론만 실컷 만들어놓았고, 이걸 실제 SF영화에 적용해 본 사례 연구는 에세이엔 없고 PPT에만 들어있습니다. 이것도 밥 때문인데..;; PPT는 다음 기회에...^^;;
아무튼 독특한 내지는 재미있는 아이디어를 내는 것에 초점을 맞추었으니 감상의 포인트를 그리 잡아주시고... 늘 부족하지만 즐감해주세요 ^^
다음 영화 중 2개 이상을 보고 나름의 스토리를 제출. 제출 형식은 자유. PPT, HTML, 워드, 동영상 등 뭐든지 오케이. 길이도 자유. 표현도 자유. 다만, 자신의 논점만 확실히 할 것. 왜 이 영화, 이 영화의 어떤 점, 리포터의 생각과의 같은 점 다른 점, 영화적 표현, 영화적 상상에 대한 소감, 당신이 SF 영화를 만든다면? (2분 발표를 예상하고 준비할 것)
영화 목록: 블레이드러너, 매트릭스, 브라질, 마이너리티 리포트, 12 몽키즈, 토탈 리콜, 지구를 지켜라, 스페이스 오디세이 2019, 메트로폴리스, 바바렐라, 천공의 성 라퓨타, 스타워즈 1/2/3/4/5/6, 해리포터, 반지의 제왕, 제 5원소, 아이로봇, 올드보이, 디워, 매드맥스 1/2/3, 에이리언, 우주전쟁, A.I., 바람계곡의 나우시카, 인디펜던스 데이, 이퀼리브리엄, 컨택트, 아일랜드, 미지와의 조우, 사인, 화성침공, 배트맨, 스타트랙, 스타게이트, 혹성탈출, 터미네이터, 라브린스, 가타카, 스피어, 워터월드, 포스트맨, E.T., 하울의 성, 엑스파일 등 기타 SF/판타지 등 어떤 영화도 좋음.
* 그리고 '공간'에 대한 이야기를 듣고 싶다는 교수님의 추가 주문이 있었습니다.
“전산학도는 영화에서 시스템을 본다”
공간: 시스템의 비유
내 막역지우 찬양이는 건축학도다. 설계가 너무 하고 싶어서 그리로 갔다 한다. 나는 전산학도다. 멋도 모르고 ‘한글로 된 OS를 만들고 싶다’며 이리로 왔다. 고등학교를 졸업할 무렵 우리는 전혀 다른 길을 걷고 있다고 생각했지만 지금에 와서 느끼는 것은 우리가 상당히 비슷한 문제를 다루고 있을지도 모른다는 것이다. 건축에서도, 전산에서도, 우리는 ‘이상’ 내지는 ‘시스템’이라고 부를 수 있는 개념을 각자의 머릿 속에 가지고 있다. 그것이 깔끔하고 정연한 질서를 갖춘 성당이든지, 생선 비린내 물씬 풍기는 왁자지껄한 시장이든지 간에 [1]. 개념 속의 이상과 시스템만을 꿈꾼다면 그것은 수식과 도식을 날개삼아 하늘을 날아다니는 수학자라 불러야 하겠지만, 우리들 ‘전산인’과 ‘건축인’이 그들과 다른 점이 있다면 그것을 현실 세계 속에 ‘구현’하는 것을 최종 목표로 삼는다는 점이다. 땅에 발을 딛고 서서 내 머릿 속의 시스템을 끌어내야 한다는 것이다.
1994년, 훌륭한 개발자 내지는 짖궂은 ‘네 명의 일당들’이 두 학문의 유사성을 일찌감치 간파한 일이 있다 [2]. 역시나 또 훌륭했던 건축가 크리스토퍼 알렉산더가 1977년에 정리한 건축에서의 디자인 패턴을 탐독하면서, 이들은 이 아름다운 원리들을 소프트웨어 개발에 접목시킬 생각을 했다. 전산이라는 분야는 과연, 다른 여느 공학에 비해 후발주자이긴 하지만, 오히려 더 유리한 점이 있으니 바로 이웃집의 좋은 것들을 가져다 쓸 수 있다는 것이다. 이를테면 소프트웨어 개발 공정의 자동화, 효율화, 정량화 등을 연구하는 소프트웨어공학에서는 태동의 시기에 자동차공학 등의 전통적인 생산 분야에서 여러 모티브를 따 오곤 했다. 그렇지만 전산인들이 다른 어느 분야보다도 특별히 건축에 눈독을 들이는 것은, 앞서 말한 바와 같이 ‘개념 속의 체계를 현실에 구현한다’는 비슷한 목표를 가지고 있기 때문이 아닐까 한다.
SF영화 몇 개 – 스타워즈와 매트릭스와 천공의 성 라퓨타. 매주 목요일 4시의 에너지 넘치는 즐거운 수업. 틈날 때마나 신나게 읽어댄 참고 서적들. 4년간 전산과에서 배워왔던 것들. 이 몇 가지를 버무려서, 공간에 대한 내 나름의 썰을 풀어볼까 한다.
공간?
먼저 공간Space이라는 것에 대해 잠시 음미할 필요가 있다. 무엇이 공간인가? 일상 생활에서의 공간이란 눈에 보이는 물리적인 면적과 부피의 덩어리를 일컫는다. 수학에서의 공간이란 벡터와 연산의 집합체이다. 전산에서의 공간이란 기억 장치 위의 섹터일 수도 있고, 웹 상에서의 하이퍼링크로 연결된 가상 공간일 수도 있고, 각 모듈들이 연결되고 쌓여 이룬 거대한 시스템일수도 있다. 그 어느 것 하나에도 한정짓지 않기 위해, 가능한한 이 공간 저 공간을 옮겨다니며 비유를 사용하려 한다. 전산과의 미덕인 타입 체크도 여기서는 조금은 느슨하게 하려 한다.
공간을 구성한다
공간을 구성하는 원리를 어떻게 잡으면 좋을까? 공간을 구성하는 원리는 실로 너무너무 다양할 것이지만, 크게 분류를 해 보라면 문법Grammar과 구조Structure라는 두 원리를 꼽고 싶다. 수업 시간에 배운 ‘분산과 통제’라는 모델에도 이 두 가지가 비교적 잘 들어맞을 것 같다.
공간 구성 원리 첫 번째. 문법
문법, ‘규칙으로 공간을 정의하는 방법’에 대해 이야기하기 위해 오토마타 수업시간에 들은 Context Free Grammar를 여기에 데려왔다. 형식 언어 이론에 따르면 문법 G는 다음과 같이 정의된다 [3].
G = (V, Σ, P, S)
(V: 미지수Variables, Σ: 열매Terminals, P: 규칙Productions, 씨앗Start Symbol)
우리가 얻고 싶은 것은 열매가 가득 달린 나무다. 공간에 비유하자면 구획이 모두 나눠지고 그 쓸모가 정해진 공간의 최종 모습이라고 할 수 있겠다. 먼저 씨앗에서 출발한다. 열매에서부터 시작하면 더 이상 싹을 틔울 것이 없으므로 보통은 미지수를 씨앗으로 삼는다. 다음, 여러 규칙 중에서 적절한 것을 적용해가며 미지수를 전개시킨다. 미지수의 전개라 함은 다른 미지수 또는 열매로 해당 미지수를 치환하는 것이다. 이렇게 계속하다보면 언젠가는 모든 미지수가 사라지고 열매만이 가득 달린 나무가 남을 것이다. 비유가 복잡하다면 아래의 예를 보자.
규칙: S → AS | ε (ε: 빈 열매)
A → 0A1 | A1 | 01
전개: S ⇒ AS ⇒ A ⇒ 0A1 ⇒ 0A11 ⇒ 00111
여기서 S는 씨앗이다. 텅 빈 어떤 광장이라고 해 보자. 이 씨앗에서부터 시작해서 우리는 위의 두 규칙 중 적합하며 맘에 드는 것을 골라 전개할 수 있다. 처음에는 S → AS 규칙밖에 적용되지 않는다. S → ε를 적용하면 빈 공간으로 게임이 끝나버리니 제외한다. 이후 우리는 AS라는 공간을 얻었다. 아직까지 우리가 가지고 있는 것은 미지수 뿐이므로 이 공간이 어떤 모습으로 분화할지 알 수 없다. 가능성만 점쳐볼 뿐이다. 다음으로 S → ε 를 적용하여 A를, A → 0A1를 적용하여 0A1을 얻었다. 이제 우리는 이 공간이 최소한 0으로 시작해서 1로 끝나는 공간이라는 것을 안다. 0을 잔디, 1을 보행로라고 해 보자. 이러한 방식으로 계속해서 미지수를 치환해나가다 보니 얻은 값이 00111이다. 잔디 잔디 보행로 보행로 보행로 라는 공간이 만들어졌다. 매 순간의 선택에 따라 결과값은 달라질 것이다.
문법으로 공간을 구성하는 방법의 특징은 무한한 방식의 공간을 유도해낸다는 것이다. 어느 순간에 어떠한 규칙을 적용할 것인가는 선택의 문제이며, 이 선택의 가짓수만큼의 공간이 나오게 된다. 즉, 문법 공간의 핵심은 결과의 다양성, 자생력, 선택의 분권, 예측 불가능성에 있다. 이러한 공간의 예로는 ‘언어’를 들 수 있겠고, 우리를 둘러싼 대부분의 자연물의 생김새와 구조, 시장 등이 있다. 전산 공간에서 찾아보자면 프랙탈나무를 쉽게 상상할 수 있다. 조금 색다른 예로 위키피디아를 들 수 있다. 최초에는 소수의 문서들에서 시작했을 것이다. 문서마다 다른 문서로 분화할 수 있는 미지수(여기서는 하이퍼링크)들을 심을 수 있다. 이 미지수가 분화하면 그 문서에는 또다른 미지수가 심겨져서 새로운 문서로 분화할 가능성을 열어두게 된다 [4]. 계속해서 자라나는 공간인 것이다. 그밖에, Kevin Kelly의 아홉 가지 규칙이 지배하는 세계 역시 생명의 씨앗과 규칙에 기반한 성장을 말하고 있으며, 우리가 사는 세계도 진화론을 믿는 한 이러한 방식으로 조금씩 분화해 온 공간이라 말할 수 있다 [5].
공간 구성 원리 두 번째. 구조
여기서 말하고 싶은 구조란 ‘객체와 관계로 공간을 정의하는 방법’이다. 벌써부터 고민이 생겨난다. 어떠한 것들을 객체로 삼아야 할까? 예를 들어 환경이라는 것을 모델링하고자 할때 ‘환경’이라는 객체부터 불쑥 말해야 하나 아니면 ‘땅’ ‘하늘’ ‘바다’부터 말해야 하나? 아니 바다보다 물이 더 상위 개념이니까 ‘물’부터 말하고 나서 ‘바다’와 ‘강’과 ‘호수’를 말해야 하나? 등등. UML 다이어그램을 그릴 때에도 늘상 고민스러운 것이지만, 사실 왕도는 없다고들 말한다. 뜻이 잘 통하면 되는 것이고, 상식에 맞으면 된다.
구조로 공간을 구성하는 절차를 보자. 먼저 공간을 구획한다. 좋아하는 숫자만큼 균일하게 쪼갤 수도 있고 격자로 쪼갤 수도 있고 동심원으로 쪼갤 수도 있다. 나뉘어진 공간 각각을 객체라 하자. 이제 각 객체의 특성을 정의한다. 객체의 종류와 용도, 들어오는 자원과 나가는 자원을 정의해준다. 예를 들어 구름인지 땅인지 정하고, 공업 용지인지 전답인지 정하고, 유동 원료와 제품과 정보와 농약과 가끔 오가는 다람쥐와 메뚜기 같은 것도 필요하다면 정한다. 마지막으로 각 객체들 간의 관계를 정의한다. 교환하는 자원의 종류는? 양과 빈도와 흐름의 방향은? 자원을 누가 수집하고 가공하고 저장하는지? 그 방법과 그에 따르는 비용은? 이 객체에 접근 가능한 객체들은 누구이며 얼마나 접근 가능한가?
구조로 만든 공간의 특징은 공간이 탄생할 때부터 그 구성이 결정된다는 것이다. 따라서 구조 공간의 목표는 효율성과 강력한 통제, 예측 가능성과 그에 따르는 안정성에 있다. 각종 건축물을 비롯한 인공물, 여러 컴퓨터 시스템도 여기에 들어간다. 게시판 및 대부분의 웹사이트들도 구조 공간이다. 계획 개발된 도시 역시 구조 공간이다. Matrix도 여기에 들어갈까? 나는 구조 공간에 가깝다고 생각한다. 아키텍트가 세심하게 설계한 21세기 지구 모습, 오라클, 스미스, 프로그래머 등으로 구성된 ‘세계’가 있다. 이 미리 갖추어진 세계 안에 사람들을 집어넣는다. 사람들은 자율적으로 행동하지만 세계를 변경하지는 못한다.
공간을 평가한다
문법 공간의 목표는 다양성, 자생력, 선택의 분권과 예측 불가능성이라고 했다. 그렇다면 만들어진 문법이 ‘좋은 공간인가’를 판단하는 척도는 무엇이 될 것인가? 문법이 좋은 문법인지는 비교적 쉽게 검증할 수 있다. 결과로 생겨난 단어(열매가 가득 달린 나무)를 보고 이 단어가 어떤 절차를 밟아 분화되어 왔는지를 정확히 유추할 수 있다면 모호성ambiguity이 없는 문법이라고 할 수 있다. 또한, 이 문법이 만들어낸 언어가 얼마나 많은 단어를 가지는 지를 살피는 것도 검증의 방법일 수 있다. 그러나 그렇게 생성된 수많은 단어 중의 하나를 집어들고 이것이 좋은지를 판단하려면? 조금은 어려운 문제다. 그저 ‘신이 보시기에 좋았다’ 즉 그 문법을 준 아키텍트의 입장에서 만족스럽다면 충분하지 않을까 싶다.
구조 공간의 경우에는 조금더 뚜렷한 목표를 가지고 있으므로 객관적인 평가의 기준을 세울 수가 있다. 효율성과 강력한 통제, 예측 가능성을 위한 설계이므로 ‘유효한가?’ ‘효율적인가?’라는 물음이 그 기준이 될 수 있다.
구조 공간에서 유효성과 효율성을 증명하기 위해 검증해야 할 것들은 무엇일까? 어떤 종류의 자원이, 누구 사이에, 얼마나 오가는지가 먼저 필요할 것이다. 자원의 방향과 양은 효율성을 판단하는 중요한 척도가 된다. 누가 누구에게 얼마 정도의 접근 권한을 가지는지도 알아야 할 것이다. 쓸데없이 권한이 많이 열려 있어 보안 문제를 야기할 수도 있고, 반대로 너무 제한되어 있어 자원의 동선이 길어질 수도 있다. 또한 누가 그 정보를 수집/가공/이용하는지도 중요하다. 가공 과정에서 자원의 양이 급격히 줄어들거나 늘어나는 일이 발생할 수 있으므로, 이것을 수집하는 주체와 붙어있어야 할지 이용할 주체에 붙어있어야 할지 판단해야 한다. 또한 각 처리 과정에서의 시간복잡도와 공간복잡도를 분석할 수도 있다. 요컨대, 정보의 흐름으로 그 공간의 유효성과 효율성을 판단하는 것이다.
이러한 요소들을 검증하기 위해, 구조 공간에서 다소 수고스럽게 택할 수 있는 방법은 시뮬레이션으로 검증하는 것이다. 여기서 말하는 시뮬레이션이란 실험적/물리적 방법으로 대상을 모사하는 것이다.
검증 순서는 다음과 같다. 먼저 공간의 구조를 모형으로 만든다. 각종 설계도나 UML, DFD, ERD와 같은 각종 모델링 언어를 이용할 것이다. 그리고 이를 조금 스케일 작게 구현한다. 목업이라든지, 데모 프로그램 등이 이 구현물에 해당한다. 구현물이 완성되면 실제와 비슷한 자원의 흐름을 생성하여, 발생하는 상황을 관찰한다. 예를 들어 모의 인구를 생성해서 유동시킨다든가, 모의 정보와 자원을 유통시키는 것이다. 어디에서 병목이 발생하는가? 공간의 부담 분배가 적절히 이루어지는가? 자원의 동선 중 이상한 것이 있는가? 트래픽은 감당할 수 있는 수준인가? 실제로 컴퓨터 시스템을 구현하다보면 예기치 않은 곳에서 기이한 동작을 하는 것을 볼 수 있는데, 모듈의 내부 동작이 예상한 것과 달라서일 때도 있고 – 한번은 URL을 인코딩하는 모듈을 오픈소스에서 가져다 사용했다가, 비정상적으로 느리게 동작하기도 했다 – 때로는 전혀 고려하지 않은 외부의 요소 – 네트워크 트래픽 등 – 가 간섭을 일으켜서일 때도 있다. 설계 단계에서 최대한 줄이려 노력해도 이러한 시행착오는 어쩔 수 없는 것이다. 시뮬레이션은 이렇듯 전혀 예상하지 못했던 문제를 발견하는 데에 도움을 준다.
그러나 이러한 시뮬레이션은 시간과 노력을 많이 소요하므로, 좀더 간편한 방법이 필요할 때가 있다. 서두에서 언급한 디자인 패턴을 다시 살펴보자. 크리스토퍼 알렉산더의 정의에 따르면 패턴이란 비슷한 문제에 대해 반복적으로 나타나는 해결법이다 [6]. 예를 들어 그는 ‘안마당은 동일한 방법으로, 적절하게 만들어지면, 사람들이 그 안에서 편안함을 느끼도록 도와준다’고 쓰고 그 ‘적절한 방법’에 대해 고금의 훌륭한 건축물들을 집대성한 결과를 기술해놓았다 [2]. 패턴은 공간을 잘 구성하기 위한 것이지만 공간을 평가하기 위한 방법으로도 훌륭히 쓰일 수 있다.
검증 순서는 다음과 같다. 이 공간의 구조가 어떤 패턴에 대응하는지 찾는다. 그 공간 자체 – 해결책 만을 보아서는 패턴을 완전히 파악할 수 없다. 형태만 보아서는 동일한 패턴인데 각 객체의 역할이 달라져서 전혀 다른 패턴이 되는 예도 있기 때문이다. 공간을 둘러싼 주변 문맥을 함께 보아야 한다. 패턴을 찾았다면, 해당 패턴의 제약사항과 영향력을 검토하며 이 공간에 적합한지 판단한다 [2]. 패턴 역시 왕도가 아니다. 많은 디자인 패턴 책에서는 패턴에 집착하여 눈을 흐리는 것을 몇 번이고 경고하곤 한다. 그러나 의사소통을 편리하게 하고 시간을 절약하기 위해서는 좋은 방법이라 할 수 있겠다.
지금까지 전산 공간을 설계하는 유용한 원리로 문법과 구조를 꼽아보았다. 이 두 원리를 건축 공간에 적용해보며 생각한 것은 건축인과 전산인이 추구하는 바는 많이 닮아 있으며, 서로 피드백을 주고받으며 유용한 원리를 발전시킬 수 있겠다는 것이다.
찬양이와 나를 묶어주는 공통점은 몇 가지 더 있다. 마감을 앞두고 밤새 작업실에서 ‘어떻게 하면 골판지를 45도 각도로 이쁘게 자를 것인가’ 골몰하던 찬양이나 세그멘테이션 폴트를 잡느라 코드 한 줄씩 스택 트레이스를 뜨던 나나, 실력을 연마하기 위해서는 먼저 부단히 ‘손’을 놀려야 한다는 점에서 닮았다. 이렇게 자조적인 농담을 하면서도 ‘아키텍트’의 경지를 향해 열심히 자라고 있다는 단단한 자부심을 가지고 있다는 것도 닮았다. 건축과 전산이 비슷한 특징을 많이 가지고 있는 이유 중의 하나는 이 학문들이 최종적으로는 기술 자체가 아니라 ‘통찰력’을 심어주기 위함이기 때문일 것 같다. 이러한 통찰력은 책만으로는 쉬이 배워지지 않는다. 도제 관계 속에서, 수많은 상황에 함께 맞닥뜨려 가면서 어깨 너머로 배우면 좀더 쉽다. 손을 더럽히는 수많은 삽질을 거쳐, 그 삽질의 개념을 간파하는 이론의 숙고를 거쳐, 마침내는 설계도 한 장 다이어그램 한 꼭지를 보면서 ‘어허 여기서 이런 문제가 발생하겠구료’ 신통력을 발휘하는 도사가 되는 것이다 [7].
– 끝 –
[0] 원래 붙여뒀던 제목 <공간: 시스템의 비유>가 다소 지루한 것 같아 물리학자는 영화에서 과학을 본다에서 부제를 슬쩍 빌려왔다.
[1] 이 비유는 오픈소스소프트웨어의 철학을 대표하는 에릭 레이먼드의 유명한 글 <성당과 시장 The Cathedral and the Bazaar>에서 따 왔다.
[2] 알란 섈로웨이, 제임스 트로트. 알기 쉬운 디자인 패턴.
[3] John E.
Hopcroft, Rajeev Motwani, Jeffery D. Ullman. Introduction to Automata
Theory, Language, and Computation.
[4] Jee H Oh는 GORI Garden에서 위키피디아를 밭과 씨앗으로 해석한다.
[5] Kevin Kelly. Out of Control.
[6] Erich
Gamma, Richard Helm, Ralph Johnson, John Vlissides. GoF의 디자인 패턴
[7] 사실 이 말은 우리 지도교수님께서 항상 하시는 말씀을 내 언어로 번역한 것이다.
직접 언급되지 않았지만 이 글을 쓰는 데에 영향을 준 책들
[8] 김진애. 매일매일 자라기.
[9] 김진애. 우리도시 예찬.
[10] 시오노 나나미. 로마인 이야기 1.
[11] 시오노 나나미. 바다의 도시 이야기 1.
[12] 슬라보예 지젝. 매트릭스로 철학하기.
[13] 아이작 아시모프 등. 세계SF걸작선.
